13:01:55 <mvollmer> #startmeeting
13:01:55 <zodbot> Meeting started Mon May  4 13:01:55 2015 UTC.  The chair is mvollmer. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:01:55 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
13:02:00 <mvollmer> .hello mvo
13:02:01 <zodbot> mvollmer: mvo 'Marius Vollmer' <marius.vollmer@gmail.com>
13:02:05 <andreasn> .hello andreasn
13:02:06 <zodbot> andreasn: andreasn 'Andreas Nilsson' <anilsson@redhat.com>
13:02:33 <dperpeet> .hello dperpeet
13:02:33 <zodbot> dperpeet: dperpeet 'Dominik Perpeet' <dperpeet@redhat.com>
13:02:55 <mvollmer> #topic Agenda
13:03:22 <mvollmer> * Storage update
13:04:06 <dperpeet> * testing
13:06:12 <mvollmer> ok, let's go.
13:06:17 <mvollmer> #topic Storage update
13:06:19 <andreasn> small agenda today :)
13:06:27 <mvollmer> yeah, nice weather outside... :-)
13:06:35 <andreasn> it's complete shit here
13:06:48 <andreasn> well, no snow
13:06:50 <andreasn> so ok
13:06:54 <mvollmer> :-)
13:07:08 <mvollmer> so, I am still rewriting the storage, and I am still happy.
13:07:08 * dperpeet gets ready the sunblocker for later
13:07:32 <mvollmer> progress is slower than I thought, but looks like storaged gets some nice features
13:07:52 <mvollmer> i was never super happy with the fstab cleanup that cockpitd did, for example
13:07:55 <mvollmer> and that is now better
13:08:16 <dperpeet> we do it or is that now a storaged feature?
13:08:33 <mvollmer> it will be a storaged feature, if I can get it in.
13:08:40 <dperpeet> nice!
13:08:46 <mvollmer> right now it is a cockpit-wrapper feature
13:09:20 <mvollmer> but it is too magical and requires cockpitd to observe the system constantly, which it doesn't, of course.
13:09:31 <dperpeet> and shouldn't :)
13:09:35 <mvollmer> of course
13:10:30 <mvollmer> so, I hope to have a big pull request for storaged in a couple of days.
13:10:38 <andreasn> nice!
13:11:01 <mvollmer> i was aiming for last week, so let's see how that prediction goes...
13:11:11 <mvollmer> (nice weather outside, btw...)
13:11:50 <mvollmer> ok, eot?
13:12:41 <dperpeet> good to see progress!
13:13:55 <mvollmer> yes, this should be nice.
13:14:23 <mvollmer> and I hope that andreasn (and the restof us) can then apply a lot of polish to storage
13:14:30 <mvollmer> like, validation of _all_ input fields
13:14:30 <andreasn> indeed
13:14:35 <mvollmer> sliders for size
13:14:39 <andreasn> yeeees!
13:14:40 <mvollmer> etc.
13:14:56 <andreasn> if I could have one thing this year, it would be that! :)
13:14:57 <dperpeet> :)
13:15:13 <mvollmer> heh, we could have done that even with the current code... :-)
13:15:20 <dperpeet> heh, andreasn has officially used up his wish-of-the-year 2015
13:15:37 <andreasn> dperpeet: kind of regret it now, still in the first half and all
13:16:06 <dperpeet> mvollmer, move on?
13:16:10 <mvollmer> let's make it the mid-summer present
13:16:14 <mvollmer> ok
13:16:17 <mvollmer> #topic Testing
13:16:41 <dperpeet> I've been working on Fedora Atomic testing
13:16:42 <dperpeet> https://github.com/cockpit-project/cockpit/pull/2231
13:17:05 <dperpeet> for that I've added support for qcow2 images (instead of root tarball)
13:17:11 <dperpeet> in our test suite
13:17:11 <mvollmer> ohh.
13:17:19 * mvollmer has been coding under a rock
13:17:32 <dperpeet> and check-login works with the deployed cockpit container
13:17:55 <dperpeet> what I'm currently working on is pushing a new state into the machine
13:18:17 <mvollmer> so tarballs are no longer supported?
13:18:20 <dperpeet> the currently proposed strategy on that is write-mounting the container file system and replacing stuff
13:18:32 <dperpeet> mvollmer, both methods work now
13:18:34 <mvollmer> ok
13:19:04 <dperpeet> copying files into the container seems to be the best way right now, but I'm still evaluating that
13:19:30 <dperpeet> also there are news regarding the new tests
13:19:47 <dperpeet> any comments on atomic or questions before I proceed?
13:20:36 <mvollmer> mounting  rw seems sane to me
13:20:59 <dperpeet> technically we could build a container and push that
13:21:14 <dperpeet> but I think just copying new stuff seems good enough and is probably faster
13:21:25 <dperpeet> so, on to the new tests:
13:21:27 <mvollmer> depends on what we are testing
13:21:45 <mvollmer> cockpit as part of atomic, or cockpit in a container
13:21:49 <dperpeet> instead of replacing our current tests, the two technologies will probably merge
13:22:05 <dperpeet> cockpit as part of atomic should be the goal
13:22:32 <dperpeet> after some discussion last week we came to the conclusion that moving all tests to avocado doesn't make much sense
13:22:41 <dperpeet> some will have to stay in virtual machines
13:23:19 <mvollmer> we could ue avocado instead of testlib.py
13:23:21 <mvollmer> *use
13:23:22 <dperpeet> I'm working on merging the testing processes and on some finer controls for individual tests
13:23:44 <dperpeet> ok, let me rephrase
13:24:03 <dperpeet> there will always be tests (e.g. destructive ones) that fare better in a vm with snapshotting capabilities
13:24:24 <dperpeet> so some tests will run like that
13:24:48 <dperpeet> others can run without a reset
13:24:53 <dperpeet> afterwards
13:24:53 <petervo> will avocado do the setup and teardown for those vms?
13:25:09 <petervo> or still the current scripts/setup
13:25:19 <dperpeet> avocado has a vm plugin
13:25:36 <dperpeet> but the way it's setup is that it doesn't reset between the individual tests
13:25:53 <dperpeet> so you have [save test-0 test-1 ... test-N reset]
13:26:16 <mvollmer> the vm plugin is for executing a complete test inside a remote machine
13:26:21 <dperpeet> before I start implementing those changes I think we need to go to a design phase
13:26:31 <mvollmer> but we would run the test outside of the vms, right?
13:26:44 <dperpeet> an example is the reboot test
13:26:59 <dperpeet> difficult to run from inside a vm, as mvollmer noted
13:28:27 <dperpeet> well, basically we now know that we won't replace everything we're currently doing in test
13:28:43 <dperpeet> a hybrid model is probably the way to go
13:29:32 <dperpeet> not because it makes our tests better for CI, but because looking to the future we might want to run in different test setups, e.g. bare metal, where it doesn't make sense to reset as often
13:30:16 <dperpeet> my goal would be to design this a bit and patch our current system into a state that supports tests compatible with the new system
13:30:44 <dperpeet> then we can decide what to do for each test as time permits
13:30:49 <dperpeet> and needs dictate
13:30:52 <mvollmer> sounds good
13:31:33 <mvollmer> i feel that bare metal _manual_ testing might be very interesting
13:31:46 <mvollmer> to see how a machine actually behaves
13:32:08 <dperpeet> hm, maybe
13:32:36 <dperpeet> do you have anything specific in mind? =)
13:33:20 <mvollmer> no, not really.
13:33:37 <mvollmer> i think andreasn is our man in the danger suit
13:33:44 <dperpeet> one thing I want to do is move away from custom qemu calls a bit and use libvirt
13:33:51 <mvollmer> managing his home server with cockpit, no?
13:33:52 <dperpeet> I've done that locally with the new tests and it works
13:34:08 <mvollmer> dperpeet, yes, that is a very good thing.
13:34:30 <mvollmer> i didn't want to learn about libvirt when I wrote the current testvm code
13:34:31 <andreasn> I tend to run stable Fedora on it, but I can start running the bleeding edge on one of the ARM systems
13:36:51 <dperpeet> anyway, immediate future is Atomic Testing
13:37:08 <dperpeet> then we can consider merging the tests
13:37:11 <dperpeet> /eot
13:37:46 <mvollmer> #topic Open floor
13:38:50 <mvollmer> ok, seems we are done.
13:39:04 <mvollmer> #endmeeting