13:00:18 <sgallagh> #startmeeting rolekit (2015-08-04)
13:00:18 <zodbot> Meeting started Tue Aug  4 13:00:18 2015 UTC.  The chair is sgallagh. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:00:18 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
13:00:18 <sgallagh> #meetingname rolekitweekly
13:00:18 <zodbot> The meeting name has been set to 'rolekitweekly'
13:00:19 <sgallagh> #chair sgallagh twoerner nphilipp
13:00:19 <sgallagh> #topic init process
13:00:19 <zodbot> Current chairs: nphilipp sgallagh twoerner
13:00:31 <nphilipp> yo
13:00:37 <sgallagh> .hello sgallagh
13:00:37 <zodbot> sgallagh: sgallagh 'Stephen Gallagher' <sgallagh@redhat.com>
13:01:28 <nphilipp> .hello nphilipp
13:01:29 <zodbot> nphilipp: nphilipp 'Nils Philippsen' <nphilipp@redhat.com>
13:02:24 <sgallagh> twoerner: Are you around?
13:03:31 <sgallagh> nphilipp: Have you seen him today?
13:04:12 <nphilipp> sgallagh: sure
13:04:39 <sgallagh> /me would prefer to run through this bug triage with all of us present
13:05:04 <sgallagh> At least this first time, since it will likely be the longest one
13:05:20 <twoerner> sgallagh: hi
13:05:27 <twoerner> now I am .... :-)
13:05:44 <sgallagh> Welcome :)
13:05:58 <sgallagh> OK, so let's start our first meeting.
13:06:02 <twoerner> ok
13:06:03 <sgallagh> #topic Agenda
13:06:06 <twoerner> I am sorry to be late
13:06:17 <sgallagh> #info Agenda Item: Issue Triage
13:06:37 <sgallagh> I think that's going to fill up our schedule for today
13:07:12 <sgallagh> Does anyone else have a pressing agenda item to bring up?
13:07:55 <sgallagh> ok, so let's get started on the list.
13:08:19 <sgallagh> #topic https://github.com/libre-server/rolekit/issues/1 - [RFE] Support deploying roles in kickstart
13:08:57 <sgallagh> So, I'm going to call this one F23 Beta. I've got a working patch almost ready for review.
13:09:33 <sgallagh> Agreed?
13:09:47 <twoerner> sgallagh: do you make sure that a config file will be copied over into the installed system?
13:09:57 <sgallagh> twoerner: I do, yes.
13:10:10 <twoerner> ok
13:10:13 <sgallagh> Pending configs going into /etc/rolekit/pendingroles/rolename/name.json
13:10:40 <sgallagh> We can discuss the particulars when I send the patch for review (but you can see it on my github fork if you're curious; it's linked from the issue)
13:11:18 <twoerner> I will have a look as soon as it is in review board, I think :-)
13:11:32 <twoerner> or if you ask me to check before ..
13:11:48 <sgallagh> #idea Fedora 23 Beta Blocker
13:11:59 <sgallagh> twoerner: It should be on Review Board sometime today
13:12:10 <twoerner> ok
13:12:41 <sgallagh> (Point of process: I'll put out #idea lines that are essentially a request for a vote on how to categorize the bugs. Please +1 or -1
13:12:44 <twoerner> +1
13:12:55 <sgallagh> If you -1, please provide reasoning :)
13:13:23 <nphilipp> +1
13:13:49 <twoerner> this should be fairly simple to achieve... therefore I do not see big issues here
13:13:54 <sgallagh> #agreed Fedora 23 Beta Blocker
13:14:14 <sgallagh> twoerner: It's slightly more complicated than it sounds, but as I said, the patch is basically ready.
13:14:30 <sgallagh> The only thing holding it up is that I'm working with the systemd folks to get a dependent patch to python-systemd upstreamed.
13:14:41 <twoerner> oh..
13:14:42 <sgallagh> We may just carry the implementation in rolekit until a release happens, though
13:14:48 <twoerner> are you sure that it will make it in?
13:15:00 <twoerner> python-systemd is now an extra package
13:15:12 <twoerner> therefore not bound to systemd release cycles anymore
13:15:19 <sgallagh> twoerner: Upstream already accepted it, it's just a matter of cleaning it up to work on both Py2 and Py3
13:15:33 <twoerner> oh yes
13:16:06 <sgallagh> My implementation was highly py3-ified
13:16:16 <sgallagh> anyway, let's move on. Lots to get through :)
13:16:31 <sgallagh> Oh, one other point of order; I've added two labels: Blocker and Nice-to-have.
13:16:45 <sgallagh> Blocker means the obvious; we won't consider the milestone met until all of those are closed.
13:16:59 <sgallagh> Nice-to-have means that it's eligible for deferral to the next release if not finished on time
13:17:14 <twoerner> yes, but the issues are not assigned to any milestone yet
13:17:39 <sgallagh> twoerner: That's the point of this triage :)
13:17:43 <twoerner> yes
13:18:57 <sgallagh> #topic https://github.com/libre-server/rolekit/issues/3 - [RFE] Add single-node kubernetes role
13:19:14 <sgallagh> So, this is a dependency for creating nulecule-based roles.
13:19:42 <sgallagh> We need to be able to set up a kube environment on the local machine to control it.
13:20:50 <sgallagh> This ticket may actually need to be split into two; we probably want separate roles for kube nodes and controllers
13:21:12 <sgallagh> Such a split will be dependent upon https://github.com/libre-server/rolekit/issues/4 which we will discuss next.
13:21:33 <sgallagh> As this is directly relevant to my internal responsibilities at Red Hat right now, I'll propose:
13:21:39 <sgallagh> #idea Fedora 23 Beta, Nice-to-have
13:21:54 <sgallagh> (It may turn out to be more than I can deliver in one month's time, with Flock in the middle)
13:22:07 <sgallagh> But if I deliver it for F23, it needs to happen by Beta.
13:22:33 <nphilipp> I don't know enough about kubernetes etc. to have a meaningful opinion of my own :)
13:22:33 <twoerner> yes, beta freeze is at 09-08
13:23:21 <sgallagh> nphilipp: It's a prereq for https://github.com/libre-server/rolekit/issues/14
13:24:26 <sgallagh> twoerner: Right, I've set the rolekit milestone for Beta at 09-04
13:24:27 <twoerner> I have not been using nulecule yet
13:25:13 <twoerner> as we do not have translation yet, the translation deadline is not an issue for us :-)
13:25:19 <sgallagh> /me nods
13:25:30 <sgallagh> We'll discuss that one later :)
13:26:33 <twoerner> ahh..
13:26:33 <sgallagh> Votes?
13:26:34 <twoerner> +1
13:26:51 <sgallagh> +1
13:26:54 <nphilipp> I'll defer to your judgment, as I said above
13:26:55 <nphilipp> +1
13:26:56 <twoerner> nice-to-have
13:27:11 <sgallagh> #agreed Fedora 23 Beta, Nice-to-have
13:27:47 <sgallagh> #topic https://github.com/libre-server/rolekit/issues/4 - Add official mechanism for chaining roles together
13:28:28 <sgallagh> Does anyone know if it's possible to set deps between issues?
13:28:31 <twoerner> chaining means here that if one fails the dependent will fail also
13:29:12 <sgallagh> twoerner: It means that one role can require the presence of another role on the system.
13:29:19 <nphilipp> I don't think so (re: github issues)
13:29:21 <sgallagh> And cause it to be installed if it's not already there.
13:29:34 <twoerner> sgallagh: and deployed and started?
13:29:36 <nphilipp> and prevent it from being uninstalled?
13:29:46 <sgallagh> twoerner: Yes
13:29:56 <sgallagh> This is a pretty complicated problem, actually. Since dependent roles may need additional settings...
13:30:26 <twoerner> yes, this needs some rules also in the roles
13:30:34 <nphilipp> step 0 would be to simply fail if the role one depends upon is not deployed and active
13:30:35 <sgallagh> As I'm typing, I'm thinking that maybe we defer being able to do this automatically and only add support for failing if the dependent role is not already available
13:30:38 <nphilipp> I think
13:30:48 <sgallagh> nphilipp: You read my mind
13:31:01 <nphilipp> heh
13:31:13 <twoerner> yes, this would be a good starting point
13:31:45 <twoerner> to install, deploy and start them automatically could be done in phase 2
13:32:06 <nphilipp> 0.5 would be to prevent the dependent role from being decommissioned if the depending role is still deployed
13:32:07 <sgallagh> #idea Reduce scope to detecting dependent roles on the system and fail if they are not present with a useful message. Fedora 23 Beta, Nice-to-have
13:32:20 <nphilipp> +1
13:32:31 <twoerner> maybe also with an additional switch to automatically solve dependencies
13:32:32 <sgallagh> nphilipp: I'd call that part of step 0, actually
13:32:33 <twoerner> +1
13:32:48 <nphilipp> sgallagh: agreed
13:33:52 <sgallagh> nphilipp: Want to work on your first non-trivial patch? :)
13:34:19 <nphilipp> I can give it a shot
13:34:33 <sgallagh> ok
13:34:52 <sgallagh> Actually, one more thing; roles should be able to override the dependency.
13:35:09 <nphilipp> meaning what
13:35:10 <sgallagh> For example, if they specify a remote database server, they should not be held to the dep on the local one
13:35:16 <nphilipp> aah
13:35:56 <twoerner> this is hard to determine within the local rolekit then
13:36:27 <sgallagh> twoerner: It should be possible for the role implementation to make the decision based on the provided settings
13:36:29 <nphilipp> dummy roles as standins for remote services?
13:36:31 <twoerner> and might depend a lot on the role itself.. test calls etc.
13:37:11 <sgallagh> If the user doesn't specify a remote server, the default should be to use the one on the standard ports provided by a role
13:37:57 <sgallagh> Or maybe we're overengineering this and we shouldn't do anything more complicated than allowing roles to add "After=" values to their systemd unit files
13:38:21 <sgallagh> And just expect users to install things in a sane order.
13:38:32 <twoerner> this would be a very simple solution
13:38:48 <sgallagh> /me likes simple solutions
13:38:49 <twoerner> phase 0.1
13:38:52 <sgallagh> hahaha
13:39:56 <twoerner> +1 for 0.1
13:39:58 <sgallagh> And since roles can already decide what After= values they set, I think we can probably just close this as WONTFIX and solve it at the individual role case
13:40:44 <twoerner> I think we can start with this simple case and extend it when needed
13:40:48 <sgallagh> Yes
13:40:50 <nphilipp> yup
13:41:16 <sgallagh> #idea We don't need additional infrastructure for this. We can solve it with systemd unit file options.
13:41:25 <sgallagh> #undo
13:41:25 <zodbot> Removing item from minutes: IDEA by sgallagh at 13:41:16 : We don't need additional infrastructure for this. We can solve it with systemd unit file options.
13:41:39 <sgallagh> #idea We don't need additional infrastructure for this. We can solve it with existing systemd unit file options.
13:42:00 <twoerner> +1
13:42:38 <nphilipp> +1
13:43:08 <sgallagh> #topic https://github.com/libre-server/rolekit/issues/6 - Redeploy() needs to handle packages and firewall rules
13:43:46 <sgallagh> #idea Fedora 23 Beta, Blocker
13:44:05 <sgallagh> Given that we implemented redeploy() for the memcache role, we probably need to fix bugs in this.
13:44:09 <sgallagh> Oops.
13:44:11 <twoerner> as far as I understood, the user/admin should be able to uninstall packages after deploy
13:44:12 <sgallagh> #undo
13:44:12 <zodbot> Removing item from minutes: IDEA by sgallagh at 13:43:46 : Fedora 23 Beta, Blocker
13:44:17 <sgallagh> #idea Fedora 23 Final, Blocker
13:44:33 <sgallagh> twoerner: No, there's no expectation that packages will be uninstalled.
13:44:47 <twoerner> ok, good
13:44:57 <sgallagh> Just that the service will be disabled and configuration restored to whatever preceded the deploy
13:45:25 <twoerner> ok.. no auto-uninstall.. this is not what I meant
13:45:33 <twoerner> s/meant/was talking about/
13:45:46 <sgallagh> Then I don't understand the question
13:46:10 <nphilipp> so state after redeploy ~= state after decomission plus deploy?
13:46:18 <twoerner> if the user is uninstalling a package manually, the redeploy will then install the package again.. this is then expected
13:47:02 <twoerner> nphilipp: if there is no new configuration supplied to redeploy it will use the role defaults
13:47:16 <sgallagh> nphilipp: No (though in the container case, that happens to be a close-but-not-exact approximation)
13:47:42 <sgallagh> twoerner: Yes
13:48:25 <twoerner> nphilipp: only one thing will still be the same: the instance name
13:48:50 <twoerner> this will not be set back to the default as it is used to identify the instance to be redeployed
13:49:09 <twoerner> and will still be the same after redeploy
13:49:29 <sgallagh> The other thing that's expected of a redeploy is that no user data should be lost
13:49:39 <sgallagh> (memcache is a special-case, as its data is non-persistent anyway)
13:49:42 <twoerner> sgallagh: user data?
13:49:51 <nphilipp> db contents for instance, twoerner
13:49:59 <sgallagh> twoerner: If you redeploy a database server, the contents must not disappear
13:50:15 <twoerner> ok..
13:50:29 <twoerner> hopefully this is the case for all roles we have
13:50:40 <nphilipp> but otherwise it should grandfather configuration if applicable, right?
13:51:09 <sgallagh> twoerner: redeploy() isn't currently implmented for any but memcache
13:51:19 <twoerner> yes, right.. just checked
13:51:26 <sgallagh> nphilipp: What does that mean?
13:52:15 <nphilipp> sgallagh: I assume that redeploying a role should if possible use the same settings that were used in the original deployment, correct?
13:53:17 <sgallagh> nphilipp: No.
13:53:36 <sgallagh> We decided early on that redeploy() must take the complete set of arguments you want. Not just a diff from the current values.
13:53:48 <twoerner> for a database this might be unexpected....
13:54:03 <sgallagh> twoerner: Which might
13:54:04 <sgallagh> ?
13:54:43 <twoerner> sgallagh: for a database the database name is very important and should at best be constant even after redeploy without new config settings
13:55:13 <nphilipp> anything else wouldn't work
13:55:21 <nphilipp> AIUI
13:55:33 <sgallagh> twoerner: There's nothing preventing the implementation from checking and refusing to redeploy() if the arguments are bad.
13:55:41 <nphilipp> or would the redeploy then rename the database (not sure this is even possible with all RDBMS)
13:55:48 <sgallagh> I just mean that the redeploy() infrastructure itself shouldn't be responsible for trying to manage that
13:56:20 <nphilipp> what's the use case for redeploy?
13:56:32 <nphilipp> as opposed to decommission && deploy
13:56:38 <sgallagh> nphilipp: Adding or removing optional components
13:56:42 <nphilipp> (which wouldn't delete user data AIUI)
13:56:59 <sgallagh> For the Domain Controller, it could mean adding the DNS server or Certificate System (for example)
13:57:26 <sgallagh> nphilipp: decommission *does* delete user data, actaully
13:57:51 <sgallagh> It doesn't uninstall packages, but it does remove databases, reset config files, etc.
13:58:24 <twoerner> there are several use cases: 1) failed deploy, use corrected settings, 2) upgrade to new role version, 3) reuse of configuration for a new use case
13:58:39 <twoerner> but there are others also...
13:59:41 <sgallagh> In the failed deploy case, I think we want to recommend the actual decommission and deploy process instead of redeploy()
13:59:53 <sgallagh> 2) Should be handled by update(), not redeploy()
14:00:00 <sgallagh> 3) Not sure what you mean there
14:00:13 <twoerner> sgallagh: not a new pacakge version... but for example the migration from mysql to the newer one
14:00:20 <nphilipp> so e.g. to update to a new role version you would do s.th. like `rolectl settings $instance | rolectl redeploy $instance --settings-stdin`?
14:00:23 <twoerner> from mysql to mariadb
14:00:41 <nphilipp> ahh update
14:00:46 <nphilipp> so scratch my comment
14:01:18 <sgallagh> twoerner: I think we may need a whole new command for that, honestly.
14:01:40 <sgallagh> I think we've gone far afield of this issue, though.
14:01:55 <sgallagh> The original idea was just "make sure the packages and firewall are correct on redeploy()"
14:01:55 <nphilipp> (btw, redeploy should accept --settings-stdin as well)
14:02:02 <twoerner> oh yes
14:02:03 <sgallagh> nphilipp: Doesn't it?
14:02:14 <twoerner> this is missing - I think
14:02:21 <nphilipp> not according to --help
14:02:32 <sgallagh> Oops
14:02:42 <twoerner> only added for deploy
14:02:55 <sgallagh> I added it to the implementation, but forgot it in the argparser
14:03:04 <sgallagh> nphilipp: Please open an issue :)
14:04:44 <twoerner> ok..
14:04:45 <twoerner> +1
14:04:50 <sgallagh> OK, so the current proposal on the table is to make sure the firewall and packages are correct on a redeploy() and for F23 Final, Blocker
14:04:52 <sgallagh> +1
14:05:02 <sgallagh> twoerner: Can I throw this one on your plate?
14:05:09 <twoerner> yes
14:05:16 <twoerner> sure
14:05:43 <nphilipp> +1
14:05:55 <sgallagh> OK, so we've gotten through four of 22 so far...
14:05:59 <sgallagh> We may need to go faster :)
14:06:09 <twoerner> hmm.. yes
14:06:11 <nphilipp> sgallagh: don't open up so many issues then :o)
14:06:21 <twoerner> LOL
14:06:33 <sgallagh> nphilipp: But I have so many great ideas!
14:06:41 <sgallagh> And even more bad ones!
14:06:44 <nphilipp> heh
14:06:55 <sgallagh> #agreed Fedora 23 Final, Blocker
14:06:56 <twoerner> let us hear the bad ones then :-)
14:06:56 <nphilipp> we need ideas to churn out decisions faster :)
14:07:05 <sgallagh> #topic https://github.com/libre-server/rolekit/issues/7 - Firewall rules need to be manipulatable based on role settings
14:07:23 <sgallagh> We've discussed this quite a bit previously.
14:07:55 <sgallagh> I don't think it's urgent for F23, though
14:08:13 <twoerner> no.. I think this is good for 24-alpha
14:08:19 <sgallagh> #idea Fedora 24 Alpha, Blocker
14:08:23 <twoerner> +1
14:08:30 <nphilipp> +1
14:08:51 <sgallagh> OK, which of you wants this one?
14:09:02 <sgallagh> #agreed Fedora 24 Alpha, Blocker
14:09:04 <twoerner> we can leave that open still
14:09:16 <sgallagh> ok
14:09:20 <sgallagh> Fine by me
14:09:23 <twoerner> let's take care about 23 for now
14:09:50 <sgallagh> #topic https://github.com/libre-server/rolekit/issues/8 - Implement the update() routine for all currently-supported roles
14:10:50 <sgallagh> #idea Fedora 24 Alpha, Nice-to-have
14:11:14 <nphilipp> I have no idea how much work this is, but f24 nice to have sounds right
14:11:18 <nphilipp> *alpha
14:11:19 <nphilipp> +1
14:11:33 <twoerner> should this update also be working without interaction after a F-X to F-X+1 upgrade?
14:11:56 <twoerner> I am for example thinking about the mysqldb to mariadb upgrade
14:11:59 <sgallagh> twoerner: Can we talk about that another time?
14:12:02 <twoerner> ok
14:12:04 <twoerner> sure
14:12:05 <twoerner> +1
14:12:13 <sgallagh> I think that's a longer topic than we want to spend right now :)
14:13:00 <sgallagh> #agreed Fedora 24 Alpha, Nice-to-have
14:13:28 <sgallagh> Let's skip over any that I have labeled "Help Wanted" (which indicates that we need help outside the core team)
14:13:36 <sgallagh> This is usually a "New Role:" issue.
14:14:00 <sgallagh> #topic https://github.com/libre-server/rolekit/issues/13 - Refactoring: handle settings in roles more simply
14:14:16 <sgallagh> This is kind of a long-term goal
14:14:17 <nphilipp> no help needed for #9?
14:14:39 <twoerner> this is there already ..
14:14:40 <sgallagh> I'd love for us to have a factory of some sort to help generate settings for roles.
14:14:41 <nphilipp> ahh reloading clears this up
14:14:41 <twoerner> just reload
14:14:52 <sgallagh> nphilipp: Sorry, I added it after the meeting started
14:14:56 <nphilipp> no worries
14:15:29 <twoerner> ok.. with the use of properties in dbus-python this is more complicated
14:15:47 <sgallagh> twoerner: I wonder how much of this gets easier with one of the new dbus implementations (or harder)
14:15:49 <twoerner> with using dbus-python without the properties patch this is very simple
14:16:10 <nphilipp> I like how e.g. SQLAlchemy, or ToscaWidgets let you simply declare such stuff
14:16:22 <twoerner> sgallagh: it will not be easier.. as the accessors and mutators need to be defined in a good way
14:16:32 <twoerner> nphilipp: ohh.. tell me
14:17:04 <nphilipp> lemme scare up an example
14:17:43 <sgallagh> Let's not implement it here.
14:17:53 <sgallagh> The important part today is deciding how important solving this is.
14:18:12 <nphilipp> okie
14:18:15 <twoerner> I have had a look at the PyQt DBus  stuff and this is not simpler than the things we have.. I even found some still unclear things.. I have to investigate further
14:18:22 <sgallagh> I'm inclined to defer it for a while until our features are settling down, but I can see how it's also an impediment to third-party role creation
14:18:55 <twoerner> yes, I agree
14:19:03 <nphilipp> yup
14:19:29 <sgallagh> Maybe we can talk a "Help Wanted" label on this and see if the DevAssistant guys could help with this
14:20:46 <sgallagh> s/talk/tack/
14:21:13 <sgallagh> #idea Defer until other things settle down, ask DevAssistant devs if an assistant could mitigate this
14:21:26 <nphilipp> +1
14:21:28 <twoerner> +1
14:21:50 <sgallagh> #agreed Defer until other things settle down, ask DevAssistant devs if an assistant could mitigate this
14:22:43 <sgallagh> #topic https://github.com/libre-server/rolekit/issues/14 - Add support for deploying roles using the nulecule specification
14:22:53 <sgallagh> #idea Fedora 23 Beta, Nice-to-have
14:23:15 <sgallagh> This is another piece of the nulecule puzzle which I've already said I'm working on in the hopes of hitting Beta
14:23:34 <twoerner> this depends on the other one
14:23:40 <sgallagh> yes
14:23:41 <twoerner> right?
14:24:00 <twoerner> +1
14:24:05 <twoerner> for ice-to-have
14:24:08 <nphilipp> +1
14:24:09 <twoerner> for nice-to-have
14:24:23 <sgallagh> #agreed Fedora 23 Beta, Nice-to-have
14:24:48 <sgallagh> tpokorra: BTW, just saw your comments on the Kolab one. Let's discuss that soon :)
14:24:49 <twoerner> 15 should be "help wanted" also
14:25:06 <nphilipp> yup
14:25:29 <sgallagh> #topic https://github.com/libre-server/rolekit/issues/16 - Delete systemd helper unit files on decommission
14:25:37 <sgallagh> #idea Fedora 23 Final, Blocker
14:25:41 <twoerner> +1
14:25:54 <nphilipp> +1
14:26:06 <sgallagh> I'll take this one myself
14:26:15 <sgallagh> #agreed Fedora 23 Final, Blocker
14:27:00 <sgallagh> #topic https://github.com/libre-server/rolekit/issues/17 - Refactor systemd unit file creation to use python-systemdunit
14:27:13 <twoerner> systemdunitparser is pathon3 onle?
14:27:16 <twoerner> python3
14:27:18 <twoerner> only
14:27:18 <sgallagh> Let's skip over this one; this is related to the patch I'm sending to python-systemd
14:27:24 <twoerner> ok
14:27:25 <twoerner> +1
14:27:28 <sgallagh> So this upstream is going to die off
14:28:07 <sgallagh> That said, we're still going to want to convert over to this approach (using SystemdUnitParser objects rather than the silly target dictionaries)
14:28:16 <nphilipp> yup
14:28:18 <sgallagh> So I'll update this ticket once that patch lands in python-systemd
14:28:21 <twoerner> yes
14:28:40 <sgallagh> #agreed Defer until needed patches land in python-systemd
14:28:51 <twoerner> the only concern I have it for python2 support
14:29:08 <sgallagh> twoerner: The patch we're working on in python-systemd will support both
14:29:12 <twoerner> this is something we should not loose for RHEL-7 or CentOS7
14:29:28 <sgallagh> Zbigniew came up with an approach that works better and is language-version-agnostic
14:29:37 <twoerner> ok, great
14:29:38 <sgallagh> I'm going to be testing it after this meeting, then it should go upstream today hopefully
14:29:58 <sgallagh> #topic https://github.com/libre-server/rolekit/issues/18 - Role deploy, decommission, etc. needs progress updater
14:30:40 <sgallagh> Lack of this is a serious impediment to inclusion in Cockpit
14:30:54 <twoerner> this is something that will need some work in the roles also to provide progress information in a more fine grained manner
14:31:24 <nphilipp> do we have infrastructure already where someone developing a role could say how far e.g. deployment has come?
14:31:26 <sgallagh> For the record, this doesn't need to necessarily be a progress bar, but we need to be able to get some information and feed it back
14:31:36 <sgallagh> nphilipp: No
14:32:00 <sgallagh> Let's not design this here, but I'd really like to see this be a major piece of F24 alpha
14:32:14 <twoerner> ok.. this is ok for me
14:32:21 <sgallagh> #idea Fedora 24 Alpha, Blocker
14:32:24 <twoerner> +1
14:32:26 <nphilipp> +1
14:32:30 <sgallagh> This will probably be a group effort
14:32:36 <twoerner> oh yes
14:32:40 <nphilipp> I think so too
14:32:53 <nphilipp> or at least, it won't be trivial
14:33:21 <sgallagh> #topic https://github.com/libre-server/rolekit/issues/19 - 'rolectl settings <role>' should list mandatory and optional settings for deployment
14:34:12 <sgallagh> #idea Fedora 24 Alpha, Nice-to-have
14:34:20 <nphilipp> sounds good to me
14:34:21 <nphilipp> +1
14:34:21 <twoerner> +1
14:34:41 <sgallagh> #agreed Fedora 24 Alpha, Nice-to-have
14:35:02 <sgallagh> #topic https://github.com/libre-server/rolekit/issues/20 - Handle the "__NULL__" responses gracefully
14:35:43 <sgallagh> This was inherited from a bug I had in the old Trac.
14:35:59 <sgallagh> I've since begun to care significantly less about it.
14:36:10 <sgallagh> #idea Close as wontfix until someone complains
14:36:14 <nphilipp> +1
14:36:34 <twoerner> this might simply be a dbus exception also
14:36:41 <sgallagh> hmm?
14:37:11 <twoerner> ohh now
14:37:13 <twoerner> no
14:37:14 <sgallagh> twoerner: It was originally an exception and that broke things
14:37:26 <twoerner> yes, now I remember
14:37:41 <twoerner> +1 for now
14:37:43 <sgallagh> But having it return the empty string wasn't good either, since that's a valid value
14:37:52 <sgallagh> #agreed Close as wontfix until someone complains
14:38:25 <sgallagh> #topic https://github.com/libre-server/rolekit/issues/21 - Check for .rksave files if the 'sed' fails in the DB role deploy.
14:38:33 <sgallagh> #idea Fedora 23 Final, Nice-to-have
14:38:37 <sgallagh> I'll self-assign this.
14:38:42 <twoerner> +1
14:38:44 <nphilipp> +1
14:39:02 <sgallagh> #agreed Fedora 23 Final, Nice-to-have
14:39:27 <sgallagh> #topic https://github.com/libre-server/rolekit/issues/22 - Enable translations of documentation and help text
14:39:40 <sgallagh> #idea Fedora 24 beta, Nice-to-have
14:39:55 <twoerner> as the translation deadline is not far away this is 24-alpha.. yes
14:40:03 <nphilipp> +1
14:40:11 <twoerner> blocker in my opinion
14:40:28 <sgallagh> twoerner: How about 24 Alpha NTH, 24 Beta Blocker?
14:40:29 <twoerner> otherwise we will also not have translations in 24
14:40:40 <twoerner> string freeze is alpha
14:40:47 <sgallagh> oh, right.
14:40:50 <twoerner> so.. this needs to be fixed at alpha
14:40:58 <sgallagh> #idea Fedora 24 Alpha, Blocker
14:41:07 <nphilipp> +1
14:41:10 <sgallagh> actually no
14:41:13 <sgallagh> Let's make it NTH
14:41:14 <nphilipp> ?
14:41:17 <twoerner> but on the other hand we can not do major updates then for beta anymore
14:41:21 <sgallagh> If we can get it done, we do it by then
14:41:29 <sgallagh> Otherwise we re-prioritize
14:41:40 <twoerner> ok,
14:41:41 <twoerner> +1
14:41:42 <sgallagh> I'm not sure the translations are that critical for a service that is mostly intended to be consumed by other UIs
14:41:48 <twoerner> for nice-to-have
14:41:48 <nphilipp> +1
14:42:06 <nphilipp> for NTH, yes
14:42:07 <sgallagh> #agreed Fedora 24 Alpha, Nice-to-have
14:42:42 <sgallagh> #topic https://github.com/libre-server/rolekit/issues/24 - Convert rolekit to different dbus implementation
14:43:13 <twoerner> this will require some work and lots of tests.. therefore this is nothing for 23 in my optinion
14:43:16 <twoerner> opinion
14:43:18 <sgallagh> #idea Fedora 24 Alpha, Blocker
14:43:26 <sgallagh> Yeah, absolutely not for F23.
14:43:27 <nphilipp> twoerner: I concur
14:44:18 <twoerner> this also could have some side effects .. we need to carefully test
14:44:41 <sgallagh> s/could/will/ ;-)
14:45:01 <twoerner> yes ;-)
14:45:15 <sgallagh> I think we have to do it for F24 though. I don't think python-dbus maintainers will keep our patches forever.
14:45:22 <twoerner> yes
14:45:32 <sgallagh> So votes?
14:45:33 <twoerner> but we could have some iterations
14:45:36 <sgallagh> True
14:46:05 <sgallagh> twoerner: Feel free to #idea a counter-proposal :)
14:46:20 <twoerner> I m not sure about alpha blocker.. it surely needs to be done by beta
14:46:43 <nphilipp> alpha nth, beta blocker?
14:46:52 <twoerner> #idea Fedora 24 Alpha, Nice-to-have - #idea Fedora 24 Beta, Blocker
14:47:09 <twoerner> ohh this is wrong syntax isn't it?
14:47:20 <sgallagh> twoerner: No worries
14:47:23 <sgallagh> +1
14:47:31 <nphilipp> +1
14:47:33 <twoerner> +1
14:48:13 <sgallagh> I'm just setting it to Fedora 24 blocker. If it arrives earlier, that's fine :)
14:48:18 <sgallagh> err beta blocker
14:48:27 <twoerner> ok, agree
14:49:05 <twoerner> #25 should be closed already, right?
14:49:24 <sgallagh> Yeah, just closed it
14:49:32 <twoerner> and 26 "help wanted"
14:49:39 <sgallagh> yes
14:49:49 <sgallagh> #topic https://github.com/libre-server/rolekit/issues/28 - redeploy should accept JSON settings via stdin as well
14:50:01 <sgallagh> I'll fix it today, but
14:50:11 <twoerner> but?
14:50:11 <sgallagh> #idea Fedora 24 Final, Blocker
14:50:17 <twoerner> 24?
14:50:21 <sgallagh> Whoops
14:50:24 <sgallagh> #undo
14:50:24 <zodbot> Removing item from minutes: IDEA by sgallagh at 14:50:11 : Fedora 24 Final, Blocker
14:50:28 <sgallagh> #idea Fedora 23 Final, Blocker
14:50:31 <nphilipp> +1
14:50:31 <twoerner> +1
14:50:32 <sgallagh> (nobody saw that, right?)
14:50:48 <twoerner> nope :-P
14:51:19 <twoerner> we are done!
14:51:22 <twoerner> hurray!
14:51:31 <nphilipp> nobody saw what?
14:52:15 <sgallagh> nphilipp: So I just realized you don't have any bugs assigned for F23 beta or final
14:52:37 <sgallagh> Want to take 16 or 21? Both should be fairly easy.
14:52:43 <nphilipp> sgallagh: I fixed mine  already :)
14:53:00 <nphilipp> sgallagh: sure
14:53:30 <sgallagh> and/or 28
14:53:39 <sgallagh> Self-assign whichever ones interest you
14:53:45 <nphilipp> yup that one sounds doable as well
14:53:48 <nphilipp> how can I self assign?
14:54:14 <sgallagh> nphilipp: Go into the bug and set the assignee to yourself
14:54:20 <sgallagh> You should be able to do that, I think
14:54:28 <nphilipp> sgallagh: no I can't
14:54:30 <sgallagh> If not, let me know which ones you want
14:54:37 <nphilipp> sgallagh: because you don't trust me :o)
14:54:50 <twoerner> he does not have the permissions, yet
14:55:04 <sgallagh> twoerner: We haven't put him through initiation yet. ;-)
14:55:10 <nphilipp> sgallagh: I'd just work through them numerically
14:55:15 <twoerner> har!!!
14:55:31 <twoerner> .-)
14:55:41 <nphilipp> I don't think they are that much different re: prio, and effort
14:56:00 <twoerner> sgallagh: what do you have in mind?
14:56:13 <sgallagh> nphilipp: I assigned you all three. We can change it later if needed.
14:56:18 <nphilipp> yup
14:56:46 <sgallagh> twoerner: I think this joke could get very dangerous, very quickly.
14:57:17 <sgallagh> #topic Open Floor
14:57:21 <sgallagh> Anything for open floor?
14:57:40 <sgallagh> Sorry to have run this meeting so long, but hopefully it should be rare to have so many tickets to go through at once
14:57:57 <sgallagh> Oh, I won't be able to attend next week's meeting (I'll be enroute to Flock)
14:58:09 <twoerner> ok
14:58:23 <twoerner> then we might have no meeting or talk here in the office if needed
14:58:24 <sgallagh> Could one of you run a status update meeting in my absence? I'll read the logs when I get to my hotel.
14:58:29 <nphilipp> yeah let's not open issues if we can help it (/jk)
14:58:39 <sgallagh> If there's nothing to discuss, that's cool too
14:58:41 <simo> sgallagh: not on fedora-meeting-1 ?
14:58:53 <sgallagh> simo: This is the rolekit meeting
14:59:03 <sgallagh> The Server SIG meeting will be in the usual place in a few minutes.
14:59:07 <simo> ops
14:59:44 <sgallagh> OK, closing the meeting. Thanks for suffering through it!
14:59:54 <nphilipp> :)
14:59:57 <sgallagh> #endmeeting