| gmann | slaweq: I am summarizing the RBAC goal progress for Yoga. If I am understanding correctly, neutron work is still in progress and not ready for operator to try? | 00:01 |
|---|---|---|
| gmann | https://review.opendev.org/c/openstack/neutron/+/821208 | 00:01 |
| opendevreview | ZhouHeng proposed openstack/neutron master: [test][unit]creating resources support set project_id https://review.opendev.org/c/openstack/neutron/+/834874 | 01:20 |
| opendevreview | Merged openstack/neutron-tempest-plugin master: CI: Fix typo for override-checkout and branch_override https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/835113 | 06:04 |
| opendevreview | liuyulong proposed openstack/neutron master: Add tag to port more earlier https://review.opendev.org/c/openstack/neutron/+/819567 | 08:39 |
| opendevreview | liuyulong proposed openstack/neutron master: Config option for link down/up ext gw port HA router in backup node https://review.opendev.org/c/openstack/neutron/+/834260 | 08:46 |
| opendevreview | Slawek Kaplonski proposed openstack/neutron master: Lower memory footprint in the functional tests job https://review.opendev.org/c/openstack/neutron/+/835179 | 08:49 |
| *** mgoddard- is now known as mgoddard | 09:11 | |
| slaweq | ralonsoh: lajoskatona obondarev hi, when You will have some time, please check https://review.opendev.org/c/openstack/neutron/+/826872 | 09:28 |
| ralonsoh | sure | 09:28 |
| slaweq | amotoki: and also You, if You can ^^ :) | 09:28 |
| slaweq | thx in advance | 09:28 |
| slaweq | ralonsoh lajoskatona obondarev and also https://review.opendev.org/c/openstack/neutron/+/834852 | 09:29 |
| opendevreview | Slawek Kaplonski proposed openstack/neutron-lib master: Rehome missing ovs constants into neutron-lib https://review.opendev.org/c/openstack/neutron-lib/+/834908 | 09:29 |
| bcafarel | ok stable/yoga is done for requirements https://review.opendev.org/c/openstack/releases/+/833610 we should have yoga CI soon :) | 09:30 |
| ralonsoh | slaweq, https://review.opendev.org/c/openstack/neutron/+/826872/3/neutron/policy.py | 09:39 |
| ralonsoh | small question, maybe I'm missing something | 09:39 |
| slaweq | sure | 09:39 |
| amotoki | slaweq: ack. looking at it now | 09:44 |
| slaweq | ralonsoh: I just replied to Your comment there | 09:45 |
| slaweq | amotoki: thx | 09:45 |
| ralonsoh | thanks | 09:46 |
| opendevreview | Merged openstack/ovn-octavia-provider master: Fix deletion of members without subnet_id https://review.opendev.org/c/openstack/ovn-octavia-provider/+/833799 | 09:59 |
| opendevreview | Merged openstack/ovn-octavia-provider stable/yoga: Retry logical switch associations to load balancers https://review.opendev.org/c/openstack/ovn-octavia-provider/+/833872 | 09:59 |
| amotoki | slaweq: I added a comment on InvalidScope from enforce(). could you check it? | 10:00 |
| opendevreview | Fernando Royo proposed openstack/ovn-octavia-provider stable/yoga: Fix deletion of members without subnet_id https://review.opendev.org/c/openstack/ovn-octavia-provider/+/835194 | 10:11 |
| opendevreview | Fernando Royo proposed openstack/ovn-octavia-provider stable/xena: Fix deletion of members without subnet_id https://review.opendev.org/c/openstack/ovn-octavia-provider/+/835195 | 10:13 |
| opendevreview | Fernando Royo proposed openstack/ovn-octavia-provider stable/wallaby: Fix deletion of members without subnet_id https://review.opendev.org/c/openstack/ovn-octavia-provider/+/835196 | 10:13 |
| opendevreview | Merged openstack/ovn-octavia-provider stable/wallaby: Retry logical switch associations to load balancers https://review.opendev.org/c/openstack/ovn-octavia-provider/+/833882 | 10:14 |
| opendevreview | Merged openstack/ovn-octavia-provider stable/victoria: Retry logical switch associations to load balancers https://review.opendev.org/c/openstack/ovn-octavia-provider/+/833884 | 10:14 |
| opendevreview | Merged openstack/ovn-octavia-provider stable/ussuri: Retry logical switch associations to load balancers https://review.opendev.org/c/openstack/ovn-octavia-provider/+/833995 | 10:14 |
| opendevreview | Fernando Royo proposed openstack/ovn-octavia-provider stable/victoria: Fix deletion of members without subnet_id https://review.opendev.org/c/openstack/ovn-octavia-provider/+/835198 | 10:25 |
| opendevreview | Fernando Royo proposed openstack/ovn-octavia-provider stable/ussuri: Fix deletion of members without subnet_id https://review.opendev.org/c/openstack/ovn-octavia-provider/+/835199 | 10:37 |
| opendevreview | Fernando Royo proposed openstack/ovn-octavia-provider stable/ussuri: Fix deletion of members without subnet_id https://review.opendev.org/c/openstack/ovn-octavia-provider/+/835204 | 10:59 |
| opendevreview | Slawek Kaplonski proposed openstack/neutron master: [API] Return 403 for POST requests when user is not authorized https://review.opendev.org/c/openstack/neutron/+/834171 | 11:27 |
| slaweq | amotoki lajoskatona ralonsoh if You have some time, please also check ^^ | 11:27 |
| slaweq | thx in advance | 11:27 |
| ralonsoh | sure | 11:28 |
| opendevreview | Slawek Kaplonski proposed openstack/neutron master: Lower memory footprint in the functional tests job https://review.opendev.org/c/openstack/neutron/+/835179 | 11:41 |
| opendevreview | Fernando Royo proposed openstack/ovn-octavia-provider stable/ussuri: Fix deletion of members without subnet_id https://review.opendev.org/c/openstack/ovn-octavia-provider/+/835204 | 11:49 |
| opendevreview | Merged openstack/networking-ovn stable/train: Retry logical switch associations to load balancers https://review.opendev.org/c/openstack/networking-ovn/+/834055 | 12:03 |
| opendevreview | Fernando Royo proposed openstack/ovn-octavia-provider stable/ussuri: Fix deletion of members without subnet_id https://review.opendev.org/c/openstack/ovn-octavia-provider/+/835204 | 12:07 |
| opendevreview | Merged openstack/ovn-octavia-provider stable/xena: Retry logical switch associations to load balancers https://review.opendev.org/c/openstack/ovn-octavia-provider/+/833885 | 12:15 |
| opendevreview | Fernando Royo proposed openstack/networking-ovn stable/train: Fix deletion of members without subnet_id https://review.opendev.org/c/openstack/networking-ovn/+/835216 | 12:44 |
| opendevreview | Merged openstack/neutron master: Add extra logs to the ip_monitor class https://review.opendev.org/c/openstack/neutron/+/833434 | 12:49 |
| lajoskatona1 | noonedeadpunk, trident, damiandabrowski[m]: Hi, can you attend from 14:00UTC the drivers meeting for the GARP issue? (https://wiki.openstack.org/wiki/Meetings/NeutronDrivers#Agenda ) | 13:03 |
| noonedeadpunk | yup, will be around! | 13:13 |
| lajoskatona1 | noonedeadpunk: ok, thanks | 13:14 |
| damiandabrowski[m] | i will also be there | 13:43 |
| opendevreview | Slawek Kaplonski proposed openstack/neutron master: Handle properly InvalidScope exceptions to not return error 500 https://review.opendev.org/c/openstack/neutron/+/826872 | 13:49 |
| trident | Me too... | 13:52 |
| opendevreview | Slawek Kaplonski proposed openstack/neutron-lib master: Add oslo_policy.InvalidScope exception to the api faults map https://review.opendev.org/c/openstack/neutron-lib/+/835234 | 13:52 |
| lajoskatona1 | #startmeeting neutron_drivers | 14:00 |
| opendevmeet | Meeting started Fri Mar 25 14:00:14 2022 UTC and is due to finish in 60 minutes. The chair is lajoskatona1. Information about MeetBot at http://wiki.debian.org/MeetBot. | 14:00 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 14:00 |
| opendevmeet | The meeting name has been set to 'neutron_drivers' | 14:00 |
| mlavalle | o/ | 14:00 |
| lajoskatona1 | o/ | 14:00 |
| yamamoto | hi | 14:00 |
| ralonsoh | hello | 14:00 |
| noonedeadpunk | o/ | 14:00 |
| trident | Hello | 14:00 |
| slaweq | o/ | 14:01 |
| damiandabrowski[m] | hi! | 14:01 |
| lajoskatona1 | So first topic for today (again :-))): | 14:02 |
| haleyb | hi | 14:02 |
| lajoskatona1 | Gratuitous ARPs are not sent during master transition: (#link https://bugs.launchpad.net/neutron/+bug/1952907) | 14:02 |
| lajoskatona1 | We have some patches (which I know about): | 14:02 |
| lajoskatona1 | #link https://review.opendev.org/c/openstack/neutron/+/821434 | 14:02 |
| lajoskatona1 | #link https://review.opendev.org/c/openstack/neutron/+/821433 | 14:02 |
| lajoskatona1 | #link https://review.opendev.org/c/openstack/neutron/+/712474 | 14:02 |
| lajoskatona1 | last time we discussed it damiandabrowski[m] and trident perhaps promised that they try to test the issue more | 14:03 |
| damiandabrowski[m] | yes, i spent some time on this | 14:04 |
| damiandabrowski[m] | in my bug report i mentioned that this bug may be already fixed by keepalived: https://github.com/acassen/keepalived/commit/72c4e54e9f2a9b5081814e549c47c7fc58b82df0 | 14:04 |
| damiandabrowski[m] | but AFAIK we don't use vmac interfaces so it's not relevant | 14:05 |
| damiandabrowski[m] | and what's most important: i think keepalived has nothing to do with it, as slaweq's bug report(the reason why we keep qg- interface down on backup routers) describes the problem pretty well | 14:07 |
| trident | To clarify, we originally thought that keepalived fix actually remedied https://review.opendev.org/c/openstack/neutron/+/707406 - which is what causes https://bugs.launchpad.net/neutron/+bug/1952907 | 14:07 |
| lajoskatona1 | damiandabrowski[m]: ok, so it seems that we need some code change on Neutron side? | 14:07 |
| damiandabrowski[m] | i think yes, https://bugs.launchpad.net/neutron/+bug/1859832 is slaweq's bugs report, the problem starts when neutron flushes link-local address on qg- interface, then interfaces sends multicast unsubscribe | 14:08 |
| trident | So as damiandabrowski[m] says, just reverting https://review.opendev.org/c/openstack/neutron/+/707406 won't be a solution as we initially thought. | 14:08 |
| damiandabrowski[m] | i'm not sure how we can fix this issue, but maybe we can do something else rather than just "flush link-local ip" | 14:09 |
| damiandabrowski[m] | or maybe we can prevent sending multicast unsubscribe packets, maybe with some sysctl parameters? | 14:09 |
| damiandabrowski[m] | i just think we need to think about better solution for this bug: https://bugs.launchpad.net/neutron/+bug/1859832 | 14:10 |
| damiandabrowski[m] | as the current solution(keeping qg- interfaces down on backup routers), solved one problem but created another one | 14:11 |
| slaweq | there was different solution for that bug https://review.opendev.org/c/openstack/neutron/+/702856/ | 14:11 |
| slaweq | but we decided to go with liu's patch which was simpler approach (only in L3 agent) | 14:11 |
| ralonsoh | just asking, none of the proposed patches/strategies are valid for you? | 14:12 |
| damiandabrowski[m] | it may be worth to consider https://review.opendev.org/c/openstack/neutron/+/702856/ as well | 14:12 |
| damiandabrowski[m] | solutions 2. and 3. from my bug report https://bugs.launchpad.net/neutron/+bug/1952907 should work fine(at least for ipv4, not sure about ipv6) | 14:13 |
| slaweq | in keepalived there is setting vrrp_garp_master_repeat - how about setting it to e.g. 2 or 3 seconds? | 14:13 |
| damiandabrowski[m] | but ideally, we would wan't to drop keepalived's dependency do neutron control plane during failovers | 14:13 |
| slaweq | so keepalived would try a bit later to send second set of GARPs | 14:13 |
| damiandabrowski[m] | it won't help, if keepalived won't send another GARPs if first one fails | 14:14 |
| damiandabrowski[m] | i tried using different keepalived options but couldn't get it working this way | 14:14 |
| damiandabrowski[m] | *it won't help, keepalived won't send another GARPs if first one fails | 14:14 |
| trident | To be honest I don't really like https://review.opendev.org/c/openstack/neutron/+/707406 ... The fact that it suddenly moves neutron into the failover scenario, which now requires neutron agents fully working and may take some additional time during failover as states have to be detected and ports brought up by neutron after a failover. If 500 routers fail over at the same time, that may actually be significant time compared to just a | 14:15 |
| trident | VRRP fail over. | 14:15 |
| slaweq | in the past we had such code in keepalived-state-change-monitor to send garps there | 14:15 |
| slaweq | but we removed it with https://review.opendev.org/c/openstack/neutron/+/752360 | 14:15 |
| ralonsoh | ^^ could be an option | 14:15 |
| damiandabrowski[m] | yes, one of my proposed solutons is to bring this eature back, but it's not ideal(i agree with @trindent): https://review.opendev.org/c/openstack/neutron/+/821433 | 14:16 |
| ralonsoh | right | 14:16 |
| slaweq | we removed that because we saw an issue when basically many garps send by many routers were killing openvswitch | 14:17 |
| slaweq | ralonsoh: probably remembers that issue well :) | 14:17 |
| ralonsoh | yes, with 200 virtual routers in one compute | 14:17 |
| ralonsoh | one controller | 14:17 |
| trident | I wonder if https://bugs.launchpad.net/neutron/+bug/1859832 could be solved by just filtering MLDv2 or if we could even disable IPv6 on the interface initially to not get a link local address before keepalived is started etc... | 14:18 |
| mlavalle | so in this scenario we need to keep neutron involved in the failover business | 14:18 |
| slaweq | if there would be way to disable sending garps by keepalived and do it only from neutron-keepalived-state-change or l3 agent, that would be IMO the best solution | 14:18 |
| ralonsoh | trident, I agree with investigating an option to just filter the "wrong" traffic. In this case MLDv2 packets | 14:19 |
| slaweq | trident: IIRC that MLDv2 issue couldn't be solved by disabling IPv6 on interface as when You enabled/disabled IPv6 those packets were sent immediately | 14:19 |
| ralonsoh | and reverting the patch to set the interfaces down | 14:19 |
| lajoskatona1 | slaweq: true, that is not dependent on 3rd party version | 14:19 |
| ralonsoh | but filtering the traffic? | 14:20 |
| slaweq | so the only option was to bring interfaces down or block them e.g in OVS (what patch https://review.opendev.org/c/openstack/neutron/+/702856/ proposed) | 14:20 |
| damiandabrowski[m] | i only wonder how keepalived(used outside the openstack) solves this issue, as basically it may be affected by the same issue when rebooting backup keepalived(but i don't have an answer for this ATM) | 14:21 |
| mlavalle | crazy idea... in damiandabrowski[m] original report he mentions "When I add random port to this router to trigger keepalived's reload, then all GARPs are sent properly". Can we force this in Neutron? | 14:21 |
| mlavalle | I mean the reload | 14:22 |
| slaweq | mlavalle: I don't see reason why, easier would be to revert https://review.opendev.org/c/openstack/neutron/+/752360 and send additional garps from neutron directly | 14:22 |
| lajoskatona1 | yeah I fear that is considered at a time as bug in keepalived.... | 14:22 |
| mlavalle | I said it was crazy idea... brainstorming | 14:23 |
| lajoskatona1 | mlavalle: +1 | 14:23 |
| trident | I do have a slight memory of seeing a proposed fix (that I think was abandoned) to that issue or some other similar issue which actually filtered the problematic traffic quite some time ago. I have however not been able to locate it. Does it ring any bells for anyone? | 14:23 |
| slaweq | :) | 14:23 |
| slaweq | trident: You mean https://review.opendev.org/c/openstack/neutron/+/702856/ ? | 14:24 |
| trident | slaweq: Nope, I think it was iptables or ebtables... | 14:24 |
| slaweq | trident: but we can't filter that traffic completly as it may break some IPv6 functionalities in the "master" router, no? | 14:25 |
| trident | slaweq: But we could instead of taking the interface down completely as we do today, apply filters and then instead of bringing the whole interface up, we could remove the filters. | 14:26 |
| slaweq | trident: You mean apply iptables fiters when router is going to be "backup" and then remove them when router is going to be "primary"? | 14:27 |
| slaweq | instead of doing "ip link set down" and "ip link set up" like we have now | 14:27 |
| trident | slaweq: Yes. Note that I have not done any testing on that idea though, I just thought of it an hour or so before this meeting. | 14:27 |
| slaweq | trident: I think that can work | 14:28 |
| slaweq | TBH I don't remember now why I was trying to block it in OVS not iptables | 14:28 |
| slaweq | maybe there was some reason for that or maybe it was just that I was somehow biased then :) | 14:28 |
| slaweq | IMO worth try | 14:29 |
| mlavalle | so we have two working hypothesis: 1) have neutron do the garps 2) apply and remove filters | 14:29 |
| mlavalle | is that a good summary? | 14:30 |
| lajoskatona1 | malavalle: thanks, thats my understanding too | 14:30 |
| slaweq | mlavalle: for 1) I would be ok with only if we can somehow disable garps in keepalived | 14:30 |
| slaweq | as we had issues with ovs when there was too much garps send | 14:30 |
| slaweq | so we should avoid that IMO | 14:30 |
| mlavalle | slaweq: yeah, that was my assumption. I just wanted to be brief in the summary | 14:30 |
| slaweq | ++ | 14:31 |
| ralonsoh | 2) can also solve frequent problems we have, at least in the CI, with race conditions when failing over | 14:31 |
| slaweq | ralonsoh: yeah, hopefully :) | 14:32 |
| mlavalle | so if we have to pick the most promising alternative, is 2) the one? | 14:32 |
| slaweq | so I would really give a try to the solution 2) first | 14:32 |
| lajoskatona1 | sounds good alternative | 14:33 |
| mlavalle | trident, damiandabrowski[m]: you ok with thi plan? will you propose a patch? | 14:33 |
| damiandabrowski[m] | or 3) do not engage neutron in keepalived's failover process at all? it's probably the best solution, but also the hardest one | 14:34 |
| damiandabrowski[m] | as if i understand correctly, 1) and 2) is still dependent from neutron | 14:34 |
| lajoskatona1 | yes, it's true | 14:35 |
| slaweq | damiandabrowski: I'm not sure if I understand correctly, can You elaborate on that one? | 14:35 |
| trident | I am afraid I might not be familiar enough with the code base to propose such a patch within reasonable time :/ I would however be most willing to help with testing! | 14:35 |
| mlavalle | separtion of concerns is always ideal... life is messy, though ;-) | 14:36 |
| damiandabrowski[m] | slaweq: because currently neutron is responsible for keeping interfaces up/down, with 1) neutron will send garps, with 2) neutron will be responsible for updating iptables rules | 14:37 |
| lajoskatona1 | noonedeadpunk: Do you have also some idea about the listed aproaches? | 14:37 |
| damiandabrowski[m] | it makes keepalived failover process fully dependent from neutron which is not ideal situation | 14:38 |
| damiandabrowski[m] | because technically, keepalived should be able to failover even when neutron is not functioning properly | 14:38 |
| noonedeadpunk | I'm not huge expert in code, but updating iptables sounds like an idea. Especially if that help out with race conditions in CI... | 14:38 |
| *** dasm|off is now known as dasm | 14:38 | |
| ralonsoh | damiandabrowski[m], you are right on this, but then keepalived should be able to block this traffic | 14:39 |
| lajoskatona1 | noonedeadpunk: thanks | 14:39 |
| mlavalle | so what you say is once the router is setup, it should function on its own regardlees of what happens to the neutron control plane | 14:39 |
| trident | ralonsoh: Which it probably _could_ not, as this if I understand it correctly happens before keepalived is even started? | 14:39 |
| trident | ralonsoh: When neutron flushes the link local address from the interface and adds it to keepalived config. | 14:39 |
| noonedeadpunk | but issue happens on router setup indeed? | 14:40 |
| noonedeadpunk | which kind of makes sense at least to me that neutron is responsible for setup of l3 | 14:40 |
| noonedeadpunk | but I guess then keepalived manages himself anyway? | 14:40 |
| damiandabrowski[m] | not exactly, the original issue(reported by slaweq) happens when You reboot backup keepalived | 14:41 |
| noonedeadpunk | ouch | 14:41 |
| noonedeadpunk | ok | 14:41 |
| trident | Hm, if we could make the filters apply only between "router startup" until keepalived has been started perhaps? As long as the link local address flush, addition to keepalived and start of keepalived happens while filter is applied it would be fine I guess. | 14:41 |
| ralonsoh | so block traffic only until keepalived is in charge | 14:42 |
| damiandabrowski[m] | ah, i think You're right | 14:43 |
| damiandabrowski[m] | so yeah, swapping https://review.opendev.org/c/openstack/neutron/+/707406/ with some 'iptables filtering solution' sounds like an idea for me | 14:44 |
| slaweq | I think that it is exactly what patch https://review.opendev.org/c/openstack/neutron/+/702856 was doing but with OVS instead of iptables rules | 14:44 |
| damiandabrowski[m] | slaweq: +1 | 14:45 |
| slaweq | but iptables filtering may be better here | 14:45 |
| trident | slaweq: With the difference that it will filter all traffic. | 14:46 |
| slaweq | trident: but only when router is created, not later during failover, right? | 14:47 |
| mlavalle | yes, afterwards we would let keepalioved do its job | 14:48 |
| slaweq | ++ | 14:48 |
| trident | slaweq: Oh, that might be true actually. In that case that might actually be a great solution! | 14:48 |
| mlavalle | ralonsoh put it very clearly: block traffic only until keepalived is in charge | 14:49 |
| lajoskatona1 | trident, damiandabrowski[m]: do you think that you can work on it? Or just testing? | 14:50 |
| damiandabrowski[m] | i can help with testing but i dont feel confident to write a patch :/ | 14:50 |
| ralonsoh | let me talk to my manager to see if we can spend time on this patch | 14:51 |
| lajoskatona1 | ralonsoh: thanks, I don't know how often we see effects of this in the CI | 14:52 |
| lajoskatona1 | so we can have few minutes during the PTG also if you think | 14:52 |
| ralonsoh | for sure (btw, I have good feedback so I'll take care of it) | 14:53 |
| mlavalle | ++ | 14:53 |
| slaweq | ralonsoh++ thx | 14:53 |
| lajoskatona1 | ok, as I see we have a plan, is that ok for everybody? | 14:53 |
| mlavalle | thanks | 14:53 |
| mlavalle | +1 | 14:53 |
| ralonsoh | +1 | 14:53 |
| trident | Great ralonsoh, thanks! I'll also be available for testing and review! | 14:53 |
| trident | +1 | 14:54 |
| damiandabrowski[m] | awesome, thanks for Your engagement everyone! | 14:54 |
| lajoskatona1 | yeah thanks everybody :-) | 14:54 |
| lajoskatona1 | Ok next topic: | 14:54 |
| lajoskatona1 | #topic On Demand Agenda | 14:54 |
| mlavalle | actually it's been a very enlightening conversation | 14:55 |
| lajoskatona1 | (ralonsoh): #link https://bugs.launchpad.net/neutron/+bug/1964575 | 14:55 |
| lajoskatona1 | mlavalle: I agree | 14:55 |
| ralonsoh | very quick: this is related to the sqlalchemy 2.0 migration | 14:55 |
| ralonsoh | the session transaction, in 2.0, will be created and never finished | 14:55 |
| ralonsoh | other side effect is that we don't have the implicit transaction creation, commit and deletion | 14:56 |
| ralonsoh | this is why it is a MUST to always we create a DB operation, to open a context (reader/writer) | 14:56 |
| ralonsoh | this is, in a nutshell, the summary | 14:56 |
| lajoskatona1 | ralonsoh: thanks | 14:56 |
| ralonsoh | that's all thansk | 14:57 |
| lajoskatona1 | this is the patch you mentioned on the wiki: https://review.opendev.org/c/openstack/neutron/+/833247 | 14:57 |
| ralonsoh | exactly | 14:57 |
| ralonsoh | and then we'll have the n-lib patch to set autocommit=False | 14:57 |
| ralonsoh | (that will enable the 2.0 feature) | 14:57 |
| mlavalle | cool | 14:57 |
| mlavalle | thank you | 14:58 |
| slaweq | ralonsoh: so another "migration to new engine facade" like story for couple of cycles? :) | 14:58 |
| ralonsoh | pfffff kind of !!! | 14:58 |
| lajoskatona1 | :-) | 14:58 |
| lajoskatona1 | ok so we will have topic for next cycles than :P | 14:58 |
| slaweq | lajoskatona1: yeah :) | 14:58 |
| mlavalle | lol | 14:59 |
| ralonsoh | I think so... we'll need keep an eye on this | 14:59 |
| lajoskatona1 | If nothing more for this I have 2 small topics | 14:59 |
| slaweq | shouldn't this be a community wide goal then? | 14:59 |
| slaweq | or only neutron is affected by that change? | 14:59 |
| ralonsoh | community (but this should be raise by oslo.db cores in TC) | 15:00 |
| ralonsoh | we'll have time for this | 15:00 |
| ralonsoh | lajoskatona1, please | 15:00 |
| lajoskatona1 | slaweq: I saw perhaps nova changes | 15:00 |
| lajoskatona1 | ralonsoh: ok ,thanks | 15:00 |
| lajoskatona1 | PTG etherpad: #link https://etherpad.opendev.org/p/neutron-zed-ptg | 15:00 |
| lajoskatona1 | please add your topics :-) | 15:00 |
| * mlavalle will be on PTO next week, so won't attend this meeting | 15:01 | |
| lajoskatona1 | mlavalle: the PTG? | 15:01 |
| lajoskatona1 | The other one is that there will be openinfra episode next week for cycle highlights | 15:02 |
| lajoskatona1 | there is a slideset: #link https://docs.google.com/presentation/d/1PhTzrIUo6kfCzdoPO5V3xgQCt6ktqGP3Q1y6BXMryzg/edit#slide=id.g11ee73f15e5_1_4 | 15:02 |
| lajoskatona1 | if you have time please check it I added few sentences for Neutron | 15:02 |
| mlavalle | I will attend the PTG on the week of april 4 - 8 | 15:02 |
| lajoskatona1 | mlavalle: ok | 15:03 |
| mlavalle | \I will just be on PTO this coming week | 15:03 |
| mlavalle | so if there is drivers meeting on 1st, I won't attend | 15:03 |
| lajoskatona1 | For next week I plane to cancel both the team meeting and the drivers meeting as the week after is the PTG | 15:03 |
| mlavalle | great | 15:03 |
| mlavalle | then nvm | 15:03 |
| lajoskatona1 | mlavalle: ok, thanks | 15:03 |
| lajoskatona1 | and that's it from me, thanks for attending | 15:03 |
| ralonsoh | thanks! | 15:04 |
| mlavalle | o/ | 15:04 |
| lajoskatona1 | #endmeeting | 15:04 |
| opendevmeet | Meeting ended Fri Mar 25 15:04:08 2022 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 15:04 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/neutron_drivers/2022/neutron_drivers.2022-03-25-14.00.html | 15:04 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/neutron_drivers/2022/neutron_drivers.2022-03-25-14.00.txt | 15:04 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/neutron_drivers/2022/neutron_drivers.2022-03-25-14.00.log.html | 15:04 |
| lajoskatona1 | o/ | 15:04 |
| slaweq | o/ | 15:04 |
| lajoskatona1 | and sorry for overtime.... | 15:04 |
| yamamoto | good night | 15:04 |
| slaweq | have a great weekend @all :) | 15:04 |
| lajoskatona1 | thanks the same to you | 15:05 |
| gmann | slaweq: ping for rbac goal status query. in case you missed my ms. | 15:20 |
| slaweq | gmann: I think I missed your message | 15:34 |
| slaweq | what query are You asking for? | 15:35 |
| gmann | slaweq: NP! | 15:35 |
| gmann | slaweq: I am summarizing the RBAC goal progress for Yoga. If I am understanding correctly, neutron work is still in progress and not ready for operator to try? | 15:35 |
| gmann | https://review.opendev.org/c/openstack/neutron/+/821208 | 15:35 |
| slaweq | gmann: we have some bugs there, like https://bugs.launchpad.net/neutron/+bug/1959333 | 15:37 |
| slaweq | but patches are in review currently | 15:37 |
| gmann | slaweq: ok, I will mark neutron as in-progress then. also will try to review these next week | 15:37 |
| slaweq | I know that devstack has job with those new defaults in neutron and that job is running fine IIRC | 15:37 |
| gmann | slaweq: ack | 15:38 |
| slaweq | the main part which we miss are neutron-tempest-plugin tests (or tempest) which would use new personas/scopes | 15:38 |
| gmann | slaweq: yeah, tempest tests can be migrated to new scope and defaults | 15:39 |
| slaweq | gmann: with some switch in config or something like that? | 15:39 |
| gmann | slaweq: plan is with switch but for stable branch. and for master it run on new default with scope | 15:40 |
| gmann | end goal is tempest/plugins tests start using new defaults | 15:40 |
| slaweq | ok | 15:40 |
| gmann | that might be lot of work which i am going to start for nova in zed | 15:41 |
| gmann | slaweq: anyways, I will check neutron changes next week, something we have done in nova and needs to be done in neutron too | 15:41 |
| slaweq | thx a lot | 15:41 |
| gmann | slaweq: thanks for updates, and have a good weekend. | 15:41 |
| slaweq | thx, You too | 15:44 |
| *** elvira4 is now known as elvira | 16:39 | |
| opendevreview | Jakub Libosvar proposed openstack/neutron master: ovn: Make ovn metadata agent report optional https://review.opendev.org/c/openstack/neutron/+/792998 | 17:26 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: [L3][QoS] L3 agent QoS extension to handle duplicated FIPs https://review.opendev.org/c/openstack/neutron/+/831238 | 17:28 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: [WIP][L3] QoS inherit network https://review.opendev.org/c/openstack/neutron/+/819147 | 17:28 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: [WIP][L3] QoS inherit network https://review.opendev.org/c/openstack/neutron/+/819147 | 17:37 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron-lib master: [WIP][DNM] Refactor session "is_active" handling for sqlalchemy-20 https://review.opendev.org/c/openstack/neutron-lib/+/828738 | 17:50 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron-lib master: [WIP][DNM] Refactor session "is_active" handling for sqlalchemy-20 https://review.opendev.org/c/openstack/neutron-lib/+/828738 | 17:52 |
| opendevreview | Merged openstack/neutron master: Fix some Openvswitch firewall doc typos https://review.opendev.org/c/openstack/neutron/+/835128 | 18:50 |
| opendevreview | Merged openstack/neutron master: ovn migration: Remove usage of tripleo-ansible-inventory https://review.opendev.org/c/openstack/neutron/+/834925 | 18:50 |
| opendevreview | Merged openstack/neutron master: [OVN] Reschedule router GW chassis when AZ updated https://review.opendev.org/c/openstack/neutron/+/825073 | 18:50 |
| opendevreview | Jakub Libosvar proposed openstack/neutron stable/yoga: ovn migration: Remove usage of tripleo-ansible-inventory https://review.opendev.org/c/openstack/neutron/+/835147 | 19:02 |
| opendevreview | Jakub Libosvar proposed openstack/neutron stable/xena: ovn migration: Remove usage of tripleo-ansible-inventory https://review.opendev.org/c/openstack/neutron/+/835148 | 19:02 |
| opendevreview | Jakub Libosvar proposed openstack/neutron stable/wallaby: ovn migration: Remove usage of tripleo-ansible-inventory https://review.opendev.org/c/openstack/neutron/+/835149 | 19:02 |
| *** dasm is now known as dasm|off | 19:14 | |
| opendevreview | Miguel Lavalle proposed openstack/python-neutronclient stable/wallaby: Dropping lower constraints testing (stable Wallaby) https://review.opendev.org/c/openstack/python-neutronclient/+/834976 | 21:51 |
| opendevreview | Miguel Lavalle proposed openstack/python-neutronclient stable/wallaby: tests: change safe_hasattr to hasattr https://review.opendev.org/c/openstack/python-neutronclient/+/834942 | 21:54 |
| opendevreview | Miguel Lavalle proposed openstack/python-neutronclient stable/wallaby: Use yaml.safe_load instead of yaml.load https://review.opendev.org/c/openstack/python-neutronclient/+/834930 | 21:55 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!