| opendevreview | Miro Tomaska proposed openstack/neutron master: Fix intermittent failures in finding metada port in SB DB https://review.opendev.org/c/openstack/neutron/+/878549 | 04:33 |
|---|---|---|
| opendevreview | Merged openstack/neutron master: Do not check the context object in ``TestMeteringPlugin`` https://review.opendev.org/c/openstack/neutron/+/880338 | 06:00 |
| slaweq | hi lajoskatona, ykarel and ralonsoh, please review https://review.opendev.org/q/topic:issue/OSP-20968+status:open when You will have few minutes. I really want to get those patches merged and propose new tag for neutron-tempest-plugin then. I need it for our d/s testing too :) | 06:34 |
| slaweq | thx in advance | 06:34 |
| opendevreview | Merged openstack/neutron-fwaas master: Use neutron-lib policy rules https://review.opendev.org/c/openstack/neutron-fwaas/+/876946 | 06:37 |
| lajoskatona | slaweq: +1 | 06:51 |
| slaweq | Thx | 06:51 |
| opendevreview | Lajos Katona proposed openstack/networking-odl master: CI: Add periodic weekly job with sqlalchemy main https://review.opendev.org/c/openstack/networking-odl/+/872416 | 06:52 |
| opendevreview | Merged openstack/neutron-dynamic-routing master: [sqlalchemy-20] Add reader context to ``get_bgp_peers`` https://review.opendev.org/c/openstack/neutron-dynamic-routing/+/880299 | 07:04 |
| ykarel | slaweq, ack | 07:20 |
| opendevreview | Slawek Kaplonski proposed openstack/neutron master: WIP [S-RBAC] Switch to new policies by default https://review.opendev.org/c/openstack/neutron/+/879827 | 07:52 |
| opendevreview | Slawek Kaplonski proposed openstack/neutron master: WIP [S-RBAC] Switch to new policies by default https://review.opendev.org/c/openstack/neutron/+/879827 | 08:30 |
| opendevreview | Slawek Kaplonski proposed openstack/neutron master: [S-RBAC] Get availability zone API available for READER role https://review.opendev.org/c/openstack/neutron/+/880461 | 08:40 |
| opendevreview | Slawek Kaplonski proposed openstack/neutron master: [S-RBAC] Get availability zone API available for READER role https://review.opendev.org/c/openstack/neutron/+/880461 | 08:40 |
| slaweq | ralonsoh ^^ yet another small fix for bug found when I switched to new policies by default :) | 08:43 |
| slaweq | please review when You will have time | 08:43 |
| opendevreview | Sahid Orentino Ferdjaoui proposed openstack/neutron master: dhcp: fix network.segments condition when no segments https://review.opendev.org/c/openstack/neutron/+/880131 | 08:53 |
| opendevreview | Sahid Orentino Ferdjaoui proposed openstack/neutron master: dhcp: fix network.segments condition when no segments https://review.opendev.org/c/openstack/neutron/+/880131 | 08:55 |
| opendevreview | Bence Romsics proposed openstack/neutron master: port-hints: api extension https://review.opendev.org/c/openstack/neutron/+/870081 | 09:40 |
| opendevreview | Bence Romsics proposed openstack/neutron master: port-hint-ovs-tx-steering: agent side https://review.opendev.org/c/openstack/neutron/+/872905 | 09:41 |
| opendevreview | Bence Romsics proposed openstack/neutron master: port-hint-ovs-tx-steering: shim extension https://review.opendev.org/c/openstack/neutron/+/873113 | 09:41 |
| opendevreview | Bence Romsics proposed openstack/neutron master: DNM debug logs and dev helper scripts https://review.opendev.org/c/openstack/neutron/+/872906 | 09:42 |
| ralonsoh | slaweq, do we need to backport https://review.opendev.org/c/openstack/neutron/+/879891? I think so, up to Z | 10:05 |
| ralonsoh | right? | 10:05 |
| slaweq | yes | 10:05 |
| slaweq | and https://review.opendev.org/c/openstack/neutron/+/880461/ too | 10:05 |
| ralonsoh | cool, I'll approve the first one now | 10:06 |
| ralonsoh | slaweq, https://review.opendev.org/c/openstack/neutron/+/880461 | 10:06 |
| ralonsoh | can you write Closes-Bug? | 10:06 |
| slaweq | thx | 10:06 |
| ralonsoh | just to create the link in the commit message | 10:06 |
| opendevreview | Slawek Kaplonski proposed openstack/neutron master: [S-RBAC] Get availability zone API available for READER role https://review.opendev.org/c/openstack/neutron/+/880461 | 10:06 |
| ralonsoh | +1 | 10:06 |
| slaweq | done | 10:06 |
| slaweq | thx | 10:08 |
| ralonsoh | slaweq, trivial stuff but needed for your n-lib patch related to the context elevated | 10:13 |
| ralonsoh | https://review.opendev.org/q/I5d7eb73606428841caa24ce1e38d1bebd5db0a9b | 10:13 |
| ralonsoh | before creating new releases for stable branches | 10:14 |
| slaweq | thx | 10:14 |
| slaweq | I +2 both backports | 10:14 |
| slaweq | but lajoskatona or bcafarel needs to take a look also | 10:14 |
| lajoskatona | slaweq, ralonsoh: checking | 10:47 |
| opendevreview | yatin proposed openstack/neutron master: [DNM] debug ovn skip level https://review.opendev.org/c/openstack/neutron/+/878761 | 11:13 |
| opendevreview | Slawek Kaplonski proposed openstack/neutron master: WIP [S-RBAC] Switch to new policies by default https://review.opendev.org/c/openstack/neutron/+/879827 | 11:23 |
| opendevreview | Slawek Kaplonski proposed openstack/neutron master: WIP [S-RBAC] Switch to new policies by default https://review.opendev.org/c/openstack/neutron/+/879827 | 11:23 |
| opendevreview | Merged openstack/neutron master: [S-RBAC] Allow network owners to get ports from that network https://review.opendev.org/c/openstack/neutron/+/879891 | 12:02 |
| opendevreview | Merged openstack/neutron stable/2023.1: Do not check the context object in ``TestMeteringPlugin`` https://review.opendev.org/c/openstack/neutron/+/880340 | 12:02 |
| opendevreview | Merged openstack/neutron stable/zed: Do not check the context object in ``TestMeteringPlugin`` https://review.opendev.org/c/openstack/neutron/+/880341 | 12:02 |
| opendevreview | Arnau Verdaguer proposed openstack/neutron master: [Trunk] Copy trunk's live-migration info to subports https://review.opendev.org/c/openstack/neutron/+/880483 | 12:08 |
| *** obondarev_ is now known as obondarev | 13:18 | |
| opendevreview | Rodolfo Alonso proposed openstack/ovsdbapp master: Add Interface paramteres to ``OvsdbIdl.add_port`` method. https://review.opendev.org/c/openstack/ovsdbapp/+/873566 | 13:49 |
| ralonsoh | slaweq, https://review.opendev.org/c/openstack/neutron/+/880461 | 13:50 |
| ralonsoh | trivial pep8 error | 13:50 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: [S-RBAC] Get availability zone API available for READER role https://review.opendev.org/c/openstack/neutron/+/880461 | 13:51 |
| opendevreview | Slawek Kaplonski proposed openstack/neutron master: [S-RBAC] Get availability zone API available for READER role https://review.opendev.org/c/openstack/neutron/+/880461 | 13:52 |
| opendevreview | Slawek Kaplonski proposed openstack/neutron master: WIP [S-RBAC] Switch to new policies by default https://review.opendev.org/c/openstack/neutron/+/879827 | 13:53 |
| slaweq | ralonsoh fixed, thx | 13:53 |
| opendevreview | Arnau Verdaguer proposed openstack/neutron master: [Trunk] Copy trunk's live-migration info to subports https://review.opendev.org/c/openstack/neutron/+/880483 | 13:53 |
| ralonsoh | ping ykarel, mlavalle, mtomaska, slawek, obondarev, sahid, tobias-urdin, lajoskatona, amotoki | 14:00 |
| mlavalle | o/ | 14:00 |
| slaweq | o/ | 14:00 |
| ralonsoh | #startmeeting neutron_drivers | 14:00 |
| opendevmeet | Meeting started Fri Apr 14 14:00:39 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:00 |
| obondarev | o/ | 14:00 |
| dvo-plv | hello | 14:01 |
| ralonsoh | the agenda: https://wiki.openstack.org/wiki/Meetings/NeutronDrivers | 14:01 |
| ralonsoh | ok, let's start because the agenda is packed today | 14:01 |
| ralonsoh | first topic | 14:02 |
| ralonsoh | #link https://bugs.launchpad.net/neutron/+bug/2012332 | 14:02 |
| ralonsoh | from liu | 14:02 |
| ralonsoh | but I don't think he is here | 14:02 |
| rubasov | o/ | 14:02 |
| ralonsoh | do you want to discuss it? | 14:02 |
| ralonsoh | or do you want me to ping the author to be present? | 14:03 |
| lajoskatona | we can I suppose | 14:03 |
| ralonsoh | ok then | 14:03 |
| mlavalle | ralonsoh: can I make a suggestion? | 14:03 |
| ralonsoh | sure | 14:03 |
| lajoskatona | The idea looks ok, and as amotoki commented a similar aproach what we have for routes can be used for allowed-addresses also | 14:04 |
| mlavalle | dvo-plv is here. why don't we discuss his RFE? | 14:04 |
| lajoskatona | +1 | 14:04 |
| ralonsoh | mlavalle, we have already started with this one | 14:04 |
| slaweq | I think that https://bugs.launchpad.net/neutron/+bug/2012332 is reasonable request and I'm +1 on this | 14:05 |
| ralonsoh | my question about this new API is that, eventually, you need to update the port | 14:05 |
| ralonsoh | so you'll take the same time | 14:05 |
| slaweq | I don't really think there is much to discuss there, amotoki basically summarized it in his comment perfectly | 14:05 |
| ralonsoh | yes and we are providing the same API for routes | 14:06 |
| obondarev | I also think it more about user experience than performance | 14:06 |
| ralonsoh | but that will improve the server time? | 14:06 |
| slaweq | time maybe yes but it will be atomic API (similar to what we have for extra routes) so | 14:06 |
| ralonsoh | obondarev, exactly | 14:06 |
| slaweq | ++ | 14:06 |
| lajoskatona | +1 | 14:06 |
| mlavalle | I'm ok with this RFE | 14:06 |
| ralonsoh | perfect, I think there is agreement | 14:07 |
| ralonsoh | one qq: do we need spec? | 14:07 |
| mlavalle | amotoki summarized well the point | 14:07 |
| ralonsoh | (IMO I don't think so) | 14:07 |
| mlavalle | I don't think so either? | 14:07 |
| slaweq | no spec needed IMO | 14:07 |
| mlavalle | +1 | 14:07 |
| obondarev | yeah, looks it just about adding new API extension, not much to rework | 14:07 |
| ralonsoh | perfect, I'll update the bug after this meeting | 14:08 |
| ralonsoh | thanks folks | 14:08 |
| ralonsoh | ok, lajoskatona, if you don't mind, I'll jump to the last one | 14:08 |
| ralonsoh | next topic | 14:09 |
| ralonsoh | #link https://bugs.launchpad.net/neutron/+bug/2013540 | 14:09 |
| ralonsoh | [RFE] Add support for Napatech LinkVirt SmartNICs | 14:09 |
| lajoskatona | to the ERSPAN RFE(https://bugs.launchpad.net/neutron/+bug/2015471 )? | 14:09 |
| lajoskatona | ok, so no | 14:09 |
| ralonsoh | dvo-plv, please, go on | 14:09 |
| dvo-plv | Hello, we are here | 14:09 |
| lajoskatona | but sure, this one hangs since long time in nova-specs | 14:09 |
| dvo-plv | we would like to add support for our nix to the openstack | 14:10 |
| dvo-plv | we need to add support for dpdk vf representor port | 14:11 |
| dvo-plv | base approach we disccused with Sean some time ago | 14:11 |
| dvo-plv | in the first itteration we suggested to us separate os-vif plugin like Agilio | 14:12 |
| dvo-plv | But during the disscussion with Sean he would like to extend default openvswitch driver with virtio-forwarder nic type | 14:13 |
| dvo-plv | we provide poc code | 14:13 |
| dvo-plv | from our specific we have next socket name stdvio + vf number | 14:13 |
| lajoskatona | by POC you mean this series: https://review.opendev.org/q/topic:Napatech_SmartNIC_support ? | 14:15 |
| dvo-plv | exactly | 14:15 |
| ralonsoh | so basically you are re-using the VIFPortProfileOVSRepresentor | 14:15 |
| ralonsoh | when a port is created | 14:16 |
| dvo-plv | yes | 14:16 |
| ralonsoh | but what is different from OVS with HW offload? | 14:16 |
| dvo-plv | we need to set dpdk port type to the ovs port | 14:17 |
| dvo-plv | and past socket to the qemu layer | 14:17 |
| dvo-plv | pass* | 14:17 |
| dvo-plv | with custom name stdvio + vf number | 14:17 |
| dvo-plv | https://review.opendev.org/c/openstack/neutron/+/869510/3/neutron/plugins/ml2/drivers/openvswitch/mech_driver/mech_openvswitch.py#217 | 14:18 |
| dvo-plv | we form socket here | 14:18 |
| ralonsoh | why this is not done in os-vif? | 14:18 |
| ralonsoh | (we had this conversation some years ago when agilio implemented this code in ovs agent) | 14:19 |
| dvo-plv | because we need to fill details for nova to create qemu command with socekt path | 14:19 |
| dvo-plv | we are open for code changes according to your better vision | 14:20 |
| sahid | i guess dvo-plv is just following the current implementation | 14:20 |
| ralonsoh | ok, we can discuss this in the patches | 14:21 |
| dvo-plv | yes, we tried to make less changes according to the Sean's vision | 14:21 |
| obondarev | so you need to create neutron port with specific parameters first, and then pass it to nova? | 14:21 |
| dvo-plv | We need to form socket name and pass this socket to the nova to form qemu command, also we need to form vf number for ovs command | 14:22 |
| dvo-plv | ovs-vsctl add-port br-int representor6 -- set Interface representor6 type=dpdk "options:dpdk-devargs=0000:65:00.0,representor=[6] | 14:22 |
| dvo-plv | this is ovs command which we need for out port | 14:22 |
| obondarev | ah, I see | 14:23 |
| dvo-plv | representor=[6] this vf numver forms with next formual | 14:23 |
| dvo-plv | vf_num = int(slot) * 8 + int(func) | 14:23 |
| ralonsoh | yes but this is provided by Nova, not in the Neutron port definition | 14:23 |
| ralonsoh | the PCI address and the VF is retrieved from Nova and the VF | 14:23 |
| ralonsoh | what do you need to create a Neutron port? this is related to another question: type=dpdk, this is a new datapath in OVS? | 14:24 |
| dvo-plv | I believe no, this datapath is supporter by vanilla ovs | 14:24 |
| dvo-plv | yes, we get pci in the nova, but neutron form details dict here | 14:25 |
| dvo-plv | https://review.opendev.org/c/openstack/neutron/+/869510/3/neutron/plugins/ml2/drivers/openvswitch/mech_driver/mech_openvswitch.py#193 | 14:25 |
| dvo-plv | so we follow the existing approach | 14:26 |
| ralonsoh | so you need to set the vnic type and populate the port profile | 14:26 |
| ralonsoh | I'm askign that because this is not in the nova spec | 14:26 |
| ralonsoh | and I would like to have this somewhere | 14:27 |
| dvo-plv | yes, we need to fill port profile with dpdk port type and socket name | 14:27 |
| ralonsoh | if we agreed not to request a spec for this feature, at least we'll need some kind of documentation | 14:28 |
| dvo-plv | okay, How we need to screen this information. does it should be done formwhere in the RFE? | 14:28 |
| ralonsoh | ^^ folks? | 14:28 |
| lajoskatona | good question | 14:28 |
| ralonsoh | that could also be written in the docs, in https://review.opendev.org/c/openstack/neutron/+/869510 | 14:28 |
| lajoskatona | do we have now such details in contrib docs? | 14:28 |
| ralonsoh | nothing | 14:29 |
| lajoskatona | but anyway we can find a place for such docs, so I think we can go with it, and find a place where we can document it | 14:29 |
| mlavalle | on the Nova side, sean-k-mooney has indicated that he is ready to approve the spec pending we support this RFE | 14:29 |
| lajoskatona | yes he left a +1 already on it | 14:30 |
| mlavalle | so I think it is ok not to request yet another spec, and add our condiferations to the existing one | 14:30 |
| sahid | +1 | 14:30 |
| sean-k-mooney | this is the dpdk hardware offload topic. if so then yes. im not sure there is enough detailin the spec for other but readign the code the general approhc look ok | 14:31 |
| mlavalle | and require good documentation on the Neutron side | 14:31 |
| mlavalle | yep, we have code to look at | 14:31 |
| ralonsoh | it will be needed some kind of description both in the RFE and the docs (the last one is important) | 14:31 |
| sean-k-mooney | mlavalle: if there are any detail form the neutron side that you think shoudl be added to the exsitng nova spec we could add them to capture that agrement | 14:32 |
| mlavalle | sean-k-mooney: yeah, that was my point. lt's use the same spec | 14:32 |
| sean-k-mooney | ack | 14:32 |
| obondarev | +1 | 14:32 |
| mlavalle | you expect us to review it anyways | 14:32 |
| lajoskatona | +1 | 14:32 |
| sean-k-mooney | in which case ya i was about to say i would like to see +1s form the neutron core team before we merge it | 14:33 |
| mlavalle | yeap, I got that message :-) | 14:33 |
| ralonsoh | ok, I'll add this spec to the list to be tracked weekly | 14:33 |
| mlavalle | loud and clear | 14:33 |
| sean-k-mooney | :) | 14:33 |
| ralonsoh | so please, Neutrinos, check and review this spec | 14:33 |
| lajoskatona | ack | 14:33 |
| mlavalle | it's here: https://review.opendev.org/c/openstack/nova-specs/+/859290 | 14:34 |
| slaweq | ack | 14:34 |
| sean-k-mooney | one thing i was wondering about is do wew want to detail what tests shoudl eb run in the third party ci in the spec or not | 14:34 |
| ralonsoh | we discussed that in the PTG | 14:34 |
| ralonsoh | first is to implement the CI | 14:34 |
| ralonsoh | it doesn't matter if we run basic tests | 14:34 |
| ralonsoh | but at least it should run in real HW | 14:34 |
| dvo-plv | we are open to provide third-party ci/cd | 14:35 |
| dvo-plv | But we would like what type of the teset we need to execute | 14:35 |
| opendevreview | Slawek Kaplonski proposed openstack/neutron master: WIP [S-RBAC] Switch to new policies by default https://review.opendev.org/c/openstack/neutron/+/879827 | 14:35 |
| sean-k-mooney | the netwroking basic ops senario tests and test cover span, attach/detach and move operations | 14:36 |
| ralonsoh | I'll reply to this in the spec, but is expected to run basic tempest/neutron-tempest-plugin tests | 14:36 |
| dvo-plv | Also we need to know to understand setup configuration for those tesets | 14:36 |
| dvo-plv | okay | 14:36 |
| mlavalle | in that case, let's formalize it in the spec, as suggested by sean-k-mooney. it will serve to document the approach and provide guidance to dvo-plv and his team | 14:36 |
| dvo-plv | great, thank you | 14:36 |
| ralonsoh | just as a formality, is the RFE approved? | 14:37 |
| ralonsoh | +1 from me | 14:37 |
| mlavalle | +1 | 14:37 |
| lajoskatona | +1 | 14:37 |
| obondarev | +1 | 14:37 |
| slaweq | +1 | 14:37 |
| ralonsoh | thanks folks, I'll comment that in the bug after the meeting | 14:37 |
| dvo-plv | so, what is the conclustion, Does community need something from our side | 14:37 |
| mlavalle | dvo-plv: let's contnue the conversation in the spec and the rest of the patches | 14:38 |
| ralonsoh | the conclusion is that 1) Neutron accepts this RFE | 14:38 |
| dvo-plv | okay, thank you | 14:38 |
| ralonsoh | 2) we agreed on reviewing a common spec | 14:38 |
| ralonsoh | and 3) we are expecting some kind of CI to test the code | 14:38 |
| mlavalle | good summary | 14:38 |
| mlavalle | 3 points, like very good summary | 14:39 |
| mlavalle | every^^^ | 14:39 |
| dvo-plv | We think that we will be ready to provide ci in 1-1.5 month from today | 14:39 |
| ralonsoh | that will be perfect, we can review and accept the code meanwhile (I guess) | 14:39 |
| ralonsoh | if that doesn't break any existing functionality | 14:40 |
| dvo-plv | Should we join to some additional meeting ? | 14:40 |
| dvo-plv | for code or doc or ci review ? | 14:40 |
| ralonsoh | dvo-plv, not really (but you can attend to any Neutron or Nova meeting) | 14:40 |
| mlavalle | you are always welcome to the neutron meeting on tuesday 14)) utc | 14:40 |
| mlavalle | but not a requirement | 14:40 |
| mlavalle | gerrit is our medium of communication | 14:41 |
| ralonsoh | ok, let's move | 14:41 |
| ralonsoh | the agenda is packed today | 14:41 |
| ralonsoh | next topic | 14:41 |
| dvo-plv | thank you, have a good day | 14:41 |
| ralonsoh | #link https://bugs.launchpad.net/neutron/+bug/2015471 | 14:41 |
| ralonsoh | [RFE] Add ERSPAN for tap-as-a-service with OVS and OVN | 14:41 |
| ralonsoh | lajoskatona, please | 14:41 |
| lajoskatona | thanks | 14:41 |
| lajoskatona | So tap-as-a-service currently can mirror OVS or SRIOV ports' traffic to another Neutron port | 14:42 |
| lajoskatona | but there is the ERSPAN which is basically also mirroring but mirroring in a tunnel (a GRE variant) | 14:42 |
| lajoskatona | and both OVS and OVN support ERSPAN, so the idea is to add this kind of mirroring to taas | 14:43 |
| opendevreview | yatin proposed openstack/neutron master: [DNM] Validate ovn grenade fix https://review.opendev.org/c/openstack/neutron/+/878761 | 14:43 |
| lajoskatona | I tried to summarize this in the RFE, so there are questions how this can be used with current API and similar things | 14:44 |
| ralonsoh | so, add an extra driver for OVS and create a new one for OVN | 14:44 |
| lajoskatona | and for OVN a new driver is necessary for sure as that is not there in taas currently | 14:44 |
| ralonsoh | is that correct? | 14:44 |
| lajoskatona | for OVS it is just the extension of the current driver | 14:45 |
| ralonsoh | ah ok ok | 14:45 |
| ralonsoh | just out of curiosity (if that doesnt' take too much time) | 14:45 |
| ralonsoh | what changes in OVS implementation? | 14:45 |
| ralonsoh | (related to the ERSPAN and current model in the RFE) | 14:46 |
| lajoskatona | with OVS you can create a port which is the source port on the bridge (br-int) for the mirror like ovs-vsctl add-port br-int -- ....... | 14:46 |
| lajoskatona | currently the driver creates frlows and there's an extra bridge br-tap with more flows, and that filters and directs the traffic to be mirrored to the destination port | 14:47 |
| lajoskatona | but with this ERSPAN OVS creates the tunnel from the erspan port on br-int and the admin is responsible to be something on the other end of the tunnel (it can be for example a floatin-ip also, but usually something outside the cloud | 14:48 |
| lajoskatona | just if you are courious I tried to doc how the current mirrring works with OVS: https://review.opendev.org/c/openstack/tap-as-a-service/+/828382 | 14:49 |
| mlavalle | in the rfe you state that "With ERSPAN this model is not that useful:" in regards to the N:1 relationship between tap-flows and tap-services. can you elaborate a bit? Why is it not that useful? | 14:49 |
| mlavalle | and thanks for the doc. Yes, I've always felt taas was light on docs | 14:50 |
| lajoskatona | with OVS/OVN ERSPAN there will be one new port for every source | 14:51 |
| mlavalle | because that is the way it is defined? | 14:52 |
| slaweq | is the intention here to replace "legacy" mirroring with this new solution or just add new possibility and keep both maintained? | 14:52 |
| lajoskatona | yes both the OVS and OVN implementation do that | 14:53 |
| rubasov | lajoskatona will correct me if I misunderstood, but with erspan the mirror destination would be an arbitrary IP:port and not a neutron port | 14:53 |
| ralonsoh | ^^ same question | 14:53 |
| mlavalle | I think we will keep the legacy and add a new additional way to do it | 14:53 |
| lajoskatona | It's an extension of the old/legacy | 14:53 |
| lajoskatona | rubasov: yes exactly | 14:53 |
| mlavalle | rubasov: ahhh, that is a good clarification. thanks | 14:54 |
| lajoskatona | as I said the destination for erspan would be out of the cloud | 14:54 |
| mlavalle | yeap, now I get it | 14:54 |
| rubasov | and the current tap flow + tap service can refer to neutron ports only (both source and destination) | 14:54 |
| lajoskatona | yes that is an important difference, thanks | 14:54 |
| mlavalle | that clarification is important because provides the rationale as to how to model this in the API | 14:55 |
| mlavalle | now I lean towards "to introduce a new API for ERSPAN to make as simple as possible" | 14:56 |
| ralonsoh | ok, I see the difference now but the implementation (including the alternatives proposed), API changes and mech driver prticulars, demand a spec | 14:56 |
| lajoskatona | ack | 14:56 |
| ralonsoh | in any case, I'm in favor of this improvement (both for OVS and OVN) | 14:57 |
| obondarev | +1 for this rfe and a spec | 14:57 |
| mlavalle | yeap | 14:57 |
| ralonsoh | +1 | 14:57 |
| mlavalle | good proposal | 14:57 |
| mlavalle | +1 | 14:57 |
| slaweq | +1 | 14:57 |
| lajoskatona | Thanks for the discussion | 14:58 |
| ralonsoh | perfect then, I'll update the launchpad bug | 14:58 |
| lajoskatona | thanks ralonsoh | 14:58 |
| ralonsoh | there is one more but let's keep it for the next week | 14:58 |
| ralonsoh | we had enough for today and this week | 14:58 |
| mlavalle | we made good progress this week | 14:58 |
| ralonsoh | so let's close for today and have a nice weekend! | 14:58 |
| mlavalle | more than I expected | 14:58 |
| mlavalle | o/ | 14:59 |
| rubasov | o/ | 14:59 |
| ralonsoh | #endmeeting | 14:59 |
| opendevmeet | Meeting ended Fri Apr 14 14:59:07 2023 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/2023/neutron_drivers.2023-04-14-14.00.html | 14:59 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/neutron_drivers/2023/neutron_drivers.2023-04-14-14.00.txt | 14:59 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/neutron_drivers/2023/neutron_drivers.2023-04-14-14.00.log.html | 14:59 |
| lajoskatona | have a nice weekend, bye | 14:59 |
| ralonsoh | see you folks | 14:59 |
| obondarev | o/ | 14:59 |
| slaweq | o/ | 14:59 |
| opendevreview | Slawek Kaplonski proposed openstack/neutron master: WIP [S-RBAC] Switch to new policies by default https://review.opendev.org/c/openstack/neutron/+/879827 | 15:08 |
| opendevreview | yatin proposed openstack/neutron master: [DNM] Check custom playbook https://review.opendev.org/c/openstack/neutron/+/880269 | 15:29 |
| opendevreview | Merged openstack/neutron master: [sqlalchemy-20] Add reader context to ``get_ports_on_host_by_subnet`` https://review.opendev.org/c/openstack/neutron/+/880298 | 15:35 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron stable/2023.1: [sqlalchemy-20] Add reader context to ``get_ports_on_host_by_subnet`` https://review.opendev.org/c/openstack/neutron/+/880496 | 15:38 |
| opendevreview | yatin proposed openstack/neutron master: Run periodic jobs in experimental queue too https://review.opendev.org/c/openstack/neutron/+/880539 | 16:02 |
| opendevreview | Merged openstack/ovsdbapp master: Add Interface paramteres to ``OvsdbIdl.add_port`` method. https://review.opendev.org/c/openstack/ovsdbapp/+/873566 | 16:50 |
| *** EugenMayer41 is now known as EugenMayer4 | 19:17 | |
| *** EugenMayer48 is now known as EugenMayer4 | 19:32 | |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!