slaweq | ralonsoh lajoskatona good morning, if one of You have some time, please check https://review.opendev.org/c/openstack/neutron/+/808502 | 08:15 |
---|---|---|
ralonsoh | slaweq, sure | 08:16 |
lajoskatona | slaweq: Hi, checking :-) | 08:16 |
slaweq | thx | 08:16 |
slaweq | and also backports https://review.opendev.org/q/Ic0bc3d951d32efadc116708bfe518a711730429d | 08:16 |
slaweq | ralonsoh lajoskatona and also https://review.opendev.org/c/openstack/neutron/+/818725 : | 08:17 |
slaweq | :) | 08:17 |
slaweq | thx in advance | 08:17 |
slaweq | and not merged backports in https://review.opendev.org/q/Idfa763df8c60d8ae46cd6351d1b6dc7d950b4c67 :) | 08:18 |
ralonsoh | slaweq, in https://review.opendev.org/c/openstack/neutron/+/818725 | 08:19 |
ralonsoh | should we adopt the policies in UTs? | 08:19 |
ralonsoh | or just skip the warning messages | 08:19 |
slaweq | ralonsoh | 08:20 |
slaweq | it's temporary to just ignore those warnings | 08:20 |
slaweq | later we will have new oslo_policy with fix for those scopes and we will start enforcing scope in those tests | 08:21 |
slaweq | and we will adjust policies | 08:21 |
slaweq | but this patch is needed to move on with https://review.opendev.org/c/openstack/oslo.policy/+/804980 | 08:21 |
ralonsoh | right so this is temporary | 08:22 |
slaweq | yes | 08:22 |
slaweq | I mean that we can skip those warnings, that will not hurt us for sure | 08:22 |
slaweq | but warnings should be gone when we will switch to enforce scopes in tests again | 08:23 |
ralonsoh | hi folks, if you have time for https://review.opendev.org/c/openstack/neutron/+/814143 | 09:03 |
ralonsoh | this is fixing an issue in the OVN mech driver, setting the info in the correct place | 09:04 |
opendevreview | Slawek Kaplonski proposed openstack/neutron stable/rocky: Populate self.floating_ips_dict using "ip rule" information https://review.opendev.org/c/openstack/neutron/+/810427 | 09:04 |
opendevreview | Slawek Kaplonski proposed openstack/neutron stable/queens: Populate self.floating_ips_dict using "ip rule" information https://review.opendev.org/c/openstack/neutron/+/810397 | 09:04 |
ralonsoh | lajoskatona, slaweq https://review.opendev.org/q/project:openstack/neutron-lib+status:open+owner:ralonsoh%2540redhat.com | 09:14 |
ralonsoh | maybe this week we can release a new n-lib | 09:14 |
ralonsoh | what do you think? | 09:14 |
opendevreview | Rodolfo Alonso proposed openstack/ovsdbapp master: Use setkey for DbSetCommand maps https://review.opendev.org/c/openstack/ovsdbapp/+/804252 | 09:16 |
slaweq | ralonsoh sounds good for me | 09:17 |
opendevreview | Merged openstack/neutron stable/queens: Don't setup bridge controller if it is already set https://review.opendev.org/c/openstack/neutron/+/816472 | 09:45 |
frickler | slaweq: lajoskatona: next round of n-d-r backports for your review list https://review.opendev.org/c/openstack/neutron-dynamic-routing/+/820908 https://review.opendev.org/c/openstack/neutron-dynamic-routing/+/820680 :-) | 09:48 |
lajoskatona | ralonsoh, slaweq: yeah, we merged a lot of things to neutron-lib | 09:55 |
lajoskatona | slaweq, ralonsoh: ovsdbapp release is also on its way: https://review.opendev.org/c/openstack/releases/+/820264 , otherwiseguy waits for some patches to be merged | 10:00 |
gibi | slaweq: do you have an open bug for https://zuul.opendev.org/t/openstack/build/9cd19c138a5746198b5a18c07c006a7c/log/job-output.txt#11282 ? | 10:02 |
gibi | slaweq: I see it happening pretty frequently | 10:02 |
gibi | slaweq: neutron.tests.functional.plugins.ml2.drivers.ovn.mech_driver.ovsdb.test_ovsdb_monitor.TestAgentMonitor.test_network_agent_present fails with return self.agents[key] | 10:02 |
slaweq | gibi: let me check | 10:08 |
*** _nick is now known as yankcrime | 10:10 | |
slaweq | gibi: it's the same as https://bugs.launchpad.net/neutron/+bug/1952508 | 10:10 |
slaweq | for which ralonsoh already have patch https://review.opendev.org/c/openstack/neutron/+/819502 | 10:10 |
gibi | slaweq: cool, thanks | 10:10 |
gibi | I will use that is recheck then :) | 10:11 |
slaweq | frickler sorry, I was in the meeting but now I see that Your patches are already approved :) | 10:11 |
slaweq | gibi++ | 10:11 |
opendevreview | Slawek Kaplonski proposed openstack/neutron stable/train: Do no use "--strict" for OF deletion in TRANSIENT_TABLE https://review.opendev.org/c/openstack/neutron/+/820493 | 10:11 |
opendevreview | Slawek Kaplonski proposed openstack/neutron stable/stein: Do no use "--strict" for OF deletion in TRANSIENT_TABLE https://review.opendev.org/c/openstack/neutron/+/820481 | 10:13 |
opendevreview | Slawek Kaplonski proposed openstack/neutron stable/rocky: Do no use "--strict" for OF deletion in TRANSIENT_TABLE https://review.opendev.org/c/openstack/neutron/+/820495 | 10:13 |
opendevreview | Slawek Kaplonski proposed openstack/neutron stable/queens: Do no use "--strict" for OF deletion in TRANSIENT_TABLE https://review.opendev.org/c/openstack/neutron/+/820496 | 10:13 |
gibi | slaweq: I also see really long running test cases like https://zuul.opendev.org/t/openstack/build/59befe6d962a4dfab0d6310a50ccf42e/log/job-output.txt#24667 took 1572 seconds (>25 minutes) is it normal? | 10:14 |
slaweq | gibi: it shouldn't be like that and it's also reported already https://bugs.launchpad.net/neutron/+bug/1953479 | 10:17 |
gibi | thanks! | 10:17 |
slaweq | I didn't had time to investigate it more | 10:17 |
slaweq | lajoskatona btw, can You maybe check https://review.opendev.org/c/openstack/neutron/+/819502 ? I hope it will solve that issue with functional tests, which gibi mentioned above :) | 10:18 |
frickler | slaweq: thx, np, my timeframe for patches is days or weeks, not minutes or seconds ;) and thx to lajoskatona too | 10:22 |
opendevreview | Merged openstack/neutron stable/rocky: Don't setup bridge controller if it is already set https://review.opendev.org/c/openstack/neutron/+/816471 | 10:26 |
opendevreview | Merged openstack/neutron master: Ignore warnings in the policies UT https://review.opendev.org/c/openstack/neutron/+/818725 | 10:26 |
opendevreview | Merged openstack/neutron stable/rocky: [Functional] Wait for the initial state of ha router before test https://review.opendev.org/c/openstack/neutron/+/808502 | 10:26 |
opendevreview | Merged openstack/neutron stable/ussuri: Cleanup router for which processing added router failed https://review.opendev.org/c/openstack/neutron/+/817676 | 10:26 |
opendevreview | Merged openstack/neutron-lib master: Add new method "update_network" to "L3AgentExtension". https://review.opendev.org/c/openstack/neutron-lib/+/818536 | 10:44 |
opendevreview | Merged openstack/neutron-dynamic-routing stable/wallaby: Dropping lower constraints testing (stable Wallaby) https://review.opendev.org/c/openstack/neutron-dynamic-routing/+/820908 | 10:46 |
opendevreview | Merged openstack/neutron-dynamic-routing stable/wallaby: Add a StaticScheduler without automatic scheduling https://review.opendev.org/c/openstack/neutron-dynamic-routing/+/820680 | 10:49 |
opendevreview | Merged openstack/neutron-lib master: Replace "target_tenant" with "target_project" in RBAC OVOs and models https://review.opendev.org/c/openstack/neutron-lib/+/820185 | 11:07 |
opendevreview | Luis Tomas Bolivar proposed openstack/neutron master: [WIP] Use Port_Binding up column to set Neutron port status https://review.opendev.org/c/openstack/neutron/+/821544 | 11:09 |
opendevreview | Merged openstack/neutron-tempest-plugin master: Use LOG.warning instead of deprecated LOG.warn https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/819592 | 11:55 |
opendevreview | Merged openstack/neutron master: [OVN] Add the VIF details "connectivity" parameter https://review.opendev.org/c/openstack/neutron/+/814143 | 12:18 |
opendevreview | Luis Tomas Bolivar proposed openstack/neutron master: [WIP] Use Port_Binding up column to set Neutron port status https://review.opendev.org/c/openstack/neutron/+/821544 | 12:34 |
slaweq | ralonsoh bcafarel please give +W in https://review.opendev.org/c/openstack/neutron/+/817677 if You will have a moment, it has 2x+2 already | 13:16 |
gibi | slaweq: one more error from tempest https://zuul.opendev.org/t/openstack/build/2b9a5465257c4580937941e25489944b/log/controller/logs/screen-q-svc.txt#3509 Does it ring a bell? | 13:16 |
slaweq | and other backports are merged | 13:16 |
ralonsoh | slaweq, sure | 13:16 |
slaweq | ralonsoh thx | 13:16 |
slaweq | gibi checking | 13:16 |
slaweq | gibi I don't think I have seen something like that already | 13:19 |
gibi | slaweq: OK, I will try to see how frequent it is and if I find multiple hits then I will open a bug | 13:20 |
slaweq | gibi++ thx a lot | 13:20 |
opendevreview | Lajos Katona proposed openstack/neutron-tempest-plugin master: Add logs for test_floatingip_port_details https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/821557 | 13:22 |
gibi | slaweq: I only found two hits in ~ a month so I think we can ignore this for now | 13:25 |
slaweq | yes | 13:26 |
slaweq | thx for checking | 13:27 |
opendevreview | Rodolfo Alonso proposed openstack/neutron stable/wallaby: [stable-only] "_clean_logs_by_target_id" to use old notifications https://review.opendev.org/c/openstack/neutron/+/821563 | 13:56 |
opendevreview | Rodolfo Alonso proposed openstack/neutron stable/victoria: [stable-only] "_clean_logs_by_target_id" to use old notifications https://review.opendev.org/c/openstack/neutron/+/821564 | 13:57 |
opendevreview | Rodolfo Alonso proposed openstack/neutron stable/ussuri: [stable-only] "_clean_logs_by_target_id" to use old notifications https://review.opendev.org/c/openstack/neutron/+/821565 | 13:57 |
opendevreview | Rodolfo Alonso proposed openstack/neutron stable/train: [stable-only] "_clean_logs_by_target_id" to use old notifications https://review.opendev.org/c/openstack/neutron/+/821566 | 13:57 |
ralonsoh | slaweq, bcafarel please check those stable-only patches ^^^ | 13:58 |
ralonsoh | and lajoskatona of course (if you have time, we saw that in a customer) | 13:58 |
slaweq | ralonsoh checking it right now | 13:58 |
icey | hey, would it be possible to get new point releases of Neutron cut? | 14:37 |
opendevreview | Rodolfo Alonso proposed openstack/neutron master: Remove the expired reservations in a separate DB transaction https://review.opendev.org/c/openstack/neutron/+/821592 | 15:34 |
opendevreview | Rodolfo Alonso proposed openstack/neutron master: [OVN] Keep "connectivity" VIF details parameter in migration https://review.opendev.org/c/openstack/neutron/+/814145 | 15:34 |
opendevreview | Lajos Katona proposed openstack/neutron master: Add logs for port_bound_to_host https://review.opendev.org/c/openstack/neutron/+/821599 | 15:49 |
mdbooth | Hi. I'm getting a 409 deleting a trunk in my CI logs. Search for req-5571a3fa-c1c3-4678-9db1-6be47b96d46a in https://storage.googleapis.com/kubernetes-jenkins/pr-logs/pull/kubernetes-sigs_cluster-api-provider-openstack/1073/pull-cluster-api-provider-openstack-e2e-test/1470370499174338560/artifacts/devstack/controller-devstack.log context to follow | 15:51 |
mdbooth | immediately. | 15:51 |
mdbooth | This is during a server delete operation, and we're doing: server.list_interfaces(), for each vif { server.detach(vif); delete_trunk_for(vif); delete(vif) } | 15:53 |
mdbooth | We know we appear to have a race between detach(vif) and delete(vif): we always see ERRORs in the logs from the detach because its port was deleted. | 15:54 |
mdbooth | However, I can't explain the 409 deleting the trunk. AFAICT we can delete the trunk when its parent port is attached or unattached. Is there any reason why we briefly wouldn't be able to delete it inbetween? | 15:55 |
mdbooth | stable/victoria in case it's important. | 15:55 |
frickler | mdbooth: I'm really no expert, but I would expect that the delete(vif) would need to go first, delete(trunk) second. because the vif should be a sub-port on the trunk? | 16:10 |
mdbooth | The vif is the parent port. I'm pretty sure those deletes are the right way round. I don't think it works the other way round. | 16:11 |
mdbooth | I should have said that. In this case the trunk has no sub-ports. | 16:12 |
frickler | mdbooth: ah, o.k., though I wonder what trunks without subports are good for. that said, looking at https://opendev.org/openstack/neutron/src/branch/master/neutron/services/trunk/rules.py#L113-L138 there seems indeed be the possibility for a race if the port is unbound after the initial is_bound() check. | 16:26 |
mdbooth | They're not useful for anything afaik, but this CI test just doesn't add any. We just need to ensure the trunk is available. | 16:27 |
mdbooth | (And we can delete it afterwards!) | 16:27 |
opendevreview | Rodolfo Alonso proposed openstack/neutron master: Add Chassis creation wait event in "TestAgentMonitor" https://review.opendev.org/c/openstack/neutron/+/819502 | 16:39 |
mdbooth | frickler: Sorry for the short answers: was in a meeting (now finished). | 16:47 |
mdbooth | I saw that code, but I got a bit lost working out what was going on with the drivers. | 16:47 |
mdbooth | IIUC if the port is not bound we will never get the 409, so I assume the port is bound. However, in my manual testing I seem to be able to delete the trunk regardless of whether the port is bound. | 16:48 |
mdbooth | Oh, I should say: I'm interpreting 'bound' here to mean 'attached'. i.e. I'm doing: port create, network trunk create, server add port, network trunk delete. I'm assuming that's me deleting a 'bound' trunk? | 16:50 |
mdbooth | That works, btw, and doesn't reproduce the CI failure. | 16:50 |
frickler | mdbooth: the race would be between server remove port and network trunk delete. do you hit the issue always or only sometimes? | 17:44 |
sean-k-mooney | mdbooth: technially bound means you have set host-id:<hostname> on the port and an ml2 driver has been selected and updated the port binding:details and and port binding:profile | 17:55 |
*** tbachman_ is now known as tbachman | 17:55 | |
sean-k-mooney | mdbooth: it does not mean the port is attach to the vm although in almost al cases there is a 1:1 releaship to attaching a port to the vm and binding it | 17:55 |
sean-k-mooney | there is an interval of time where the port is bound and not acttached to the vm while we are booting or hot attaching the port or during a migration | 17:56 |
sean-k-mooney | but that is mroe of a trasient state | 17:56 |
sean-k-mooney | e.g. while we are generating the xml and invoking libvirt to do whatever | 17:57 |
sean-k-mooney | using port bound status to infer attachment howver is an ok proxy in must case but technially its not somethign you shoudl realy on | 17:58 |
sean-k-mooney | you should look at the nova not neutron if you care about the attach completeing ectra | 17:58 |
frickler | mdbooth: o.k., I can trigger your error pretty fast by doing "server add/remove port" in one loop and "network trunk create/delete" in a second one | 18:07 |
frickler | I'm also seeing a similar race for trunk creation, which is calling the same function I linked to | 18:14 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!