14:32:09 <sgallagh> #startmeeting rolekit (2015-12-08)
14:32:09 <zodbot> Meeting started Tue Dec  8 14:32:09 2015 UTC.  The chair is sgallagh. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:32:09 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
14:32:09 <zodbot> The meeting name has been set to 'rolekit_(2015-12-08)'
14:32:09 <sgallagh> #meetingname rolekitweekly
14:32:09 <sgallagh> #chair sgallagh twoerner nilsph
14:32:09 <sgallagh> #topic init process
14:32:09 <zodbot> The meeting name has been set to 'rolekitweekly'
14:32:09 <zodbot> Current chairs: nilsph sgallagh twoerner
14:32:16 <twoerner> .hello twoerner
14:32:17 <zodbot> twoerner: twoerner 'Thomas Woerner' <twoerner@redhat.com>
14:32:27 <sgallagh> .hello sgallagh
14:32:28 <zodbot> sgallagh: sgallagh 'Stephen Gallagher' <sgallagh@redhat.com>
14:32:39 <sgallagh> nils: You around?
14:32:47 <sgallagh> (Also, stop changing nicks :-P)
14:32:48 <nils> .hello nphilipp
14:32:49 <zodbot> nils: nphilipp 'Nils Philippsen' <nphilipp@redhat.com>
14:32:58 <sgallagh> #chair nils
14:32:58 <zodbot> Current chairs: nils nilsph sgallagh twoerner
14:33:03 <nils> sgallagh: heh, I had to secure "my" nick once it was available :)
14:33:20 <nils> sorry for the delay, needed to grab something to drink
14:33:37 <sgallagh> No worries
14:33:44 <sgallagh> #topic Agenda
14:34:00 <sgallagh> #info Agenda Item: Containerized Domain Controller role
14:34:03 <sgallagh> other items?
14:34:34 <nils> not from my side
14:35:01 <twoerner> not from me
14:35:39 <sgallagh> #topic Containerized Domain Controller role
14:36:40 <sgallagh> So, for the last few working days, I've been looking at reworking the Domain Controller role to run off of the semi-official Docker container that upstream has out (built atop Fedora 23)
14:37:21 <sgallagh> In the process, I've been somewhat reworking how the SystemdContainerUnit class works; I should have some groundwork patches out for review today or tomorrow
14:38:12 <sgallagh> The advantage I see with this is that we (Fedora) should be less vulnerable to upgrades breaking our stack, since the FreeIPA image can be tested as a complete unit, rather than a summation of many packages.
14:39:10 <sgallagh> It will also mean that we can maintain a repository of domain controller images based on upstream version, rather than necessarily what is the latest RPM in Fedora
14:39:34 <sgallagh> (So a user can choose their migration schedule separately from their OS upgrade schedule)
14:41:46 <twoerner> nice
14:41:47 <sgallagh> I think this will also provide a good way to actually implement the update() mechanism for this role
14:43:33 <sgallagh> I'm expecting this to be ready for review before the Red Hat holiday shutdown
14:45:58 <sgallagh> My work-in-progress is being kept at https://github.com/sgallagher/rolekit/tree/dc-container (regularly force-pushed) if anyone is interested in perusing it
14:46:21 <sgallagh> So that's all I have on this topic for now.
14:46:29 <sgallagh> #topic Holiday Vacation Plans
14:46:37 <sgallagh> When are you folks planning to take time off?
14:48:51 <sgallagh> twoerner, nils?
14:48:54 <nils> Probably only Christmas Eve and New Years Eve for me, thanks to German vacation laws I don't have to take time off when my wife is working. Time to work on some backlog between the holidays. I'll probably make up for it in early 2016.
14:48:58 <twoerner> I think I will be unavailable from 23rd/24th to 1st
14:49:46 <twoerner> hmm. that would be a good idea also..
14:50:50 <sgallagh> Yeah, I'm likely to take the 24th until the new year
14:51:30 <sgallagh> OK, so all the bugs go to nils for December :-D
14:51:34 <nils> haha
14:52:06 <sgallagh> #info sgallagh will be on vacation from Dec. 24th, returning Jan. 4th
14:52:11 <twoerner> that is a nice idea.-)
14:52:57 <sgallagh> #info nils will be on vacation Dec. 24th and 25th and taking vacation in early 2016
14:53:56 <nils> for not yet defined values of "early", depends on some other folk
14:54:03 <sgallagh> ok
14:54:29 <sgallagh> I'm lucky in that my wife works in a school system, so her mandatory vacation matches shutdown :)
14:54:37 <nils> heh
14:54:52 <twoerner> that is nice
14:55:11 <sgallagh> #topic Status Update
14:55:16 <nils> my wife works in the German healthcare system, so...
14:55:27 <sgallagh> #info See Containerized Domain Controller role for sgallagh update
14:55:55 <nils> I submitted some reviews, the most notable is about rudimentary documentation for custom roles.
14:55:57 <sgallagh> twoerner: Mind doing a #info on what you've done lately?
14:56:01 <nils> Curiously, it even worked.
14:56:11 <sgallagh> err, that was supposed to be "twoerner, nils:"
14:56:23 <nils> okay I'll start making it formal
14:56:38 <sgallagh> nils: What was curious?
14:56:46 <twoerner> #info started to work on issue#7
14:56:52 <nils> sgallagh: that it worked
14:56:55 <nils> :)
14:57:18 <sgallagh> nils: Ambiguous statement: submitting the reviews worked or the custom roles worked? :)
14:57:24 <nils> I suspected some hidden pitfall after last time we talked about the topic
14:57:39 <nils> This is natural language, it's full of ambiguity :P
14:58:20 <nils> #info Added some documentation for adding custom roles, and fixes for some minor nits I found.
14:58:34 <sgallagh> nils: Well, we know that dropping files in the right place works... we need documentation on what that file needs to contain and how it works.
14:58:41 <sgallagh> And API docs for the common helper routines we write.
14:59:11 <sgallagh> Thanks, nils. I'll finish the reviews on those today.
14:59:25 <nils> So it needs to go in the rolekit.roles XML/man page, right?
14:59:57 <sgallagh> nils: I think it might actually be acceptable for it to be a Markdown document and not part of the man pages
15:00:04 <nils> okay.
15:00:10 <sgallagh> The API stuff maybe belongs in the man pages
15:00:59 <sgallagh> nils: OK, thanks.
15:01:06 <sgallagh> twoerner: Could you elaborate a bit on the firewall work?
15:01:47 <twoerner> I started some minutes before the meeting.. nothing ready yet
15:02:23 <twoerner> I have some question though
15:02:27 <twoerner> questions
15:03:32 <sgallagh> Sure, go ahead
15:03:47 <twoerner> the firewall requirements in _SETTINGS should still be visible in the initial form after deployment, right?
15:04:07 <twoerner> a new setting key will be needed for applied settings
15:05:16 <twoerner> and the firewall settings will only be made if custom_firewall is not set
15:05:28 <sgallagh> twoerner: I'm not actually sure.
15:06:04 <sgallagh> Realistically, the firewall in _SETTINGS should probably be like the packages: they're what's needed for the *deployment*, not necessarily the runtime.
15:06:21 <twoerner> we already have firewall-changes for the applied firewall changes in _SETTINGS
15:07:56 <sgallagh> OK
15:08:13 <sgallagh> I think maybe that the only part that needs to be visible is the firewall_changes.
15:08:37 <sgallagh> Because it might be confusing to see both (especially if they differ)
15:09:14 <twoerner> but it also might be good to see if the default firewall settings are applied or not
15:10:06 <twoerner> something that is missing in the issue is that there will be some offset for the ports
15:10:13 <twoerner> if requested
15:11:09 <sgallagh> twoerner: I'm trying to say that this should not be considered the "Default"
15:11:28 <twoerner> yes.. then we need a switch to enable this
15:11:45 <sgallagh> That the value of that field actually shouldn't be visible *ever*. That it's only internal data.
15:11:58 <sgallagh> And that the end-user should only ever see the actual changes
15:12:44 <twoerner> how should the user know the mapping of the ports?
15:13:19 <twoerner> if you are for example mapping several services (ftp, dns, ssh) to other ports
15:13:59 <twoerner> then the user should know which one is used for the services
15:14:19 <twoerner> s/which one/which/
15:15:01 <sgallagh> hmm
15:15:53 <sgallagh> That's a hard question.
15:15:55 <twoerner> with a fixed offset it might be simpler - but if ports are low..
15:16:17 <sgallagh> Maybe we "cheat" and just say we only support arbitrary ports for services that only present a single port.
15:16:23 <twoerner> but if available ports are low..
15:16:32 <sgallagh> s/arbitrary ports/arbitrary port selection/
15:16:32 <twoerner> wow
15:16:45 <twoerner> that is not working for lots of things
15:16:56 <sgallagh> twoerner: Yeah :(
15:17:13 <sgallagh> Well, maybe not
15:17:28 <sgallagh> I mean, most services that require multiple ports are going to rely on well-known ports, aren't they?
15:18:15 <twoerner> this depends on the use case
15:18:47 <twoerner> if you are mapping the ports internally only to be able to have different roles talking to each other, then it might not be an issue
15:18:53 <sgallagh> twoerner: OK, another simplifying assumption then:
15:19:57 <sgallagh> We don't solve this generically for the roles. Instead, if a role wants to specify a specific port for a service, they have to have an explicit setting for it.
15:20:25 <sgallagh> And then we just build a helper routine that opens the appropriate port and adjusts firewall_changes appropriately.
15:21:20 <twoerner> I would say, that this is similar to what we have right now
15:21:21 <sgallagh> So the role creator has to call `add_port(port, zone=None)`
15:22:46 <sgallagh> twoerner: Not exactly. At the very least, we should stop displaying the firewall and custom_firewall setting
15:22:57 <sgallagh> And only show the actual effective changes afterwards.
15:23:28 <twoerner> ok
15:23:54 <twoerner> right now we only show the default for the firewall configuration, as these are applies
15:23:57 <twoerner> applied
15:24:24 <sgallagh> Right... my thought is that this probably isn't useful information
15:24:25 <twoerner> and the applied firewall settings are hidden as they only show the changes that have been done
15:24:40 <twoerner> as these are the settings we need to revert
15:24:44 <twoerner> ye, but
15:25:11 <twoerner> what do we do with roles that require to open a port up, that is already open?
15:25:38 <twoerner> it is not opened up be the role, therefore it should not be closed by decommissioning
15:25:58 <twoerner> but it might be visible as open to the role
15:26:07 <sgallagh> twoerner: OK, so maybe we have two values: firewall_current and firewall_changes
15:26:16 <twoerner> yes
15:26:16 <sgallagh> The latter is hidden and used only for decommission
15:26:37 <sgallagh> firewall_current may be a superset (but never a subset) of firewall_changes.
15:26:39 <sgallagh> Sound sensible?
15:27:05 <twoerner> yes
15:27:20 <sgallagh> Actually, maybe we can just reuse the older 'firewall' name instead of firewall_current.
15:27:38 <sgallagh> And just display it as empty in the undeployed role settings
15:28:03 <twoerner> ok.. but please keep in mind that we need the old firewall settings to be able to provide the needed firewall settings to the user before deploy
15:28:20 <sgallagh> twoerner: Sorry, why?
15:28:56 <sgallagh> Or you mean that it would be telling the user ahead of time what is going to happen to the firewall, assuming no manual changes?
15:29:15 <twoerner> sgallagh: we have all requirements visible for all roles even if they are not deployed
15:29:16 <twoerner> yes
15:29:19 <sgallagh> I'm not sure that's useful information from the API. Certainly worthwhile to have in the man pages.
15:29:39 <sgallagh> But I don't feel strongly
15:29:46 <twoerner> but then we can also hide all other default settings
15:29:52 <twoerner> like services
15:29:54 <twoerner> packages
15:30:05 <sgallagh> twoerner: That was actually going to be my next statement :)
15:30:14 <twoerner> really?
15:30:17 <sgallagh> Yes
15:30:22 <twoerner> uhh
15:30:33 <twoerner> why?
15:30:34 <sgallagh> We probably only need to inform users of the settings that we want them to twiddle
15:30:44 <sgallagh> What we do internally isn't really relevant to them
15:31:41 <sgallagh> Actually, 'services' is also not used anymore, so we should scrap that completely.
15:31:56 <sgallagh> (Since we now wrap everything in the role-rolename-instancename.service file)
15:32:15 <sgallagh> err, s/.service/.target/
15:33:23 <twoerner> it lacks some transparency then in my opinion
15:33:34 <sgallagh> "packages" actually just means the packages needed to do deployment (for example, the memcache role just needs docker and does the deployment with images after that)
15:33:58 <sgallagh> That's useful information for the role implementation, but the end-user shouldn't care
15:33:59 <twoerner> yes
15:34:41 <twoerner> shouldn't is good, but it might be goo to know if there are several roles at some point doing similar things
15:34:52 <sgallagh> twoerner: similar how/
15:35:15 <twoerner> dns servers as an example.. named or another one
15:36:02 <twoerner> but if that is not important.. ok..
15:36:58 <sgallagh> twoerner: I'm dropping that firmly in the category of "the admin has to have a minimal level of knowledge of what they're deploying"
15:38:04 <twoerner> ok.. but how - if the information is not visible?
15:39:22 <twoerner> as a bad example: "dns", "dns1", "dns2"
15:39:51 <sgallagh> twoerner: Well, their deployment is going to fail when we can't open the requested port
15:40:48 <twoerner> yes, but without getting information on the role before deploying it..
15:41:07 <twoerner> "life is like a box of chocolate, you never know what you get" :-)
15:41:20 <sgallagh> twoerner: I think it's a bit optimistic to assume that people are going to use the rolekit API to find out what port "DNS" uses
15:42:51 <twoerner> I am talking about removing the packet, service and firewall configuration settings form the defaults
15:43:33 <twoerner> with creating this information while deploying there will not be any information for roles that are not deployed
15:45:19 <sgallagh> Actually, the package and service values at least should remain invisible *after* deployment as well, I think
15:45:41 <sgallagh> 'service' isn't a feature we use at all anymore. It's vestigial.
15:46:04 <sgallagh> And packages are internal information that may not be actually relevant, particularly in container casess
15:46:16 <twoerner> ok
15:46:43 <sgallagh> I mean, if all of our "packages" attributes just show "python3-docker", that's not giving anyone useful info :)
15:47:07 <sgallagh> If you want to argue that we should also report the image or nulecule name back, we can add that
15:47:10 <sgallagh> I could buy that
15:47:12 <twoerner> yes, not in the docker case.. but it might give information about the source of the docker images instead
15:48:29 <twoerner> just a but of transparency...
15:49:12 <twoerner> s/but/bit/
15:49:22 <twoerner> ok.. let's stop this here
15:49:53 <sgallagh> Yeah, I've got to run the Server SIG meeting in 10 minutes too
15:50:34 <sgallagh> twoerner: For now, how about we just suppress this information and add it back later once we've shaken out how everything else works.
15:50:43 <danofsatx> yay, I arrived in time for at least one meeting today
15:51:05 <sgallagh> Technically two, as I haven't yet done #endmeeting on rolekit
15:51:12 <twoerner> ok,
15:51:37 <sgallagh> twoerner: Basically, I view incomplete information as worse than none.
15:51:46 <sgallagh> Or at least, misleading
15:52:24 <sgallagh> twoerner: OK, let's call it a meeting. Thanks for the discussion.
15:53:04 <twoerner> thanks also
15:53:25 <sgallagh> #endmeeting