| opendevreview | liuhuajie proposed openstack/neutron master: Refactor generate address pools by cidr https://review.opendev.org/c/openstack/neutron/+/862217 | 02:52 |
|---|---|---|
| opendevreview | Merged openstack/networking-odl master: Imported Translations from Zanata https://review.opendev.org/c/openstack/networking-odl/+/857997 | 07:17 |
| *** cstone5 is now known as cstone | 08:07 | |
| *** carloss_ is now known as carloss | 08:07 | |
| *** andrewbonney_ is now known as andrewbonney | 08:07 | |
| *** open10k8s_ is now known as open10k8s | 08:07 | |
| *** erbarr_ is now known as erbarr | 08:07 | |
| *** TheJulia_ is now known as TheJulia | 08:07 | |
| *** gouthamr_ is now known as gouthamr | 08:07 | |
| *** PrinzElvis_ is now known as PrinzElvis | 08:07 | |
| *** chateaulav_ is now known as chateaulav | 08:07 | |
| elodilles | ralonsoh: with lajoskatona we just checked the stable/wallaby state of neutron and we see that neutron (any maybe 1 or 2 other repo) could have a final release before the EM transition (see the patch: https://review.opendev.org/c/openstack/releases/+/862333 ) | 08:34 |
| elodilles | ralonsoh: does the neutron team plan a release for these? (next week is the transition deadline) | 08:34 |
| elodilles | ralonsoh: no worries if that is not planned as things can be consumed from EM branches (downstream) as well, though (but no upstream release is possible after the transition) | 08:36 |
| ralonsoh | elodilles, yes, I'm now checking this | 08:37 |
| ralonsoh | https://review.opendev.org/c/openstack/releases/+/677478/ | 08:37 |
| ralonsoh | to EOL up to Stein | 08:37 |
| ralonsoh | I'll push this patch today | 08:37 |
| elodilles | yepp, EOL'ing old stable branches. that's another story :) let me know if you need help | 08:38 |
| ralonsoh | elodilles, we didn't discuss about EM wallaby | 08:39 |
| ralonsoh | should we? | 08:39 |
| elodilles | ralonsoh: these 4 easy steps need to be followed: https://docs.openstack.org/project-team-guide/stable-branches.html#end-of-life | 08:39 |
| ralonsoh | elodilles, ok, I'll work on both issues, but first Wallaby | 08:40 |
| elodilles | for EOL | 08:40 |
| elodilles | for wallaby: | 08:40 |
| elodilles | https://lists.openstack.org/pipermail/openstack-discuss/2022-October/030937.html | 08:40 |
| ralonsoh | (this is all new for me) | 08:40 |
| elodilles | it's worth to follow the [release] and [ptl] tags on openstack-discuss to see these kind of things | 08:41 |
| ralonsoh | yeah, I know | 08:41 |
| elodilles | and don't worry, feel free to ask if you have any question :) | 08:42 |
| lajoskatona | ralonsoh: I am bad with these rules, but I can help :-) | 08:42 |
| ralonsoh | elodilles, that applies to other neutron related projects? | 08:42 |
| ralonsoh | fwaas, neutron-lib, etc? | 08:42 |
| ralonsoh | the wallaby EM? | 08:42 |
| elodilles | ralonsoh: all deliverables that are owned by neutron team | 08:43 |
| ralonsoh | understood | 08:43 |
| elodilles | so everything that is listed in the patch ( https://review.opendev.org/c/openstack/releases/+/862333 ) | 08:44 |
| ralonsoh | yeah, I had the same opened | 08:44 |
| ralonsoh | I'll update it now | 08:44 |
| elodilles | ralonsoh: don't need to update, if there are no new release | 08:45 |
| bcafarel | ltomasbo: froyo_ ^^ any backports you want to send for ovn-octavia-provider wallaby before EM? I just W+1 https://review.opendev.org/c/openstack/ovn-octavia-provider/+/862585 | 09:08 |
| froyo_ | bcafarel: on my side are all of them! thx | 09:09 |
| ltomasbo | bcafarel, I have one extra one I need | 09:10 |
| ltomasbo | bcafarel, this one: https://review.opendev.org/c/openstack/ovn-octavia-provider/+/860781 | 09:11 |
| bcafarel | ltomasbo: ack thanks I commented on releases patch https://review.opendev.org/c/openstack/releases/+/862333 | 09:13 |
| bcafarel | still doable to get it in before Nov 2 | 09:14 |
| ltomasbo | I'll trigger the cherry-pick right after the previous one gets merged | 09:15 |
| ltomasbo | should be doable, yes | 09:15 |
| ltomasbo | fingers crossed on the gates | 09:15 |
| bcafarel | :) | 09:15 |
| ralonsoh | ltomasbo, bcafarel I'll include those tags | 09:33 |
| opendevreview | Merged openstack/ovn-octavia-provider stable/xena: Optimization for find_ls_for_lr https://review.opendev.org/c/openstack/ovn-octavia-provider/+/862584 | 10:05 |
| ralonsoh | ltomasbo, https://review.opendev.org/c/openstack/releases/+/862333/1..2/deliverables/wallaby/ovn-octavia-provider.yaml | 10:10 |
| ralonsoh | is that ok? | 10:10 |
| ltomasbo | ralonsoh, I don't think so, I need to create the wallaby backport | 10:11 |
| ralonsoh | ltomasbo, I though you merged the patch... | 10:12 |
| ltomasbo | ralonsoh, but depends on the previous one... as soon as it merges, I'll create it | 10:12 |
| ralonsoh | ahhh ok | 10:12 |
| ralonsoh | no rush, I need to update the releases patch because of neutron | 10:12 |
| ralonsoh | ltomasbo, ping me once is done | 10:12 |
| ltomasbo | no no, we need to backport 2 (chained) patch sets... ones is on the merging gate at the moment, the other one is not even created as it depends on the previous noe | 10:12 |
| ltomasbo | ralonsoh, I'll do! | 10:12 |
| ralonsoh | elodilles, sorry, what does it mean? --> | 10:19 |
| ralonsoh | https://zuul.opendev.org/t/openstack/build/965bd96e6d2b471b8aedc1776308f3d1 | 10:19 |
| ralonsoh | do I need to create a new release for those hashes to be EM that have no version? | 10:20 |
| ralonsoh | lajoskatona, ^ maybe you happen to know this | 10:30 |
| elodilles | ralonsoh: the *-em tag only be applied towards a release | 10:30 |
| ralonsoh | elodilles, so can I add in the same patch a new release and the -em tag? | 10:30 |
| elodilles | ralonsoh: so it need to be the same hash as in the latest release | 10:30 |
| ralonsoh | or should I push first a patch to create these new releases? | 10:31 |
| elodilles | ralonsoh: in short: it needs a separate release patch | 10:31 |
| ralonsoh | perfect | 10:31 |
| ralonsoh | I'll do it | 10:31 |
| elodilles | thanks | 10:31 |
| lajoskatona | ralonsoh, elodilles: ok, I misunderstood this part also, push release patches for stadiums where need | 10:45 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: [WIP] Placement tunnelled networks https://review.opendev.org/c/openstack/neutron/+/860639 | 10:49 |
| opendevreview | Merged openstack/ovn-octavia-provider stable/wallaby: Optimization for find_ls_for_lr https://review.opendev.org/c/openstack/ovn-octavia-provider/+/862585 | 10:54 |
| opendevreview | Merged openstack/ovn-octavia-provider stable/victoria: Optimization for find_ls_for_lr https://review.opendev.org/c/openstack/ovn-octavia-provider/+/862586 | 10:55 |
| opendevreview | Merged openstack/ovn-octavia-provider stable/ussuri: Optimization for find_ls_for_lr https://review.opendev.org/c/openstack/ovn-octavia-provider/+/862357 | 10:55 |
| opendevreview | Merged openstack/neutron stable/wallaby: [OVN] Set the default OVN metadata worker number to 0 https://review.opendev.org/c/openstack/neutron/+/862712 | 11:02 |
| opendevreview | Merged openstack/neutron stable/xena: [OVN] Set the default OVN metadata worker number to 0 https://review.opendev.org/c/openstack/neutron/+/862711 | 11:02 |
| opendevreview | Merged openstack/neutron stable/yoga: [OVN] Set the default OVN metadata worker number to 0 https://review.opendev.org/c/openstack/neutron/+/862710 | 11:03 |
| opendevreview | Merged openstack/neutron stable/zed: [OVN] Set the default OVN metadata worker number to 0 https://review.opendev.org/c/openstack/neutron/+/862589 | 11:27 |
| opendevreview | Merged openstack/networking-ovn stable/train: Optimization for find_ls_for_lr https://review.opendev.org/c/openstack/networking-ovn/+/862358 | 11:32 |
| ralonsoh | ltomasbo, https://review.opendev.org/c/openstack/ovn-octavia-provider/+/862585 is that the last patch? | 11:35 |
| opendevreview | Merged openstack/ovn-octavia-provider stable/zed: Optimization for find_ls_for_lr https://review.opendev.org/c/openstack/ovn-octavia-provider/+/862582 | 12:01 |
| ltomasbo | ralonsoh, no... let me generate the right one | 12:24 |
| opendevreview | Luis Tomas Bolivar proposed openstack/ovn-octavia-provider stable/zed: Ensure OVN-LB is properly configured upon LS removal from LR https://review.opendev.org/c/openstack/ovn-octavia-provider/+/862581 | 12:31 |
| opendevreview | Luis Tomas Bolivar proposed openstack/ovn-octavia-provider stable/xena: Ensure OVN-LB is properly configured upon LS removal from LR https://review.opendev.org/c/openstack/ovn-octavia-provider/+/862890 | 12:33 |
| opendevreview | Luis Tomas Bolivar proposed openstack/ovn-octavia-provider stable/wallaby: Ensure OVN-LB is properly configured upon LS removal from LR https://review.opendev.org/c/openstack/ovn-octavia-provider/+/862891 | 12:34 |
| ltomasbo | bcafarel, ralonsoh: this is the patch to include for ovn-octavia: https://review.opendev.org/c/openstack/ovn-octavia-provider/+/862891 | 12:34 |
| opendevreview | Luis Tomas Bolivar proposed openstack/ovn-octavia-provider stable/victoria: Ensure OVN-LB is properly configured upon LS removal from LR https://review.opendev.org/c/openstack/ovn-octavia-provider/+/862892 | 12:34 |
| opendevreview | Luis Tomas Bolivar proposed openstack/ovn-octavia-provider stable/zed: Ensure OVN-LB is properly configured upon LS removal from LR https://review.opendev.org/c/openstack/ovn-octavia-provider/+/862581 | 12:47 |
| opendevreview | Luis Tomas Bolivar proposed openstack/ovn-octavia-provider stable/ussuri: Ensure OVN-LB is properly configured upon LS removal from LR https://review.opendev.org/c/openstack/ovn-octavia-provider/+/862362 | 12:48 |
| opendevreview | Luis Tomas Bolivar proposed openstack/networking-ovn stable/train: Ensure OVN-LB is properly configured upon LS removal from LR https://review.opendev.org/c/openstack/networking-ovn/+/862363 | 13:07 |
| opendevreview | Luis Tomas Bolivar proposed openstack/ovn-octavia-provider stable/yoga: Ensure OVN-LB is properly configured upon LS removal from LR https://review.opendev.org/c/openstack/ovn-octavia-provider/+/862364 | 13:15 |
| ralonsoh | #startmeeting neutron_drivers | 14:00 |
| opendevmeet | Meeting started Fri Oct 28 14:00:39 2022 UTC and is due to finish in 60 minutes. The chair is ralonsoh. 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 |
| ralonsoh | hello all | 14:00 |
| haleyb_ | hi | 14:00 |
| lajoskatona | Hi | 14:01 |
| njohnsto- | o/ | 14:01 |
| ralonsoh | I think we have quorum | 14:02 |
| ralonsoh | let's start | 14:02 |
| ralonsoh | #link https://bugs.launchpad.net/neutron/+bug/1994137 | 14:02 |
| *** njohnsto- is now known as njohnsto_ | 14:02 | |
| ralonsoh | [RFE] Specify the precedence of port routes if multiple ports attached to a VM | 14:02 |
| ralonsoh | there are many proposals for this RFE | 14:02 |
| ralonsoh | not incompatible between them | 14:02 |
| obondare_ | hi | 14:03 |
| *** haleyb_ is now known as haleyb | 14:03 | |
| *** obondare_ is now known as obondarev | 14:03 | |
| ralonsoh | the first one is adding the router metric into the cloud-init | 14:03 |
| ralonsoh | as commented by Sean | 14:03 |
| ralonsoh | but I don't know if we can provide this info via dnsmasq | 14:04 |
| ralonsoh | if we need this feature, then we'll need to use config drive | 14:04 |
| ralonsoh | (that's what I think) | 14:04 |
| ralonsoh | a second alternative (not incompatible with the other one): https://bugs.launchpad.net/neutron/+bug/1717560 | 14:05 |
| ralonsoh | to disable the subnet default route | 14:05 |
| ralonsoh | the dnsmasq won't provide the default GW, that means the kernel won't provide a default route for this subnet | 14:06 |
| lajoskatona | the above one is an old RFE, wasn't that implemented? | 14:06 |
| lajoskatona | or it was just forgotten? | 14:06 |
| ralonsoh | no, just abandoned | 14:06 |
| lajoskatona | ok | 14:06 |
| ralonsoh | that requires to set a dnsmasq option | 14:06 |
| ralonsoh | (let me find it again) | 14:07 |
| ralonsoh | dhcp-option=3 | 14:07 |
| ralonsoh | that disables the default route | 14:08 |
| ralonsoh | of course, that will be for any port on this subnet | 14:08 |
| ralonsoh | any opinion? | 14:09 |
| njohnsto_ | Just out of curiosity, how would it work in OVN without dnsmasq? | 14:10 |
| lajoskatona | if I understand well the first one to add metric to cloud init is more a workaround, or am I wrong? | 14:10 |
| ralonsoh | njohnsto_, no, that feature will need to be implemented in the internal dhcp server | 14:11 |
| obondarev | for the second option it says "API extension for a new 'default_route' attribute on the subnet resource" - can't this be for a port rather than subnet? | 14:12 |
| ralonsoh | lajoskatona, not really, if you add a metric, you can have multiple default routes with different metrics | 14:12 |
| ralonsoh | (not very useful) but works | 14:12 |
| ralonsoh | obondarev, that will depend on the DHCP service | 14:12 |
| obondarev | agree | 14:12 |
| lajoskatona | obondarev: that would overwrite the gateway on subnet? | 14:12 |
| ralonsoh | for dnsmasq, for example, this is for all ports in the subnet | 14:13 |
| ralonsoh | because this is a config in the service | 14:13 |
| ralonsoh | for OVN could be implemented independently (but just guessing, no idea) | 14:13 |
| obondarev | lajoskatona: I think it's more a flag rather than actual value | 14:13 |
| njohnsto_ | To me, passing the metric to cloud-unit seems like the best and least intrusive solution on first look | 14:14 |
| lajoskatona | obondarev: yeah, that's true | 14:14 |
| ralonsoh | njohnsto_, that implies not using dhcp service | 14:15 |
| mlavalle | should get more input from chateaulav? | 14:15 |
| mlavalle | (the person who brought this up in the pain points etherpad) | 14:16 |
| chateaulav | mlavalle: all for providing more info | 14:17 |
| mlavalle | good to see you here... | 14:18 |
| mlavalle | did you have an approach in mind when you brought this up? | 14:18 |
| lajoskatona | chateaulav: welcome :-) | 14:18 |
| chateaulav | always been here. just not a full-time openstack dev so always pulled 5 ways to the wind | 14:19 |
| mlavalle | or could you provide more detail? | 14:19 |
| chateaulav | lol | 14:19 |
| ralonsoh | chateaulav, so do you have an implementation in mind when you proposed this RFE? | 14:21 |
| ralonsoh | (am I connected?) | 14:22 |
| chateaulav | ``` | 14:22 |
| chateaulav | root@hack-the-power-de-ctf-dev-1-powerplant-sel351:~# ip route | 14:22 |
| chateaulav | default via 10.30.20.1 dev ens4 proto dhcp src 10.30.20.5 metric 100 | 14:22 |
| chateaulav | default via 192.168.20.1 dev ens3 proto dhcp src 192.168.20.113 metric 100 | 14:22 |
| chateaulav | 10.30.20.0/24 dev ens4 proto kernel scope link src 10.30.20.5 | 14:22 |
| lajoskatona | ralonsoh: yes | 14:22 |
| chateaulav | 169.254.169.254 via 10.30.20.1 dev ens4 proto dhcp src 10.30.20.5 metric 100 | 14:22 |
| chateaulav | 169.254.169.254 via 192.168.20.1 dev ens3 proto dhcp src 192.168.20.113 metric 100 | 14:22 |
| chateaulav | 192.168.20.0/24 dev ens3 proto kernel scope link src 192.168.20.113 | 14:22 |
| chateaulav | ``` | 14:22 |
| chateaulav | this is an example when both subnets have dhcp enabled. | 14:22 |
| chateaulav | i know we discussed the option of potentially passing through a route metric | 14:23 |
| chateaulav | mulitple df gw's arent bad, they just cant all be 100. and correct me if im wrong or missing something as far as being able to accomodate this now | 14:24 |
| ralonsoh | no, I can't create two default routes, using two different interfaces with the same metric | 14:26 |
| ralonsoh | but the goal is just the opposite, in any case | 14:27 |
| ralonsoh | how do you suggest to do this? via a config drive? | 14:27 |
| ralonsoh | hello? | 14:29 |
| mlavalle | we are all here | 14:29 |
| mlavalle | probabble chateaulav has a bad connection | 14:29 |
| lajoskatona | We can also ask for more details in the RFE, ot understand better the possibilities | 14:30 |
| ralonsoh | yes, that exactly what I was going to say | 14:30 |
| ralonsoh | I don't want you to spend more time on this | 14:31 |
| ralonsoh | I'll update the launchpad bug requesting more information | 14:31 |
| ralonsoh | if we have feedback, we'll continue with this | 14:31 |
| ralonsoh | of for you? | 14:31 |
| ralonsoh | ok for you? | 14:31 |
| mlavalle | yeap | 14:31 |
| lajoskatona | +1 | 14:32 |
| obondarev | +1 | 14:32 |
| mlavalle | +1 | 14:32 |
| haleyb | +1 | 14:32 |
| ralonsoh | ok, sorry for the lack of progress in this meeting, next time I'll try to have the owners of the requests before starting | 14:33 |
| ralonsoh | have a nice weekend, see you | 14:33 |
| obondarev | o/ | 14:33 |
| ralonsoh | #endmeeting | 14:33 |
| opendevmeet | Meeting ended Fri Oct 28 14:33:22 2022 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 14:33 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/neutron_drivers/2022/neutron_drivers.2022-10-28-14.00.html | 14:33 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/neutron_drivers/2022/neutron_drivers.2022-10-28-14.00.txt | 14:33 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/neutron_drivers/2022/neutron_drivers.2022-10-28-14.00.log.html | 14:33 |
| lajoskatona | See, you, have a nice weekend | 14:33 |
| mlavalle | o/ | 14:33 |
| lajoskatona | o/ | 14:33 |
| chateaulav | Sounds good | 14:35 |
| *** dasm|off is now known as dasm | 14:58 | |
| atmark | Hello, I have old openstack deployment running stable/ussuri. What's the correct order to remove FWaaS from a tenant? | 14:59 |
| atmark | I managed to get the FW group STATE and STATUS to down but I notice it's dropping incoming traffic. When I go to active router, I see this chain `neutron-l3-agent-fwaas-defau` | 15:01 |
| atmark | -A neutron-l3-agent-fwaas-defau -j neutron-l3-agent-dropped | 15:02 |
| opendevreview | Lajos Katona proposed openstack/networking-bagpipe stable/wallaby: Follow pyroute2 changes https://review.opendev.org/c/openstack/networking-bagpipe/+/862893 | 15:44 |
| opendevreview | Lajos Katona proposed openstack/networking-bagpipe stable/wallaby: Add required projects where necessary https://review.opendev.org/c/openstack/networking-bagpipe/+/862502 | 15:45 |
| opendevreview | Merged openstack/ovn-octavia-provider stable/xena: Ensure OVN-LB is properly configured upon LS removal from LR https://review.opendev.org/c/openstack/ovn-octavia-provider/+/862890 | 16:09 |
| opendevreview | Merged openstack/ovn-octavia-provider stable/wallaby: Ensure OVN-LB is properly configured upon LS removal from LR https://review.opendev.org/c/openstack/ovn-octavia-provider/+/862891 | 16:09 |
| opendevreview | Merged openstack/ovn-octavia-provider stable/victoria: Ensure OVN-LB is properly configured upon LS removal from LR https://review.opendev.org/c/openstack/ovn-octavia-provider/+/862892 | 16:09 |
| opendevreview | Merged openstack/ovn-octavia-provider stable/ussuri: Ensure OVN-LB is properly configured upon LS removal from LR https://review.opendev.org/c/openstack/ovn-octavia-provider/+/862362 | 16:22 |
| opendevreview | Merged openstack/ovn-octavia-provider stable/zed: Ensure OVN-LB is properly configured upon LS removal from LR https://review.opendev.org/c/openstack/ovn-octavia-provider/+/862581 | 16:22 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: [WIP] Placement tunnelled networks https://review.opendev.org/c/openstack/neutron/+/860639 | 16:38 |
| ralonsoh | elodilles, one qq about EOL: if there are new patches submitted between a EM branch and the current stable head, what should I do there? | 16:40 |
| ralonsoh | e.g.: in Neutron queens, between the EM hash and the queens current hash, there are some new patches | 16:40 |
| ralonsoh | ok, I see an example: https://review.opendev.org/c/openstack/releases/+/862520/1/deliverables/queens/nova.yaml | 16:42 |
| ralonsoh | I can just push the new hash in the tag EOL, without releasing a new branch | 16:42 |
| mnasiadka_ | Has something changed between Xena and Yoga? I use neutron-dhcp-agent with OVN for baremetal ports, and dhcp agents stopped working - Horizon/CLI can't list dhcp agents in network - the error is "No controller found for: dhcp-agents" | 17:09 |
| ralonsoh | mnasiadka_, please open a launchpad bug describing the issue you have | 17:56 |
| mnasiadka_ | ralonsoh: will do | 18:16 |
| elodilles | ralonsoh: yes, sorry, so: *-em tags are always shares the hash of the *latest release*, while *-eol tag should have the HEAD/tip of the branch, so as when the branch is deleted, the final state is not lost as it can be seen via checking out the *-eol tag | 18:27 |
| *** dasm is now known as dasm|off | 20:23 | |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!