13:00:03 <sgallagh> #startmeeting rolekit (2015-08-18)
13:00:03 <zodbot> Meeting started Tue Aug 18 13:00:03 2015 UTC.  The chair is sgallagh. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:00:03 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
13:00:03 <sgallagh> #meetingname rolekitweekly
13:00:03 <sgallagh> #chair sgallagh nphilipp twoerner
13:00:03 <sgallagh> #topic Roll Call
13:00:03 <zodbot> The meeting name has been set to 'rolekitweekly'
13:00:03 <zodbot> Current chairs: nphilipp sgallagh twoerner
13:00:16 <sgallagh> Hello, folks. Who is around today?
13:00:20 <nilsph> hi
13:00:38 <sgallagh> #chair nilsph
13:00:38 <zodbot> Current chairs: nilsph nphilipp sgallagh twoerner
13:00:48 <nilsph> sgallagh: I've changed nicknames, strike nphilipp from the roll
13:01:12 <sgallagh> OK
13:01:13 <twoerner> .hello
13:01:13 <zodbot> twoerner: (hello <an alias, 1 argument>) -- Alias for "hellomynameis $1".
13:01:32 <twoerner> hi
13:01:40 <sgallagh> Thanks for running the meeting last week.
13:01:58 <sgallagh> I just got back from Flock, so I haven't had a chance to look through the activity of the last week in-depth.
13:02:23 <sgallagh> You probably noticed that at Flock we opened a number of new issues though
13:02:35 <sgallagh> This happened during the rolekit hackfest.
13:03:09 <twoerner> yes, I have seen some of them
13:03:25 <sgallagh> We didn't really get any coding done that day, unfortunately
13:03:45 <sgallagh> #topic Status Update
13:03:50 <nilsph> as evidenced by the number of pull requests vs. new issues >:->
13:04:12 <sgallagh> nilsph: Well, I spent most of the two hours walking people through the codebase.
13:04:24 <nilsph> sgallagh: jk
13:04:33 <sgallagh> At least one person in the session is planning to send patches; I'll mention it when we get there
13:05:11 <sgallagh> nilsph, twoerner: What have you been up to since last week?
13:05:43 <sgallagh> #info sgallagh gave a talk on Fedora Server and a hackfest on rolekit at the Flock conference.
13:05:48 <twoerner> I have been working on some firewalld things, mostly no additional rolekit work
13:05:57 <sgallagh> ok
13:06:27 <twoerner> but I have added the information about the dbus backends to the issue
13:06:47 <sgallagh> #info twoerner researched DBUS backends some more
13:06:54 <nilsph> sgallagh: fix issue #28 "redeploy should accept JSON settings via stdin as well" which was a one-liner, couple of other fixes without issues, all posted for review
13:07:07 <sgallagh> I contacted GNOME about the gdbus issue. I've seen that they have already restarted that code review you pointed out
13:07:16 <twoerner> with both DBUS backends there is a need for additional work
13:07:33 <sgallagh> #info nilsph submitted several bugfixes for review
13:07:39 <twoerner> that would be good.. but this is worked on somehow since 2011 from time to time
13:07:42 <sgallagh> #action sgallagh to perform code reviews today and tomorrow
13:08:22 <sgallagh> twoerner: Yeah, we will see what happens. There are other projects that want this (like libstoragemgmt) so I'm hopeful about getting it reprioritized
13:08:36 <nilsph> sgallagh: I also reviewed two of your patches, but that's about it
13:08:39 <sgallagh> Thanks
13:08:43 <twoerner> it gives a similar impression as property handling patches in python-dbus - not much interest in a fix upstream
13:09:39 <sgallagh> twoerner: So, I forgot to mention; there *is* a third option.
13:09:47 <sgallagh> We can always fork python-dbus and maintain it ourselves.
13:09:53 <sgallagh> I'd prefer not to go that route, of course.
13:09:58 <twoerner> ohh yes.. this is another option
13:10:00 <nilsph> I concur with twoerner that all dbus libraries out there (that I know of) leave me unsatisfied. Most of them require too much boilerplate (at least on the native side).
13:10:08 <nilsph> ugh
13:10:18 <nilsph> python-dbus isn't the nicest of codebases
13:10:26 <twoerner> sgallagh: yes, we do not want to fork it..
13:10:30 <nilsph> I'd rather add convenience stuff to gdbus
13:10:40 <twoerner> yes
13:11:01 <sgallagh> #topic DBUS Implementations
13:11:29 <sgallagh> #info We have three realistic options: 1) gdbus, 2) PyQT5, 3) Fork and maintain python-dbus with property patches
13:11:53 <nilsph> from a "WANT" perspective, I'd like something that lets the developer define interfaces etc. in a declarative way, and all the boilerplate gets added automatically
13:12:00 <sgallagh> Let's consider forking python-dbus our last resort
13:12:11 <twoerner> sgallagh: +1
13:12:20 <nilsph> sgallagh: +1
13:12:23 <sgallagh> nilsph: That actually dabbles into something I was going to talk about later in the meeting
13:12:36 <sgallagh> #agreed Forking python-dbus is our option of last-resort
13:12:48 <twoerner> is it simplification of property handling?
13:12:49 <nilsph> ok I'll try not to peek further in your head
13:13:02 <twoerner> in rolekit
13:13:09 <nilsph> twoerner: yeah, property handling is over-complicated everywhere I've looked at
13:13:35 <sgallagh> nilsph: One of the attendees of the hackfest pointed out that a lot of our crufty setting up of settings parameters in roles could be possibly be replaced with metaclass magic.
13:13:44 <nilsph> dbus should be as easy to work with as say sqlalchemy in that regard
13:13:50 <nilsph> sgallagh: I like how they think :)
13:13:55 <nilsph> whoever that was
13:14:14 <twoerner> Phil und Harald, right?
13:14:15 <nilsph> incidentally, sqlalchemy solves a lot of these issues by metaclass magic
13:14:29 <twoerner> lol
13:14:50 <sgallagh> nilsph: It was Solly Ross, actually
13:15:02 <twoerner> I thought about alchemist.. wrong project
13:15:33 <sgallagh> Let's try to avoid creating any homunculi here. Never ends well.
13:16:03 <nilsph> I really like how the SQLalchemy declarative extension lets you define properties, SQL columns and stuff, and dbus would profit if it were as easily usable
13:16:42 <twoerner> sgallagh: that was a project here at RH a long time ago
13:16:44 <nilsph> sgallagh: yeah that was a rather short-lived homunculus
13:16:55 <sgallagh> ...
13:16:59 <sgallagh> Moving on
13:17:10 <nilsph> sgallagh: are you familiar with sqla?
13:17:21 <sgallagh> nilsph: I haven't played with it, but I've heard of it.
13:17:31 <nilsph> let me scare up an example
13:17:37 <sgallagh> ok
13:17:51 <sgallagh> Just for the record, are we now discussing 4) write a new binding ?
13:18:09 <nilsph> no
13:18:14 <nilsph> absolutely not
13:18:30 <nilsph> I'm much too lazy for that, others can deal with on-the-wire protocols if they want, but I'd rather not
13:18:36 <twoerner> just something on top of the D-Bus backaend
13:18:52 <twoerner> s/backaend/backend/
13:18:53 <sgallagh> ok
13:18:54 <nilsph> more convenience code around one of the existing dbus libraries, probably gdbus
13:19:25 <sgallagh> twoerner: BTW, mclasen has asked me to have you talk with #gtk+ about rolekit's needs there.
13:19:36 <nilsph> and I guess we'd limit this to python, as this becomes nigh impossible in native code, or will be awkwards
13:19:38 <nilsph> -s
13:19:47 <sgallagh> Agreed
13:19:50 <twoerner> sgallagh: for a UI?
13:19:59 <sgallagh> twoerner: No, that's the group that owns gdbus
13:20:08 <twoerner> ahh..ok
13:20:31 <nilsph> sgallagh: ideally this would be upstream, but I don't guess they want enhancements that only target one language, so we could put it in python-slip
13:20:32 <sgallagh> Sorry, should have been more clear
13:20:45 <sgallagh> nilsph: Sounds good to me
13:20:51 <sgallagh> (What does "slip" mean anyway?)
13:20:57 <twoerner> yes, that might be a good place
13:21:01 <nilsph> "simple library in python"
13:21:11 <nilsph> I didn't come up with a good name, but meh
13:21:16 <sgallagh> heh
13:21:40 <nilsph> sgallagh: "garbage dump" sounded worse :)
13:21:53 <sgallagh> nilsph: Are you familiar with my old project ding-libs?
13:21:58 <nilsph> no
13:22:08 <sgallagh> "Ding Is Not Glib"
13:22:11 <nilsph> hah
13:22:14 <twoerner> LOL
13:22:18 <nilsph> is that "glib for the real world"?
13:22:48 <twoerner> ohh my.. I am just asking myself which road we are on right now
13:22:49 <sgallagh> No, really it was a bunch of convenience libraries we built for SSSD and FreeIPA that were somewhat useful outside those projects.
13:22:57 <sgallagh> But it's an eclectic collection of them
13:23:18 <nilsph> similar with slip, convenience and enhancement stuff that for some reason or other wasn't palatable to upstream
13:23:23 <twoerner> yes
13:23:31 <sgallagh> /me nods
13:23:33 <nilsph> dbus <-> polkit integration for instance, that's the main reason for its existence
13:23:52 <sgallagh> OK, so:
13:23:56 <twoerner> yes.. python-slip makes it much easier for the projects
13:24:15 <sgallagh> #info We will aim to add metaclass magic to python-slip-dbus
13:24:34 <nilsph> more metaclass magic
13:24:38 <nilsph> :)
13:25:00 <sgallagh> My goal is to conquer the world with metaclasses /darkwizard
13:25:08 <nilsph> ideally something that makes gdbus similarly easy to work with as python-dbus, and more
13:25:18 <sgallagh> /me nods
13:25:21 <nilsph> good
13:25:39 <nilsph> and bonus: metaclasses aren't straight-forward to debug, so job security :D
13:25:40 <sgallagh> OK, so it sounds like we generally prefer the gdbus approach?
13:25:45 <sgallagh> (But we're blocked on that one bug?)
13:26:22 <nilsph> what exactly is it we don't like about the python-dbus API (not its bugs)?
13:26:23 <twoerner> yes
13:26:34 <twoerner> with gdbus we have the dbus types at least
13:26:41 <twoerner> and are able to use them
13:26:43 <nilsph> I mean it's already pretty declarative.
13:26:56 <nilsph> It isn't declarative enough in terms of properties.
13:27:03 <sgallagh> nilsph: Upstream doesn't want to carry the patch we added for property support.
13:27:04 <nilsph> That's one thing that itches me.
13:27:07 <nilsph> aye
13:27:11 <sgallagh> And the new Fedora maintainer wants to remove it
13:27:32 <nilsph> upstream at one point didn't even want to develop it further, when I asked them about getting some stuff from slip upstream
13:27:55 <sgallagh> It seems like they still don't want to maintain it, honestly
13:27:58 <nilsph> so step 0 is getting "easy properties" into slip.dbus?
13:28:03 <twoerner> this is a long standing issue with python-dbus
13:28:32 <twoerner> hopefully we have more luck with gdbus ...
13:28:32 <sgallagh> nilsph: Our main concern is that without python-dbus being actively maintained upstream, it's only going to be accruing technical debt to stick with it
13:28:33 <nilsph> which "just" hides the property handling from the user, but is still based on python-dbus
13:28:41 <nilsph> agreed
13:29:54 <sgallagh> The longer we stick with it, the harder it will be to divest from it
13:30:39 <sgallagh> Unless we came up with a really clever way to abstract it with python-slip such that we could change out the implementation at will
13:31:11 <nilsph> well I don't want to make it dbus-implementation agnostic, that sounds like (nnecessary) work
13:31:34 <nilsph> stick with one implementation, but get the declarative shinyness of python-dbus plus the property stuff they don't want to have
13:32:32 <nilsph> I don't mean get the same API necessarily, but one that's as easy to use
13:32:50 <sgallagh> Sure
13:33:04 <nilsph> without having to write your fingers bloody, if you want to do that, go program Java :o)
13:33:53 <sgallagh> So I see two choices here: 1) Push for gdbus and assume that pain up-front and write python-slip helpers to make it easy to use. 2) Stick with python-dbus and move the property implementation into python-slip and out of the python-dbus package
13:34:30 <nilsph> sgallagh: twoerner just told me OOB that it's probably impossible to make the property stuff on top of, but outside of python-dbus
13:34:31 <sgallagh> The first one is a lot of work now, but the project is maintained; the second one is less work now, but could bit us hard down the line
13:34:37 <twoerner> we can not easily add property handling on top of python-dbus.. as it does not support to extend the introspection data
13:34:46 <sgallagh> ah
13:34:58 <twoerner> this means there is no way to get information about properties to the client
13:35:07 <sgallagh> ok, that reduces the problem-space back to gdbus-or-fork, then
13:35:19 <twoerner> yes, these are the options
13:35:20 <nilsph> which sucks with python-dbus because it relies on introspection data to work AIUI
13:35:23 <twoerner> in my opinion
13:35:50 <sgallagh> (or create a new implementation, but that would be unpleasant)
13:35:55 <nilsph> I'll cast my vote for a shiny gdbus wrapper, more pain now, less later
13:36:30 <twoerner> as long as there are no additional issue with it that need to be solved
13:36:40 <twoerner> s/issue/issues/
13:36:44 <nilsph> it doesn't have to be in slip, we can make a separate thing out of it if it gets too big
13:37:01 <twoerner> python-slip-gdbus
13:37:06 <sgallagh> /me nods
13:37:38 <twoerner> I will most likely reuse it for firewalld then also
13:37:39 <nilsph> twoerner: what additional issues? I mean, yes additional issues suck, but what do we do now, when we don't know about them :)
13:38:04 <sgallagh> Yeah, we can't be held hostage to unknowable issues
13:38:14 <twoerner> nilsph: without beeing able to create a server that is doing something, we do not know if there are more issues
13:38:23 <nilsph> Ideally, the objects that fall out of "that" would still be as close to Gdbus stuff in their behavior etc.
13:38:32 <twoerner> yes
13:38:58 <sgallagh> twoerner: How critical is the Vtable bug? Can we hack around it, or is it a non-starter if that isn't fixed?
13:39:02 <nilsph> twoerner: true, true, but if the stuff is close to gdbus, we can start out with "native" gdbus and migrate to "declarative, nice, shiny" later
13:39:13 <twoerner> we can not get around it now
13:39:28 <nilsph> context for the uninitiated?
13:39:40 <sgallagh> #link https://bugzilla.gnome.org/show_bug.cgi?id=656325
13:40:16 <nilsph> gack that one just celebrated its 8th birthday
13:40:19 <twoerner> it is the main point to anchor the method call handling in the server
13:41:12 <sgallagh> nilsph: Fourth, not eighth :)
13:41:19 <nilsph> yuck right
13:41:21 <nilsph> still
13:41:27 <nilsph> it's in Kindergarten now!
13:42:15 <sgallagh> Well, it has seen activity today. We'll see how that goes.
13:42:20 <twoerner> without vtable you can define introspection data, but there is no way to call into anything you have in your code to handle this
13:44:37 <sgallagh> ok, so we'll call that a distinct blocker.
13:44:46 <sgallagh> We'll put this effort on temporary hold until that's resolved.
13:45:24 <sgallagh> For general agreement: The plan of record is to move to gdbus and implement python-slip-gdbus helpers as soon as the blocker bug is resolved.
13:45:37 <sgallagh> +1/-1?
13:45:41 <sgallagh> +1 from me
13:47:04 <twoerner> +1
13:47:07 <nilsph> +1, as long as we don't nail down where it happens. if it's big enough, it should go separate.
13:47:29 <sgallagh> nilsph: OK
13:47:49 <sgallagh> #agreed The plan of record is to move to gdbus and implement helpers as soon as the blocker bug is resolved.
13:48:20 <nilsph> sgallagh: who knows, perhaps we need to do stuff on the native side, then I don't want it in slip
13:48:34 <sgallagh> Understood.
13:48:36 <sgallagh> OK, do we want to go through the new tickets?
13:49:08 <twoerner> ok
13:49:09 <sgallagh> #topic Triage
13:49:13 <sgallagh> #link https://github.com/libre-server/rolekit/issues?q=is%3Aopen+is%3Aissue+no%3Amilestone
13:49:37 <sgallagh> No need to revisit anything from ticket 32 or older today
13:49:53 <sgallagh> Err, 31 or older I mean
13:50:16 <sgallagh> #topic New role: SSL VPN server - https://github.com/libre-server/rolekit/issues/32
13:50:39 <nilsph> "help wanted" is my gut feeling
13:50:43 <twoerner> yes
13:50:44 <sgallagh> I'm looking into this with Nikos.
13:50:53 <sgallagh> Yes, this is going to require collaboration with the maintainer
13:51:02 <sgallagh> I'm not prepared to set a milestone on it today, but I'll self-assign
13:52:01 <sgallagh> #info Setting help-wanted and assigning to sgallagh
13:52:04 <nilsph> btw, what about nomenclature -- we now have a "databaseserver" that is a specific implementation (postgresql), do we want to continue that, i.e. select one tool which we find best for a job and name that $job instead of $specific-tool-for-job?
13:52:34 <nilsph> on the other hand we have "memcached" which is specific to the implementation
13:52:37 <sgallagh> Yes, if this is implemented, it will become the SSL VPN role
13:52:56 <sgallagh> actually, we have 'memcache' which provides an in-memory caching daemon
13:53:08 <sgallagh> The fact that 'memcached' implements it is entirely a coincidence ;-)
13:53:13 <nilsph> mmh
13:53:41 <sgallagh> #topic There should be a way to drop autogenerated secrets stored in rolekit - https://github.com/libre-server/rolekit/issues/33
13:54:01 <sgallagh> This will be a very easy fix, but it's very important.
13:54:56 <sgallagh> Also, once we have this, we can probably move Domain Controller away from requiring any arguments at all (since previously we mandated the password solely because admin_password could change and we didn't want to have wrong information in the settings)
13:55:29 <nilsph> I haven't worked with the domain controller yet, where does it store these? would that involve a new verb for rolectl?
13:55:45 <alxgrtnstrngl> Hello, finally made it this week
13:56:20 <sgallagh> nilsph: I think we can probably use Set() for this.
13:56:29 <sgallagh> alxgrtnstrngl: Good to see you
13:56:38 <twoerner> we might need to define which ones are to be removed
13:56:39 <sgallagh> Right now we're going through bug triage
13:56:50 <nilsph> well, ticket triage
13:57:11 <sgallagh> twoerner: Right, we'll need a mechanism for that. Then for those properties, we can just accept "empty string" as removal.
13:57:35 <twoerner> yes.. just removing all might lead into big fun
13:57:43 <nilsph> sgallagh: wouldn't setting an empty string unset the password in the controller?
13:57:54 * nilsph is confused
13:58:00 <sgallagh> twoerner: Actually, it probably wouldn't do anything
13:58:20 <sgallagh> nilsph: No, only a redeploy() actually changes things.
13:58:38 <sgallagh> twoerner: Really, it would just leave them in a state where rolekit's view didn't match reality.
13:58:50 <sgallagh> Which can already happen if things are changed behind the scenes sometimes anyway.
13:59:04 <twoerner> yes, you are right...
13:59:09 <sgallagh> So as a first approximation, allowing the attributes to be set to empty string is probably okay
13:59:38 <twoerner> maybe we should have a special value to make sure that they have been removed
13:59:40 <nilsph> sgallagh: so if you redeploy, you'd need to supply the password(s) again, and remove it/them?
13:59:54 <twoerner> to make sure that in a redeploy the passwords are not empty
13:59:56 <sgallagh> (an argument could be made that we might want to make Set() capable of hooking into a callback, but that's probably best left ignored until we change out our dbus implementation0
14:00:08 <twoerner> which would be very bad in some scenarios
14:00:14 <sgallagh> nilsph: Well, right now redeploy() isn't implemented for DC anyway
14:00:22 <nilsph> right
14:00:36 <sgallagh> twoerner: redeploy() isn't a diff; it has to have all options
14:01:24 <twoerner> why I am always thinking it would be a diff ... maybe this would be more expected?
14:02:33 * twoerner hammers this into his# head: redeploy requires all settings again
14:02:39 <sgallagh> twoerner: Unclear, but for now it's not a diff
14:02:55 <sgallagh> twoerner: But the idea was for it to be idempotent
14:04:46 <sgallagh> So, I'm not going to call it a blocker, but I'd rather like to see this in Fedora 23 Beta if we can manage it.
14:04:55 <twoerner> +1
14:07:10 <nilsph> the forgetting secrets thing?
14:07:12 <nilsph> +1
14:07:42 <sgallagh> Looking at dbusrole.py, we may already have most of this. Probably just need to add 'rolectl clear-setting <instance> <setting>'
14:07:51 <twoerner> yes
14:08:02 <sgallagh> I'll self-assign. Shouldn't be too hard.
14:08:14 <twoerner> I could do this if you want to
14:08:20 <twoerner> ohh.. too late :-)
14:08:37 <sgallagh> Reassigning to twoerner :)
14:08:43 <twoerner> thanks
14:09:00 <sgallagh> Cool. Yeah, I should really be focusing on the nulecule stuff, actually
14:09:03 <sgallagh> OK, next ticket.
14:09:42 <sgallagh> #info Milestone: F23 Beta, Assignee: twoerner, non-blocking
14:09:49 <sgallagh> #topic Man pages still reference the old website - https://github.com/libre-server/rolekit/issues/34
14:10:00 <sgallagh> EasyFix, just need to tweak the manpage XML
14:10:28 <nilsph> can do
14:11:14 <sgallagh> #info Milestone: F23 Beta, Assignee: nilsph, non-blocking
14:11:47 <nilsph> sgallagh: there's some other stuff referencing fedorahosted, what shall we do about it?
14:11:55 <nilsph> e.g. "make archive"
14:12:16 <sgallagh> nilsph: Anything referencing fhosted should be updated
14:12:36 <nilsph> I've recently migrated slip from fedorahosted to github and uploading a tarball isn't a mere scp :)
14:12:39 <sgallagh> #info Anything else referencing Fedora Hosted should be replaced
14:12:59 <sgallagh> #topic Convert Async Code to Python 3.4 Style - https://github.com/libre-server/rolekit/issues/35
14:13:16 <sgallagh> Solly submitted this one and implied he'd be interested in helping.
14:13:17 <nilsph> I have implemented make recipes that do that however. Not sure how much tweaking they need to work in rolekit
14:13:39 <sgallagh> Currently, our async code is done in 2.7-compatible style. It's not broken, but 3.4 is more maintainable once we make the switch.
14:13:59 <nilsph> if he wants it he can have it +1
14:14:03 <twoerner> are we going to drop Python2 support completely?
14:14:08 <sgallagh> It's not urgent, so I'm going to say "help-wanted, no milestone at this time"
14:14:11 <sgallagh> twoerner: We already have
14:14:18 <sgallagh> It doesn't build against Python 2 at this time
14:14:19 <twoerner> not everywhere
14:14:50 <sgallagh> #info Help wanted
14:15:54 <sgallagh> #topic Simplify the dbus property method creation - https://github.com/libre-server/rolekit/issues/36
14:15:59 <sgallagh> Same as above, I think
14:16:33 <nilsph> sgallagh: btw, is the wiki documentation on github now?
14:16:37 <twoerner> yes, this is something that takes some time
14:16:45 <sgallagh> nilsph: No, I keep meaning to do that.
14:16:53 <sgallagh> Please open an issue and assign it to me :)
14:16:53 <nilsph> so shall I leave the old url?
14:16:56 <nilsph> heh
14:16:58 <nilsph> good
14:17:33 <nilsph> I'll leave a reference to the old home page in, until we've fully migrated
14:18:53 <sgallagh> Makes sense
14:19:03 <sgallagh> Though I'll try to do that right after this meeting
14:19:15 <nilsph> I'll also leave the old source urls in because the tarballs aren't yet on github
14:19:28 <sgallagh> /me nods
14:19:44 <sgallagh> I thought I had done that; no?
14:20:00 <nilsph> https://github.com/libre-server/rolekit/releases
14:20:05 <nilsph> doesn't look like it
14:20:13 <nilsph> only the auto-generated ones
14:20:34 <sgallagh> Huh... could have sworn.
14:20:37 <sgallagh> OK, I'll fix that too
14:20:41 <nilsph> so this basically makes this issue (nix fedorahosted references) depend on "fully migrate to github" (docs, tarballs, etc.)
14:21:19 <sgallagh> Ah, looks like even the recent ones went to fhosted. Right, we made the switch after that
14:21:32 <sgallagh> Yes, please file that, I'll do it today.
14:21:36 <nilsph> ok
14:23:16 <nilsph> sgallagh: hmm the old URL for the wiki docs returns an empty page. https://fedoraproject.org/wiki/Rolekit
14:23:22 <sgallagh> #info Help wanted
14:23:52 <sgallagh> nilsph: Not sure where that one came from.
14:25:03 <sgallagh> #topic Open Floor
14:25:13 <sgallagh> Any other topics or shall we close this meeting?
14:25:22 <alxgrtnstrngl> Issue 17
14:26:48 <alxgrtnstrngl> https://github.com/libre-server/rolekit/issues/17
14:27:22 <alxgrtnstrngl> you can assign me to that issue, I've already reviewed systemdunitparser and am testing the patch
14:28:03 <alxgrtnstrngl> I also have a few questions as well.  So far the config/roles will generate *.service files correct?
14:28:33 <sgallagh> alxgrtnstrngl: What's your github account?
14:28:51 <alxgrtnstrngl> https://github.com/alxgrtnstrngl
14:28:56 <sgallagh> Also, systemdunitparser is going away; We're going to carry the functionality in rolekit itself for a while.
14:29:13 <sgallagh> Please develop atop http://reviewboard-fedoraserver.rhcloud.com/r/178/
14:29:23 <alxgrtnstrngl> Right, will do
14:29:53 <alxgrtnstrngl> So the roles create service files that bindto the underlying services, like the domain controller to ipa service files
14:29:59 <sgallagh> Eventually, that implementation will move to python-systemd (upstream's tools)
14:31:47 <twoerner> alxgrtnstrngl: please share some information about yourself :-)
14:32:10 <alxgrtnstrngl> Quick Intro:
14:32:44 <alxgrtnstrngl> Have been using Linux for several years, primarily Fedora, currently in DevOps and very interested in Python and server automation
14:33:39 <twoerner> ok, thanks
14:34:00 <sgallagh> alxgrtnstrngl: Accept the github invitation and I'll assign that to you
14:34:40 <twoerner> alxgrtnstrngl: welcome! :-)
14:36:01 <alxgrtnstrngl> twoerner, thanks!
14:36:09 <alxgrtnstrngl> sgallagh, got it
14:36:49 <sgallagh> Assigned
14:37:11 <alxgrtnstrngl> awesome
14:38:17 <sgallagh> OK, anything else folks?
14:38:29 <sgallagh> alxgrtnstrngl: We can talk more about that specific bug outside the meeting.
14:38:37 <alxgrtnstrngl> sgallagh, ok
14:40:29 <sgallagh> OK, let's call it a day, then
14:40:31 <sgallagh> #endmeeting