| opendevreview | ZhouHeng proposed openstack/neutron master: [ovn]l3 plugin support floating ip distributed attribues https://review.opendev.org/c/openstack/neutron/+/856955 | 02:08 |
|---|---|---|
| opendevreview | ZhouHeng proposed openstack/neutron-lib master: Add FirewallGroupPortNotSupported exception https://review.opendev.org/c/openstack/neutron-lib/+/884599 | 02:25 |
| opendevreview | ZhouHeng proposed openstack/neutron master: [ovn]l3 plugin support floating ip distributed attribues https://review.opendev.org/c/openstack/neutron/+/856955 | 06:52 |
| opendevreview | ZhouHeng proposed openstack/neutron master: [ovn]l3 plugin support floating ip distributed attribues https://review.opendev.org/c/openstack/neutron/+/856955 | 07:32 |
| opendevreview | Rodolfo Alonso proposed openstack/networking-odl stable/zed: Remove periodic-stable-jobs template https://review.opendev.org/c/openstack/networking-odl/+/884189 | 07:44 |
| opendevreview | Merged openstack/networking-odl stable/zed: Update the CI requirements and remove grenade/tempest jobs https://review.opendev.org/c/openstack/networking-odl/+/885062 | 08:52 |
| opendevreview | Elod Illes proposed openstack/networking-odl stable/xena: Remove periodic-stable-jobs template https://review.opendev.org/c/openstack/networking-odl/+/884191 | 08:53 |
| opendevreview | Slawek Kaplonski proposed openstack/neutron-tempest-plugin master: Don't check exit status when nc_client is spawned https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/885108 | 08:57 |
| opendevreview | Merged openstack/ovn-octavia-provider stable/2023.1: Apply admin_state_up on a new member creation https://review.opendev.org/c/openstack/ovn-octavia-provider/+/884480 | 08:58 |
| opendevreview | Merged openstack/ovn-octavia-provider stable/zed: Apply admin_state_up on a new member creation https://review.opendev.org/c/openstack/ovn-octavia-provider/+/884481 | 08:58 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron-specs master: Port extension to create hardware offloaded ports https://review.opendev.org/c/openstack/neutron-specs/+/882272 | 09:06 |
| opendevreview | Merged openstack/neutron-lib stable/2023.1: Add a "GROUP BY" clause on queries with RBAC entries https://review.opendev.org/c/openstack/neutron-lib/+/885080 | 09:06 |
| opendevreview | Merged openstack/networking-odl stable/zed: Remove periodic-stable-jobs template https://review.opendev.org/c/openstack/networking-odl/+/884189 | 09:25 |
| opendevreview | Merged openstack/networking-odl stable/xena: Remove periodic-stable-jobs template https://review.opendev.org/c/openstack/networking-odl/+/884191 | 09:38 |
| opendevreview | liuxie proposed openstack/neutron master: [OVN] Support address group for ovn driver https://review.opendev.org/c/openstack/neutron/+/851509 | 09:47 |
| opendevreview | huanghailun proposed openstack/neutron master: Add allowed_address_pairs add/remove atomic operations https://review.opendev.org/c/openstack/neutron/+/880922 | 09:52 |
| opendevreview | Merged openstack/ovn-octavia-provider stable/xena: Apply admin_state_up on a new member creation https://review.opendev.org/c/openstack/ovn-octavia-provider/+/884483 | 09:53 |
| opendevreview | Merged openstack/ovn-octavia-provider stable/wallaby: Apply admin_state_up on a new member creation https://review.opendev.org/c/openstack/ovn-octavia-provider/+/884484 | 09:53 |
| opendevreview | Merged openstack/ovn-octavia-provider stable/2023.1: Discard batch-update-members not valid request https://review.opendev.org/c/openstack/ovn-octavia-provider/+/884696 | 09:53 |
| opendevreview | Merged openstack/ovn-octavia-provider stable/zed: Discard batch-update-members not valid request https://review.opendev.org/c/openstack/ovn-octavia-provider/+/884697 | 09:53 |
| opendevreview | Merged openstack/ovn-octavia-provider stable/yoga: Discard batch-update-members not valid request https://review.opendev.org/c/openstack/ovn-octavia-provider/+/884698 | 09:53 |
| opendevreview | Fernando Royo proposed openstack/ovn-octavia-provider master: Allow multiple VIPs per LB https://review.opendev.org/c/openstack/ovn-octavia-provider/+/885111 | 10:15 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: WIP - Add ``OVNGatewayHAChassisGroup`` scheduler class https://review.opendev.org/c/openstack/neutron/+/872033 | 10:42 |
| ralonsoh | rubasov, hi, do you have a couple of mins for https://bugs.launchpad.net/neutron/+bug/2022321 | 10:49 |
| ralonsoh | ? | 10:49 |
| rubasov | ralonsoh: hi, sure I can look into it | 10:50 |
| ralonsoh | rubasov, we know what the problem is | 10:51 |
| ralonsoh | the issue is in the IPv4 metadata | 10:51 |
| rubasov | Brian already pushed this (which looks similar): https://review.opendev.org/c/openstack/neutron/+/883193 | 10:51 |
| ralonsoh | ok, I need to check that immediatly | 10:52 |
| ralonsoh | and thanks for the link! | 10:52 |
| ralonsoh | haleyb, ^^ do you have 5 mins? | 10:53 |
| ralonsoh | I think this is a very important issue | 10:53 |
| ralonsoh | before releasing any new version (Y, Z and 2023.1) we need to fix that | 10:53 |
| ralonsoh | your patch ^^ looks very similar (if not the same) to the proposal we had | 10:54 |
| rubasov | there's some discussion in https://bugs.launchpad.net/neutron/+bug/1953165 starting from comment #40 | 10:54 |
| opendevreview | Merged openstack/ovn-octavia-provider stable/wallaby: Discard batch-update-members not valid request https://review.opendev.org/c/openstack/ovn-octavia-provider/+/884700 | 10:57 |
| opendevreview | Maximilian Sesterhenn proposed openstack/networking-bgpvpn master: WIP: Add OVN-based Neutron BGPVPN driver https://review.opendev.org/c/openstack/networking-bgpvpn/+/883060 | 11:01 |
| opendevreview | Merged openstack/ovn-octavia-provider stable/yoga: Apply admin_state_up on a new member creation https://review.opendev.org/c/openstack/ovn-octavia-provider/+/884482 | 11:13 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron-lib master: Add new SG rule extension ``security-groups-rules-is-default`` https://review.opendev.org/c/openstack/neutron-lib/+/883939 | 11:44 |
| opendevreview | Vasyl Saienko proposed openstack/os-vif master: Don't break traffic if port already exists https://review.opendev.org/c/openstack/os-vif/+/885127 | 12:00 |
| opendevreview | Vasyl Saienko proposed openstack/os-vif master: Don't break traffic if port already exists https://review.opendev.org/c/openstack/os-vif/+/885127 | 12:01 |
| opendevreview | Merged openstack/neutron-lib stable/zed: Add a "GROUP BY" clause on queries with RBAC entries https://review.opendev.org/c/openstack/neutron-lib/+/885081 | 12:07 |
| opendevreview | Merged openstack/neutron-lib stable/wallaby: Add a "GROUP BY" clause on queries with RBAC entries https://review.opendev.org/c/openstack/neutron-lib/+/885084 | 12:13 |
| opendevreview | Merged openstack/neutron-lib stable/yoga: Add a "GROUP BY" clause on queries with RBAC entries https://review.opendev.org/c/openstack/neutron-lib/+/885082 | 12:13 |
| opendevreview | Merged openstack/neutron-lib stable/xena: Add a "GROUP BY" clause on queries with RBAC entries https://review.opendev.org/c/openstack/neutron-lib/+/885083 | 12:13 |
| ges | ralonsoh: hello! I finally had time to look at your comment on https://review.opendev.org/c/openstack/neutron/+/883235. I can write specific unit tests for _clear_child_sg_rules, but from what I see that's not the way it's been done up till now. | 12:15 |
| ges | Since it's a callback, from what I understand _clear_child_sg_rules is called by the self.rcache.record_resource_delete(self.ctx, 'SecurityGroup', s1.id) call in the test (which is different from the recourd_resource_delete of the SecurityGroupRules done by _clear_child_sg_rules) | 12:16 |
| maximkorezkij[m] | hey! can someone help me with a question regarding the ovn_idl in the neutron api and the connection to the southbound database in an ml2/ovn setup ? | 12:34 |
| opendevreview | Merged openstack/neutron master: Implement ``get_port_type_virtual_and_parents`` method https://review.opendev.org/c/openstack/neutron/+/882557 | 12:34 |
| opendevreview | Merged openstack/neutron-lib master: Introduce "HasProjectPrimaryUniqueKey" class https://review.opendev.org/c/openstack/neutron-lib/+/881804 | 12:39 |
| opendevreview | Merged openstack/neutron master: Move ``determine_bind_host`` to ``ovn.utils`` https://review.opendev.org/c/openstack/neutron/+/882562 | 12:47 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron-lib master: Add new SG rule extension ``security-groups-rules-is-default`` https://review.opendev.org/c/openstack/neutron-lib/+/883939 | 13:09 |
| 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 | 13:10 |
| ralonsoh | ges, sorry, what is the question? | 13:21 |
| opendevreview | Lajos Katona proposed openstack/neutron master: Delete sg rule which remote is the deleted sg https://review.opendev.org/c/openstack/neutron/+/884505 | 13:23 |
| ralonsoh | maximkorezkij[m], same here, what is the question? | 13:24 |
| maximkorezkij[m] | Why does the maintenance worker of the api need a leader connection to the sb ? | 13:26 |
| maximkorezkij[m] | regarding the comment from this commit 10f23398ce43a666c17feeef7c1b516ce3afddff it uses it for locking but i just found locking code for the northbound - not the southbound | 13:26 |
| ralonsoh | maximkorezkij[m], about the maintenance worker, this is because we create an OVNClient inside this thread | 13:31 |
| ralonsoh | from the OvnNbSynchronizer | 13:31 |
| ralonsoh | but the main problem with the SB database connections are from the compute nodes metadata agents, this is the real pain of the SB database | 13:31 |
| ralonsoh | in any case, you can propose a refactor to stop using the SB from this worker | 13:32 |
| ralonsoh | that will be welcome, of course | 13:33 |
| maximkorezkij[m] | yeah i know, we mainly use the relays and i was testing to use the relays instead of a direct sb connection in the api but came across some warnings in the log | 13:40 |
| maximkorezkij[m] | is something speaking against removing the leader=true condition when initializing the maintenance worker ? im not that deep into the code yet | 13:41 |
| ralonsoh | to be honest, I don know if we modify any SB register | 13:44 |
| ralonsoh | that should be tested first | 13:44 |
| maximkorezkij[m] | okey, thanks | 13:45 |
| maximkorezkij[m] | do you know how to test it in a good way ? | 13:45 |
| ges | ralonsoh: I don't really have a specific question, I am just sharing context related to my choice of implementation. | 13:48 |
| ralonsoh | maximkorezkij[m], what I would do is to 1) check where the SB IDL is called in the maintenance worker (I think only two methods) and then check what these methods are doing (I think only reading the SB) | 13:49 |
| maximkorezkij[m] | ack, thanks | 13:49 |
| ralonsoh | maximkorezkij[m], the maintenance worker will run through all methods, make sure you call these affected | 13:49 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron-lib master: Add new SG rule extension ``security-groups-rules-is-default`` https://review.opendev.org/c/openstack/neutron-lib/+/883939 | 13:51 |
| ralonsoh | Ping list: ykarel, mlavalle, mtomaska, slawek, obondarev, tobias-urdin, lajoskatona, amotoki | 14:00 |
| mlavalle | o/ | 14:00 |
| slaweq | o/ | 14:00 |
| obondarev | o/ | 14:00 |
| ralonsoh | #startmeeting neutron_drivers | 14:00 |
| opendevmeet | Meeting started Fri Jun 2 14:00:58 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 |
| lajoskatona | o/ | 14:01 |
| ralonsoh | hello all, let's give one more minute | 14:01 |
| mlavalle | we might want to ping haleyb | 14:01 |
| ralonsoh | no, he's not going to attend | 14:01 |
| mlavalle | ok | 14:01 |
| ralonsoh | he told me that yesterday | 14:01 |
| ralonsoh | ok, I think we have quorum | 14:02 |
| ralonsoh | the topic we have today is | 14:02 |
| ralonsoh | #link https://bugs.launchpad.net/neutron/+bug/2020823 | 14:02 |
| ralonsoh | [RFE] Add flavor/service provider support to routers in the L3 OVN plugin | 14:02 |
| ralonsoh | mlavalle, please | 14:02 |
| mlavalle | back in 2016 Kevin Benton implemented a framework to create routers with flavors | 14:03 |
| mlavalle | in other words, a way to implement routers with different backends | 14:03 |
| obondarev | btw, is it used now? | 14:04 |
| ralonsoh | not really, only a few external projects used it | 14:04 |
| ralonsoh | (I don't remember which ones) | 14:05 |
| obondarev | got it, thanks! | 14:05 |
| mlavalle | In fact, if we look in the repo under services/l3_router/service_providers you will find his attempt to disentangle the agent based routers in different drivers | 14:05 |
| mlavalle | He didn't get to the final goal but he laid a good foundation that is relatively easy to reuse with the ML2 / OVN mechanism driver | 14:06 |
| mlavalle | my employer has received strong signals from potential big deployers that they want to use flavored routed with ML2 / OVN | 14:06 |
| mlavalle | so I created a PoC to investigate the feasability: https://review.opendev.org/c/openstack/neutron/+/883988 | 14:07 |
| slaweq | what backends for routers in ML2/OVN we may have? | 14:07 |
| sahid | mlavalle: what is the use case (sorry for this noob question but this will help me to understand better) | 14:07 |
| mlavalle | the use case is a big telco deployer who already has their own implementation of routers that they want to use under ml2/ovn | 14:08 |
| mlavalle | vrouters that is | 14:08 |
| mlavalle | I've been testing the PoC in my dev environment and ot works fine | 14:08 |
| mlavalle | in fact, I added a README in the code where I show inital results | 14:09 |
| slaweq | ahh, so they want to create router in neutron but to have own plugin/driver/whatever to create and manage it, instead of creating it in OVN as LR, is that correct? | 14:09 |
| lajoskatona | this is the readme: https://review.opendev.org/c/openstack/neutron/+/883988/7/neutron/services/ovn_l3/service_providers/README.rst | 14:10 |
| mlavalle | yes, if you look at the PoC, I added a service_providers folder under ovn_l3 | 14:10 |
| lajoskatona | I though it quite useful to see how it will work | 14:10 |
| mlavalle | services/ovn_l3/service_providers | 14:10 |
| mlavalle | inside it, you will find ovn.py, which isolates the ovn based routers control plane | 14:11 |
| mlavalle | and also you find user_defined.py, which stands for a potential implementation of routers with a different backend | 14:11 |
| obondarev | those service providers may be not related to OVN itself, right? | 14:12 |
| sahid | that is really intersting.. so if tomorrow we build a full ebpf router we can plug it as well without the pain of creating a full sdn compatible with neutron api | 14:12 |
| mlavalle | right now, this flavor does nothing but just log a message that it has received a request to create, update or delete a router | 14:12 |
| mlavalle | obondarev: correct | 14:13 |
| mlavalle | sahid: you got it | 14:13 |
| ralonsoh | I have many questions about this. In ML2/OVS (or ML2/LB), Neutron is both the orchestrator and the CMS. With ML2/OVS, the CMS. How are we going to deal with all L3 operations? I mean FIPs, router interfaces, etc | 14:13 |
| obondarev | so my confusion is that it lays under "ovn_l3" while might me completely unrelated to OVN | 14:13 |
| mlavalle | ralonsoh: my plan is to move all the router / fip related functionality from the services/ovn_l3/service_providers/plugin.py to the ovne driver in services/ovn_l3/service_providers/ovn.py | 14:15 |
| lajoskatona | obondarev: good point | 14:15 |
| mlavalle | so the plugin just does the purely CMS part | 14:15 |
| slaweq | I know it's crazy idea but shouldn't we then try to unifiy our l3 service plugin and ovn_l3 service plugin and use different flavors for agent based routers (ML2/OVS) and OVN routers too? | 14:16 |
| ralonsoh | nonono, I would avoid this idea | 14:16 |
| ralonsoh | we have two L3 implementations, OVN and OVS/LB | 14:16 |
| ralonsoh | I wouldn't mix both | 14:17 |
| mlavalle | obondarev: you are right. As I slowly hollow out plugin.py and move the ovn related functionality to the ovn driver, it might not make sense to keep the plugin under ovn_l3 | 14:17 |
| ralonsoh | we don't have the same functionalities | 14:17 |
| obondarev | mlavalle: ack | 14:17 |
| mlavalle | for now, I am just slowly hollowing it out, to disentangle the CMS and ovn functionality | 14:17 |
| obondarev | so it sounds pretty much what Kevin's goal was, no? What's the main difference? | 14:18 |
| mlavalle | so ralonsoh is absolutely correct in that a big chunck of what needs to be done is to disentabgle the CMS part from the OVN part | 14:19 |
| mlavalle | obondarev: it is the exact same idea. Just that he attacked it from the agent based implementation, while I am coming from the OVN side, where it is proving to be much simpler | 14:20 |
| mlavalle | once we isolate the ovn part in a driver, we now can add other drivers | 14:21 |
| racosta | mlavalle, would only the routers be managed with multiple backends? what about subnets? | 14:21 |
| mlavalle | racosta: at this point I haven't uncovered anything that seggests that we might need to mess with subnets | 14:22 |
| mlavalle | but in any case, that is why I am doing it gradually and as I move functionality to the driver, I'm testing it | 14:22 |
| ralonsoh | so, in a nutshell, anything related to LR, LRP or NAT will be skipped from the OVN L3 point of view and the needed calls to the external routers will be made. Is that correct? | 14:23 |
| mlavalle | ralonsoh: those calls will be done from the ovn driver | 14:23 |
| mlavalle | and their counterparts for a different flavor, from a different driver | 14:24 |
| mlavalle | like the sample one I've included in the PoC | 14:24 |
| ralonsoh | (well, at least everything related to OVN l3 seems to be in one single file) | 14:25 |
| ralonsoh | in any case, the idea of having this driver controller looks fine, with a common API for all drivers | 14:26 |
| lajoskatona | +1 | 14:26 |
| ralonsoh | any other question? | 14:26 |
| ralonsoh | I have one: do we need a spec? I think so | 14:27 |
| lajoskatona | do we need a spec of the RFE is enough? | 14:27 |
| obondarev | in the PoC I see create/update/delete router methods moved to ovn driver, but for example "add_router_interface" is still in ovn l3 plugin. Is it going to be moved as well? | 14:27 |
| lajoskatona | yeah the same :-) | 14:27 |
| mlavalle | obondarev: yes, I'm doing this gradually, as I said above | 14:27 |
| mlavalle | I want to tackle the challenges gradually | 14:28 |
| mlavalle | the idea is to isolate all the ovn related functionality in its associated driver | 14:28 |
| obondarev | just want to realise what would be the difference between ovn l3 plugin and it's parent class in the end? | 14:28 |
| mlavalle | obondarev: in the end there will be very little, if any | 14:29 |
| obondarev | so why not just have different l3 plugin for those who needs new backend? | 14:29 |
| mlavalle | that is why I think of this process as hollowing out the ovn l3 plugin. It will be reduced purely to its CMS functionality | 14:30 |
| slaweq | IIU the reason to do it that way is that You can't have e.g. 2 different l3 service plugins enabled at the same time, and with this approach You may have "mixed" routers | 14:31 |
| mlavalle | I think we need a unified plugin that allows users to use routers of different flavors at the same time | 14:31 |
| slaweq | *IIUC | 14:31 |
| ralonsoh | right, we don't have the concept of multiple L3 plugins | 14:31 |
| obondarev | ah, right | 14:32 |
| ralonsoh | (multiple L3 plugins loaded at the same time, I meant) | 14:32 |
| mlavalle | which was ultimately Kevin's goal. He just got bogged down with all the spaghetti in the agents based implementation | 14:32 |
| obondarev | I think a spec with a diagram of L3 plugins & drivers would be nice to have | 14:33 |
| mlavalle | it so happens that his goal is simpler to achieve coming from the ml2/ovn side | 14:33 |
| mlavalle | and to Kevin's credir, as I'm uncovering with the PoC, he laid a very good foundation, even though he didn't get to his ultimate goal 6 years ago | 14:34 |
| mlavalle | credit^^^ | 14:34 |
| obondarev | so end goal is to have kind of same architecture as with ML2 plugins and drivers | 14:35 |
| obondarev | plugin* | 14:35 |
| slaweq | ML3 service plugin :) | 14:36 |
| obondarev | nice! | 14:36 |
| mlavalle | obondarev: yeah, I like the way ralonsoh put it. Neutron will do the CMS part and there will be drivers implementing different flavors for routers | 14:36 |
| mlavalle | with different backends | 14:37 |
| mlavalle | and in the way to that, let's isolate the ovn related bits | 14:37 |
| mlavalle | in a driver | 14:37 |
| ralonsoh | any other question? | 14:38 |
| lajoskatona | Not from me, with a spec I like the idea | 14:39 |
| slaweq | nothing more from me | 14:39 |
| ralonsoh | ok, let's vote then | 14:39 |
| slaweq | I think it's good idea to go with | 14:39 |
| ralonsoh | +1 with spec | 14:39 |
| slaweq | +1 | 14:39 |
| obondarev | +1 | 14:39 |
| lajoskatona | +1 | 14:40 |
| ralonsoh | perfect then, I'll update the LP bug with this result | 14:40 |
| ralonsoh | something else you want to discuss? | 14:40 |
| mlavalle | thanks for the time and consideration! | 14:40 |
| ralonsoh | thank you all for participating and thanks mlavalle for this RFE | 14:40 |
| obondarev | o/ | 14:40 |
| ralonsoh | have a nice weekend! | 14:40 |
| lajoskatona | o/ | 14:41 |
| ralonsoh | #endmeeting | 14:41 |
| opendevmeet | Meeting ended Fri Jun 2 14:41:02 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-06-02-14.00.html | 14:41 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/neutron_drivers/2023/neutron_drivers.2023-06-02-14.00.txt | 14:41 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/neutron_drivers/2023/neutron_drivers.2023-06-02-14.00.log.html | 14:41 |
| lajoskatona | The same to you all | 14:41 |
| mlavalle | and the questions were very good. They will be the foundation for the spec | 14:41 |
| * haleyb is lurking here because he was reading email and xchat was flashing | 14:41 | |
| haleyb | ralonsoh: i responded to your comments in https://review.opendev.org/c/openstack/neutron/+/883193 | 14:41 |
| ralonsoh | haleyb, let me check | 14:41 |
| mlavalle | ralonsoh, slaweq: I won't go to Vancouver. My trip was not approved. So good luck | 14:42 |
| mlavalle | with the forum session | 14:42 |
| ralonsoh | mlavalle, pfffff sorry for that | 14:42 |
| slaweq | mlavalle sorry to hear that, I was hoping to meet there | 14:43 |
| mlavalle | ralonsoh: if I submit a topic for discussion in Vancouver, will there be a way to present it remotely | 14:43 |
| mlavalle | ? | 14:43 |
| mlavalle | slaweq: yeah, me too. I was looking forward to see you and ralonsoh | 14:43 |
| ralonsoh | mlavalle, maybe you can ask that in #openstack to diablo rojo | 14:43 |
| mlavalle | ralonsoh: ok, I'll do that | 14:43 |
| mlavalle | have a nice trip | 14:43 |
| ralonsoh | but if we need to set a device (camera, mic) that won't be a problem | 14:44 |
| slaweq | mlavalle I think that fungi or Kendal was saying that the rooms will not be really prepared for such remote participation | 14:44 |
| ralonsoh | ^^ right | 14:44 |
| mlavalle | slaweq: enjoy your vacation, also | 14:44 |
| slaweq | mlavalle thx a lot | 14:44 |
| racosta | bad news mlavalle... I was hoping to meet you all in Vancouver... | 14:44 |
| ralonsoh | haleyb, BTW, ccamposr has been testing the patch and is working | 14:44 |
| ralonsoh | I'll update the patch now with these comments | 14:44 |
| haleyb | ralonsoh: ack, i had tested as had Florian who also noticed the issue | 14:45 |
| mlavalle | ralonsoh, slaweq: ok, then I will create a RFE to be discussed in a future drivers meeting | 14:45 |
| ralonsoh | mlavalle, sure | 14:45 |
| mlavalle | racosta: will find another opportunty. Looking forward to meet you | 14:45 |
| ccamposr | ralonsoh, haleyb, yes just now it is running all the neutron test cases, but it seems works properly becasue haproxy container seems be created properly | 14:46 |
| fungi | slaweq: mlavalle: yes, they're just rooms (where the forum sessions will also be held), as opposed to the general ptg space which is the keynote hall converted into a giant room full of individual tables for each team (similar to what we had for shanghai in 2019) | 14:46 |
| mlavalle | fungi: thanks for the clarification | 14:47 |
| fungi | if people want to use them for teleconferencing remote participants, they'll need to use their own computers and a/v equipment (there's none provided), but we can make some zoom teleconference bridges available | 14:47 |
| fungi | it was simply a way of acknowledging that trying to teleconference in a room being shared by 23 other teams may not work well, so being in a separate room when doing that could help some | 14:48 |
| fungi | but also it's mostly just the second half of thursday those separate rooms are available (whenever there's no forum sessions scheduled in them basically) | 14:48 |
| mlavalle | fungi: I appreciate the offer. But I don't want you or other Foundation folks to go to extra efforts for something I can discuss in a Neutron drivers meeting. Thanks any way and have a nice trip! | 14:48 |
| fungi | no worries, and sorry it's not convenient, we're just really tight on space at the venue to keep the conference within budget | 14:50 |
| haleyb | ralonsoh: thanks for approving that, i'll go back to not working, but feel free to +2 any of my other patches :) | 14:52 |
| ralonsoh | for sure | 14:52 |
| slaweq | fungi in Shanghai we (as Neutron team) were lucky as we had separate room during PTG part :) | 15:02 |
| slaweq | but I of course remember how the big room looked like | 15:03 |
| lajoskatona | slaweq, ralonsoh, fungi: so not expect hybrid way of discussion by default? This means we can sleep here, and don't have to be ready in Vancouver timezone.... | 15:16 |
| fungi | yes, trying to do remote discussions is going to be complicated at best | 15:17 |
| slaweq | @lajoskatona so you are t going to Vancouver too? | 15:17 |
| lajoskatona | fungi: thanks | 15:17 |
| lajoskatona | slaweq: yes based on last discussions with our management, we will not travel | 15:17 |
| lajoskatona | slaweq: next week when the travel to Budapest I will have a chance to discuss the travel ban with them :P | 15:18 |
| slaweq | Ouch. That's bad. Sorry to hear that | 15:19 |
| zorun | hi there | 15:20 |
| ralonsoh | lajoskatona, I'm sorry to hear that | 15:20 |
| zorun | I am going to Vancouver and will present some work we did on NGS (Networking-Generic-Switch) | 15:21 |
| ralonsoh | nice to read that, I'll join this session | 15:22 |
| zorun | I would like to discuss design ideas for NGS while being there, what would be the best format? | 15:22 |
| ralonsoh | did you apply for a presentation? | 15:22 |
| zorun | is there a in-person Neutron meeting planned? do people working on NGS typically attend these meetings? | 15:22 |
| ralonsoh | or a forum session? | 15:22 |
| zorun | it's a presentation | 15:22 |
| ralonsoh | so did you apply for this? | 15:22 |
| ralonsoh | or did you add this topic to the etherpad agenda | 15:23 |
| zorun | https://vancouver2023.openinfra.dev/a/schedule#track=421&company=inria&view=calendar | 15:23 |
| zorun | these are two different things: the presentation has been accepted, I will present our work | 15:24 |
| ralonsoh | perfect! | 15:24 |
| zorun | but then, we would like to upstream our changes, and this needs design discussions | 15:24 |
| ralonsoh | so you need first to open a launchpad bug | 15:25 |
| zorun | ok | 15:25 |
| ralonsoh | then present this RFE in the drivers meeting | 15:25 |
| zorun | oh, is NGS considered a driver? | 15:25 |
| ralonsoh | this is another repositoru, right? | 15:25 |
| zorun | yes, definitely | 15:25 |
| ralonsoh | yes, networking-xxx | 15:25 |
| ralonsoh | but we already have this project | 15:26 |
| ralonsoh | https://docs.openstack.org/networking-generic-switch/latest/ | 15:26 |
| ralonsoh | zorun, you should talk to the project leaders | 15:27 |
| ralonsoh | this is not under the Neutron umbrella | 15:27 |
| zorun | oh, ok, I thought it indirectly was | 15:28 |
| ralonsoh | no, the Neutron core group is not related to this project | 15:29 |
| ralonsoh | https://review.opendev.org/admin/groups/eaf58f67a6c1ac4246bec3197d3fbd5ea42e9b5b,members | 15:29 |
| ralonsoh | this is related to Ironic | 15:29 |
| zorun | right, NGS sits between Neutron and Ironic, since it's a ML2 plugin | 15:31 |
| zorun | thanks for the pointer | 15:31 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: [OVN] Prevent binding a virtual type port https://review.opendev.org/c/openstack/neutron/+/882588 | 15:48 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: WIP == [OVN] Prevent Trunk creation/deletion with parent port bound https://review.opendev.org/c/openstack/neutron/+/885154 | 16:54 |
| ralonsoh | mtomaska1, ^^ testing, reno and documentation is missing, but this is basically the code | 16:55 |
| mtomaska1 | ralonsoh ACK | 16:55 |
| ralonsoh | @all, have a nice weekend | 16:55 |
| *** ralonsoh is now known as ralonsoh_afk | 16:56 | |
| mtomaska1 | you too! | 16:56 |
| opendevreview | Merged openstack/neutron master: Fix 'consider-using-with' warning https://review.opendev.org/c/openstack/neutron/+/884947 | 17:17 |
| opendevreview | Merged openstack/neutron-fwaas master: [alembic] Alembic operations require keywords only arguments https://review.opendev.org/c/openstack/neutron-fwaas/+/883342 | 18:49 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!