13:01:20 #startmeeting 13:01:20 Meeting started Mon May 18 13:01:20 2015 UTC. The chair is mvollmer. Information about MeetBot at http://wiki.debian.org/MeetBot. 13:01:20 Useful Commands: #action #agreed #halp #info #idea #link #topic. 13:01:31 .hello mvo 13:01:32 mvollmer: mvo 'Marius Vollmer' 13:01:46 #topic Welcome 13:01:48 Welcome! 13:02:00 let's have the weekly cockpit irc meeting 13:02:03 .hello andreasn 13:02:06 andreasn_: andreasn 'Andreas Nilsson' 13:02:22 petervo, around? 13:02:45 phatina, maybe you are interested. 13:03:01 #topic Agenda 13:03:11 * Storage update / packaging 13:03:31 * CI status 13:03:47 * ostree updates 13:04:12 i'm here 13:04:43 jscotka, meeting? 13:04:55 mvollmer, yep, I'm ready 13:05:03 anything for the agenda? 13:05:26 .hello phatina 13:05:27 phatina: phatina 'Peter Hatina' 13:05:49 mvollmer, probably not, need to talk with Dominit :-) 13:05:54 ok! 13:06:03 #topic Status update / packaging 13:06:19 ok, so now I should be close to feature complete... :-) 13:06:31 I added some graphs 13:06:41 but tey don't show individual disks anymore 13:07:07 i hope we can figure that out more generally, with "The Grid" and D3, etc. 13:07:34 there are bugs, maybe only with jquery amend. 13:07:45 so its time to think about packaging 13:08:04 i guess we could have a cockpit-storaged package, and a cockpit-udisks2 package 13:08:36 I am not sure how to split the old code out of the shell, maybe it can stay there. 13:08:39 [cockpit] stefwalter reopened pull request #2291: bridge: Add "owned" message to dbus-json3 (master...name-changed) http://git.io/vUhYj 13:09:12 next up are getting the tests to run again. 13:09:25 sounds good 13:09:33 any opinions about the packaging? 13:09:50 i guess we need to support the old udisks2 code for some while still. 13:10:59 ok, next topic? 13:11:13 #topic CI status 13:11:17 it rains again... 13:11:33 i tried to fix the frequent failures 13:11:45 https://github.com/cockpit-project/cockpit/pull/2301 13:11:53 https://github.com/cockpit-project/cockpit/pull/2300 13:12:07 no definite results yet... 13:12:32 but it's not as bad as it looks. 13:12:47 stefw is fixing the Travis "stream" failure 13:13:08 and the kube failure, forgot about that 13:13:42 so, no green right now, but that is because of a few known failures. 13:14:13 next? :-) 13:14:42 sure 13:15:17 #topic ostree updates 13:15:26 petervo has a branch 13:15:38 i put a tree up on cockpit-files 13:15:46 and since I'm terrible with these things, I'm still struggling to get things working :) 13:16:48 should be mostly working needs review and testing, the daemon still needs some work as well 13:17:24 i'll help andreasn get it working 13:17:33 really close now 13:17:53 mvollmer: I have a topic for later in the meeting related to *non*-ostree updates (for Fedora Server) 13:18:12 sgallagh, noted, thanks. 13:18:26 petervo, where is the daemon? 13:18:56 * mvollmer reads good things about ember in the interwebs 13:20:37 ok, next? 13:20:42 sure 13:20:54 I guess that's sgallagh's item then 13:21:02 #topic *non*-ostree updates 13:21:09 Hello 13:21:11 as in rpm-updates? 13:21:27 Yes 13:21:51 In a recent Fedora Server meeting, we addressed the possibility of having Cockpit be capable of managing standard RPM updates (using PackageKit) 13:22:31 There are (as always) multiple opinions on how this should be done. 13:23:18 such as offline updates or not? 13:23:24 Option 1) Cockpit behaves like DNF, just updates the packages live (possibly offering an option to reboot afterwards) 13:23:35 Option 2) Offline updates just like Fedora Workstation 13:23:51 does option 1 include restarting the affected services and stuff? 13:23:56 Option 3) "Warm" updates where the system descends into the update-only mode and then resumes to default.target 13:24:26 andreasn_: Doing that successfully is a complicated problem. 13:24:41 I assumed so 13:24:49 For example, it's extremely difficult to know which services to restart if you update a single libraryt. 13:25:07 (With glibc, rebooting is really the only sane option) 13:25:19 Or rather, restarting everything. 13:25:39 Option 2) is the most resilient, while resulting in the most downtime/disruption to the user. 13:26:07 It guarantees a known state of the system, at the expense of two reboots. 13:26:36 This can be extremely costly on a lot of server hardware which may have multiple-minute EFI memory checks. 13:27:02 right 13:27:34 Actually, I should add Option 4): Option 3, but with a reboot after updating instead of a resume to default.target 13:28:08 If we implemented Option 3, we should have Option 4 around in any case, for glibc/kernel updates. 13:28:22 I thought we had an issue open about rpm updates, but I can't seem to find it 13:28:46 there were issues with packaging 13:29:03 and dependcies 13:29:08 Anyway, the approach is still up for discussion, but I wanted to open the conversation with Cockpit upstream 13:29:13 but those should be resolved now i think 13:29:19 petervo: Sorry, can you be more descriptive? 13:30:06 Packagekit was pulling in x11 and a bunch of graphics libraries as dependencies 13:31:26 i haven't had a chance to look at the latest but i think those were removed 13:31:47 petervo: I'm not sure if they have been or not, but Server is carrying PackageKit at this point anyway 13:32:08 is that new with f22? 13:32:09 /me notes he's also working on a project to detect large dependency sets so we can narrow those down. 13:33:21 cockpit right now isn't very good with anticipated reboots. 13:33:23 petervo: I'm not sure; I *thought* it was also in F21, but I might be mistaken 13:33:34 so that would be one thing to fix as part of this, I guess 13:33:45 I should note that it's not explicitly part of the compose; something we do include pulls it in, apparently 13:33:45 it wasn't back in jan when i was testing, but i was using cloud images 13:34:04 petervo: Cloud images are a different compose set than Fedora Server 13:34:21 that might be it 13:34:57 Actually, I take that back. PackageKit *is* explicitly included as part of the "headless-management" group in comps 13:34:59 mvollmer, we are going to work on that as part of the ostree work 13:35:02 It's there for openlmi 13:35:09 since that requires reboot 13:35:12 And yeah, it would have been there in F21 also 13:35:16 petervo, ahh, yes, that makes a lot of sense. 13:38:37 OK, anyway I mostly brought this up to have you guys think about it (and ideally work up some mock-ups on how the user-experience should be) 13:38:45 I'll keep it in mind 13:38:49 Thank you 13:38:52 looks like we are not scared of updates via PackageKit 13:38:58 I'm *hoping* for this to be an F23 target. 13:39:05 mvollmer: Hmm? 13:39:13 and I'm not sure what the best answer is in the end with regards to reboots and all. It's a bit of pick-your-poison 13:39:15 :) 13:39:18 (as always) 13:39:38 sgallagh, i didn't want to say "we are ready", but I don#t see any blockers. 13:40:49 andreasn_: Yeah, there are no good answers. The actual mechanism under the hood should hopefully be invisible to Cockpit 13:40:54 right 13:41:16 Except insofar as we should provide feedback to Cockpit whether a reboot will be necessary, so it can inform the user 13:41:36 *invisible to the Cockpit UI (not to the Cockpit implementation, necessarily) 13:42:02 if we end up with offline updates, I think it can be fairly similar to the ostree updates we're working on right now 13:42:59 Except for Option 1, all of the approaches I listed above would be *effectively* offline updates from Cockpit's point of view 13:43:07 Since Cockpit wouldn't be reachable during that time. 13:43:56 I have no idea if we would have time to get it to work for F23 13:44:06 but it would be good to have at some point 13:44:25 It's a pretty significant missing piece from Fedora Server's perspective. 13:44:35 yeah 13:45:32 That's all I had for todahy 13:45:45 ok! 13:45:54 anything else? 13:46:17 nothing from me 13:46:25 ok. 13:46:32 quick meeting, nice. 13:46:36 #endmeeting