20:00:32 <johnsom> #startmeeting Octavia
20:00:33 <openstack> Meeting started Wed Apr 25 20:00:32 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:34 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:00:36 <openstack> The meeting name has been set to 'octavia'
20:00:46 <cgoncalves_> hi
20:00:51 <xgerman_> o/
20:00:57 <johnsom> Hi all
20:01:17 <johnsom> #topic Announcements
20:01:27 <johnsom> PTG is back in Denver Sept 10-14
20:01:36 <nmagnezi> o/
20:01:41 <johnsom> Same hotel. In theory less train
20:02:07 <rm_mobile> ... how
20:02:08 <johnsom> The foundation is interested in how many folks plan to attend for room planning.
20:02:34 <johnsom> I guess they fixed the crossing gate issue (or wrote it off) and the hotel installed better windows.
20:02:48 <rm_mobile> Lol k
20:02:49 <johnsom> Does anyone know if they are already planning to attend?
20:03:20 <xgerman_> depends on funding…
20:03:39 <johnsom> Ok, I will take a guess and give them that based on previous attendance.
20:03:49 <johnsom> Yeah, I have no idea if I can make it yet either.
20:03:52 <xgerman_> prob. more since we are in F5 land
20:04:13 <johnsom> Yeah, they might want some quality time with us to work on the driver
20:04:36 <johnsom> Also, TC elections are on. Check you inbox for you ballot email.
20:05:10 <johnsom> That is all I have for announcements. Any others?
20:05:55 <johnsom> #topic Brief progress reports / bugs needing review
20:06:31 <rm_mobile> I will definitely try
20:06:36 <johnsom> I have been buried in gate fixes, but have started work on the provider driver again.
20:07:08 <johnsom> Making decent progress, I have most of the LB API moved over to running through the new "octavia" driver.
20:07:26 * johnsom Looks to see if Carlos is paying  attention or not.
20:07:26 <cgoncalves_> s/octavia/amphora :D
20:08:07 <johnsom> I am making a few changes to the data model for drivers, just as a heads up in case someone is developing against my WIP data model patch
20:08:46 <johnsom> I expect the provider driver work will be my focus for the rest of the week
20:08:54 <cgoncalves_> johnsom: do you need help in any particular area? just reviewing?
20:09:01 <johnsom> Any other progress updates?
20:10:01 <johnsom> Keeping reviews rolling on stuff is super helpful. Once I get over this data model work and get updates working I think the reset will fall together pretty quick.
20:10:19 <xgerman_> famous last words “fall together quickly”
20:10:25 <johnsom> Yeah, exactly
20:10:57 <cgoncalves_> ok
20:11:02 <johnsom> cgoncalves I will keep you in mind though, once the framework is in place I can probably hand off converting some of the other objects for parallel work.
20:12:03 <johnsom> #link https://review.openstack.org/#/q/(project:openstack/octavia+OR+project:openstack/octavia-dashboard+OR+project:openstack/python-octaviaclient+OR+project:openstack/octavia-tempest-plugin)+AND+status:open+AND+NOT+label:Code-Review%253C0+AND+NOT+label:Verified%253C%253D0+AND+NOT+label:Workflow%253C0
20:12:12 <cgoncalves_> sure, ping me whenever you need
20:12:20 <johnsom> There are a bunch of patches open without reviews however, so that would be great too
20:13:30 <johnsom> Any other progress updates?
20:14:20 <johnsom> #topic Octavia deleted status vs. 404
20:14:28 <johnsom> #link https://review.openstack.org/#/c/545493/
20:14:54 <johnsom> Looks like the patch has a gate issue, I will look at that after the meeting.
20:15:08 <johnsom> Any other updates on library support/no-support?
20:15:25 <rm_work> i think the gate issue was a neutron bug
20:15:29 <rm_work> just needs a recheck
20:15:30 <johnsom> I thought I have this handled in the new tempest plugin, but I guess I missed something
20:15:38 <rm_work> johnsom: i have a patch for that
20:15:55 <rm_work> https://review.openstack.org/#/c/563737/
20:16:03 <johnsom> Ah, sweet
20:16:30 <rm_work> fixes all the way to the HM patch i had on top of your deleted one
20:16:36 <rm_work> so hopefully we can merge all the way up there
20:16:45 <rm_work> and the constraints patch (because our l-c is broken)
20:16:54 <johnsom> Ok, cool
20:17:42 <johnsom> Yeah, more good stuff needing reviews
20:17:53 <rm_work> I did also get the proxy-gate passing in neutron-lbaas, where it just adds an L7 proxy for /lbaas/ direct to octavia from neutron
20:18:33 <rm_work> could use eyes and opinions on the test changes that were made to accomodate that, to make sure there's nothing too dumb (because changing tests to make them pass is normally dirty)
20:18:41 <rm_work> https://review.openstack.org/#/c/561049/
20:18:58 <rm_work> most of them are around one bug (which is that octavia ignores tenant-id on subobjects)
20:19:29 <xgerman_> and here is the other proxy: https://review.openstack.org/#/c/539350/
20:20:00 <johnsom> Well, having different project-ids for different parts of a single load balancer doesn't really make any sense, so....
20:20:07 <rm_work> yes
20:20:14 <rm_work> the tests were negative tests to make sure it exploded
20:20:29 <rm_work> whereas octavia just ignores them entirely
20:20:49 <rm_work> so the question is, should octavia change to also reject the requests, or should the tests just expect either
20:20:54 <johnsom> Yeah, until the deprecation cycle is up.
20:21:23 <rm_work> because I could make the patch to octavia to make it actually check those ids, and actually reject requests where they don't match correctly
20:21:36 <rm_work> the question is, should we?
20:21:47 <rm_work> or should we skip/fix those "bad" negative tests
20:21:57 <xgerman_> my proxy handles tenant_id just fine
20:22:27 <xgerman_> but yeah, skipping tests is fine
20:22:33 <rm_work> yeah, my goal is different than yours
20:22:34 <johnsom> Ah, they can be removed in "S"
20:22:46 <rm_work> i'm trying to prove octavia's backwards-compatibility
20:23:01 <rm_work> and this proves there are some differences
20:23:08 <rm_work> so, what do we do about that
20:23:22 <xgerman_> backward compatible != parot every single thing n-lbaas does
20:23:31 <rm_work> k
20:23:43 <rm_work> that's one
20:23:54 <rm_work> i'd need another person to agree to get a merge, at least :P
20:24:23 <johnsom> I guess I am fine with patching octavia to slightly care about submitted project_ids on sub-objects. But on the otherhand I doubt it really matters/gets used, so skipping is ok too.
20:24:41 <rm_work> k
20:25:26 <johnsom> Let's move on in the agenda and come back to proxies in open discussion
20:25:31 <cgoncalves_> octavia resources are immutable on transient states. neutron-lbaas´ are not, or are so quick to flip between states that most users don´t notice it and hence further requests succeed
20:25:43 <xgerman_> +1
20:26:14 <johnsom> neutron-lbaas resources are in fact immutable during transitions.
20:26:31 <johnsom> It is true that some drivers will flip those back to active faster than others.
20:27:26 <rm_work> yes. though, neutron-lbaas also lies on returns for updates
20:27:32 <rm_work> whereas octavia does not
20:27:36 <rm_work> but yeah, let's move on and come back to this
20:27:44 <johnsom> The locking in neutron-lbaas is broken pretty badly and high rates of API requests can sometimes get through when it is in an immutable state.
20:27:54 <johnsom> Yep.
20:28:01 <johnsom> #topic Muttable config for neutron-lbaas
20:28:20 <johnsom> So there is a community goal to enable muttable Oslo configs in projects
20:28:26 <johnsom> (we still need to do that)
20:28:54 <johnsom> neutron-lbaas proper will inherit this from neutron as it runs under the neutron context.
20:29:04 <rm_work> i really think it has only one `t` ;P
20:29:19 <johnsom> However, there are some sub-processes in neutron-lbaas
20:29:29 <rm_work> do we even have to worry about n-lbaas
20:29:35 <rm_work> i say we skip it
20:29:47 <johnsom> Yeah, it does. Opps, copied over the typo from the agenda
20:30:06 <johnsom> So someone proposed a patch for neutron-lbaas to enable this:
20:30:07 <johnsom> #link https://review.openstack.org/#/c/559412/
20:30:20 <rm_work> ok, so, enable it for no actual vars right?
20:30:29 <rm_work> fine by me, merge that, call it done
20:30:42 <johnsom> I initially -1'd it because this is a feature IMO and these are sub-processes that probably don't matter much.
20:31:01 <johnsom> I see it was abandoned
20:31:07 <rm_work> My only point here is that we should not waste too much time on n-lbaas
20:31:12 <johnsom> So the question to the team is "do we care"?
20:31:14 <rm_work> doing something like this that just doesn't matter
20:31:17 <rm_work> so
20:31:21 <rm_work> obviously you know my answer
20:32:00 <johnsom> Well, that makes two votes of "don't care". Any other comments?
20:32:44 <xgerman_> I have seen people fixing bugs/making improvements on n-lbaas so if a patch show up…
20:32:47 <johnsom> Ok then, leaving it abandoned
20:33:21 <cgoncalves_> johnsom: you made a good point, though: n-lbaas runs under the neutron context so it will inherit from it. it would be half implemented if not extending to sub-processes
20:33:22 <johnsom> Fixing bugs is of course still important for neutron-lbaas, but features no.
20:33:38 <cgoncalves_> again, neutral vote from my side
20:33:59 <johnsom> Ok, I think we leave it as-is.
20:34:11 <johnsom> #topic Open Discussion
20:34:22 <johnsom> Ok, other topics?
20:35:10 <rm_work> <<
20:35:41 * johnsom taps the mic to see if it is on
20:35:47 <nmagnezi> just to keep everyone posted
20:36:08 <nmagnezi> we discussed the storyboard issues that were raised here a few weeks ago
20:36:16 <nmagnezi> with the storyboard team
20:36:20 <nmagnezi> see: http://eavesdrop.openstack.org/meetings/storyboard/2018/storyboard.2018-04-25-19.02.log.html#l-40
20:36:40 <nmagnezi> we will follow up next week.
20:37:08 <nmagnezi> #link http://eavesdrop.openstack.org/meetings/storyboard/2018/storyboard.2018-04-25-19.02.log.html#l-40
20:37:46 <johnsom> I also see some chatter in their IRC channel
20:38:09 <johnsom> Though it's "use tags" so maybe not what you are looking for.
20:38:34 <nmagnezi> indeed it's not..
20:38:54 <johnsom> cgoncalves_ Did we answer your neutron-lbaas questions (statement) above?
20:39:47 <cgoncalves_> johnsom: yes
20:40:59 <rm_work> sooo.... proxy?
20:41:00 <johnsom> Ok, yeah, the locking in neutron-lbaas would require a complete rewrite to completely fix. Oh, wait, I have that right here.......
20:41:19 <rm_work> lol yes
20:41:22 <rm_work> For the proxy thing, really the core question is: how backwards compatible do we need/want to be with neutron-lbaas?
20:41:31 <cgoncalves_> the kuryr folks were expecting octavia to be fully compatible with n-lbaas, including heat support. took some time to convince them it doesnt work as they would have hoped
20:41:46 <rm_work> really the only tests that don't pass when run directly against octavia are some of the negative stuff
20:42:01 <rm_work> I did find a couple of real bugs, which i have patches up for
20:42:16 <rm_work> cgoncalves_: so, what i am proving is that it CAN Be
20:42:32 <johnsom> cgoncalves_ Yes, it should be basically switching the endpoint. If it's not I would like to know what they ran into.
20:42:44 <rm_work> cgoncalves_: did you look at the proxy gate i am testing?
20:42:47 <xgerman_> there is such a big need for backwards compatibility that we have two proxies
20:42:52 <cgoncalves_> rm_work: pssssst! they could be reading :P
20:43:04 <johnsom> We are making the hard call to even pull forward some neutron bugs (IMO) to make it compat
20:43:11 <cgoncalves_> rm_work: not yours, no, sorry
20:43:36 <rm_work> cgoncalves_: i am literally putting haproxy in front of neutron, and L7-Redirecting calls to lbaas to the octavia API
20:43:56 <rm_work> so zero code changes, no neutron-lbaas installed at all, it will work
20:44:06 <rm_work> *zero code changes in end-user apps
20:44:20 <rm_work> it requires us to add a compatibility layer in octavia
20:44:29 <johnsom> At least up to the level the neutron-lbaas tempest tests  are testing
20:44:33 <cgoncalves_> johnsom: I quickly set up an env with neutron-lbaas+octavia driver and ran heat neutron-lbaas resources. it failed because of immutability so I hard stopped there
20:44:44 <rm_work> mainly it's about the deprecated tenant-id stuff
20:45:00 <xgerman_> cgoncalves_:  that won’t be fixed in any of them
20:45:03 <rm_work> cgoncalves_: well, our immutability is the same as neutron-lbaas, sooooo if that was broken, then it's broken for n-lbaas too
20:45:20 <rm_work> and if it works, it's only by sheer luck
20:45:38 <johnsom> cgoncalves_ I'm not following. Both use the PENDING_* states
20:46:13 <xgerman_> heat probably doesn’t wait
20:46:16 <johnsom> Was heat just not checking them in neutron-lbaas?
20:46:32 <cgoncalves_> ah, sorry. I meant to say an env with neutron-lbaas + proxy to octavia (not the octavia driver itself)
20:46:44 <rm_work> if so, that's broken for either neutron-lbaas OR octavia
20:46:47 <rm_work> cgoncalves_: my style of proxy or xgerman_'s?
20:46:54 <xgerman_> mine
20:46:55 <johnsom> lol
20:47:00 <cgoncalves_> rm_work: xgerman_'s
20:47:03 <rm_work> k
20:47:17 <johnsom> Ah, yeah, xgerman's proxy wasn't working until like this week
20:47:19 <xgerman_> but as I said earlier having tow proxies is confusing for users
20:47:29 <rm_work> yeah...
20:47:30 <xgerman_> it was working
20:47:44 <xgerman_> just not passing the tests
20:47:48 <johnsom> Not that I ever saw
20:47:50 <cgoncalves_> johnsom: I quickly had a look at the heat support for neutron-lbaas and there are some waiting/status polling
20:48:06 <johnsom> Ok, yeah, it should be "the same"
20:48:06 <rm_work> xgerman_: i'd rather not get into "there can only be one"
20:48:44 <rm_work> especially since, my "proxy" isn't actually anything
20:48:45 <rm_work> it's just a method
20:48:46 <rm_work> no code
20:49:02 <cgoncalves_> anyway, they were still using on n-lbaas because octavia doc was recommending that. I submitted a doc patch to fix that
20:49:02 <rm_work> but it is what i have been recommending and will continue to recommend
20:49:21 <johnsom> Yeah, that doc change merged right?
20:49:31 <cgoncalves_> yes
20:49:38 <johnsom> Cool
20:51:06 <johnsom> Yeah, I don't have a problem with providing options for folks migrating.
20:52:08 <johnsom> I don't think we want to "support" anything that isn't gating though. Plus I don't want to load up the octavia repo with stuff that is neutron-lbaas specific beyond having a compatible API.
20:52:23 <rm_work> yeah, need to decide exactly how to progress with that
20:52:44 <rm_work> the patch i have on the neutron-lbaas side is *just* a gate
20:52:46 <xgerman_> my plan is to fix the gate (obviously)
20:53:02 <rm_work> and a few test fixes (a lot of which are similar to / based on the ones in xgerman_'s proxy patch)
20:55:53 <johnsom> Is there something we need to decide here or just discussion of the parallel paths / options for migration?
20:56:44 <rm_work> wanted to ask if we should try to make octavia 100% compatible even with the negative test stuff
20:56:45 <rm_work> or if it's ok to just ignore some of those
20:56:46 <rm_work> because no one will likely see the difference
20:56:57 <rm_work> unless they were relying on neutron blocking bad calls
20:57:04 <rm_work> in a very specific way
20:57:57 <xgerman_> I think we should chart our own course … and only do stuff which was in the API doc and not some quirks n-lbaas had
20:58:07 <johnsom> The project_id on the sub-objects was an admin only thing that doesn't make any sense. As octavia is coded, it will "do the right thing", just silently instead of slapping your wrist.
20:58:20 <xgerman_> +1
20:58:51 <johnsom> Were there any others?
20:59:01 <rm_work> k that's pretty much it
20:59:10 <johnsom> Ok cool.
20:59:17 <johnsom> We are about out of time anyway.
20:59:28 <johnsom> Thanks folks!
20:59:43 <johnsom> #endmeeting