| *** iurygregory is now known as iurygregory|holiday | 02:26 | |
| opendevreview | liuxie proposed openstack/neutron-lib master: New api-def: allowedaddresspairs-atomic https://review.opendev.org/c/openstack/neutron-lib/+/880615 | 03:06 |
|---|---|---|
| opendevreview | huanghailun proposed openstack/neutron master: Add allowed_address_pairs add/remove atomic operations https://review.opendev.org/c/openstack/neutron/+/880922 | 07:09 |
| opendevreview | huanghailun proposed openstack/neutron master: Add allowed_address_pairs add/remove atomic operations https://review.opendev.org/c/openstack/neutron/+/880922 | 07:11 |
| opendevreview | huanghailun proposed openstack/neutron master: Add allowed_address_pairs add/remove atomic operations https://review.opendev.org/c/openstack/neutron/+/880922 | 07:18 |
| dvo-plv | Hello | 08:06 |
| dvo-plv | Do you have ability to review our spec file from this fre ? https://bugs.launchpad.net/neutron/+bug/2013540 | 08:06 |
| ralonsoh | dvo-plv, I'll take a look on Monday, I can't today. But this is in my TODO list | 08:15 |
| dvo-plv | greate, thanks | 08:18 |
| opendevreview | Fernando Royo proposed openstack/ovn-octavia-provider master: Discard batch-update-members not valid request https://review.opendev.org/c/openstack/ovn-octavia-provider/+/881198 | 08:28 |
| opendevreview | huanghailun proposed openstack/neutron master: Add allowed_address_pairs add/remove atomic operations https://review.opendev.org/c/openstack/neutron/+/880922 | 09:05 |
| opendevreview | Fernando Royo proposed openstack/ovn-octavia-provider master: Discard batch-update-members not valid request https://review.opendev.org/c/openstack/ovn-octavia-provider/+/881198 | 10:10 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: [OVN] Admin procedure for duplicated or deleted OVN agents https://review.opendev.org/c/openstack/neutron/+/881204 | 10:20 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: Update QoS documentation https://review.opendev.org/c/openstack/neutron/+/881206 | 10:58 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: Update QoS documentation https://review.opendev.org/c/openstack/neutron/+/881206 | 10:59 |
| dmitriis | Got a pass on https://review.opendev.org/c/openstack/neutron-lib/+/870887 again after a re-upload if anybody has time. | 11:13 |
| dmitriis | lajoskatona, ralonsoh: tyvm | 12:28 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: Use a writer context for the online alembic migrations https://review.opendev.org/c/openstack/neutron/+/880867 | 13:14 |
| lajoskatona | dmitriis: :-) Thanks for proposing this feature upstream :-) | 13:19 |
| ralonsoh | folks, if you have 1 min: https://review.opendev.org/c/openstack/neutron/+/874669 | 13:22 |
| slaweq | ralonsoh +2 | 13:23 |
| ralonsoh | thanks! | 13:23 |
| lajoskatona | Tahnks, I added in comment the reference for the original patch which introduced OVNSqlFixture | 13:29 |
| ralonsoh | thanks! | 13:29 |
| ralonsoh | ah yes, I missed that link... | 13:29 |
| opendevreview | Merged openstack/neutron-lib master: ext-gw-multihoming: api-def and api-ref https://review.opendev.org/c/openstack/neutron-lib/+/870887 | 13:34 |
| ralonsoh | Ping list: ykarel, mlavalle, mtomaska, slawek, obondarev, sahid, tobias-urdin, lajoskatona, amotoki | 14:00 |
| mlavalle | o/ | 14:00 |
| ralonsoh | #startmeeting neutron_drivers | 14:00 |
| opendevmeet | Meeting started Fri Apr 21 14:00:49 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 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 14:00 |
| opendevmeet | The meeting name has been set to 'neutron_drivers' | 14:00 |
| ralonsoh | hello | 14:00 |
| lajoskatona | o/ | 14:01 |
| slaweq | o/ | 14:01 |
| rubasov | o/ | 14:01 |
| ralonsoh | ok, let's start | 14:02 |
| obondarev | o/ | 14:02 |
| sahid_ | o/ | 14:02 |
| ralonsoh | first topic is | 14:02 |
| ralonsoh | #link https://bugs.launchpad.net/neutron/+bug/2013228 | 14:02 |
| ralonsoh | [rfe] Non-admin users unable to create SR-IOV switch dev ports | 14:02 |
| ralonsoh | I'll present it | 14:02 |
| ralonsoh | the idea, discussed during this PTG and the previous one | 14:02 |
| ralonsoh | is to have another port extension | 14:03 |
| ralonsoh | a flag, that will enable/disable the HW offload | 14:03 |
| ralonsoh | instead of writing in the port binding, that is something Neutron shouldn't do | 14:03 |
| ralonsoh | any backend supporting HWOL, will read it and create the corresponding interface | 14:03 |
| ralonsoh | (that means communication with Nova, that needs to support this extension) | 14:04 |
| ralonsoh | so that's the feature. That will require a spec because: we create a new API extension, DB changes, changes in 2 backends and Nova-Neutron sync | 14:04 |
| lajoskatona | nova-spec also? | 14:05 |
| ralonsoh | I don't think so | 14:05 |
| lajoskatona | akc | 14:05 |
| lajoskatona | ack | 14:05 |
| ralonsoh | but this is something I can check with Nova folks | 14:05 |
| sahid_ | I may not understand all, but insn't that somehing whcih should be controled by nova, having a port created using HW offload? | 14:07 |
| ralonsoh | no, the port is created by Neutron | 14:07 |
| ralonsoh | the DB port | 14:07 |
| ralonsoh | Nova, reading the Neutron port, creates the L1 port | 14:07 |
| ralonsoh | ah, this flag will be by default admin only but configurable via policies | 14:08 |
| slaweq | so currently this information is in binding profile and that's how nova and other backends expects it, right? | 14:08 |
| ralonsoh | yes | 14:08 |
| ralonsoh | well, the backend is controlled by Neutron, so that is something to be changed in our side | 14:09 |
| ralonsoh | the only "external" issue is the info passed to Nova | 14:09 |
| ralonsoh | to pass to os-vif the correct way to create the L1 port | 14:09 |
| slaweq | why can't we add new extension to add new port's attribute for that so users can use it but then internally translate it into binding profile and send to e.g. nova? | 14:09 |
| slaweq | that way impact of the change would be smaller, am I correct? | 14:09 |
| ralonsoh | right, but the secondary goal of this feature was to avoid writing in the por tbinding dict | 14:10 |
| ralonsoh | something that should be done only by nova | 14:10 |
| ralonsoh | but | 14:10 |
| ralonsoh | we can implement that in two phases | 14:10 |
| ralonsoh | 1) add the port extension + port binding | 14:10 |
| ralonsoh | 2) in the next release, if nova implements the port extension, remove the port binding stuff | 14:11 |
| slaweq | yeah, IIUC what You actuallywant to do are 2 different things | 14:11 |
| ralonsoh | yes | 14:11 |
| slaweq | 1. new extension to allow users setting this HWOL flag and | 14:11 |
| slaweq | 2. change/improve communication with nova | 14:11 |
| ralonsoh | yes | 14:11 |
| ralonsoh | and also allow non-admin users to create HWOL ports | 14:12 |
| ralonsoh | **if** the admin allows that in the policies | 14:12 |
| slaweq | yes, but that's kind of related to 1) | 14:12 |
| mlavalle | and without touching the port binding | 14:12 |
| ralonsoh | yes | 14:12 |
| slaweq | yes, but that's kind of related to 1) | 14:13 |
| mlavalle | honestly, the rfe is not as clear as what we've discussing here | 14:14 |
| ralonsoh | no, it isn't | 14:14 |
| lajoskatona | agree | 14:14 |
| obondarev | same feeling | 14:14 |
| ralonsoh | if approved, I'll add a comemnt of what should be implemented and what the spec will contain | 14:14 |
| mlavalle | right, I was about to suggest that | 14:14 |
| mlavalle | to make clear what we understood | 14:15 |
| ralonsoh | I prefer no to change the description, that is not mine | 14:15 |
| mlavalle | that's fine | 14:15 |
| slaweq | ++ | 14:15 |
| lajoskatona | shall we expect johnthetubaguy to work on this? | 14:15 |
| ralonsoh | no | 14:15 |
| mlavalle | just in a coment leave in black and white our understanding | 14:15 |
| ralonsoh | but I can ask him | 14:15 |
| sahid_ | why this was admin only from the beginning? something was just missing or it was legitimate? | 14:15 |
| ralonsoh | port binding is admin only | 14:16 |
| ralonsoh | and not configurable | 14:16 |
| mlavalle | so who would write the spec? | 14:16 |
| ralonsoh | I'll do | 14:16 |
| ralonsoh | and I'll implement the feature | 14:17 |
| obondarev | +1 then :) | 14:17 |
| ralonsoh | but if you agree on the description given here | 14:17 |
| slaweq | so I'm +1 for this RFE but for point 1) for now | 14:17 |
| ralonsoh | ok, I'll add the description of the 2 phases | 14:17 |
| slaweq | I think that neutron-nova thing is another story | 14:17 |
| ralonsoh | that will be easy to implement | 14:17 |
| slaweq | I'm also fine with that but this should probably be discussed separately in nova-neutron session probably | 14:18 |
| ralonsoh | for sure | 14:18 |
| ralonsoh | we can change the Neutron code isolating the neutron-nova communication | 14:18 |
| ralonsoh | any other question? | 14:20 |
| slaweq | nothing from me | 14:20 |
| lajoskatona | not from me | 14:20 |
| mlavalle | no, I think enabling users to create hwol ports, under controls, is a worthy cause | 14:20 |
| lajoskatona | I agree with this plan | 14:20 |
| ralonsoh | then please vote for this RFE | 14:20 |
| mlavalle | +1 | 14:21 |
| lajoskatona | +1 with the spec | 14:21 |
| mlavalle | yeap, spec is needed | 14:21 |
| ralonsoh | slaweq, obondarev ? | 14:21 |
| obondarev | +1 | 14:21 |
| slaweq | +1 | 14:22 |
| ralonsoh | so approved with spec, including the description done in this conversation (and the 2 phases plan) | 14:22 |
| ralonsoh | thank you all | 14:22 |
| ralonsoh | next one | 14:22 |
| ralonsoh | #link https://bugs.launchpad.net/neutron/+bug/2016197 | 14:22 |
| ralonsoh | neutron can create port from network which has no subnet | 14:22 |
| ralonsoh | related to | 14:22 |
| ralonsoh | #link https://bugs.launchpad.net/neutron/+bug/2016198 | 14:22 |
| * sahid_ checked the spec to this why it has been implemented in that way considering admin only, but no mentions of that | 14:23 | |
| ralonsoh | OK, Liu is not here but I'll start the conversation | 14:24 |
| ralonsoh | regardless of seeing the problem in lp#2016198 | 14:24 |
| ralonsoh | I don't think we should block the creation of a port in a network without subnets | 14:24 |
| slaweq | if we already have it like that, I don't think we can remove it as it would be backward incompatible | 14:25 |
| slaweq | and we can break someone's use case even if we don't know about it | 14:25 |
| ralonsoh | although, being said, I don't see any useful thing | 14:25 |
| ralonsoh | yeah, that's the point, this is something that the current API allows | 14:25 |
| ralonsoh | to be honest I don't see any usecase | 14:25 |
| ralonsoh | but is allowd | 14:25 |
| slaweq | subnet is just our internal thing used for IPAM - network and port are things which IMO may be treated as representation of things from "physical" world | 14:25 |
| sahid_ | removing this will be an api breaking | 14:25 |
| obondarev | seems like HA routers bug can be fixed with just checking HA network subnets | 14:26 |
| slaweq | sahid_++ | 14:26 |
| ralonsoh | obondarev, right! | 14:26 |
| ralonsoh | but this call should be done inside the same context creating the subnet | 14:27 |
| ralonsoh | just to be transactional | 14:27 |
| slaweq | maybe we should do something like allocating IP addresses to ports when subnet is created | 14:27 |
| slaweq | something like: | 14:27 |
| slaweq | for port in network.ports: | 14:27 |
| slaweq | if not port.fixed_ips: | 14:28 |
| slaweq | port.allocate_ip() | 14:28 |
| mlavalle | ^^^inside subnet creation | 14:28 |
| slaweq | which would be done after subnet creation | 14:28 |
| obondarev | can it be undesired behaviour for those using no-IP ports on purpose? | 14:28 |
| ralonsoh | but we can have a subnet withtout ports | 14:28 |
| slaweq | obondarev so we can add maybe config knob to disable this new behavior | 14:29 |
| slaweq | but use it for HA networks mentioned in https://bugs.launchpad.net/neutron/+bug/2016198 | 14:29 |
| obondarev | yeah, but if the only reason to do this is HA bug - I'd still fix race condition in traditional way | 14:29 |
| obondarev | by adding wait condition I mean | 14:30 |
| ralonsoh | if this is a race condition, then the best way is to use somehow the DB engine | 14:30 |
| mlavalle | I agree with ralonsoh | 14:30 |
| opendevreview | Slawek Kaplonski proposed openstack/neutron master: [S-RBAC] Switch to new policies by default https://review.opendev.org/c/openstack/neutron/+/879827 | 14:30 |
| obondarev | makes sense | 14:30 |
| slaweq | ok, so for HA networks bug there are for sure better solutions and ways to fix it | 14:31 |
| mlavalle | at the same time I agree with obondarev that we shouldn't add features to fix a bug | 14:31 |
| slaweq | and for RFE I'm -1 to remove this functionality from our API | 14:31 |
| ralonsoh | -1, agree, there should be another way to prevent this race condition | 14:32 |
| obondarev | so I guess there are several ways to fix the bug, and disallow no-IP port creation seems an overkill | 14:32 |
| ralonsoh | is there something that identifies an HA network? | 14:32 |
| obondarev | -1 for RFE | 14:32 |
| lajoskatona | agree, there should be users who depend on it | 14:32 |
| ralonsoh | that makes it different from other HA networks? | 14:32 |
| slaweq | ralonsoh nothing except name IIRC | 14:32 |
| mlavalle | it's just a network | 14:33 |
| ralonsoh | but is created for a router, right? | 14:33 |
| slaweq | it's created for tenant | 14:33 |
| ralonsoh | for a tenant, sorry | 14:33 |
| ralonsoh | yes | 14:33 |
| ralonsoh | so there we are: we can add a name check in the network creation | 14:33 |
| ralonsoh | in the DB engine | 14:34 |
| slaweq | but internally it can be identified easy | 14:34 |
| slaweq | it has own OVO object https://github.com/openstack/neutron/blob/47d070c71e795e41e698cdb278d99dcfb3448bde/neutron/objects/l3_hamode.py#L58 | 14:34 |
| ralonsoh | so there it is!! | 14:34 |
| slaweq | and there is method to find it https://github.com/openstack/neutron/blob/master/neutron/db/l3_hamode_db.py#L97 | 14:35 |
| ralonsoh | we can't have more that one L3HARouterNetwork per project | 14:35 |
| ralonsoh | right? | 14:35 |
| slaweq | yes | 14:35 |
| ralonsoh | so perfect, this condition is perfect for the DB engine | 14:35 |
| slaweq | https://github.com/openstack/neutron/blob/master/neutron/db/models/l3ha.py#L62 | 14:35 |
| mlavalle | the primary key is the project | 14:36 |
| ralonsoh | but not unique | 14:36 |
| ralonsoh | we need a new class for this | 14:36 |
| ralonsoh | but easily doable | 14:37 |
| ralonsoh | what do you think about proposing that in the LP bugs? | 14:37 |
| mlavalle | yes, let's do it | 14:37 |
| slaweq | ++ | 14:38 |
| obondarev | + | 14:38 |
| lajoskatona | +1 | 14:38 |
| ralonsoh | perfect, thank you all, good stuff! | 14:38 |
| ralonsoh | last topic | 14:38 |
| ralonsoh | mlavalle: Change in implementation of metadata rate limiting vs spec in order to support IPv6 | 14:38 |
| ralonsoh | please | 14:38 |
| mlavalle | I've continued the implementation of this feature after the original proposer indicated he couldn't continue doing it | 14:39 |
| opendevreview | Slawek Kaplonski proposed openstack/neutron master: Fix functional tests modules which are using PluginFixture https://review.opendev.org/c/openstack/neutron/+/881228 | 14:39 |
| mlavalle | the spec, https://specs.openstack.org/openstack/neutron-specs/specs/2023.1/metadata-rate-limit.html, didn't address ipv6 | 14:40 |
| mlavalle | ipv6 came up in one comment from ralonsoh to the proposed code | 14:40 |
| mlavalle | so addressing that comment, I've added ipv6 support | 14:40 |
| mlavalle | there is an issue, though. the opensource haproxy implementation only allows the tracking of 3 sticky counters | 14:41 |
| mlavalle | to implement the spec with rate limiting for ipv4 and ipv6 at he same time, we would need 4 sticky counters | 14:42 |
| mlavalle | btw, in line 79 here you can see the haproxy limitation: https://paste.openstack.org/show/bAE6IhPh4fQOGqFoxmMu/ | 14:43 |
| mlavalle | so I'm proposing a slight change to the spec | 14:43 |
| mlavalle | the deployer would need to decide whether the want to rate limit for ipv4 or ipv6, but not both at the same time | 14:44 |
| mlavalle | that was, we only need two sticky counters | 14:44 |
| slaweq | is that something what can be changed in haproxy in future? | 14:44 |
| lajoskatona | hmmm, sad but reasonable limitation | 14:45 |
| slaweq | TBH I don't think we need to have it for IPv6 for now | 14:45 |
| slaweq | it's not that widely used | 14:45 |
| mlavalle | their documentation explicitely indicates that the open source version only allows 3 sticky counters | 14:45 |
| obondarev | better than just limiting to ipv4 | 14:45 |
| slaweq | IPv4 should be more important | 14:45 |
| rubasov | I agree that currently we force the deployer to choose between ipv4 and ipv6, however I'd suggest to choose a config format that can allow both in the future, if/when we can support both at the same time | 14:46 |
| mlavalle | with my proposal we support both, just not both at the same time | 14:46 |
| lajoskatona | +1 | 14:46 |
| slaweq | ok | 14:47 |
| lajoskatona | I mean +1 for cfg option which can be used for allowing both | 14:47 |
| ralonsoh | +1, this is an external limitation and we provide to the user the ability to define which one is needed | 14:47 |
| ralonsoh | so I think we agree on the proposal | 14:48 |
| obondarev | +1 | 14:48 |
| ralonsoh | mlavalle, make a summary of this conversation in the LP bug | 14:48 |
| lajoskatona | +1, thanks mlavalle | 14:48 |
| ralonsoh | and thanks! | 14:48 |
| mlavalle | thanks, will do | 14:48 |
| ralonsoh | so that's all, anything else you want to discuss? | 14:48 |
| ralonsoh | have a nice weekend! | 14:49 |
| mlavalle | o/ | 14:49 |
| ralonsoh | #endmeeting | 14:49 |
| opendevmeet | Meeting ended Fri Apr 21 14:49:31 2023 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 14:49 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/neutron_drivers/2023/neutron_drivers.2023-04-21-14.00.html | 14:49 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/neutron_drivers/2023/neutron_drivers.2023-04-21-14.00.txt | 14:49 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/neutron_drivers/2023/neutron_drivers.2023-04-21-14.00.log.html | 14:49 |
| ralonsoh | bye | 14:49 |
| rubasov | o/ | 14:49 |
| obondarev | o/ | 14:49 |
| slaweq | have a great weekend | 14:49 |
| slaweq | o/ | 14:49 |
| lajoskatona | o/ | 14:49 |
| opendevreview | Slawek Kaplonski proposed openstack/neutron-tempest-plugin master: Don't run stable/xena jobs in check/gate queue anymore https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/881232 | 15:00 |
| opendevreview | Merged openstack/python-neutronclient master: Remove the CLI code from the Neutron client. https://review.opendev.org/c/openstack/python-neutronclient/+/871711 | 15:01 |
| slaweq | ralonsoh ^^ if You have time | 15:01 |
| slaweq | it will also need https://review.opendev.org/c/openstack/releases/+/881230 | 15:01 |
| dmitriis | https://review.opendev.org/c/openstack/releases/+/880267 - created a change for openstack/releases to bump up the neutron-lib version (related to https://review.opendev.org/c/openstack/neutron-lib/+/870887) | 15:12 |
| dmitriis | pasted a wrong link above, should be this instead: https://review.opendev.org/c/openstack/releases/+/881231 | 15:17 |
| opendevreview | Lajos Katona proposed openstack/neutron master: Doc: Add FWaaS v2 install details https://review.opendev.org/c/openstack/neutron/+/881239 | 15:40 |
| opendevreview | Lajos Katona proposed openstack/networking-sfc master: Doc: refresh sfc install details https://review.opendev.org/c/openstack/networking-sfc/+/881240 | 15:43 |
| opendevreview | Terry Wilson proposed openstack/neutron master: WIP Use neutron db for ovn agents https://review.opendev.org/c/openstack/neutron/+/818850 | 17:28 |
| opendevreview | Merged openstack/neutron master: Remove the ``OVNSqlFixture`` class workaround https://review.opendev.org/c/openstack/neutron/+/874669 | 17:30 |
| opendevreview | Miguel Lavalle proposed openstack/neutron master: Add rate-limiting to metadata agents https://review.opendev.org/c/openstack/neutron/+/858879 | 21:36 |
| opendevreview | Miguel Lavalle proposed openstack/neutron master: Add rate-limiting to metadata agents https://review.opendev.org/c/openstack/neutron/+/858879 | 22:30 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!