14:00:51 <ralonsoh> #startmeeting networking
14:00:51 <opendevmeet> Meeting started Tue Aug 22 14:00:51 2023 UTC and is due to finish in 60 minutes.  The chair is ralonsoh. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:51 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:51 <opendevmeet> The meeting name has been set to 'networking'
14:00:54 <ralonsoh> hello all
14:00:56 <frickler> \o
14:00:58 <isabek> Hi
14:01:00 <haleyb> o/
14:01:02 <slaweq> o/
14:01:11 <bcafarel> o/
14:01:22 <mtomaska> o/
14:01:27 <obondarev_> hi
14:01:45 <rubasov> o/
14:01:56 <lajoskatona> o/
14:02:02 <ralonsoh> ok, let's start
14:02:11 <ralonsoh> #topic announcements
14:02:19 <ralonsoh> #link https://releases.openstack.org/bobcat/schedule.html
14:02:44 <ralonsoh> very important this week: election nomination begins
14:03:01 <ralonsoh> so please send your candidacy mails to the mailing list
14:03:22 <ralonsoh> more info: https://governance.openstack.org/election/
14:03:50 <ralonsoh> and we have the final release for the non-client libraries
14:04:03 <ralonsoh> os-ken: https://review.opendev.org/c/openstack/releases/+/892214
14:04:14 <ralonsoh> ovsdbapp: https://review.opendev.org/c/openstack/releases/+/892237
14:04:34 <ralonsoh> about https://review.opendev.org/c/openstack/releases/+/892120, I know this patch is older than the releases team one
14:04:46 <ralonsoh> but let's use the releases team one
14:04:55 <ralonsoh> frickler, in any case, thanks for proposing it
14:05:38 <ralonsoh> same as the previous week, just a reminder
14:05:53 <ralonsoh> we have a new openinfra episode
14:05:58 <ralonsoh> #link https://openinfra.dev/live/#all-episodes
14:06:07 <ralonsoh> and that's all I have this week
14:06:17 <ralonsoh> (we are getting closer to the release date!)
14:06:25 <ralonsoh> Am I missing something?
14:07:18 <ralonsoh> ok, let's move to bugs
14:07:21 <ralonsoh> #topic bugs
14:07:28 <ralonsoh> Report from obondarev: https://lists.openstack.org/pipermail/openstack-discuss/2023-August/034777.html
14:07:41 <ralonsoh> (lucky you, that was an easy week)
14:07:48 <obondarev> true
14:07:53 <ralonsoh> only one unassigned bug
14:08:00 <ralonsoh> #link https://bugs.launchpad.net/neutron/+bug/2031520
14:08:43 <ralonsoh> I opened this bug because there could be (for sure) some confusion about DVR/SNAT in OVN with PF, load balancing, network types (tunelled or vlan), etc
14:09:14 <ralonsoh> so it could be very useful to have a documentation with all the config parameters, options and current implementation
14:09:18 <ralonsoh> and that's all!
14:09:21 <haleyb> people only file bugs on my week :-(
14:09:28 <ralonsoh> hehehehe
14:09:51 <ralonsoh> I'll try to take this bug at the end of this week, in any case, if some else didn't take it before
14:10:03 <ralonsoh> Am I missing any other bug you want to bring here?
14:10:16 <ralonsoh> it doesn't matter if it is an older bug
14:10:51 <frickler> I think https://bugs.launchpad.net/neutron/+bug/2028651 is worth mentioning again
14:10:59 <frickler> iiuc it still blocks octavia?
14:11:33 <ralonsoh> I need to check it, yes. But I don't know why the patch related introduced this regression
14:11:47 <ralonsoh> I mean https://review.opendev.org/c/openstack/neutron/+/882588 is preventing from using a VIP port as a VM port
14:12:23 <ralonsoh> I'll check it tomorrow morning, because gthiemonge will need it asap
14:12:56 <ralonsoh> frickler, did you have time to investifate it?
14:13:16 <frickler> no, I'm just watching this from the outside
14:13:40 <ralonsoh> ok, I'll try to use the reproducer provided
14:14:12 <ralonsoh> any other bug?
14:14:42 <ralonsoh> This week isabek is the deputy, next week will be elvira.
14:14:43 <ralonsoh> ack?
14:14:47 <isabek> o/
14:14:47 <elvira> ack o/
14:14:50 <ralonsoh> thanks!
14:15:03 <ralonsoh> ok, let's jump to the next topic
14:15:06 <ralonsoh> #topic os-ken
14:15:16 <ralonsoh> I commented that before
14:15:25 <ralonsoh> frickler, pushed some patches for os-ken
14:15:41 <ralonsoh> and now we are releasing a new (and last for this cycle) release
14:15:53 <frickler> hopefully that unblocks n-d-r
14:15:58 <ralonsoh> I hope si
14:16:00 <ralonsoh> so*
14:16:18 <frickler> one side note from testing this is that the n-d-r job on os-ken is completely useless
14:16:18 <ralonsoh> and next release (during C), we'll try the new implementation with more time
14:16:38 <ralonsoh> why is so?
14:16:42 <frickler> because it only tests the released os-ken, not the patch in question
14:17:05 <opendevreview> Slawek Kaplonski proposed openstack/neutron master: [S-RBAC] Add service role in neutron policy  https://review.opendev.org/c/openstack/neutron/+/886724
14:17:48 <frickler> also I'm still not sure what actually happened that caused this regression
14:17:49 <ralonsoh> frickler, but I'm checking the "neutron-tempest-plugin-dynamic-routing" definition
14:17:55 <ralonsoh> and required-projects: os-ken
14:18:22 <frickler> that does not seem to be enough
14:18:39 <frickler> also os-ken is installed twice, once in the neutron venv and once in the tempest venv
14:18:50 <frickler> but both get installed from pypi
14:19:53 <ralonsoh> I don;'t understand, if os-ken is in required projects, it should be git cloning the project and installing from source
14:19:59 <ralonsoh> I'll open a LP bug for this
14:20:48 <frickler> it is not getting installed directly, just as dependency of n-d-r, I think that's what the issue comes from, but didn't check yet in detail
14:21:06 <frickler> but would be nice if one of the CI ppl could have a look, too
14:21:10 <ralonsoh> I'll check the job logs before creating the LP bug
14:21:31 <ralonsoh> but yes, we should be able to install whatever version of os-ken we need
14:22:12 <ralonsoh> ok, let's move to the next topic then
14:22:17 <ralonsoh> #topic community_goals
14:22:23 <ralonsoh> 1) Consistent and Secure Default RBAC
14:22:34 <ralonsoh> slaweq, https://bugs.launchpad.net/neutron/+bug/2026182
14:22:42 <ralonsoh> (I think I'll change the title of this section)
14:23:26 <ralonsoh> ok, I'll ping him later
14:23:37 <ralonsoh> there is an ongoing patch ready to be reviewed
14:23:40 <ralonsoh> #link https://review.opendev.org/c/openstack/neutron/+/886724
14:23:48 <slaweq> hi
14:23:50 <ralonsoh> but we won't merge it during this release
14:23:54 <ralonsoh> hi
14:24:08 <slaweq> I think that patch https://review.opendev.org/c/openstack/neutron/+/886724 is ready if You have time to release it
14:24:15 <slaweq> *to review
14:24:17 <slaweq> sorry :)
14:24:19 <ralonsoh> perfect!
14:24:38 <slaweq> it's not that big really as it mostly adds unit tests
14:24:50 <slaweq> and changes some of the policies (but not that many)
14:24:52 <ralonsoh> just one heads-up, I don't think we should merge it during this release
14:24:56 <ralonsoh> just in case
14:25:08 <ralonsoh> and service role is not mandatory during Bobcat
14:25:24 <slaweq> sure, we can wait for the beginning of the next cycle with it
14:25:30 <lajoskatona> and for that we need any change in nova for example?
14:25:35 <slaweq> it's fine for me
14:26:05 <ralonsoh> they should add this new role in the configuration and make these calls using it
14:26:08 <opendevreview> Merged openstack/neutron stable/ussuri: [OVN] ovn-db-sync check for router port differences  https://review.opendev.org/c/openstack/neutron/+/892183
14:26:13 <slaweq> lajoskatona I don't think so as we already had "advsvc" role
14:26:22 <lajoskatona> ok, thanks
14:26:34 <ralonsoh> but is Nova using it?
14:26:37 <slaweq> this patch actually deprecates it and renames it to the "service" role to be consistent with new policies and all projects
14:26:54 <slaweq> but CI is happy with it so far
14:28:10 <ralonsoh> sorry but I don't understand that
14:28:19 <ralonsoh> ADVSVC role was an internal one
14:28:32 <ralonsoh> only used in Neutron
14:29:39 <slaweq> yes, and now our context.is_advsvc returns True in both cases - if it's advsvc role or service role: https://github.com/openstack/neutron-lib/blob/master/neutron_lib/context.py#L84
14:30:09 <ralonsoh> ok, so we have "converted" this Neutron role to service role
14:30:16 <slaweq> yes
14:30:18 <ralonsoh> ok, understood
14:30:26 <slaweq> but with keeping old name for now too
14:30:40 <ralonsoh> in any case, you have moved some operations to be only performed by this new role
14:30:46 <ralonsoh> port binding, for example
14:31:08 <slaweq> yes
14:31:38 <ralonsoh> ok, maybe we could have some rants from user in a future
14:31:41 <slaweq> as it's not needed to be available for admin user and we can just allow it to the advsvc/service role
14:31:57 <ralonsoh> if they want to make this kind of operations manually (for debugging or testing)
14:32:21 <slaweq> it's just default policy and can be always overwritten in the policy.yaml file in such case
14:32:27 <ralonsoh> right
14:32:33 <ralonsoh> ok, sorry for this time
14:32:40 <slaweq> no problem
14:32:44 <ralonsoh> I only wanted to have some answers!
14:32:47 <slaweq> thx for the questions about it
14:32:50 <ralonsoh> thanks!
14:32:57 <ralonsoh> next section
14:33:03 <ralonsoh> 2) Neutron client deprecation
14:33:07 <ralonsoh> lajoskatona, please
14:33:18 <lajoskatona> the usual etherpad: https://etherpad.opendev.org/p/python-neutronclient_deprecation
14:33:44 <lajoskatona> what is ongoing the sfc work: https://etherpad.opendev.org/p/python-neutronclient_deprecation#L40
14:34:04 <lajoskatona> but I suppose in SDK we have to wait with it till the new release will start
14:34:19 <ralonsoh> is it possible to have the sdk patches during this week?
14:34:24 <ralonsoh> before the release
14:34:50 <lajoskatona> I can ask sdk team
14:35:03 <ralonsoh> that could be perfect
14:35:08 <lajoskatona> and if you have time please review it, that can be a push for the malso :-)
14:35:14 <ralonsoh> sure
14:35:22 <ralonsoh> and I have approved the n-lib patch
14:35:35 <ralonsoh> I had it open today but I didn't push the buttong
14:35:35 <lajoskatona> Another thing is that I started to play with Horizon, but that is really just playing with it
14:35:47 <lajoskatona> ralonsoh: thanks
14:35:58 <ralonsoh> horizon is another beast...
14:36:03 <lajoskatona> https://review.opendev.org/c/openstack/horizon/+/891205
14:36:34 <lajoskatona> yes, it has some traps which I hit on my first try :-)
14:36:51 <ralonsoh> but yes, we can propose incremental changes in horizon
14:36:58 <lajoskatona> but anyway I got some help in review from the horizon team, so at least there's some attention
14:36:59 <ralonsoh> that could be easier, for sure
14:37:00 <frickler> does n-lib also count as non-client lib and should be frozen this week?
14:37:06 <ralonsoh> nope
14:37:32 <ralonsoh> only (for us) os-ken and ovsdbapp
14:38:04 <lajoskatona> I thought n-lib also
14:38:21 <ralonsoh> let me check but I'm almost sure
14:38:26 <lajoskatona> ok
14:38:38 <lajoskatona> for the neutron-client topic, that's all from me
14:38:45 <slaweq> neutron-lib too AFAIK
14:38:48 <frickler> both n-lib and os-ken have "type:library"
14:38:57 <slaweq> frickler exactly
14:39:11 <slaweq> ovn-octavia-provider is not in that category but n-lib is
14:39:35 <ralonsoh> so I'll ping release folks
14:39:44 <ralonsoh> (or maybe they didn't have time yet to push the patch)
14:39:56 <slaweq> but do we need new release of n-lib now?
14:40:04 <slaweq> it was released about 2-3 weeks ago
14:40:09 <slaweq> do we have anything new there?
14:40:23 <ralonsoh> yes but we need the cycle last release
14:40:28 <ralonsoh> and this is the week for that
14:40:39 <slaweq> I just checked and there is nothing new:
14:40:52 <slaweq> tools/list_unreleased_changes.sh master openstack/neutron-lib
14:40:52 <slaweq> [ Unreleased changes in openstack/neutron-lib (master) ]
14:40:52 <slaweq> Changes between 3.8.0 and 4f862dac
14:40:55 <lajoskatona> It was the last release 3 weeks ago: https://review.opendev.org/c/openstack/releases/+/890038
14:40:59 <ralonsoh> apart from lajoskatona patch, I don't think there is anything else pending
14:41:32 <ralonsoh> so this is why release folks didn't send a patch
14:41:39 <slaweq> yes
14:41:39 <ralonsoh> because there were no new patches
14:41:42 <lajoskatona> yeah possible
14:42:02 <slaweq> but if we want to merge and release something, that's fine if we will do it this week
14:42:07 <ralonsoh> lajoskatona, do you need https://review.opendev.org/c/openstack/neutron-lib/+/887193 during this cycle?
14:42:13 <ralonsoh> if so, we can release a new one
14:42:20 <ralonsoh> if not, we can keep the current one
14:42:34 <slaweq> api-ref don't need to be released
14:42:35 <lajoskatona> I dont' think so
14:42:40 <lajoskatona> it's just documentation
14:42:44 <slaweq> it's always rendered from the master branch IIRC
14:42:47 <ralonsoh> perfect, so let's keep the current version we have now
14:42:52 <lajoskatona> +1
14:43:19 <ralonsoh> and that's all I have here
14:43:21 <ralonsoh> let's move then
14:43:28 <ralonsoh> #topic on_demand
14:43:49 <ralonsoh> last weel stephenfin pinged me about including tox py310 with sqlalchemy master
14:44:14 <ralonsoh> as you saw last days, I added it and is now voting in the check queue
14:44:37 <ralonsoh> I also removed our local py311 implementation and we are now using the glocal openstack-tox-py311
14:44:49 <slaweq> I hope it won't break too often, especially now when we are close to the release
14:45:04 <ralonsoh> and fixed, as recommended by frickler, our bindep file for some debian library issues with py311
14:45:14 <ralonsoh> so far, we are good now
14:45:24 <frickler> py311 should still be non-voting until next cycle
14:45:25 <ralonsoh> slaweq, the 2.0 release is in the oven
14:45:44 <slaweq> ++
14:45:46 <ralonsoh> frickler, yes but at least we should manually check if we break something
14:46:02 <ralonsoh> one sec
14:46:16 <frickler> yes, just responded to slaweq that it should not block the release
14:46:26 <ralonsoh> https://review.opendev.org/c/openstack/requirements/+/879743
14:46:38 <slaweq> frickler I was thinking more about py310 with sqlalchemy master :)
14:46:46 <slaweq> I know py311 is non voting for now
14:46:58 <ralonsoh> actually I prefer having it in the check queue
14:46:59 <frickler> ah, then I misread that
14:47:18 <ralonsoh> 2 weeks ago we introduced something that break the 2.0 compatibility
14:47:21 <ralonsoh> "select 1;"
14:47:33 <ralonsoh> now is fixed
14:48:08 <ralonsoh> ok, something else (apart from my dramas with sqlalchemy 2.0 hehehe) ??
14:48:25 <slaweq> just FYI
14:48:31 <frickler> I made no progress with building OVN 23.06 yet, did anyone test that successfully?
14:48:52 <slaweq> this week I sent email https://lists.openstack.org/pipermail/openstack-discuss/2023-August/034778.html with proposal of some changes to the neutron related questions in OS user survey
14:49:08 <slaweq> I need to check one more thing and reply to last email from fungi still
14:49:16 <slaweq> that's all from me
14:49:22 <mlavalle> can I get someone to push this over the edge, please: https://review.opendev.org/c/openstack/python-openstackclient/+/891557?
14:49:27 <slaweq> and thx all for the feedback in the etherpad
14:49:35 <frickler> I agree that most people choose "OVS" but really mean "ML2/OVS"
14:49:43 <ralonsoh> slaweq, thanks for the time on this
14:49:52 <slaweq> mlavalle I will check this patch
14:50:00 <mlavalle> slaweq: thanks
14:50:26 <ralonsoh> frickler, yes, always, no one is manyally configuring OVS without an orchestrator
14:50:36 <ralonsoh> same as OVN or SRIOV
14:50:57 <lajoskatona> frickler: I just checked and I have a devstack with OVN main, and northd said it is ovn-northd 23.06.90
14:51:17 <lajoskatona> frickler: I have OVS_BRANCH="v3.1.0"
14:51:39 <frickler> lajoskatona: oh, testing with main would be an option I guess, yes, I can try that
14:51:43 <ralonsoh> but is this the git submodule hash recommended by OVN repo?
14:52:03 <ralonsoh> each OVN branch has a defined OVS branch provided by git submodule
14:52:35 <lajoskatona> to tell the truth I stolen it from one debvstack job after some unsuccessful tries
14:52:54 <ralonsoh> frickler, did you try that? I think I commented that in IRC last week
14:53:11 <frickler> I did not try that yet, os-ken got in the way
14:53:27 <frickler> but I will test both variants this week
14:53:42 <ralonsoh> ping me if you still have problems with this after using the recommended version
14:53:53 <frickler> ack, thx
14:54:01 <ralonsoh> remember that in 5 mins we have the CI meeting
14:54:11 <slaweq> ++
14:54:12 <ralonsoh> I'll give you some time to grab some coffee
14:54:17 <ralonsoh> see you in 5 mins
14:54:21 <mlavalle> o/
14:54:23 <ralonsoh> #endmeeting