20:00:11 <johnsom> #startmeeting Octavia
20:00:12 <openstack> Meeting started Wed Mar 27 20:00:11 2019 UTC and is due to finish in 60 minutes.  The chair is johnsom. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:00:13 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:00:15 <openstack> The meeting name has been set to 'octavia'
20:00:35 <johnsom> Hi folks!
20:01:12 <rm_work> o/
20:02:08 <johnsom> Might be a quiet day. I know a few folks can't make it.
20:02:09 <cgoncalves> hi
20:02:53 <johnsom> #topic Announcements
20:03:02 <johnsom> Octavia projects RC1 has been released, stable branches are available
20:03:41 <johnsom> We can chat later and decide if we are ready to open Train.
20:04:16 <johnsom> As far as I can see, the RC1 will be our Stein release. Please let me know if you have concerns about bug fix patches you feel need to be in the Stein release.
20:05:03 <johnsom> Also of note, I have created the Octavia PTG planning etherpad
20:05:09 <johnsom> #link  https://etherpad.openstack.org/p/octavia-train-ptg
20:05:36 <johnsom> Please include if you are planning to attend or not and any topic ideas you think we should cover at the PTG.
20:06:10 <johnsom> rm_work Feel free to take this over as you will be the PTL in charge by then.
20:06:20 * johnsom Knows the answer to that....
20:06:38 <rm_work> I hereby delegate management of that to.... ..... Any takers? :D
20:06:56 <johnsom> I will try to keep it up to date and do a proposed schedule
20:08:05 <johnsom> Also of note,  there is a big re-name/re-org of the repositories being discussed.
20:08:07 <johnsom> #link http://lists.openstack.org/pipermail/openstack-discuss/2019-March/003825.html
20:09:01 <johnsom> and
20:09:03 <johnsom> #link http://lists.openstack.org/pipermail/openstack-discuss/2019-March/003603.html
20:09:32 <johnsom> So you will see patches changing from GIT protocol to HTTPS and some discussions about the repo names.
20:10:07 <johnsom> Any other announcements this week?
20:10:10 <cgoncalves> https://review.openstack.org/#/q/owner:iwienand%2540redhat.com+status:open+project:%255E.*octavia.*
20:10:46 <johnsom> Cool, thanks. I know at least one has already merged. We probably have lbaas patches too
20:11:05 <colin-> o/
20:12:51 <johnsom> Ah, another e-mail chain on the repo renames:
20:12:53 <johnsom> #link http://lists.openstack.org/pipermail/openstack-discuss/2019-March/003943.html
20:13:39 <johnsom> Any other announcements today?
20:14:41 <johnsom> #topic Brief progress reports / bugs needing review
20:15:08 <johnsom> Last week was all about getting the last bug fix patches in and the release cut.
20:15:39 <johnsom> I did do a tempest release for those folks that package it.
20:17:47 <cgoncalves> this last week I worked on fixing two issues related to VIP QoS policy: https://review.openstack.org/#/c/645817/
20:18:17 <cgoncalves> also addressed Michael's comment and submitted new patch set to the spare pool tempest test: https://review.openstack.org/#/c/634988/
20:18:53 <cgoncalves> reviews would be welcome
20:18:54 <johnsom> I also fixed an interesting issue with the client, where under some strange cases the API might return an error in HTML format if we don't explicitly ask it to return JSON. I didn't find it on the API side yet, but fixed the client to always ask for JSON.
20:19:07 <johnsom> Cool
20:19:36 <cgoncalves> we might want to include that fix in Stein GA rather than waiting until next dot release
20:20:02 <johnsom> Recently I have been helping figure out this super strange grenade job issue when going from queens. I think we have isolated it today, just need to come up with a good fix.
20:20:40 <johnsom> cgoncalves You want the QoS in Stein GA?
20:21:07 <cgoncalves> johnsom, no. I meant your client patch, although not necessary
20:21:29 <cgoncalves> Kong needed it fixed but I don't think he needs it for Stein GA
20:22:04 <johnsom> Yeah, technically the client is "release with intermediates" so other than the release team blocking it for Stein, we can release updates at any time
20:22:29 <cgoncalves> ah, as I transitioned from Vim/PyCharm to Visual Studio Code, I figured I'd also add support to their debugger (we support pydev today): https://review.openstack.org/#/c/645280/
20:22:43 <cgoncalves> ok, good to me
20:23:27 <johnsom> I hope we don't end up with a bunch of debugger specific code....
20:23:51 <cgoncalves> I'm okay dropping pydev in favor of VSCode :P
20:23:59 <johnsom> lol
20:24:10 <johnsom> Well, I think it's good to post it and let the cores decide.
20:24:26 <cgoncalves> sure
20:24:58 <johnsom> Any other updates today?
20:25:35 <johnsom> #topic Are we ready to open Train development?
20:25:53 <johnsom> I missed that on the agenda, but we should talk about it.
20:26:17 <johnsom> Basically the question is, are we comfortable enough with RC1 that we can start landing Train features?
20:26:51 <rm_work> We can always just backport anything right?
20:26:57 <rm_work> I mean, that's how we'd make an RC2 anyway
20:27:01 <johnsom> Yeah, it just gets slightly harder
20:27:15 <cgoncalves> "anything" == non API/DB changes, yes
20:27:55 <NobodyCam> I have a dumb question, should the lbaas network be external?
20:27:58 <johnsom> Personally I think we are good and could consider opening Train for feature merge
20:28:12 <rm_work> agree
20:28:18 <cgoncalves> +1
20:28:21 <johnsom> NobodyCam lb-mgmt-net? Not usually, but it "can" be
20:28:39 <NobodyCam> ack Thank you ... sorry didn't see meeting notice
20:28:58 <johnsom> Ok then, let's open Train for development!
20:29:12 * johnsom Swings his virtual Stein in the air
20:29:19 <openstackgerrit> Carlos Goncalves proposed openstack/octavia master: Add support to the Python Visual Studio Debugger  https://review.openstack.org/645280
20:29:55 <johnsom> Insert cheesy train whistle meme here
20:30:35 <johnsom> #topic Open Discussion
20:30:41 <johnsom> Other topics this week?
20:30:57 <colin-m> nothing from me
20:31:11 <cgoncalves> I had two things, can only remember of one...
20:31:19 <cgoncalves> ah!
20:31:30 <johnsom> Thank you again to everyone for your contributions to Stein!  We did a great job during that last push!
20:31:32 <johnsom> #link https://etherpad.openstack.org/p/octavia-priority-reviews
20:32:11 <cgoncalves> active-standby tempest test. Michael proposed one approach that relies on the existence of an API that is only avalable in >= Stein
20:32:35 <johnsom> Ah, yes, good topic.
20:32:41 <cgoncalves> I proposed another approach that relies on iptables to log VIP traffic, which could be run in stable versions
20:33:08 <cgoncalves> there are pros/cons on both. ultimately I think it would be better take either one or the other
20:33:46 <cgoncalves> nothing prevent us from having both and running Michael's test >= Stein and mine in <Stein releases
20:34:08 <cgoncalves> but would be more effort and slightly different tests in the end
20:34:14 <johnsom> Well, it's just more to maintain/duplicate tests. I think we should pick one and live with it.
20:34:42 <cgoncalves> #link https://review.openstack.org/#/c/637073/
20:34:49 <cgoncalves> #link https://review.openstack.org/#/c/584681/
20:35:14 <cgoncalves> thoughts?
20:36:11 <johnsom> If the iptables path seems stable now, I guess I would lean towards it just because it brings coverage to the older releases
20:36:29 <johnsom> I just worry about it be "fragile" due to the SSH/iptables stuff.
20:36:54 <cgoncalves> yeah, I understand
20:37:49 <cgoncalves> it has only passed the queens job thus far. it passed locally on master when I wrote it. if we agree to take that test, I'll resume the work
20:38:18 <johnsom> lol, how about we agree to take that test IF it works. grin
20:38:36 <cgoncalves> it WILL work -_-
20:39:03 <johnsom> That is my opinion. Maybe the new PTL has one as well?
20:39:12 <cgoncalves> :D
20:41:17 <johnsom> rm_work Thoughts on the active/standby tests?
20:41:38 <rm_work> i literally do not
20:41:49 <johnsom> Ok
20:42:06 <rm_work> oh, actually yes
20:42:13 <rm_work> but not that i can vocalize presently
20:42:26 <rm_work> I did a bunch of work for that previously
20:42:30 <johnsom> So, there you go, let's polish up cgoncalves test
20:43:09 <cgoncalves> Ok
20:43:34 <johnsom> I think you had another topic?
20:43:42 <openstackgerrit> Carlos Goncalves proposed openstack/octavia-tempest-plugin master: Add iptables-based active/standby scenario test  https://review.openstack.org/637073
20:44:24 <cgoncalves> first one question. I must confess I haven't had time to do my homework
20:44:44 * johnsom reaches for the ruler
20:44:51 <colin-m> inexcusable
20:44:51 <cgoncalves> what is the expectation when a LB is created in a given VIP network?
20:44:52 <cgoncalves> lol
20:45:12 <cgoncalves> I mean, should it listen on all of its subnets? like, ipv4 and ipv6
20:45:34 <johnsom> Yeah, this is a GREAT discussion for our new PTL.... grin
20:45:40 <rm_work> well, presently we don't expose multiple VIPs...
20:45:48 <colin-m> haha
20:45:51 <rm_work> which is ... problematic
20:46:02 <rm_work> This is a discussion to be had in Denver IMO
20:46:04 <cgoncalves> agreed, problematic
20:46:06 <johnsom> So, if you pass in a port, the decision is made for us.
20:46:13 <cgoncalves> right
20:46:22 <johnsom> If you pass in a subnet-id, it listens on *that* subnet.
20:46:34 <colin-m> yeah what was the intent originally good Q
20:46:47 <johnsom> If you pass in a network, right now it preferences the first IPv4 subnet that neutron returns
20:47:41 <cgoncalves> first IPv4 subnet or first subnet regardless of IP version?
20:47:51 <johnsom> It preferences IPv4
20:48:27 <johnsom> I know this off my head because I had some arguments about this in the past, lost, and grumble about the implementation.
20:48:36 <cgoncalves> Ok. we can talk about this at the PTG then as it seems will take some time
20:49:22 <johnsom> To me, only passing in a network doesn't make sense, but I know there are some "creative" cloud deployments that don't see it that way
20:49:49 <cgoncalves> one other question that gthiemonge raised today was when he created a LB with IPv6 VIP and then was trying to add an IPv4 member on the same VIP network
20:50:07 <johnsom> This is the code in quesiton:
20:50:09 <cgoncalves> IIRC his LB went to ERROR or didn't configure IPv4 at all
20:50:11 <johnsom> #link https://github.com/openstack/octavia/blob/master/octavia/api/v2/controllers/load_balancer.py#L138
20:51:10 <rm_work> yeah it seemed in my testing like if you created it with ipv4 it brought up both, but if you created with ipv6 it didn't bring up ipv4, which matters when you're using member-on-vip
20:51:31 <cgoncalves> yep
20:51:34 <johnsom> cgoncalves Hmmm, that is interesting. I may not have tested the cross-protocol stuff when it's on the same VIP and actually I know off my head that is broken.
20:51:57 <johnsom> This comes back to a discussion I was having with Nir where the whole member networking flow needs re-worked
20:51:58 <rm_work> yeah it's kinda a design issue
20:52:04 <rm_work> i think
20:52:34 <johnsom> Well, the member network flow is broken. It only thinks in terms of networks and not subnets (even though the API does).
20:52:51 <cgoncalves> Ok, good, sort of. wanted to confirm with you all if I was missing something or not
20:53:15 <johnsom> So in that case, it would have decided that since the VIP network was already plugged, it had nothing to do, where in reality, it should have setup the subnet.
20:53:42 <cgoncalves> exactly
20:53:49 <johnsom> There is an open story for this
20:54:23 <johnsom> If you are willing to wait long enough for storyboard to load
20:54:33 <cgoncalves> lol
20:55:06 <rm_work> yeah at some point i was hitting this pretty hard but then i left that org :D
20:55:50 <johnsom> #link https://storyboard.openstack.org/#!/story/2005038
20:56:19 <johnsom> That is the exact story cgonvalves
20:56:33 <cgoncalves> who? xD
20:56:49 <johnsom> opps, sorry
20:57:02 <cgoncalves> thank you! I'll share this with gthiemonge tomorrow
20:57:07 <johnsom> I think Nir was going to work on fixing the member network flows
20:57:28 <johnsom> He could not make the meeting today however.
20:57:51 <johnsom> We have three minutes left, any other topics today?
20:58:24 <cgoncalves> thank you all for the time and input. much appreciated!
20:58:42 <johnsom> Ok, thanks folks! Have a great week!
20:58:51 <rm_work> seriously why is storyboard taking so long, is it just me?
20:59:00 <johnsom> No, it's everyone
20:59:02 <johnsom> #endmeeting