opendevreview | Merged openstack/neutron master: Add rate-limiting to metadata agents https://review.opendev.org/c/openstack/neutron/+/858879 | 00:10 |
---|---|---|
opendevreview | Brian Haley proposed openstack/neutron master: Fix some new pylint "W" warnings https://review.opendev.org/c/openstack/neutron/+/883605 | 01:56 |
opendevreview | Brian Haley proposed openstack/neutron master: Fix some new pylint "R" warnings https://review.opendev.org/c/openstack/neutron/+/883606 | 01:57 |
opendevreview | Brian Haley proposed openstack/neutron master: Fix some new pylint "E" warnings https://review.opendev.org/c/openstack/neutron/+/883607 | 01:57 |
opendevreview | Brian Haley proposed openstack/neutron master: Fix some new pylint "C" warnings https://review.opendev.org/c/openstack/neutron/+/883608 | 01:57 |
opendevreview | Brian Haley proposed openstack/neutron master: Fix some new pylint "W" warnings https://review.opendev.org/c/openstack/neutron/+/883605 | 02:32 |
opendevreview | zhouxinyong proposed openstack/networking-sfc master: Use new get_rpc_client API from oslo.messaging https://review.opendev.org/c/openstack/networking-sfc/+/883186 | 02:55 |
opendevreview | liuxie proposed openstack/neutron master: [OVN] Support address group for ovn driver https://review.opendev.org/c/openstack/neutron/+/851509 | 03:51 |
opendevreview | yatin proposed openstack/neutron master: [DNM] reproduce grenade issue https://review.opendev.org/c/openstack/neutron/+/883629 | 04:48 |
*** dmellado90 is now known as dmellado9 | 05:09 | |
*** EugenMayer45 is now known as EugenMayer4 | 06:17 | |
opendevreview | Slawek Kaplonski proposed openstack/neutron-specs master: Add "used_in_non_default_sg" attribute to the default SG rules API https://review.opendev.org/c/openstack/neutron-specs/+/883267 | 07:37 |
opendevreview | Slawek Kaplonski proposed openstack/neutron-specs master: Add "remote_address_group_id" attribute to the default SG rules API https://review.opendev.org/c/openstack/neutron-specs/+/883268 | 07:44 |
opendevreview | Slawek Kaplonski proposed openstack/neutron-specs master: Default SG rules - update fields in the API examples https://review.opendev.org/c/openstack/neutron-specs/+/883481 | 07:44 |
slaweq | ralonsoh ykarel lajoskatona hi, can You check https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/873380 ? I think it finally can be merged as https://review.opendev.org/c/openstack/devstack/+/880892 is merged in devstack | 07:46 |
slaweq | thx in advance | 07:46 |
ralonsoh | sure | 07:46 |
ralonsoh | slaweq, but the parent patch depends on https://review.opendev.org/c/openstack/neutron/+/880890 too | 07:48 |
opendevreview | Rodolfo Alonso proposed openstack/neutron master: gate: bump ovn to the latest LTS release (22.03) https://review.opendev.org/c/openstack/neutron/+/880890 | 07:49 |
opendevreview | liuxie proposed openstack/neutron master: [OVN] Support address group for ovn driver https://review.opendev.org/c/openstack/neutron/+/851509 | 08:11 |
ykarel | slaweq, ack | 08:47 |
opendevreview | Merged openstack/neutron master: [alembic] Alembic operations require keywords only arguments https://review.opendev.org/c/openstack/neutron/+/883340 | 09:18 |
opendevreview | liuxie proposed openstack/neutron master: [OVN] Support address group for ovn driver https://review.opendev.org/c/openstack/neutron/+/851509 | 09:27 |
opendevreview | yatin proposed openstack/neutron master: Disable mysql gather performance in jobs https://review.opendev.org/c/openstack/neutron/+/883648 | 09:32 |
lajoskatona | ralonsoh: Hi, today I can't participate on the Drivers meeting, hope you will have quorum | 09:35 |
ralonsoh | lajoskatona, no problem at all | 09:45 |
opendevreview | Dmitrii Shcherbakov proposed openstack/neutron master: Allow Multiple External Gateways https://review.opendev.org/c/openstack/neutron/+/873593 | 09:48 |
opendevreview | Dmitrii Shcherbakov proposed openstack/neutron master: Add extra router attributes for ECMP and BFD https://review.opendev.org/c/openstack/neutron/+/874797 | 09:49 |
opendevreview | Dmitrii Shcherbakov proposed openstack/neutron master: [ovn] Implement support for external-gateway-multihoming extension https://review.opendev.org/c/openstack/neutron/+/874199 | 09:49 |
opendevreview | Dmitrii Shcherbakov proposed openstack/neutron master: [ovn] Honor `enable_default_route_ecmp` attribute https://review.opendev.org/c/openstack/neutron/+/878531 | 09:49 |
opendevreview | Dmitrii Shcherbakov proposed openstack/neutron master: [ovn] Allow L3 scheduler to be aware of current transaction https://review.opendev.org/c/openstack/neutron/+/874760 | 09:49 |
opendevreview | Dmitrii Shcherbakov proposed openstack/neutron master: [ovn] Add helper for retrieving LR associated with LRP https://review.opendev.org/c/openstack/neutron/+/873698 | 09:49 |
opendevreview | Dmitrii Shcherbakov proposed openstack/neutron master: [ovn] Apply soft anti-affinity for LRs with multiple LRPs when scheduling https://review.opendev.org/c/openstack/neutron/+/873699 | 09:49 |
opendevreview | Dmitrii Shcherbakov proposed openstack/neutron master: [ovn] Add support for enable_default_route_bfd attribute https://review.opendev.org/c/openstack/neutron/+/878543 | 09:49 |
opendevreview | Rodolfo Alonso proposed openstack/neutron master: Use ``TextClause`` to define the DB model "server_default" https://review.opendev.org/c/openstack/neutron/+/883421 | 09:51 |
mnasiadka | ralonsoh: reno for neutron ovn agent mentions that it should run on compute and controllers - what about network nodes? (https://review.opendev.org/c/openstack/neutron/+/870024/12/releasenotes/notes/ovn-agent-added-84fc31c0fba02be9.yaml) | 10:01 |
ralonsoh | mnasiadka, so far it is not needed. The OVN agent will have the OVN metadata service by default (only needed in the compute nodes). A new extension was added to set the QoS rules on port with HW offload (but needed in compute nodes too) | 10:04 |
ralonsoh | actually I don't know why it should be needed in controllers | 10:05 |
mnasiadka | ok, so for now compute nodes are enough? | 10:05 |
ralonsoh | yes | 10:05 |
mnasiadka | thanks | 10:05 |
mnasiadka | So, does it serve metadata now, or is it a plan to move the functionality from metadata-agent to ovn-agent? | 10:06 |
ralonsoh | yes, there is a bug for this | 10:07 |
ralonsoh | one sec | 10:07 |
ralonsoh | the plan is to deprecate the ovn metadata agent | 10:07 |
mnasiadka | because we need ovn metadata agent on network nodes for ironic nodes | 10:07 |
mnasiadka | Ok, to be more precise - I'm asking about Antelope (2023.1) state of things | 10:07 |
ralonsoh | in the networker nodes? | 10:08 |
ralonsoh | https://bugs.launchpad.net/neutron/+bug/2017871 | 10:08 |
mnasiadka | ah, ok, rfe | 10:08 |
mnasiadka | yeah, for metadata on bare metal Ironic nodes - the metadata agent needs to run on network nodes | 10:09 |
opendevreview | Lucas Alvares Gomes proposed openstack/neutron master: [OVN] Expose chassis hosting information in LSP https://review.opendev.org/c/openstack/neutron/+/882705 | 10:09 |
ralonsoh | why not in the controller nodes? | 10:09 |
mnasiadka | external ports are scheduled on network nodes, right? | 10:10 |
mnasiadka | so on the nodes that have enable-chassis-as-gw set | 10:11 |
ralonsoh | yes, on these chassis | 10:11 |
mnasiadka | you have it documented here https://docs.openstack.org/neutron/latest/admin/ovn/baremetal.html#metadata-access ;-) | 10:11 |
mnasiadka | ok, then all clear, for now in Antelope Kolla-Ansible will deploy neutron-ovn-agent on computes only | 10:11 |
mnasiadka | once metadata service is moved there, we'll remove neutron-ovn-metadata-agent deployment and extend also to the network nodes | 10:11 |
mnasiadka | thanks again | 10:12 |
ralonsoh | yw | 10:12 |
ralonsoh | slaweq, trivial patches | 10:33 |
ralonsoh | https://review.opendev.org/c/openstack/neutron-dynamic-routing/+/883341 | 10:33 |
ralonsoh | https://review.opendev.org/c/openstack/neutron-vpnaas/+/883343 | 10:33 |
ralonsoh | thanks in advance | 10:33 |
opendevreview | Arnau Verdaguer proposed openstack/neutron master: [OVN trunk] Add bound info on subport when parent is bound https://review.opendev.org/c/openstack/neutron/+/882581 | 10:35 |
opendevreview | Rodolfo Alonso proposed openstack/neutron-fwaas master: Fix issues due to rcent RBAC changes https://review.opendev.org/c/openstack/neutron-fwaas/+/883653 | 10:37 |
slaweq | ralonsoh I just +2 both of them | 10:52 |
ralonsoh | thanks | 10:52 |
opendevreview | Rodolfo Alonso proposed openstack/neutron-fwaas master: Fix issues due to rcent RBAC changes https://review.opendev.org/c/openstack/neutron-fwaas/+/883653 | 11:25 |
opendevreview | Merged openstack/neutron-dynamic-routing master: [alembic] Alembic operations require keywords only arguments https://review.opendev.org/c/openstack/neutron-dynamic-routing/+/883341 | 11:42 |
ykarel | slaweq, can you check https://review.opendev.org/c/openstack/neutron/+/883648 | 12:19 |
dvo-plv | ralonsoh: Hello, I have a question regarding bp: https://review.opendev.org/c/openstack/nova-specs/+/859290/11/specs/2023.2/approved/support-napatech-linkvirtualization-smartnic.rst#55 | 12:20 |
dvo-plv | Could you please tell me, what you mean under nit2 comment | 12:20 |
slaweq | ykarel done | 12:44 |
opendevreview | Fernando Royo proposed openstack/ovn-octavia-provider master: Add retry on case of sqlite3.InterfaceError on FT https://review.opendev.org/c/openstack/ovn-octavia-provider/+/883662 | 12:44 |
ykarel | thx slaweq | 12:47 |
opendevreview | Merged openstack/neutron-specs master: Add "used_in_non_default_sg" attribute to the default SG rules API https://review.opendev.org/c/openstack/neutron-specs/+/883267 | 12:55 |
opendevreview | Merged openstack/neutron-specs master: Add "remote_address_group_id" attribute to the default SG rules API https://review.opendev.org/c/openstack/neutron-specs/+/883268 | 12:55 |
opendevreview | Fernando Royo proposed openstack/ovn-octavia-provider master: Add retry on case of sqlite3.InterfaceError on FT https://review.opendev.org/c/openstack/ovn-octavia-provider/+/883662 | 13:15 |
ralonsoh | dvo-plv, it was formated by gerrit. What I said was that you need to use double backtricks | 13:30 |
ralonsoh | ``OvsPlugin`` | 13:31 |
dvo-plv | okay, I will update | 13:32 |
dvo-plv | I would like to past this link https://github.com/openstack/os-vif/blob/18bd440bbe5692229ac029937000814393898298/vif_plug_ovs/ovs.py#L40 | 13:35 |
dvo-plv | but it too long, how I should add this properly? | 13:35 |
ralonsoh | https://www.urlshort.dev | 13:41 |
dvo-plv | thanks | 13:43 |
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 May 19 14:00:57 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 all | 14:00 |
amotoki | hi | 14:01 |
slaweq | o/ | 14:01 |
haleyb | o/ | 14:01 |
ralonsoh | Lajos is not attending today | 14:01 |
ykarel | o/ | 14:01 |
mtomaska | o/ | 14:01 |
ralonsoh | ok, I think we have quorum | 14:02 |
ralonsoh | let's start with the first topic | 14:02 |
ralonsoh | from liushy | 14:02 |
ralonsoh | #link https://bugs.launchpad.net/neutron/+bug/2016504 | 14:02 |
ralonsoh | [rfe]Support specify fixed_ip_address for DHCP or Metadata port | 14:02 |
ralonsoh | liushy, please | 14:02 |
liushy | Hi all | 14:02 |
sahid | o/ | 14:02 |
liushy | We want define a new api that can specify the fixed_ip for dhcp port or metadata port | 14:03 |
liushy | In this time, we firstly need agree the new api extention | 14:04 |
slaweq | did You try to create manually port with fixed_ip which You want and with device_owner set as "reserved_dhcp_port"? IMO such port should be later used by dhcp agent as dhcp port when network will be scheduled to the dhcp agent | 14:04 |
sahid | slaweq: whao interesting :-) | 14:06 |
liushy | Yeah, it is, but I have no good idea for reserved_dhcp_port | 14:07 |
ralonsoh | what do you mean? sorry, I don't understand | 14:07 |
liushy | Maybe this reserved dhcp port would not been | 14:07 |
liushy | Used | 14:07 |
ralonsoh | by who? this is the same as any other DHCP port. In any case, this is an alternative to be explored | 14:09 |
ihrachys_ | (it's device_id, not device_owner0 | 14:09 |
ralonsoh | yes, device_id | 14:09 |
ralonsoh | if port_device_id == constants.DEVICE_ID_RESERVED_DHCP_PORT | 14:09 |
ihrachys_ | and I don't think it's part of API (and specific to dhcp agent...), so it doesn't directly address the request | 14:09 |
haleyb | i guess OVN doesn't look for such port, but guess it could... | 14:09 |
ihrachys_ | but I struggle to see why the request is needed. why would a user want to specify this? | 14:10 |
mlavalle | yeah, what's the use case? | 14:10 |
amotoki | i have a same question as from ihar. what is the motivation of this RFE? | 14:10 |
slaweq | yeah, this device_owner is used by neutron-dhcp-agent but ML2/OVN is using "distributed" port probably | 14:11 |
liushy | Yeah, we have meet many customers want specify the dhcp ip or metadata ip | 14:11 |
ihrachys_ | they want it to achieve what? | 14:11 |
opendevreview | Merged openstack/neutron master: Disable mysql gather performance in jobs https://review.opendev.org/c/openstack/neutron/+/883648 | 14:11 |
amotoki | why do they want to specify such IPs? | 14:12 |
liushy | And in any cases, we have always update the ip of metadata port, right? | 14:12 |
slaweq | metadata port, why? | 14:13 |
ihrachys_ | liushy I don't follow. what do you mean we update the ip of metadata port? it's created when network is initialized and in general it's not touched. | 14:13 |
ralonsoh | so liushy, what is the rationale behind this RFE? why your customers need to "move" this IP addresses? | 14:15 |
ralonsoh | hello? | 14:18 |
liushy | In any cases, the first ip of subnet is config on switch | 14:18 |
amotoki | liushy: if so, you can define allocation_pools for a subnet not to use the first IP of the subnet | 14:19 |
ralonsoh | exactly | 14:19 |
slaweq | amotoki++ | 14:19 |
ralonsoh | does it solve your issue? skipping this IP address from the IPAM pool? | 14:20 |
ralonsoh | (except that you manually assign the IP address to a port) | 14:20 |
slaweq | actually in Your case if You would assign different IP to the dhcp port, then Your "first" ip from the subnet can be allocated to some vm | 14:21 |
slaweq | so You will just move problem somewhere else, not solve it | 14:21 |
slaweq | and using proper allocation pool in neutron can solve it permanently | 14:21 |
liushy | Ok | 14:22 |
ralonsoh | cool, please explore this alternative. I'll update the LP bug with amotoki's proposal | 14:23 |
mlavalle | ++ | 14:23 |
ralonsoh | thanks liushy | 14:24 |
ralonsoh | let's move then to the next topic | 14:24 |
ralonsoh | #link https://bugs.launchpad.net/neutron/+bug/2019960 | 14:24 |
ralonsoh | [RFE] Can't protect the "default" security group from regular users | 14:24 |
ralonsoh | I don't know if Paolo is in this channel now | 14:24 |
slaweq | I know this topic | 14:24 |
ralonsoh | slaweq, please go on then | 14:25 |
slaweq | ok, all started in the ML thread few days ago | 14:25 |
slaweq | author of this bug wanted to have policy which will not allow regular users to change SG rules in "default" SG | 14:25 |
slaweq | we are treating "default" SG in kind of special way, it's created for every project | 14:26 |
slaweq | and that can be valid use case | 14:26 |
slaweq | problem is that currently we can't configure even custom API policies for SG rules base on "name" of the SG, which is parent for the SG rule | 14:26 |
slaweq | I described it in https://lists.openstack.org/pipermail/openstack-discuss/2023-May/033719.html | 14:27 |
slaweq | it's the same thing like using "network:shared" field for e.g. ports or subnets | 14:27 |
slaweq | we are doing that but it required special treat in the code | 14:28 |
ralonsoh | in this case I would avoid this special treatment in the code, I would prefer to introduce a bool field (read-only) in the SG rule object | 14:28 |
slaweq | now the question is - do we want to introduce yet another "special" handling, this time for "security_group:name" attribute so it will be possible to use it in policies for SG rules | 14:28 |
ralonsoh | ^ no, I prefer a new field in the SG rule object, filtered as other field with a rule | 14:29 |
slaweq | ralonsoh something like "sg_default: True/False" in the SG rules? | 14:30 |
slaweq | or what? | 14:30 |
ralonsoh | yes | 14:30 |
ralonsoh | is_sg_default | 14:30 |
ralonsoh | a SG rule can be created or deleted | 14:30 |
ralonsoh | when the SG rule is created, the server will read the SG default flag and copy it to the SG rule | 14:31 |
ralonsoh | that will avoid the special treatment | 14:31 |
slaweq | yes, that way You will be able to use directly this new attribute in the api policies | 14:31 |
ihrachys | can it not be generated synthetically by neutron api layer? no need to store it I think. | 14:31 |
slaweq | ihrachys I think that that was the idea | 14:32 |
ralonsoh | that implies doing a second query every time we retrieve a SG rule | 14:32 |
slaweq | it can be calculated "in flight" | 14:32 |
ralonsoh | yes but with a cost | 14:32 |
ralonsoh | hmmm maybe we can, in the SG rule OVO, implement that query to the SG.is_default column | 14:33 |
ihrachys | optimize your query if that's a concern... storing has its own cost (not just in bytes, but keeping consistency, migrating db etc.) | 14:33 |
slaweq | I think that this is good idea | 14:34 |
ralonsoh | maybe we can use a back reference, adding the is_default value of the SG register in the SG rule OVO (that is a SQL view, in a nutshell) | 14:35 |
ralonsoh | ok, that's something technical | 14:35 |
ralonsoh | let's vote first if this RFE (the goal) is approved | 14:36 |
*** han-guangyu is now known as Guest672 | 14:36 | |
slaweq | +1 for that RFE and for ralonsoh's proposal how to solve it | 14:36 |
ralonsoh | do you agree with having a way to limit the SG rules modification belonging to the default SG? | 14:36 |
*** Guest672 is now known as han-guangyu | 14:37 | |
amotoki | +1 it sounds a reasnable request to me | 14:37 |
mlavalle | +1 | 14:37 |
ralonsoh | haleyb, ? | 14:38 |
haleyb | +1 | 14:38 |
ralonsoh | ykarel, are you part of the drivers team? I think so | 14:38 |
ralonsoh | is just to have more votes | 14:38 |
ralonsoh | because I don't present this RFE, I can vote | 14:39 |
ralonsoh | +1 from me | 14:39 |
ihrachys | +0 from me! | 14:39 |
ralonsoh | hehehe | 14:39 |
ralonsoh | thank you all | 14:39 |
ralonsoh | I think this request is reasonable | 14:39 |
ralonsoh | I'll try to implement a POC ASAP | 14:40 |
ralonsoh | I'll update the LP bug | 14:40 |
ralonsoh | something else you want to discuss? | 14:40 |
ralonsoh | PLEASE: kind (maybe not so kind) reminder to review the specs!! | 14:41 |
ralonsoh | have a nice weekend | 14:41 |
ralonsoh | #endmeeting | 14:41 |
opendevmeet | Meeting ended Fri May 19 14:41:26 2023 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 14:41 |
opendevmeet | Minutes: https://meetings.opendev.org/meetings/neutron_drivers/2023/neutron_drivers.2023-05-19-14.00.html | 14:41 |
opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/neutron_drivers/2023/neutron_drivers.2023-05-19-14.00.txt | 14:41 |
opendevmeet | Log: https://meetings.opendev.org/meetings/neutron_drivers/2023/neutron_drivers.2023-05-19-14.00.log.html | 14:41 |
slaweq | o/ | 14:41 |
mlavalle | o/ | 14:41 |
amotoki | o/ | 14:41 |
mtomaska | o/ | 14:41 |
opendevreview | Lucas Alvares Gomes proposed openstack/neutron master: [OVN] Expose chassis hosting information in LSP https://review.opendev.org/c/openstack/neutron/+/882705 | 14:44 |
opendevreview | Brian Haley proposed openstack/neutron master: Revert "Delete sg rule which remote is the deleted sg" https://review.opendev.org/c/openstack/neutron/+/883582 | 14:45 |
ykarel | ralonsoh, yes i am added in drivers meeting, but i had to leave just after the meeting started so didn't follow the discussion, sorry | 15:05 |
ralonsoh | no, no problem | 15:05 |
han-guangyu | hello, I see that when the dvr is turned on, the North/South SNAT is still in charge of the network node. I would like to ask, whether North/South SNAT is also distributed to computing nodes? | 15:22 |
han-guangyu | This requirement comes from the fact that I need to port forward many ports of only one floating ip to different ports of different vm. Such a large amount of traffic still gathers on the network nodes. Is there a way to disperse the load of the floating ip port forwarding on the network nodes? | 15:24 |
han-guangyu | Thank you for any help | 15:24 |
ralonsoh | han-guangyu, sorry no, we still don't have distributed snat, the port forwarding is done in done in the networker/controller nodes | 15:30 |
ralonsoh | at least in ML2/OVS. If I'm not wrong, with ML2/OVN you have dvr for port forwarding (but I would need to check that) | 15:31 |
ralonsoh | slaweq, ^^ am I wrong? | 15:32 |
slaweq | I think you're right | 15:33 |
han-guangyu | ralonsoh: hey, that's so good for me, I would try ML2/IVN | 15:35 |
opendevreview | Rodolfo Alonso proposed openstack/neutron master: Improve the ``PortBindingUpdateVirtualPortsEvent`` match filter https://review.opendev.org/c/openstack/neutron/+/883681 | 16:01 |
opendevreview | Rodolfo Alonso proposed openstack/neutron master: gate: bump ovn to the latest LTS release (22.03) https://review.opendev.org/c/openstack/neutron/+/880890 | 16:02 |
*** han-guangyu is now known as Guest686 | 16:12 | |
*** Guest686 is now known as han-guangyu | 16:13 | |
han-guangyu | ralonsoh: sorry to bother, I want to ask if the dvr for port forwarding of ML2/OVN is releated with openstack version | 16:19 |
han-guangyu | I'm now have a train env | 16:19 |
ralonsoh | I think so, let me check when that was added | 16:19 |
han-guangyu | ralonsoh: very appreciate for you | 16:20 |
ralonsoh | I see this extension in Train | 16:20 |
han-guangyu | ralonsoh: that's so good | 16:24 |
han-guangyu | ralonsoh: thank you | 16:25 |
han-guangyu | ralonsoh: May I know more, ML2/OVS does not have distributed snat, is there a technical blocking problem, or is it mainly because there is not enough manpower to invest in development | 16:25 |
ralonsoh | no time for implementing and testing | 16:25 |
han-guangyu | ok | 16:26 |
han-guangyu | best wishes for you, thank you so much for your answer about my question | 16:26 |
opendevreview | Dr. Jens Harbott proposed openstack/neutron-dynamic-routing stable/zed: Fix address_scope calculation https://review.opendev.org/c/openstack/neutron-dynamic-routing/+/883583 | 16:36 |
*** kmasterson` is now known as kmasterson | 16:48 | |
opendevreview | Rodolfo Alonso proposed openstack/neutron master: [WIP] Stop the RPC connections when the agent exits https://review.opendev.org/c/openstack/neutron/+/883685 | 16:53 |
opendevreview | sean mooney proposed openstack/neutron master: send ovn heatbeat more often. https://review.opendev.org/c/openstack/neutron/+/883687 | 17:09 |
*** melwitt_ is now known as melwitt | 17:11 | |
opendevreview | Elvira GarcĂa Ruiz proposed openstack/neutron master: [ovn] Avoid unwanted ACL_NOT_FOUND error when deleting log objects https://review.opendev.org/c/openstack/neutron/+/883693 | 18:36 |
opendevreview | Brian Haley proposed openstack/neutron master: Fix some new pylint "E" warnings https://review.opendev.org/c/openstack/neutron/+/883607 | 18:53 |
opendevreview | Miro Tomaska proposed openstack/neutron master: [OVN][Migration] Enable settings backup subnet for NFS clients https://review.opendev.org/c/openstack/neutron/+/869613 | 19:18 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!