15:00:16 <puiterwijk> #startmeeting Cockpit public meeting 2014-09-01
15:00:16 <zodbot> Meeting started Mon Sep  1 15:00:16 2014 UTC.  The chair is puiterwijk. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:16 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:00:18 <puiterwijk> #chair puiterwijk andreasn mvollmer stefw sgallagh
15:00:18 <zodbot> Current chairs: andreasn mvollmer puiterwijk sgallagh stefw
15:00:20 <puiterwijk> #topic Welcome
15:00:37 <puiterwijk> okay, so just a short roll call who is arround here for the meeting?
15:00:46 * mvollmer is
15:01:10 <yinzhang> me
15:01:23 * stefw is here
15:01:24 <puiterwijk> #info Today is Labor day in the US, so nobody from the US will be here probably
15:01:38 <puiterwijk> #topic Fedora 21 status
15:01:58 <puiterwijk> okay, so a quick update on Fedora 21: we got the port change release in F21 Alpha, should be in TC5+
15:02:13 <puiterwijk> this was release 0.21 for those taking count
15:02:20 <mvollmer> great
15:02:34 <puiterwijk> #info Port change to 9090 in release 0.21, which is in Fedora 21 Alpha
15:02:58 <mvollmer> so we should write the test day test cases for 0.21, right?
15:03:05 <puiterwijk> mvollmer: yes.
15:03:11 <mvollmer> ok
15:03:17 <puiterwijk> #info Cockpit 0.21 will be in the test composes used for test days
15:03:28 <stefw> have we had any further decisions on what the test cases should cover?
15:03:50 <puiterwijk> I think we decided somewhere between hand-holding and abstract, but not exact, no
15:04:03 <mvollmer> only root login, no focus on dialog input validation
15:04:27 <puiterwijk> #info Cockpit test day on 2014-09-16
15:04:46 <mvollmer> puiterwijk, should we review last weeks action items?
15:05:09 <puiterwijk> mvollmer: sure. let me get the meeting minutes
15:05:36 <puiterwijk> mvollmer will merge Pull Request #870, changing our port to 9090
15:05:46 <mvollmer> done
15:05:56 <puiterwijk> puiterwijk will make a new release and submit to Fedora today
15:06:01 <puiterwijk> done
15:06:46 <puiterwijk> puiterwijk to review and merge open PRs => was not done, mainly because of next one
15:06:53 <puiterwijk> andreasn working through post-review, to report to puiterwijk once ETA is available to plan exact release time
15:06:55 <puiterwijk> andreasn: ?
15:07:06 <puiterwijk> mvollmer to rename F21 Sprint to F21 Alpha
15:07:09 <mvollmer> done
15:07:21 <mvollmer> and closed already, moved all open isues to Fedora 21 Beta
15:07:38 <puiterwijk> that also covers the next one then I guess: mvollmer andreasn puiterwijk to review open issues filed under F21 Sprint and F21 milestone to see which are needed before Alpha
15:07:58 <puiterwijk> well, for Alpha was already too late anyway. we should check which issues are blockers for F21 Beta
15:08:00 <mvollmer> done my share
15:08:32 <stefw> when does the alpha freeze lift?
15:08:34 <puiterwijk> okay, so do we have any blockers so far?
15:08:41 <puiterwijk> stefw: when alpha is releases
15:08:43 <puiterwijk> released*
15:08:58 <stefw> so are we going to continue with our releases in the mean time?
15:09:03 <mvollmer> https://github.com/cockpit-project/cockpit/issues/1099
15:09:03 <stefw> and just not put them in fedora?
15:09:28 <puiterwijk> stefw: well, I would say that's okay, though it might hinder with getting stuff through the blocker process if we get releases with fixes for other things than approved blockers
15:09:44 <stefw> i imagine we'd have to patch those in anyway
15:10:01 <stefw> but yeah, it's a tradeoff
15:10:10 <stefw> fedora isn't our only target (more on that later)
15:10:16 <puiterwijk> that's also an option. yeah, I'd say to go ahead with releases, and if we can't get something through the blocker process we'll just patch it
15:10:26 <stefw> k
15:10:44 <puiterwijk> #info Normal releases to continue, and if something gets stuck for blocker process, patch that instead of new release
15:10:59 <puiterwijk> note that we can always send zero-day updates for non-critical things
15:11:11 <puiterwijk> (so after all the freezes etc have been lifted)
15:11:47 <mvollmer> we should agree how we treat Cockpit in Fedora 21.  Stable?  Rolling beta?
15:12:02 <puiterwijk> mvollmer: I'd say stable, given that it's the server product..
15:12:17 <puiterwijk> well, relatively stable. aka, do not add new features, but fix bugs
15:12:24 <stefw> what does stable mean?
15:12:30 <stefw> our internals and API certainly aren't stable
15:12:39 <stefw> for example, the cockpit in f22 won't work with the cockpit in f21
15:12:47 <stefw> although hopefully the one in f22 will work with all others after that.
15:12:58 <puiterwijk> stefw: right, but we shouldn't make any major UI changes or add new major features after F21 is releases I think
15:13:02 <puiterwijk> (within the F21 release)
15:13:03 <mvollmer> stable == we don't surprise users too much and we try very hard not to release bugs.
15:13:10 <stefw> so we branch?
15:13:17 <puiterwijk> stefw: I'd say yes
15:13:19 <stefw> or we just let it rot
15:13:24 <stefw> without any fixes?
15:13:28 <puiterwijk> I say branch and do bugfixes
15:13:57 <mvollmer> i am afraid we don't have enough dev power for a branch
15:14:01 <stefw> yeah
15:14:11 <puiterwijk> hmm, that's true.
15:14:19 <stefw> i would put my dev power behind fixes that actual users discover and patches from others
15:14:38 <puiterwijk> but I don't think we should make major UI changes or the like after GA
15:15:06 <stefw> yeah, i'm torn on that
15:15:20 <stefw> maybe we should leave the one in f21 locked to the GA release
15:15:22 <stefw> but in updates-testing
15:15:27 <stefw> track the latest release
15:15:30 <stefw> or something like that
15:15:30 <andreasn> hi! sorry for being later!
15:15:35 <andreasn> late
15:15:46 <mvollmer> stefw, yes, sounds good.
15:15:47 <puiterwijk> stefw: yeah, that's certainly possible. sojust not push it to stable?
15:15:54 <stefw> yeah
15:15:56 <puiterwijk> just like F20 now
15:16:08 <stefw> because then people can use the 'stable but broken' or 'unstable but also broken ' :P
15:16:19 <puiterwijk> hah, right :)
15:16:20 <stefw> no seriously ... they can choose which bugs affect them
15:16:21 <mvollmer> hehe, right.
15:16:24 <stefw> and help with development, testing, etc...
15:16:49 <mvollmer> yeah, if you are happy with the corner of cockpit that works for you, you might not want to update.
15:16:51 <puiterwijk> #info Freezing Cockpit after F21 GA for updates, but still push new versions to updates-testing
15:17:00 <stefw> i would be in favor of no branch ... and nothing but security updates in F21 stable
15:17:11 <puiterwijk> stefw: that works for me
15:17:19 <mvollmer> yes, sounds like a good compromise.
15:18:06 <puiterwijk> mvollmer: so for the blocker bug: that needs to be filed in bugzilla, and marked as a blocker candidate for Beta
15:18:24 <puiterwijk> (or possible even Alpha if you're daring and want to defend that)
15:18:39 <puiterwijk> so if you want to, I can do that, or you can, either works for me
15:18:55 <stefw> but above only applies after Fedora 21 is actually released, right?
15:19:02 <stefw> we can keep updating f21 until then
15:19:04 <puiterwijk> yup, after F21 GA
15:19:09 <stefw> minus freezes of course
15:19:15 <puiterwijk> yeah
15:19:46 <puiterwijk> note that between freezes there's still a stricter commit policy which we should take into account
15:20:10 <puiterwijk> but there's nothing actually preventing us from updates
15:21:33 <puiterwijk> mvollmer: so do you think you can fix the blocker between freezes, or would it take longer than that?
15:21:43 <puiterwijk> #info Beta freeze starts 2014-09-30
15:22:01 <puiterwijk> #info Translation freeze starts 2014-09-30
15:22:16 <mvollmer> puiterwijk, I have patch, which needs testing of course.
15:22:30 <puiterwijk> mvollmer: okay, great. so then I guess we don't need a freeze exception for that
15:22:41 <mvollmer> puiterwijk, would be nice to get it into alpha.
15:23:00 <puiterwijk> mvollmer: that would be possible, though that needs a freeze exception
15:23:07 <mvollmer> but I can't say whether it is justified to delay the schedule for it.
15:23:36 <puiterwijk> well, since it breaks one of our main features, we can at least request it, and then leave it up to QA/rel-eng?
15:23:37 <mvollmer> so, hmm, can we tell people to update Cockpit as part of the test day preparations?
15:23:47 <mvollmer> or is that totally pointless?
15:23:57 <puiterwijk> theoretically, we could. but that's really bad(R)
15:23:58 <stefw> mvollmer, sure we can
15:24:02 <mvollmer> puiterwijk, yes, makes sense.
15:24:03 <stefw> why is it bad?
15:24:12 <stefw> obviously we should include fixes for bugs *everyone* is going to hit
15:24:15 <stefw> in the test day images
15:24:18 <stefw> otherwise the test day is useless
15:24:21 <mvollmer> puiterwijk, yes, makes sense (letting re-leng decide).
15:24:21 <puiterwijk> stefw: because you want to test Cockpit with the rest of the system etc
15:24:23 <stefw> just noise
15:24:45 <puiterwijk> but sure, if you want to make people update, we certainly can
15:24:52 <stefw> or we just inlcude it in the image
15:24:54 <stefw> when we build it
15:25:00 <stefw> or both
15:25:07 <mvollmer> i see.
15:25:22 <mvollmer> yes, since it is 'only' alpha testing, we can be a bit loose there.
15:25:27 <puiterwijk> I think the best way would be to try to get it as freeze exception so it goes into the alpha fixes
15:25:45 <puiterwijk> and if we can't do that, then we can always ask people to update during the test day
15:26:28 <stefw> yeah
15:26:37 <puiterwijk> mvollmer: do you want me to file the bugzilla ticket, or will you file it and request freeze exception?
15:28:30 <mvollmer> puiterwijk, please file it.
15:28:35 <puiterwijk> okay
15:28:51 <puiterwijk> #action puiterwijk to file RHBZ for #1099 and request freeze exception
15:29:06 <puiterwijk> anything else F21 related?
15:29:11 <mvollmer> testsuite
15:29:21 <mvollmer> and dropping f20 support, possibly.
15:29:30 <puiterwijk> mvollmer: ah, I have that next in the agenda
15:29:34 <mvollmer> ok, cool.
15:29:42 <puiterwijk> #topic Dropping f20 for f21 (multi-os testing)
15:29:53 <mvollmer> ok, status:
15:30:18 <mvollmer> integration tests almost pass, one or two days of tinkering, then we should be good.
15:30:40 <mvollmer> biggest regression is extended DOS partitions, which seem to be broken in F21 right now.
15:30:57 <puiterwijk> #info Integration tests almost pass
15:31:02 <mvollmer> but we can disable those in our tests.
15:31:06 <puiterwijk> #info Regression with extended DOS partitions
15:31:10 <mvollmer> so, no blockers, as far as I can see.
15:31:24 <puiterwijk> okay, so we could just say we abandon F20 now and just move all development to F21?
15:31:40 <mvollmer> supporting both f20 and f21 can be done, I guess, but dropping f20 makes things easier.
15:31:59 <puiterwijk> right, but there's not that many differences that affect us, and we've never been in stable for f20
15:32:07 <mvollmer> main issue there is SELinux: for f21 we can just delete all SELinux bits from our packaging.
15:32:30 <stefw> well as things change we need to have selinux updated
15:32:38 <stefw> for example, with the gssapi work there will be a change
15:32:42 <stefw> to read the keytab
15:32:51 <stefw> but more to the point on f20 ...
15:33:02 <stefw> puiterwijk, i'm assuming we still don't have ostree based testing going on right?
15:33:16 <stefw> we *need* to be able to test against more than one base OS
15:33:43 <stefw> if it's not f20 + f21, then it should probably be atomic + f21 at this point
15:33:51 <puiterwijk> stefw: not automatically, and the VERIFY-script fixes are not complete yet, no. As published I have the script that can create the ostrees
15:34:34 <mvollmer> stefw, I agree.
15:34:39 <puiterwijk> I also haven't heard from RHIT regarding the move of ci.cockpit-project.org to the RH network, will ping again
15:34:39 <stefw> puiterwijk, yeah, i think you sent that to me a few weeks ago right?
15:34:47 <stefw> but i haven't had time to work on it, since i've been away
15:34:53 <puiterwijk> stefw: yes, that's that
15:35:17 <puiterwijk> also, I was wondering: would it be an idea to do main development on rawhide?
15:35:19 <mvollmer> I guess we can have OS specific packaging in the test suite.
15:35:26 <puiterwijk> (just thinking out loud)
15:35:37 <mvollmer> cockpit.spec.fedora-20, cockpit.spec.fedora-21, etc.
15:35:38 <stefw> in the future there's no 'main development' OS per se.
15:35:45 <stefw> certain features will work on certain OS's
15:36:01 <mvollmer> puiterwijk, makes sense to me.
15:36:05 <stefw> andreasn has been working on getting the atomic features ready for us to implement
15:36:17 <puiterwijk> mvollmer: that's a possibility, but we'd be better of with just %if-ing in the spec file as the gross will be the same
15:36:20 <stefw> but we won't be able to test or do development on (all of) them in fedora rawhide
15:36:31 <mvollmer> rawhide for Fedora, not as "main".
15:37:11 <puiterwijk> stefw: right, so I can easily modify my script to push the ostree images to files.cockpit-project.org so we can just setup an ostree VM and use that
15:37:34 <puiterwijk> and I can also make it follow master with the ostree (and with some modifications also other branches)
15:37:46 <puiterwijk> most of that code is already in my script, just needs an rsync and some tagging
15:38:34 <puiterwijk> but for development for atomic stuff, we just need documentation, as it complicates development a little bit
15:39:02 <puiterwijk> there's nothing preventing you from creating an ostree yourself with your development branch and testing that, just needs to be documented
15:40:21 <puiterwijk> do my remarks make sense, or am I just rambling?
15:40:49 <mvollmer> makes enough sense to me.
15:40:54 <stefw> well to actually do atomic specific development we also need the modular stuff done
15:41:05 <mvollmer> nothing == not enough time
15:41:07 <stefw> which ties into the navigation work, unless we figure out a good way to split it out
15:41:26 <mvollmer> i mean, there doesn't seem to be enough time to do evrything that makes sense.
15:41:38 <puiterwijk> right. I removed the navigation work from the agenda for today on andreasn's request, given it's waiting on external review
15:41:56 <andreasn> basically from julim and leslie
15:42:53 <puiterwijk> │                    | done                                        │
15:43:01 <puiterwijk> sorry for that
15:43:34 <puiterwijk> okay, so do we want to plan anything for that, or work arround the navigation stuff, or do we just wait for the review?
15:44:06 <mvollmer> stefw, so what about dropping f20 at the same time as supporting f21?
15:44:13 <stefw> yeah, lets just do it
15:44:15 <mvollmer> stefw, would that make you cringe?
15:44:32 <stefw> no, i was hoping we could use it as the use case for multi-os testing
15:44:38 <stefw> but that never materialized
15:44:41 <mvollmer> yeah, let's see.
15:44:42 <stefw> so lets not hold things up
15:45:09 <puiterwijk> okay, so we're dropping f20?
15:45:14 <mvollmer> i have to do some cross-checks with f20 anyway, so maybe I am making the problem bigger as it actually is.
15:45:41 <mvollmer> puiterwijk, I would say: probably.
15:45:59 <puiterwijk> #info F20 support maybe to be dropped when we start supporting F21
15:46:58 <puiterwijk> okay, next?
15:46:59 <mvollmer> the DOS extended partition stuff is interesting... looks like the kernel randomly forgets about them.
15:47:13 <puiterwijk> mvollmer: hum. so that's a kernel issue?
15:47:21 <mvollmer> looks like it.
15:47:32 <puiterwijk> sure it's not udisks?
15:47:37 <mvollmer> pretty sure.
15:47:41 <puiterwijk> wow
15:47:55 <mvollmer> you can reproduce it with parted and blkid.
15:48:19 <mvollmer> At one point, opening /dev/sda1 (say) return ENODEV.
15:48:36 <puiterwijk> hum. I guess that should be filed upstream.
15:49:03 <mvollmer> I have filed it for Fedora.
15:49:11 <puiterwijk> mvollmer: ah, great
15:49:12 <mvollmer> needs more investigation
15:50:07 <puiterwijk> #action mvollmer to investigate DOS partitions bug in F21
15:50:25 <puiterwijk> mvollmer: anything else for F21 so far?
15:51:09 <mvollmer> no, except that everything works much better already than I had hoped.
15:51:16 <puiterwijk> heh, that's always good
15:51:21 <puiterwijk> #info F21 works better than hoped
15:51:25 <mvollmer> puiterwijk, yeah, one thing:
15:51:32 <puiterwijk> mvollmer: yeah?
15:51:48 <mvollmer> the mirrors seem to be unreliable, and signatures, too.
15:51:55 <puiterwijk> mvollmer: you mean the Fedora mirrors?
15:52:01 <mvollmer> yes.
15:52:04 <puiterwijk> yeah, I've been working on that for the last few days.
15:52:09 <puiterwijk> that's a FEdora Infra issue
15:52:11 <mvollmer> oho! :-)
15:52:36 <puiterwijk> and it's in one of the most annoying parts of our stack, so it's a puzzle, but I'm working on that :)
15:52:38 <mvollmer> ok, just checking what I am seeing.
15:52:59 <puiterwijk> yup, thanks again for reporting. if you see it happen again, please let me know
15:53:27 <puiterwijk> #info Fedora Infra has issues with mirror metalink, so sometimes updates might give lots of errors. Working on fixing that
15:53:57 <puiterwijk> (just for your interresent: the issue is that the metalink that we generate is outdated on sone mirror servers.. :-/ )
15:53:58 <mvollmer> ok, so I continue with the testsuite on F21, ok?
15:54:06 <puiterwijk> yup
15:54:18 <puiterwijk> #topic systemd + polkit
15:54:21 <puiterwijk> stefw: ^
15:54:26 <mvollmer> ahh, yes.
15:54:37 <stefw> so systemd merged patches that enable polkit support for the systemd1.Manager interfaces and friends.
15:54:45 <mvollmer> \o/
15:54:47 <stefw> however, lennart did this with interactive = no prompts
15:54:59 <mvollmer> /o\
15:55:07 <stefw> so it doesn't work with any of the default polkit that they (now) distribute
15:55:24 <stefw> there's a discussion on dbus mailing list about adding a flag to dbus to indicate whether a method should be interactively authenticated or not.
15:55:37 <stefw> if that's approved, spec updated, libdbus and glib would need to be updated
15:55:43 <stefw> as well as services like systemd
15:55:52 <stefw> so it's a pretty big deal
15:55:55 <stefw> in theory backportable
15:56:11 <mvollmer> it's not cockpit specific, right?
15:56:15 <stefw> no
15:56:29 <mvollmer> it's so that systemd can properly use polkit?
15:56:32 <stefw> but we may end up having to write our own brain-dead stupid daemon that listens on same interfaces, just does polkit verify, and passes the call along to systemd
15:56:37 <stefw> systemd can use polkit
15:56:40 <stefw> and for things like hostnamed
15:56:47 <stefw> they have a allow_interaction boolean argument in each method
15:56:53 <stefw> which is then passed along to polkit
15:57:08 <stefw> but for the Manager interface (the main one managing units etc...) there's no such arguments
15:57:19 <stefw> and instead of defaulting to allow_interaction = yes, it defaults to no
15:57:32 <stefw> see http://www.freedesktop.org/wiki/Software/systemd/hostnamed/
15:57:36 <mvollmer> i see.
15:57:47 <stefw> vs these methods:
15:57:47 <stefw> http://www.freedesktop.org/wiki/Software/systemd/dbus/
15:57:52 <puiterwijk> hum... is that default an error? as that sounds pretty strange and breaking to me?
15:58:21 <stefw> not really, some callers of dbus methods don't want to have to block on a prompt
15:58:25 <mvollmer> i would expect that there is no such flag, and whether interaction is allowed or not is handled by the polkit-agent.
15:58:52 <stefw> yeah, except the agent and caller don't know much about each other
15:58:54 <mvollmer> stefw, right
15:58:56 <stefw> in our case they're more closely related
15:59:07 <stefw> dbus interactive authentication flag discussion: http://lists.freedesktop.org/archives/dbus/2014-August/016294.html
15:59:26 <stefw> related: http://lists.freedesktop.org/archives/systemd-devel/2014-September/022804.html
15:59:59 <stefw> i guess in addition to making this happen upstream
16:00:21 <stefw> we should file some bugs in the red hat bugzilla, so we can track backporting patches, implementing work arounds, and making those sorts of decisions
16:00:33 <stefw> likely systemd, libdbus, glib would be affected
16:01:18 <puiterwijk> #info major changes happening to systemd/polkit, need to backport patches for systemd, libdbus, glib
16:01:58 <stefw> maybe
16:02:04 <puiterwijk> #undo
16:02:04 <zodbot> Removing item from minutes: INFO by puiterwijk at 16:01:18 : major changes happening to systemd/polkit, need to backport patches for systemd, libdbus, glib
16:02:11 <puiterwijk> #info major changes happening to systemd/polkit, maybe need to backport patches for systemd, libdbus, glib
16:02:45 <stefw> so the alternative (and probably method of last resolt for us) is to proxy all systemd calls through a service running as root
16:02:51 <stefw> that does polkit verification with allow_interactoin = true
16:02:57 <stefw> it wouldn't need to be *that* tedious
16:03:09 <mvollmer> can it be generated from some XML file?
16:03:10 <stefw> could just have a mapping of which methods belong to which polkit actions
16:03:13 <puiterwijk> stefw: right. though currently we only support root anyway, right? so this is for if we want to support wheel-users as well?
16:03:27 <stefw> we only support root, because this stuff is broken
16:03:37 <stefw> also, anyone can log in
16:03:40 <stefw> they just find stuff broken
16:03:44 <puiterwijk> right.
16:03:45 <stefw> so this is stuff we need to fix
16:04:03 <stefw> the current 'only-root' situation is only for f21 because we haven't fixed all these issues yet
16:04:17 <puiterwijk> yeah, I know. so this was just a summary
16:04:19 <stefw> also, i wonder if we should have a warning when you log in as non-root, in the interim
16:05:08 <andreasn> like at the login page?
16:05:39 <andreasn> or on the initial dashboard?
16:05:42 <stefw> not sure
16:05:50 <stefw> or on the top bar?
16:06:29 <puiterwijk> well, we probably want to make sure it gets seen?
16:06:46 <andreasn> it would be easiest as a little box on the dashboard that you can dismiss
16:06:56 <andreasn> like we have for docker right now
16:07:04 <stefw> sure
16:07:45 <andreasn> I'll open an issue about it
16:07:47 <puiterwijk> #info Look into adding a warning message on dashboard if logged in as non-root
16:08:03 <puiterwijk> #action andreasn to open issue on warning for non-root
16:08:09 <yinzhang> Is everything broken when login with non-root? I think is part of the features
16:08:48 <stefw> just certain features and actions
16:09:10 <andreasn> https://github.com/cockpit-project/cockpit/issues/1101 <- done
16:09:23 <yinzhang> yeah, which we need to capture carefully
16:09:45 <puiterwijk> stefw: maybe it'd be useful to have a short list of broken things on that ticket?
16:10:10 <stefw> yup
16:10:13 <yinzhang> I think it's a good idea
16:10:35 <puiterwijk> can you do that, stefw?
16:11:00 <stefw> so go through all of cockpit as non-root and look at what breaks?
16:11:12 <stefw> also, what about non-wheel users?
16:11:24 <puiterwijk> I think that's a different category of issues
16:11:41 <puiterwijk> and non-wheel is, I think, not a core feature, as we're a management system..
16:12:26 <puiterwijk> although if someone disagrees, we could decide otherwise
16:12:45 <stefw> wheel essentially ends up being root equivalent
16:12:54 <stefw> so ... i think we'll need to eventually support non-wheel
16:13:06 <stefw> the roles stuff was an interesting first step in that direction
16:13:13 <puiterwijk> yeah, but for that we need to have a way to check which permissions the current user does have
16:13:16 <stefw> althuogh probably would be reimplemented using polkit as we discussed earlier
16:13:49 <stefw> i gotta go soon ... i guess irc meetings take much longer ...
16:14:09 <puiterwijk> stefw: well, our other meetings used to take about 2 hours, remember? :)
16:14:14 <stefw> really?
16:14:17 <puiterwijk> yes
16:14:25 <puiterwijk> I left the office arround 7PM quite often
16:14:41 <stefw> interesting. well i i'll try and stay
16:14:46 <puiterwijk> anyway, we only have one other big point on the agenda
16:15:15 <puiterwijk> #action stefw to put a list of stuff that doesnt work as non-root in ticket #1101
16:15:23 <puiterwijk> #topic Atomic features
16:15:30 <andreasn> all right, I guess that's me
16:15:36 <puiterwijk> yup
16:15:56 <puiterwijk> andreasn: could you put the links in here prepended with #link?
16:15:57 <andreasn> so, I've filled the pages stefw started
16:16:12 <andreasn> Atomic Updates from Cockpit
16:16:16 <andreasn> #link https://github.com/cockpit-project/cockpit/wiki/Atomic:-OSTree-Update
16:16:24 <andreasn> like that?
16:16:27 <puiterwijk> yup
16:16:49 <andreasn> so, today, the only way to update your atomic host is from the cli
16:17:00 <andreasn> we should have something in Cockpit for that
16:17:30 <andreasn> there are 2 personas/user stories connected to that and two workflows
16:17:44 <andreasn> if there is any persona or workflow missing, please let me know
16:18:19 <andreasn> the second one is Atomic: Docker Storage
16:18:24 <andreasn> #link https://github.com/cockpit-project/cockpit/wiki/Atomic:-Docker-Storage
16:18:28 <puiterwijk> #topic Two user stories for update stuff, let andreasn know if it's missing anything
16:18:32 <puiterwijk> #undo
16:18:32 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0xe07a310>
16:18:41 <puiterwijk> #info Two user stories for update stuff, let andreasn know if it's missing anything
16:19:01 <andreasn> right now you have 8.5 GB for your docker files in Atomic and, yeah, that's pretty much it
16:19:30 <andreasn> if you run out of that space, then, well
16:20:01 <andreasn> that feature page has 3 user stories/personas and 3 scenarios
16:20:21 <andreasn> same with that if anything is missing from that that we need to cover
16:20:36 <puiterwijk> #info Three user stories for docker storage management
16:20:49 <andreasn> the thind one is Atomic: Resource Controls
16:20:53 <puiterwijk> #link https://github.com/cockpit-project/cockpit/wiki/Atomic:-Resource-Controls
16:23:45 <puiterwijk> that's for management of CPU, memory and disk space resources, right?
16:23:53 <andreasn> sorry, client died
16:24:06 <puiterwijk> and I'm seeing two user stories?
16:24:16 <andreasn> yes, we have some management of cpu and memory today, but none for network and storage
16:24:26 <andreasn> so it's kind of interconnected with the storage one I guess
16:24:48 <puiterwijk> #info Two user stories for docker resource management, but missing stories for network and storage resources
16:24:49 <andreasn> yep
16:25:25 <andreasn> so once these are reviewed for sanity and completeness the next step would be design
16:25:35 <andreasn> so please review! :)
16:25:47 <puiterwijk> #info please review the user stories and provide feedback to Andreas
16:25:59 <puiterwijk> #topic vm-create on files.cockpit-project.org
16:26:14 <andreasn> I've also gotten in touch with julim, leslie and walters about it
16:26:18 <puiterwijk> #undo
16:26:18 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0xdafb490>
16:26:43 <puiterwijk> andreasn: right. Good feedback from them so far?
16:27:01 <andreasn> sent it just today, so no feedback from anyone yet
16:27:07 <puiterwijk> ah, right
16:27:15 <andreasn> neither from anyone on cockpit-devel
16:27:40 <puiterwijk> #info Please post review comments on the user stories to the cockpit-devel mailing list
16:28:27 <andreasn> and that was pretty much it from me
16:28:32 <puiterwijk> okay :)
16:28:38 <puiterwijk> #topic vm-create on files.cockpit-project.org
16:28:42 <puiterwijk> mvollmer:
16:28:49 <mvollmer> yep.
16:29:00 <andreasn> lookinf forward to the docker fix so I can run more containers on my server :)
16:29:01 <puiterwijk> so you want to run that as a cron?
16:29:06 <mvollmer> so, it would be nice to create the test machine images on that server.
16:29:19 <mvollmer> puiterwijk, I want to run it at all.
16:29:31 <puiterwijk> mvollmer: fine with me. just make sure you're not running it every minute :)
16:29:43 <mvollmer> looks like qemu doesnt't understand the "-net bridge" options.
16:30:07 <mvollmer> puiterwijk, do you have experience there?  do you run the tests on RHEL6?
16:30:38 <mvollmer> i spent about 10 seconds with this, so I might be totally wrong about everything.
16:30:45 <puiterwijk> mvollmer: I have bridging net working on RHEL6, so I can check how I have that done. I think it needs some manual fiddling
16:31:02 <mvollmer> puiterwijk, that would be cool.
16:31:09 <puiterwijk> #action puiterwijk to check into bridging net for RHEL6 to run vm-create on files.cockpit-project.org
16:31:15 <mvollmer> thanks
16:31:24 <puiterwijk> mvollmer: so after that works, how about we just set it as a cron for every day at midnight?
16:31:46 <mvollmer> yes, that makes sense.
16:31:58 <mvollmer> of course we should also publish any failures, etc.
16:32:12 <puiterwijk> right, we can just make it pipe the output to a daily log file
16:32:42 <mvollmer> ok, gotta run soon, still in the office...
16:32:49 <puiterwijk> okay. we have just one last thing
16:32:52 <puiterwijk> #topic Open floor
16:33:01 * mvollmer starts dancing
16:33:03 <puiterwijk> andreasn, mvollmer, stefw: any last remarks?
16:33:15 <andreasn> nothing from me
16:33:32 <mvollmer> test cases for test day worry me a bit.
16:33:53 <mvollmer> i am not sure how the end result should look like.
16:34:01 <mvollmer> I'll check other test day pages.
16:34:06 <puiterwijk> mvollmer: right. so how about we just have someone write something up in the wiki and then review it next week?
16:34:26 <puiterwijk> we still have a little over two weeks, if I recall correctly
16:34:44 <puiterwijk> #action mvollmer to check other test days and write some test cases
16:34:55 <mvollmer> jawohl! :-)
16:35:01 <puiterwijk> :-)
16:35:06 <puiterwijk> anything else?
16:35:21 <puiterwijk> I'm going to end the meeting in 30 seconds if nothing else
16:35:22 <mvollmer> i have that other action item anyway: mvollmer to update the test day page to include warning
16:35:22 <mvollmer> about error checking in dialogs
16:35:28 <puiterwijk> ah, right
16:35:42 <puiterwijk> but that's linked with the test case stuff, right?
16:35:58 <puiterwijk> #info Make sure to put "last weeks action points" on next weeks agenda
16:36:10 <mvollmer> woohoo, VERIFICATION PASSED on Fedora 21.
16:36:17 <puiterwijk> mvollmer++
16:36:26 <mvollmer> images are on files.cockpit-project.org.
16:36:40 <puiterwijk> awesome :)
16:36:43 <mvollmer> credits go to fedora.
16:36:58 <puiterwijk> heh
16:37:00 <mvollmer> ok, see you tomorrow!
16:37:02 <puiterwijk> oh, and I had one last question
16:37:06 <mvollmer> sure
16:37:16 <puiterwijk> so we have multi-os testing on the schedule now right?
16:37:25 <puiterwijk> when do we start supporting Windows?
16:37:26 * puiterwijk ducks
16:37:31 <mvollmer> heh.
16:37:46 <puiterwijk> okay, on that note, before people start killing me, thanks to everyone for coming!
16:37:53 <andreasn> thanks!
16:38:07 <mvollmer> thanks, bye!
16:38:09 <puiterwijk> #endmeeting