00:01:05 <ekcs> #startmeeting congressteammeeting
00:01:06 <openstack> Meeting started Thu Mar  2 00:01:05 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:07 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
00:01:09 <openstack> The meeting name has been set to 'congressteammeeting'
00:01:34 <aimeeu> Hello!
00:01:37 <ekcs> Hi all! Hope everyone had a nice trip back from ATL.
00:01:40 <ekcs> hello aimeeu
00:01:41 <thinrichs> Hi all
00:02:04 <masahito> hi
00:02:26 <ekcs> hi thinrichs masahito
00:02:52 <ekcs> Here are the topics I have for today. Please feel free to add topics you have in mind. https://etherpad.openstack.org/p/congress-meeting-topics
00:03:34 <ekcs> Going forward I’ll try to have the topics ready a day ahead so people have time to add topics ahead of time and also to think about them.
00:04:32 <ekcs> i’ll wait a couple minutes for people to look through and maybe add topics. But also feel free to add as we go.
00:08:09 <ekcs> ok let’s get started then =)
00:08:17 <ekcs> #topic PTG very brief recap
00:08:46 <ekcs> We had a very productive first PTG. We took lessons from ocata cycle, heard very useful feedback from bryan_att and aimeeu and others, worked through technical issues, and came away with a great list of concrete goals and tasks we'd like to pursue. It was very nice to have cgoncalves join us for the discussions.
00:08:58 <ekcs> I'll be sending out individual emails to ask for more feedback and suggestions on the PTG, but feel free to share your thoughts here too =)
00:09:32 <aimeeu> +1 very productive
00:09:41 <bryan_att> I agree. A number of specific actions that we will followup on.
00:09:50 <thinrichs> +1
00:11:01 <ekcs> awesome. speaking of specific actions, let’s move on to the next topic then.
00:11:08 <ekcs> #topic pike goals
00:11:43 <ekcs> I'm still organizing the goals, but here are some themes from my perspective. Please feel free to share your thoughts and perspectives!
00:11:43 <ekcs> 1. we have a bunch of testing improvements we want to make. upstreaming opnfv tests, better driver testing in tempest, systematic HA tests, periodic stable tests, upgrade tests, etc.
00:11:56 <ekcs> 2. We have several small-medium features we'd like to add in response to requirements and needs of the community. generic datasource driver, non-blocking action execution, oslo notification of action execution, dashboard separation, etc.
00:14:23 <ekcs> 3. Probably the most public "headline" features we are looking to do are policy library and policy monitoring pane.
00:14:49 <ekcs> Policy library involves many pieces including the actual policies, help and descriptions, templating the policies, UI for using the policies, etc. Significant design work is still needed as we go to make it all work together in a compelling package.
00:16:26 <ekcs> 4. specific action items in community engagement
00:17:07 <ekcs> Any thoughts/reactions/corrections/additions to my characterization here?
00:17:44 <ekcs> I’m still in the process of adding tasks to launchpad and should be done before the week is over.
00:18:28 <bryan_att> I'll be adding some patches to the docs etc as noted
00:19:58 <ekcs> yups several docs improvements discussed. especially around installation and requirements.
00:19:59 <masahito> ekcs: tasks about improving project navigator are in #4?
00:20:52 <ekcs> masahito: I guess so. partly 1 and partly 4.
00:23:02 <ekcs> ok then let’s move on =)
00:23:31 <ekcs> #topic policy library design
00:24:42 <ekcs> lots of complex issues here we’re not going to figure out today. but in reviewing the goals I did notice something that could be helpful to spend a little bit of time on.
00:25:25 <ekcs> one of the tasks we have listed is the function to enable and disable policies. the rationale if I recall, is that
00:26:17 <ekcs> 1. it would support modular policy management based on type of deployment (bryan_att talked about this)
00:26:35 <ekcs> 2. it would support enabling and disabling policies in our (to be constructed) policy library.
00:28:07 <ekcs> when I thought more about it, I wondered if we really want to make this kind of API/data model change at this point. in terms of 1, it seems to be a medium term goal rather than an immediate goal.
00:28:47 <bryan_att> I can agree with it being medium-term, an optimization
00:29:33 <ekcs> in terms of 2, it’s not clear that policies in our policy library are actual policies, more likely they are templates that need parameters to become actual policies. so it seems to call for a different kind of mechanism than the enabling and disabling of policies.
00:31:03 <thinrichs> While eventually I expect the policy library to be an entirely new kind of thing, it might be a good starting point to have them be regular policies.
00:31:18 <thinrichs> Then people can customize them by changing the individual rules.
00:31:51 <thinrichs> To really know the answer, I think we want to assemble a collection of policies that we think are valuable out of the box, and then look at whether modifying those policies is a reasonable first step.
00:32:12 <thinrichs> Or whether we think we need to invent policy-templates or the like before users will see any value.
00:32:13 <bryan_att> I agree, e.g. a yaml file in the repo that has a policy name and string that is the policy rule
00:32:36 <bryan_att> if we find any that must have parameters we can cross that bridge
00:32:52 <bryan_att> but some should be useful and generic
00:33:06 <ekcs> makes sense.
00:33:06 <thinrichs> bryan_att: you're thinking about enabling/disabling policies via config to Congress?
00:33:33 <bryan_att> not sure, have to think thru it
00:33:34 <thinrichs> I was imagining enabling/disabling policies via the API, but config would be even quicker to get up and running.
00:33:48 <bryan_att> config would be quicker for sure
00:34:25 <bryan_att> via API we would need to query available policies and enable them by name
00:34:34 <bryan_att> so a new API function
00:34:59 <bryan_att> or something like that
00:35:13 <masahito> I'm not sure using config is quicker in the case of multi PE deployment
00:35:53 <bryan_att> and esp if it's an install-time thing only it might not be flexible enough
00:36:09 <thinrichs> bryan_att: I like the idea of having a library as a separate database table and then an API that pulls policies out of that table and creates them in today's API.
00:36:44 <bryan_att> yes, that would work too - reuse as much as possible of the existing API unchanged
00:38:56 <ekcs> hmm ok. so it sounds like we’re not sure at this point. probably the thing to do is get further along in policy library authoring then deciding at that point how to realize things?
00:39:15 <thinrichs> ekcs: +1
00:39:24 <thinrichs> We've got several good ideas here.
00:39:35 <ekcs> helpful discussion though to get the issues and ideas out.
00:39:38 <ekcs> yup thinrichs
00:39:38 <bryan_att> what's the next step then, a design doc for this?
00:41:06 <ekcs> I think a rough draft kind of design doc could make sense.
00:41:38 <ekcs> as a good place to put the general concepts down and discuss further as we develop the actual policies.
00:42:41 <bryan_att> as a google doc or a blueprint?
00:43:36 <ekcs> for facilitating discussion, google doc or spec on gerrit would be good. blueprint doesn’t work as well.
00:44:00 <thinrichs> I'd also say we should put together a handful of policies that we'd want to include in the library.
00:44:11 <bryan_att> ok, either works for me. if someone wants to start one I can comment and help define it.
00:44:42 <ekcs> great. yea I agree with thinrichs that’s the first step.
00:44:58 <ekcs> ok let’s move on then if we’re done with this topic.
00:46:13 <ekcs> ramineni is not here so let’s skip the angular.js topic. we didn’t get to that at the PTG and I figure we’d at least understand the rationale behind that thought.
00:46:45 <ekcs> #topic status updates and open discussion
00:47:12 <ekcs> feel free to give an update if you like, and/or discuss any other topic on your mind =)
00:48:45 <ekcs> I’ve pretty much been reviewing and organizing the notes & tasks from the PTG and checking in on gerrit. In the process of launchpadding the tasks. and also releasing a newton update.
00:50:54 <thinrichs> Nothing from me.  Still recovering from the PTG.
00:51:12 <aimeeu> I've been very busy with the upcoming OPNFV Danube release. Once that's out the door, I'll be able to focus on Congress a bit more.
00:51:48 <ekcs> good stuff.
00:51:49 <masahito> nothing from my side.
00:51:59 <ekcs> I do have another topic I’ll bring up since there is time. I thought about antlr3 removal some more. Eventually we have to do it, but it’s not needed in python2.
00:52:49 <ekcs> reading the tea leafs a little bit, it doesn’t seem to me like openstack will officially and completely support python3 within the next two cycles.
00:53:38 <ekcs> so maybe it makes more sense to de-prioritize the antlr3 removal and focus my/our attention on things congress needs now.
00:54:25 <ekcs> the trade-off is if we wait too long, it’ll be a rush job at some point and we’ll have a pretty terrible first official python3 release.
00:55:16 <thinrichs> I thought antlr3 worked for python3, and the main problem was the debian packaging
00:55:35 <thinrichs> and that fact that we can't actually maintain it.
00:55:51 <ekcs> for clarification, congress will run on python3 (if we include some thirdparty code the way we do now), but we can’t debian-package congress in a way that supports python3.
00:55:57 <ekcs> yup thinrichs
00:57:31 <ekcs> so maybe it’s even less of a concern that I made it to be. if at some point openstack moves officially to python3, the worst thing that can happen is we get left out of the debian package at that point.
00:57:46 <ekcs> if openstack moves before we are ready to replace antlr3.
00:58:14 <ekcs> that’s a lot less bad than a terribly buggy release.
00:59:10 <ekcs> also this is not new news, but python has extended python2 support to 2020.
00:59:32 <ekcs> will continue to release 2.7.x as needed.
00:59:50 <ekcs> ok well about out of time.
01:00:10 <ekcs> please ping/email me if you have any thoughst on this issue.
01:00:49 <ekcs> thanks all and have a great week!
01:00:53 <thinrichs> Thanks all!
01:01:11 <ekcs> #endmeeting