15:00:44 <sgallagh> #startmeeting Cockpit public meeting 2014-09-15
15:00:44 <zodbot> Meeting started Mon Sep 15 15:00:44 2014 UTC.  The chair is sgallagh. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:44 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:00:44 <sgallagh> #chair puiterwijk andreasn mvollmer stefw sgallagh
15:00:44 <zodbot> Current chairs: andreasn mvollmer puiterwijk sgallagh stefw
15:00:44 <sgallagh> #topic Welcome and Agenda
15:00:59 <sgallagh> Who is around?
15:01:02 * stefw o/
15:01:05 <sgallagh> .hellomynameis sgallagh
15:01:06 <zodbot> sgallagh: sgallagh 'Stephen Gallagher' <sgallagh@redhat.com>
15:01:12 <andreasn> .hellomynameis andreasn
15:01:13 <zodbot> andreasn: andreasn 'Andreas Nilsson' <anilsson@redhat.com>
15:01:38 <fche2> .hellomynameis fche
15:01:39 <zodbot> fche2: fche 'None' <fche@redhat.com>
15:01:43 <fche2> take that!
15:03:02 <sgallagh> No puiterwijk or mvollmer for now, I guess
15:03:44 <sgallagh> OK, I have several agenda items.
15:03:49 <sgallagh> #info Agenda Item: Test Day Tomorrow
15:03:52 <sgallagh> #info Agenda Item: Fedora 21 Status
15:03:56 <sgallagh> #info Agenta Item: Atomic Status
15:04:07 <sgallagh> Other agenda topics?
15:04:29 <andreasn> I think that sounds good
15:04:49 * fche is curious whether people had time to consider the pcp mail from last week
15:05:49 * sgallagh did not
15:06:16 <stefw> fche, i think that it makes sense in general
15:06:43 * fche would be glad to talk about it more here once your normal agenda's done
15:07:31 <mvollmer> sorry, late, have we started?
15:07:40 <stefw> yup
15:07:40 <andreasn> mvollmer: just now
15:07:46 <mvollmer> k
15:07:52 <stefw> pcp stuff step 1 seems to be something we should try to do first
15:07:53 <sgallagh> fche: Leave it for Open Floor, then?
15:08:17 <stefw> it's certainly the clearest ... but we can discuss it more later
15:09:04 <sgallagh> ok, let's start with the Test Day
15:09:10 <sgallagh> #info Agenda Item: Test Day Tomorrow
15:09:17 <sgallagh> #undo
15:09:17 <zodbot> Removing item from minutes: INFO by sgallagh at 15:09:10 : Agenda Item: Test Day Tomorrow
15:09:21 <sgallagh> #topic Test Day Tomorrow
15:09:32 <mvollmer> right, i think we are set.
15:09:55 <sgallagh> #info mvollmer says we are set
15:10:04 <andreasn> wiki page looks good. Very nice work!
15:10:12 <mvollmer> worst case: people can install TC7 or the live image.
15:10:13 <sgallagh> #info jscotka has a live media prepared for the event
15:10:30 <mvollmer> did anyone test that live image?
15:10:32 <sgallagh> #info Fedora Server Alpha TC7 has Cockpit 0.23
15:11:32 <sgallagh> mvollmer: jscotka claims to have done so
15:12:01 <mvollmer> sure, but better to double check. :-)
15:12:15 <mvollmer> #action mvollmer test the live image
15:12:18 <sgallagh> "(09:52:36 AM) jscotka: sgallagh, also docker is enabled and running, I've tested it now, and it is super working immediatelly without installation :-), after few minutes it will be uploaded  to fedora pages and will be aviable"
15:12:34 <sgallagh> OK
15:12:46 <sgallagh> Test cases looked good the last time I checked
15:13:24 <mvollmer> there is confusion re docker, I think.
15:13:31 <sgallagh> What sort of confusion?
15:13:36 <mvollmer> the test case tells people how to start docker.
15:14:01 <mvollmer> (using cockpit)
15:14:04 <andreasn> does it not run by default?
15:14:10 <mvollmer> but we also tell them how to start it via systemctl up front.
15:14:11 <sgallagh> Right, because if they are using just F21/TC7 rather than the live image, they would need to
15:14:21 <sgallagh> oh, right
15:14:30 <sgallagh> We should drop the systemctl example
15:14:37 <mvollmer> so one is redundant
15:14:43 <mvollmer> ok.
15:15:05 <sgallagh> #action mvollmer to remove redundant reference to starting docker with systemctl
15:15:13 <sgallagh> (ok to assign that to you?)
15:15:24 <mvollmer> #action mvollmer but leave a hint in place
15:16:00 <mvollmer> also, now we have both the result reporting app, and the old tables.
15:16:11 <sgallagh> We should direct everyone to the app
15:16:14 <mvollmer> is it ok to remove the tables?
15:16:18 <sgallagh> Yes
15:16:21 <mvollmer> ok
15:16:29 <mvollmer> #action mvollmer remove test result tables
15:18:25 <mvollmer> so all the images have cockpit 0.23?
15:18:34 <mvollmer> then we can remove the instructions to update it.
15:18:41 <mvollmer> (which I have just done... :-)
15:18:43 <sgallagh> ok
15:19:17 <mvollmer> yum -y install qemu\* is scarx
15:19:20 <mvollmer> *scray
15:19:22 <mvollmer> *scary
15:19:31 <fche> all of the above
15:19:35 * mvollmer relaxes and breathes out
15:20:14 <mvollmer> should we do something about that?
15:20:29 <mvollmer> (sorry, I haven't really checked the recent changes in that area.)
15:21:02 <mvollmer> ohh, the update, wait.
15:21:24 <mvollmer> #action mvollmer remind people to update cockpit to at least 0.23 when they use an existing F21 installation.
15:21:38 <sgallagh> right
15:22:22 <sgallagh> Anything else on the Test Day?
15:22:58 <mvollmer> yeah, what timezone is it in? :-)
15:23:24 <sgallagh> All of them :)
15:23:27 <stefw> usually it's all timezones, whenever anyone is awake
15:23:29 <mvollmer> I'll be online during Old World Office Hours
15:24:05 <sgallagh> I'll try to be around for the later Western world
15:25:16 <mvollmer> ok.
15:25:19 <mvollmer> next topic?
15:25:29 <sgallagh> #topic Fedora 21 Status
15:25:34 <sgallagh> How are we doing here?
15:26:12 <mvollmer> i think the dos partitions regression is still open, the rest is fixed.
15:26:23 <mvollmer> stefw, selinux policy is ok, right?
15:26:38 <mvollmer> (except that we can't cleanly update it with a new version.)
15:26:40 <stefw> yup
15:27:04 <sgallagh> Why can't we cleanly update it?
15:27:17 <mvollmer> stefw?
15:27:37 <stefw> that's mostly related to our test suite
15:27:47 <stefw> in the base selinux policy they've taken bits and pieces of cockpit related stuff
15:27:54 <stefw> and spread it out amoung various selinux modules
15:28:02 <stefw> so when we try to put in an updated selinux cockpit module
15:28:19 <stefw> it fails, because it conflicts with stuff outside of module its replacing in the base policy
15:28:35 <stefw> if everything cockpit related in the base policy was in the cockpit module
15:28:43 <stefw> then we could replace it cleanly during our testing, etc.
15:28:50 <stefw> for example, i have gssapi auth working here
15:29:02 <stefw> we'll need to change the selinux policy to permit reading teh keytab
15:29:13 <stefw> to keep our tests working
15:29:21 <stefw> ... we do have a work around
15:29:34 <stefw> and that is that we've commented out the bits that they've moved out of our base cockpit module
15:29:41 <stefw> ... and we just hope we don't need to change them
15:30:43 <mvollmer> in the worst case, we need to make a new version of the complete selinux policy, which is possible, but sucks a bit.
15:30:49 <stefw> quite a bit
15:31:06 <stefw> less worst case: rename our module and all our selinux types
15:31:09 <stefw> in our own policy
15:31:15 <stefw> but then we're not really testing properly
15:31:22 <stefw> anyway ... this shoudln't affect the test day
15:31:29 <stefw> as we want to test the selinux base policy and not our customized one
15:31:41 <mvollmer> no, but should Fedora 21 block on that?
15:31:54 <stefw> no, upstream has refused to fix hte issue
15:32:00 <mvollmer> right.
15:32:00 <stefw> or downstream selinux
15:32:02 <stefw> or whatever
15:32:14 <stefw> so it would be silly to block on it, given that we have a workable work around
15:32:15 <mvollmer> certainly not mainstream. :-)
15:32:22 <stefw> it's not something that's going to get fixed
15:32:31 <stefw> whereas hopefully the other issues we found in testing will get fixed
15:32:31 <mvollmer> ok.
15:32:32 <stefw> many already have
15:33:33 <sgallagh> #info Keeping the SELinux policy aligned with updates is difficult, as the cockpit-selinux package ends up conflicting with selinux-policy
15:34:35 <mvollmer> otherwise, we have a list of issues in the "Fedora 21 Beta" milestone, and we are working on those.
15:34:56 <mvollmer> come beta, i think we will split out the real beta blockers and move the rest to "Fedora 21".
15:36:06 <sgallagh> I'm going to note that I'm going to be advocating for simultaneous Beta Freeze and Final Freeze.
15:36:14 <mvollmer> ok.
15:36:19 <mvollmer> noted. :-)
15:36:26 <andreasn> nice
15:36:35 * stefw snorts :)
15:36:35 <sgallagh> So that once Beta is cut, we do not reopen the firehose until release.
15:36:50 <stefw> ... and then it opens anyway :S
15:37:04 <sgallagh> I want to release F21 within 2014
15:37:09 <stefw> i see
15:37:09 <stefw> good
15:37:19 <sgallagh> The current schedule is already at Dec. 04
15:37:32 <andreasn> wow
15:37:41 <sgallagh> Yeah, these Alpha slips are killing us.
15:37:48 <andreasn> :/
15:37:53 <mvollmer> #action mvollmer move non-embarrassing issues out of "Fedora 21 Beta" milestone.
15:38:22 <mvollmer> e.g., not being able to change the hostname is embarrassing.
15:40:50 <mvollmer> sgallagh, so once F21 is released, updates-testing will be disabled by default, right?
15:41:26 <fche> (mvollmer, what do you mean?  f* updates-testing is still alive for N=19..21)
15:41:42 <stefw> enabled=1
15:41:48 <sgallagh> It will no longer be enabled by default
15:41:49 <mvollmer> i mean, "yum update cockpit" will not install things from updates-testing.
15:42:16 <mvollmer> i try to summarize our release plan:
15:42:28 <sgallagh> Correct
15:42:39 <sgallagh> (Without --enablerepo=updates-testing, obviously0
15:42:42 <mvollmer> * everything in the Fedora 21 Beta milestone should be in "stable" when Fedora 21 is released.
15:43:13 <mvollmer> * Then we make regular, reasoanble releases from master for updates-testing.
15:43:35 <mvollmer> * When the excrement hits the air conditioning, we make a bug fix release that goes to "updates", somehow.
15:43:59 <mvollmer> stefw, does that sound right?
15:44:19 <stefw> the third point is only for security fixes and serious data loss issues
15:44:26 <stefw> not contradicting
15:44:30 <stefw> just clarifying the poo flinging
15:44:36 <mvollmer> yes.
15:44:56 <stefw> so basically the goal is that the stuff in fedora 21 will remain stable
15:45:08 <stefw> and for anyone who complains, wants newer stuff, wants to see if their bug got fixed ...
15:45:09 * mvollmer reads "hocus pocus" by vonnegut, which doesn't have any swear words in it.
15:45:13 <stefw> --enablerepo=updates-testing
15:45:15 <stefw> is for them
15:45:48 <sgallagh> Counter-proposal:
15:46:07 <mvollmer> hear hear
15:46:15 <sgallagh> We branch a stable release of Cockpit at Fedora 21 and do minor bugfixes on it where needed (such as CVEs)
15:46:25 <sgallagh> We maintain a COPR of the master branch for people who want new features.
15:46:50 <stefw> we decided against that, but happy to hear your reasoning ...
15:46:58 <sgallagh> (Well, Rawhide with duplicated COPR for older versions)
15:47:22 <mvollmer> would it make it simpler to actually release something to updates?
15:47:34 <sgallagh> stefw: Once someone installs a package from updates-testing, the versions need to continue going up or they'll get stuck
15:47:49 <stefw> that's how it'll be
15:47:56 <stefw> essentially we won't be branching Cockpit
15:48:09 <stefw> but maybe, we'll backport a fix or two into a revision here or there
15:48:10 <sgallagh> i.e. if we stick 0.24 into updates-testing, but then realize we need to fix a CVE for 0.23, we have two (bad) choices.
15:48:44 <sgallagh> 1) Push 0.25 into stable (0.24+CVE fix), thereby bringing in the potential instability
15:49:16 <andreasn> (almost at a hour, need to leave fairly soon)
15:49:19 <sgallagh> 2) Push 0.23-2 into stable, causing issues for anyone with 0.24
15:49:31 <sgallagh> Also, we can't send it directly into stable.
15:49:34 <stefw> i see
15:49:37 <stefw> yes, that's the problem
15:49:43 <mvollmer> what are the issues?
15:49:51 <stefw> that you can't send something to updates
15:49:52 <mvollmer> for the people with 0.24?
15:49:55 <stefw> without it first being in updates-testing
15:50:00 <stefw> you can't send two different updates
15:50:12 <stefw> so maybe we don't have the manpower to deal with overhead of routine updates for fedora 21 at all
15:50:17 <stefw> and we'll just send people to rawhide
15:50:23 <sgallagh> mvollmer: We would have to untag 0.24 from updates-testing, create 0.23-2, then wait for it to make it to stable before we could put 0.24-2 in updates-testing.
15:50:26 <mvollmer> stefw, why not copr?
15:50:43 <stefw> because we can barely cope with the overhead of this exercise as it is
15:50:56 <stefw> i guess we should try it and see how much work it is
15:51:00 <sgallagh> mvollmer: That was my proposal. A COPR that was just a trivial backport of master
15:51:05 <sgallagh> s/master/Rawhide/
15:51:09 <mvollmer> can't be that bad...
15:51:28 <mvollmer> sgallagh, a rebuild, hopefully.
15:51:33 <sgallagh> Of course, if you start depending on features that are Rawhide-only, that's a different story.
15:51:37 <stefw> perhaps it's not that bad, we should check
15:51:43 <sgallagh> 'rebuild == trivial backport' in my head
15:51:50 <mvollmer> right
15:51:51 <stefw> we could easily deadend right here and on pure maintenance without new features in cockpit ... given how few people are contributing
15:52:05 <stefw> so we just have to be careful with any long term overhead
15:52:28 <mvollmer> stefw, yes, but maybe we find someone from the community to handle the COPR.
15:52:34 <stefw> that's a good idea
15:52:43 <sgallagh> Of course, we can also agree that backwards-compatibility is a high priority for us and we break it only at greatest need.
15:52:47 <mvollmer> should be fun
15:53:03 <stefw> sgallagh, we haven't crossed the no-breaking backwards compatibility bridge yet
15:53:09 * sgallagh nods
15:53:17 <sgallagh> 1.0 :)
15:53:18 <stefw> it's very likely that the cockpit in fedora 22 will not be completely compatible with that in fedora 21
15:53:30 <stefw> at some point we certainly do need to nail that down
15:53:33 <mvollmer> we don't have any APIs, do we?
15:53:33 <stefw> but we're not ready yet
15:53:36 <stefw> we do
15:53:37 <stefw> sorta
15:53:40 <mvollmer> bookmarks, maybe.
15:53:41 <stefw> because we connect between machines
15:53:43 <sgallagh> Right, so why don't we just stick with the branch approach.
15:53:50 <sgallagh> It doesn't need to be an upstream branch.
15:53:50 <mvollmer> stefw, right.
15:53:56 <stefw> yeah, no upstream branch
15:54:07 <sgallagh> Just a statement that 0.23 (or whichever we land on) is there for the duration of F21's life
15:54:08 <stefw> and no downstream branch until there's a CVE or something equally serious
15:54:12 <sgallagh> With only CVEs backported.
15:54:17 <stefw> that is the downstream branch just sits
15:54:29 <stefw> sgallagh, yes
15:54:54 <mvollmer> yes
15:55:03 <mvollmer> so:
15:55:09 <mvollmer> * everything in the Fedora 21 Beta milestone should be in "stable" when Fedora 21 is released.
15:55:31 <mvollmer> * Then we make regular, reasoanble releases from master to rawhide.
15:55:50 <mvollmer> * someone maintains a COPR with a rebuild of rawhide cockpit for F21.
15:56:11 <mvollmer> * When the poo hits the fan, we make a release via updates-testing into updates.
15:56:43 <mvollmer> If we can't keep the COPR running, then people need to go to rawhide for the latest, greatest.
15:56:58 <stefw> makes sense
15:57:14 <mvollmer> i like that rawhide is in the picture.
15:57:29 <mvollmer> that's how it should be, I guess.
15:57:44 <mvollmer> but we already had releases in rawhide, right?
15:57:53 * mvollmer is naive.
15:58:24 <stefw> yes
15:58:28 <stefw> everything has gone to rawhide first
15:58:32 <stefw> but then a few minutes later
15:58:32 <mvollmer> right
15:58:35 <sgallagh> As it is required to
15:58:35 <stefw> gone into other branches
15:59:23 <mvollmer> one day I will understand how this fedora sausage is made....
15:59:43 <sgallagh> proposed #agreed The release that goes into the Fedora GA will be maintained for serious (CVE) issues only. All newer upstream releases will go to Rawhide and may also be maintained for stable Fedora in a COPR.
15:59:47 <sgallagh> ack/nack/patch?
16:00:00 <mvollmer> ack
16:00:24 <stefw> ack
16:00:37 <andreasn> sure
16:00:45 <sgallagh> #agreed The release that goes into the Fedora GA will be maintained for serious (CVE) issues only. All newer upstream releases will go to Rawhide and may also be maintained for stable Fedora in a COPR.
16:01:22 <mvollmer> ok, very good.
16:02:27 * stefw has got to go
16:02:38 <andreasn> me too :(
16:02:47 <mvollmer> ok, see you, and thanks!
16:02:57 <stefw> o/
16:03:41 <andreasn> later!
16:03:41 * sgallagh has an emergency and needs to go
16:03:52 <andreasn> Atomic discussions more next week then
16:03:59 <mvollmer> ok!
16:04:05 <andreasn> same with pcp
16:05:55 * fche will hang around here if someone's in the mood & is available for pcp conversations
16:06:02 <fche> we'd need just a starting point or two
16:11:02 <mvollmer> i am here a bit
16:11:42 <mvollmer> we had a pcp starting point way back when, but it always had low priority for us.
16:12:01 <fche> yup, saw your old code, looked like a decent start
16:12:20 <fche> would you like us to massage it into a backend for one of the existing agent -monitor.[ch] files ?
16:12:27 <mvollmer> that was contributed by someone, but i think we lost the attribution when we went public... :-
16:12:54 <mvollmer> yes, that would help.
16:13:19 <fche> ok, any preference which one ?
16:13:35 <mvollmer> netdev and/or blockdev monitoring.
16:13:53 <fche> ok, will get back to y'all in a few days
16:14:03 <mvollmer> cool.
16:14:46 <mvollmer> if you want to change the D-Bus API, feel free.
16:14:55 <mvollmer> it doesn't need to be drop-in.
16:15:02 * fche likes little surgical changes though if possible
16:15:07 <mvollmer> yes.
16:15:28 <mvollmer> if we could get access to historical data, that would be great.
16:16:28 <fche> that's more akin to step 2 of the integration ideas - identifying & talking to a log archive, we need to talk about possible approaches to that
16:16:30 <fche> a bit later
16:16:32 <mvollmer> fche, out of interest, do you have some magical performance enhancing sauce in pcp that goes beyond mere /proc reading an parsing?
16:16:48 <mvollmer> fche, ok, fair enough.
16:17:16 <mvollmer> of course, getting rid of our own /proc parsing is a huge win already.
16:17:20 <fche> re. magic perf-enhancing sauce ... /me won't promise that going through pcp will necessarily make those little parts faster
16:17:30 <fche> just that any remaining sloth can be filed as bugs in our code rather than yours :-)
16:17:38 <mvollmer> yeah
16:17:51 <fche> (and we do have some medium-sized cherry picking opportunities in e.g. not constantly reopening /proc files.)
16:18:12 <fche> so for now, yeah, think of pcp as a /proc parsing offload thingie
16:18:31 <fche> then when we go to archiving / historical work, you'll see the other angles
16:18:45 <mvollmer> right
16:19:19 <mvollmer> totally unrelated: can you use systemtap to get a notification when someone calls sethostname?
16:19:26 <fche> certainly
16:19:31 <mvollmer> systemd-hostnamed should maybe do that.
16:22:11 <fche> # stap -e 'probe syscall.sethostname { println(name) }'
16:22:36 <stefw> mvollmer, it requires kernel-debuginfo and kernel-devel, gcc, and etc...
16:22:48 <fche> not necessarily kernel-debuginfo.
16:22:50 <mvollmer> ahh.
16:22:52 <stefw> it basically compiles a kernel module on the fly and sticks it in
16:23:09 <stefw> at least that's how i understand it
16:23:13 <mvollmer> can such a module be pre-compiled and shipped in the systemd package?
16:23:37 <fche> stefw, yes, that's the dominant model (there is also a separate --runtime=dyninst one, but not applicable here)
16:23:44 * mvollmer is just generally excited about getting all kinds of notifications out of the kernel that we can't get otherwise.
16:24:39 <mvollmer> such as use% of a filesystem.
16:24:39 <fche> mvollmer, maybe the place for this sort of thing wouldn't be systemd per se, but stap/pcp.  (we're looking into just such integration of our two bad boys, passing notifications and such out to pcp clients as events)
16:24:49 <fche> use% of filesystem - already avail. from plain pcp / proc
16:25:05 <mvollmer> with notifications, without polling?
16:25:34 <fche> well ... not sure what that'd look like .... want to trap each filesystem write or free-block manipulation, and keep tabs?
16:25:44 <mvollmer> i don't know...
16:26:11 <fche> we haven't found polling with reasonable frequencies (1-60 seconds e.g.) a problem fwiw
16:26:44 <mvollmer> it's slightly inelegant because then the system never goes completely idle.
16:27:02 <fche> yup
16:27:06 <mvollmer> otherwise, idle system -> no changes can happen.
16:27:21 <fche> well, polling itself could be regulated by notifications of idlenss
16:27:34 <mvollmer> yes
16:29:13 <mvollmer> ok, logging out here....
16:30:19 <fche> see ya
17:46:44 <sgallagh> #endmeeting