Wednesday, 2023-11-08

opendevreviewTom Weininger proposed openstack/octavia master: Integrate mypy type checker  https://review.opendev.org/c/openstack/octavia/+/87974914:50
gthiemonge#startmeeting Octavia16:00
opendevmeetMeeting 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
opendevmeetUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.16:00
opendevmeetThe meeting name has been set to 'octavia'16:00
gthiemongehello16:00
oschwarto/16:00
tweiningo/16:00
johnsomo/16:00
gthiemonge#topic Announcements16:01
gthiemonge* 2024.1 Caracal Release Schedule16:01
gthiemongeFYI next week is Caracal-1 milestone!16:02
gthiemongeI think we should focus on reviewing the specs16:02
gthiemonge(SR-IOV, LB resize)16:02
johnsomWow, so fast.16:02
gthiemongeyeah16:02
tweiningalready? we just had PTG16:02
johnsomBTW, I am updating the SR-IOV spec as we speak16:02
johnsomI should push an update today16:03
gthiemongehttps://releases.openstack.org/caracal/schedule.html16:03
gthiemongeI don't have any other announcements16:07
gthiemongeanyone?16:07
tweiningwill there be a summary about the ptg? or did I miss it?16:07
gthiemongeit's in the etherpad ;-)16:08
johnsom+116:08
johnsomlol16:08
tweiningok, I have a few things about the ptg but we can discuss it in the open discussion16:09
gthiemongeack16:10
gthiemongeI'll skip the CI status section, I didn't see any issues16:11
gthiemonge#topic Brief progress reports / bugs needing review16:11
johnsomYou aren't impacted by the oslo util issue for the sqlalchemy 2.x job?16:11
gthiemongejohnsom: oh yes we are16:12
gthiemongehttps://zuul.opendev.org/t/openstack/builds?job_name=octavia-tox-functional-py39-sqlalchemy-tips&project=openstack/octavia16:12
johnsomWe made it non-voting for now on designate16:12
gthiemongeack we can do the same thing in octavia16:12
johnsomThe fix merged yesterday, I'm not sure when a release and UC bump will happen16:13
gthiemongeok16:13
johnsomThis is the bug I opened if you aren't familiar with the issue: https://bugs.launchpad.net/bugs/204288616:13
gthiemongethanks johnsom 16:15
gthiemongeI dont have new patches for you guys16:18
gthiemongebut tkajinam proposed to fix the deprecated/removed pyopenssl functions:16:18
gthiemongehttps://review.opendev.org/c/openstack/octavia/+/90014216:18
gthiemongedamn, we passed the 900000 reviews16:19
johnsomYeah, good stuff. Glad cryptography finished the pkcs12 work16:19
tweiningopenssl had that deprecated for 3 years apparently16:19
johnsomYeah, it was in 2.5, but that wasn't in distros16:20
tweiningmypy caught that issue as well btw16:20
johnsomYeah, that is a problem, it's running unconstrained?16:20
johnsomThis is the reason I am reluctant to add more/new tooling like this16:21
tweiningit got the typing info from the latest pyopenssl release16:21
tweining(where this function was removed)16:21
johnsomYeah, so that is a problem16:21
gthiemongethe pyopenssl typing module doesn't have upper constraints16:22
tweiningI see that as a feature, not a problem16:22
johnsomIt means those jobs will be broken very often16:22
gthiemongebut it could report false positives16:23
tweiningwhat do you mean? that it alarms about a release that openstack won't use?16:23
johnsomA release OpenStack is not using yet.16:23
gthiemongeif the typing info don't match the code, we may have some false reports16:24
tweiningI think it is good that typing packages are not constrained by uc in openstack, so that things like that get caught early16:24
johnsomLike sqlalchemy for example, it was released long before OpenStack was ready for it.16:24
tweiningwell, in that case it would need to be constrained then. I agree.16:25
gthiemongethen we can also have an unconstraint job16:25
johnsomYeah, if there is value, we can add tips jobs, but they are non-voting.16:26
tweiningI will come back to mypy later as well. let's move on16:27
gthiemongewe can move to the next topic16:27
gthiemonge#topic Open Discussion16:27
johnsomI want to run a design decision by you all16:28
johnsomOn the SR-IOV patch, right now the API does not show if the VIP is a SR-IOV VF or not.16:28
johnsomI 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
johnsomThoughts?16:29
gthiemongejohnsom: does the user need it?16:29
johnsomEh, I don't know. They can't see it otherwise as the port is owned by Octavia16:30
tweiningI can imagine it can be useful to have that info in some cases16:31
gthiemongejohnsom: maybe a stupid question, how does octavia know that a VIP is a SR-IOV port? (I mean internally)16:33
johnsomThe neutron port has a vnic_type field. Also, when we create the port, we ask for a "direct" port16:33
gthiemongeit's in the flavor too?16:34
johnsom<someone hasn't read the docs in the patch yet> grin16:34
gthiemongehttps://review.opendev.org/c/openstack/octavia/+/899504/2/octavia/api/drivers/amphora_driver/flavor_schema.py16:34
gthiemongeI'm reading it ;-)16:34
johnsomSo, yeah, the Octavia flavor has a new parameter that says this LB should be created with SR-IOV ports16:34
gthiemongeack16:35
johnsomIn neutron the port has:16:35
johnsom| binding_vnic_type       | direct16:35
gthiemongeok I think a new field in the API is fine16:36
johnsomWhere "normal" is an OVS/OVN port16:36
gthiemonge+116:36
johnsomOk, I was leaning that direction too, but wanted feedback16:36
tweiningok, let me come back to mypy again...16:37
tweininghttps://review.opendev.org/c/openstack/octavia/+/879749 for reference16:37
tweiningI 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
johnsomI don't have an issue with adding typing to the python. (Though I don't have that habit yet)16:38
tweiningbecause it's the code stuff that is more important to me personally16:38
johnsomMy concern is about job stability and is this another tool that breaks our gates regularly16:39
tweiningwe could give it a chance at least. a trial period or so.16:40
gthiemongeI think we can keep it like that, we just need to check if all the required changes are relevant16:40
gthiemongemaybe we need to make it non-voting until we clarify/fix those unconstrainted requirements16:41
tweiningok, thanks. I am looking forward to your reviews :)16:41
tweininganother topic. I found a few interesting things on the PTG etherpad of the nova project16:42
tweiningpyupdate and codespell are two other tools and I posted patches about them already. thanks for the reviews16:43
tweiningthe other thing was a spec for "per-process-healthchecks"16:44
tweininghttps://review.opendev.org/c/openstack/nova-specs/+/89722516:44
tweiningmaybe we should have something similar for octavia as well. ATM only o-api has a healthcheck endpoint16:44
tweiningit would improve compatibility with kubernetes I guess16:45
gthiemongedo they add REST servers to all their services?16:45
johnsomYeah, the kubernetes issue is something I have raised internally a number of times.16:45
johnsomThis topic has been debated for a number of years in OpenStack as well.16:45
tweiningI haven't read that spec in detail yet to be honest16:46
johnsomI have not read the nova spec, but the previous PTG debates have been around how to do this16:46
johnsomMany of us don't want to add HTTP stacks to every process. For security and resource usage reasons.16:47
gthiemongeI'll read it16:47
johnsomThere is the approach of using rabbit messages, designate went down this path to some degree, but didn't finish16:47
tweiningit is not really blocking k8s compatibility because there are other mechanisms, but it would be nice to have it probably16:47
johnsomThat doesn't solve the k8s issue though16:47
johnsomIt really is necessary for k8s as otherwise graceful shutdowns can be interrupted by k8s timeouts and very bad things happen16:48
johnsomThere was talk of opening a local socket too. This would work for k8s and many monitoring agents.16:49
johnsomThen the debate goes into, per process, per thread, etc. How much it tests (db, rabbit, etc.)16:49
johnsomAnyhow, 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:50
johnsomThe current oslo middleware healthcheck stuff is not great16:51
gthiemongeack16:52
gthiemongeinteresting stuff16:52
gthiemongethanks for bringing up the topic tweining 16:54
tweiningyeah, it's food for thought16:54
tweiningthere was another tool on the nova etherpad, I think sphinxlint or so. I didn't look into that one.16:55
johnsomhttps://review.opendev.org/c/openstack/oslo-specs/+/53145616:55
johnsomThat was an old spec starting to address some issues with the healthcheck middleware16:56
johnsomit's abandoned16:56
gthiemongeok folsk, we're almost at the top of the hour16:59
gthiemongeanything else before we close the meeting?16:59
tweiningthat's all from me16:59
gthiemongeok17:00
gthiemongegood discussions!17:00
gthiemongethank you guys!17:00
gthiemonge#endmeeting17:00
opendevmeetMeeting ended Wed Nov  8 17:00:32 2023 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)17:00
opendevmeetMinutes:        https://meetings.opendev.org/meetings/octavia/2023/octavia.2023-11-08-16.00.html17:00
opendevmeetMinutes (text): https://meetings.opendev.org/meetings/octavia/2023/octavia.2023-11-08-16.00.txt17:00
opendevmeetLog:            https://meetings.opendev.org/meetings/octavia/2023/octavia.2023-11-08-16.00.log.html17:00
opendevreviewMichael Johnson proposed openstack/octavia master: Add spec for SR-IOV in Octavia Amphora  https://review.opendev.org/c/openstack/octavia/+/89124423:20

Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!