16:00:50 <gthiemonge> #startmeeting Octavia
16:00:50 <opendevmeet> Meeting started Wed Jun 16 16:00:50 2021 UTC and is due to finish in 60 minutes.  The chair is gthiemonge. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:50 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:50 <opendevmeet> The meeting name has been set to 'octavia'
16:00:57 <gthiemonge> Hi
16:01:07 <johnsom> o/
16:01:17 <haleyb> hi
16:01:42 <gthiemonge> #topic Announcements
16:01:56 <gthiemonge> functional tests are broken on octavia master - related to sqlachemy 1.4?
16:02:06 <gthiemonge> #link https://zuul.opendev.org/t/openstack/build/76fb5298a6b54152bc67722a10e18a23
16:02:14 <rm_work> o/
16:02:19 <rm_work> Hmm maybe
16:02:36 <gthiemonge> I'm going to take a look after the meeting, unless someone has an idea
16:02:42 <rm_work> I put up a patch that I think is also related, with duplicate member creation error handling
16:03:07 <johnsom> "Deferred loader for attribute 'pool_id' failed to populate correctly" lol
16:03:29 <rm_work> Where's zzzeek lol
16:03:44 <gthiemonge> there are a bunch of other errors in the same job
16:03:57 <gthiemonge> TypeError: unsupported operand type(s) for +: 'ImmutableColumnCollection' and 'list'
16:04:45 <haleyb> Database health check failed due to: boom.: Exception: boom
16:04:50 <haleyb> that's a nice exception
16:05:07 <johnsom> Thanks
16:05:11 <rm_work> XD
16:05:22 <rm_work> Yeah that one was probably typed into the test data
16:05:36 <rm_work> Mocked exception ;)
16:05:40 <johnsom> I used that for an expected failur
16:05:52 <rm_work> ^^ yeah in a bunch of places
16:06:13 * johnsom is in a parallel meeting, so slightly distracted
16:07:14 <gthiemonge> next announcement/topic is:
16:07:23 <gthiemonge> lower-constraints jobs are broken on python-octaviaclient stable branches (<=victoria)
16:07:27 <gthiemonge> another one!
16:07:32 <gthiemonge> #link https://zuul.opendev.org/t/openstack/build/a2ae26e5c9e9442caa04ac5e1addeccd
16:08:02 <gthiemonge> There are at least 3 stable branches affected:
16:08:12 <gthiemonge> #link https://review.opendev.org/q/project:openstack%252Fpython-octaviaclient+status:open
16:09:19 <gthiemonge> and I can see other errors on train
16:09:21 <haleyb> were we going to drop those jobs from stable branches?  i think other components did
16:10:01 <haleyb> oh, we did in octavia too
16:10:01 <gthiemonge> Yeah we can drop the lower-constraints job on stable branches, I think we already did it in the past for similar reason
16:10:05 <johnsom> No. we decided not to as our tests, unlike some other projects, actually test lower constraints
16:10:25 <johnsom> Yeah, I think we agreed that stable could go
16:11:28 <gthiemonge> ok
16:11:43 <gthiemonge> I'll take a look at those patches as well
16:11:59 <haleyb> johnsom: so was that a yes or a no?
16:12:09 <rm_work> yes for stable-branches, no for master branch
16:12:12 <rm_work> AFAIU
16:12:23 <johnsom> Yes for stable. No we are not going to remove it for the main branch
16:12:28 <johnsom> Right
16:12:33 <gthiemonge> rm_work: Yes, that was our agreement from a previous meeting
16:12:43 <rm_work> then we're all agreed! again! :D
16:13:09 <haleyb> agreed, can do like we did for octavia repo then
16:13:14 <gthiemonge> yep
16:13:18 <gthiemonge> great!
16:13:41 <gthiemonge> any other announcements?
16:14:50 <gthiemonge> ok
16:15:02 <gthiemonge> #topic Brief progress reports / bugs needing review
16:15:48 <gthiemonge> not such much upstream work for this week, I've been focusing on downstream tasks.
16:16:06 <gthiemonge> but I proposed a commit to disable conntrack for TCP connections in the amphora
16:16:31 <gthiemonge> #link https://review.opendev.org/c/openstack/octavia/+/796608
16:16:46 <johnsom> Yeah, all I have is the client patch for large cloud improvements and the associated backports
16:17:02 <gthiemonge> conntrack is always enabled in Octavia but we should use it only for LVS-based listeners (UDP/SCTP)
16:17:13 <johnsom> +1 to that
16:17:39 <johnsom> Wish we could just remove that kernel module again, but at least we can bypass it for non-UDP based traffic
16:17:39 <gthiemonge> I heard people complaining about the kernel messages that are logged when the conntrack table is full, and then an haproxy with a high maxconn was killed by the oom-killer.
16:18:20 <rm_work> bleh :/
16:18:35 <rm_work> oh, so probably (maybe?) related to SQLAlchemy upgrade: https://review.opendev.org/c/openstack/octavia/+/795637
16:18:46 <rm_work> i should update the title to mention it's also for listeners, pre-emptively
16:22:17 <gthiemonge> #topic Open Discussion
16:22:25 <gthiemonge> Any other topics today?
16:22:42 <haleyb> can we decide on an irc channel? :-p
16:22:45 <haleyb> https://review.opendev.org/c/openstack/project-config/+/793999
16:22:53 <gthiemonge> johnsom: rm_work: should we propose a pytohn-octaviaclient release for Xena?
16:23:04 <haleyb> that way i can update the contributor doc
16:23:06 <gthiemonge> haleyb: yeah sorry I was a bit lazy on that one
16:23:22 <johnsom> Yes, if it's not broken. grin
16:23:27 <gthiemonge> I'll fix the commit and re-propose it
16:23:34 <gthiemonge> johnsom: master is broken?
16:23:49 <gthiemonge> johnsom: I'll check what you did :D
16:23:49 <johnsom> I don't know
16:24:14 <opendevreview> Adam Harwell proposed openstack/octavia master: Make duplicate constraint checks more generic  https://review.opendev.org/c/openstack/octavia/+/795637
16:25:29 <gthiemonge> so the next meeting will probably be held in openstack-octavia
16:25:36 <rm_work> I wish we could do channel redirects... ... can we do that?
16:25:45 <gthiemonge> if my commit passes the CI :D
16:25:48 <rm_work> I still don't particularly like switching the channel name
16:26:03 <gthiemonge> rm_work: I don't think OFTC supports it
16:26:22 <johnsom> Right, I don't think OFTC supports it
16:26:27 <rm_work> i think it's 50/50, maybe some people are looking for the "openstack-octavia" channel and can't find it? but I think once we switch it's just going to be some people failing to find the lbaas channel <_<
16:26:53 <gthiemonge> we will be in the lbaas channel, redirecting people to octavia ;-)
16:26:54 <haleyb> should i flip a coin?
16:27:10 <rm_work> my followup for that is, if it's a coin flip, why bother changing
16:27:37 <rm_work> we have like 8 years of people knowing where this channel is :D
16:27:46 <rm_work> and docs showing it is here, etc
16:27:49 <haleyb> ok, thumb war then
16:27:57 <rm_work> lol
16:28:35 <gthiemonge> Yeah you have a point here
16:28:38 <rm_work> i mean whatever, if you're set on changing the name, i guess that's fine... it just seems pointless to me
16:29:15 <rm_work> go sit in #openstack-octavia and set the topic to "head over to #openstack-lbaas"
16:29:23 <rm_work> ;)
16:29:46 <johnsom> We can easily make openstack-octavia disappear as well.
16:29:55 <haleyb> i proposed it just as we were moving, pendulum never swung far enough i guess
16:30:37 <rm_work> i mean there's two ways to look at that -- we're moving, so lets rip the bandaid and do all the change at once; or: we're already doing one change, lets upset things as little as possible
16:30:52 <rm_work> but wasting too much time discussing this is just bikeshedding :D
16:31:26 <rm_work> I'm +0
16:31:35 <rm_work> so if the change is merging, i'll see you over there :P
16:31:53 <gthiemonge> ok, I'll abandon the change, we will stay on #openstack-lbaas
16:32:04 <gthiemonge> change is still WIP-1 and 2xCR-1
16:32:15 <gthiemonge> so that would be extra work for me
16:32:19 <haleyb> ok, i'll update by contrib doc patch then to point to OFTC
16:32:33 <gthiemonge> haleyb: thanks, rm_work will review that change
16:32:38 <rm_work> I will :P
16:32:47 <rm_work> ping me!
16:33:42 <haleyb> oh, and while we're on the simple patch wagon, https://review.opendev.org/c/openstack/python-octaviaclient/+/795902 fits the bill
16:34:36 <gthiemonge> haleyb: I'll review it thanks
16:34:55 <gthiemonge> Ok guys, anything else?
16:36:37 <gthiemonge> Ok thank you!
16:36:43 <gthiemonge> #endmeeting