| opendevreview | Ihar Hrachyshka proposed openstack/neutron master: tests: Remove skip_if_ovs_older_than decorator from a test case https://review.opendev.org/c/openstack/neutron/+/935250 | 02:12 |
|---|---|---|
| opendevreview | Ihar Hrachyshka proposed openstack/neutron master: functional: Don't assume privsep-helper is installed in virtualenv https://review.opendev.org/c/openstack/neutron/+/935251 | 02:22 |
| opendevreview | Ihar Hrachyshka proposed openstack/neutron master: functional: Allow to override OS_FAIL_ON_MISSING_DEPS https://review.opendev.org/c/openstack/neutron/+/935252 | 02:40 |
| opendevreview | OpenStack Proposal Bot proposed openstack/neutron master: Imported Translations from Zanata https://review.opendev.org/c/openstack/neutron/+/935254 | 03:44 |
| opendevreview | Liushy proposed openstack/neutron-fwaas master: [OVN] Fix the provider error in devstack settings https://review.opendev.org/c/openstack/neutron-fwaas/+/934103 | 03:55 |
| opendevreview | Liushy proposed openstack/neutron-fwaas master: Fix the tests import error https://review.opendev.org/c/openstack/neutron-fwaas/+/934591 | 07:03 |
| ralonsoh | slaweq, lajoskatona haleyb hello! Please check https://review.opendev.org/c/openstack/releases/+/935265. That should fix the issue with the tempest ovn job, when the docker image is created in the FFR tests using the os-ken testing FW | 07:48 |
| lajoskatona | thanks ralonsoh | 07:57 |
| opendevreview | Merged openstack/neutron-fwaas unmaintained/2023.1: Update .gitreview for unmaintained/2023.1 https://review.opendev.org/c/openstack/neutron-fwaas/+/935094 | 08:53 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: Catch when the process does not exist when killing it https://review.opendev.org/c/openstack/neutron/+/935046 | 10:11 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: Set a new removal release for ``set_network_type`` https://review.opendev.org/c/openstack/neutron/+/935272 | 10:23 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: [OVN] QoS max and min rules should be defined in LSP for phynet ports https://review.opendev.org/c/openstack/neutron/+/934418 | 10:26 |
| ralonsoh | slaweq, hi! if you have 1 minute: https://review.opendev.org/c/openstack/neutron/+/934652 | 10:29 |
| ralonsoh | thanks! | 10:29 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: Filter out the floating IPs when removing a shared RBAC https://review.opendev.org/c/openstack/neutron/+/935278 | 11:13 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: Filter out the floating IPs when removing a shared RBAC https://review.opendev.org/c/openstack/neutron/+/935278 | 11:14 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: Migrate from tenant_id to project_id in ``test_network.py`` https://review.opendev.org/c/openstack/neutron/+/935280 | 11:32 |
| opendevreview | Chris Buggy proposed openstack/ovn-octavia-provider master: Adding Tobiko Test To CI https://review.opendev.org/c/openstack/ovn-octavia-provider/+/935281 | 11:46 |
| slaweq | hi, do we have drivers meeting today? | 14:03 |
| ralonsoh | I'm waiting for it, yes | 14:03 |
| mlavalle | I thought so | 14:03 |
| lajoskatona | we have agenda so something will happen :-) | 14:03 |
| slaweq | I think we need someone to chair it then :) | 14:03 |
| ralonsoh | one sec | 14:03 |
| ralonsoh | #startmeeting neutron_drivers | 14:04 |
| opendevmeet | Meeting started Fri Nov 15 14:04:06 2024 UTC and is due to finish in 60 minutes. The chair is ralonsoh. Information about MeetBot at http://wiki.debian.org/MeetBot. | 14:04 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 14:04 |
| opendevmeet | The meeting name has been set to 'neutron_drivers' | 14:04 |
| ralonsoh | Ping list: ykarel, mlavalle, mtomaska, slaweq, obondarev, tobias-urdin, lajoskatona, amotoki, haleyb, ralonsoh | 14:04 |
| mlavalle | \o | 14:04 |
| ralonsoh | hello all | 14:04 |
| lajoskatona | o/ | 14:04 |
| obondarev | o/ | 14:04 |
| slaweq | o/ | 14:04 |
| s3rj1k | hi all | 14:04 |
| ralonsoh | we have many RFEs to discuss today | 14:04 |
| ralonsoh | and we have quorum, so I think we can start | 14:05 |
| amnik | hello all | 14:05 |
| ralonsoh | First one: [RFE] Configurable Agent Termination on OVS Restart | 14:05 |
| ralonsoh | https://bugs.launchpad.net/neutron/+bug/2086776 | 14:05 |
| ralonsoh | s3rj1k, please, present the RFE | 14:05 |
| s3rj1k | ralonsoh: Hi, yea so basically the idea is to automate manual fixes that are done by human, of agent in k8s env | 14:06 |
| ralonsoh | s3rj1k, my question, same as Liu in the bug is: why don't we fix what is broken in the OVS agent code? | 14:07 |
| ralonsoh | what exact flows are not recovered? | 14:07 |
| s3rj1k | to do that, there is an idea to introduce opt-in functionality to terminate agent instead of flow recovery | 14:07 |
| s3rj1k | fixing is a separate thing, here is about making sure that prod envs are working without human interaction | 14:08 |
| ralonsoh | the OVS agent is capable of detecting when the vswitch has been restarted and tries to restore the flows | 14:09 |
| opendevreview | Sebastian Lohff proposed openstack/neutron master: docs: Fix typo in openstack create subnet command https://review.opendev.org/c/openstack/neutron/+/935182 | 14:09 |
| s3rj1k | Liu also mentioned that this is only related to containerized evns, as for systemd setups there is already similar restarts happen, as I understand | 14:09 |
| ralonsoh | if we fix what is broken, that will solve your problem (and for any other one using it) | 14:09 |
| ralonsoh | Liu is stating, as he is right, that restaring the OVS agent has a high cost in the Neutron API | 14:10 |
| s3rj1k | to fix that we need to reporo bug, there is no time to do that on envs that have client workloads | 14:10 |
| s3rj1k | > restaring the OVS agent has a high cost - agree, hence opt-in | 14:10 |
| slaweq | I personally feel like this proposal is more like workaround for some bug rather then fix of it | 14:11 |
| ralonsoh | exactly | 14:11 |
| s3rj1k | agree, workaround | 14:11 |
| ralonsoh | s3rj1k, can you share with the community what is broken when the OVS restores the flows? | 14:11 |
| ralonsoh | because this is the critical point here but is not documented | 14:11 |
| ralonsoh | this is what needs to be fixed | 14:11 |
| s3rj1k | I have no specific repros right now, details that I have is in ticket, one of the flows was not recovered | 14:12 |
| ralonsoh | s3rj1k, so please, add this information in the LP bug and how to reproduce it locally, if possible | 14:12 |
| s3rj1k | when I will have a repro I will create a bug for it, but htis does not mean that workaround is invalid | 14:12 |
| ralonsoh | with this information we can try to fix it | 14:13 |
| lajoskatona | Could you please check the suggestion from Liu (https://bugs.launchpad.net/neutron/+bug/2086776/comments/5 ) that seam reasonable and in sync with the current design? | 14:13 |
| ralonsoh | that is a lightweight workaround too | 14:13 |
| ralonsoh | no API involved in this case | 14:13 |
| ralonsoh | but maybe could be a solution: instead of the current code that restores the flows, when the OVS is restarted, restart the OVS agent monitoring mechanism | 14:14 |
| lajoskatona | anyway if we have a list of missing things as ralonsoh suggested that can help to find the places to fix | 14:14 |
| lajoskatona | yeah perhaps | 14:15 |
| ralonsoh | s3rj1k, so please, before proceeding on any decision, we need to know what is actually broken. Then we can propose a solution (fix the restore methods, lightweight restart or full restart) | 14:16 |
| s3rj1k | are we sure we want to block general workaround on specific bug repro? | 14:16 |
| s3rj1k | things can be done async | 14:17 |
| ralonsoh | sorry what does it mean? | 14:17 |
| s3rj1k | continue with terminate workaround and as a separate bug try to find repro for that one specific flow | 14:17 |
| s3rj1k | I am pretty sure that there are more cases for flows recovery but I have no info on that, only value report on one of them | 14:18 |
| ralonsoh | if you ask me to implement a workaround for a bug I don't understand, I will say no | 14:18 |
| ralonsoh | I need to know what is broken | 14:18 |
| slaweq | personally I don't like idea of such kind of workaround because it don't seems for me as professional thing - it's a bit like implementing restart of service to fix memory leak :) So I would personally vote for fixing real bugs and handle ovs restart properly instead of this rfe | 14:19 |
| s3rj1k | as basically fix is manual restart, nobody is triaging bugs in prod | 14:19 |
| ralonsoh | nobody is triaging bugs in prod --> I do this for a living | 14:20 |
| s3rj1k | slaweq: so better to ignore that and keep line1 ops just restart all the things? | 14:20 |
| slaweq | also if you need workaround like that you can probably implement some small script which will be doing what you need to do - it don't need to be in the agent itself | 14:20 |
| slaweq | s3rj1k no, IMO it's better to try to reproduce the issue on dev env and try to fix it | 14:20 |
| s3rj1k | sure it can be done as some script | 14:20 |
| obondarev | no need to reproduce intentionally, just next time when manual intervention is needed (agent restart) - dump flows before and after restart, that could be enough for investigation | 14:21 |
| greatgatsby_ | was just coming in here to post about our outage we've had during 2 of our last 3 upgrade tests. Seems directly related to the OVS conversation you're having here now | 14:21 |
| lajoskatona | obondarev: +1, good that you added here | 14:22 |
| s3rj1k | as I said, when some details come in, I will create a separate bug for that | 14:22 |
| greatgatsby_ | we've had a 5 minute outage between when kolla-ansible restarts OVS containers (which triggers 2 separate flow re-creations) and we don't get FIP connectivity back until the neutron role, some 5 minutes later | 14:23 |
| s3rj1k | this is more about do we want some workaround in place or not | 14:23 |
| greatgatsby_ | in our testing, both the restart of openvswitch_db and openvswitch-vswitchd trigger neutron agent to recreate the flows, this happens within about 20 seconds of each other | 14:24 |
| slaweq | IMHO it is better to have script e.g. in https://opendev.org/openstack/osops for that rather then implement that in neutron | 14:25 |
| obondarev | +1 to slaweq | 14:25 |
| ralonsoh | s3rj1k, we want to fix this bug, for sure. We don't want to implement a workaround for something we don't understand. In order to push code, we need to know what is happening | 14:25 |
| greatgatsby_ | for some reason, but not always, neutron ovs agent doesn't seem to like this and connectivity is lost until the agent is restarted during the neutron role | 14:25 |
| greatgatsby_ | sorry for just injecting my recent experience, just excited that this is being discussed in here, hoping for some kind of mitigation | 14:26 |
| ralonsoh | so, for now, we are not going to vote for this RFE until we have a better description of the current problem | 14:26 |
| ralonsoh | s3rj1k, please, do not open a separate bug, provide this info in the current one | 14:26 |
| ralonsoh | ok, we have more RFEs and just 35 mins left | 14:27 |
| lajoskatona | greatgatsby_: do you think your issue is related to https://bugs.launchpad.net/neutron/+bug/2086776 ? | 14:27 |
| s3rj1k | greatgatsby_: can you please add more info to RFE if possible | 14:27 |
| ralonsoh | ok, next RFE: [RFE] L3 Agent Readiness Status for HA Routers | 14:28 |
| s3rj1k | ralonsoh: ok, if have more details I'll add them to this RFE | 14:28 |
| ralonsoh | #link https://bugs.launchpad.net/neutron/+bug/2086794 | 14:28 |
| ralonsoh | we had a similar bug https://bugs.launchpad.net/neutron/+bug/2011422 | 14:28 |
| ralonsoh | that was also discussed in a PTG (I don't remember which one) | 14:28 |
| s3rj1k | can be also discussed together with 2086799 | 14:28 |
| lajoskatona | I have a general comment for this and next one ([RFE] OVS Agent Synchronization Status for Container Environments ) | 14:28 |
| ralonsoh | first let's wait for the RFE proposal | 14:29 |
| ralonsoh | s3rj1k, please, go on | 14:29 |
| lajoskatona | Are these about monitoring our processes / agents etc.... Nova discussed something similar: https://etherpad.opendev.org/p/nova-2025.1-ptg#L255 perhaps worth to check before reinventing it | 14:29 |
| s3rj1k | both RFEs are about extending available data for k8s probes | 14:29 |
| greatgatsby_ | it sounds very similar. We've only just identified the trigger, and it not being 100% reproducable, it takes me a couple days to get back to a fresh environment. My next test I will log the flows the whole upgrade. For now, we've just identified it's caused by the 2 OVS container restarts, neutron agent doesn't recover properly somehow, and connectivity is lost to our VMs until minutes later | 14:30 |
| greatgatsby_ | when the agent is restarted as part of the neutron role in kolla-ansible | 14:30 |
| s3rj1k | so that pod mgmnt can do monitroing and life-cycling of containerized agents | 14:30 |
| greatgatsby_ | we've using DVR and VLANs, if that matters | 14:31 |
| ralonsoh | s3rj1k, but what is the information required? | 14:31 |
| ralonsoh | what do you exactly need to monitor? | 14:31 |
| slaweq | I think it is good idea generally for all the agents to report in some file what they are doing, like "full_sync in progress", "sync finished", etc. | 14:31 |
| s3rj1k | OVS agent's synchronization status (started/ready/dead states) | 14:31 |
| ralonsoh | slaweq, why a file? we have the Neutron API and heartbeats | 14:32 |
| slaweq | as sometimes such full sync after e.g. agent start can take very long time indeed | 14:32 |
| s3rj1k | and for second one HA router status | 14:32 |
| slaweq | ralonsoh IIUC it's about checking it locally | 14:32 |
| slaweq | by e.g. readiness probe in k8s | 14:32 |
| s3rj1k | I can extend both of RFEs with details if in general this sounds good | 14:32 |
| lajoskatona | agree with neutron API, we already have some healtcheck API, that should be extended | 14:32 |
| greatgatsby_ | we were surprised that both OVS container restarts each trigger flow re-creation in rapid succession | 14:33 |
| lajoskatona | Nova also move that direction see the spec: https://specs.openstack.org/openstack/nova-specs/specs/2024.2/approved/per-process-healthchecks.html | 14:33 |
| greatgatsby_ | https://github.com/openstack/kolla-ansible/blob/master/ansible/roles/openvswitch/handlers/main.yml | 14:33 |
| ralonsoh | we have a fantastic Neutron API that can be feed with anything we want | 14:33 |
| slaweq | and for such puprose reporting this to the neutron db and checking for each agent through api will not scale at all | 14:33 |
| ralonsoh | lajoskatona, exactly: this is a matter of improving the agent information mechanism | 14:33 |
| s3rj1k | for k8s probes it is best to use something local to pod | 14:34 |
| slaweq | we can send such info in the hearbeat too but saving it in a file locally shouldn't hurt anyone and can help in some cases | 14:34 |
| slaweq | but we should probably have some standarized list of possible states and reuse them in all agents | 14:35 |
| ralonsoh | I'm against storing local info if we don't push that to the API too | 14:35 |
| s3rj1k | probes in general tend to run frequently so anything that is network related can have pref impact on cluster, better to have local data | 14:35 |
| slaweq | not that each agent will report something slightly different | 14:35 |
| ralonsoh | slaweq, yes, that was the PTG proposal, having a set of states per agent, that coudl be configurable | 14:36 |
| ralonsoh | DHCP: network status (provisioning), L3: router status, etc | 14:36 |
| ralonsoh | that could be defined in each agent independently | 14:36 |
| ralonsoh | but again, this info should go to the API. If we want to store it locally as an option, perfect | 14:37 |
| mlavalle | like a state machine | 14:37 |
| ralonsoh | mlavalle, yes, and not only a global one per agent, but also per resource (network, router, etc) | 14:37 |
| slaweq | do we need them per agent, shouldn't just few standard ones be enough? Like e.g. "sync in progress", "operational" or something like that | 14:37 |
| s3rj1k | ralonsoh: works for my case if bot local and API | 14:37 |
| slaweq | what else would be needed there? | 14:38 |
| ralonsoh | slaweq, do you mean having standard states? | 14:38 |
| ralonsoh | regardless of the resource/agent | 14:38 |
| slaweq | ralonsoh yes, IMHO it can work that way | 14:38 |
| slaweq | but maybe I am missing something | 14:38 |
| ralonsoh | I think that makes sense | 14:38 |
| ralonsoh | slaweq, we can always add new states (that don't need to be used by all resources/agents) | 14:39 |
| slaweq | true | 14:39 |
| mlavalle | maybe there is a common set of states and then each agent has a few of its own | 14:39 |
| ralonsoh | but yes, initially I would propose a set of states that could match with the state of the common agents | 14:39 |
| slaweq | but that way we can have them in the neutron lib defined so that everyone will be able to rely on them pretty easily | 14:39 |
| ralonsoh | yes to both | 14:39 |
| lajoskatona | so let's have now some framweork with basic common information locally and on API? | 14:39 |
| slaweq | on api it is very easy as you can add whatever you want to the dict send in the heartbeat IIRC | 14:40 |
| ralonsoh | yes, some information that will be provided to the API and, via config, stored locally if needed | 14:40 |
| slaweq | so yes, I would say - have them in both places - api and locally | 14:40 |
| ralonsoh | I'm ok with this proposal, but of course we need a spec for sure | 14:41 |
| slaweq | locally it would be similar to the ha state of the router stored in the file | 14:41 |
| ralonsoh | ^ yes | 14:41 |
| lajoskatona | +1 | 14:41 |
| slaweq | yes, spec would be good. It don't need to be long but we should define there what states we want to have | 14:41 |
| ralonsoh | so +1 with spec | 14:42 |
| obondarev | +1 | 14:42 |
| slaweq | +1 from me | 14:42 |
| mlavalle | +1 | 14:42 |
| s3rj1k | should we start proposing states in RFE comments? | 14:42 |
| lajoskatona | +1 | 14:42 |
| ralonsoh | s3rj1k, it would be better to describe it in the spec | 14:42 |
| mlavalle | s3rj1k: wrte a short spec | 14:42 |
| s3rj1k | ok, will do | 14:43 |
| lajoskatona | Like these : https://opendev.org/openstack/neutron-specs/src/branch/master/specs/2024.2 under 2025.1 folder | 14:43 |
| mlavalle | s3rj1k: do you know how to propose a spec? | 14:43 |
| ralonsoh | s3rj1k, are you going to combine the RFEs in one single spec? | 14:43 |
| s3rj1k | I'll walk through docs, in case of questions just ask them here on regular day, so no prob with that, thanks | 14:43 |
| s3rj1k | > in one single spec? - that can make sense yes | 14:44 |
| ralonsoh | perfect, I'll comment that in the LP bugs after this meeting | 14:44 |
| ralonsoh | so we can skip the 3rd one and go for the last one | 14:45 |
| ralonsoh | [RFE] Add OVN Ganesha Agent to setup path for VM connectivity to NFS-Ganesha | 14:45 |
| ralonsoh | #link https://bugs.launchpad.net/neutron/+bug/2087541 | 14:45 |
| ralonsoh | Is Amir here now? | 14:45 |
| amnik | Yes I'm here | 14:45 |
| ralonsoh | perfect, can you explain it a bit? | 14:46 |
| amnik | sure | 14:46 |
| amnik | According to the Manila documentation, there is a need for network connectivity between the NFS-Ganesha service and the client mounting the Manila share. | 14:46 |
| amnik | Currently, no existing solution addresses this requirement. This RFE proposes to solve it using Neutron and OVN. | 14:46 |
| slaweq | first thing from me - instead of new agent we can do this as extension to the neutron-ovn-agent probably | 14:47 |
| ralonsoh | I couldn't agree more (note: during this release I need to make the OVN agent the default one...) | 14:47 |
| mlavalle | +1 | 14:48 |
| ralonsoh | we already have a generic agent for OVN, with a plugable interface | 14:48 |
| mlavalle | that was the whole point of it | 14:48 |
| ralonsoh | is just a matter of implementing the needed plugin and enable it | 14:48 |
| ralonsoh | amnik, what is actually needed? what the agent needs to do? | 14:49 |
| ralonsoh | what will trigger these actions? | 14:49 |
| amnik | this solution inspired by ovn metadata agent | 14:49 |
| amnik | it detects ports for ganesha connectivity and plug the on compute nodes | 14:50 |
| amnik | these ports are distributed localport like metadata port | 14:50 |
| slaweq | I don't know about Ganesha at all, can you maybe in briefly explain what this port is needed for on compute nodes , how vms will use it, etc.? | 14:51 |
| amnik | ganesha mediated traffic to the cephFS. You can think about it like NFS server between vms and cephFS in ceph cluster | 14:52 |
| amnik | after we plugging the port on compute nodes we add some iptables rule to dnat traffic to the ganesha | 14:53 |
| amnik | private_ip_port:2049 -> ganesha_ip:2049 | 14:54 |
| ralonsoh | is this port a VM port? | 14:54 |
| slaweq | and it is one virtual port per network? So all vms conected to that network will use the same port? | 14:54 |
| amnik | It like metadata port. Not bind to any chassis. | 14:55 |
| ralonsoh | but who is creating this port? | 14:55 |
| ralonsoh | is in the OVN database? | 14:55 |
| slaweq | and other question: ganesha_ip is from the same private network or not? | 14:55 |
| ralonsoh | apart from the technical questions, I'm a bit reluctant to add something so specific in the Neutron repository | 14:57 |
| amnik | slaweq: I think better to create port for each share that vms want to connect to. So we can manage it per share(storage on cephFS ) | 14:57 |
| amnik | ralonsoh: the port will be created with API and after that ganesha agent detect it | 14:58 |
| amnik | ralonsoh: yes in OVN database that agent can detect it with event. | 14:59 |
| ralonsoh | how? this port won't be bound to a chassis | 14:59 |
| ralonsoh | we use the SB and the local OVS database | 14:59 |
| ralonsoh | same as an ovn-controller | 14:59 |
| slaweq | could it be that neutron-ovn-agent extension which would be respoinsible for this would be actually in Manila and just loaded by neutron-ovn-agent if needed? We can accept new device type if needed so that you can create port with this new device type in neutron api but other things may actually be in Manila as it seems that this is team of experts on this topic, not we | 15:00 |
| amnik | slaweq: No ganesha is service that deploy for example on our controller servers and has IP with network of that server. | 15:00 |
| amnik | ralonsoh: agent can detect it by device_id convention like ovnganesh- and port type in PORT_binding table | 15:02 |
| ralonsoh | slaweq, yes, that could work | 15:02 |
| ralonsoh | amnik, you said this port is not bound | 15:02 |
| ralonsoh | who is physically creating this port? | 15:03 |
| slaweq | if that would have to land in the neutron repository, we would probably need spec but I agree with ralonsoh that this may be a bit outside our expertise here so maybe it would be better to keep as much as possible in manila and just add necessary bits in neutron (neutron-lib) to handle that new type of ports correctly | 15:03 |
| ralonsoh | agree with this | 15:04 |
| amnik | ralonsoh: This is a seperate API call that user should create the port (openstack port create ...) | 15:04 |
| ralonsoh | amnik, no | 15:04 |
| ralonsoh | who is creating the layer one port | 15:04 |
| ralonsoh | ? | 15:04 |
| ralonsoh | anyway, we are running out of time | 15:05 |
| ralonsoh | we can continue after this meeting | 15:05 |
| ralonsoh | what is the recommendation for this RFE? | 15:05 |
| ralonsoh | I agree with slaweq's comment | 15:05 |
| mlavalle | me too | 15:06 |
| slaweq | I would like to see detailed spec with exact description about how this is going to work in both API and backend | 15:06 |
| amnik | ralonsoh: This is a responsiblity of ganesha agent. user create port. agent will plug it to the compute node with veth devices like metadata port | 15:06 |
| ralonsoh | but for now this RFE is not approved, right? | 15:07 |
| slaweq | Then we can discuss there what have to be in neutron and maybe what can be somewhere else | 15:07 |
| obondarev | I think RFE needs to be updated at least, new agent seems an overkill | 15:07 |
| slaweq | ralonsoh IMO not yet, it's too early | 15:07 |
| ralonsoh | ok, I'll comment that in the LP bug | 15:07 |
| ralonsoh | I'm closing this meeting now | 15:07 |
| ralonsoh | #endmeeting | 15:07 |
| opendevmeet | Meeting ended Fri Nov 15 15:07:54 2024 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 15:07 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/neutron_drivers/2024/neutron_drivers.2024-11-15-14.04.html | 15:07 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/neutron_drivers/2024/neutron_drivers.2024-11-15-14.04.txt | 15:07 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/neutron_drivers/2024/neutron_drivers.2024-11-15-14.04.log.html | 15:07 |
| ralonsoh | thanks for attending | 15:08 |
| lajoskatona1 | Bye | 15:08 |
| slaweq | o/ | 15:08 |
| s3rj1k | thanks, bye | 15:08 |
| amnik | bye | 15:08 |
| ralonsoh | amnik, what I'm saying is that the agents read form the SB and the OVS local DB | 15:08 |
| ralonsoh | if you don't bind the port, who is adding it? the OVN agent cannot | 15:08 |
| amnik | Agent read from OVN DB. The API that user call add it to database. | 15:09 |
| ralonsoh | amnik, there are two DBs: NB and SB | 15:10 |
| ralonsoh | so you are expecting the OVN agent to create the port | 15:11 |
| amnik | ralonsoh: yes, from Port_Binding table in NB. https://man7.org/linux/man-pages/man5/ovn-nb.5.html | 15:11 |
| ralonsoh | amnik, port binding is in the SB | 15:12 |
| amnik | oh ,yes sorry your right. https://man7.org/linux/man-pages/man5/ovn-sb.5.html#Port_Binding_TABLE here | 15:14 |
| ralonsoh | but you won't have an event if the port is not created | 15:14 |
| ralonsoh | again, you are expecting the OVN agent to create the port | 15:14 |
| ralonsoh | Neutron doesn't create port (there are a few exception with trunk ports in OVS) | 15:14 |
| ralonsoh | I mean, Neutron doesn't create L1 ports | 15:15 |
| amnik | ralonsoh: I tested this solution on staging environment and implement most of it's logic and It work | 15:16 |
| amnik | openstack port create --network {} --device ovnganesha-d60f1efd-4791-419e-8c0d-93dc209fad49 --device-owner network:distributed manila | 15:16 |
| amnik | after above command I can get the event and plug the port on appropriate compute nodes. | 15:17 |
| ralonsoh | amnik, again, the proposal is to use the OVN agent but implement the code in your repository. You need to make a plugin for the OVN agent | 15:18 |
| amnik | ralonsoh: Yes I agree to implement it as OVN agent plugin. | 15:20 |
| amnik | I don't have time to say:) | 15:20 |
| vprokofev | ralonsoh, could you please advise on this RFE? https://bugs.launchpad.net/neutron/+bug/2083214 it's approved, I've pushed the spec, what's the next step would be? | 15:23 |
| ralonsoh | vprokofev, hi, now we need to review it. I'll add it to the Neutron meeting agenda on Tuesdays, to highlight it | 15:28 |
| ralonsoh | I'll also add other Neutron cores to the review | 15:28 |
| vprokofev | Thank you | 15:29 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: Bump os-ken version to 2.11.1 https://review.opendev.org/c/openstack/neutron/+/935364 | 15:36 |
| ralonsoh | @all: the CI is failing since os-ken 2.11.0 | 16:12 |
| ralonsoh | https://bugs.launchpad.net/neutron/+bug/2088285 | 16:12 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron-tempest-plugin master: Limit temporarily the os-ken version to <2.11.0 https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/935366 | 16:17 |
| opendevreview | Lajos Katona proposed openstack/neutron-tempest-plugin master: Change references from Quagga to FRR https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/935368 | 16:26 |
| ralonsoh | lajoskatona1, hey | 16:26 |
| ralonsoh | I've pushed and fast approved https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/935366 | 16:27 |
| ralonsoh | I'll stop it if you are fixing it | 16:27 |
| lajoskatona1 | ralonsoh: not sure if this is enugh: https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/935368 | 16:27 |
| ralonsoh | if not, I' | 16:27 |
| ralonsoh | tomorrow I'll send the patch capping the version | 16:28 |
| ralonsoh | just to fix temporarily the CI | 16:28 |
| ralonsoh | I need to leave now, I'll catch up later today | 16:28 |
| frickler | ralonsoh: what about 2.11.1, will that work? I just approved https://review.opendev.org/c/openstack/requirements/+/935360 | 16:28 |
| ralonsoh | frickler, no | 16:29 |
| lajoskatona1 | ralonsoh: ack, I have to leave also soon | 16:29 |
| ralonsoh | that is only a fix for the docker image build | 16:29 |
| frickler | looks like you cannot easily override the reqs in neutron anyway, so will need a revert of the upper-constraints bump, then | 16:30 |
| ralonsoh | no no, no need for now | 16:30 |
| ralonsoh | we can cap it in n-t-p and fix that later | 16:30 |
| frickler | you can't, zuul is very -1 on that | 16:30 |
| ralonsoh | ok because that is incorrect | 16:31 |
| ralonsoh | I'll push a new one or a fix | 16:31 |
| ralonsoh | but not now, in some hours | 16:31 |
| ralonsoh | CI can wait a bit a friday afternoon | 16:31 |
| ralonsoh | I need to leave now, see you later | 16:31 |
| frickler | ok then, ping me if you still need anything on the reqs side | 16:32 |
| ralonsoh | thanks! | 16:32 |
| lajoskatona1 | frickler: https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/935368 I suspect this will fail at least on the stable jobs as tempest is branchless, so perhaps we really need some magic on the reqs :-) | 16:38 |
| opendevreview | Ihar Hrachyshka proposed openstack/neutron master: tests: Remove skip_if_ovs_older_than decorator from a test case https://review.opendev.org/c/openstack/neutron/+/935250 | 16:42 |
| frickler | lajoskatona1: essentially you would revert https://review.opendev.org/c/openstack/requirements/+/935082 and denylist 2.11.0 and 2.11.1 | 16:51 |
| frickler | lajoskatona1: (ralonsoh offline): tkajinam also noticed n-d-r failures caused by os-ken, not sure if these have the same root cause or would need yet another fix https://bugs.launchpad.net/neutron/+bug/2088279 | 17:07 |
| opendevreview | Ihar Hrachyshka proposed openstack/neutron master: Enable no-else-return pylint check https://review.opendev.org/c/openstack/neutron/+/934205 | 17:43 |
| lajoskatona1 | firckler: yes the same as I see as https://bugs.launchpad.net/neutron/+bug/2088285 | 17:57 |
| opendevreview | Ihar Hrachyshka proposed openstack/neutron master: functional: Don't assume privsep-helper is installed in virtualenv https://review.opendev.org/c/openstack/neutron/+/935251 | 18:03 |
| opendevreview | Gaudenz Steinlin proposed openstack/neutron master: Add conntrackd support to HA routers in L3 agent https://review.opendev.org/c/openstack/neutron/+/917430 | 20:54 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!