| yangyi01 | hello, anybody there? | 01:08 |
|---|---|---|
| yangyi01 | Is driver meeting Beijing Time 22:00 Fri if it is UTC 14:00 Fri? | 01:09 |
| opendevreview | Ihar Hrachyshka proposed openstack/neutron master: Bump minimal ovsdbapp version to 1.11.0 https://review.opendev.org/c/openstack/neutron/+/796943 | 01:32 |
| slaweq | yangyi01 hi, yes, that's correct | 06:17 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: Sanitize MAC addresses https://review.opendev.org/c/openstack/neutron/+/789831 | 06:36 |
| opendevreview | Kamil Sambor proposed openstack/neutron master: Enable querier for multicast (IGMP) in OVN https://review.opendev.org/c/openstack/neutron/+/796997 | 07:15 |
| opendevreview | Slawek Kaplonski proposed openstack/neutron stable/wallaby: Read keepalived initial state in parallel to interface monitoring https://review.opendev.org/c/openstack/neutron/+/796865 | 07:33 |
| opendevreview | Slawek Kaplonski proposed openstack/neutron stable/victoria: Read keepalived initial state in parallel to interface monitoring https://review.opendev.org/c/openstack/neutron/+/796866 | 07:34 |
| opendevreview | Slawek Kaplonski proposed openstack/neutron stable/ussuri: Read keepalived initial state in parallel to interface monitoring https://review.opendev.org/c/openstack/neutron/+/796998 | 07:37 |
| opendevreview | Jakub Libosvar proposed openstack/neutron stable/wallaby: ovn: Don't use dict.remove() for filtering dhcp ports in db-sync https://review.opendev.org/c/openstack/neutron/+/796872 | 07:43 |
| opendevreview | Jakub Libosvar proposed openstack/neutron stable/victoria: ovn: Don't use dict.remove() for filtering dhcp ports in db-sync https://review.opendev.org/c/openstack/neutron/+/797013 | 07:43 |
| opendevreview | Slawek Kaplonski proposed openstack/neutron stable/train: Read keepalived initial state in parallel to interface monitoring https://review.opendev.org/c/openstack/neutron/+/796999 | 07:45 |
| opendevreview | Jakub Libosvar proposed openstack/neutron stable/ussuri: ovn: Don't use dict.remove() for filtering dhcp ports in db-sync https://review.opendev.org/c/openstack/neutron/+/797000 | 07:48 |
| opendevreview | Lajos Katona proposed openstack/networking-bgpvpn stable/train: stable only: Fix failing jobs and make l-c non-voting https://review.opendev.org/c/openstack/networking-bgpvpn/+/796808 | 07:56 |
| opendevreview | Jakub Libosvar proposed openstack/networking-ovn stable/train: ovn: Don't use dict.remove() for filtering dhcp ports in db-sync https://review.opendev.org/c/openstack/networking-ovn/+/797001 | 07:58 |
| *** rpittau|afk is now known as rpittau | 08:17 | |
| opendevreview | Slawek Kaplonski proposed openstack/neutron master: Remove FIP agent's gw port when L3 agent is deleted https://review.opendev.org/c/openstack/neutron/+/787691 | 08:21 |
| opendevreview | Mamatisa Nurmatov proposed openstack/neutron master: use payloads for PORT AFTER_UPDATE events https://review.opendev.org/c/openstack/neutron/+/795117 | 08:31 |
| opendevreview | Slawek Kaplonski proposed openstack/neutron master: Force to close http connection after notify about HA router status https://review.opendev.org/c/openstack/neutron/+/796844 | 08:34 |
| opendevreview | Mamatisa Nurmatov proposed openstack/neutron master: use payloads for PORT AFTER_DELETE events https://review.opendev.org/c/openstack/neutron/+/797004 | 08:34 |
| slaweq | ralonsoh obondarev lajoskatona please check https://review.opendev.org/c/openstack/neutron/+/796844 when You will have some time | 08:34 |
| ralonsoh | slaweq, right now | 08:38 |
| slaweq | Thanks | 08:55 |
| bcafarel | slaweq: wow nice one (I guess it is something to backport to branches running on focal?) | 09:02 |
| slaweq | bcafarel yes, I will backport it | 09:02 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: Sanitize MAC addresses https://review.opendev.org/c/openstack/neutron/+/789831 | 09:21 |
| ralonsoh | lajoskatona, can you please check https://review.opendev.org/c/openstack/neutron/+/795761? | 09:24 |
| ralonsoh | thank you in advance | 09:24 |
| lajoskatona | ralonsoh: sure | 09:25 |
| ralonsoh | lucasagomes, if you have some time (I know the patch is quite big): minBW placement for OVN | 09:25 |
| ralonsoh | https://review.opendev.org/c/openstack/neutron/+/776701/22 | 09:25 |
| ralonsoh | (there are other 3 patches on top of this one) | 09:25 |
| lucasagomes | ralonsoh, thanks I will try to take a look soon | 09:29 |
| bcafarel | slaweq: https://review.opendev.org/c/openstack/neutron/+/788893 so this may change default value returned, but I suppose if get_hypervisor_hostname != socket.gethostname() that deployment was not working properly? | 09:50 |
| bcafarel | (aka for existing working deployments, this does not change the value returned) | 09:50 |
| slaweq | bcafarel do You mean resource_provider_default_hypervisor's value? | 09:53 |
| bcafarel | slaweq: yes, if an existing working deployment had socket.gethostname() and after that patch value returned by get_hypervisor_hostname() is a different one | 09:55 |
| bcafarel | if I got it correctly this should not exist in the real world (as it would mean broken configuration and non-working hypervisor), but just wanted to confirm :) | 09:56 |
| bcafarel | as it potentially changes the default value used | 09:56 |
| slaweq | bcafarel yes, it may, but that config option was introduced in the previous patch in same series: https://review.opendev.org/c/openstack/neutron/+/763563/8 | 09:57 |
| slaweq | so in fact nobody will use one without another :) | 09:57 |
| bcafarel | ooh true | 09:58 |
| bcafarel | well I had reviewed the previous patch at least 20 minutes ago, so it is normal I forgot about it in this long interval :) | 09:59 |
| slaweq | :D | 10:00 |
| opendevreview | Dr. Jens Harbott proposed openstack/neutron-dynamic-routing master: Drop dsvm-functional tox env and related files https://review.opendev.org/c/openstack/neutron-dynamic-routing/+/797044 | 10:17 |
| opendevreview | Dr. Jens Harbott proposed openstack/neutron-dynamic-routing master: Use xena-based job definitions instead of wallaby https://review.opendev.org/c/openstack/neutron-dynamic-routing/+/797045 | 10:17 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: Make explicit the network backend used in the CI jobs https://review.opendev.org/c/openstack/neutron/+/797051 | 10:27 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: Make explicit the network backend used in the CI jobs https://review.opendev.org/c/openstack/neutron/+/797051 | 10:50 |
| opendevreview | Slawek Kaplonski proposed openstack/neutron master: DVR: Populate ARP entries of the allowed_address_pairs to the routers https://review.opendev.org/c/openstack/neutron/+/601336 | 11:08 |
| opendevreview | Jakub Libosvar proposed openstack/neutron master: ovn: Make ovn metadata agent report optional https://review.opendev.org/c/openstack/neutron/+/792998 | 12:07 |
| opendevreview | Mamatisa Nurmatov proposed openstack/neutron master: use callback payloads for SECURITY_GROUP https://review.opendev.org/c/openstack/neutron/+/674044 | 12:09 |
| opendevreview | Mamatisa Nurmatov proposed openstack/neutron master: use callback payloads for SECURITY_GROUP_RULE https://review.opendev.org/c/openstack/neutron/+/792895 | 12:26 |
| opendevreview | Slawek Kaplonski proposed openstack/networking-sfc master: Use ovs constants from neutron-lib https://review.opendev.org/c/openstack/networking-sfc/+/797077 | 12:53 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: Make explicit the network backend used in the CI jobs https://review.opendev.org/c/openstack/neutron/+/797051 | 13:14 |
| opendevreview | Mamatisa Nurmatov proposed openstack/neutron master: use payloads for PORT AFTER_DELETE events https://review.opendev.org/c/openstack/neutron/+/797004 | 13:24 |
| opendevreview | Luis Tomas Bolivar proposed openstack/neutron master: WIP/DNR Add neutron port tags information into OVN DBs https://review.opendev.org/c/openstack/neutron/+/797087 | 13:59 |
| slaweq | #startmeeting neutron_drivers | 14:00 |
| opendevmeet | Meeting started Fri Jun 18 14:00:18 2021 UTC and is due to finish in 60 minutes. The chair is slaweq. 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 |
| slaweq | hi | 14:00 |
| fnordahl | o/ | 14:00 |
| mlavalle | o/ | 14:00 |
| obondarev | hi | 14:00 |
| amotoki | o/ | 14:00 |
| lajoskatona | i | 14:00 |
| lajoskatona | Hi | 14:00 |
| velizarx_ | o/ | 14:01 |
| ralonsoh | hi | 14:01 |
| yangyi01 | hi | 14:01 |
| *** velizarx_ is now known as velizarx | 14:01 | |
| dmitriis | o/ | 14:02 |
| slaweq | I think we can start | 14:02 |
| slaweq | #topic RFEs | 14:02 |
| slaweq | we have one new RFE for today | 14:03 |
| slaweq | https://bugs.launchpad.net/neutron/+bug/1931953 | 14:03 |
| slaweq | which in fact isn't very new as we had something similar in the past | 14:03 |
| slaweq | https://bugs.launchpad.net/neutron/+bug/1705536, https://blueprints.launchpad.net/neutron/+spec/openflow-based-dvr | 14:03 |
| ralonsoh | I added this topic but I shouldn't talk about it | 14:04 |
| slaweq | ralonsoh I think You should :) | 14:04 |
| yangyi01 | I filed this REF | 14:04 |
| ralonsoh | yangyi01, will present this feature better than me | 14:04 |
| ralonsoh | right | 14:04 |
| slaweq | hi yangyi01, good that You are here :) | 14:04 |
| yangyi01 | ok, let me talk about why we need it. | 14:05 |
| yangyi01 | Actually, I have worke on this tough issue last year in OVS project. | 14:06 |
| yangyi01 | We want to use OVS DPDK in openstack | 14:06 |
| mlavalle | who's we? | 14:07 |
| yangyi01 | But obviously it is very very bad as far as performance is concerned. | 14:07 |
| yangyi01 | Inpur, China-based cloud provider. | 14:07 |
| mlavalle | ack | 14:07 |
| yangyi01 | I have fixed many perofermance issues on OVS DPDK side. | 14:08 |
| yangyi01 | including VXLAN TSO, GRO, GSO, UFO, etc. | 14:08 |
| yangyi01 | I also have a batch process patch to improve tap and veth performnce in OVS, it has been merged. | 14:09 |
| *** rpittau is now known as rpittau|afk | 14:09 | |
| yangyi01 | that can improve performance significantly, but it is far not enough. | 14:10 |
| yangyi01 | it is best way not to use tap and veth in OVS DPDK case. | 14:10 |
| yangyi01 | that is why I want to have this REF. | 14:11 |
| yangyi01 | this can improve across-node L3 vm to vm performance and FIP performance dramatically. | 14:12 |
| yangyi01 | the result is really incredible. | 14:12 |
| yangyi01 | this REF also can improve OVS kernel performance and big UDP issue. | 14:13 |
| mlavalle | in your RFE you mention that it is different to https://blueprints.launchpad.net/neutron/+spec/openflow-based-dvr. How is it different? | 14:13 |
| yangyi01 | now, big UDP or big ICMP can't work in OVS kernel case with security group in linux bridge. | 14:14 |
| yangyi01 | yes, implementation way is different. | 14:14 |
| mlavalle | how? | 14:14 |
| yangyi01 | I think old spec only considered virtual IP, didn't consider FIP. | 14:15 |
| ralonsoh | it was, in centralized mode | 14:15 |
| yangyi01 | for FIP, only neutron as a SDN controller and handle ARP request can fix it. | 14:16 |
| amotoki | IIRC current DVR supports FIP from compute nodes. | 14:17 |
| yangyi01 | yes, for SNAT, it also used FIP, that can be centralized or distributed. | 14:18 |
| ralonsoh | for sure, L3 agents supports this, not the Intel implementation for OF DVR | 14:18 |
| ralonsoh | but let's focus on the new implementation | 14:18 |
| yangyi01 | Intel just impelmented l3 agent by using openflow. | 14:19 |
| yangyi01 | I was Intel guy before. | 14:19 |
| slaweq | do You think that Your solution may replace current DVR implementation, or we should keep both in-tree? | 14:19 |
| yangyi01 | if you chech that submited implementation patch, I don't think it can work, it din't install flow per FIP or qrouter. | 14:20 |
| mlavalle | meaning it cannot replace the current DVR implementation? | 14:21 |
| opendevreview | Lajos Katona proposed openstack/networking-bgpvpn stable/train: stable only: Fix failing jobs and make l-c non-voting https://review.opendev.org/c/openstack/networking-bgpvpn/+/796808 | 14:21 |
| yangyi01 | We added a config option dvr_use_openflow, if set to True, l3 agent will install openflow to br-int, if false, old way can still work. | 14:22 |
| yangyi01 | my REF depends on current DVR impelmetation. | 14:22 |
| amotoki | do you mean the neutron tree maintains two different OVS based DVR implementations? | 14:22 |
| mlavalle | thanks for the clarification | 14:23 |
| obondarev | I'd say not only DVR but all L3 agent, right? | 14:23 |
| slaweq | so in Your implementation L3 agent will change flows in the br-int directly, right? | 14:24 |
| yangyi01 | I think it is ok. With old implementation there, users can use old namespaces to do anything as before. | 14:24 |
| yangyi01 | yes | 14:25 |
| slaweq | my main concern is maintenance of that code, we will need to add new CI job to have it tested, etc. | 14:25 |
| slaweq | :/ | 14:25 |
| yangyi01 | it is worthy for super high performance. | 14:25 |
| obondarev | an option is to have it in a separate networking-ovs-dvr repo, right? | 14:26 |
| ralonsoh | that's a good option | 14:26 |
| yangyi01 | FIP can reach line speed, I don't think current implementation can attain this. | 14:26 |
| ralonsoh | I have the same concern as slaweq. This is not like the distributed DHCP feature in OVS, that removes the need of any DHCP agent. | 14:27 |
| mlavalle | or why don't we go in the opposite direction... could this proposal be used as a springboard to have a brand new DVR implementaion in tree? | 14:27 |
| slaweq | or include it in networking-ovs-dpdk repo maybe? | 14:27 |
| ralonsoh | here you are duplicating paths: with iptables or OF, but keeping the L3 agent | 14:27 |
| ralonsoh | (and the L3 agent code is not easy to maintain) | 14:27 |
| ralonsoh | networking-ovs-dpdk is dead | 14:28 |
| mlavalle | that's why I say, take this as an opportunity for a new reset | 14:28 |
| yangyi01 | this isn't ML2 driver, main neutron tree is best place for this. | 14:28 |
| mlavalle | yangyi01: what would it take to expand your effort to completely replace our current DVR implementation? | 14:29 |
| yangyi01 | Not sure, if it has been stable enough, we can remove old unnecesary DVR code. | 14:31 |
| amotoki | our concern is mainly for the maintenance cost of having competing DVR implementations. It includes the number of CI jobs, review bandwitdh and deeper knowledge of specific impls. | 14:31 |
| * mlavalle understands slaweq and ralonsoh concerns about CI and all that. But meaybe this is an opportunity to offer our OVS deployments a more performant DVR implementation. THos OVS deployments will be around for a loong time | 14:31 | |
| ralonsoh | mlavalle, we should support linux bridge | 14:31 |
| ralonsoh | that won't work with an OF based L3 agent | 14:32 |
| slaweq | ralonsoh DVR don't works with linux bridge currently | 14:32 |
| slaweq | so that's not an issue IMO | 14:32 |
| ralonsoh | right | 14:32 |
| ralonsoh | sorry | 14:32 |
| mlavalle | all I'm saying is that we have and will have for a long time OVS users and we should strive to improve their performance experience when the oppotunity arises. Maybe this is one of these opportunities if we expand the effort | 14:33 |
| slaweq | TBH personally I'm a bit torn here - from one side I have this maintenance concern, but from the other hand I like idea of more performant DVR implementation, especially that old RFE for that was actually approved already long time ago :) | 14:33 |
| ralonsoh | I'm ok with this if that means replace any other implementation. I prefer not to have two paths in the code | 14:33 |
| mlavalle | yeah, I agree with not having two paths in the code | 14:34 |
| yangyi01 | Finally, we can have one path if new path is good enough, I'm not sure if it covers some corner cases. | 14:35 |
| ralonsoh | you have my +1 if that RFE includes the replacement of all iptables/conntrack code and provides the same functionality | 14:36 |
| ralonsoh | and a good spec to know how are you going to implement it | 14:36 |
| mlavalle | so going back to yangyi01, could we re-scope your RFE / spec in such a way that the effort's goal is to replace our DVR implementation in OF? | 14:36 |
| slaweq | I agree with ralonsoh - if that can finally be replacement for old implementation of DVR, than I'm ok with it | 14:36 |
| slaweq | but IMO we will need much more detailed spec first | 14:37 |
| amotoki | ralonsoh: what do you mean by "the replacement of all iptables/conntrack code"? is it the one related to the current DVR? | 14:37 |
| amotoki | or l3-agent itself? | 14:37 |
| ralonsoh | amotoki, yes, just this code | 14:37 |
| yangyi01 | No problem, please point out what parts it ddin't cover, I can add them. | 14:37 |
| ralonsoh | no no, not all L3 agent, only DVR stuff | 14:37 |
| mlavalle | ralonsoh: DVR, right? | 14:37 |
| ralonsoh | yes | 14:38 |
| amotoki | ralonsoh: thanks | 14:38 |
| mlavalle | +1 | 14:38 |
| obondarev | what is L3 agent without DVR? | 14:38 |
| yangyi01 | I have iplemented it, maybe patch is best spec. | 14:38 |
| ralonsoh | sorry no | 14:38 |
| obondarev | in a DVR env DVR and L3 agent seem the same | 14:38 |
| ralonsoh | I could help, but no | 14:38 |
| yangyi01 | I can submit my patch if you want to know details. | 14:38 |
| yangyi01 | l2 agent also handled many DVR-related stuff, DVR is very complicated. | 14:39 |
| slaweq | yangyi01 only implementation will for sure not be enough, even if not detailed spec, we would need some docs patch at least with detailed description of tables/flows/etc. | 14:39 |
| mlavalle | yeah, because we have to live with the maintenace issue | 14:40 |
| mlavalle | so I'd say, let's start with a good spec of what is going to be done | 14:40 |
| yangyi01 | understood, developers prefer code to docuemnt. | 14:40 |
| mlavalle | yangyi01: we are being supportive of you, don't dismiss us as non-developers | 14:41 |
| mlavalle | not very nice of you | 14:41 |
| slaweq | so let's vote - I'm +1 to approve this rfe, but it's final goal should be to replace current dvr implementation, and we will need detailed spec and docs with description of how it works | 14:43 |
| yangyi01 | mlavalle, sorry, I can add parts you expect, please add your comments in current spec. not sure what parts are missed. | 14:43 |
| ralonsoh | +1 with those conditions | 14:43 |
| mlavalle | +1 with aformentioned conditions | 14:44 |
| yangyi01 | +1 by myself :-) | 14:44 |
| slaweq | amotoki any thoughts? | 14:45 |
| amotoki | +1. I agree the final goal should cover replacing with the current dvr impl. I think we need to cover the rough plan in the spec. | 14:45 |
| slaweq | thx, I will mark rfe as approved with those mentioned conditions | 14:46 |
| slaweq | and we can then review spec and then implementation as well | 14:46 |
| mlavalle | include those conditions in your approval comment | 14:46 |
| slaweq | mlavalle sure, I will | 14:46 |
| slaweq | thx yangyi01 for the proposal | 14:47 |
| slaweq | ok, that was the only rfe for today | 14:47 |
| fnordahl | Anything you need answered to triage https://bugs.launchpad.net/neutron/+bug/1932154 for next weeks meeting? | 14:47 |
| slaweq | do You have any other topics You would like to talk about? | 14:47 |
| amotoki | yangyi01: one question: you said "add your comments in current spec". did you already propose some spec? | 14:47 |
| yangyi01 | One question, how long can a approved spec take to finish? This is a big engineering effort. | 14:48 |
| yangyi01 | yes, I have submited spec. | 14:48 |
| slaweq | amotoki https://review.opendev.org/c/openstack/neutron-specs/+/796746 | 14:48 |
| slaweq | this is the spec | 14:48 |
| amotoki | thanks. I just found it :) | 14:48 |
| velizarx | could we discuss RFE from previous meeting https://bugs.launchpad.net/neutron/+bug/1931100? | 14:49 |
| yangyi01 | https://blueprints.launchpad.net/neutron/+spec/openflow-based-dvr-l3 | 14:49 |
| slaweq | fnordahl I asked ralonsoh to check Your rfe, I think he didn't check it yet | 14:49 |
| ralonsoh | slaweq, I couldn't yet | 14:49 |
| slaweq | ralonsoh np at all :) | 14:50 |
| fnordahl | slaweq, ralonsoh ok, nw, ta for answer, we'll wait in line :) | 14:50 |
| slaweq | ok, lets quickly back to velizarx's RFE https://bugs.launchpad.net/neutron/+bug/1931100 | 14:50 |
| slaweq | amotoki I see that velizarx just replied to Your comment yesterday | 14:51 |
| amotoki | I saw it. | 14:51 |
| mlavalle | This last RFE makes sense at first glance | 14:51 |
| amotoki | it clarifies what should be shared and I think we can allow network/router association only to end-users with access_as_shared. | 14:52 |
| amotoki | I am now fine with this RFE. | 14:52 |
| slaweq | thx amotoki, are there any other questions regarding that RFE? | 14:52 |
| slaweq | or can we vote on it now? | 14:52 |
| mlavalle | mhhh, I said at first glance | 14:53 |
| amotoki | slaweq: no more questions from me | 14:53 |
| slaweq | I'm +1 on that RFE too | 14:53 |
| mlavalle | if you want my vote, can we vote at the beginning of next meeting? | 14:53 |
| slaweq | mlavalle we can, of course but next week I will not be able to chair the meeting so I though about cancelling it | 14:54 |
| slaweq | in that case we will have next meeting in 2 weeks | 14:54 |
| slaweq | if You want, we can wait with this RFE | 14:54 |
| mlavalle | of course y'all can go ahead and approve without me. I just don't want to give a +1 without some thinking | 14:54 |
| velizarx | Could you give some details about glance? Where is a problem? | 14:55 |
| velizarx | I'm a bit out of context | 14:55 |
| mlavalle | glance means at first sight | 14:55 |
| velizarx | ah :) | 14:55 |
| mlavalle | I'm not talking glance the OpenStack project | 14:56 |
| mlavalle | slaweq: please feel free to approve this RFE without me. "At first glance" I don't have any concerns | 14:56 |
| mlavalle | :-) | 14:56 |
| ralonsoh | I think it sounds reasonable but as amotoki said, the spec should define the operations to be allowed | 14:57 |
| ralonsoh | so +1 from me too | 14:57 |
| velizarx | I have only one question about implementation (if this RFE will be approved ofc) for this RFE. For this RFE I should add BGPV's objects to the main neutron repository (to neutron/objects) but all other code will be in networking-bgpvpn repository. Is it problem? | 14:57 |
| slaweq | thx mlavalle and ralonsoh | 14:57 |
| slaweq | I will mark rfe as approved | 14:57 |
| ralonsoh | no, those objects will live in your repo | 14:57 |
| ralonsoh | we can talk about this later | 14:58 |
| velizarx | ok, will retrun with this question ;) thx | 14:58 |
| slaweq | thank You all for attending the meeting | 14:58 |
| amotoki | I think we can skip the spec for this RFE. | 14:58 |
| slaweq | we are almost on top of the hour now | 14:58 |
| ralonsoh | amotoki, ok then, I'll wait for the patch | 14:58 |
| slaweq | amotoki I agree with You | 14:58 |
| amotoki | the scope clarifies in the RFE. the API ref and the patch can cover it. | 14:59 |
| ralonsoh | perfect | 14:59 |
| amotoki | s/clarifies/is clarified/ | 14:59 |
| slaweq | have a great weekend and see You online :) | 14:59 |
| slaweq | #endmeeting | 14:59 |
| opendevmeet | Meeting ended Fri Jun 18 14:59:53 2021 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 14:59 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/neutron_drivers/2021/neutron_drivers.2021-06-18-14.00.html | 14:59 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/neutron_drivers/2021/neutron_drivers.2021-06-18-14.00.txt | 14:59 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/neutron_drivers/2021/neutron_drivers.2021-06-18-14.00.log.html | 14:59 |
| ralonsoh | have a nice weekend | 14:59 |
| mlavalle | o/ | 14:59 |
| amotoki | o/ | 15:00 |
| fnordahl | \o cheers | 15:00 |
| lajoskatona | o/ | 15:00 |
| velizarx | o/ | 15:00 |
| yangyi01 | bye | 15:00 |
| opendevreview | Slawek Kaplonski proposed openstack/neutron master: Use ovs constants from neutron-lib https://review.opendev.org/c/openstack/neutron/+/797120 | 15:06 |
| opendevreview | Slawek Kaplonski proposed openstack/neutron master: Remove ovs agent's common constants module https://review.opendev.org/c/openstack/neutron/+/797121 | 15:06 |
| opendevreview | Kamil Sambor proposed openstack/neutron master: Enable querier for multicast (IGMP) in OVN https://review.opendev.org/c/openstack/neutron/+/796997 | 15:11 |
| opendevreview | Gregory Thiemonge proposed openstack/neutron master: Fix devstack path in plugin.sh https://review.opendev.org/c/openstack/neutron/+/797128 | 15:30 |
| opendevreview | Lajos Katona proposed openstack/networking-bgpvpn stable/train: stable only: Fix failing jobs and make l-c non-voting https://review.opendev.org/c/openstack/networking-bgpvpn/+/796808 | 15:39 |
| sean-k-mooney | slaweq: will you have a chance to comment on https://review.opendev.org/c/openstack/devstack/+/796826 today | 16:21 |
| sean-k-mooney | ralonsoh: perhaps you could ^ | 16:21 |
| sean-k-mooney | basicaly defaulting to the old vsctl client in os-vif via devstack until we fix https://launchpad.net/bugs/1929446 | 16:22 |
| sean-k-mooney | it can wait to moday but if ye are around then it would be nice to get this on its way. | 16:25 |
| ralonsoh | sean-k-mooney, sure I'll do | 16:26 |
| opendevreview | Mamatisa Nurmatov proposed openstack/neutron master: use payloads for PORT AFTER_DELETE events https://review.opendev.org/c/openstack/neutron/+/797004 | 17:02 |
| slaweq | sean-k-mooney sorry for being late with that but I already +1'ed it | 19:05 |
| opendevreview | Merged openstack/neutron stable/train: Make phynet paramter also is optional when network_segment_range enabled https://review.opendev.org/c/openstack/neutron/+/795280 | 23:13 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!