00:01:39 <ekcs> #startmeeting congressteammeeting
00:01:40 <openstack> Meeting started Thu Jul  6 00:01:39 2017 UTC and is due to finish in 60 minutes.  The chair is ekcs. Information about MeetBot at http://wiki.debian.org/MeetBot.
00:01:41 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
00:01:43 <openstack> The meeting name has been set to 'congressteammeeting'
00:01:44 <thinrichs> Hi all
00:01:56 <ekcs> hi thinrichs !
00:03:05 * ekcs topics are here as usual
00:04:17 <masahito> hi
00:04:30 <ekcs> gosh something happened to my IRC clietn and I can’t paste.
00:04:43 <ekcs> well topics are at the usual place. feel free to add & comment!
00:04:59 <ekcs> I’ll restart my clietn and be back.
00:06:01 <ramineni_> Hi
00:06:57 <masahito> ramineni_: hi
00:07:10 <ramineni_> masahito: hi
00:07:20 <masahito> ekcs is restarting his IRC client now.
00:07:25 <ekcs> hey guys. sorry about the delay. Don’t know why irc client isn’t letting me paste even after several restarts.
00:07:27 <ekcs> but let’s continue.
00:07:43 <ekcs> please find the etherpad by following the eavesdrop line
00:07:44 <ekcs> link
00:07:54 <ramineni_> Ohk
00:07:56 <ekcs> i’ll just type it.
00:08:23 <ekcs> https://etherpad.openstack.org/p/congress-meeting-topics
00:08:39 <ekcs> Anything else I need to paste I’ll paste in the etherpad.
00:09:10 <ekcs> ok let’s get started then.
00:09:26 <ekcs> feel free to add to the etherpad as we go if you have topics or comments
00:09:53 <ekcs> #topic policy library discussion
00:09:59 <ekcs> let’s start with this.
00:10:41 <ekcs> so the implementation effort is continuing along.
00:11:00 <ekcs> I think all the core pieces are in review.
00:11:09 <ekcs> quite a few CLI and GUI things left.
00:11:19 <ekcs> here’s a point of discussion we could tackle now.
00:11:41 <ekcs> please follow the link on etherpad under policy library discussion
00:12:08 <ekcs> regarding whether to use unique names in policy library, as well as implementation options.
00:12:52 <ekcs> to summarize real quick: we have the option to make policy names in library unique or not.
00:13:21 <thinrichs> Ooops—I had a comment there and forgot to publish it.  If everyone refreshes they should see what I wrote.
00:13:40 <ekcs> non-unique names enable some helpful use cases. but unique names may be simpler for users being consistent with policy engine (even though there is no technical requirement for uniqueness)
00:14:51 <ekcs> I’m going to start talking, but go ahead and jump in with thoughts any time.
00:15:19 <ekcs> thinrichs: in comment on gerrit you said: “”
00:15:24 <ekcs> ugh forgot can’t paste.
00:15:43 <ekcs> but I want to clarify that source path and rank won’d be required when a user adds policy.
00:15:53 <ekcs> they’re hidden from the user completely. only meaningful to database.
00:16:01 <ekcs> and they’re nullable unique fields.
00:17:02 <ekcs> leaving aside implementation though, I think there is a question over which behavior we desire independently of implementation.
00:17:10 <thinrichs> I see, so the ID suggestion is the same as what's there.
00:17:45 <thinrichs> Last I remember we thought it could be valuable for the *library* to have policies with the same name, so that it would be easier to support multiple versions of the same policy.
00:18:53 <thinrichs> For example, if the policy name were 'network', you might want one version of the policy to work with Neutron
00:18:58 <thinrichs> and another version to work with Nova-network
00:19:23 <thinrichs> In the library they might both have the same name 'network' so that other policies could reference them
00:20:14 <ekcs> yup that’s a discussion we had a couple weeks ago.
00:20:14 <thinrichs> But if each library policy were required to have a unique name, people could name them 'network_nova' and 'network_neutron'
00:20:25 <ramineni_> While adding the policy from library to pe , how it will be handled in such case ..pe requires uniqueness
00:20:36 <thinrichs> and then have other policies still reference 'network', with the idea that when you insert 'network_nova' or 'network_neutron' you insert them with the name 'network'
00:21:28 <thinrichs> ramineni_: the PE would ensure you can only insert one policy named 'network', which would be okay because they are all different versions of each other.
00:21:57 <ekcs> ramineni_: I see it being handled the same way duplicate names are handled with a normal policy creation
00:22:24 <ekcs> if policy named ‘a’ already exists, and user tries to import a policy named ‘a’ from library, then it fails for duplicate name.
00:22:33 <thinrichs> What that does, however, is stop people from saying "insert all policies from the library into the PE"
00:22:55 <ramineni_> And get policy with name in library
00:23:24 <ekcs> thinrichs: right, the import all function would be complex.
00:23:35 <thinrichs> ramineni_: that's true—the user would need to know to reference policies differently when pulling them out of the library.
00:23:46 <ekcs> ramineni_: at a baseline, user would not be able to import by name. the workflow I imagine would be
00:23:52 <thinrichs> That feels like a usability problem
00:24:00 <thinrichs> at least initially
00:24:02 <ekcs> browse on horizon and select the one to import.
00:24:20 <ekcs> or search by name on CLI, then import by UUID.
00:24:40 <ekcs> on horizon it’s just selecting the entry, which is what you’d expect.
00:24:43 <thinrichs> Though maybe the CLI behavior would be to let you use the name if it's unique, and otherwise require the UUID
00:25:09 <ekcs> thinrichs: agree on CLI behavior when the input name happens to be unique.
00:26:11 <thinrichs> Do we have any policies in the library that reference another policy?
00:26:50 <thinrichs> If not, the value of having multiple policies with the same name seems small.
00:26:51 <ekcs> Not as of right now I think. So it’s really not an issue either way we go. problem is it’s hard to switch down the road.
00:27:05 <ekcs> if we choose non-unique now and switch to unique, there are obvious upgrade problems.
00:27:25 <ekcs> if we choose unique now and CLI, API that use that assumption, then move to non-unique later breaks them.
00:27:27 <thinrichs> And it would be cool if people would start saying "use policy network_neutron_7" to fix this bug
00:28:05 <ekcs> yea one vision that could potentially happen is a big library of policies people have contributed to and built up over the years.
00:28:27 <ekcs> I guess thinrichs you’re saying that as a reason to go unique name.
00:28:39 <thinrichs> It seems that we should be able to relax the requirement of unique-names later if we wanted...
00:29:00 <thinrichs> (Meaning that if every policy has a unique name, everything works the same
00:29:21 <ekcs> I’m also thinking it’s a reason to go non-unique name because then someone can write a policy that refers to another without being tightly coupled to the specific policy.
00:29:36 <thinrichs> but you could also have non-unique names and that would only impact you when using the CLI (via UUIDs)
00:29:42 <thinrichs> or the API (using UUIDs)
00:30:50 <thinrichs> ekcs: If policy A referring to policy B becomes a real problem we could always invent an Interface concept
00:31:01 <thinrichs> where policy A refers to interface B, and policies C, D, and E all implement interface B.
00:32:18 <ekcs> so it seems we’re leaning toward using unique names for now but not keeping the option open te move to non-unique later?
00:34:47 <thinrichs> I think there could be tremendous value in giving the community concrete names for a collection of policy statements that address a particular problem.  That too me is the most compelling reason to go with unique names.
00:34:52 <thinrichs> s/too/to
00:36:02 <ekcs> oh correctly my previous message: s/but not keeping/but keeping
00:36:22 <ekcs> ramineni_, masahito any more thoughts?
00:37:56 <masahito> unique name sounds goods for me.
00:38:04 <ramineni_> I'm leaning towards unique names , can be changed later if required
00:39:39 <masahito> it's easier for users to check which real policy is created by which policy library.
00:39:42 <ekcs> ok let’s do that then. great discussion!
00:39:53 <ekcs> anything else we want to talk about right now on policy library?
00:41:27 <ekcs> ok let’s move on then =)
00:41:49 <ekcs> #topic pike priorities
00:42:00 <ekcs> We’re coming up towards the end of pike.
00:42:17 <ekcs> I went through our pike goals and downgraded some of them.
00:42:40 <ekcs> leaving the high priority ones that I’m thinking we really want to get done for pike.
00:43:04 <ekcs> please take a look now or later and comment and whether that makes sense.
00:43:19 <ekcs> like are there other things that should be in there? or are there things that should not be in there.
00:43:31 <ekcs> link is in etherpad.
00:45:18 <ramineni_> Are high priority ones as must go in pike? Medium as good to go
00:46:00 <ekcs> That’s the way I’m using it. At this point I don’t expect we’ll get to most medium ones.
00:47:00 <ramineni_> Ok
00:47:39 <ekcs> The big remaining pieces I prioritized as high are: author library policies, monitoring UI, CLI and UI for policy lib, WSGI deployment, python3 integration tests.
00:48:14 <ekcs> the one I have least confidence in is WSGI deployment. I’ve been looking at it on and off but it’s a brand new thing for me.
00:48:51 <ekcs> library policies and python3 integration tests COULD go in between pike-3 and rc1.
00:49:58 <ramineni_> I'll look at wsgi one
00:50:23 <ekcs> the monkey wrench we got kind of late in the game is doc migration target moving from queens to pike because of openstack changes. but again that could be done between pike-3 and rc1.
00:51:12 <ekcs> ramineni_: awesomeness.
00:51:20 <ekcs> let’s move on then for now.
00:51:29 <ekcs> #topic open discussion
00:52:02 <ekcs> please jump in with whatever you may want to talk about =)
00:52:58 <ekcs> one interesting thing on ML is linked to on etherpad under congress for config files
00:54:06 <ekcs> someone was proposing that congress be used to check configs during cloud operation. to make sure that they haven’t deviated from desired and accepted practices.
00:54:53 <thinrichs> I saw that
00:55:00 <ekcs> he seems to have thought a fair bit about it and proposed that a new datasource be created to send config info to congress.
00:55:32 <thinrichs> Another way to look at this is to *independently* check that the systems are behaving correctly through their APIs.
00:56:23 <ekcs> yup. does that seem like something that’s useful?
00:56:50 <thinrichs> I don't know about the config files.  Seems they could be hard to flatten.
00:56:53 <ekcs> or is that really covered by all the existing config management systems in use.
00:56:55 <thinrichs> Or would they?
00:57:26 <thinrichs> I don't know if puppet/chef/ansible have a way of expressing invariants over the /etc/congress.conf files that get dumped onto disk
00:57:26 <ekcs> doesn’t seem hard actually. are there hierarchicial data in configs?
00:57:45 <ekcs> I feel like you could almost get away with a two column table. first is name/path of config, second a value.
00:57:51 <thinrichs> I imagine those tools make it easy to write tests though.  Just not sure about what you're testing.
00:58:08 <thinrichs> Sounds like it'd be worth exploring
00:58:15 <ekcs> like (“default.auth.blah”, “value”)
00:58:16 <thinrichs> Solving a concrete pain point is always valuable
00:59:18 <ekcs> agreed.
00:59:30 <ekcs> any other last min topics?
00:59:32 <ekcs> literally last min.
01:00:15 <ekcs> ok I guess we’re done then. Thanks all again!
01:00:34 <masahito> thanks
01:00:36 <ekcs> #endmeeting