16:02:17 <johnsom> #startmeeting Octavia 16:02:17 <openstack> Meeting started Wed Mar 31 16:02:17 2021 UTC and is due to finish in 60 minutes. The chair is johnsom. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:02:18 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:02:20 <openstack> The meeting name has been set to 'octavia' 16:02:41 <haleyb> should have run when i had the chance 16:02:41 <johnsom> Hi everyone 16:02:52 <gthiemon1e> hi 16:02:52 <johnsom> Yeah, got distracted commenting on a story 16:03:04 <johnsom> #topic Announcements 16:03:19 <johnsom> RC2 release today - Should be the final release for Wallaby 16:03:27 <johnsom> Any comments on the RC2 release? 16:03:32 <johnsom> I will post it right after the meeting 16:03:43 <gthiemonge> +1 16:03:53 <haleyb> lgtm 16:04:15 <johnsom> PTG (virtual and free) registration is open 16:04:24 <johnsom> #link https://www.openstack.org/ptg/ 16:04:36 <johnsom> gthiemonge set up the PTG etherpad 16:04:43 <johnsom> #link https://etherpad.opendev.org/p/xena-ptg-octavia 16:04:59 <johnsom> Please note if you plan to join and add any topics you think we should discuss 16:05:11 <johnsom> Any other announcements this week? 16:05:59 <johnsom> #topic Brief progress reports / bugs needing review 16:06:14 <johnsom> I have been mostly focused on getting the patches merged for RC2. 16:06:41 <johnsom> I fixed the bug with older amphora and the new pools ALPN feature. This will be included in RC2 16:07:45 <johnsom> Currently I am looking into why the tempest tests for pool re-encryption are failing now. It looks like the floating IP (test created) is not passing traffic for some reason. Not sure if that is a known neutron issue or not 16:07:52 <gthiemonge> I've been working on some updates in the Octavia integration in tripleo 16:09:00 <gthiemonge> and I'm still looking at the ipv6+tcp+least_connection+allowed_cidrs scenario test that fails randomly 16:09:18 <haleyb> and i've been working on the ovn-provider and some downstream gate issues 16:09:21 <johnsom> Thanks, that is annoying 16:10:08 <johnsom> #topic Open Discussion 16:10:12 <johnsom> Any other topics today? 16:11:18 <gthiemonge> yep 16:11:20 <gthiemonge> one question 16:11:28 <johnsom> Just in time, lol 16:11:57 <gthiemonge> a user reported on the ML that not configuring "heartbeat_key" breaks the heartbeat message encryption 16:12:22 <gthiemonge> when not setting heartbeat_key, the default is None 16:12:53 <gthiemonge> in the amp we encrypt using "str(heartbeat_key)" while in the hm we decrypt using "heartbeat_key" 16:13:12 <gthiemonge> so in the case of None, str(None) != None 16:13:26 <haleyb> i'm assuming this review was from that, https://review.opendev.org/c/openstack/octavia/+/784022 16:13:32 <johnsom> hmmm, I would have expected that to be marked "required" in config.py as well.. 16:13:39 <gthiemonge> my question is: should we fix it? or should we set another default value for heartbeat_key 16:14:01 <cgoncalves> ah, reminds me of https://review.opendev.org/c/openstack/octavia/+/595578/1/octavia/common/config.py@196 16:14:48 <johnsom> cgoncalves Yeah, good point 16:15:19 <gthiemonge> https://opendev.org/openstack/octavia/src/branch/master/octavia/certificates/common/local.py#L32-L33 16:15:32 <gthiemonge> ^ we already have insecure defaults for some other config settings 16:16:18 <johnsom> Well, that is different. That key is only used for internal to the controller content, not stuff that goes over the wire. 16:16:46 <johnsom> It's a poorly named setting IMO 16:18:02 <johnsom> Hmm, yeah, the heartbeat key is an interesting one. There is no harm in setting it even if the amphora drivers are not used. 16:18:33 <johnsom> It is bad to have that content unprotected by allowing None 16:18:48 <johnsom> But we also shouldn't fail like it is 16:18:50 <gthiemonge> it's encrypted, but the key is None ;-) 16:19:12 <johnsom> It's actually not encrypted, but it's signed 16:19:45 <gthiemonge> the heartbeat_key was missing in the install-ubuntu doc, and there's a patch to add it 16:20:24 <gthiemonge> but I think we also need to have a working default value 16:20:39 <johnsom> Or require it be set to something 16:21:24 <gthiemonge> yeah that could be a good fix 16:21:36 <gthiemonge> with the fix in the doc 16:22:16 <gthiemonge> I'll propose a patch 16:23:26 <johnsom> Ok. It is a bit cheesy to require it even for providers that don't use it, but that might just be simpler 16:26:11 <johnsom> Ok, anything else today? 16:27:20 <johnsom> Ok, thanks everyone 16:27:24 <johnsom> #endmeeting