| opendevreview | Merged openstack/neutron master: Exclude files from coverage check, improve overall result https://review.opendev.org/c/openstack/neutron/+/910968 | 00:47 |
|---|---|---|
| opendevreview | Liushy proposed openstack/neutron master: [OVN] Support address group for ovn driver https://review.opendev.org/c/openstack/neutron/+/851509 | 03:50 |
| opendevreview | Liushy proposed openstack/neutron master: [OVN] Support address group for ovn driver https://review.opendev.org/c/openstack/neutron/+/851509 | 07:11 |
| opendevreview | Liushy proposed openstack/neutron master: [OVN] Support address group for ovn driver https://review.opendev.org/c/openstack/neutron/+/851509 | 07:22 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: [FT] Group "functional.agent.l3" tests in the same executor https://review.opendev.org/c/openstack/neutron/+/911647 | 08:29 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: [OVN] Enable "ha" API flag for OVN routers https://review.opendev.org/c/openstack/neutron/+/910889 | 08:37 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: Add "subnet-external-network" extension to "subnet" resource https://review.opendev.org/c/openstack/neutron/+/907313 | 08:48 |
| ralonsoh | slaweq, Houston, I have a problem. I have a new extension to be added | 08:55 |
| ralonsoh | https://review.opendev.org/c/openstack/neutron/+/907313 | 08:55 |
| ralonsoh | and the n-t-p patch | 08:55 |
| ralonsoh | https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/911105 | 08:55 |
| ralonsoh | the problem is that both patches depend on each other | 08:56 |
| ralonsoh | if I push the neutron patch (alone), the "neutron_tempest_plugin.api.test_subnets.SubnetsSearchCriteriaTest" will fail (because the extension is not loaded yet in the n-t-p test) | 08:56 |
| slaweq | ralonsoh let me finish one thing and I will check those patches, ok? | 08:57 |
| ralonsoh | slaweq, sure, thanks a lot | 08:57 |
| *** mklejn_ is now known as mklejn | 09:00 | |
| frickler | ralonsoh: shouldn't the new test be skipped if the extension isn't loaded? | 09:15 |
| slaweq | frickler but it's not new tests which are failing | 09:16 |
| slaweq | and I don't really understand how neutron-tempest-plugin's patch may help with that | 09:17 |
| opendevreview | Frode Nordahl proposed openstack/neutron master: Add documentation for aa-l3-gw-multihoming https://review.opendev.org/c/openstack/neutron/+/899402 | 09:20 |
| ralonsoh | frickler, slaweq I think I know how to solve this: we need to enable the extension only if present | 09:25 |
| ralonsoh | this is why the neutron devstack neutron-**** service was created | 09:25 |
| ralonsoh | I'll push a new patch | 09:25 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: [FT] Group "functional.agent.l3" tests in the same executor https://review.opendev.org/c/openstack/neutron/+/911647 | 09:39 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron-tempest-plugin master: Add extension "subnet-external-network" https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/911105 | 09:42 |
| opendevreview | Liushy proposed openstack/neutron master: [OVN] Support address group for ovn driver https://review.opendev.org/c/openstack/neutron/+/851509 | 09:46 |
| slaweq | ralonsoh ykarel lajoskatona can You check https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/911445 when You will have time? | 09:56 |
| slaweq | thx in advance | 09:56 |
| slaweq | ralonsoh I already addressed Your comments there | 09:57 |
| slaweq | lajoskatona thx, I just noticed You already reviewed it :) | 09:58 |
| opendevreview | Merged openstack/os-ken unmaintained/wallaby: Update .gitreview for unmaintained/wallaby https://review.opendev.org/c/openstack/os-ken/+/911537 | 10:11 |
| *** fnordahl_ is now known as fnordahl | 10:13 | |
| opendevreview | Merged openstack/ovn-octavia-provider unmaintained/victoria: Update .gitreview for unmaintained/victoria https://review.opendev.org/c/openstack/ovn-octavia-provider/+/911514 | 10:14 |
| opendevreview | Merged openstack/networking-midonet unmaintained/victoria: Update .gitreview for unmaintained/victoria https://review.opendev.org/c/openstack/networking-midonet/+/911495 | 10:14 |
| opendevreview | Merged openstack/os-ken unmaintained/victoria: Update .gitreview for unmaintained/victoria https://review.opendev.org/c/openstack/os-ken/+/911512 | 10:16 |
| opendevreview | Fernando Royo proposed openstack/ovn-octavia-provider master: Ensure cr-lrp is assigned to a gateway chassis https://review.opendev.org/c/openstack/ovn-octavia-provider/+/911684 | 10:29 |
| opendevreview | Fernando Royo proposed openstack/ovn-octavia-provider master: Ensure cr-lrp is assigned to a gateway chassis https://review.opendev.org/c/openstack/ovn-octavia-provider/+/911684 | 10:29 |
| opendevreview | Jayce Houtman proposed openstack/neutron master: Change exception messages to error log messages for DNS integration. https://review.opendev.org/c/openstack/neutron/+/900212 | 10:57 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: [FT] Group "functional.agent.l3" tests in the same executor https://review.opendev.org/c/openstack/neutron/+/911647 | 10:58 |
| opendevreview | Jayce Houtman proposed openstack/neutron master: Change exception messages to error log messages for DNS integration. https://review.opendev.org/c/openstack/neutron/+/900212 | 11:00 |
| opendevreview | Jayce Houtman proposed openstack/neutron master: Change exception messages to error log messages for DNS integration. https://review.opendev.org/c/openstack/neutron/+/900212 | 11:08 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: [FT] Group "functional.agent.l3" tests in the same executor https://review.opendev.org/c/openstack/neutron/+/911647 | 11:23 |
| opendevreview | yatin proposed openstack/neutron unmaintained/yoga: [DNM] check yoga periodic jobs https://review.opendev.org/c/openstack/neutron/+/911699 | 12:01 |
| opendevreview | Fernando Royo proposed openstack/ovn-octavia-provider master: Fix check for a CR-LRP as a gateway port https://review.opendev.org/c/openstack/ovn-octavia-provider/+/911701 | 12:07 |
| noonedeadpunk | Hey folks. I was wondering, to which chassis in OVN FIP is designed to be assigned to when enable_distributed_floating_ip is False? | 12:07 |
| noonedeadpunk | As I do see it on compute both in NB and SB dbs | 12:07 |
| noonedeadpunk | there could be some changes lately ofc, I'm playing with some sort of Bobcat right now | 12:09 |
| ralonsoh | noonedeadpunk, https://docs.openstack.org/neutron/latest/admin/ovn/routing.html. Without DVR, the FIP traffic goes through the active chassis | 12:20 |
| ralonsoh | check the LRP gateway_chassis | 12:20 |
| noonedeadpunk | so fip has `options: {requested-chassis=os-compute02}` when I do `ovn-sbctl list Port_Binding` | 12:28 |
| noonedeadpunk | and same for `ovn-nbctl list Logical_Switch_Port` | 12:28 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: Add "subnet-external-network" extension to "subnet" resource https://review.opendev.org/c/openstack/neutron/+/907313 | 12:29 |
| noonedeadpunk | `gateway_chassis : []` | 12:29 |
| noonedeadpunk | in sb db | 12:29 |
| ralonsoh | requested-chassis is only used for live migrations | 12:31 |
| ralonsoh | as far as I know | 12:31 |
| opendevreview | Fernando Royo proposed openstack/ovn-octavia-provider master: Fix check for a CR-LRP as a gateway port https://review.opendev.org/c/openstack/ovn-octavia-provider/+/911701 | 12:31 |
| opendevreview | Merged openstack/neutron unmaintained/yoga: [OVN] Add ``subnetpool-prefix-ops`` extension to ML2/OVN mech driver https://review.opendev.org/c/openstack/neutron/+/908818 | 12:35 |
| noonedeadpunk | ralonsoh: well, I'm jsut checking on ovn-bgp and trying to understand how it "should" get chassis of the FIP | 12:43 |
| noonedeadpunk | as currently they indeed use requested-chassis from what I see | 12:43 |
| noonedeadpunk | or well | 12:45 |
| noonedeadpunk | on sb db chassis: 252cf809-ab9d-46d2-96e2-15c212b6628b and then ovn-sbctl list Chassis 252cf809-ab9d-46d2-96e2-15c212b6628b gives `hostname : os-compute02-az1.mh.citytest.se` | 12:46 |
| noonedeadpunk | so in sbdb it's still maps to compute. But actually, I would expect to find some binding in NB DB as well and either I'm looking in the wrong place... or it's not there... | 12:47 |
| noonedeadpunk | so I assume it passes throgh this logic: https://opendev.org/openstack/ovn-bgp-agent/src/branch/master/ovn_bgp_agent/drivers/openstack/watchers/base_watcher.py#L107-L109 | 12:50 |
| noonedeadpunk | ltomasbo: sorry, will ping you here as well :) | 12:51 |
| noonedeadpunk | as it feel that logic of the agent slightly falling apart for non-distributed FIPs. Or I just running too old neutron, which does not populate smth to ovn... | 12:51 |
| noonedeadpunk | but given ralonsoh saying that requested-chassis should not be source of truth for VIP chassis selection, but it feels like it is after all? | 12:52 |
| noonedeadpunk | ralonsoh: but do you know how/where I can check for the chassis if FIP in NB DB? Is there a way at all? | 13:01 |
| mnederlof | i am not sure ovn-bgp-agent is suited for non-distributed fips; fips are stored in nat table, and attached to a fip_port_id, you can lookup that port id in the logical_switch_port table | 13:03 |
| mnederlof | but that is in the case of distributed fip | 13:03 |
| mnederlof | the router ports can be found in logical-router-port table | 13:03 |
| mnederlof | if you have recent ovn version, you should have status column, that tells you which host is responsible for exposing the router port | 13:04 |
| mnederlof | in the nat table you will find a reference to the neutron:router_name too in the external_ids | 13:05 |
| mnederlof | and the nat entry is referenced from the logical-router entry as well | 13:06 |
| mnederlof | @noonedeadpunk ^^ | 13:06 |
| noonedeadpunk | I will check on that now, thanks! | 13:11 |
| mnederlof | out of curiosity, why not use the distributed fip feature? | 13:12 |
| noonedeadpunk | well, we want to limit amount of places where public connectivity is possible | 13:13 |
| noonedeadpunk | we eventually wanted air-gapped environment as much as possible | 13:14 |
| noonedeadpunk | meaning that exposing net nodes / gateways towards core routers is minimal thing | 13:14 |
| mnederlof | ok, interesting :) | 13:15 |
| noonedeadpunk | and then network folks want only very minimal list of bgp speakers | 13:17 |
| noonedeadpunk | and small network for announcements | 13:18 |
| mnederlof | i probably do not have to explain you this, but the node that are connected to public, are the bottlenecks of your traffic, and when ddos occurs, your failure domain (of ip´s that are unreachable) is quite big at that point. But still that is something you probably accepted in favor of the air-gap requirement :) | 13:19 |
| noonedeadpunk | yeah | 13:19 |
| noonedeadpunk | we're running OVS setup for years pretty much the same way | 13:20 |
| * frickler has the same requirements as noonedeadpunk, so likely not an uncommon setup | 13:20 | |
| noonedeadpunk | so there's some level of concervatism present as well | 13:20 |
| opendevreview | Liushy proposed openstack/neutron master: [OVN] Support address group for ovn driver https://review.opendev.org/c/openstack/neutron/+/851509 | 13:21 |
| mnederlof | oh definitely not uncommon, it was how neutron worked in the early days as well, until DVR / distributed FIP became a thing | 13:21 |
| noonedeadpunk | mnederlof: well... I mean... I did run namespaces on linuxbridges back in the days. which is kinda-kinda close to distributed FIP (not really, but still) | 13:25 |
| opendevreview | Merged openstack/neutron-tempest-plugin master: Remove usage of testscenarios and replace it with ddt library https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/911445 | 13:28 |
| mnederlof | xD | 13:34 |
| *** gthiemon1e is now known as gthiemonge | 13:36 | |
| noonedeadpunk | namespaces on linuxbridges on computes | 14:04 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron master: [FT] Group "functional.agent.l3" tests in the same executor https://review.opendev.org/c/openstack/neutron/+/911647 | 14:05 |
| opendevreview | Rodolfo Alonso proposed openstack/neutron-tempest-plugin master: Add extension "subnet-external-network" https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/911105 | 14:53 |
| opendevreview | Merged openstack/neutron-lib master: reno: Update master for unmaintained/xena https://review.opendev.org/c/openstack/neutron-lib/+/911555 | 15:14 |
| opendevreview | Merged openstack/os-ken master: reno: Update master for unmaintained/xena https://review.opendev.org/c/openstack/os-ken/+/911565 | 15:16 |
| opendevreview | Merged openstack/os-ken master: reno: Update master for unmaintained/wallaby https://review.opendev.org/c/openstack/os-ken/+/911538 | 15:16 |
| opendevreview | Merged openstack/os-ken master: reno: Update master for unmaintained/victoria https://review.opendev.org/c/openstack/os-ken/+/911513 | 15:16 |
| opendevreview | Merged openstack/ovsdbapp master: reno: Update master for unmaintained/xena https://review.opendev.org/c/openstack/ovsdbapp/+/911569 | 15:21 |
| opendevreview | Merged openstack/ovsdbapp master: reno: Update master for unmaintained/wallaby https://review.opendev.org/c/openstack/ovsdbapp/+/911542 | 15:21 |
| opendevreview | Merged openstack/ovsdbapp master: reno: Update master for unmaintained/victoria https://review.opendev.org/c/openstack/ovsdbapp/+/911517 | 15:23 |
| opendevreview | Merged openstack/neutron-vpnaas master: reno: Update master for unmaintained/xena https://review.opendev.org/c/openstack/neutron-vpnaas/+/911561 | 15:23 |
| ltomasbo | noonedeadpunk, sorry I was on a meeting and then having lunch | 15:25 |
| opendevreview | Merged openstack/neutron-lib master: reno: Update master for unmaintained/wallaby https://review.opendev.org/c/openstack/neutron-lib/+/911530 | 15:25 |
| opendevreview | Merged openstack/neutron-lib master: reno: Update master for unmaintained/victoria https://review.opendev.org/c/openstack/neutron-lib/+/911502 | 15:25 |
| opendevreview | Merged openstack/neutron-vpnaas master: reno: Update master for unmaintained/wallaby https://review.opendev.org/c/openstack/neutron-vpnaas/+/911534 | 15:26 |
| ltomasbo | noonedeadpunk, for VIPs (virtual IPs, different than FIPs), we were using information on the external-ids, as the requested chassis is not working for vips | 15:26 |
| ltomasbo | noonedeadpunk, so if neutron version is too old, perhaps it does not have the option to add that information on the external_ids | 15:27 |
| ltomasbo | noonedeadpunk, https://review.opendev.org/c/openstack/ovn-bgp-agent/+/883187 | 15:28 |
| ltomasbo | noonedeadpunk, this is the patch needed on neutron side: https://review.opendev.org/c/openstack/neutron/+/882705, it was backported up to wallaby | 15:29 |
| noonedeadpunk | ltomasbo: yeah, sorry, I indeed meant FIPs | 15:30 |
| ltomasbo | noonedeadpunk, ahh, ok, and you are using the NB driver, right? | 15:31 |
| noonedeadpunk | yep | 15:31 |
| noonedeadpunk | And eventually, this is using requested_chassis: https://opendev.org/openstack/ovn-bgp-agent/src/branch/master/ovn_bgp_agent/drivers/openstack/watchers/base_watcher.py#L107-L109 | 15:31 |
| noonedeadpunk | and requested_chassis is always compute there | 15:32 |
| opendevreview | Merged openstack/neutron-vpnaas master: reno: Update master for unmaintained/victoria https://review.opendev.org/c/openstack/neutron-vpnaas/+/911508 | 15:32 |
| noonedeadpunk | I was also on a meeting with our net folks who tried to explain me what we do want in fact:) | 15:32 |
| noonedeadpunk | and among exposing fips from net nodes, they also mentioned multiple VRFs for FRR configuration | 15:33 |
| noonedeadpunk | in order to be able to bring in external customer networks | 15:33 |
| ltomasbo | noonedeadpunk, the process was to detect the external_ids information on the logical router ports | 15:34 |
| noonedeadpunk | and we've briefly looked at EVPN implementation, but it seems there's only either-or case for the drivers? | 15:34 |
| ltomasbo | noonedeadpunk, so, it is using the information on the logical port where the fips is associated too | 15:34 |
| noonedeadpunk | um. so why I started digging in code as I got no signs of fip being even processed on action | 15:35 |
| ltomasbo | noonedeadpunk, it is not directly (NAT entries are not used) | 15:35 |
| ltomasbo | noonedeadpunk, we process logical router ports... and check that in the external_ids neutron has added/removed the FIP reference | 15:36 |
| noonedeadpunk | which lead me here https://opendev.org/openstack/ovn-bgp-agent/src/branch/master/ovn_bgp_agent/drivers/openstack/watchers/nb_bgp_watcher.py#L176-L180 | 15:36 |
| ltomasbo | noonedeadpunk, regarding evpn, mnederlof is working on a patch to add support for it: https://review.opendev.org/c/openstack/ovn-bgp-agent/+/906505 | 15:36 |
| noonedeadpunk | and eventually it should not pass the condition? | 15:36 |
| noonedeadpunk | oh! | 15:36 |
| opendevreview | OpenStack Release Bot proposed openstack/neutron-lib stable/2024.1: Update .gitreview for stable/2024.1 https://review.opendev.org/c/openstack/neutron-lib/+/911893 | 15:37 |
| opendevreview | OpenStack Release Bot proposed openstack/neutron-lib stable/2024.1: Update TOX_CONSTRAINTS_FILE for stable/2024.1 https://review.opendev.org/c/openstack/neutron-lib/+/911894 | 15:37 |
| opendevreview | OpenStack Release Bot proposed openstack/neutron-lib master: Update master for stable/2024.1 https://review.opendev.org/c/openstack/neutron-lib/+/911895 | 15:37 |
| ltomasbo | noonedeadpunk, the nb driver is newer than the sb driver... perhaps we missed the non-DVR in there | 15:37 |
| opendevreview | OpenStack Release Bot proposed openstack/os-ken stable/2024.1: Update .gitreview for stable/2024.1 https://review.opendev.org/c/openstack/os-ken/+/911896 | 15:37 |
| opendevreview | OpenStack Release Bot proposed openstack/os-ken stable/2024.1: Update TOX_CONSTRAINTS_FILE for stable/2024.1 https://review.opendev.org/c/openstack/os-ken/+/911897 | 15:37 |
| opendevreview | OpenStack Release Bot proposed openstack/os-ken master: Update master for stable/2024.1 https://review.opendev.org/c/openstack/os-ken/+/911898 | 15:37 |
| opendevreview | OpenStack Release Bot proposed openstack/ovsdbapp stable/2024.1: Update .gitreview for stable/2024.1 https://review.opendev.org/c/openstack/ovsdbapp/+/911899 | 15:38 |
| opendevreview | OpenStack Release Bot proposed openstack/ovsdbapp stable/2024.1: Update TOX_CONSTRAINTS_FILE for stable/2024.1 https://review.opendev.org/c/openstack/ovsdbapp/+/911900 | 15:38 |
| opendevreview | OpenStack Release Bot proposed openstack/ovsdbapp master: Update master for stable/2024.1 https://review.opendev.org/c/openstack/ovsdbapp/+/911901 | 15:38 |
| noonedeadpunk | ltomasbo: ok, sure, that's really a good lead | 15:38 |
| noonedeadpunk | I can check on sb code then and suggest a fix! | 15:38 |
| opendevreview | OpenStack Release Bot proposed openstack/python-neutronclient stable/2024.1: Update .gitreview for stable/2024.1 https://review.opendev.org/c/openstack/python-neutronclient/+/911902 | 15:38 |
| opendevreview | OpenStack Release Bot proposed openstack/python-neutronclient stable/2024.1: Update TOX_CONSTRAINTS_FILE for stable/2024.1 https://review.opendev.org/c/openstack/python-neutronclient/+/911903 | 15:38 |
| opendevreview | OpenStack Release Bot proposed openstack/python-neutronclient master: Update master for stable/2024.1 https://review.opendev.org/c/openstack/python-neutronclient/+/911904 | 15:39 |
| ltomasbo | noonedeadpunk, SB driver works for sure, as it is checking the nat addressed added on the cr-lrp port... so... it is taking the right chassis | 15:39 |
| ltomasbo | noonedeadpunk, please open a launchpad bug for this... I think it is indeed something we missed there | 15:39 |
| noonedeadpunk | yeah, but what I got nb is preffered? | 15:39 |
| noonedeadpunk | as sb should not be considered as source of truth? | 15:40 |
| ltomasbo | noonedeadpunk, yep, problem with the SB is that things can change in OVN and break us | 15:40 |
| ltomasbo | (as it already happen with LoadBalancers several times) | 15:40 |
| ltomasbo | noonedeadpunk, and all the new stuff is being done on top of NB DB driver | 15:40 |
| noonedeadpunk | yeah, fair. I'm just thinking if I should consider using SB for now as an option at all | 15:40 |
| noonedeadpunk | yeah, ok. | 15:41 |
| ltomasbo | so... yeah, we definitely should fix it on the NB DB is that is not working | 15:41 |
| ltomasbo | noonedeadpunk, if it has what you need... why not | 15:42 |
| ltomasbo | in your case you only need to run the ovn-bgp-agent in the networker/gateway nodes | 15:42 |
| noonedeadpunk | because of the reasons you've mentioned?:) | 15:42 |
| noonedeadpunk | yeah, this is what I'm really aiming for | 15:42 |
| noonedeadpunk | but also wanna use something future-proof a bit rather then deprecated legacy out of the box... | 15:43 |
| opendevreview | Liushy proposed openstack/neutron master: [OVN] Support address group for ovn driver https://review.opendev.org/c/openstack/neutron/+/851509 | 15:44 |
| spatel | Folks, does anything changed between zed and 2023.1 about policy.yaml ? because in Zed same policy working but in 2023.1 it doesn't | 15:44 |
| spatel | "delete_floatingip": "(rule:admin_only)" | 15:44 |
| spatel | does policy.yaml file required restart of neutron service? | 15:45 |
| ltomasbo | noonedeadpunk, for what is worth... SB was the base, but it is not deprecated (we actually support it), but the new stuff will get added to the NB DB I suppose | 15:46 |
| noonedeadpunk | iirc it should be loaded on-fly | 15:46 |
| ltomasbo | and... as mentioned... if NB has a bug... we should fix it! xD | 15:46 |
| noonedeadpunk | yeah, I'd rather focus on fixing it:) | 15:46 |
| ltomasbo | that is even better... if you not only report it, but also fix it! | 15:47 |
| noonedeadpunk | So. given our usecase of air-gapped environement as much as possible, and will for isolation between external networks, as some are going to be customer-only (private) ones, and others are shared - what exposure method I should be looking at - vrf or ovn is still on the table? | 15:49 |
| noonedeadpunk | yeah, I mean, I'm given some time to dig there and get us a working state | 15:49 |
| ltomasbo | noonedeadpunk, I may need more details... you have a BGP (l3) datacenter? I mean, why not using DVR is you have BGP? | 15:50 |
| ltomasbo | noonedeadpunk, and if you require evpn/vrf... then there is only one option, which is mnederlof patch | 15:51 |
| noonedeadpunk | we're building a new as-much-as-possible L3 datacenter | 15:52 |
| noonedeadpunk | reason for no DVR - is limit hosts that do have/process internet access as much as possible | 15:52 |
| noonedeadpunk | so we can't put all computes there for this reason | 15:52 |
| ltomasbo | noonedeadpunk, but then... why not having DVR? | 15:52 |
| noonedeadpunk | basically - no hosts are having access to the internet, though tenant VMs should | 15:53 |
| ltomasbo | but... internet access will go through the spine leaf, right? why not blocking it at a different point? instead of having the L3 infrastructure saturated in some spots? | 15:53 |
| noonedeadpunk | but hypervisors, controller nodes, etc are fully air-gapped | 15:53 |
| jrosser | ^ i am in the same sitation as noonedeadpunk and would follow almost identical model for my deployments when i come to do OVN fwiw | 15:54 |
| ltomasbo | noonedeadpunk, ok, I see | 15:54 |
| noonedeadpunk | exactly - all will go through spine leaf | 15:54 |
| ltomasbo | jrosser, also with ovn-bgp-agent?? | 15:54 |
| jrosser | i would need a solution for ipv6 tenant networks for sure | 15:55 |
| ltomasbo | noonedeadpunk, | 15:55 |
| ltomasbo | noonedeadpunk, so... you want to expose only FIPS or also tenant IPS? | 15:56 |
| jrosser | and i am also very interested in having multiple external networks in different VRF too | 15:56 |
| ltomasbo | noonedeadpunk, as the tenant IPs will already be exposed through the controllers/networkers | 15:56 |
| noonedeadpunk | I'm a bit confused right now about tenant IPs... I mean - I don't have full picture as it's not me who's desigining core networking. I need though to bring all things together:) | 15:57 |
| noonedeadpunk | but I think tenant IPs are east-west traffic? | 15:57 |
| noonedeadpunk | or you mean - "external" networks? | 15:57 |
| mnederlof | tenant ips are ips behind neutron router | 15:57 |
| ltomasbo | noonedeadpunk, those tenant IPs can also be BGP advertised, from the networker node | 15:58 |
| ltomasbo | then, from there it will go geneve tunnel to the node where the VM is | 15:58 |
| ltomasbo | but instead of exposing the FIP, you are exposing directly the IP of the VM in the tenant network( though you need to ensure it does not overlap) | 15:58 |
| ltomasbo | that is simpler with vrf support that mnederlof is adding | 15:59 |
| noonedeadpunk | yeah, ok, this non-overlaping of tenant networks was really confusing me | 15:59 |
| noonedeadpunk | to the point where I don't understand what is meant and what's the usecase | 15:59 |
| noonedeadpunk | I guess the usecase, is that you make an external shared network? | 15:59 |
| noonedeadpunk | so you don't need FIPs anymore and can attach external network directly? | 16:00 |
| ltomasbo | noonedeadpunk, the point is that you can expose newtork connected to the provider network | 16:00 |
| ltomasbo | it will go through an ovn router... thus it needs to be exposed on the networker node | 16:00 |
| ltomasbo | and the problem is that you need to avoid different tenant exposing the same CIDR | 16:00 |
| noonedeadpunk | yeah, I don't think I have that usecase | 16:00 |
| noonedeadpunk | as we totally have tenants with same cidrs as there's no way we can control it | 16:01 |
| ltomasbo | right | 16:01 |
| mnederlof | there is a way to control it though, you should check out address scopes and subnet pools | 16:01 |
| noonedeadpunk | or well. we might be having some networks that customers bring to us. They're currently implemented jsut as vlans | 16:01 |
| noonedeadpunk | and connect VMs with out-of-premise things | 16:02 |
| mnederlof | then you can only expose the tenant subnets that match a specific address scope | 16:02 |
| ltomasbo | still... there may be customer that need to use 10.0.0.0/24 for whatever reason... so | 16:02 |
| mnederlof | yeah, those just need to be separated with vni | 16:02 |
| noonedeadpunk | 10.0.0.0/8 I'd say. would be even more fun | 16:02 |
| mnederlof | and separate provnet | 16:02 |
| ltomasbo | I need to go, nice discussion! don't forget to file the bug, we'll try to figure out a solution for it, it may only affect fips | 16:02 |
| noonedeadpunk | ok, separate provnet is probably fair.... | 16:02 |
| noonedeadpunk | ltomasbo: thanks for your time as usual! | 16:03 |
| mnederlof | at least that is how we would solve that, every external customer connection that we have to expose, we would create a new provnet, with it´s own vni/vrf | 16:03 |
| noonedeadpunk | so basically, VRF is better choice. And I guess OVN exposure method won't handle the use-case | 16:03 |
| mnederlof | then the customer can use that subnet to route through it, or use that network directly, as ´shared´ network | 16:03 |
| noonedeadpunk | and we'd need your patch for that https://review.opendev.org/c/openstack/ovn-bgp-agent/+/906505 | 16:04 |
| mnederlof | yep, but i have not tested non-dvr scenario | 16:04 |
| noonedeadpunk | mnederlof: ok, yes, that's what was I told the usecase will be (one of) | 16:04 |
| noonedeadpunk | while mainly we need to expose only FIPs | 16:05 |
| noonedeadpunk | -only- | 16:05 |
| noonedeadpunk | * mainly exposing FIPs | 16:05 |
| mnederlof | which is basically a provider network with ´router:external´ enabled | 16:05 |
| noonedeadpunk | yeah | 16:05 |
| noonedeadpunk | ok, well. I think I can test the patch :) | 16:06 |
| mnederlof | please read the doc i wrote (zuul temp copy can be found here: https://45b67cabc958c12316a8-de1ec222256e01db8c1f1f4d7a4b9170.ssl.cf2.rackcdn.com/906505/7/check/openstack-tox-docs/a45a6ed/docs/examples/nb_evpn_vrf.html ) | 16:07 |
| noonedeadpunk | yeah, sure, I was already reading it | 16:07 |
| mnederlof | might get you up and running a bit faster (and if something is still unclear, please let me know in the patchset | 16:07 |
| mnederlof | then i can add it in there | 16:07 |
| mnederlof | as i need to make some other changes as well, as you probably already read in the discussions there :) | 16:08 |
| mnederlof | our compute nodes also do not have direct public access per se, they just peer with the internal address of the public router, which maps the evpn to a public vrf | 16:09 |
| mnederlof | since the entire thing is L3 routed anyway, i´d guess your routers are/should be reachable anyway O:-) | 16:09 |
| noonedeadpunk | for some reason, which I'm not aware about, net team wants to peer with public IPs in small /28 subsets | 16:10 |
| noonedeadpunk | So placing all computes there is not feasable | 16:10 |
| noonedeadpunk | I mean, yes. they should. But there's some magic behind the scene I don't get. | 16:10 |
| mnederlof | well, you need to terminate your EVPN/VXLAN overlay network somewhere, which is typically not done by the compute node in my experience | 16:11 |
| noonedeadpunk | no, totally not, I assume it's on leafs... | 16:11 |
| noonedeadpunk | I guess I'd need to bring somebody from our net team, as I'm really bad on details how they do thing... | 16:12 |
| noonedeadpunk | and they do not wanna touch openstack world... | 16:12 |
| mnederlof | since it is overlay, you _could_ terminate the EVPN/VXLAN subnets on your networker nodes, and map them there to the public thing | 16:12 |
| noonedeadpunk | hm | 16:13 |
| noonedeadpunk | I probably could... | 16:13 |
| mnederlof | so on your networker nodes you could advertise the 0.0.0.0/0 route towards the computes (for those specific vni´s) | 16:14 |
| mnederlof | over the EVPN/VXLAN thing | 16:14 |
| mnederlof | then, on those networker nodes, you can act as a router between openstack and the public domain | 16:15 |
| noonedeadpunk | that sounds pretty much hacky way ? | 16:15 |
| noonedeadpunk | as frankly - I'd rather rely on geneve or smth in OVN | 16:16 |
| noonedeadpunk | to get the traffic to net node for me | 16:16 |
| noonedeadpunk | and I guess it's totally fine from business prespective, that ppl will have to deal with FIPs | 16:17 |
| noonedeadpunk | but I mean, on the networker nodes I already act as a router for such external networks | 16:18 |
| noonedeadpunk | as we don't want traffic to go through the default gateway there | 16:19 |
| noonedeadpunk | so I made a separate table and ip rule to redirect traffic to this another routing table with alternative default route | 16:19 |
| mnederlof | yes, definitely :) | 16:21 |
| noonedeadpunk | But I guess you got your point | 16:22 |
| mnederlof | i do not think is is necessarily hacky, since you are just terminating the EVPN/VXLAN on the router from where you do the actual routing | 16:22 |
| mnederlof | which in our point is a juniper mx router, but that could very well be a linux box obviously with frr | 16:22 |
| mnederlof | but if non-dvr is the better way to go, then use that :) | 16:23 |
| opendevreview | Merged openstack/neutron master: reno: Update master for unmaintained/xena https://review.opendev.org/c/openstack/neutron/+/911563 | 16:23 |
| noonedeadpunk | frankly - I was already thinking about running ovn-bgp-agent with FRR in a namespace to use both evpn and underlay drivers :D | 16:23 |
| mnederlof | would be great if that works for the nb driver as well (if it not already is) | 16:23 |
| spatel | noonedeadpunk are your planning to use FRR create bgp peer with your leaf switches? | 16:24 |
| mnederlof | i have to go for now, nice discussion :) | 16:25 |
| noonedeadpunk | yeah, that's how ovn-bgp-agent works? | 16:25 |
| noonedeadpunk | mnederlof: thanks a lot! | 16:25 |
| noonedeadpunk | ah, about bgp peer - probably spine actually | 16:26 |
| spatel | That is what I am thinking.. all your leaf switch will be act like spine switches in that case.. | 16:26 |
| noonedeadpunk | Franjkly - I just got set of IPs for neighbours and AS (and auth) | 16:26 |
| noonedeadpunk | so no idea what's there | 16:26 |
| noonedeadpunk | ah, and note that I should use ebgp-multihop :) | 16:27 |
| noonedeadpunk | anywya | 16:27 |
| spatel | In this diagram its very clear https://ltomasbo.wordpress.com/2021/02/04/ovn-bgp-agent-testing-setup/ | 16:28 |
| spatel | compute node FRR creating peers with leaf switches using /30 network and exposing /32 loopback IP as compute nodes IP | 16:30 |
| opendevreview | Merged openstack/neutron master: reno: Update master for unmaintained/wallaby https://review.opendev.org/c/openstack/neutron/+/911536 | 16:33 |
| opendevreview | Merged openstack/neutron master: reno: Update master for unmaintained/victoria https://review.opendev.org/c/openstack/neutron/+/911511 | 16:33 |
| opendevreview | Merged openstack/networking-sfc master: reno: Update master for unmaintained/xena https://review.opendev.org/c/openstack/networking-sfc/+/911551 | 16:37 |
| opendevreview | Merged openstack/networking-bgpvpn master: reno: Update master for unmaintained/xena https://review.opendev.org/c/openstack/networking-bgpvpn/+/911548 | 16:37 |
| opendevreview | Merged openstack/networking-bagpipe master: reno: Update master for unmaintained/wallaby https://review.opendev.org/c/openstack/networking-bagpipe/+/911521 | 16:46 |
| *** jamesdenton_ is now known as jamesdenton | 16:48 | |
| -opendevstatus- NOTICE: Jobs that fail due to being unable to resolve mirror.dfw.rackspace.opendev.org can be rechecked. This error was an unexpected side effect of some nodepool configuration changes which have been reverted. | 16:55 | |
| opendevreview | Merged openstack/networking-bagpipe master: reno: Update master for unmaintained/victoria https://review.opendev.org/c/openstack/networking-bagpipe/+/911492 | 17:00 |
| opendevreview | Merged openstack/networking-sfc master: reno: Update master for unmaintained/victoria https://review.opendev.org/c/openstack/networking-sfc/+/911498 | 17:42 |
| opendevreview | Brian Haley proposed openstack/neutron master: Add note on iptables cleanup after OVS firewall migration https://review.opendev.org/c/openstack/neutron/+/911957 | 19:03 |
| opendevreview | Merged openstack/networking-bgpvpn master: reno: Update master for unmaintained/victoria https://review.opendev.org/c/openstack/networking-bgpvpn/+/911494 | 19:59 |
| opendevreview | Merged openstack/networking-sfc master: reno: Update master for unmaintained/wallaby https://review.opendev.org/c/openstack/networking-sfc/+/911526 | 20:02 |
| opendevreview | Merged openstack/networking-bagpipe master: reno: Update master for unmaintained/xena https://review.opendev.org/c/openstack/networking-bagpipe/+/911546 | 20:18 |
| opendevreview | Merged openstack/neutron master: [OVN] Enable "ha" API flag for OVN routers https://review.opendev.org/c/openstack/neutron/+/910889 | 22:32 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!