| *** Guest0 is now known as prometheanfire | 00:29 | |
| gthiemonge | Hi Folks, I have a bug in Octavia with neutron/ovn. In Octavia, we allocate an unplugged VIP port (to keep the VIP address) and each VM has another neutron port that has the VIP address in the allowed-address-pair list. | 07:32 |
|---|---|---|
| gthiemonge | the VIP port should be a "virtual" port in OVN, but the type of OVN port is incorrectly changed when we update the neutron port | 07:33 |
| gthiemonge | I have a reproduced here: https://paste.opendev.org/show/bmT8x4oK2vzUqHLVw6Np/ | 07:33 |
| gthiemonge | the vip port is "virtual" and after I update the security-group of the port, the virtual type disappears | 07:34 |
| gthiemonge | any ideas on this issue? | 07:34 |
| ralonsoh | gthiemonge, and the VIP is never bound to a VM, right? | 07:35 |
| gthiemonge | ralonsoh: yeah the port is DOWN, we use it to store/maintain the IP address | 07:36 |
| ralonsoh | gthiemonge, why do you update the SG of the VIP? | 07:36 |
| ralonsoh | does it matters? | 07:36 |
| ralonsoh | it shouldn't | 07:36 |
| ralonsoh | I mean, the SG rules should apply on the port with the allowed address pairs | 07:36 |
| gthiemonge | it shouldn't, I need to check why we're doing it :D | 07:36 |
| ralonsoh | but the VIP SG rules are irrelevant | 07:36 |
| ralonsoh | gthiemonge, you are right | 07:37 |
| ralonsoh | gthiemonge, please, open a LP bug | 07:37 |
| gthiemonge | ralonsoh: ok thanks | 07:37 |
| ralonsoh | slaweq, do you have 5 mins? | 07:37 |
| ralonsoh | I think I found something "not good" in HA and the router interfaces | 07:38 |
| ralonsoh | related to this SQLalchemy stuff | 07:38 |
| *** lajoskatona_ is now known as lajoskatona | 07:42 | |
| gthiemonge | ralonsoh: https://bugs.launchpad.net/neutron/+bug/1973276 | 07:51 |
| ralonsoh | gthiemonge, thanks | 07:51 |
| gthiemonge | don't hesitate to ping me if there's anything I can help with | 07:51 |
| ralonsoh | gthiemonge, this is not happening in master | 07:56 |
| ralonsoh | I can't reproduce it in master | 07:57 |
| slaweq | ralonsoh: yeah, I'm looking into that fullstack test right now | 08:11 |
| slaweq | do You want to talk maybe? | 08:11 |
| ralonsoh | slaweq, sure, give me 5 mins | 08:16 |
| slaweq | ralonsoh: sure | 08:18 |
| opendevreview | Merged openstack/neutron master: Update python testing as per zed cycle teting runtime https://review.opendev.org/c/openstack/neutron/+/841532 | 08:39 |
| opendevreview | yatin proposed openstack/neutron stable/train: [Train Only] Do not run grenade-skip-level job https://review.opendev.org/c/openstack/neutron/+/841698 | 09:17 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: [WIP][DNM] [OVN] Allow VIP ports with a defined "device_owner" https://review.opendev.org/c/openstack/neutron/+/841711 | 09:59 |
| opendevreview | Slawek Kaplonski proposed openstack/neutron master: [L3HA] Don't update HA router's ports if router isn't active on agents https://review.opendev.org/c/openstack/neutron/+/841712 | 10:00 |
| slaweq | ralonsoh: ^^ please check that patch | 10:00 |
| slaweq | I hope it will fix that fullstack test :) | 10:01 |
| ralonsoh | sure | 10:01 |
| slaweq | at least it did in my local lab | 10:01 |
| ralonsoh | slaweq, right, I think the code is correct | 10:02 |
| ralonsoh | let's wait for the CI | 10:02 |
| slaweq | yeag | 10:02 |
| slaweq | *yeah | 10:02 |
| ralonsoh | and, btw, probably we won't need to block n-lib 2.21.0 | 10:02 |
| ralonsoh | we'll see | 10:02 |
| slaweq | I hope so | 10:02 |
| ralonsoh | ok... | 10:02 |
| ralonsoh | it's done: the 2.21.0 patch is merged | 10:03 |
| ralonsoh | dammit | 10:03 |
| ralonsoh | https://review.opendev.org/c/openstack/requirements/+/841566 | 10:03 |
| ralonsoh | this is not good | 10:03 |
| ralonsoh | because now we can't check with the sqlalchemy 2.0 patch | 10:03 |
| ralonsoh | arggggggg | 10:03 |
| slaweq | so now we need revert that patch and make my patch depends on that revert, right? | 10:03 |
| ralonsoh | slaweq, I'll do it now | 10:04 |
| slaweq | thx | 10:04 |
| slaweq | submitted 10 minutes ago and now revert :) | 10:04 |
| ralonsoh | slaweq, https://review.opendev.org/c/openstack/requirements/+/841489 | 10:09 |
| ralonsoh | you can use this patch in the depends-on | 10:09 |
| lajoskatona | slaweq: Hi, the forum for the Berlin summit is rejected :-( | 10:11 |
| slaweq | lajoskatona: ohh, really? | 10:17 |
| slaweq | that's bad | 10:17 |
| lajoskatona | slaweq: agree | 10:18 |
| opendevreview | Slawek Kaplonski proposed openstack/neutron master: [L3HA] Don't update HA router's ports if router isn't active on agents https://review.opendev.org/c/openstack/neutron/+/841712 | 10:18 |
| opendevreview | Damian Dąbrowski proposed openstack/neutron master: [L3-HA] Always keep qg- port up, but with a few tweaks to avoid issues https://review.opendev.org/c/openstack/neutron/+/839671 | 10:52 |
| opendevreview | Merged openstack/neutron stable/ussuri: Fix setting table monitoring conditions https://review.opendev.org/c/openstack/neutron/+/840744 | 11:06 |
| lajoskatona | mnaser: Hi, please check this comment https://review.opendev.org/c/openstack/neutron-vpnaas/+/840330/5//COMMIT_MSG#26 | 11:20 |
| lajoskatona | mnaser: as I see that's blocking the vpnaas backports | 11:20 |
| opendevreview | Merged openstack/neutron-fwaas-dashboard master: Address RemovedInDjango40Warning https://review.opendev.org/c/openstack/neutron-fwaas-dashboard/+/839977 | 11:29 |
| noonedeadpunk | hey there. Has anybody was complaining on performance degradation of mysql queries after upgrade to X? | 12:21 |
| noonedeadpunk | s/has/was/ | 12:21 |
| noonedeadpunk | As basically we see a relatively slow subquery, that's being executed several times during single api call. Like for port list this https://paste.openstack.org/show/b01q2g07wM3SXLbrWImp/ will get executed 3 times independently, and each run would take like 10-15 sec. | 12:23 |
| noonedeadpunk | First to get allowedaddresspairs, then for extradhcpopts and ipallocations | 12:24 |
| slaweq | ralonsoh: good new, fullstack is green with my patch https://5e938628fc9e2dcb7a2d-22a46b7f7ce23fe9b2117d76fd7c738d.ssl.cf2.rackcdn.com/841712/2/check/neutron-fullstack-with-uwsgi/5ae1347/job-output.txt | 12:26 |
| slaweq | and it uses neutron-lib 2.21.0 :) | 12:26 |
| ralonsoh | slaweq, yeah!!! I'm going to recheck it | 12:40 |
| ralonsoh | just to test it again | 12:40 |
| slaweq | ++ | 12:41 |
| frickler | noonedeadpunk: seems ports.network_id isn't indexed on its own, making that query slow. not sure what changed though | 12:54 |
| ralonsoh | noonedeadpunk, do you know where in the code is done this query? | 12:56 |
| noonedeadpunk | ralonsoh: nope, not really :) Was just looking for it | 12:57 |
| ralonsoh | noonedeadpunk, and did you see a regression when installing X? | 12:58 |
| ralonsoh | or maybe this query was not before... | 12:58 |
| ralonsoh | ok, I'll try to find it | 12:58 |
| noonedeadpunk | So we haven't saw any slow queries before upgrade | 12:58 |
| noonedeadpunk | So either there was no such query, or it was running way faster | 12:59 |
| ralonsoh | noonedeadpunk, just for curiosity | 12:59 |
| ralonsoh | how do you measure this in your env? | 12:59 |
| noonedeadpunk | Another thing that changed with upgrade is sqlaclhemy... | 12:59 |
| noonedeadpunk | we were drawing graphs from monitoring regarding queries that take more then 10 seconds. And spotted that this subquery among raised other in slow log of mysql | 13:00 |
| ralonsoh | more than 10 secs? | 13:00 |
| ralonsoh | pfffff | 13:00 |
| noonedeadpunk | Well, port list was timouting with 60sec wait for connection on load balancer | 13:01 |
| noonedeadpunk | Interesting part, is that if running this as admin user - query isn't issued | 13:02 |
| ralonsoh | noonedeadpunk, please, report a launchpad bug, this is important | 13:02 |
| ralonsoh | I really want to have this info and address it asap | 13:02 |
| noonedeadpunk | So like `openstack port list` as a tenant takes 70 seconds and openstack port list --project <tenant> takes 6 | 13:03 |
| noonedeadpunk | Sure | 13:03 |
| noonedeadpunk | I was told that list of plugins isntalled is important here? Some other information to mention? | 13:03 |
| ralonsoh | yes, for example the backend used, the plugins (qos, trunk, etc) | 13:04 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: Create an index for "ports.network_id" https://review.opendev.org/c/openstack/neutron/+/841761 | 13:27 |
| lajoskatona | ralonsoh, noonedeadpunk: if QoS is enabled this can be a good candidate https://bugs.launchpad.net/neutron/+bug/1905726 | 13:28 |
| lajoskatona | ralonsoh, noonedeadpunk: hmmm, it was backported till train https://review.opendev.org/q/I1d0b3975ae6e92e34e9da20a0e26ce024422d332, so it shouldnt be theoretically | 13:29 |
| noonedeadpunk | Good idea but I guess qos is disabled... Need to double check | 13:29 |
| noonedeadpunk | Nope, it's disabled | 13:30 |
| noonedeadpunk | router vpnaas metering and bgp are there | 13:31 |
| ralonsoh | lajoskatona, the sql query is actually a problem | 13:32 |
| noonedeadpunk | I'm trying to succeed on executing prot list to paste output in bug report :) | 13:32 |
| ralonsoh | lajoskatona, https://review.opendev.org/c/openstack/neutron/+/841761 | 13:32 |
| ralonsoh | noonedeadpunk, ^ | 13:32 |
| lajoskatona | ralonsoh: thanks | 13:32 |
| ralonsoh | I've identified the method creating this query | 13:32 |
| noonedeadpunk | I think we can try this out | 13:35 |
| ralonsoh | just a heads-up: a DB change cannot be backported to stable releases | 13:36 |
| noonedeadpunk | yeah, I totally get that :) | 13:37 |
| noonedeadpunk | At least we can test this out in dev env | 13:38 |
| noonedeadpunk | I'm not sure it's the whole issue we see though | 13:38 |
| noonedeadpunk | https://bugs.launchpad.net/neutron/+bug/1973349 | 13:40 |
| noonedeadpunk | ralonsoh: ^ | 13:40 |
| ralonsoh | thanks | 13:40 |
| noonedeadpunk | What concerns me most, is why the hell that difference: https://paste.openstack.org/show/bROSFo0TpJGoLvsTcQ2L/ | 13:40 |
| noonedeadpunk | between admin/user call | 13:41 |
| ralonsoh | that could be a RBAC issue, but just thinking loud | 13:41 |
| opendevreview | Merged openstack/ovn-octavia-provider master: [OVN] Fix DuplicateOptionError on test scope https://review.opendev.org/c/openstack/ovn-octavia-provider/+/839083 | 13:48 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: Create an index for "ports.network_id" https://review.opendev.org/c/openstack/neutron/+/841761 | 13:49 |
| noonedeadpunk | btw, if pass &tenant_id=70b8361aacd9459097e706ba56206c7c to query it's twice faster... | 13:49 |
| noonedeadpunk | ralonsoh: well it appeared we already had network_id as index field in one of environments, and it's as slow as others | 13:53 |
| noonedeadpunk | Seems one day we tried to optimize that without result | 13:53 |
| ralonsoh | noonedeadpunk, did you change the neutron code? | 13:54 |
| noonedeadpunk | Nope, looks like jsut made an index manually | 13:54 |
| opendevreview | Sandeep Yadav proposed openstack/neutron stable/wallaby: Revert "Use Port_Binding up column to set Neutron port status" https://review.opendev.org/c/openstack/neutron/+/835340 | 14:00 |
| noonedeadpunk | WHile comparing envs trident just found that index was present one of them likely for quite a while | 14:00 |
| lajoskatona | #startmeeting neutron_drivers | 14:01 |
| opendevmeet | Meeting started Fri May 13 14:01:29 2022 UTC and is due to finish in 60 minutes. The chair is lajoskatona. Information about MeetBot at http://wiki.debian.org/MeetBot. | 14:01 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 14:01 |
| opendevmeet | The meeting name has been set to 'neutron_drivers' | 14:01 |
| mlavalle | o/ | 14:01 |
| lajoskatona | o/ | 14:01 |
| slaweq | o/ | 14:01 |
| mtomaska | o/ | 14:01 |
| haleyb | hi | 14:01 |
| *** dasm|off is now known as dasm | 14:01 | |
| amotoki | hi | 14:01 |
| ralonsoh | hi | 14:02 |
| lajoskatona | I think we can start | 14:03 |
| lajoskatona | We have one RFE for today and one more topic from ralonsoh | 14:03 |
| lajoskatona | [RFE][fwaas][OVN]support l3 firewall for ovn driver (#link https://bugs.launchpad.net/neutron/+bug/1971958) | 14:03 |
| damiandabrowski[m] | hi! | 14:03 |
| ralonsoh | (nice and complex RFE) | 14:04 |
| lajoskatona | this RFE is as I see is the official thing for why Inspur arrived to maintain neutron-fwaas | 14:04 |
| slaweq | yeah, IMO it should be straightforward as that's the reason why we revived neutron-fwaas mostly | 14:04 |
| lajoskatona | I am not sure if we have to ask a spec for this where details can be discussed or just let it flow ? | 14:05 |
| mlavalle | yes, the way I see this, is that we already approved this RFE | 14:05 |
| ralonsoh | I would ask, in the LP, for the goals in this RFE | 14:06 |
| ralonsoh | what are they expecting from fwaas in OVN | 14:06 |
| lajoskatona | ralonsoh: true that can be listed to have clear focus | 14:06 |
| mlavalle | +1 | 14:06 |
| amotoki | +1 | 14:07 |
| slaweq | maybe we should open Blueprint to track all of that work? | 14:07 |
| lajoskatona | yes we can I think | 14:07 |
| amotoki | i think a blueprint would be useful | 14:07 |
| mlavalle | +1 | 14:07 |
| lajoskatona | ok, so let's accept it with a blueprint to track progress, and ask details in LP bug for the exact goals | 14:08 |
| slaweq | +1 | 14:09 |
| amotoki | +1 | 14:09 |
| mlavalle | +1 | 14:09 |
| ralonsoh | +1 | 14:10 |
| haleyb | +1 | 14:10 |
| lajoskatona | thanks, let's move on | 14:10 |
| lajoskatona | #topic On Demand Agenda | 14:10 |
| lajoskatona | (ralonsoh): (added on 14/5/22) https://bugs.launchpad.net/neutron/+bug/1973049: with the SQLAlchemy 2.0 compatibility patch in place (n-lib 2.21.0), there are some issues when an API call (e.g.: user command) updates the same resource as another RPC call (agent call). This is very frequent with port status and FIP status. Sometimes (I still need to investigate the reason), the retry command detects that there is another SQ | 14:10 |
| lajoskatona | ansaction in progress (https://paste.opendev.org/show/beHzMCKjVLmE5nX0ZXZX/). | 14:10 |
| ralonsoh | thanks | 14:10 |
| lajoskatona | A long sentence | 14:10 |
| ralonsoh | summary: | 14:11 |
| ralonsoh | This is a recurrent problem in the Neutron server when updating a resource that has "standardattributes". If a concurrent update is done, the DB (SQLAlchemy) will return a "StaleDataError" exception. E.g.: [1] | 14:11 |
| ralonsoh | """ | 14:11 |
| ralonsoh | UPDATE statement on table 'standardattributes' expected to update 1 row(s); 0 were matched. | 14:11 |
| ralonsoh | """ | 14:11 |
| ralonsoh | that usually happens when a port or FIP is updated from two different agents | 14:11 |
| ralonsoh | or the RPC (agent) and API call (user) | 14:11 |
| slaweq | because of revision numbers, right? | 14:11 |
| ralonsoh | yes | 14:11 |
| lajoskatona | but we have this only since sqlalchemy 2.0 work ws merged? | 14:12 |
| ralonsoh | no no | 14:12 |
| ralonsoh | this is something that has been happening always | 14:12 |
| lajoskatona | ahh, ok ,thanks | 14:12 |
| mlavalle | it's a long standing thing | 14:12 |
| slaweq | I think it is also with older SQLAlchemy | 14:12 |
| ralonsoh | I'm not sure | 14:12 |
| ralonsoh | because this is related to the object mapper | 14:12 |
| ralonsoh | one sec | 14:12 |
| ralonsoh | __mapper_args__ = { | 14:13 |
| ralonsoh | # see http://docs.sqlalchemy.org/en/latest/orm/versioning.html for | 14:13 |
| ralonsoh | # details about how this works | 14:13 |
| ralonsoh | "version_id_col": id, | 14:13 |
| ralonsoh | (this is in neutron-lib) | 14:13 |
| ralonsoh | sqlalchemy will use (not ID, this is my change) "revision_number" as version_id_col | 14:13 |
| ralonsoh | my proposal: https://bugs.launchpad.net/neutron/+bug/1973049/comments/2 | 14:14 |
| slaweq | does your comment means that in case of such conflict, we will not have correct revision number for resource (it will be one less that it should be)? | 14:15 |
| slaweq | or am I misunderstanding something there? | 14:15 |
| ralonsoh | slaweq, we'll have the latest one updated | 14:16 |
| ralonsoh | but yes, it will be one less | 14:16 |
| mlavalle | why keep the revision number at all, then? | 14:16 |
| ralonsoh | in case of two commands | 14:16 |
| slaweq | so if e.g. 2 workers will want to update same port and each of them will try to bump revision number to let's say from 9 to 10, both will do updates of the port but revision number will be 10 instead of 11 finally, right? | 14:17 |
| ralonsoh | yes | 14:17 |
| slaweq | mlavalle: revision_numbers are pretty important e.g. for ovn driver | 14:17 |
| ralonsoh | mlavalle, this is something I would need to check | 14:17 |
| slaweq | but it's in api too so I'm not sure we can remove it really | 14:17 |
| ralonsoh | exactly... so this could be intrusive | 14:17 |
| slaweq | maybe other software, like e.g. heat relies on it, idk | 14:18 |
| lajoskatona | yes it can hit all clients I suppose | 14:18 |
| mlavalle | I wasn't proposing removing revision numbers | 14:18 |
| mlavalle | it was a rethroical question. Let me be more straight: | 14:18 |
| mlavalle | revision_numbers protect us from multiple updates taking place at once | 14:19 |
| mlavalle | isn't that true? | 14:19 |
| ralonsoh | not really | 14:19 |
| ralonsoh | well, it will prevent the DB from accepting the transaction | 14:20 |
| ralonsoh | it will rollback | 14:20 |
| slaweq | I'm not sure if we can do things like that, to e.g. not update revision number in some cases as this will break that described behaviour https://docs.openstack.org/api-ref/network/v2/#revisions IMO | 14:21 |
| lajoskatona | as I see it is like a poor man's transaction guard :-) you ask the resource check the rev number and update with it and if the server check is different for the number the operation fails | 14:21 |
| mlavalle | yeap | 14:22 |
| ralonsoh | this is only enabled with service revisions and version_check=True | 14:22 |
| ralonsoh | ok, I'll review this proposal again | 14:22 |
| ralonsoh | I won't spend more of your time | 14:22 |
| slaweq | can | 14:23 |
| slaweq | sorry | 14:23 |
| mlavalle | I think this revision number stuff was inspired by this: http://www.joinfu.com/2015/01/understanding-reservations-concurrency-locking-in-nova/ | 14:23 |
| mlavalle | originally | 14:23 |
| slaweq | can't we e.g use some distributed lock to lock resource which is going to be updated | 14:23 |
| slaweq | so that no other workers will try to update same resource in same time | 14:24 |
| ralonsoh | nonono, no distributed locks | 14:24 |
| ralonsoh | we have the DB for this | 14:24 |
| mlavalle | it's the compare and swap approach | 14:24 |
| ralonsoh | for reservations, we have our own engine | 14:24 |
| ralonsoh | with a new driver in place now | 14:24 |
| ralonsoh | no need for revisions | 14:24 |
| ralonsoh | but OVN does, so we need to be careful on this | 14:24 |
| obondarev | AFAIR rev numbers are needed for push notifications mechanism, for agent to be in sync with latest server updates | 14:25 |
| slaweq | also API uses it, so that client can use If-Match header to check revisions of resources | 14:25 |
| obondarev | (sorry for being late) | 14:25 |
| ralonsoh | obondarev, right, agents consume that number | 14:25 |
| ralonsoh | ok, I'm starting to think that this was a bad proposal... | 14:26 |
| ralonsoh | (thanks for the brain storming) | 14:26 |
| slaweq | ralonsoh: this is valid issue but IMO we have to keep revision numbers working as they are now and to be sure they are updated always | 14:27 |
| ralonsoh | exactly | 14:27 |
| lajoskatona | it was really enlighting | 14:29 |
| ralonsoh | for sure | 14:29 |
| ralonsoh | thank you all | 14:29 |
| mlavalle | Let's also look at previous commits, to remeber the history. For example: https://review.opendev.org/c/openstack/neutron/+/423581 | 14:29 |
| mlavalle | just read the commit messager | 14:30 |
| mlavalle | message^^^ | 14:30 |
| damiandabrowski[m] | sorry for interrupting but I need to leave in 5min | 14:30 |
| damiandabrowski[m] | I just want to say that today I removed WIP tag from https://review.opendev.org/c/openstack/neutron/+/839671 so please have a look if You can. I think it may be the best possible solution | 14:30 |
| ralonsoh | ok | 14:31 |
| slaweq | damiandabrowski: sure | 14:31 |
| lajoskatona | damiandabrowski[m]: thanks | 14:31 |
| damiandabrowski[m] | thank You! | 14:32 |
| lajoskatona | For https://bugs.launchpad.net/neutron/+bug/1973049/ does anybody more comments? | 14:33 |
| slaweq | ralonsoh: one more question | 14:33 |
| ralonsoh | suer | 14:34 |
| ralonsoh | sure | 14:34 |
| slaweq | can't we maybe somehow do something like: | 14:34 |
| slaweq | UPDATE standardattributes SET revision_number = revision_number + 1 WHERE id = 42 | 14:34 |
| slaweq | instead of "get and update" like we do now? | 14:34 |
| ralonsoh | but this is the goal: update what you retrieve from the DB in this transaction | 14:35 |
| slaweq | wouldn't that solve the issue with those errors? | 14:35 |
| ralonsoh | nope, that will introduce more | 14:35 |
| ralonsoh | you are deleting the transactionality | 14:35 |
| slaweq | ok | 14:36 |
| slaweq | I was just thinking loud :) | 14:36 |
| slaweq | so there is no way to tell mysql "increase for me this number by 1"? | 14:37 |
| slaweq | and we need to do it in python? | 14:37 |
| mlavalle | ralonsoh: to be clear, I don't oppose any efforts to improve DB and it's performance. But before we mess with the revision number mechanism, let's go back to the history (blog, commits) and all remind ourselves what we are dealing with | 14:37 |
| mlavalle | so whatever change we make, we do it with our eyes wide open | 14:37 |
| mlavalle | that's all | 14:37 |
| lajoskatona | mlavalle: thanks | 14:39 |
| lajoskatona | if no more comments or questions... | 14:40 |
| lajoskatona | #endmeeting | 14:40 |
| opendevmeet | Meeting ended Fri May 13 14:40:41 2022 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 14:40 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/neutron_drivers/2022/neutron_drivers.2022-05-13-14.01.html | 14:40 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/neutron_drivers/2022/neutron_drivers.2022-05-13-14.01.txt | 14:40 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/neutron_drivers/2022/neutron_drivers.2022-05-13-14.01.log.html | 14:40 |
| ralonsoh | have a nice weekend! | 14:40 |
| mlavalle | o/ | 14:40 |
| slaweq | o/ | 14:40 |
| mtomaska | o/ | 14:40 |
| lajoskatona | Thanks for the discussion, have a nice weekend | 14:40 |
| amotoki | o/ | 14:40 |
| lajoskatona | o/ | 14:40 |
| mlavalle | have a nice weekend! | 14:40 |
| ralonsoh | and check https://review.opendev.org/c/openstack/neutron/+/841712 before leaving today! | 14:41 |
| slaweq | have a nice weekend @all! | 14:41 |
| obondarev | o/ | 14:41 |
| mlavalle | ralonsoh: thanks for today's proposal. Nice discussion | 14:45 |
| ralonsoh | mlavalle, yw | 14:45 |
| slaweq | ralonsoh: I'm just updating to address haleyb's comments ther | 14:50 |
| slaweq | should be ready in a minute | 14:50 |
| ralonsoh | perfect | 14:50 |
| * haleyb is assuming his comments were valid :) | 14:52 | |
| opendevreview | Slawek Kaplonski proposed openstack/neutron master: [L3HA] Don't update HA router's ports if router isn't active on agents https://review.opendev.org/c/openstack/neutron/+/841712 | 14:52 |
| slaweq | ralonsoh: haleyb ^^ done | 14:52 |
| ralonsoh | checking now | 14:53 |
| slaweq | thx | 14:54 |
| haleyb | slaweq: typo in log message, 'an any' -> 'on any' | 14:58 |
| *** ykarel_ is now known as ykarel | 15:05 | |
| opendevreview | Slawek Kaplonski proposed openstack/neutron master: [L3HA] Don't update HA router's ports if router isn't active on agents https://review.opendev.org/c/openstack/neutron/+/841712 | 15:05 |
| slaweq | haleyb: done ^^ :) | 15:06 |
| slaweq | have a nice weekend, I'm done for today | 15:06 |
| slaweq | :) | 15:06 |
| haleyb | you too! | 15:07 |
| lajoskatona | slaweq: just a sec, sorry.... | 15:07 |
| lajoskatona | slaweq: could you abandon this one: https://review.opendev.org/c/openstack/neutron/+/823292 ? | 15:07 |
| slaweq | lajoskatona: done | 15:08 |
| lajoskatona | slaweq: thanks | 15:08 |
| lajoskatona | mlavalle: Hi, could you help me out, it seems I cant abandon old pike patches in neutron-lbaas: | 15:11 |
| lajoskatona | mlavalle: https://review.opendev.org/q/project:openstack/neutron-lbaas+status:open+branch:stable/pike | 15:11 |
| lajoskatona | mlavalle: could you try it please, as I see you are in the neutron-release group and that perhaps has right for it | 15:11 |
| elodilles | mlavalle lajoskatona : sorry, i've done that meanwhile o:) | 15:16 |
| lajoskatona | elodilles: thanks | 15:17 |
| opendevreview | Terry Wilson proposed openstack/ovsdbapp stable/xena: Add cooperative_yield() to OvsdbIdl https://review.opendev.org/c/openstack/ovsdbapp/+/841738 | 15:54 |
| opendevreview | Terry Wilson proposed openstack/ovsdbapp stable/wallaby: Add cooperative_yield() to OvsdbIdl https://review.opendev.org/c/openstack/ovsdbapp/+/841739 | 15:54 |
| opendevreview | Terry Wilson proposed openstack/ovsdbapp stable/ussuri: Add cooperative_yield() to OvsdbIdl https://review.opendev.org/c/openstack/ovsdbapp/+/841740 | 15:55 |
| opendevreview | Terry Wilson proposed openstack/ovsdbapp stable/train: Add cooperative_yield() to OvsdbIdl https://review.opendev.org/c/openstack/ovsdbapp/+/841741 | 15:55 |
| opendevreview | sean mooney proposed openstack/os-vif stable/xena: Use TCP keepalives for ovsdb connections https://review.opendev.org/c/openstack/os-vif/+/841771 | 16:09 |
| opendevreview | sean mooney proposed openstack/os-vif stable/xena: only register tables used by os-vif https://review.opendev.org/c/openstack/os-vif/+/841772 | 16:09 |
| opendevreview | sean mooney proposed openstack/os-vif stable/wallaby: Use TCP keepalives for ovsdb connections https://review.opendev.org/c/openstack/os-vif/+/841773 | 16:10 |
| opendevreview | sean mooney proposed openstack/os-vif stable/wallaby: only register tables used by os-vif https://review.opendev.org/c/openstack/os-vif/+/841774 | 16:10 |
| opendevreview | sean mooney proposed openstack/os-vif stable/victoria: Use TCP keepalives for ovsdb connections https://review.opendev.org/c/openstack/os-vif/+/841775 | 16:13 |
| opendevreview | sean mooney proposed openstack/os-vif stable/victoria: only register tables used by os-vif https://review.opendev.org/c/openstack/os-vif/+/841776 | 16:13 |
| opendevreview | sean mooney proposed openstack/os-vif stable/ussuri: Use TCP keepalives for ovsdb connections https://review.opendev.org/c/openstack/os-vif/+/841777 | 16:13 |
| opendevreview | sean mooney proposed openstack/os-vif stable/ussuri: only register tables used by os-vif https://review.opendev.org/c/openstack/os-vif/+/841778 | 16:13 |
| opendevreview | Elvira García Ruiz proposed openstack/neutron master: [OVN] Log drop events per security group https://review.opendev.org/c/openstack/neutron/+/835014 | 16:14 |
| opendevreview | sean mooney proposed openstack/os-vif stable/train: Use TCP keepalives for ovsdb connections https://review.opendev.org/c/openstack/os-vif/+/841779 | 16:14 |
| opendevreview | sean mooney proposed openstack/os-vif stable/train: only register tables used by os-vif https://review.opendev.org/c/openstack/os-vif/+/841780 | 16:14 |
| mlavalle | lajoskatona: I think you've been taken care of | 16:28 |
| mlavalle | elodilles: thanks | 16:28 |
| *** gibi is now known as gibi_pto | 16:39 | |
| lajoskatona | mnaser: Hi, please check this comment https://review.opendev.org/c/openstack/neutron-vpnaas/+/840330/5//COMMIT_MSG#26 | 18:49 |
| lajoskatona | mnaser: as I see that's blocking the vpnaas backports | 18:49 |
| mnaser | lajoskatona: let me address that right away | 18:49 |
| opendevreview | Mohammed Naser proposed openstack/neutron-vpnaas stable/yoga: tests: fix functional tests https://review.opendev.org/c/openstack/neutron-vpnaas/+/840330 | 18:50 |
| opendevreview | Mohammed Naser proposed openstack/neutron-vpnaas stable/xena: tests: fix functional tests https://review.opendev.org/c/openstack/neutron-vpnaas/+/840331 | 18:52 |
| opendevreview | Mohammed Naser proposed openstack/neutron-vpnaas stable/victoria: tests: fix functional tests https://review.opendev.org/c/openstack/neutron-vpnaas/+/840333 | 18:52 |
| opendevreview | Mohammed Naser proposed openstack/neutron-vpnaas stable/wallaby: tests: fix functional tests https://review.opendev.org/c/openstack/neutron-vpnaas/+/840332 | 18:52 |
| mnaser | lajoskatona: should be ok now | 18:53 |
| lajoskatona | mnaser: thanks | 19:03 |
| opendevreview | Mohammed Naser proposed openstack/neutron-vpnaas master: Clean-up README file https://review.opendev.org/c/openstack/neutron-vpnaas/+/574679 | 19:04 |
| mnaser | cool, i'm going on the backlog of reviews and making some changes for those that need it to make them decent ot land | 19:04 |
| opendevreview | Mohammed Naser proposed openstack/neutron-vpnaas master: Clean-up README file https://review.opendev.org/c/openstack/neutron-vpnaas/+/574679 | 19:06 |
| mnaser | lajoskatona: https://review.opendev.org/c/openstack/neutron-vpnaas/+/822926 trivial cleanup here too | 19:13 |
| opendevreview | Merged openstack/neutron-vpnaas master: Drop install_venv https://review.opendev.org/c/openstack/neutron-vpnaas/+/809912 | 20:16 |
| opendevreview | Merged openstack/ovsdbapp stable/xena: Add cooperative_yield() to OvsdbIdl https://review.opendev.org/c/openstack/ovsdbapp/+/841738 | 20:26 |
| opendevreview | Merged openstack/ovsdbapp stable/ussuri: Add cooperative_yield() to OvsdbIdl https://review.opendev.org/c/openstack/ovsdbapp/+/841740 | 20:26 |
| opendevreview | Merged openstack/ovsdbapp stable/train: Add cooperative_yield() to OvsdbIdl https://review.opendev.org/c/openstack/ovsdbapp/+/841741 | 21:13 |
| *** dasm is now known as dasm|off | 21:18 | |
| opendevreview | Merged openstack/ovsdbapp stable/wallaby: Add cooperative_yield() to OvsdbIdl https://review.opendev.org/c/openstack/ovsdbapp/+/841739 | 21:29 |
| opendevreview | Jakub Libosvar proposed openstack/neutron master: ovn-migration: Remove second tripleo-update call https://review.opendev.org/c/openstack/neutron/+/841801 | 21:37 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!