13:01:45 #startmeeting 13:01:45 Meeting started Mon Mar 30 13:01:45 2015 UTC. The chair is andreasn. Information about MeetBot at http://wiki.debian.org/MeetBot. 13:01:45 Useful Commands: #action #agreed #halp #info #idea #link #topic. 13:02:02 .hello andreasn 13:02:04 andreasn: andreasn 'Andreas Nilsson' 13:02:29 .hello dperpeet 13:02:30 dperpeet: dperpeet 'Dominik Perpeet' 13:02:43 .hello sgallagh 13:02:44 sgallagh: sgallagh 'Stephen Gallagher' 13:03:17 petervo, stefw, you here too? 13:03:22 .hello stefw 13:03:24 stefw: stefw 'Stef Walter' 13:03:35 #topic Agenda 13:03:44 what do we have today? 13:03:47 * Fedora 22 13:04:06 yep 13:04:30 * GSoC 13:04:56 * Patternfly 13:04:57 * User syncing without accountsservice 13:05:10 * storage daemon 13:06:07 [cockpit] dperpeet opened pull request #2059: Test: add support for RHEL guest (master...rhel_ci) http://git.io/jKFW 13:06:18 all right 13:06:26 #topic Fedora 22 13:06:59 If we still want to be able to add Fedora 22 servers to future dashboards ... (ie: backwards compatibility) then we are not ready yet 13:07:02 I noticed that the branding suddenly appeared in a recent update, so thanks for that 13:07:22 We need to migrate away from the cockpitd Accounts code in order to have that backwards compatibility 13:07:43 WIP branch: https://github.com/cockpit-project/cockpit/pull/2057 13:07:58 (in theory the setup code could fall back to using cockpitd when it detects it.) 13:08:13 true, except for even now that code errors out 13:08:59 so i'd like to see if we can do our Fedora 22 release later tonight? 13:09:07 and try and include the code that migrates away from cockpitd Accounts 13:09:37 stefw: That's going to be a bit tight for getting it into stable, but we can manage it as long as we get the necessary karma 13:09:54 (Otherwise we have to aim for a blocker or freeze exception bug) 13:10:13 between petervo, sgallagh, and me, we can find 2 karma 13:10:26 which is usually what we require 13:11:11 /me nods 13:11:38 anything else on Fedora 22? 13:11:44 don't think so 13:11:52 #topic GSoC 13:13:01 So, we have three candidates for Cockpit in GSoC 13:13:03 I haven't heard from any candidates personally 13:13:23 One of them may not actually be eligible to participate, we're sorting that out. 13:13:29 do you have a URL to the tasks? 13:14:00 https://fedoraproject.org/wiki/Summer_coding_ideas_for_2015#Cockpit_UI_for_Rolekit 13:14:03 thanks 13:14:10 #info https://fedoraproject.org/wiki/Summer_coding_ideas_for_2015#Cockpit_UI_for_Rolekit 13:14:31 #info Tasks are "Cockpit UI for Rolekit", "Docker Volume Support" and "Cockpit support for systemd timers" 13:15:03 primary topic was rolekit, we added the others last minute 13:15:15 so three candidates as people who reached out and said they are interested in these tasks, or 3 candidates as in 3 tasks? 13:16:06 they all signed up for rolekit, but after we posted the other two as alternatives, two of the candidates also posted their interested in the two new topics 13:16:17 andreasn: Three candidates (all with well thought-out proposals) applied for the rolekit one 13:16:27 ah, I see 13:16:52 We added others because it looked like we might end up with more good candidates than tasks :) 13:17:11 the other two tasks looks excellent as well 13:17:39 Unfortunately, as I mentioned above, one of the applicants may be ineligible (I'm not going to name the student publicly) due to a possible conflicting relationship with the mentoring organization. 13:17:47 right 13:18:54 Anyway, the main point here is that dperpeet and I need to get in touch with the applicants and decide how to proceed. 13:19:03 #action sgallagh and dperpeet to review GSoC applications 13:19:21 sgallagh, I sent you an e-mail with preliminary thoughts on this, but we can discuss further 13:19:41 Yeah, I saw the email but haven't gotten that far through my weekend backlog :) 13:19:58 We can take that outside of the meeting. 13:21:02 ok 13:21:15 all right, anything else on that topic? 13:21:22 Not for now. More as it develops :) 13:21:35 excellent, thanks for driving this! 13:21:44 Happy to :) 13:21:45 #topic Patternfly migration 13:22:24 pull request is here https://github.com/cockpit-project/cockpit/pull/2058 13:22:37 will need to test a bit more and see I didn't forget any old spinners in there 13:23:02 nothing more to report 13:23:36 andreasn, thanks for that - looking forward to seeing the current style used consistently 13:23:58 yeah, would be great to leave the old version behind us 13:24:07 ok, next topic I guess 13:24:10 #topic User syncing without accountsservice 13:24:49 i've been working on this today 13:24:54 i went down the wrong road at first 13:25:19 because of the (somewhat unfortunate) way we handle running the remote cockpit-bridge during the 'add to dashboard' setup process 13:25:33 i wasn't able to implement the logic for syncing users in javascript 13:25:52 this is because the javascript code requires multiple channels, and we can only open one channel to the remote cockpit-bridge during setup 13:26:09 so this means essentially either spawning a remote process, or using a remote dbus API 13:26:24 i've opted for the latter, which is to implement an internal DBus API in cockpit-bridge, by which the users are synced 13:26:37 it's a cockpit.Setup() API, that has various phases, and is extensible for domain support later 13:26:48 this is the pull request: https://github.com/cockpit-project/cockpit/pull/2057 13:26:52 i'm writing detailed tests right now 13:27:11 that's it 13:27:44 cool 13:28:04 what's the reason for having only one channel? 13:28:12 the different credentials? 13:28:16 and host keys, yes 13:28:20 right 13:28:28 we sorta cringed when we were implementing that in cockpitwebservice, i remember 13:28:35 yes 13:28:36 but it's too late to change it now :S 13:29:06 there is one thing we could do to make it "less magical" 13:29:13 and that is to make opening a private channel explicit 13:29:20 rather than implicit 13:29:40 right now it's implicitly private if there is a 'user' option and/or a 'host-key' option 13:29:42 (maybe others?) 13:30:03 why can't the js open multiple private channels? 13:30:12 N ssh connections? 13:30:15 if it can open one, it can open many, no? 13:30:21 sure, but it would be pretty nasty 13:30:25 i see 13:30:30 true 13:30:31 lets say you want to read /etc/passwd /etc/group and /etc/shadow 13:30:34 that's 3 channels 13:30:38 then you want to check if users exist 13:30:40 then you want to run useradd 13:30:43 then you want to change passwords 13:31:00 and you've just created N + 5 channels 13:31:02 right, so we are taken dozens of channels. 13:31:03 where N is the number of users 13:31:04 right 13:31:08 so anyway 13:31:16 lets just stick with what we have 13:31:23 yep 13:31:24 and live within that 13:33:27 all right, next topic? 13:33:30 yup 13:33:37 #topic storage daemon 13:33:45 so PR is in 13:33:55 i was wondering about the name 13:34:13 github is still having issues 13:34:16 can we keep cockpit-storaged for the storaged we will likely have to self-host for RHEL? 13:34:23 what were you thinking? 13:34:26 and maybe use cockpit-udisks as the client-side binary name? 13:34:36 ok 13:34:43 or something like that? 13:34:52 https://github.com/cockpit-project/cockpit/pull/2050 13:34:55 otherwise the name 'storaged' is used in both things 13:35:39 i was thinking cockpitd-storage 13:36:11 it's sorta like cockpit-pcp 13:36:11 petervo, pr looks good to me. 13:36:19 petervo, what are the next steps? 13:36:19 but it's for udisks 13:36:35 import storaged? 13:36:41 and rename it a bit? 13:37:30 i wasn't sure if wanted to move storaged inside on fedora as well 13:37:47 right 13:37:49 it would allow the new storaged to start replacing us on rawhide 13:37:54 even if we don't yet have time to migrate to the new storaged 13:37:58 or if that was something we were going to do just as part of the build process for OSest that need it 13:38:26 i agree with stefw, it would be nice to make space for the new one. 13:38:32 in fedora. 13:38:46 ok 13:39:10 so cockpit-storaged and cockpit-udisks 13:39:24 everyone good with those 2? 13:39:30 ++ 13:39:41 or cockpit-storaged and cockpit-storage 13:39:47 if people have problems with 'udisks' 13:39:54 but i really think this is udisks specific implementation 13:40:11 yes 13:40:11 even the fact that the old storaged exists 13:41:54 i think that's it for that topic 13:42:06 all right 13:42:10 #topic Open Floor 13:42:52 pr for RHEL support is in https://github.com/cockpit-project/cockpit/pull/2059 13:42:53 can anyone else think of anything else for Fedora 22 13:42:54 finally 13:43:25 I e-mailed Ryan Lerch twice and asked if he had any feedback on the current branding 13:43:34 but I never got a reply back, so I guess it's ok 13:43:46 cool 13:43:49 andreasn: How recently? 13:44:16 /me notes that Ryan has been on his way to Australia for about half a week and will be out of contact until next week. 13:44:18 on the 24th 13:44:38 He left on the 25th I think, so he may not actually have had a chance to examine it. 13:44:50 Might be worth pinging mizmo or edirsh 13:45:00 all right 13:46:53 anything else for the open floor? 13:48:47 sounds not 13:48:51 #endmeeting