20:00:04 <johnsom> #startmeeting Octavia
20:00:05 <openstack> Meeting started Wed Jun  6 20:00:04 2018 UTC and is due to finish in 60 minutes.  The chair is johnsom. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:00:06 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:00:08 <openstack> The meeting name has been set to 'octavia'
20:00:09 <xgerman_> o/
20:00:12 <johnsom> Hello everyone
20:00:49 <johnsom> I have a list of announcements today...
20:00:57 <johnsom> #topic Announcements
20:01:10 <johnsom> There is interest in starting a Zun compute driver for Octavia
20:01:12 <nmagnezi> o/
20:01:17 <johnsom> #link http://lists.openstack.org/pipermail/openstack-dev/2018-June/131056.html
20:01:39 <johnsom> Good stuff there.  I hope we can support that effort
20:02:18 <johnsom> The next OpenStack summit is in Berlin and the one after will be in Denver (downtown and not at the train, grin)
20:02:43 <johnsom> It sounds likely that in 2019 the PTG and summit will merge back into one event.
20:03:02 <johnsom> (These are all notes I have captured from the mailing list BTW
20:03:26 <johnsom> There is a proposal for Barbican to become a base service for OpenStack
20:03:32 <johnsom> #link https://review.openstack.org/#/c/572656/
20:03:44 <johnsom> You can vote and comment on that patch
20:04:00 <johnsom> Also of note, today is Rocky milestone 2
20:04:11 <johnsom> That means I will be cutting milestone releases
20:04:44 <johnsom> #link https://releases.openstack.org/rocky/schedule.html
20:04:59 <johnsom> Any other announcements today?
20:05:46 <johnsom> #topic Brief progress reports / bugs needing review
20:06:34 <johnsom> I have been busy working on the provider driver activities.  I think all of the provider driver spec is now implemented.  There are still things we need to work out and fix, notably status updates and the update calls.
20:07:46 <johnsom> I have also been working on the neutron-lbaas to octavia load balancer migration tool.  As it is today, it *should* work for octavia provider load balancers.  I still need to finish the support for migrating other driver LBs and some testing.
20:08:21 <nmagnezi> this is great!
20:08:28 <johnsom> Any other updates?
20:08:34 <rm_work> re: Milestone releases -- i think you should wait a day if possible, we have some fixes to merge for some important bugs related to stuff that just merged IMO
20:08:53 <nmagnezi> I'll try to spawn a node for that. hopefully devstack can handle installing both octavia and n-lbaas
20:09:09 <johnsom> rm_work I need to get that in today, but we have the rest of the day.  Can you put together a list?
20:09:29 <nmagnezi> I have a story that needs review, maybe worth to discuss in the open discussion part
20:09:37 <johnsom> Ok
20:09:38 <nmagnezi> #link https://storyboard.openstack.org/#!/story/2002167
20:10:10 <nmagnezi> If it's acceptable, I can try to make it work
20:10:25 <johnsom> Other updates?  I know we have made some progress on grenade.
20:10:28 <nmagnezi> but there are open questions there
20:12:02 <johnsom> Hmm, yeah, this leads into another conversation I wanted to start in open discussion.
20:12:30 <nmagnezi> np
20:13:05 <johnsom> If there are no other progress updates I guess we can jump in there
20:13:06 <johnsom> Ok
20:13:06 <johnsom> #topic Brief progress reports / bugs needing review
20:13:06 <johnsom> opps
20:13:11 <johnsom> #topic Open Discussion
20:13:26 <xgerman_> that was quick
20:13:32 <johnsom> Ok, so my topic was about API versioning
20:14:04 <johnsom> Yeah, I didn't get the right topic cut and pasted, so duplicate topic for progress reports.
20:14:37 <johnsom> Nir did you want to go first or should we just talk about it in the context of the API versions?
20:14:51 <nmagnezi> i'm fine with both
20:15:48 <nmagnezi> johnsom, lead the way :)
20:16:07 <johnsom> Ok, So we have been bad
20:16:34 <johnsom> Currently we have only one version for the v2 API "v2.0" though we have added new capability
20:17:32 <xgerman_> yeah, we should be at 2.1
20:17:41 <johnsom> I think it is time we really get serious about versioning the API so that clients, etc. can work with our API across deployments
20:17:46 <johnsom> I proposed
20:17:50 <johnsom> #link https://review.openstack.org/#/c/559460/
20:18:11 <johnsom> But there was pushback about the 2.1
20:18:19 <johnsom> It's probably not the right answer anyway.
20:19:02 <johnsom> I think it might be time we consider microversioning
20:19:06 <johnsom> #link https://specs.openstack.org/openstack/api-wg/guidelines/microversion_specification.html
20:19:32 <johnsom> I'm not the biggest fan of this
20:19:56 <johnsom> Most notably if people make a request without a micro version they get the oldest version of the API by default.
20:20:18 <johnsom> I think that is a bit lame
20:20:40 <johnsom> It also means we have to think about how we want to handle version in the API code.
20:20:50 <nmagnezi> johnsom, just for context, when you say that we added new capability, which API capability you refer? cascade delete? asking just to get a sense of how major/minor that feature was..
20:20:54 <johnsom> As well as in tempest as Nir mentioned
20:21:19 <xgerman_> amphora API
20:21:21 <johnsom> Well, Queens added amphora failover
20:21:38 <nmagnezi> gotcha
20:21:42 <rm_work> yeah the amp API, which ... i don't know if anyone uses? it definitely isn't end-user
20:21:53 <johnsom> Rocky adds timeouts and listing provider drivers
20:21:59 <rm_work> and might not be in the right place given changes made with provider anyway <_<
20:22:12 <nmagnezi> rm_work, yeah but it's still an API change. a totally new API call
20:22:59 <nmagnezi> johnsom, yup. those listener timeouts will cause tests that we currently have in our tempest plugin to fail against stable/queens
20:23:07 <rm_work> yeah i guess we can't "undo" adding it ... but i wonder if it should be in a different place when we finally actually put up v2.1 or whatever
20:23:24 <nmagnezi> which makes sense. we just need to find a way to skip it somehow
20:23:30 <rm_work> eh, this is not relevant for right now, so ignore me
20:23:48 <rm_work> nmagnezi: wait, why do they cause test failures? because extra data comes back?
20:23:57 <rm_work> i feel like that's badly designed testing :/
20:24:04 <rm_work> but ... ehh
20:24:17 <nmagnezi> rm_work, because some listener attrs just didn't exist in Queens
20:24:27 <rm_work> oh
20:24:32 <johnsom> There is some docs for tempest testing with microversions
20:24:34 <johnsom> #link https://docs.openstack.org/tempest/latest/microversion_testing.html
20:24:36 <rm_work> ah right you mean the NEW tests (which test those)
20:24:47 <rm_work> and yeah obviously they don't work :P
20:25:00 <nmagnezi> rm_work, yes. it's in the story I submitted https://storyboard.openstack.org/#!/story/2002167
20:25:11 <nmagnezi> johnsom, will read it.
20:25:24 <johnsom> To be honest, I have not read up on the microversion stuff recently, so can't talk in too much detail.
20:26:18 <rm_work> yeah i hate the "oldest" thing too
20:26:32 <rm_work> i don't suppose we could just ... do it differently? or is that code that's in the client / etc
20:26:36 <rm_work> and not really our choice
20:26:55 <nmagnezi> johnsom, if we don't want to go with micro versioning (because of what you wrote above), can't we just go with 2.1 for that reason?
20:27:09 <rm_work> yeah i don't particularly mind a v2.1
20:27:18 <xgerman_> So the way I undertstand microversions is that you rev up to 2.X and someday call it fine and then release 2.X as 3.0
20:27:20 <johnsom> There was discussion at the summit about how to fix it to not be the "oldest"
20:27:49 <xgerman_> and if somebody needs some of the “new” functionality they need to do that call with the appropriate microversion
20:28:03 <xgerman_> which all sounds pretty crazy to me
20:28:12 <johnsom> I am fine with v2.1, it's what I proposed, but we need to figure out how to support the older and newer in our API code
20:28:28 <rm_work> yeah
20:28:30 <rm_work> i mean ermm
20:28:41 <johnsom> xgerman Yeah, so we are all in agreement on microversions kind of suck
20:28:52 <johnsom> On option is a full copy
20:28:56 <rm_work> i suppose it's naive / bad to just make a v2.1 directory in the api module, and make new classes that just inherit and pass from the old ones? >_>
20:29:24 <johnsom> Right
20:29:30 <rm_work> i guess that could lead to a mess
20:29:49 <johnsom> A bit, but at least it would be kind of clear
20:29:51 <rm_work> eugh i don't want to be in the business of fixing bugs in multiple classes at once
20:30:02 <xgerman_> well, the people behind microversions have little concerns for the plights of us programmers having to implement those schemes
20:30:32 <rm_work> the microversions stuff has like... decorators with version numbers and allows multiple functions with the same name?
20:30:36 <rm_work> and they live side-by-side?
20:32:22 <johnsom> I'm not up to date enough on it to say
20:32:39 <rm_work> i need to do some research but, this is something we do need <_<
20:32:43 <rm_work> do we need it BY ROCKY?
20:32:44 <johnsom> I would likely need to dig into nova code to see how they do it
20:32:51 <xgerman_> I think like it or not but we probably have to do microversions
20:33:05 <johnsom> I'm not convinced he have to do microversions.
20:33:07 <rm_work> err i am thinking of broader than openstack
20:33:09 <johnsom> neutron does not
20:33:11 <nmagnezi> maybe we can learn from neutron https://specs.openstack.org/openstack/neutron-specs/specs/liberty/microversioning.html
20:33:20 <xgerman_> you want to do extensions?
20:33:30 <rm_work> like, i would like to research how this is done in general
20:33:50 <johnsom> Yeah, ok.  I am fine with putting it on the next agenda
20:34:01 <johnsom> I do think we need something in place by the end of Rocky
20:34:29 <nmagnezi> yeah.
20:34:31 <rm_work> k
20:34:39 <rm_work> though i will maybe miss next week
20:34:51 <rm_work> i'm in an all week internal summit thing next week
20:34:52 <xgerman_> sure, but it’s a major change and R-2…
20:35:37 <nmagnezi> johnsom, as for https://storyboard.openstack.org/#!/story/2002167 , not sure if this needs to depend on API versioning. what do you think?
20:36:33 <johnsom> nmagnezi We do need to have that running in queens. I am fine with moving forward to add the gates non-voting
20:37:08 <rm_work> yeah, we should do that
20:37:27 <nmagnezi> great
20:37:30 <rm_work> and i can noodle fixing the tests to be a little more compatible
20:37:31 <rm_work> we do have SOME api versioning
20:37:32 <rm_work> there's dates
20:37:37 <rm_work> I generally tried to update those on api changes but may not always have remembered :(
20:37:40 <nmagnezi> I'll try to make it happen and keep you all posted
20:37:45 <rm_work> but, probably i can tag on whatever queens uses
20:37:54 <rm_work> i hope it's different
20:38:34 <johnsom> Ok. Sounds good
20:38:42 <johnsom> Any other discussion today?
20:39:29 <rm_work> ummm
20:40:31 <rm_work> eh
20:40:35 <rm_work> i was gonna plug some stuff
20:40:38 <rm_work> but i think we're on it
20:40:41 <johnsom> Ok
20:40:46 <rm_work> i'll try to get a list of stuff i'd like by R2
20:41:05 <johnsom> Excellent
20:41:38 <johnsom> It looks like we finally have movement on the zuul job update to collect the nodejs coverage reports, so the coverage patches can merge.
20:41:57 <johnsom> I also cut a python-octaviaclient in case you missed it
20:42:12 <johnsom> Otherwise, I don't have any more topics
20:42:45 <rm_work> k
20:42:47 <johnsom> Going once...
20:42:53 <rm_work> i feel like i'm forgetting something
20:43:03 <rm_work> but i'll remember after you close the meeting and we can discuss later :P
20:43:08 <johnsom> grin
20:43:11 <johnsom> #endmeeting