| opendevreview | Merged openstack/ovn-octavia-provider master: setup.cfg: Replace dashes with underscores https://review.opendev.org/c/openstack/ovn-octavia-provider/+/788675 | 00:36 |
|---|---|---|
| opendevreview | Merged openstack/ovn-octavia-provider master: Add a Kuryr Kubernetes co-gating job https://review.opendev.org/c/openstack/ovn-octavia-provider/+/760225 | 01:10 |
| opendevreview | Merged openstack/ovn-octavia-provider master: Change minversion of tox to 3.18.0 https://review.opendev.org/c/openstack/ovn-octavia-provider/+/794902 | 01:40 |
| opendevreview | Lajos Katona proposed openstack/neutron master: WIP: Privsep with timeout for some privsep call https://review.opendev.org/c/openstack/neutron/+/794994 | 08:12 |
| *** mgoddard- is now known as mgoddard | 08:40 | |
| lajoskatona | ralonsoh: Hi, could You please check my pyroute2 related change for bagpipe: https://review.opendev.org/c/openstack/networking-bagpipe/+/800062 ? | 08:54 |
| ralonsoh | lajoskatona, sure | 08:54 |
| lajoskatona | ralonsoh: I am not sure if it is really needed, but pep8/pylint started to fail and I ralized that IPDB is deprecated from 1st July, and things like that | 08:55 |
| opendevreview | zhangyanxian proposed openstack/neutron master: [OVN] Update the local.conf for devstack https://review.opendev.org/c/openstack/neutron/+/800176 | 10:01 |
| opendevreview | Szymon Wróblewski proposed openstack/neutron master: Update AFTER callbacks of L3 DB FloatingIP https://review.opendev.org/c/openstack/neutron/+/798009 | 10:34 |
| *** luis5tb is now known as ltomasbo | 10:36 | |
| opendevreview | Szymon Wróblewski proposed openstack/neutron master: Update AFTER callbacks of L3 DB FloatingIP https://review.opendev.org/c/openstack/neutron/+/798009 | 10:48 |
| opendevreview | Lajos Katona proposed openstack/networking-bagpipe master: Follow pyroute2 changes https://review.opendev.org/c/openstack/networking-bagpipe/+/800062 | 11:30 |
| opendevreview | Lajos Katona proposed openstack/neutron master: WIP: Privsep with timeout for some privsep call https://review.opendev.org/c/openstack/neutron/+/794994 | 11:46 |
| opendevreview | Merged openstack/neutron master: Use IP_VERSION_{4,6} constants in ovn_client module https://review.opendev.org/c/openstack/neutron/+/799650 | 12:42 |
| simondodsley | Hi - looking for help with an issue on devstack where it appears the OVN routing is not getting set correctly and instances cannot ping the external world. They can successfully ping the compute host, but nothing beyond that, including the compute hosts gateway. This is causing major issues for our 3rd party Zuul CI for manila. | 13:12 |
| simondodsley | gouthamr: ^ | 13:13 |
| *** liuyulong__ is now known as liuyulong_ | 13:40 | |
| mlavalle | #startmeeting neutron_drivers | 14:00 |
| opendevmeet | Meeting started Fri Jul 9 14:00:12 2021 UTC and is due to finish in 60 minutes. The chair is mlavalle. 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 | hi | 14:00 |
| fnordahl | o/ | 14:00 |
| mlavalle | Good morning / afternoon / evening | 14:00 |
| haleyb | hi | 14:00 |
| amotoki | hi | 14:00 |
| rubasov | o/ | 14:01 |
| lajoskatona | Hi | 14:01 |
| manub | hi | 14:02 |
| dmitriis | o/ | 14:02 |
| obondarev | hi | 14:03 |
| mlavalle | let's see if yamamoto or njohnston show up. We need one of them to discuss the first RFE ion out agenda. Let's geve them a few minutes | 14:03 |
| mlavalle | https://review.opendev.org/admin/groups/5b063c96511f090638652067cf0939da1cb6efa7,members | 14:04 |
| ralonsoh | nate is on PTO | 14:04 |
| mlavalle | let's wait a few minutes. If we don't get any of them, we can discuss the other two RFEs in our agenda since we have quorum for those | 14:05 |
| mlavalle | fnordahl, dmitriis: are you here to discuss a RFE? I don't want to have you waiting until the end | 14:08 |
| dmitriis | yes | 14:08 |
| fnordahl | yes | 14:08 |
| mlavalle | ok, I see fnordahl filed https://bugs.launchpad.net/neutron/+bug/1932154 | 14:09 |
| mlavalle | so let's start there | 14:09 |
| mlavalle | #topic RFEs | 14:09 |
| mlavalle | https://bugs.launchpad.net/neutron/+bug/1932154 is up for discussion now | 14:10 |
| ralonsoh | I have one question about the spec (about the architecture) | 14:11 |
| dmitriis | sure | 14:11 |
| ralonsoh | in the schema, the "SmartNIC DPU Board" is hosting the OVN processes (controller, vswtichd, etc) | 14:11 |
| ralonsoh | but any Neutron process? | 14:11 |
| opendevreview | Lajos Katona proposed openstack/networking-bagpipe master: Follow pyroute2 changes https://review.opendev.org/c/openstack/networking-bagpipe/+/800062 | 14:12 |
| dmitriis | ralonsoh: We aim to avoid it in the OVN case. At least the goal is to not introduce any Neutron agents | 14:12 |
| dmitriis | at the moment there is a discussion upstream around representor plugging at the SmartNIC DPU side | 14:12 |
| ralonsoh | ok so is running the backend, not the orchestrator processes | 14:12 |
| ralonsoh | perfect then | 14:12 |
| dmitriis | yes, extra comms between Neutron and every SmartNIC DPU wouldn't be good | 14:13 |
| ralonsoh | so far, I'm ok with the RFE (and the spec although I need to review it again) | 14:13 |
| dmitriis | we are actively discussing the OVN bits upstream since a lot depends on them | 14:14 |
| amotoki | if it is only related to the backend, why do you need to use "binding:profile" (i.e. API visible field)? Can't you pass information from neutron (driver) to the backend? | 14:14 |
| amotoki | I understand you need to pass information on host to the backend (ovn). | 14:15 |
| ralonsoh | (I think this is for Nova) | 14:15 |
| fnordahl | as I understand it this is part of the current Nova -> Neutron communication which we continue to use here | 14:15 |
| dmitriis | the board serial number is needed to get an OVN chassis hostname | 14:16 |
| dmitriis | in case of port deletion that info needs to be present in the port as well | 14:16 |
| dmitriis | otherwise we don't know which SmartNIC DPU host should handle representor unplugging | 14:16 |
| dmitriis | (if that makes sense) | 14:18 |
| fnordahl | The OVN mechanism driver would most likely need it throughout the lifetime of the port, to know what requested-chassis to put on the LSP | 14:19 |
| amotoki | I see. no neutron agent like sriov agent, so you need to pass host information to OVN via the ovn mech driver running in the API server. | 14:19 |
| fnordahl | yes | 14:19 |
| mlavalle | and that is why you have a converstion upstream with ovn, to be able to coordinate that, correct? | 14:20 |
| dmitriis | yes, we need an entity that would do the job similar to os-vif | 14:21 |
| mlavalle | how is that conversation going? | 14:21 |
| fnordahl | Our conversation with OVN is to get code to look up representor ports running alongside / as part of the ovn-controller and extending the CMS API to specify how to find it. | 14:21 |
| mlavalle | do you think you will get the necessary support implemented? | 14:21 |
| fnordahl | Our target is to get it into OVN 21.09, it has been a conversation since May, and recently we have made progress with a few compromises from both sides suggested. We don't have a +2/-2 as of now, but I feel confident we will be able to move forward. | 14:22 |
| * mlavalle shudders at the thought of having to get approvals from ovn upstream, nova and worst of all, neutron ;-) | 14:23 | |
| fnordahl | add libvirt to the mix | 14:23 |
| fnordahl | ;) | 14:23 |
| mlavalle | LOL | 14:23 |
| dmitriis | mlavalle: yes, that's a tricky feature to coordinate | 14:24 |
| dmitriis | the libvirt part is just about retrieving PCIe VPD and exposing it | 14:24 |
| mlavalle | I'm fine with this RFE. I propose that we continue the detailed conversation in the spec | 14:24 |
| ralonsoh | right | 14:24 |
| dmitriis | we had a conversation about it already in the ML and it was approved | 14:24 |
| amotoki | which ML? | 14:25 |
| fnordahl | ^ I think dmitriis is talking about libvirt? | 14:25 |
| dmitriis | https://listman.redhat.com/archives/libvir-list/2021-May/msg00873.html | 14:25 |
| dmitriis | let me find a reply as well | 14:25 |
| amotoki | thanks | 14:25 |
| dmitriis | https://listman.redhat.com/archives/libvir-list/2021-June/msg00037.html | 14:26 |
| amotoki | there are several components involved. where can we get the whole picture on this? I think it is an important thing for people to understand how it works. | 14:26 |
| dmitriis | amotoki: the Nova spec contains a lot of information https://review.opendev.org/c/openstack/nova-specs/+/787458. It originally contained more Neutron and OVN pieces but we removed them during the review to keep it Nova-related | 14:27 |
| mlavalle | amotoki: I agree with you. Should we strive to get that whole picture in the spec phase? | 14:28 |
| fnordahl | The nova spec still has schematics (ascii) of the whole thing if I don't misremember dmitriis? | 14:28 |
| fnordahl | https://review.opendev.org/c/openstack/nova-specs/+/787458/9/specs/xena/approved/integration-with-off-path-network-backends.rst line 532 | 14:28 |
| dmitriis | fnordahl: yes there's a bit more information in it regarding certain pieces | 14:29 |
| fnordahl | amotoki: mlavalle: would that schema help? | 14:29 |
| mlavalle | I might ask for more in the spec, but at first glance it looks like a good start to me | 14:31 |
| amotoki | I cannot read through it right now, but it is okay as it looks like it covers the main picture. if we find something missing, we can cover it in the neutron spec (or add smth to the nova spec if needed) | 14:31 |
| amotoki | we can look thru the nova spec when reviewing the neutron spec. | 14:31 |
| fnordahl | ack | 14:31 |
| dmitriis | mlavalle, amotoki: ack | 14:32 |
| amotoki | I am feeling okay with this rfe. | 14:32 |
| mlavalle | yeah, we will have to read also at least the nova spec | 14:33 |
| mlavalle | haleyb: what are your thoughts? | 14:34 |
| haleyb | i'm +1 on it, just trying to read through the spec too | 14:34 |
| haleyb | complicated with all the dependencies | 14:34 |
| mlavalle | ok, I think we have the votes necessary yo approve this RFE today. Thanks fnordahl and dmitriis for this proposal. We'll see you in gerrit in the spec conversation | 14:35 |
| amotoki | fnordahl, dmitriis: the subject of the rfe says Off-path SmartNIC Port Binding, but can we add "with OVN"? | 14:35 |
| dmitriis | sure | 14:36 |
| dmitriis | done | 14:36 |
| fnordahl | thank you all for taking the time to review and discuss it with us | 14:36 |
| amotoki | dmitriis: thanks. it highlights the scope more :) | 14:36 |
| dmitriis | Yes, thanks a lot for considering it. The input is much appreciated as there are many pieces to this effort. | 14:37 |
| mlavalle | good luck herding all these cats! | 14:37 |
| dmitriis | 👍 | 14:38 |
| * mlavalle shudders again | 14:38 | |
| fnordahl | :) I might just add professional cat herder to my CV after this | 14:38 |
| mlavalle | ok, next up for discussion is https://bugs.launchpad.net/neutron/+bug/1933222 | 14:38 |
| ralonsoh | I have a couple of question (that I'll add to the LP bug) | 14:40 |
| ralonsoh | 1) shouldn't be called metadata aggregation? this is what he is proposing | 14:40 |
| ralonsoh | 2) what is the resource (memory) saving we gain? | 14:40 |
| ralonsoh | I saw that an haproxy is using around 2MB | 14:40 |
| ralonsoh | we can have tens of then in one host without any problem | 14:41 |
| ralonsoh | that's all from my side | 14:41 |
| mlavalle | he also raises reliability concerns in his rfe | 14:42 |
| obondarev | RPC chattiness is another concern as I see | 14:43 |
| obondarev | if not the main | 14:43 |
| ralonsoh | because if I'm not wrong, what he is proposing is NOT having a single metadata agent in one single place | 14:44 |
| ralonsoh | but one agent with one haproxy per host, right? | 14:45 |
| mlavalle | correct.... there will be an ovs bridge in each compute with flows properly set up | 14:45 |
| ralonsoh | (from c#3) | 14:45 |
| ralonsoh | so I don't see too much benefit on this (at least in memory or CPU usage) | 14:45 |
| haleyb | is there a spec? i guess i would like to see a diagram better describing what this META_IP range is and how the mapping is going to work | 14:46 |
| ralonsoh | no | 14:46 |
| obondarev | so there is meta agent and meta proxy now, the RFE is going to replace meta agent only IIUC | 14:47 |
| mlavalle | same understanding | 14:47 |
| lajoskatona | I think this proposal is in line with the distributed dhcp ( https://bugs.launchpad.net/neutron/+bug/1900934 ) | 14:47 |
| lajoskatona | to have only as minimum agents as possible and that is ovs-agent | 14:48 |
| mlavalle | yeah, it is really an overall effort on yulong's part to distribute a lot of the functions | 14:48 |
| ralonsoh | ok this is what I though initially but I didn't read that in the RFE | 14:49 |
| mlavalle | it is part of a broader picture | 14:50 |
| amotoki | my understanding is as yours. it tries to replace the metadata agent to per-host agent-like feature. I am not sure who plays a role of the metadata agent i.e. who laucnhes local haproxy. | 14:50 |
| amotoki | but perhaps it can be covered by a spec. | 14:51 |
| liuyulong_ | Hi guys, | 14:51 |
| ralonsoh | hi, we are discussing https://bugs.launchpad.net/neutron/+bug/1933222 | 14:51 |
| liuyulong_ | amotoki, it is ovs-agent | 14:51 |
| liuyulong_ | The datapath is VM -> br-int -> br-meta -> tap-meta -> host haproxy. | 14:52 |
| mlavalle | and all that path is in the same host | 14:52 |
| liuyulong_ | Yep | 14:52 |
| ralonsoh | so you want OVS agent to control the metadata proxy (I din't read that in the RFE) | 14:52 |
| obondarev | so may it result in more time needed to handle each new port? | 14:53 |
| liuyulong_ | ralonsoh, "So, I'd like to request for implementing an agent extension for Neutron | 14:53 |
| liuyulong_ | openvswitch agent to make the metadata datapath distributed." | 14:53 |
| obondarev | I mean overall | 14:53 |
| obondarev | currently the load is kind of shared between metadata/dhcp/l3 agents and ovs agent | 14:53 |
| liuyulong_ | obondarev, No, at least for our cloud. | 14:53 |
| obondarev | if ovs agent becomes responsible for all this.. | 14:54 |
| liuyulong_ | We implement this about 2 years ago, like distribtued DHCP extension for ovs-agent. | 14:54 |
| obondarev | so did you measure port provisioning time? | 14:55 |
| liuyulong_ | comparing to metadata agent, this is more reliable and fast. | 14:55 |
| mlavalle | if you did, it would be useful data in the rfe / spec | 14:55 |
| liuyulong_ | The origin metadata work procedure is: | 14:56 |
| liuyulong_ | VM -> router namespace -> haproxy -> metadata agent | 14:56 |
| mlavalle | with node hops in the middle | 14:57 |
| liuyulong_ | #link https://review.opendev.org/c/openstack/neutron/+/633871 | 14:57 |
| liuyulong_ | This is the fix of race conditon between VM booting and L3 agent processing router ( creating "router namespace + haproxy" ). | 14:58 |
| ralonsoh | one question: that feature will be independent to the L3 deployment (legacy, DVR, HA) now you don't need the router | 14:59 |
| ralonsoh | right? | 14:59 |
| liuyulong_ | "router namespace -> haproxy -> metadata agent" any of these point down will have effect on all hosts for VMs. | 14:59 |
| ralonsoh | but with your feature that won't be needed | 15:00 |
| ralonsoh | right? | 15:00 |
| liuyulong_ | Yes | 15:00 |
| ralonsoh | perfect | 15:00 |
| mlavalle | ok, we are at the top of the hour. We will start next meeting with this RFE, which will take place in two weeks | 15:00 |
| mlavalle | Have a nice weekend | 15:00 |
| ralonsoh | you too | 15:00 |
| liuyulong_ | OK | 15:00 |
| amotoki | this proposal replaces existing metadata-agent along with l3-agent and dhcp-agent with a per-host metadata-agent as part of ovs-agent. | 15:00 |
| mlavalle | #endmeeting | 15:00 |
| opendevmeet | Meeting ended Fri Jul 9 15:00:57 2021 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 15:00 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/neutron_drivers/2021/neutron_drivers.2021-07-09-14.00.html | 15:00 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/neutron_drivers/2021/neutron_drivers.2021-07-09-14.00.txt | 15:00 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/neutron_drivers/2021/neutron_drivers.2021-07-09-14.00.log.html | 15:00 |
| lajoskatona | Bye | 15:01 |
| rubasov | o/ | 15:01 |
| mlavalle | o/ | 15:01 |
| liuyulong_ | amotoki, partitially right, no metadata-agent anymore. | 15:01 |
| amotoki | liuyulong_: yes. so perhaps i need to say per-host metadata-agent FEATURE as part of ovs-agent. | 15:02 |
| liuyulong_ | And metatadata data (packets) will not be sent to ovs-agent. | 15:02 |
| liuyulong_ | Packets are sent to host haproxy. | 15:02 |
| ralonsoh | ok, now I see the picture much better | 15:03 |
| amotoki | don't meatadata packet from VM go thru ovs-agent? | 15:03 |
| liuyulong_ | Host haproxy is host only, only one. | 15:03 |
| liuyulong_ | Allow me quote from the LP bug: | 15:04 |
| liuyulong_ | For VMs which try to access metadata via 169.254.169.254:80 will be send to a new ovs-bridge, called br-meta. In this br-meta, the VM's fixed_IP + MAC (source) will be translated to a local META_IP + MAC, while the (dest) 169.254.169.254 is translated to local META_gateway IP which resides in tap-meta. Then send packets to a tap-meta device which resides in br-meta. A host only haproxy which listen the port 80 via | 15:04 |
| liuyulong_ | the device tap-meta and then trasimit the request to nova-metadata-api. | 15:04 |
| ralonsoh | liuyulong_, one qq: what if you have IP+MAC duplicated from different networks? | 15:04 |
| amotoki | liuyulong_: so how can metadata from different networks handled? | 15:04 |
| amotoki | ah, ralonsoh asked the same question | 15:05 |
| amotoki | different networks can have same IP/MAC | 15:05 |
| liuyulong_ | VM fixed_IP + MAC pair will be translated to host only META_IP + MAC | 15:05 |
| liuyulong_ | No matter the VM coming from. | 15:05 |
| amotoki | same pair of (fixed_IP, MAC) from different networks work? how are they distinguished? | 15:06 |
| liuyulong_ | No overlaping in " META_IP + MAC" in one host. | 15:06 |
| ralonsoh | why? you can have several networks in one host | 15:06 |
| ralonsoh | and duplicated MACs | 15:06 |
| liuyulong_ | META_IP can be something like this "100.100.0.0/16" which META_MAC range can be "fe:ee:00:00:00:00". | 15:07 |
| amotoki | (IP1,MAC1) on net1 and (IP1,MAC1 on net2 can be on a same host. how are they distinguished? | 15:07 |
| liuyulong_ | VM1 from network1 has IP 192.168.1.1 and MAC aa:aa:aa:aa:aa:aa. While VM2 has same MAC + IP from network2. | 15:07 |
| liuyulong_ | VM1's IP + MAC will be translated to, for instance, 100.100.1.100 + fe:ee:00:00:11:11 | 15:08 |
| liuyulong_ | while VM2 is to 100.100.1.101 + fe:ee:00:00:11:12 | 15:08 |
| amotoki | so does the mapping key include netowrk infomration too? | 15:09 |
| liuyulong_ | Am i clear? | 15:09 |
| ralonsoh | not really, sorry | 15:09 |
| amotoki | you said "(IP, MAC)" wil be mapped to (MATA_IP, MAC), but (net, ip, mac) is mapped to (meta_ip, mac). perhaps you assume vlan infomration in ovs implicitlly | 15:10 |
| amotoki | (or port info in ovs) | 15:10 |
| liuyulong_ | amotoki, local vlan (match and check) will be applied in flows. | 15:10 |
| ralonsoh | yes, you have vlan isolation in OVS, but when this request reaches haproxy, how do you filter by VLAN? | 15:11 |
| ralonsoh | anyway, maybe we can wait for the RFE for this | 15:11 |
| liuyulong_ | VM -> br-int -> br-meta -> tap-meta -> host haproxy. | 15:12 |
| liuyulong_ | I will expand this... | 15:12 |
| amotoki | perhaps br-meta applies this mapping from (local-vlan, ip, mac) to (meta-ip, mac) and send it to tap-meta. | 15:13 |
| amotoki | this can be covered in a comment in the rfe. | 15:13 |
| liuyulong_ | VM -> (192.168.1.1 + aa:aa:aa:aa:aa:aa) to 169.254.169.254:80 -> br-meta -> match local vlan + (192.168.1.1 + aa:aa:aa:aa:aa:aa) -> 100.100.1.100 + fe:ee:00:00:11:11 | 15:13 |
| liuyulong_ | 169.254.169.254:80 -> 100.100.0.1:80 which resides in br-meta | 15:14 |
| liuyulong_ | 169.254.169.254:80 -> 100.100.0.1:80 which resides in tap-meta | 15:15 |
| liuyulong_ | strip vlan and send to tap-meta | 15:15 |
| liuyulong_ | Then packet goes back. | 15:15 |
| amotoki | i think DNAT happens when going thru br-meta (not in tap-meta) | 15:16 |
| liuyulong_ | Before send back, ARP will do first, tap-meta(100.100.0.1) will try to find 100.100.1.100's MAC | 15:16 |
| liuyulong_ | so, the ARP responder will be added to br-meta to answer this. | 15:16 |
| ralonsoh | yes, now I understand it: the DNAT address will depend on the network | 15:16 |
| amotoki | ralonsoh: do you mean DNAT'ed address assigned to local haproxy is per-network? | 15:18 |
| liuyulong_ | Back packet is firstly from haproxy is TCP:[from 100.100.1.1:80 to 100.100.1.100:TCP_SRC_PORT + fe:ee:00:00:11:11] | 15:18 |
| ralonsoh | amotoki, I think so | 15:18 |
| amotoki | ralonsoh: it is different from what liuyulong_ said. | 15:18 |
| ralonsoh | hahaha anyway, today is not my best day understanding concepts... | 15:19 |
| amotoki | ralonsoh: he said same (IP, MAC) can be covered into (100.100.1.101 + fe:ee:00:00:11:11) for net1 and (100.100.1.101 + fe:ee:00:00:11:12) for net2. | 15:19 |
| liuyulong_ | This packet goes to br-meta, then match " 100.100.1.100 + fe:ee:00:00:11:11", with action change dest to "192.168.1.1 + aa:aa:aa:aa:aa:aa" | 15:19 |
| liuyulong_ | and mod_vlan with local_vlan of this port | 15:20 |
| amotoki | ralonsoh: hahaha. anyways i agree this is complicated enought when we try to explain it only by words..... | 15:20 |
| liuyulong_ | While source IP address is changing from 100.100.0.1 to 169.254.169.254 | 15:20 |
| liuyulong_ | then go to br-int, finally hit a direct (dest mac is VM's port) flow to VM. | 15:21 |
| opendevreview | Lajos Katona proposed openstack/networking-bagpipe master: Follow pyroute2 changes https://review.opendev.org/c/openstack/networking-bagpipe/+/800062 | 15:24 |
| liuyulong_ | ralonsoh, https://review.opendev.org/c/openstack/neutron/+/799159, hi, would have time to take a look of this again? | 15:25 |
| ralonsoh | liuyulong_, sure | 15:25 |
| opendevreview | Merged openstack/neutron master: Check router routes connectivity when GW port is updated https://review.opendev.org/c/openstack/neutron/+/789929 | 15:59 |
| opendevreview | Elvira García Ruiz proposed openstack/neutron master: [OVN] Change ControllerAgent type dinamically https://review.opendev.org/c/openstack/neutron/+/800278 | 16:17 |
| opendevreview | Merged openstack/ovn-octavia-provider master: Improve enabled_provider_drivers default in devstack https://review.opendev.org/c/openstack/ovn-octavia-provider/+/782941 | 17:06 |
| *** melwitt is now known as Guest322 | 17:31 | |
| *** melwitt_ is now known as melwitt | 17:57 | |
| *** melwitt is now known as jgwentworth | 17:58 | |
| opendevreview | Michael Johnson proposed openstack/neutron-tempest-plugin master: Update service client access test_dns_integration https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/800291 | 18:24 |
| opendevreview | Michael Johnson proposed openstack/neutron-tempest-plugin master: Update service client access test_dns_integration https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/800291 | 19:26 |
| opendevreview | Brian Haley proposed openstack/ovn-octavia-provider master: Add Health Monitor support https://review.opendev.org/c/openstack/ovn-octavia-provider/+/713253 | 22:39 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!