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