16:01:05 <rm_work> #startmeeting Octavia
16:01:05 <openstack> Meeting started Wed Dec  9 16:01:05 2020 UTC and is due to finish in 60 minutes.  The chair is rm_work. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:01:06 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:01:08 <openstack> The meeting name has been set to 'octavia'
16:01:13 <johnsom> Opps, yes, thanks
16:01:21 <gthiemonge> Hi
16:01:23 <rm_work> o/
16:01:31 <mchlumsky> Hello
16:01:41 <johnsom> #topic Announcements
16:01:56 <mchlumsky> Hi guys! I just want to introduce myself. My name is Martin Chlumsky and I work at Ubisoft. We have several hundred loadbalancers in Octavia (Stein) in several Openstack deployments. I've been tasked to improve our Octavia deployments (upgrade to Ussuri, better monitoring, etc...) so you'll see me in here asking questions and I'd like to contribute
16:01:56 <mchlumsky> where I can (time permitting). :)
16:02:02 <johnsom> After today I am on vacation until January 4th
16:02:26 <rm_work> #chair johnsom
16:02:26 <openstack> Current chairs: johnsom rm_work
16:02:27 <johnsom> mchlumsky Welcome!
16:02:45 <rm_work> #topic Announcements
16:02:53 <johnsom> Opps, lol
16:03:01 <rm_work> now you're good :D
16:03:06 <johnsom> I will repeat myself: After today I am on vacation until January 4th
16:03:23 <gthiemonge> johnsom: enjoy!
16:03:25 <johnsom> mchlumsky This channel is a great resource to ask questions about Octavia.
16:03:31 <rm_work> Similar for me after next week -- I think i have one more meeting in me
16:04:08 <mchlumsky> johnsom I noticed already giot a few answers. thanks! :)
16:04:14 <johnsom> Nice, enjoy your break
16:04:57 <johnsom> Any other announcements this week?
16:05:48 <johnsom> #topic Brief progress reports / bugs needing review
16:06:15 <johnsom> I have mostly been working on reviews and poking at the bandit issues on stable/stein. Otherwise downstream work
16:07:24 <gthiemonge> Can we start using the priority review etherpad? I know that some people have added patches to the awaiting prioritization list...
16:07:53 <rm_work> yeah I really need to get back in the groove of reviews
16:07:55 <johnsom> Yeah, good question. Milestone 1 has now passed
16:08:09 <rm_work> my guess is the first opportunity i'll have to do so will really be in January
16:09:13 <johnsom> gthiemonge I would say feel free to freshen up the priority review etherpad and get it started for Wallaby
16:09:55 <gthiemonge> ok, I'll update the list tomorrow
16:10:52 * johnsom likes not being PTL this cycle and still delegating. grin
16:11:12 <johnsom> Any other updates this week?
16:11:32 <johnsom> Thank you all for helping review the stable branch patches. I think we have made good progress this week
16:11:51 <johnsom> #topic Stable/Stein gate jobs are broken due to bandit py27->py3x transition
16:12:21 <johnsom> As you may have seen on the openstack-discuss e-mail list, bandit released a version that no longer supports python2.7.
16:12:39 <johnsom> This broke a number of projects including the stable/stein branch test jobs.
16:13:10 <johnsom> rm_work and I have poked at the issue and I will probably spend a bit of time on that today again.
16:13:26 <johnsom> This is blocking some of our tempest patches from passing.
16:14:00 <johnsom> We will pin bandit on the stein branch to a version that supports python2.7
16:14:19 <johnsom> #topic Open Discussion
16:14:24 <johnsom> Any other topics this week?
16:14:31 <mchlumsky> I have a story I would like to work on (https://storyboard.openstack.org/#!/story/2008060) as we will likely need this feature. I think it should be labelled as a RFE (but I'm not too sure of the complexity of the change yet so maybe it's a spec?). I might require some guidance but I'll reach out unless you have some vital pieve of information to
16:14:31 <mchlumsky> give me right now. ;)
16:15:56 <johnsom> Ah, yeah. So, basically you will want to enable changing that setting and then trigger a load balancer failover process to enact the change.
16:17:07 <johnsom> I would advise against trying to hot-change CPU or RAM via nova as it unfortunately triggers an instance reboot, which can cause the security content (TLS keys) to be lost, which will trigger a failover as well.
16:17:30 <mchlumsky> Would this be done via 2 separate API operations? or can this be done behind the scenes via a PUT to the LB?
16:17:32 <johnsom> Does that align to your thoughts?
16:17:53 <johnsom> You can do it all behind one API call
16:19:22 <mchlumsky> I won't touch anything on the nova side. I was totally thinking of doing a failover to get this done. I'm just not sure what will happen when you change the topology from active-standby to standalone for example
16:20:07 <rm_work> you'd need to delete the backup basically, and send a new config to the remaining amp, generated with STANDALONE as the type
16:20:11 <johnsom> Well, with the changes I made during Victoria to the failover flow, it should handle the case ok. It will just think that nova lost one of the amphora instances.
16:20:24 <rm_work> but yeah, the failover flow itself should basically just "do that"
16:20:52 <rm_work> new failover flow is great! :thumbsup:
16:21:09 <johnsom> I think I would do a full LB failover. I wouldn't mess with converting an existing instance. Converting would mean a lot of changes inside the amp (keepalived, etc.) that just isn't worth it
16:21:36 <rm_work> ah yeah that's probably cleanest
16:21:47 <mchlumsky> ok, great.
16:22:13 <rm_work> actually yeah, would it literally just be changing the topo to standalone, and triggering the failover? XD
16:22:34 <johnsom> Yeah, pretty much. The tricky part is handling the rollback correctly maybe.
16:22:35 <rm_work> i suppose that might just work
16:23:01 <mchlumsky> thanks for making this all so easy for me :p
16:23:20 <johnsom> So, I think this is pretty straight forward and we had a good discussion on it. I'm not sure it needs a full spec to hammer out the details. I would just tag this story as RFE and propose the change
16:24:06 <mchlumsky> awesome.
16:24:55 <johnsom> Any other topics this week?
16:25:01 <gthiemonge> yes! here
16:25:17 <gthiemonge> one of my colleagues is working on a tempest test for TLS
16:25:21 <gthiemonge> https://review.opendev.org/c/openstack/octavia-tempest-plugin/+/763169
16:25:29 <gthiemonge> it looks like it's failing on stein
16:26:02 <gthiemonge> I'm wondering if it's worth it to spend some time to fix stein, or we could just skip the test for some old releases
16:26:37 <johnsom> Well, if the feature was present in stein, we should not skip the test.
16:27:06 <rm_work> how long until we can EOL stein again? :D
16:27:27 <rm_work> we should really be doing one EOL per cycle...
16:27:30 <rm_work> what's up next?
16:27:38 <johnsom> For one thing, I would strongly advise to not change the existing tests, but add additional.
16:27:59 <gthiemonge> ok, we can check the test in stein... perhaps one backport is missing there
16:28:06 <johnsom> It appears the existing tests were incorrectly modified
16:29:29 <gthiemonge> I haven't reviewed the patch yet... but yeah the issue might be in the test itself
16:29:55 <johnsom> I can review later, but that is my first comment. Don't change existing tests unless absolutely necessary.
16:30:27 <gthiemonge> ok thanks
16:30:43 <johnsom> Especially with the TLS tests, it's easy and quick to just create another listener for your new test case.
16:31:03 <johnsom> The current TLS tests are very detailed and still valid IMO
16:32:48 <johnsom> Any other topics to raise?
16:33:59 <johnsom> Ok, thanks everyone. Have a great week and holiday!
16:34:12 <gthiemonge> johnsom: thank you
16:34:15 <johnsom> #endmeeting