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