14:04:54 <andreasn> #startmeeting Cockpit weekly meeting
14:04:54 <zodbot> Meeting started Mon Dec 14 14:04:54 2015 UTC.  The chair is andreasn. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:04:54 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
14:04:54 <zodbot> The meeting name has been set to 'cockpit_weekly_meeting'
14:05:04 <andreasn> .hello andreasn
14:05:05 <zodbot> andreasn: andreasn 'Andreas Nilsson' <anilsson@redhat.com>
14:05:12 <jscotka> stefw, I've added some changes to selenium starting script https://github.com/cockpit-project/cockpit/pull/3329, It should at least better check if started browsers are aviable via web iface.
14:05:24 <stefw> .hellow stefw
14:05:26 <stefw> .hello stefw
14:05:27 <zodbot> stefw: stefw 'Stef Walter' <stefw@redhat.com>
14:06:11 <petervo> hi
14:06:31 <stefw> * tuned work
14:06:38 <andreasn> #topic agenda
14:06:43 <stefw> * tuned work
14:06:54 <andreasn> * container scanning
14:07:00 <stefw> * Scheduling different kinds of tests
14:08:26 <mvollmer> .hello mvo
14:08:27 <zodbot> mvollmer: mvo 'Marius Vollmer' <marius.vollmer@gmail.com>
14:08:44 <andreasn> * docker storage
14:09:19 <andreasn> ok, lets start
14:09:27 <andreasn> #topic tuned work
14:09:48 <stefw> It's great to see the progress around the pull request, design, and upstream API changes
14:10:12 <stefw> I think our consensus was that we clean up and merge the prototype this week, but not ship it
14:10:14 <stefw> does that still stand?
14:10:25 <stefw> it won't be shipped until it's "ready" with the proper design, and tests
14:10:54 <andreasn> will it be disabled somehow?
14:11:25 <stefw> well it won't be packaged
14:11:36 <andreasn> ah, ok
14:11:36 <stefw> so in order to see it, you need to manually make install or run from cockpit sources
14:11:46 <andreasn> right
14:12:16 <andreasn> so do we keep the pull request open even if we merge, to keep the discussion, or move it elsewhere?
14:12:32 <stefw> close the pull request, but we should move the relevant sttuff to a featurte page, no?
14:13:09 <andreasn> sure. I think most of it is on a feature page already
14:14:30 <andreasn> https://github.com/cockpit-project/cockpit/wiki/Feature:Performance-tuning
14:14:38 <andreasn> need to update the mockup there
14:15:34 <andreasn> but yeah, lets get the pull in
14:16:15 <andreasn> anything else with regards to tuned?
14:16:39 <andreasn> really nice progress on it in general!
14:16:40 <stefw> nope, that should be good
14:16:44 <stefw> yes for sure
14:17:36 <andreasn> all right, next up container scanning
14:17:52 <andreasn> #topic container image scanning
14:18:11 <andreasn> got a bit delayed due to tuned showing up last week, but it's still in progress
14:18:17 <andreasn> mockups 90% there
14:18:24 <andreasn> will finish this week
14:18:41 <andreasn> next up?
14:19:03 <stefw> #topic Scheduling different kinds of tests
14:19:04 <andreasn> #topic scheduling different kinds of tests
14:19:15 <stefw> I've been thinking about how to schedule different kinds of tests, not just the verify test suite.
14:19:32 <stefw> and have those other tests also be run by the verify machines
14:19:51 <stefw> for example, having build checks against koji on various architectures run
14:20:10 <stefw> this also means not everything has to be in one big test suite.
14:20:16 <stefw> the avocado tests could run as their own test suite
14:20:35 <stefw> the first step to doing this is to split apart check-verify as mvollmer said we should do a while back
14:20:50 <stefw> and have a github-task script ... which calls various other things, like check-verify
14:21:03 <stefw> if there are no objections, i'd like to put in a dummy github-task script first
14:21:10 <stefw> so that the verifiers can be upgraded to call that
14:21:14 <mvollmer> sounds good
14:21:18 <stefw> and once that's in place, do the actual work to split things apart
14:21:31 <stefw> this would also mean that the github status contexts get a bit more wordy
14:21:32 <stefw> such as
14:21:34 <stefw> verify/fedora-23
14:21:39 <stefw> verify/rhel-7
14:21:40 <stefw> etc.
14:22:36 <stefw> ok, i guess we can move to the next topic
14:22:39 <andreasn> sure
14:22:40 <mvollmer> so a tets would trigger a koji build?
14:22:48 <mvollmer> and then wait for it to complete?
14:22:50 <stefw> mvollmer, yeah, not sure if it would be required
14:23:02 <stefw> well something like that
14:23:08 <mvollmer> right
14:23:21 <mvollmer> would be good not to block the whole machine during that time
14:23:30 <stefw> yes, one can post the koji build id to the status
14:23:40 <stefw> and then have a way to have the next test run check how it went
14:23:54 <mvollmer> yep
14:24:12 <andreasn> #topic docker storage
14:24:44 <andreasn> so this is pretty high up on the roadmap, and the feature page is done since a while back
14:24:57 <andreasn> I think garrett was interested in helping with designs on that
14:25:03 <andreasn> so things are looking good
14:25:35 <stefw> cool, and i guess this will be the 'main' storage UI on Atomic Host right?
14:25:42 * stefw notes that we don't have one there right now
14:26:48 <andreasn> yeah, I think so
14:27:44 <andreasn> this is the feature page https://github.com/cockpit-project/cockpit/wiki/Atomic:-Docker-Storage
14:28:05 <andreasn> it's mostly about growing the storage for the containers
14:28:08 <stefw> i think so
14:28:18 <stefw> resizing the operating system right now would be too complex
14:29:01 <andreasn> yeah
14:30:10 <andreasn> so I'll discuss this more with garrett tomorrow I think
14:30:21 <andreasn> or later today
14:30:32 <stefw> nice
14:30:54 <andreasn> anything else?
14:31:00 <andreasn> #topic open floor
14:32:27 <mvollmer> some debian update maybe
14:32:44 <mvollmer> now I want to test every PR against unstable
14:32:46 <andreasn> sure
14:33:24 <mvollmer> works ok so far, but NM still doesn't allow an admin to control all network configs
14:33:30 <mvollmer> don't yet know why
14:33:55 <mvollmer> i had expected that this is fixed in the polkit policy
14:34:00 <mvollmer> *shrug*
14:34:25 <mvollmer> just because it is interesting: Debian has a nasty docker transition ahead
14:34:38 <mvollmer> stable uses aufs, unstable uses overlayfs
14:34:46 <mvollmer> there is no kernel in debian that can do both
14:34:56 <mvollmer> but docker needs that for transitioning
14:35:15 <mvollmer> we can cleanly workaround this when making images
14:35:40 <mvollmer> i am curious how they solve this
14:36:18 <stefw> there's another docker transition ahead by the way, as far as i know
14:36:25 <mvollmer> altogether, I am now in favor of not shipping network support for Debian
14:36:26 <stefw> docker 1.10 uses a completely different on disk format
14:36:30 <mvollmer> until we have sorted it out
14:36:35 <stefw> mvollmer, ok, that makes sense
14:36:52 <mvollmer> there are two issues:
14:37:06 <mvollmer> eth0 is unmanaged by default and we don't deal with that as weel as we should
14:37:14 <mvollmer> the polkit issue
14:37:38 <mvollmer> rather, we don't disable button based on polkit, but we should
14:38:09 <mvollmer> so, it's mostly our work, and a polkit policy tweak in NM
14:38:37 <mvollmer> eot
14:39:02 <andreasn> all right
14:39:06 <andreasn> end of meeting?
14:39:27 <stefw> yup
14:39:31 <andreasn> #endmeeting