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