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