| frickler | Zer0Byte: if you want global IPv6 connectivity from your tenant networks, you need to set them up with global addresses and get them routed. I wrote this piece about it some time ago https://cloudbau.github.io/openstack/neutron/networking/ipv6/2017/09/11/neutron-pike-ipv6.html | 05:58 |
|---|---|---|
| Zer0Byte | that what im facing now | 06:00 |
| Zer0Byte | i can reach the router | 06:00 |
| Zer0Byte | but i dont have a inbound route | 06:00 |
| Zer0Byte | so i need to setup a bgp to make it work ? | 06:01 |
| Zer0Byte | @frickler | 06:01 |
| songwenping_ | grfy: thanks a lot for your guide, i have created an ACTIVE instance. | 06:03 |
| frickler | Zer0Byte: bgp on the outside, neutron-dynamic-routing on the openstack side, yes | 06:03 |
| songwenping_ | but the ovn-southd service is not avalable. | 06:04 |
| Zer0Byte | my setup is border routers that talk with the upstream provider and core and manage the ip addreses | 06:04 |
| Zer0Byte | so for each router created will create a route via Bgp | 06:04 |
| Zer0Byte | ? | 06:05 |
| Zer0Byte | honesly that make sense | 06:09 |
| Zer0Byte | are routers routers need to talk each others | 06:10 |
| slaweq | ralonsoh lajoskatona hi, if You will have few minutes, please check https://review.opendev.org/c/openstack/neutron/+/808071 | 07:11 |
| slaweq | it should fix one of the functional tests failures (I hope at least :)) | 07:11 |
| ralonsoh | sure | 07:17 |
| slaweq | thx | 07:20 |
| opendevreview | Slawek Kaplonski proposed openstack/neutron stable/train: HA-non-DVR router don't need manually add static route https://review.opendev.org/c/openstack/neutron/+/808153 | 07:52 |
| opendevreview | Kevin Li proposed openstack/neutron master: Trunk and port are residual in VM deleting scenario when southbound plugin/agent failed https://review.opendev.org/c/openstack/neutron/+/808179 | 07:56 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: [OVN] Metadata ports device_owner is "network:distributed" only https://review.opendev.org/c/openstack/neutron/+/807707 | 08:24 |
| kevko | Hi folks, nice day to everyone :) | 08:27 |
| kevko | please, could someone help me with below tempest tests ? | 08:27 |
| kevko | FAILED 2021-09-08 09:54:26.840 286 INFO testing-verifier [-] {14} tempest.api.compute.servers.test_attach_interfaces.AttachInterfacesTestJSON.test_create_list_show_delete_interfaces_by_fixed_ip ... fail [234.924s] | 08:27 |
| kevko | FAILED 2021-09-08 09:58:02.904 286 INFO testing-verifier [-] {14} tempest.api.compute.servers.test_attach_interfaces.AttachInterfacesTestJSON.test_create_list_show_delete_interfaces_by_network_port ... fail [216.005s] | 08:27 |
| kevko | FAILED 2021-09-08 10:04:26.683 286 INFO testing-verifier [-] {14} tempest.api.compute.servers.test_attach_interfaces.AttachInterfacesTestJSON.test_reassign_port_between_servers ... fail [383.674s] | 08:27 |
| kevko | FAILED 2021-09-0i8 10:15:02.346 286 INFO testing-verifier [-] {8} tempest.scenario.test_network_basic_ops.TestNetworkBasicOps.test_hotplug_nic ... fail [224.785s] | 08:27 |
| kevko | FAILED 2021-09-08 10:24:58.366 286 INFO testing-verifier [-] {8} tempest.scenario.test_network_basic_ops.TestNetworkBasicOps.test_port_security_macspoofing_port ... fail [156.483s] | 08:27 |
| kevko | all tempests are ok ..but these 5 tests are always failing ..and I don't know why | 08:28 |
| kevko | these two strange errors are appearing in log | 08:28 |
| kevko | https://paste.opendev.org/show/809221/ | 08:29 |
| kevko | anyone ? | 08:29 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: Replace "Inspector.from_engine()" with "sqlalchemy.inspect()" https://review.opendev.org/c/openstack/neutron/+/808103 | 08:32 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: [DNM] TEST: check "neutron-ovn-tempest-ovs-master-fedora" job works fine https://review.opendev.org/c/openstack/neutron/+/808110 | 08:36 |
| opendevreview | Slawek Kaplonski proposed openstack/neutron stable/wallaby: VLAN "allocate_partially_specified_segment" can return any physnet https://review.opendev.org/c/openstack/neutron/+/808156 | 09:09 |
| frickler | kevko: that looks similar to an issue that nova had with the recently released osc-placement. maybe check if you are using latest versions | 09:09 |
| kevko | i'm using victoria btw (sorry , i forgot to mention) | 09:10 |
| kevko | so I am using 2.1.0 | 09:10 |
| opendevreview | Slawek Kaplonski proposed openstack/neutron stable/victoria: Make test_throttler happy https://review.opendev.org/c/openstack/neutron/+/808157 | 09:14 |
| kevko | frickler: could you point me to some commit ? | 09:14 |
| opendevreview | Slawek Kaplonski proposed openstack/neutron stable/ussuri: Make test_throttler happy https://review.opendev.org/c/openstack/neutron/+/808158 | 09:14 |
| opendevreview | Slawek Kaplonski proposed openstack/neutron stable/train: Make test_throttler happy https://review.opendev.org/c/openstack/neutron/+/808159 | 09:15 |
| opendevreview | Slawek Kaplonski proposed openstack/neutron stable/victoria: Randomize segmentation ID assignation https://review.opendev.org/c/openstack/neutron/+/805000 | 09:23 |
| opendevreview | Slawek Kaplonski proposed openstack/neutron stable/ussuri: Randomize segmentation ID assignation https://review.opendev.org/c/openstack/neutron/+/804999 | 09:27 |
| opendevreview | Slawek Kaplonski proposed openstack/neutron stable/train: Randomize segmentation ID assignation https://review.opendev.org/c/openstack/neutron/+/808160 | 09:28 |
| ralonsoh | slaweq, hi! on top of ^^^ those patche, you'll need https://review.opendev.org/c/openstack/neutron/+/808156 too | 09:28 |
| slaweq | ralonsoh: thx I will propose it | 09:29 |
| ralonsoh | slaweq, btw, we have a problem with some patches here https://review.opendev.org/q/Id3f71611a00e69c4f22340ca4d05d95e4373cf69 | 09:30 |
| ralonsoh | those ones in WIP must be set as active only by the owner | 09:30 |
| slaweq | I know, I just rebased them and fixed conflicts | 09:30 |
| slaweq | when CI will be ok, I will try to contact owner to remove WIP flag :) | 09:31 |
| ralonsoh | cool | 09:31 |
| slaweq | thx for checking them :) | 09:31 |
| opendevreview | Slawek Kaplonski proposed openstack/neutron stable/victoria: VLAN "allocate_partially_specified_segment" can return any physnet https://review.opendev.org/c/openstack/neutron/+/808189 | 09:34 |
| opendevreview | Slawek Kaplonski proposed openstack/neutron stable/ussuri: VLAN "allocate_partially_specified_segment" can return any physnet https://review.opendev.org/c/openstack/neutron/+/808191 | 09:36 |
| opendevreview | Slawek Kaplonski proposed openstack/neutron stable/train: VLAN "allocate_partially_specified_segment" can return any physnet https://review.opendev.org/c/openstack/neutron/+/808192 | 09:37 |
| *** elodilles_pto is now known as elodilles | 09:37 | |
| frickler | kevko: see https://bugs.launchpad.net/placement-osc-plugin/+bug/1942740 , if that doesn't solve your issue, maybe still check with nova if it might be related | 09:54 |
| kevko | frickler: now i found this in nova-compute -> /var/log/kolla/nova/nova-compute.log:2021-09-10 09:49:09.815 8 ERROR nova.virt.libvirt.driver [req-8082a663-ca30-4845-9e93-2429c500ba76 31031550a7c94928abbd9dfa8634fba1 7b2ac086026741aa82c6c9c96ded42ee - default default] [instance: cf3ae6f9-a971-4123-ae73-9b597364985a] attaching network adapter failed.: libvirt.libvirtError: internal error: unable to execute QEMU command 'netdev_add': Invalid | 10:12 |
| kevko | parameter type for 'vhost', expected: boolean | 10:12 |
| kevko | 10:12 | |
| kevko | and that's definitely sounds like a bug :/ :( | 10:12 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: [OVS][FW] Initialize ConjIdMap._max_id depending on the current OFs https://review.opendev.org/c/openstack/neutron/+/804236 | 10:17 |
| ralonsoh | slaweq, just a heads-up about https://bugs.launchpad.net/tempest/+bug/1942913 for the next CI meeting | 10:24 |
| ralonsoh | there are two errors, first one is solved with https://review.opendev.org/c/openstack/tempest/+/808081 | 10:24 |
| ralonsoh | test patch: https://review.opendev.org/c/openstack/neutron/+/808110 | 10:24 |
| ralonsoh | I'm still trying to find the problem with tempest.scenario.test_server_basic_ops.TestServerBasicOps.test_server_basic_ops | 10:25 |
| ralonsoh | (this is because next week I'm in PTO) | 10:25 |
| slaweq | ralonsoh thx a lot | 10:34 |
| slaweq | I see You updated it in etherpad too | 10:34 |
| ralonsoh | I'm on it now | 10:34 |
| slaweq | thx a lot, that's great :) | 10:34 |
| opendevreview | Merged openstack/neutron stable/wallaby: VLAN "allocate_partially_specified_segment" can return any physnet https://review.opendev.org/c/openstack/neutron/+/808156 | 10:58 |
| slaweq | ralonsoh regarding https://review.opendev.org/c/openstack/neutron-lib/+/807876 I don't think it can be shim extension really | 11:06 |
| slaweq | did You test that it works fine with shim extension and Neutron can accept that extra attribute? | 11:06 |
| ralonsoh | slaweq, maybe the description is incorrect | 11:09 |
| ralonsoh | one sec | 11:09 |
| kevko | frickler: libvirt 5.0.0 is issue .. it's buggy unfortunatelly | 11:16 |
| kevko | frickler: https://bugzilla.redhat.com/show_bug.cgi?id=1832710 | 11:17 |
| frickler | kevko: good to know, thanks for the update | 11:23 |
| kevko | frickler: i've already replaced libvirt container from buster to bullseye ..and it's just works :) | 11:24 |
| ralonsoh | slaweq, quota controller does not work as any other extension in Neutron | 11:27 |
| ralonsoh | all extensions have an API definition, that is usually defined in n-lib | 11:27 |
| ralonsoh | this is what is used to create the controller | 11:28 |
| ralonsoh | however, quota controller API is built using the registered resources | 11:28 |
| ralonsoh | slaweq, please check https://review.opendev.org/c/openstack/neutron-lib/+/807876/3/neutron_lib/api/definitions/quota_check_limit.py#16 | 11:44 |
| opendevreview | Lajos Katona proposed openstack/neutron master: CI: add experimental jobs to be executed with n-lib master https://review.opendev.org/c/openstack/neutron/+/807722 | 11:52 |
| opendevreview | Lajos Katona proposed openstack/neutron master: Add functional tests for ECMP routes https://review.opendev.org/c/openstack/neutron/+/805052 | 12:56 |
| lajoskatona | slaweq: Do we have drivers meeting? | 14:03 |
| mlavalle | wondering that myself | 14:03 |
| ralonsoh | we do yes | 14:04 |
| slaweq | sorry, I had a phone call | 14:04 |
| slaweq | lajoskatona I though You will start it :) | 14:04 |
| lajoskatona | I feared that You thought that :-) | 14:05 |
| slaweq | #startmeeting neutron_drivers | 14:05 |
| opendevmeet | Meeting started Fri Sep 10 14:05:02 2021 UTC and is due to finish in 60 minutes. The chair is slaweq. Information about MeetBot at http://wiki.debian.org/MeetBot. | 14:05 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 14:05 |
| opendevmeet | The meeting name has been set to 'neutron_drivers' | 14:05 |
| slaweq | #chair lajoskatona | 14:05 |
| opendevmeet | Current chairs: lajoskatona slaweq | 14:05 |
| mlavalle | o/ | 14:05 |
| ralonsoh | hi | 14:05 |
| lajoskatona | o/ | 14:05 |
| obondarev | hi | 14:05 |
| haleyb | hi | 14:05 |
| slaweq | ok, I will do it today for the last time :) | 14:05 |
| slaweq | no worries | 14:05 |
| slaweq | ok, I think we can start | 14:06 |
| slaweq | #topic RFEs | 14:06 |
| slaweq | we have 3 rfes for today | 14:06 |
| slaweq | first one | 14:06 |
| slaweq | https://bugs.launchpad.net/neutron/+bug/1830014 | 14:06 |
| lajoskatona | For that I found an old merged spec: https://review.opendev.org/c/openstack/neutron-specs/+/662541 | 14:07 |
| slaweq | this is an old RFE which I though would be good to get back to and decide finally maybe if we want to approve it (as an idea) or not | 14:07 |
| slaweq | lajoskatona this spec isn't merged | 14:07 |
| lajoskatona | oh, bad link: https://review.opendev.org/c/openstack/neutron-specs/+/308973 | 14:08 |
| lajoskatona | it's something similar | 14:08 |
| lajoskatona | and it seems an old topic | 14:08 |
| slaweq | but idea here is a bit different IIUC | 14:09 |
| slaweq | I just quickly looked at that old spec | 14:09 |
| slaweq | old spec wants to focus on diagnostic of the neutron resources like agent, network or subnet | 14:09 |
| slaweq | and liuyulong's proposal now is to have some "probe" to check locally connectivity to the instance | 14:10 |
| slaweq | that's my understanding at least | 14:10 |
| lajoskatona | yeah that's a difference, that's true | 14:11 |
| mlavalle | whose CI problems are we trying to address with this? Ours? | 14:12 |
| slaweq | TBH I have problem with that liuyulong's proposal as IMO it will do very small diagnosis actually | 14:12 |
| slaweq | and it can only check if VM is configured properly in the guest os - it will really tell nothing about where connectivity can be broken | 14:13 |
| ralonsoh | please, let's focus on one spec | 14:13 |
| ralonsoh | both are very different | 14:13 |
| slaweq | mlavalle TBH original issue with SSH not ready in our CI was solved/workarounded some time ago with simple patch which checks console-log of the vm | 14:13 |
| slaweq | so the original use case given in that spec is not the problem anymore IMO | 14:13 |
| ralonsoh | that means spec 308973 is not relevant anymore? | 14:14 |
| mlavalle | not for this conversation | 14:15 |
| slaweq | ralonsoh when I was talking about original use case, I meant the one described in Liu's spec: https://review.opendev.org/c/openstack/neutron-specs/+/662541 | 14:16 |
| slaweq | I didn't even read the old one :) | 14:16 |
| ralonsoh | slaweq, ok. About Liu's spec, I think skydive can provide this functionality | 14:17 |
| slaweq | more or less | 14:18 |
| obondarev | ralonsoh, will you please share a link? | 14:18 |
| ralonsoh | obondarev, http://skydive.network/ | 14:18 |
| obondarev | thanks! | 14:19 |
| slaweq | the only thing which Liu's proposal can address is checking if some service, like e.g. ssh works on the guest vm or if security groups are ok or not | 14:19 |
| slaweq | as he wan't to install probe in the node where vm is placed | 14:19 |
| obondarev | to me it sounds like something similar to tempest: like some subset of tests that could be run easily | 14:20 |
| obondarev | with pings, ssh, etc. | 14:20 |
| slaweq | obondarev kind of but it's for "real" vms | 14:21 |
| ralonsoh | so this is basically a probe with a set of tools | 14:21 |
| slaweq | I can imaging that this could be maybe useful for e.g. support team in public cloud company | 14:21 |
| ralonsoh | I'm ok if, in the spec, we specify what will be able to do, the implementation | 14:22 |
| slaweq | maybe if probe could be manually placed on any host that could be useful - someone from support could then e.g. install probe in the host where customer's router is and check if from there there is connectivity to vm | 14:22 |
| mlavalle | the use case described in the RFE is upstream CI. you, lajoskatona, ralonsoh, slaweq are the prime use case targets. Do you find this useful? | 14:24 |
| mlavalle | described in the RFE and the spec ^^^^ | 14:24 |
| ralonsoh | the CI has its own tools, if this is the target, no | 14:24 |
| slaweq | mlavalle as I said, in the ci it isn't really needed now | 14:24 |
| mlavalle | ok, then we can speculate about possible use cases... but if we don't have users representing those use cases demanding this, why do it? | 14:25 |
| lajoskatona | yeah if I understand well we should add / change existing tests to use the API and install probe to test hosts | 14:25 |
| lajoskatona | the original debug tool was only used in CI or in production environemt also? | 14:26 |
| mlavalle | additional lines of code add to the maintenance challenge (entropy) of the project. Why add to it if we don't have a clear use case? | 14:27 |
| slaweq | mlavalle: I agree with You 100% | 14:28 |
| slaweq | also, it can be proposed as separate project if it could be really useful for some use cases | 14:29 |
| slaweq | but for now, I tend to vote -1 for this rfe | 14:29 |
| mlavalle | in factin fact Yulong said something about this back in January, looking at the spec | 14:29 |
| mlavalle | so I don't think it's a pressing issue even for him, on the evidence we have | 14:29 |
| slaweq | true, this is sitting there for very long time :) | 14:31 |
| opendevreview | OpenStack Release Bot proposed openstack/neutron-lib stable/xena: Update .gitreview for stable/xena https://review.opendev.org/c/openstack/neutron-lib/+/808228 | 14:31 |
| opendevreview | OpenStack Release Bot proposed openstack/neutron-lib stable/xena: Update TOX_CONSTRAINTS_FILE for stable/xena https://review.opendev.org/c/openstack/neutron-lib/+/808230 | 14:31 |
| opendevreview | OpenStack Release Bot proposed openstack/neutron-lib master: Update master for stable/xena https://review.opendev.org/c/openstack/neutron-lib/+/808234 | 14:31 |
| opendevreview | OpenStack Release Bot proposed openstack/neutron-lib master: Add Python3 yoga unit tests https://review.opendev.org/c/openstack/neutron-lib/+/808236 | 14:31 |
| opendevreview | OpenStack Release Bot proposed openstack/os-ken stable/xena: Update .gitreview for stable/xena https://review.opendev.org/c/openstack/os-ken/+/808251 | 14:32 |
| opendevreview | OpenStack Release Bot proposed openstack/os-ken stable/xena: Update TOX_CONSTRAINTS_FILE for stable/xena https://review.opendev.org/c/openstack/os-ken/+/808254 | 14:32 |
| opendevreview | OpenStack Release Bot proposed openstack/os-ken master: Update master for stable/xena https://review.opendev.org/c/openstack/os-ken/+/808255 | 14:32 |
| opendevreview | OpenStack Release Bot proposed openstack/os-ken master: Add Python3 yoga unit tests https://review.opendev.org/c/openstack/os-ken/+/808256 | 14:32 |
| opendevreview | OpenStack Release Bot proposed openstack/ovsdbapp stable/xena: Update .gitreview for stable/xena https://review.opendev.org/c/openstack/ovsdbapp/+/808269 | 14:32 |
| opendevreview | OpenStack Release Bot proposed openstack/ovsdbapp stable/xena: Update TOX_CONSTRAINTS_FILE for stable/xena https://review.opendev.org/c/openstack/ovsdbapp/+/808273 | 14:32 |
| opendevreview | OpenStack Release Bot proposed openstack/ovsdbapp master: Update master for stable/xena https://review.opendev.org/c/openstack/ovsdbapp/+/808276 | 14:32 |
| opendevreview | OpenStack Release Bot proposed openstack/ovsdbapp master: Add Python3 yoga unit tests https://review.opendev.org/c/openstack/ovsdbapp/+/808278 | 14:32 |
| lajoskatona | agree, it's not something that is a must in the upstream CI | 14:32 |
| opendevreview | OpenStack Release Bot proposed openstack/python-neutronclient stable/xena: Update .gitreview for stable/xena https://review.opendev.org/c/openstack/python-neutronclient/+/808304 | 14:33 |
| slaweq | are we ready to vote on this one? | 14:33 |
| mlavalle | -1 | 14:33 |
| slaweq | I'm -1 for that rfe | 14:33 |
| ralonsoh | -1 | 14:33 |
| haleyb | -1 | 14:33 |
| lajoskatona | -1 | 14:33 |
| slaweq | thx | 14:33 |
| opendevreview | OpenStack Release Bot proposed openstack/python-neutronclient stable/xena: Update TOX_CONSTRAINTS_FILE for stable/xena https://review.opendev.org/c/openstack/python-neutronclient/+/808323 | 14:33 |
| opendevreview | OpenStack Release Bot proposed openstack/python-neutronclient master: Update master for stable/xena https://review.opendev.org/c/openstack/python-neutronclient/+/808324 | 14:33 |
| opendevreview | OpenStack Release Bot proposed openstack/python-neutronclient master: Add Python3 yoga unit tests https://review.opendev.org/c/openstack/python-neutronclient/+/808325 | 14:33 |
| slaweq | I will mark it as declined after the meeting | 14:33 |
| slaweq | let's move on to the next one | 14:34 |
| slaweq | https://bugs.launchpad.net/neutron/+bug/1916428 | 14:34 |
| slaweq | this is also old one | 14:34 |
| lajoskatona | not even a year old :-) | 14:34 |
| slaweq | and tbh I'm not even sure if we should treat it as new rfe | 14:34 |
| ralonsoh | this is a hard nut to crack | 14:34 |
| slaweq | it's not about new feature but new driver for the PD | 14:35 |
| slaweq | so in general I'm totally fine with new driver, especially as dibbler client is not maintained anymore | 14:35 |
| haleyb | yes, having a second driver would be perfect | 14:36 |
| slaweq | so my only concern is about what driver should it be | 14:37 |
| slaweq | I don't know that software too much but I saw that lajoskatona did some research there | 14:37 |
| lajoskatona | yeah I just checked how we use dibbler today and if we can have similar for kea | 14:38 |
| lajoskatona | as I remember we use external scripts and there something similar called hooks in kea | 14:39 |
| mlavalle | has the license issue you raised in the RFE been sorted out? | 14:40 |
| lajoskatona | and another question is that kea has many features but for neutron we need on pd, and another is to have package support, and for ubuntu20 the hook supporting version is not included | 14:40 |
| lajoskatona | mlavalle: nope, for that we have to ask | 14:41 |
| lajoskatona | I suppose openstack has somebody who has experience with these legal things | 14:41 |
| slaweq | I agree that we should choose wisely the backend software for which we will have new driver | 14:43 |
| opendevreview | Merged openstack/neutron-lib master: Add API shim extension "quota-check-limit" https://review.opendev.org/c/openstack/neutron-lib/+/807876 | 14:44 |
| slaweq | but TBH for me RFE is about "having new driver" and in that sense I'm ok with approving it | 14:44 |
| slaweq | wdyt? | 14:44 |
| ralonsoh | +1, we need it | 14:44 |
| lajoskatona | +1 | 14:44 |
| mlavalle | well, if we don't fix it, it will come back and bite us eventually, so yeah, +1 | 14:44 |
| haleyb | +1 | 14:45 |
| slaweq | actually if we will not have any new driver we will need to drop support for PD at some point probably | 14:45 |
| slaweq | ok, thx for voting | 14:45 |
| slaweq | I will mark rfe as approved and we can continue discussion there to choose proper backend software for which driver we will want to have | 14:46 |
| slaweq | ok, last one for today | 14:46 |
| slaweq | https://bugs.launchpad.net/neutron/+bug/1870319 | 14:46 |
| slaweq | this is also something old :) | 14:46 |
| slaweq | (I did some cleaning for lajoskatona :)) | 14:47 |
| lajoskatona | slaweq: thanks | 14:47 |
| slaweq | It's on me but I didn't had time for it earlier | 14:47 |
| slaweq | basically it came from the Kuryr team who would like to have such feature | 14:47 |
| slaweq | as for amotoki's questions I don't think that bulk port deletion would solve the issue completly for them | 14:48 |
| slaweq | but in fact it can be step to accomplish final goal which is cascade network deletion | 14:48 |
| ralonsoh | as you commented in the bug in c#3. "what response should be in case of partial failure?" | 14:49 |
| slaweq | ralonsoh that's good question | 14:49 |
| ralonsoh | because it is easy to retrieve the ports to be deleted | 14:49 |
| ralonsoh | and send the bulk port deletion | 14:49 |
| slaweq | I spent recently some time reading about it and there is no one straight way for that | 14:49 |
| slaweq | I asked e.g. how Octavia is doing it but their API is asynchronous | 14:50 |
| slaweq | so if used do "loadbalancer delete --cascade" it will return 204 immediately | 14:50 |
| slaweq | and then will start processing deletion of resources | 14:50 |
| ralonsoh | that's not the problem I think having bulk port deletion | 14:50 |
| slaweq | so user will need to periodically check if all is deleted already | 14:50 |
| ralonsoh | for example, in a heat stack you track the resources created and deleted | 14:51 |
| slaweq | ralonsoh, actually for bulk port deletion it would be similar thing | 14:51 |
| ralonsoh | and you can set this stack as failed or something similar | 14:51 |
| slaweq | what if some ports will be deleted and others not? | 14:51 |
| ralonsoh | right so there should be a detailed output at the end of the command | 14:52 |
| ralonsoh | in case of error, of course | 14:52 |
| slaweq | in case of bulk deletion we can return 207 Multistatus | 14:52 |
| slaweq | https://httpstatuses.com/207 | 14:52 |
| slaweq | and details about each port in the body | 14:53 |
| ralonsoh | right | 14:53 |
| slaweq | maybe for cascade network deletion we can do similar | 14:53 |
| slaweq | 207 Multi status | 14:53 |
| slaweq | and then in body something like | 14:53 |
| slaweq | [{"resource": "port", "id": ....", "status": 204}, {....}] | 14:54 |
| ralonsoh | hmm well, I don't think we should use a 200 return status | 14:54 |
| slaweq | so we would have everything detailed in the body | 14:54 |
| ralonsoh | ok: "Further elements contain 200, 300, 400, and 500 series status codes generated during the method invocation" | 14:55 |
| slaweq | but I would of course write a spec where we can discuss such details | 14:55 |
| ralonsoh | right | 14:55 |
| ralonsoh | that's something for the spec | 14:55 |
| obondarev | easiest thing is to just fail on first resource(port) delete failure saying: following port could not be deleted: "<reason>", right? | 14:55 |
| slaweq | that's also an option obondarev | 14:55 |
| slaweq | but then we will not return what actually was deleted before that port :) | 14:56 |
| obondarev | agree this is a discussion for the spec :) | 14:56 |
| obondarev | *I agree | 14:56 |
| mlavalle | I say approve the RFE and hash out the details in the spec | 14:57 |
| slaweq | thx mlavalle | 14:57 |
| slaweq | I will not vote on this one :) | 14:57 |
| ralonsoh | +1 for the RFE (and waiting for the spec) | 14:57 |
| lajoskatona | +1 | 14:58 |
| haleyb | +1 | 14:58 |
| slaweq | ok, thx | 14:58 |
| slaweq | so I will mark that as approved too | 14:58 |
| slaweq | and that's all from my side for this meeting | 14:59 |
| slaweq | next week our new chair will be lajoskatona :) | 14:59 |
| slaweq | thx a lot for this meeting and for all others so far | 14:59 |
| lajoskatona | \o/ | 14:59 |
| slaweq | that was really great for me to be chair of this meeting for about 2 years | 15:00 |
| slaweq | and we are on top of the hour now | 15:00 |
| mlavalle | o/ | 15:00 |
| obondarev | o/ | 15:00 |
| slaweq | have a great weekend and see You all next week | 15:00 |
| slaweq | o/ | 15:00 |
| ralonsoh | bye | 15:00 |
| slaweq | #endmeeting | 15:00 |
| opendevmeet | Meeting ended Fri Sep 10 15:00:36 2021 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 15:00 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/neutron_drivers/2021/neutron_drivers.2021-09-10-14.05.html | 15:00 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/neutron_drivers/2021/neutron_drivers.2021-09-10-14.05.txt | 15:00 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/neutron_drivers/2021/neutron_drivers.2021-09-10-14.05.log.html | 15:00 |
| lajoskatona | Bye | 15:00 |
| slaweq | obondarev ping https://review.opendev.org/c/openstack/neutron/+/808071 seems is stable | 15:08 |
| slaweq | can You maybe +W it? :) | 15:09 |
| slaweq | thx in advance | 15:09 |
| obondarev | slaweq: yep, sure | 15:10 |
| slaweq | obondarev thx a lot | 15:11 |
| os_user | hello guys | 15:15 |
| os_user | does the ovn driver (specifically in the interaction with the databases) have any known issues with hostnames containing a dot? as in "openstack.org" or "devstack.localdomain" | 15:16 |
| os_user | I deployed devstack with hostname "devstack.localdomain", and neutron complained in the logs that it "Failed to bind port..." | 15:17 |
| os_user | and earlier in the logs it said it couldn't find an OVN chassis for the host | 15:18 |
| os_user | I tried changing the hostname to just "devstack" | 15:18 |
| os_user | and it just worked | 15:18 |
| os_user | didn't change anything else, same local.conf, same everything | 15:18 |
| opendevreview | OpenStack Release Bot proposed openstack/os-vif stable/xena: Update .gitreview for stable/xena https://review.opendev.org/c/openstack/os-vif/+/808452 | 15:20 |
| opendevreview | OpenStack Release Bot proposed openstack/os-vif stable/xena: Update TOX_CONSTRAINTS_FILE for stable/xena https://review.opendev.org/c/openstack/os-vif/+/808453 | 15:20 |
| opendevreview | OpenStack Release Bot proposed openstack/os-vif master: Update master for stable/xena https://review.opendev.org/c/openstack/os-vif/+/808454 | 15:20 |
| opendevreview | OpenStack Release Bot proposed openstack/os-vif master: Add Python3 yoga unit tests https://review.opendev.org/c/openstack/os-vif/+/808455 | 15:20 |
| opendevreview | Ihar Hrachyshka proposed openstack/neutron master: ovn: use stateless NAT rules for FIPs https://review.opendev.org/c/openstack/neutron/+/804807 | 15:20 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: [OVN] Metadata ports device_owner is "network:distributed" only https://review.opendev.org/c/openstack/neutron/+/807707 | 15:41 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: [WIP] Do not use privsep daemon within DHCP agents https://review.opendev.org/c/openstack/neutron/+/808026 | 16:40 |
| slaweq | lbragstad gmann hi, if You will have few minutes, please check https://review.opendev.org/c/openstack/oslo.policy/+/804980 | 17:39 |
| slaweq | I added some UTs as You requested there. I hope it will be ok now :) | 17:39 |
| lbragstad | slaweq sounds good - i'll take a look | 17:39 |
| lbragstad | slaweq thank you for updating that | 17:39 |
| slaweq | lbragstad one thing worth to mention, I also need to do change in Neutron to actually be able to check scopes in case of those rules which inherits from BaseCheck | 17:40 |
| slaweq | lbragstad so if You will have time, please check also https://review.opendev.org/c/openstack/neutron/+/807559 | 17:41 |
| gmann | slaweq: lbragstad so basically Check object will be hacing scope_type ? | 17:43 |
| slaweq | gmann policy module will be checking it for Check objects but neutron needs to set scope_type for such rule | 17:44 |
| slaweq | as currently Neutron is not doing that so in such rule there is no scope_type defined at all | 17:44 |
| slaweq | please check https://review.opendev.org/c/openstack/neutron/+/807559 and You should understand it :) | 17:44 |
| gmann | slaweq: yeah, i got that. it was my expectation about use case when comemented on oslo.policy change but question is whether we want to add scope_type in _checks.BaseCheck obect or not ? | 17:45 |
| gmann | if yes then should we add it in base class itself and rule prepared directly from _checks.BaseCheck can set it in its definition itself ? | 17:46 |
| slaweq | gmann IMO it has to be there at least optionally for Neutron - otherwise we will not be able to enforce it for many our rules | 17:47 |
| gmann | yeah | 17:47 |
| slaweq | gmann neutron builds such rules dynamically: https://github.com/openstack/neutron/blob/master/neutron/policy.py#L167 | 17:47 |
| gmann | slaweq: yeah but as per lbragstad comment in this discussion we do not want to set scope_type in Checks objects https://review.opendev.org/c/openstack/oslo.policy/+/804980/1/oslo_policy/policy.py | 17:48 |
| slaweq | sorry, here https://github.com/openstack/neutron/blob/master/neutron/policy.py#L208 | 17:48 |
| slaweq | so should we change Neutron to create dynamically rules from RuleDefault class? | 17:50 |
| slaweq | instead of RuleCheck | 17:50 |
| slaweq | then patch in oslo_policy wouldn't be needed maybe | 17:50 |
| slaweq | gmann lbragstad anyway, please comment on those patches. I'm going offline now :) | 17:52 |
| slaweq | have a great weekend | 17:52 |
| gmann | slaweq: sure, I was ok with that but I will re-think on this and how we can more standardize the Checks object with scope_type | 17:53 |
| gmann | especially they reflect in documentation instead of doing it hardcoded way in code | 17:53 |
| gmann | slaweq: you too, | 17:57 |
| spatel | i am try to set --stateless security group but getting error, i may be doing something wrong so correct me please | 18:57 |
| spatel | openstack security group set --stateless my-sg | 18:57 |
| spatel | getting error - Unrecognized attribute(s) 'stateful' | 18:57 |
| spatel | I am running latest openstack so it should support | 18:58 |
| * haleyb thinks ^^ is a bug but doesn't see spatel around | 20:58 | |
| opendevreview | Corey Bryant proposed openstack/neutron-dynamic-routing master: DNM: Testing gate https://review.opendev.org/c/openstack/neutron-dynamic-routing/+/808518 | 21:08 |
| opendevreview | Terry Wilson proposed openstack/ovsdbapp master: Use setkey for DbSetCommand maps https://review.opendev.org/c/openstack/ovsdbapp/+/804252 | 21:37 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!