16:00:20 <gthiemonge> #startmeeting Octavia
16:00:20 <opendevmeet> Meeting started Wed Nov  8 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:25 <gthiemonge> hello
16:00:30 <oschwart> o/
16:00:34 <tweining> o/
16:00:38 <johnsom> o/
16:01:38 <gthiemonge> #topic Announcements
16:01:51 <gthiemonge> * 2024.1 Caracal Release Schedule
16:02:07 <gthiemonge> FYI next week is Caracal-1 milestone!
16:02:14 <gthiemonge> I think we should focus on reviewing the specs
16:02:22 <gthiemonge> (SR-IOV, LB resize)
16:02:44 <johnsom> Wow, so fast.
16:02:51 <gthiemonge> yeah
16:02:52 <tweining> already? we just had PTG
16:02:56 <johnsom> BTW, I am updating the SR-IOV spec as we speak
16:03:16 <johnsom> I should push an update today
16:03:19 <gthiemonge> https://releases.openstack.org/caracal/schedule.html
16:07:21 <gthiemonge> I don't have any other announcements
16:07:24 <gthiemonge> anyone?
16:07:56 <tweining> will there be a summary about the ptg? or did I miss it?
16:08:07 <gthiemonge> it's in the etherpad ;-)
16:08:13 <johnsom> +1
16:08:14 <johnsom> lol
16:09:12 <tweining> ok, I have a few things about the ptg but we can discuss it in the open discussion
16:10:50 <gthiemonge> ack
16:11:20 <gthiemonge> I'll skip the CI status section, I didn't see any issues
16:11:24 <gthiemonge> #topic Brief progress reports / bugs needing review
16:11:47 <johnsom> You aren't impacted by the oslo util issue for the sqlalchemy 2.x job?
16:12:24 <gthiemonge> johnsom: oh yes we are
16:12:30 <gthiemonge> https://zuul.opendev.org/t/openstack/builds?job_name=octavia-tox-functional-py39-sqlalchemy-tips&project=openstack/octavia
16:12:41 <johnsom> We made it non-voting for now on designate
16:12:55 <gthiemonge> ack we can do the same thing in octavia
16:13:09 <johnsom> The fix merged yesterday, I'm not sure when a release and UC bump will happen
16:13:38 <gthiemonge> ok
16:13:50 <johnsom> This is the bug I opened if you aren't familiar with the issue: https://bugs.launchpad.net/bugs/2042886
16:15:31 <gthiemonge> thanks johnsom
16:18:15 <gthiemonge> I dont have new patches for you guys
16:18:41 <gthiemonge> but tkajinam proposed to fix the deprecated/removed pyopenssl functions:
16:18:47 <gthiemonge> https://review.opendev.org/c/openstack/octavia/+/900142
16:19:06 <gthiemonge> damn, we passed the 900000 reviews
16:19:19 <johnsom> Yeah, good stuff. Glad cryptography finished the pkcs12 work
16:19:42 <tweining> openssl had that deprecated for 3 years apparently
16:20:05 <johnsom> Yeah, it was in 2.5, but that wasn't in distros
16:20:42 <tweining> mypy caught that issue as well btw
16:20:59 <johnsom> Yeah, that is a problem, it's running unconstrained?
16:21:27 <johnsom> This is the reason I am reluctant to add more/new tooling like this
16:21:39 <tweining> it got the typing info from the latest pyopenssl release
16:21:47 <tweining> (where this function was removed)
16:21:56 <johnsom> Yeah, so that is a problem
16:22:32 <gthiemonge> the pyopenssl typing module doesn't have upper constraints
16:22:35 <tweining> I see that as a feature, not a problem
16:22:59 <johnsom> It means those jobs will be broken very often
16:23:02 <gthiemonge> but it could report false positives
16:23:37 <tweining> what do you mean? that it alarms about a release that openstack won't use?
16:23:56 <johnsom> A release OpenStack is not using yet.
16:24:13 <gthiemonge> if the typing info don't match the code, we may have some false reports
16:24:28 <tweining> I think it is good that typing packages are not constrained by uc in openstack, so that things like that get caught early
16:24:41 <johnsom> Like sqlalchemy for example, it was released long before OpenStack was ready for it.
16:25:19 <tweining> well, in that case it would need to be constrained then. I agree.
16:25:59 <gthiemonge> then we can also have an unconstraint job
16:26:27 <johnsom> Yeah, if there is value, we can add tips jobs, but they are non-voting.
16:27:18 <tweining> I will come back to mypy later as well. let's move on
16:27:50 <gthiemonge> we can move to the next topic
16:27:54 <gthiemonge> #topic Open Discussion
16:28:12 <johnsom> I want to run a design decision by you all
16:28:35 <johnsom> On the SR-IOV patch, right now the API does not show if the VIP is a SR-IOV VF or not.
16:29:15 <johnsom> I am thinking I should add that to my patch and have a vip_vnic_type field that would be "normal" or "direct" (same as the neutron port).
16:29:17 <johnsom> Thoughts?
16:29:59 <gthiemonge> johnsom: does the user need it?
16:30:27 <johnsom> Eh, I don't know. They can't see it otherwise as the port is owned by Octavia
16:31:40 <tweining> I can imagine it can be useful to have that info in some cases
16:33:02 <gthiemonge> johnsom: maybe a stupid question, how does octavia know that a VIP is a SR-IOV port? (I mean internally)
16:33:38 <johnsom> The neutron port has a vnic_type field. Also, when we create the port, we ask for a "direct" port
16:34:03 <gthiemonge> it's in the flavor too?
16:34:24 <johnsom> <someone hasn't read the docs in the patch yet> grin
16:34:32 <gthiemonge> https://review.opendev.org/c/openstack/octavia/+/899504/2/octavia/api/drivers/amphora_driver/flavor_schema.py
16:34:36 <gthiemonge> I'm reading it ;-)
16:34:50 <johnsom> So, yeah, the Octavia flavor has a new parameter that says this LB should be created with SR-IOV ports
16:35:01 <gthiemonge> ack
16:35:42 <johnsom> In neutron the port has:
16:35:42 <johnsom> | binding_vnic_type       | direct
16:36:03 <gthiemonge> ok I think a new field in the API is fine
16:36:04 <johnsom> Where "normal" is an OVS/OVN port
16:36:04 <gthiemonge> +1
16:36:31 <johnsom> Ok, I was leaning that direction too, but wanted feedback
16:37:12 <tweining> ok, let me come back to mypy again...
16:37:17 <tweining> https://review.opendev.org/c/openstack/octavia/+/879749 for reference
16:38:05 <tweining> I understand there is some resistance against that new tool. would it help if I separate the typing information that I added from the mypy tool related stuff?
16:38:42 <johnsom> I don't have an issue with adding typing to the python. (Though I don't have that habit yet)
16:38:51 <tweining> because it's the code stuff that is more important to me personally
16:39:12 <johnsom> My concern is about job stability and is this another tool that breaks our gates regularly
16:40:14 <tweining> we could give it a chance at least. a trial period or so.
16:40:23 <gthiemonge> I think we can keep it like that, we just need to check if all the required changes are relevant
16:41:17 <gthiemonge> maybe we need to make it non-voting until we clarify/fix those unconstrainted requirements
16:41:44 <tweining> ok, thanks. I am looking forward to your reviews :)
16:42:48 <tweining> another topic. I found a few interesting things on the PTG etherpad of the nova project
16:43:24 <tweining> pyupdate and codespell are two other tools and I posted patches about them already. thanks for the reviews
16:44:03 <tweining> the other thing was a spec for "per-process-healthchecks"
16:44:04 <tweining> https://review.opendev.org/c/openstack/nova-specs/+/897225
16:44:31 <tweining> maybe we should have something similar for octavia as well. ATM only o-api has a healthcheck endpoint
16:45:01 <tweining> it would improve compatibility with kubernetes I guess
16:45:15 <gthiemonge> do they add REST servers to all their services?
16:45:30 <johnsom> Yeah, the kubernetes issue is something I have raised internally a number of times.
16:45:51 <johnsom> This topic has been debated for a number of years in OpenStack as well.
16:46:31 <tweining> I haven't read that spec in detail yet to be honest
16:46:37 <johnsom> I have not read the nova spec, but the previous PTG debates have been around how to do this
16:47:07 <johnsom> Many of us don't want to add HTTP stacks to every process. For security and resource usage reasons.
16:47:09 <gthiemonge> I'll read it
16:47:43 <johnsom> There is the approach of using rabbit messages, designate went down this path to some degree, but didn't finish
16:47:45 <tweining> it is not really blocking k8s compatibility because there are other mechanisms, but it would be nice to have it probably
16:47:53 <johnsom> That doesn't solve the k8s issue though
16:48:35 <johnsom> It really is necessary for k8s as otherwise graceful shutdowns can be interrupted by k8s timeouts and very bad things happen
16:49:13 <johnsom> There was talk of opening a local socket too. This would work for k8s and many monitoring agents.
16:49:48 <johnsom> Then the debate goes into, per process, per thread, etc. How much it tests (db, rabbit, etc.)
16:50:58 <johnsom> Anyhow, I think it would be a good thing, but it's a complicated topic. If you have ideas, I encourage you to post a spec.
16:51:12 <johnsom> The current oslo middleware healthcheck stuff is not great
16:52:35 <gthiemonge> ack
16:52:38 <gthiemonge> interesting stuff
16:54:37 <gthiemonge> thanks for bringing up the topic tweining
16:54:58 <tweining> yeah, it's food for thought
16:55:37 <tweining> there was another tool on the nova etherpad, I think sphinxlint or so. I didn't look into that one.
16:55:58 <johnsom> https://review.opendev.org/c/openstack/oslo-specs/+/531456
16:56:16 <johnsom> That was an old spec starting to address some issues with the healthcheck middleware
16:56:22 <johnsom> it's abandoned
16:59:16 <gthiemonge> ok folsk, we're almost at the top of the hour
16:59:39 <gthiemonge> anything else before we close the meeting?
16:59:54 <tweining> that's all from me
17:00:21 <gthiemonge> ok
17:00:25 <gthiemonge> good discussions!
17:00:30 <gthiemonge> thank you guys!
17:00:32 <gthiemonge> #endmeeting