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