16:00:20 <gthiemonge> #startmeeting Octavia
16:00:20 <opendevmeet> Meeting started Wed May  3 16:00:20 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:20 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:20 <opendevmeet> The meeting name has been set to 'octavia'
16:00:22 <gthiemonge> o/
16:00:31 <tweining> o/
16:01:04 <johnsom> o/
16:02:18 <gthiemonge> #topic Announcements
16:02:25 <gthiemonge> * Octavia Forum Session at Vancouver
16:02:42 <gthiemonge> FYI The Octavia Forum Session will be Wednesday, June 14th (9am)
16:02:52 <johnsom> Yep, it is scheduled for Wednesday morning at 9am
16:03:18 <tweining> what time is that in CEST?
16:03:33 <tweining> and, will it be streamed somehow?
16:04:22 <gthiemonge> well I don't think it will be streamed
16:04:31 <gthiemonge> I didn't see an announcement about it
16:04:48 <tweining> ok, then forget my questions
16:05:32 <johnsom> No, I don't think they will be streaming the forum sessions
16:05:48 <johnsom> I will be this time slot however
16:07:22 <gthiemonge> * Bobcat Release Schedule
16:07:34 <gthiemonge> tweining has updated the review list etherpad with our priorities for the next milestones
16:07:40 <gthiemonge> #link https://etherpad.opendev.org/p/octavia-priority-reviews
16:07:45 <gthiemonge> priority #1 is python-neutronclient removal
16:07:49 <gthiemonge> #link https://review.opendev.org/c/openstack/octavia/+/866327
16:07:59 <gthiemonge> johnsom: you gave a CR+2 before it was rebased, could you take another look?
16:08:11 <johnsom> Sure, NP
16:08:37 <gthiemonge> thanks!
16:09:59 <gthiemonge> #topic CI Status
16:10:12 <gthiemonge> the Ubuntu Jammy nested-virt nodes are ok now
16:10:20 <gthiemonge> the vexxhost nodes were removed
16:10:20 <johnsom> Oh good
16:10:33 <gthiemonge> (the latest issue was random mirror issues that is under investigation)
16:10:43 <gthiemonge> so the question:
16:10:49 <gthiemonge> should we merge "Updating Octavia tempest jobs on Ubuntu jammy (22.04)" now?
16:10:55 <gthiemonge> #link https://review.opendev.org/c/openstack/octavia-tempest-plugin/+/861369
16:11:06 <gthiemonge> in case those nodes are re-enabled we might be exposed to new failures
16:11:19 <gthiemonge> or should we expect that if they re-enable the nodes, they should work as expected?
16:11:24 <gthiemonge> what do you think?
16:11:44 <johnsom> I think it's ok to merge if it's passing
16:11:54 <johnsom> We should remove that centos 8 job too
16:11:58 <johnsom> in another patch
16:12:05 <gthiemonge> yeah
16:12:11 <gthiemonge> ok, I'm +2 it
16:12:34 <tweining> I concur
16:12:55 <gthiemonge> we also need to add zed(!) and antelope jobs (zed is in the chain)
16:13:23 <gthiemonge> gmann has also a patch for the CI jobs, I'll rebase it
16:13:45 <gthiemonge> johnsom: could you also review https://review.opendev.org/c/openstack/octavia-tempest-plugin/+/861369 ?
16:14:13 <tweining> that was fast :)
16:14:25 <gthiemonge> thanks!
16:15:12 <gthiemonge> #topic Brief progress reports / bugs needing review
16:15:21 <gthiemonge> I have 2 bugfixes that need reviews:
16:15:26 <johnsom> gthiemonge I already did +2 that one
16:15:31 <gthiemonge> +1
16:15:35 <gthiemonge> #link https://review.opendev.org/c/openstack/octavia/+/881728
16:15:49 <gthiemonge> this patch fixes the incorrect removal of one IP rule in the amphora namespace
16:16:02 <gthiemonge> with some specific network topologies, the bug makes the VIP unresponsive
16:16:14 <gthiemonge> it is backport candidate to >=wallaby
16:16:25 <gthiemonge> and I also have:
16:16:30 <gthiemonge> #link https://review.opendev.org/c/openstack/octavia/+/881719
16:16:39 <gthiemonge> it fixes a potential bug when plugging a new member subnet into the amp
16:16:46 <gthiemonge> see https://bugs.launchpad.net/octavia/+bug/2017894
16:17:00 <gthiemonge> it affects all the releases (>=train)
16:17:28 <gthiemonge> tweining had an interesting question, because I added an hardcoded value to a loop
16:17:33 <gthiemonge> #link https://review.opendev.org/c/openstack/octavia/+/881719/comment/4fd18ed7_78438fab/
16:17:57 <gthiemonge> maybe I should set a more reasonable value, or I should remove the upper limit, but I don't like to add a possible infinite loop
16:18:44 <tweining> my concern was mostly about test performance, although the number isn't huge really
16:19:02 <gthiemonge> the loop should never go that far
16:19:30 <gthiemonge> unless a user adds 65k members with their own networks
16:19:47 <tweining> https://review.opendev.org/c/openstack/octavia/+/881719/2/octavia/tests/unit/amphorae/backends/agent/api_server/test_plug.py#447
16:19:56 <johnsom> One other thing there, we always work with MAC addresses and never trust the interface name.
16:20:10 <johnsom> Interface naming changes release to release and across distros
16:20:26 <gthiemonge> it is used for renaming the new interface in the ns
16:20:31 <johnsom> I was very careful in the old code to never rely on the name unless we set it
16:21:08 <gthiemonge> I mean, this name is only used when renaming the iface, and in other calls, we use the hwaddr
16:21:48 <johnsom> Ok, I will take some time looking at this patch. Historically we used the interface file to make sure we had no name conflicts, etc.
16:21:49 <gthiemonge> we could use "eth<network_uuid>"
16:22:19 <johnsom> Nah, short is fine, just want to make sure we don't make assumptions that will break on other distros
16:22:58 <gthiemonge> ok
16:24:38 <tweining> I'm mostly done with my work on the new HSTS feature, but there might be some detail fixes while I'm still testing
16:24:39 <tweining> https://review.opendev.org/q/topic:hsts-haproxy+-is:wip
16:25:24 <tweining> for some reason the new tempest test times out in my devstack env, but I think it succeeded in Zuul, so it's probably a configuration issue with my environment
16:25:44 <gthiemonge> ack, the priority is the octavia-lib patch, because we need a new release for the other patches
16:26:30 <johnsom> Right
16:29:30 <gthiemonge> #topic Open Discussion
16:30:22 <tweining> regarding that octavia-lib change you talked. there is a parent patch: https://review.opendev.org/c/openstack/octavia-lib/+/881701/2
16:31:11 <tweining> it is similar to the db model repr() implementation I did last year. I'll need to check if there are fields that might be security sensitive.
16:32:17 <gthiemonge> ack
16:32:52 <tweining> also, since I hate stestr I worked on adding support for running unit tests and functional tests with pytest
16:32:57 <tweining> for octavia, not octavia-lib
16:33:17 <tweining> https://review.opendev.org/q/topic:tox-pytest
16:33:32 <gthiemonge> tweining: what are the main differences?
16:34:13 <tweining> much more convenient to use. just look at the options that pytest offers.
16:35:20 <tweining> I also love pytest for its fixtures and ease of use, but we're uses standard unittest style tests, so that is not a benefit in our case
16:35:50 <gthiemonge> johnsom: do we have some requirements on those tools?
16:36:01 <gthiemonge> johnsom: stestr vs pytest
16:36:20 <tweining> pytest can also run tests in parallel and I noticed that certain tests fail when I run them in parallel. that is a sign that there is something wrong with some tests
16:36:56 <johnsom> Yeah, I think there is an OpenStack standard for that. I vaguely remember it when we switched the tool, testr->ostestr->stester
16:37:14 <johnsom> All our tests run in parallel
16:37:27 <tweining> I saw that some openstack projects do use pytest
16:37:59 <tweining> yeah, but stestr runs them differently aparently
16:38:08 <johnsom> For example: 2023-05-03 13:45:00.458197 | ubuntu-jammy | {7} octavia.tests.unit.common.tls_utils.test_cert_parser.TestTLSParseUtils.test_validate_cert_and_key_match [0.138818s] ... ok
16:38:21 <johnsom> The {7} means it is running on the seventh thread
16:39:15 <johnsom> The current system also randomizes the order of the tests
16:39:55 <gthiemonge> we could ping openstack-qa to get their feedback on it
16:39:59 <tweining> IDK, that might play a role.
16:40:55 <tweining> just to be clear: I do not propose to use pytest instead of stestr
16:41:22 <tweining> my patch only adds pytest as an option and as new tox test envs
16:41:38 <tweining> pytest-unit and pytest-func
16:42:02 <gthiemonge> ack
16:44:21 <gthiemonge> ok folks, any other topics?
16:46:24 <gthiemonge> ok!
16:46:38 <gthiemonge> thank you!
16:46:41 <gthiemonge> #endmeeting