16:00:21 <gthiemonge> #startmeeting Octavia
16:00:21 <opendevmeet> Meeting started Wed Jan  4 16:00:21 2023 UTC and is due to finish in 60 minutes.  The chair is gthiemonge. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:21 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:21 <opendevmeet> The meeting name has been set to 'octavia'
16:00:33 <tweining> o/
16:00:37 <gthiemonge> o/ HNY!
16:00:48 <oschwart> o/ HNY!
16:00:50 <johnsom> o/
16:02:55 <gthiemonge> #topic Announcements
16:03:08 <gthiemonge> * Deadline for CFP on Jan 10th
16:03:20 <gthiemonge> FYI the deadline for the Call for Paper for the 2023 OpenInfra summit is closing soon (Jan 10th)
16:03:27 <gthiemonge> #link https://cfp.openinfra.dev/app/vancouver-2023/19/presentations
16:05:01 <gthiemonge> any other annoucements?
16:05:15 <johnsom> MS2 is next week
16:05:34 <tweining> yeah, in a bit more than a month is feature freeze I think
16:05:39 <johnsom> Correction, this week
16:06:00 <johnsom> Yeah, feature freeze is Feb 13th
16:06:05 <johnsom> That week
16:06:16 <johnsom> Also, the virtual PTG registration is now open:
16:06:28 <gthiemonge> wow next week
16:06:37 <tweining> so time for updating the review priorities soon I guess
16:06:37 <johnsom> #link https://openinfra.dev/ptg/
16:06:44 <gthiemonge> tweining: I agree
16:07:24 <gthiemonge> thanks for the heads-up folks
16:09:37 <gthiemonge> #topic CI Status
16:09:47 <gthiemonge> the fix for tox4 was merged on master
16:09:54 <gthiemonge> thank you to those who have worked on it!
16:10:16 <gthiemonge> and the backports are in review on stable branches! thanks tweining!
16:10:22 <gthiemonge> #link https://review.opendev.org/q/I5ac930e0d3928bb8acba4212dfff25f788acd442
16:10:28 <tweining> np
16:11:41 <tweining> at least I learnt how to debug such issues on Zuul nodes directly, so it wasn't completly wasted time ;)
16:12:08 <gthiemonge> FYI our tempest jobs are still based on Ubuntu Focal, we have a commit that updates them to Jammy (on master) that has been waiting for a long time
16:12:11 <gthiemonge> #link https://review.opendev.org/c/openstack/octavia-tempest-plugin/+/861369
16:16:27 <oschwart> gthiemonge: ack, I will review too
16:16:33 <gthiemonge> thanks
16:16:38 <gthiemonge> #topic Brief progress reports / bugs needing review
16:17:02 <tweining> there are lots of small changes can can be reviewed quickly
16:17:12 <tweining> *that an
16:20:02 <gthiemonge> I have one important fix: fix listener creation with fully-populated API (only for SINGLE topology):
16:20:10 <gthiemonge> #link https://review.opendev.org/c/openstack/octavia/+/868423
16:20:31 <gthiemonge> we could also review the associated tempest test (yeah, it's still not covered by the CI)
16:20:54 <gthiemonge> #link https://review.opendev.org/c/openstack/octavia-tempest-plugin/+/824999
16:21:02 <gthiemonge> (V-1 we need to take a look)
16:21:40 <gthiemonge> another change is about losing the qos_policy_id after a failover of a LB:
16:21:44 <gthiemonge> #link https://review.opendev.org/c/openstack/octavia/+/868994
16:24:05 <oschwart> I will review and test it
16:24:38 <tweining> I continued to work on removing neutronclient, but we can discuss that during open discussion
16:25:14 <gthiemonge> #topic Open Discussion
16:25:15 <gthiemonge> :)
16:25:25 <tweining> https://review.opendev.org/q/topic:remove-neutronclient+project:openstack/octavia
16:25:59 <tweining> I will squash it into 1 patch later but for now it's easier for me to track the changes that way
16:26:26 <tweining> so one issue I ran into is grenade
16:26:47 <tweining> old config needs to work with new code apparently
16:27:09 <gthiemonge> johnsom: do you confirm?
16:27:43 <johnsom> We need to maintain compatibility such that upgrades don't break
16:27:49 <gthiemonge> ok
16:27:52 <johnsom> Via deprecation cycles
16:28:15 <gthiemonge> hmm ok
16:28:22 <johnsom> https://docs.openstack.org/oslo.config/latest/reference/deprecating.html
16:28:43 <johnsom> But, it is best to "just have the code fix/do the right thing".
16:28:51 <johnsom> What is the specific config issue you hit?
16:28:59 <gthiemonge> there are some helpers in keystoneauth that automatically add options for authentication to the config parser
16:29:00 <johnsom> auth_url?
16:29:04 <gthiemonge> that would be nice to use them
16:29:20 <gthiemonge> but for instance, they add a 'endpoint_override' while we have already a 'endpoint' for the same purpose
16:29:25 <gthiemonge> how could we deal with that?
16:29:30 <tweining> mmh, I need to check. it happened last year ;)
16:30:11 <gthiemonge> ok, so in case of missing params in [neutron], we could use for instance the value from [service_auth]
16:30:22 <johnsom> Well, originally we had to do things a bit more manually (couldn't use the keystoneauth parsers) because we have separate configs for each service we talk to. So it doesn't know how to parse them correctly or where they are.
16:30:33 <tweining> yeah "Auth plugin requires parameters which were not given: auth_url"
16:31:19 <johnsom> Some clouds did "odd" things like having neutron in a different region than nova for example.
16:31:41 <johnsom> So they had to have full duplicates of the config settings for EACH service
16:31:50 <gthiemonge> yeah, so now, it means that we would have multiple openstacksdk connections (with different parameters)
16:32:15 <johnsom> So, service_auth section was purely for talking with keystone, the others were for nova, neutron, glance, etc.
16:32:42 <johnsom> Yeah, that is how it is today, multiple client connections
16:33:10 <johnsom> We  use singletons, so we only create one "instance" per service
16:34:46 <tweining> when using the ks_loading functions in combination with the neutron config section (which seemed the right thing to do) I noticed that it doesn't work if ovn provider is used because it uses that section too.
16:34:54 <johnsom> For the auth_url, I think it would be fair to default back to the service_auth settings if it's not defined, but I'm not sure oslo.config will make that easy.
16:35:00 <tweining> but gthiemonge found a way to work around that
16:36:00 <johnsom> OVN provider should NOT be defining config settings that overlap with ours. They could use what we have, but should  not add overlapping config sections.
16:36:42 <tweining> gthiemonge said if it breaks their stuff they need to fix it
16:37:02 <gthiemonge> we can also help them :D
16:37:09 <johnsom> Yeah, if they are adding config settings that overlap sections we define, that is an OVN provider bug
16:37:22 <tweining> yeah, what I mean is that it is not blocking the change
16:37:54 <johnsom> right
16:39:28 <johnsom> On a side note, you don't want to break config settings during upgrade, world-plus-dog will hate you as all 16 deployment tool projects will break.
16:40:26 <gthiemonge> yeah
16:42:15 <tweining> ok, thanks guys. so I understand using a separate neutron section in the config is okay, but code should use service_auth if it doesn't exist in the config.
16:42:27 <johnsom> Extra credit: I don't think our provider driver development guide talks about config settings, we might want to add a section saying that any config settings added by a provider driver must be name spaced to the provider driver.
16:42:44 <johnsom> I think that is fair, yes.
16:45:04 <gthiemonge> johnsom: thanks
16:47:13 <gthiemonge> anything else folks?
16:48:17 <tweining> only that we need to increase review speed
16:48:43 <johnsom> My time is pretty limited for reviews
16:48:45 <gthiemonge> I will restore the etherpad
16:48:58 <johnsom> So, yeah, prioritizing is going to be key to getting my time
16:50:15 <tweining> some changes are really tiny and should only take a minute or so
16:50:56 <johnsom> Yeah, but I can't track the patches in octavia like I used to be able too. I'm spread over a lot of projects now
16:51:20 <johnsom> So, hints, nags, priority lists are going to be your best bet
16:52:04 <tweining> johnsom: https://review.opendev.org/c/openstack/octavia/+/858739 whould be a good start :)
16:52:31 <tweining> thanks. that's all from me.
16:53:40 <oschwart> Nothing from me
16:54:13 <gthiemonge> Ok Folks!
16:54:23 <gthiemonge> Thank you, really interesting talks!
16:54:26 <gthiemonge> #endmeeting