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

[dev][infra][tact-sig] Updating Zuul's default-ansible-version to 6
by Jeremy Stanley 19 Oct '22

19 Oct '22

Just a heads up for folks not following the OpenDev Collaboratory's service-announce mailing list... now that Zed is officially released, we'll be increasing the default Ansible version for Zuul jobs from 5 to 6 in preparation for Zuul to drop Ansible 5 support in coming weeks. See the full announcement here: https://lists.opendev.org/pipermail/service-announce/2022-October/000046.ht… -- Jeremy Stanley

2 1

[horizon] Cancelling Two Weekly Meeting
by vishal manchanda 19 Oct '22

19 Oct '22

Hello Team, As discussed in Yesterday's PTG meeting, there will be no horizon weekly meeting for today and next week. The next horizon weekly meeting will be on 2nd November. Thanks & Regards, Vishal Manchanda

1 0

DC DR Setup Queries
by KK CHN 19 Oct '22

19 Oct '22

List, We are having a client DC running on HP( HP simplivity) HCI servers, With VMware ( Vsphere 7.0) only few VMs running on it. (11 VMs maximum all Linux VMs). The DR site also having the same HCI setup another location. ( The VMs are replicated to DR site with HP simplivity). We are planning to use Openstack for both DC and DR solutions with Wallaby or Xena version with KVM as hypervisor to replace the proprietary S/W and H/W vendor locking. The requirement is to Setup a Stable DC- DR solution. Totally confused How to setup a best Dc- DR solution for this purpose. The DR setup can be possible / advisable with Zero down time ?( or manual DR site uping with downtime of hours ) ? What are the available/suggested DC-DR replication mechanisms for high degree of application data protection and service availability? Kindly advise.. Thanks in advance, Krish

2 2

[cloudkitty] Another core team cleanup
by Pierre Riteau 19 Oct '22

19 Oct '22

Hello, Almost exactly two years since the last core team cleanup [1], it's probably time to have another one. I don't think we have heard from these contributors in the last couple of years: Justin Ferrieu jferrieu(a)objectif-libre.com Luis Ramirez luis.ramirez(a)opencloud.es Luka Peschke mail(a)lukapeschke.com Maxime Cottret maxime.cottret(a)gmail.com Stéphane Albert sheeprine(a)nullplace.com Jeremy Liu liuj285(a)chinaunicom.cn Is everyone okay with removing cloudkitty-core membership for these users? Cheers, Pierre Riteau (priteau) [1] https://lists.openstack.org/pipermail/openstack-discuss/2020-October/017751…

2 3

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

19 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 18 Oct '22

18 Oct '22

Cancelling due to the PTG

1 0