14:30:45 <sgallagh> #startmeeting rolekit (2016-01-05)
14:30:45 <zodbot> Meeting started Tue Jan  5 14:30:45 2016 UTC.  The chair is sgallagh. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:30:45 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
14:30:45 <zodbot> The meeting name has been set to 'rolekit_(2016-01-05)'
14:30:45 <sgallagh> #meetingname rolekitweekly
14:30:45 <sgallagh> #chair sgallagh twoerner nilsph
14:30:45 <sgallagh> #topic init process
14:30:45 <zodbot> The meeting name has been set to 'rolekitweekly'
14:30:45 <zodbot> Current chairs: nilsph sgallagh twoerner
14:30:51 <twoerner> .hello twoerner
14:30:53 <zodbot> twoerner: twoerner 'Thomas Woerner' <twoerner@redhat.com>
14:30:54 <sgallagh> Happy New Year, rolekitters
14:30:59 <sgallagh> rolekittens?
14:31:10 <sgallagh> rolekites?
14:31:18 <twoerner> hmmm...
14:31:25 <twoerner> Happy new year
14:31:28 <nils> .hello nphilipp
14:31:29 <zodbot> nils: nphilipp 'Nils Philippsen' <nphilipp@redhat.com>
14:31:56 <nils> rolecritters?
14:32:18 <sgallagh> nils++
14:32:19 <twoerner> hide the water
14:32:50 <sgallagh> #topic Agenda
14:33:41 <sgallagh> OK, so I don't have much of a formal agenda this week
14:33:51 <sgallagh> twoerner wanted to discuss firewalling
14:34:00 <twoerner> yes, this is on my agenda
14:34:04 <sgallagh> #info Agenda Item: Firewall management in rolekit
14:34:24 <twoerner> I am not sure about the final decisions on firewall management in rolekit
14:34:29 <sgallagh> nils: Do you want to talk again about your third-party role creation work?
14:35:35 <nils> yeah, I wanted you guys to look at how I want to implement role parameters/settings.
14:35:53 <nils> I have some code, but it doesn't work yet :)
14:35:54 <sgallagh> #topic Agenda Item: Third-party Role Creation
14:35:55 <twoerner> ok.. this interferes with the firewall work
14:35:59 <nils> yes
14:36:09 <sgallagh> OK, do we want to cover this in reverse order, then?
14:36:15 <nils> another reason why I wanted you to pass this by you
14:36:21 <twoerner> yes, please
14:36:33 <sgallagh> #topic Third-Party Role Creation
14:36:43 <sgallagh> #undo
14:36:43 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x7f4747ef3c50>
14:36:45 <sgallagh> #undo
14:36:45 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x7f4759a8c4d0>
14:36:50 <sgallagh> #info Agenda Item: Third-party Role Creation
14:36:52 <sgallagh> #topic Third-Party Role Creation
14:37:01 <sgallagh> nils: You have the floor
14:37:45 <nils> okay, so here's how imagine what I'm working on should be used, i.e. when writing a Role class: https://gist.github.com/nphilipp/2f3c533ba4e22c4301e2
14:39:03 <nils> every new parameter gets defined on the class as a RoleParam (RoleParamList, RoleParameters) object. Values can be simply set on child classes without giving that fact much attention (see the database Role example)
14:40:40 <nils> I'd also like to differentiate a bit between real settings and "state" variables (like "lasterror", "state", ...) which are more tied to the internal implementation and not to how a user deals with a role.
14:41:47 <twoerner> how do you plan to differentiate?
14:41:51 <nils> One thing I didn't particularly like about the old way of things was that you had to set both ports and services of firewall, even if one of both was empty.
14:42:02 <nils> But I guess we'll discuss changes there later :).
14:42:43 <sgallagh> nils: Will RoleParam accept a validator function as well?
14:43:04 <nils> twoerner: one way could be to have different classes for each, e.g. RoleParam and RoleVariable. Both would be (de)serialized to and from JSON, but only Params would be displayed to the user.
14:43:16 <nils> sgallagh: yes, that's my intention
14:43:42 <sgallagh> nils: I think that would be better than the minval/maxval stuff, for example.
14:43:48 <sgallagh> We could provide a couple standard validators
14:43:51 <nils> sgallagh: I called it constraint, but so far nothing regarding names is very much set in stone :)
14:44:00 <nils> ahh yes
14:44:03 <sgallagh> Constraint is fine.
14:44:17 <nils> validator is fine, too
14:44:32 <nils> I have no real preference.
14:44:42 <sgallagh> twoerner: Break the tie? ;-)
14:44:51 <twoerner> nils: what means sensitive here?
14:44:54 <nils> Or come up with a third name :o)
14:45:03 <twoerner> visible like in UIs?
14:45:06 <nils> twoerner: sensitive data that can be scrubbed from the instance, like a password
14:45:07 <sgallagh> twoerner: I am assuming it means "things that would be cleared when sanitize() is called"
14:45:13 <nils> yep
14:45:46 <twoerner> why not using sanitizable then?
14:45:59 <twoerner> then it would match with name
14:46:17 <sgallagh> twoerner: I think I like 'sensitive' better here, actually.
14:46:21 <sgallagh> Because it implies two things:
14:46:22 <nils> I don't think "sanitizable" is very descriptive or intuitive.
14:46:36 <sgallagh> 1) If passed in explicitly, it won't be saved to the settings.json
14:46:45 <sgallagh> 2) If auto-generated, it will be cleared by sanitize()
14:46:52 <nils> yes
14:47:10 <twoerner> ok
14:47:49 <twoerner> there will be mutators that will automatically update the settings.json file on insensitive changes?
14:48:00 <nils> note to self: need to differentiate between auto-generated and explicitly set "sensitive" data
14:48:02 <sgallagh> twoerner: Sorry, can you give an example?
14:49:57 <twoerner> most of the firewall setting will be writeable later on to make port changes or assignments possible. Will self.firewall["ports"]["tcp"] = 23 automatically update the settings.json file?
14:51:31 <twoerner> or will it be needed to call the self.write_settings() or similar?
14:51:57 <sgallagh> twoerner: Well, we only call write_settings() at the end of processing for a call
14:52:12 <sgallagh> We don't do it midway through a deploy(), for example
14:52:40 <nils> I haven't thought about how it should be done. I think it's better to explicitly write (once), rather than write every time a setting is touched.
14:52:59 <sgallagh> Well, write once per D-BUS call at least.
14:53:14 <twoerner> if we have more dynamic ports I need to make sure that the changes, that I have done already are saved somewhere even in case of roled dying to be able to revert again
14:53:17 <sgallagh> If we decide to add a ModifyFirewall() method, for example...
14:53:20 <nils> ...that changed something.
14:54:00 <twoerner> but we might ignore this also
14:54:30 <sgallagh> twoerner: In an ideal world, I think we'd have rolekit create a custom chain and, upon startup, ensure that the running chain matches what rolekit thinks it is
14:54:42 <sgallagh> That way if it crashed partway through processing, it would at least restore the old state
14:55:59 <twoerner> ok.. I think I like the new settings
14:56:13 <nils> now I only need to get them working
14:56:15 <nils> :)
14:56:35 <twoerner> ok... one more
14:56:53 <twoerner> if I change a setting, is there a way to get the default back again?
14:57:33 <twoerner> is there a default value at all?
14:57:58 <nils> I thought about that, and there are a couple of ways the API could look like.
14:57:59 <twoerner> I can see it for database
14:58:28 <nils> For instance, an explicit method: somerole.someparam.unset()
14:58:40 <twoerner> but the question is if services = "postgresql.service" is seen as a default
14:58:54 <twoerner> in the database role
14:59:01 <nils> which would make it unset, using/setting the default value next time it is accessed.
14:59:47 <nils> that parameter is read only (and should probably one of the "differentiated as not user-settable" things)
14:59:58 <nils> IIRC
14:59:59 <sgallagh> I think 'services' by the way is going to go away.
15:00:10 <sgallagh> We don't actually use that for anything anymore
15:00:23 <nils> ok
15:00:25 <sgallagh> Because it isn't interesting to the end-user.
15:00:43 <nils> I just tried to "translate" what I found on RoleBase and the database role into the API I had in mind.
15:00:48 <sgallagh> It gives them no information and is always handled by the role-rolename-roleinstance.target file
15:01:11 <nils> But it is something a role developer would set, yes?
15:01:31 <sgallagh> A better example of course would be the default port for a service
15:01:41 <nils> Right.
15:01:43 <twoerner> yes
15:01:44 <sgallagh> nils: It's something that would realistically be hard-coded into the role definition
15:02:11 <nils> but something we should serialize into the settings.json of the role, right?
15:02:16 <sgallagh> nils: No
15:02:33 <sgallagh> That was what I meant by having it go away
15:02:45 <twoerner> if it has been applied, then yes. no?
15:03:02 <nils> Hmm, what if a future role version uses different services? We want to be able to decommission the old instance, don't we?
15:04:01 <sgallagh> nils: That information is managed by the role.target file
15:04:18 <nils> Yeah, we can query that via systemd.
15:04:32 <nils> If we need to.
15:04:36 <sgallagh> We don't actually need to query it; we just stop the role.target and the appropriate services are also stopped
15:05:01 <nils> And if we remove the instance, we remove the role target file. Right.
15:05:06 <sgallagh> Precisely
15:07:28 <twoerner> nils: I think there is a missing _gen in default=_database_default, right?
15:07:35 <twoerner> or am I missing somehting?
15:07:46 <nils> twoerner: probably, it's not working code :)
15:07:54 <twoerner> nils: ok :-)
15:08:27 <twoerner> nils: there will also be something like settings.is_default()?
15:08:58 <sgallagh> I think there will have to be, in order to ensure that we know which settings can be sanitized too
15:09:06 <twoerner> yes
15:09:59 <twoerner> and also accessors for the parmameter options like readonly etc
15:10:01 <nils> that's easily done
15:10:20 <nils> that would simply be `role.setting.<parametername>` ;)
15:10:34 <twoerner> great
15:10:54 <sgallagh> OK, so I think we're all on board with this new approach
15:11:15 <nils> `role.setting` would be a RoleSetting/Param object and act as a descriptor for getting/setting/unsetting
15:11:31 <nils> that's the idea anyway
15:12:07 <twoerner> ok.. looks good to me
15:12:08 <nils> I need to see where the descriptor use case and "normal member" use case clash
15:12:22 <nils> but I'm positive that there's a way to accommodate both
15:13:06 <twoerner> and it should be possible to register the parameters as dbus properties
15:13:30 <nils> for instance, if you want to deal with the actual values, you're working on the instance object, and if you want to find out stuff of the settings/param class, then work on the class.
15:13:34 <nils> Yes.
15:13:39 <twoerner> are all registered automatically or only by setting an option like dbus=True
15:13:58 <nils> the semantics should be: user-settable, yes or no
15:14:15 <nils> or "interesting to the user" or whatever
15:14:28 <nils> and then it should at least be readable from the bus
15:14:37 <nils> (depending on readonly)
15:15:23 <twoerner> do we want to have parameters that are not exported over dbus in any way?
15:15:37 <twoerner> s/over/to/
15:16:33 <twoerner> I think we have those too
15:16:34 <nils> I don't know, internal book-keeping stuff? implementation details?
15:17:11 <nils> stuff like that I really want to have separate from a) role settings and b) role state
15:17:19 <twoerner> or maybe also not.. need to have a look at the code
15:17:22 <nils> yes
15:17:32 <nils> I'm bound to trip over it sooner or later anyway :)
15:17:57 <twoerner> nils: yes :-)
15:19:37 <twoerner> ok
15:19:47 <twoerner> do we have time for the firewall stuff still?
15:20:18 <nils> yes as far as I'm concerned. sgallagh?
15:21:00 <sgallagh> Fine by me.
15:21:04 <twoerner> nils, sgallagh: do you have more to discuss about the parameters?
15:21:05 <sgallagh> #topic Firewall management
15:21:31 <sgallagh> No, I think we need nils to get a prototype working and we'll adjust from there
15:21:37 <nils> yup
15:21:41 <twoerner> ok, good
15:22:04 <twoerner> I will also need parts of this as a base for the firewall stuff I think
15:22:49 <twoerner> especially default vs. role deployment setting
15:23:53 <twoerner> sgallagh: could you please explain what the firewall interaction should look like now?
15:24:41 <twoerner> I think the things mentioned in issue#7 are not complete or accurate anymore
15:24:57 <sgallagh> Geez, give me all the tough questions... ;-)
15:25:07 <twoerner> sgallagh: :-)
15:25:37 <sgallagh> We had a long discussion about this during a meeting before the break
15:25:43 <sgallagh> Let me see if I can find a decent summary there
15:27:04 <sgallagh> Not coming up with it really quickly...
15:27:19 <twoerner> I am not sure that we had a summary
15:27:42 <sgallagh> So the core problem we had was that the port assignments were being strictly defined by the role definition, which makes life really difficult if you want to run on non-standard ports.
15:28:14 <sgallagh> We also determined that the details of the firewall configuration were not *strictly* interesting to the end-user, provided that the service is reachable
15:29:00 <sgallagh> So what we were talking about was having a set of helper tools that role definitions could call that would mark the correct ports as open when the role was active.
15:29:36 <sgallagh> And that the end-user should only have to specify on which ports they want the service to run and not separately care about the firewall.
15:29:52 <sgallagh> (With the notable exception that we want to be able to restrict by network interface)
15:30:05 <sgallagh> Does that provide a decent summary?
15:30:09 <twoerner> network interface or zone?
15:30:48 <sgallagh> twoerner: The strict requirement is by interface. Zones can provide a superset of that, so I'm fine with it
15:31:07 <twoerner> at the moment there is no interface use in roles for firewalls
15:32:00 <sgallagh> twoerner: Right, we've never actually achieved that goal
15:32:33 <sgallagh> It's always been on the back-burner as long as it works for all interfaces.
15:32:34 <twoerner> that goal?
15:32:52 <sgallagh> Restricting by interface; we deferred that goal.
15:33:13 <sgallagh> Might as well keep it in mind while we're redesigning this
15:33:32 <twoerner> interface names are not set in stone - there was a case again that the interface name changed after doing an upgrade..
15:33:59 <twoerner> but I am not sure that we support upgrades with keeping roles
15:34:18 <sgallagh> twoerner: We *intend* to, but we have made no official statement about it yet.
15:34:36 <sgallagh> And thus far it seems to be working for the roles we have
15:36:27 <twoerner> ok.. I will think about this and will provide a proposal as Nils did for parameters
15:36:39 <twoerner> is that ok?
15:37:01 <sgallagh> Works for me.
15:37:14 <sgallagh> #topic Open Floor
15:37:46 <sgallagh> I have a PoC for a containerized Domain Controller Role up on Review Board: http://reviewboard-fedoraserver.rhcloud.com/r/242/
15:38:16 <sgallagh> Anyone who has a few minutes and would be willing to review it is encouraged to do so.
15:38:39 <sgallagh> It's not finalized; it currently points to my personal Docker repo, since I had to make a few modifications to the FreeIPA container to make it work.
15:39:00 <sgallagh> I'm working with upstream to get those changes in
15:39:19 <twoerner> ok
15:40:38 <sgallagh> Anything else?
15:40:53 <sgallagh> If not, I'll close out the meeting and get ready for the Server SIG meeting in 20 minutes.
15:41:15 <twoerner> I am done
15:41:26 <sgallagh> nils: You good?
15:41:48 <nils> sgallagh: yeah, just took a look at the containerized DC role
15:41:59 <nils> sgallagh: and done, yes :)
15:42:31 <sgallagh> Thanks for coming folks. It's going to be a very exciting 2016.
15:42:33 <sgallagh> #endmeeting