October 2022 - openstack-discuss - lists.openstack.org

[ovn][neutron] RE: OVN BGP Agent query
by Ihtisham ul Haq 18 Oct '22

18 Oct '22

Hi Luis and Daniel, Please see inline response. > From: Daniel Alvarez Sanchez <dalvarez(a)redhat.com> > Sent: 29 September 2022 11:37 > Subject: Re: OVN BGP Agent query > > Hi Ihtisham and Luis, > > On Thu, Sep 29, 2022 at 7:42 AM Luis Tomas Bolivar <ltomasbo(a)redhat.com> wrote: > > Some comments and questions inline > > > > On Tue, Sep 27, 2022 at 1:39 PM Ihtisham ul haq <ihtisham.uh(a)hotmail.com> wrote: > > > Hi Luis, > > > > > > Thanks for your work on the OVN BGP Agent. We are planning > > > to use it in our OVN deployment, but have a question regarding it. > > > > Great to hear! Can you share a bit more info about this environment? like > > openstack version, target workload, etc. We plan to use this with Yoga version. Our workload consist of enterprise users with VMs running on Openstack and connected to their enterprise network via transfer network(to which the customer neutron router is attached to). And we also have public workload but with the ovn-bgp we only want to we want to advertise the former. > > > > > The way our current setup with ML2/OVS works is that our customer VM IP routes > > > are announced via the router IP(of the that customer) to the leaf switch instead of > > > the IP of the host where the neutron BGP agent runs. And then even if the > > > router fails over, the IP of the router stays the same and thus the BGP route > > > doesn't need to be updated. > > > > Is this with Neutron Dynamic Routing? When you say Router IP, do you mean the virtual neutron router and its IP associated with the provider network? What type of IPs are you announcing with BGP? IPs on provider network or on tenant networks (or both)? Yes, that's with Neutron DR agent, and I meant virtual neutron router with IP from the provider network. We announce IPs of our tenant network via the virtual routers external address. > > If the router fails over, the route needs to be updated, doesn't it? Same IP, but exposed in the new location of the router? Correct. > The route to the tenant network doesn't change, ie. > 192.168.0.0 via 172.24.4.100 (this route remains the same regardless of where 172.24.4.100 is). > If there's L2 in the 172.24.4.0 network, the new location of 172.24.4.100 will be learnt via GARP announcement. In our case, this won't happen as we don't have L2 so we expose directly connected routes to overcome this "limitation". Right, in our case we have a stretched L2 transfer network(mentioned above) to which our gateway nodes and customer routers are connected to, so we can advertise the IPs from the tenant network via the virtual router external IP and thus the location of the router isn't relevant in case of failover as its address will be relearned. > In the case of Neutron Dynamic Routing, there's no assumption that everything is L3 so GARPs are needed to learn the new location. > > > > We see that the routes are announced by the ovn-bgp-agent via the host IP(GTW) in our > > > switch peers. If that's the case then how do you make sure that during failover > > > of a router, the BGP routes gets updated with the new host IP(where the router > > > failed over to)? > > > > The local FRR running at each node is in charge of exposing the IPs. For the IPs on the provider network, the traffic is directly exposed where the VMs are, without having to go through the virtual router, so a router failover won't change the route. > > In the case of VMs on tenant networks, the traffic is exposed on the node where the virtual router gateway port is associated (I suppose this is what you refer to with router IP). In the case of a failover the agent is in charge of making FRR to withdraw the exposed routes on the old node, and re-advertise them on the new router IP location > > > > > Can we accomplish the same route advertisement as our ML2/OVS setup, using the ovn-bgp-agent? > > I think this is technically possible, and perhaps you want to contribute that functionality or even help integrating the agent as a driver of Neutron Dynamic Routing? Sounds good, our plan currently is to add this to the ovn-bgp-agent, so we can announce our tenant routes via virtual routers external address on a stretched L2 network, to make it work with our use case. -- Ihtisham ul Haq Diese E Mail enthält möglicherweise vertrauliche Inhalte und ist nur für die Verwertung durch den vorgesehenen Empfänger bestimmt. Sollten Sie nicht der vorgesehene Empfänger sein, setzen Sie den Absender bitte unverzüglich in Kenntnis und löschen diese E Mail. Hinweise zum Datenschutz finden Sie hier<https://www.datenschutz.schwarz>.

3 5

[kolla] Monasca removal, Kafka and Zookeeper deprecation/removal
by Michał Nasiadka 18 Oct '22

18 Oct '22

Hello, As Kolla/Kolla-Ansible projects are implementing switch to OpenSearch - it became obvious to remove Elasticsearch (which is EOL in Kolla-provided version) and orchestrate a direct upgrade into OpenSearch. Part of this work is removal of elasticsearch and log stash Kolla container images and elasticsearch role in Kolla-Ansible. Since Monasca is relying on Elasticsearch and Logstash - and there are no contributors willing to make it work with OpenSearch inside Kolla/Kolla-Ansible - we decided to drop Monasca support in Zed release (especially that the CI jobs have been long failing). One of the Monasca dependencies is Kafka (and ZooKeeper) - is there anybody using it outside of Monasca deployment in Kolla/Kolla-Ansible? If in 4 weeks there will be no answers to this question - we will also remove Kafka and ZooKeeper container images in Kolla (and their respective roles in Kolla-Ansible). Thanks Michal

1 0

[cinder] cancelling this week's meeting (19 Oct)
by Rajat Dhasmana 18 Oct '22

18 Oct '22

Hello Argonauts, Since we've PTG this week, we will not be conducting the weekly meeting on 19th Oct 2022 but everyone is recommended to attend the PTG instead[1]. See you all at the PTG! [1] https://etherpad.opendev.org/p/antelope-ptg-cinder Thanks and regards Rajat Dhasmana

1 0

[kolla] Weekly meeting 20th Oct 2022
by Michał Nasiadka 18 Oct '22

18 Oct '22

Hello, Since this is PTG week - this week meeting is cancelled. Best regards, Michal

1 0

[tacker] Cancelling IRC meeting on Oct 18
by Yasufumi Ogawa 18 Oct '22

18 Oct '22

Hi team, Since we're going to have the vPTG session, I'd like to cancel IRC meeting today. Thanks, Yasufumi

1 0

[keystone] Cancelling weekly meeting for 10/18/22
by Dave Wilde 17 Oct '22

17 Oct '22

Cancelling due to the PTG

1 0

[ptls][tc] 2022 OpenStack User Survey Project Question Responses
by Allison Price 17 Oct '22

17 Oct '22

Hi everyone, Please find attached the responses to the project questions from the 2022 OpenStack User Survey. Based on feedback last year, I included additional, non-identifiable information that will hopefully help provident deployment context for the responses to your questions. If you need a reminder of your project question, you can review the OpenStack User Survey [1]. During the PTG, I would encourage you and your teams to review the responses and decide if you would like to make any changes to your question for the 2023 OpenStack User Survey. It is live now, but we can make changes ahead of significant promotion. Please reach out to me directly with any changes. If you have any questions on how to read the results, please let me know. Have a great week at the PTG! Cheers, Allison [1] https://www.openstack.org/usersurvey

2 4

[kolla][ptg] Meetings on Tuesday 18th Oct
by Michał Nasiadka 17 Oct '22

17 Oct '22

Hello Koalas, Due to exhaustion of topics - we’re meeting tomorrow only on the Kolla Operator Hour at 16 UTC. Kolla Operator Hour Etherpad: https://etherpad.opendev.org/p/oct2022-ptg-operator-hour-kolla Best regards, Michal Nasiadka

1 0

[manila] Cancelling two weekly meetings
by Carlos Silva 17 Oct '22

17 Oct '22

Hello, Zorillas! As agreed in the previous week, we will be cancelling the next two weekly meetings: from this week (Oct 20th) and next week (Oct 27th). The next weekly meeting for Manila will be on Nov 3rd. Thank you, carloss

1 0

[release] Release countdown for week R-22, Oct 17 - 21
by Előd Illés 17 Oct '22

17 Oct '22

Hi, Welcome back to the release countdown emails! These will be sent at major points in the 2023.1 Antelope development cycle, which should conclude with a final release on March 22nd, 2023. Development Focus ----------------- At this stage in the release cycle, focus should be on planning the 2023.1 Antelope development cycle, assessing 2023.1 Antelope community goals and approving 2023.1 Antelope specs. General Information ------------------- 2023.1 Antelope is a 24 weeks long development cycle. In case you haven't seen it yet, please take a look over the schedule for this release: https://releases.openstack.org/antelope/schedule.html By default, the team PTL is responsible for handling the release cycle and approving release requests. This task can (and probably should) be delegated to release liaisons. Now is a good time to review release liaison information for your team and make sure it is up to date: https://opendev.org/openstack/releases/src/branch/master/data/release_liais… By default, all your team deliverables from the Zed release are continued in 2023.1 Antelope with a similar release model. Upcoming Deadlines & Dates -------------------------- Virtual PTG: October 17-21, 2022 Antelope-1 milestone: November 17th, 2022 Előd Illés irc: elodilles @ #openstack-release

1 0