13:00:24 <sgallagh> #startmeeting rolekit (2015-08-25) 13:00:24 <zodbot> Meeting started Tue Sep 1 13:00:24 2015 UTC. The chair is sgallagh. Information about MeetBot at http://wiki.debian.org/MeetBot. 13:00:24 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 13:00:25 <sgallagh> #meetingname rolekitweekly 13:00:25 <sgallagh> #chair sgallagh twoerner nilsph 13:00:25 <sgallagh> #topic init process 13:00:25 <zodbot> The meeting name has been set to 'rolekitweekly' 13:00:25 <zodbot> Current chairs: nilsph sgallagh twoerner 13:00:35 <nilsph> hi 13:00:42 <sgallagh> .hello sgallagh 13:00:43 <zodbot> sgallagh: sgallagh 'Stephen Gallagher' <sgallagh@redhat.com> 13:02:00 <nilsph> .hello nphilipp 13:02:03 <zodbot> nilsph: nphilipp 'Nils Philippsen' <nphilipp@redhat.com> 13:02:11 <sgallagh> twoerner: You around? 13:02:18 <twoerner> sgallagh: yes 13:02:19 <nilsph> ...and that is not my preferred mail address 13:02:30 <sgallagh> nilsph: That's what you have set in FAS 13:02:32 <twoerner> I am just having a look at rb179 13:02:34 <sgallagh> If that's not preferred, change it 13:02:45 <sgallagh> ok 13:02:49 <nilsph> sgallagh: and I can't do it differently because weird interactions with RH internal tools 13:02:53 <twoerner> hi 13:03:05 <twoerner> .hello twoerner 13:03:06 <zodbot> twoerner: twoerner 'Thomas Woerner' <twoerner@redhat.com> 13:03:51 <sgallagh> #topic Fedora 23 Beta Freeze Preparation 13:05:05 <sgallagh> I'm planning to do a 0.4.0 RC1 today or tomorrow 13:05:23 <sgallagh> (With 0.4.0 Final being released in time for F23 Final Freeze) 13:05:27 <twoerner> ok 13:05:45 <twoerner> what do you think about rb199 and rb200? 13:05:55 <sgallagh> #info 0.4.0 RC1 to be released by tomorrow 13:06:14 <sgallagh> I'd like to include them. I'm going to review them immediately after the meeting. 13:06:18 <nilsph> and it'll likely be missing a fix for the "clean up systemd units" issue, thanks to me underestimating the effort to do so 13:06:19 <twoerner> I will be in Brno next week and therefore I will most likely not have a lot of time 13:06:34 <sgallagh> Could you make sure that 199 applies atop 179 or rebase it if not? 13:06:49 <twoerner> yes, will do 13:06:55 <twoerner> the rebase 13:07:09 <sgallagh> nilsph: Which issue was that? 13:07:37 <nilsph> sgallagh: issue 16 13:08:02 <nilsph> I got roled to traceback in all weird places 13:08:03 <sgallagh> Ah right 13:08:27 <nilsph> I need to make some stuff on the decommission side more symmetrical to the deployment side 13:08:35 <sgallagh> OK, we had that targeted at F23 Final, which I think is fine 13:08:40 <nilsph> okie 13:08:51 <nilsph> phew 13:08:53 <nilsph> :) 13:08:54 <sgallagh> Hmm, is it going to involve an architecture change? 13:08:59 <nilsph> I hope not 13:09:10 <sgallagh> "I need to make some stuff on the decommission side more symmetrical to the deployment side" <-- sounds scary 13:09:11 <nilsph> but what I'd like to call "cleanups" 13:09:15 <nilsph> :) 13:09:41 <nilsph> I just need some information when decommissioning which is not yet available, or not where I looked for it :o) 13:09:51 <sgallagh> ok 13:10:15 <sgallagh> #info https://github.com/libre-server/rolekit/issues/16 requires a little more work, will be ready for 0.4.0 final release 13:10:54 <sgallagh> OK, so I think we're in pretty good shape. Let's go through the newly-filed tickets (I think there's only one). 13:11:05 <sgallagh> #info 0.4.0 is in good shape for Fedora schedule. 13:11:41 <sgallagh> #topic https://github.com/libre-server/rolekit/issues/38 - rolectl bash-completion shouldn't suggest --settings-file if --settings-stdin was passed (and vice-versa) 13:12:10 <sgallagh> twoerner has a patch ready for this awaiting review, so I'm good with calling this an F23 beta nice-to-have. Agree? 13:12:15 <twoerner> sgallagh: this is covered by http://reviewboard-fedoraserver.rhcloud.com/r/199/ 13:12:25 <twoerner> +1 13:12:43 <nilsph> +1 13:13:03 <sgallagh> #agreed Fedora 23 Beta, nice-to-have. Already under review 13:14:00 <sgallagh> That was the only ticket currently open 13:14:17 <twoerner> yes.. the one and only new one 13:14:35 <nilsph> twoerner: OOB, the patch looks good to me, just let me give it a round in testing 13:14:37 <sgallagh> twoerner: Would you mind opening a bug about canceling the pending roles? 13:15:02 <twoerner> ohh yes.. I will open the issue 13:15:05 <sgallagh> That way we can discuss whether we want it for F23 Final or deferred. 13:18:20 <sgallagh> #topic Pendingrole Cancellation (Issue # pending) 13:18:47 <sgallagh> I'm on the fence as to whether to try getting this into F23 or just holding it to F24 alpha 13:19:06 <sgallagh> Since it will require a new verb in the rolectl command. 13:19:32 <sgallagh> O 13:19:44 <sgallagh> I think it's more useful for developers than end-users 13:20:21 <sgallagh> Since I think it would be unlikely to cancel many of these in the real world. 13:20:33 <sgallagh> (Their primary purpose is for use in a kickstart file) 13:22:13 <sgallagh> #link https://github.com/libre-server/rolekit/issues/39 13:22:13 <twoerner> here is the issue: https://github.com/libre-server/rolekit/issues/39 13:22:50 <twoerner> sgallagh: we had the new verb in rolectl also for sanitize 13:23:06 <sgallagh> twoerner: Right, but I'm not sure I'm comfortable adding new verbs post-Beta 13:23:17 <twoerner> we are still before beta :-) 13:23:33 <twoerner> this week 13:23:43 <twoerner> but it might be too short 13:24:03 <twoerner> s/short/close/ 13:24:04 <sgallagh> OK, shall we call this F23 Beta nice-to-have with a plan to bump it to F24 Alpha if I don't manage to find the time and/or the review process takes too long? 13:24:16 <twoerner> +1 13:24:16 <nilsph> sounds good 13:24:17 <nilsph> +1 13:24:54 <alxgrtnstrngl> hey, just arrived, what is the timeline for rolekit's release? 13:24:56 <sgallagh> I suppose it probably won't be too much work; we already have the cleanup as part of deploy() 13:25:05 <twoerner> it needs to clean up the service file, the link and also the json file 13:25:10 <sgallagh> alxgrtnstrngl: We're planning to release 0.4.0rc1 this week 13:25:29 <sgallagh> twoerner: Yes; I'll make the deploy() pieces into common code 13:25:42 <twoerner> that isgreat 13:26:04 <twoerner> this might then also help Nils 13:26:14 <sgallagh> alxgrtnstrngl: The patch you're working on is not an F23/0.4.0 target. We're looking at that as part of a major refactor for F24/0.5.0 13:27:13 <alxgrtnstrngl> sgallagh, thanks for the clarification 13:27:17 <sgallagh> twoerner: Suggestions for the verb? 13:27:38 <sgallagh> I was thinking about using the decommission verb for this, but I don't think that's exactly the right fit. 13:30:54 <sgallagh> Maybe `rolectl decommission --pending` is the best approach 13:31:13 <twoerner> nope.. decommission is not the proper word in my opinion 13:31:21 <twoerner> more cancel pendingrole 13:31:32 <twoerner> ro rolectl pendingroles list 13:31:36 <sgallagh> Hmm 13:31:36 <twoerner> rolectl pendingroles list 13:31:41 <sgallagh> Yeah, we probably need a list too 13:31:58 <twoerner> rolectl pendingtrole <role>/<name> cancel 13:31:59 <sgallagh> Which is getting complicated, since all of this logic is happening inside the CLI (which I don't like when it can be avoided) 13:32:16 <sgallagh> hmm 13:32:25 <twoerner> or remove 13:32:31 <sgallagh> The thing is, we're creating it as part of a deploy() 13:32:45 <sgallagh> It seems like we should try to mirror that behavior 13:32:55 <sgallagh> I mean, we still use decommission() to clean up a failed deploy() 13:32:56 <nilsph> it should be similar to how we can cancel currently running deployments (can we?) 13:33:07 <sgallagh> nilsph: We don't currently support that, no 13:33:11 <nilsph> "pendingroles" is not a verb 13:33:15 <nilsph> is what I'm getting at 13:33:31 <twoerner> rolectl list pending-roles 13:33:58 <sgallagh> I'm thinking `rolectl list instances --pending` and `rolectl decommission --pending` is the best approach.\ 13:34:39 <sgallagh> It fits with our (already flawed) approach at least. 13:34:44 <nilsph> "decommission" seems wrong as well for canceling a planned "pending" deployment 13:35:05 <twoerner> then --next-boot should be --pending 13:35:07 <sgallagh> It's not a perfect verb, I agree. 13:35:14 <twoerner> to make it fit in 13:35:21 <sgallagh> I'm thinking about that too 13:35:35 <sgallagh> --next-boot is more descriptive of what deploy() is doing. 13:35:51 <sgallagh> But we can't use the same term for decommission(), since we want that to be immediate 13:35:55 <nilsph> "deferred" 13:36:03 <twoerner> +1 13:36:13 <nilsph> gets the vote from the guy at the desk across from me as well :o) 13:36:16 <nilsph> +1 13:36:19 <sgallagh> twoerner: Was that a +1 in support of "deferred" 13:36:24 <twoerner> yes 13:36:36 <twoerner> --deferred 13:36:53 <nilsph> "pending" is a state that could fit a running deployment 13:36:55 <sgallagh> OK, I'll switch the command in my current patch 13:37:05 <sgallagh> I'll leave "pending" in the code though, since it's descriptive. 13:37:10 <nilsph> "deferring" fits better what we intend to do I think 13:37:16 <twoerner> yes 13:37:36 <danofsatx> deferred sounds better, but for some reason I still prefer pending. 13:38:04 <twoerner> sgallagh: please use also deferred in the code just to make it easier to find.. maybe with an additional comment about pending.. 13:38:45 <sgallagh> twoerner: That will require me to refactor the directory paths too... yay -_- 13:38:55 <twoerner> right 13:39:02 <twoerner> but it would be consistent ... 13:39:06 * twoerner hides 13:39:21 <sgallagh> Yeah, it's probably the better choice. I was just *so close* to getting this committed. 13:39:24 <sgallagh> /me weeps softly 13:39:38 <twoerner> I am sorry :-P 13:39:53 <sgallagh> #info We'll rename "pending" to "deferred" in the existing patch and use that terminology going forward. 13:39:58 <nilsph> as evidenced by wagging your tongue at him, right? 13:40:47 <sgallagh> #info We will use `rolectl list instances --deferred` and `rolectl decommission --deferred` for issue 39 13:41:42 <sgallagh> #topic Open Floor 13:42:00 <sgallagh> Anything for Open Floor this week? 13:42:05 <twoerner> yes 13:42:08 <sgallagh> Go ahead 13:42:31 <twoerner> sgallagh: do you know if someone is working on python bindings for libsystemd sd-bus 13:42:32 <twoerner> ? 13:43:09 <twoerner> I had a closer look again after lvm people want to use it for a lvm D-Bus service 13:43:33 <twoerner> and the API is a lot better than gdbus in my opinion.. 13:43:48 <sgallagh> I'm not aware of anyone doing so 13:44:12 <sgallagh> I'm having a meeting with my boss (who is the manager for systemd as well) today. 13:44:21 <sgallagh> I'll see what he knows or is willing to push for. 13:44:33 <twoerner> are you talking about Jack? 13:45:20 <twoerner> there are not really docs for sd-bus 13:45:34 <sgallagh> twoerner: Yes (the description was for the benefit of anyone reading these meeting minutes who doesn't work in our management chain) 13:46:03 <twoerner> I am not part of this management chain anymore ... 13:46:11 <sgallagh> Oh, right. 13:46:29 <sgallagh> Well, anyway... 13:46:34 <sgallagh> I'll see what I can find out. 13:46:39 <twoerner> ok 13:47:34 <nilsph> Just a hunch, I don't think the sd folks will be terribly interested in maintaining language bindings. 13:48:23 <sgallagh> nilsph: I don't expect the upstream to jump at that. 13:48:39 <sgallagh> Although zbsyzek has been very responsive. 13:48:57 <sgallagh> But RHT and Fedora have needs that we may be able to cover from somewhere. 13:49:07 <sgallagh> I'll report back on that later. 13:49:10 <nilsph> cool 13:49:27 <twoerner> ok, thanks 13:50:28 <sgallagh> Anything else for this week? 13:50:39 <nilsph> not from me 13:50:58 <twoerner> I have made some progress with gdbus 13:51:02 * danofsatx is still on his first cup of coffee 13:51:16 <linux-modder> one cup and a soda for me 13:51:39 <twoerner> but this is not in any way in a usable state 13:51:45 <sgallagh> twoerner: ok, good to know 13:52:19 <twoerner> I found some good, bad and also ugly things .. 13:52:32 <sgallagh> twoerner: Even if we asked for someone to build sd-bus python bindings, I suspect they won't be in a usable state in the time we need, so we probably will have to stick with gdbus for the time being 13:52:56 <twoerner> yrs, I also thought about this 13:52:59 <twoerner> yes 13:53:28 <twoerner> but on the other hand we do not want to have two migrations to another dbus implementation 13:54:05 <twoerner> if there would be something in the pipeline for sd-bus python bindings, it would be awesome 13:54:31 <nilsph> depends on the length of the pipeline... 13:54:45 <sgallagh> Right, but we really do have a hard deadline of F24 to work wih 13:54:51 <twoerner> yes 13:55:13 <sgallagh> I'll get back to you ASAP on the sd-bus situation 13:55:22 <twoerner> thanks 13:55:25 <sgallagh> Probably tomorrow, since you'll have left for the day by the time I meet with Jack 13:55:44 <sgallagh> twoerner: In the meantime, maybe set it aside and work on the firewall changes instead? 13:55:46 <twoerner> I will leave at about 18:30 today 13:56:07 <twoerner> and have to have a look at some RHEL-7 things also 13:56:19 <sgallagh> My meeting with Jack is about 20:00 CET 13:56:31 <twoerner> ok.. tomorrow then 13:57:14 <sgallagh> Well, Jack probably won't know anything today, so if you're looking for something to do while that's in limbo... :) 13:58:46 <sgallagh> OK, anything else for today? 14:00:01 <nilsph> no 14:00:15 <twoerner> nope, not from me 14:01:08 <sgallagh> OK, I'll get to work rewriting my patch again. 14:01:10 <sgallagh> #endmeeting