00:01:31 <ekcs> #startmeeting congressteammeeting
00:01:32 <openstack> Meeting started Thu Sep 21 00:01:31 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:33 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
00:01:35 <openstack> The meeting name has been set to 'congressteammeeting'
00:02:03 <ekcs> hi all. welcome back to congress meeting!
00:02:24 <ramineni_> ekcs: hi
00:02:32 <ekcs> list of topics are here as usual: https://etherpad.openstack.org/p/congress-meeting-topics
00:02:52 <ekcs> feel free to add/edit/comment
00:02:52 <ekcs> hi ramineni_ !
00:03:49 <ekcs> ok let’s get started then!
00:03:53 <ekcs> #topic PTG recap
00:05:05 <ekcs> We had a great PTG with people bringing use cases, cross project discussions, and overall congress direction.
00:05:32 <ekcs> here’s a bullet points summary I sent out over ML: https://etherpad.openstack.org/p/congress-ptg-queens
00:06:12 <ekcs> anything we want to clarify or follow up on?
00:07:05 <ramineni_> ekcs: no
00:08:04 <ekcs> ok then let’s move along =)
00:08:40 <ramineni_> ekcs: i thought policy library UI is not priority?
00:08:49 <ramineni_> are we again targeting that feature?
00:09:06 <ekcs> #topic policy lib UI
00:11:03 <ekcs> haha so I was revisiting the tasks and priorities today. I said over email I didn’t think policy lib UI is a great return on effort required. But today I realized I was conflating browse & activate GUI with full CRUD.
00:11:35 <ekcs> After more thought I’m now of the opinion that browse and activate is a good return on effort but full CRUD is not.
00:12:04 <ekcs> ramineni_: do you have thoughts about that?
00:13:01 <ramineni_> ekcs: ok
00:13:39 <ekcs> any opinions one way or another?
00:13:51 <ramineni_> ekcs: should be fie i think
00:13:54 <ramineni_> fine**
00:14:18 <ekcs> ok =p
00:14:30 <ekcs> well lets come back to priorities later.
00:14:47 <ekcs> #topic unofficial driver
00:15:24 <ekcs> this is something masahito and I discussed at the PTG, partly triggered by the dynamic driver loading discussion
00:15:56 <ekcs> Here’s a BP: #link https://blueprints.launchpad.net/congress/+spec/separate-unofficial-drivers
00:16:40 <ramineni_> ekcs: yes , had a look at it
00:16:45 <ekcs> basically the idea is to establish a lower-tested/supported tier of drivers, to clearly communicate which drivers are most supported.
00:17:11 <ekcs> ramineni_: great. any thoughts? good idea? bad idea? potential problems?
00:18:03 <ramineni_> ekcs: hmm, non-openstack ones make sense .. but the openstack ones , do we need to support if it is not tested
00:18:26 <ramineni_> ekcs: i dont think any operator uses in production environment , if we keep as non-tested ones
00:18:46 <ekcs> good question to consider.
00:19:27 <ekcs> for instance, should we merge say designate driver to a lower tier, or not merge it at all.
00:19:33 <ramineni_> ekcs: and there is quite good chance that they will be beroken in future releases, if not monitored in gate
00:20:50 <ramineni_> ekcs: IMO , we should keep the tested ones,(production ready)
00:21:24 <masahito> sorry, late.
00:21:31 <ekcs> if merged the second tier, the more adventurous people trying/testing things out can easily enable and use it. but it can easily break in future.
00:21:50 <ramineni_> ekcs: if we support that, there will be bunch of drivers always in unsupported list? or we should consider deprecation of some time?
00:22:48 <ekcs> ramineni_: what if for openstack drivers we require at least the “update without error” test to be merged into “unofficial”. but comprehensive test (adding things that create content for tables then checking the contents) to be top level official drivers?
00:23:05 <ekcs> hi masahito ! talking about whether to do unofficial drivers =)
00:23:58 <masahito> ekcs: got it.
00:24:23 <ekcs> ramineni_: what do you think is the main disadvantage to having “unofficial” drivers that may or may not be broken? is to going to confuse users? generate too many bugs? lower the perception of quality for the overall project?
00:25:28 <ramineni_> ekcs: 1. no one uses it , 2. increases maintainability, 3. not production ready
00:26:12 <ramineni_> ekcs: at some point we have to make them stable? or planning to keep them in unoffcial drivers
00:26:13 <ramineni_> ?
00:26:46 <ramineni_> ekcs: advantages: i see your point, we can get more drivers into tree, but are they really useful, like that?
00:27:38 <ekcs> the way I’m thinking about it is that it doesn’t hurt to include more in an “unofficial” dir as long as it is clear we don’t promise anything with respect to those. That way people trying out new use cases can experiment with them.
00:28:29 <ramineni_> ekcs: once we land them there, i dont think no one cares about making it stable, or make sure well tested
00:28:53 <ramineni_> ekcs: mostly, new drivers will land there, not in supported ones
00:29:08 <ekcs> and if we add better testing, we can move them to official. for example if some users find an unofficial driver is useful for their use case, then we&them can invest resources into making it official.
00:29:22 <ekcs> but there is no promise and some may be forever unofficial.
00:30:31 <ekcs> ramineni_: right I see that as the main disadvantage. by opening up that tier, we can end up crafting the incentives such that we end up getting fewer official drivers than we otherwise would.
00:30:46 <ekcs> masahito: do you have any thoughts?
00:33:02 <masahito> I'm not sure people have concerns about drivers are official or not because all drivers are located in Congress repo.
00:34:50 <ekcs> ramineni_: has a concern that by opening up a tier of unofficial drivers in tree, instead of insisting on proper tests before merging at all, we may basically create a situation where we never make new drivers official and well tested.
00:35:22 <ekcs> so the end result is we have fewer well tested drivers.
00:35:56 <ramineni_> and they may break eventually , which will not be noticed
00:37:05 <ekcs> ramineni_: right. so the actual value of the unofficial drivers may be minimal if they all end up broken anyway.
00:39:34 <ramineni_> ekcs: masahito: not quite sure, actually if this feature would be really useful or not, if some usecases, we can consider this, but with some guidelines, atleast , we have some useful ones, vncetre, benchmarking etc which are useful point for non-openstack ones to write their own drivers
00:40:28 <ramineni_> but for openstack ones, if we open up for veryone, i dont think anyone will care about writing tempest tests, at some point we should consider their maintainability
00:41:03 <ekcs> so it seems like we all agree on this: the non-openstack drivers without CI should be moved to unofficial subdir. correct?
00:41:10 <ramineni_> if we think really useful to include we can consider may be
00:41:50 <ramineni_> ekcs: right, i dont think we have hw to test them anyway
00:41:59 <ramineni_> on gate
00:42:04 <ekcs> ok.
00:42:47 <ekcs> We're not sure about opening that up to openstack drivers without good integration tests because it may discourage good tests for drivers and end up in a bad situation.
00:43:49 <ekcs> so why don’t we just move the non-openstack drivers we don’t have integration tests for. but not allow openstack drivers in there.
00:44:46 <ramineni_> ekcs: sounds good to me
00:45:29 <ekcs> ok then. I’ll update the BP.
00:45:48 <ekcs> let’s move on then. more comments welcome on the BP =)
00:45:54 <ekcs> #topic QoS patch
00:46:39 <ekcs> I’m hoping we can make progress on the QoS patch because it is need by a partner.
00:46:43 <ekcs> https://review.openstack.org/#/c/488992/
00:46:44 <patchbot> patch 488992 - congress - Add Qos translator in neutron datasource drive.
00:46:51 <ramineni_> ekcs: i have one question, does QoS driver alone can exist witought creating neutron datasource, or is it dependent
00:47:06 <ekcs> ramineni_: it can exist independently.
00:47:30 <ekcs> there is no dependency mechanism between congress datasources.
00:48:13 <ramineni_> ekcs: because it queries neutron for ports , but the table diffrs a lot
00:48:47 <ekcs> ramineni_: right. so here’s the story.
00:49:25 <ekcs> that driver doesn’t actually want the ports table. it just wants the port to qos policy binding.
00:49:48 <ekcs> but because of the way congress datasource driver framework works, there needs to be a parent table in order for the port to qos policy binding subtable to work.
00:50:22 <ekcs> the choices are 1. add a new tranlation kind to datasource driver.
00:50:28 <ekcs> 2. just include a dummy ports table.
00:50:45 <ekcs> we figured 2 is ok because an extra table doesn’t hurt anyone.
00:50:59 <ramineni_> ekcs: ok, ya, i think existing looks ok
00:51:15 <ekcs> and the work needed to add new translation kind may not be justified because it’s not clear there are more cases that need it.
00:51:48 <ramineni_> if its independent , doesnt hurt, i thought , qos doesnt make sense if it neutron is not availble
00:52:18 <ramineni_> i thought dependent
00:52:25 <ramineni_> ill take a look at patch again
00:52:31 <ekcs> ah ok. thanks!
00:53:21 <ekcs> ok let’s go back to queens priorities in the last few minutes.
00:53:36 <ekcs> #topic Queens priorities
00:53:46 <ekcs> #link https://etherpad.openstack.org/p/congress-task-priority
00:53:55 <ekcs> here’s my attempt to prioritize for queens.
00:54:29 <ekcs> any thoughts or comments about it?
00:54:40 <ekcs> we can continue to discuss it today and next week.
00:55:09 <ekcs> are there priorities I’m missing?
00:55:11 <ramineni_> ekcs: there is one wsgi one, pike goal, is it done
00:55:13 <ramineni_> ?
00:55:23 <ekcs> ramineni_: it’s not done yet.
00:55:36 <ekcs> it’s included in the ‘unranked’ section because i’m not sure where to rank it.
00:55:49 <ramineni_> ok :)
00:55:58 <ramineni_> is it required? or can be ignored now
00:57:36 <ramineni_> ekcs: ill take a look at it, and assign myself some features
00:58:00 <ekcs> ramineni_: none of the TC goals are *required*, but prioritized. it’s not clear to me how much impact that goal has compared to the others.
00:58:25 <ramineni_> ekcs: ok
00:59:33 <ekcs> I think we want to get it done sometime soon-ish because at some point people will want to deploy congess that way and we don’t want to be not ready, but it doesn’t immediately impact users or devs right now.
00:59:52 <ekcs> so I think between the TC goals it’s somewhat less immediate that tempest plugin which saves us work right away.
00:59:55 <ramineni_> ekcs: ok, got it
01:00:11 <ekcs> ok let’s end meeting.
01:00:17 <ekcs> very helpful discussion.
01:00:25 <ekcs> thank and more next week!
01:00:28 <ekcs> #endmeeting