August 2022 - openstack-discuss - lists.openstack.org

[election][Release_Management] Proposal to change to Distributed PTL model
by Előd Illés 31 Aug '22

31 Aug '22

Hi, This is my 2nd cycle (Yoga + Zed) as PTL of the Release Management team and this is the time when usually a PTL role is handed over. We had a discussion in our team and decided that now that OpenStack moves from Zed to Antelope and the cycles starts again from the beginning of the alphabet + the new naming is going to be introduced (2023.1 Antelope) this is a good time to change the leadership model of the team to a group leadership model (or DPTL; distributed project team leadership). @TC: so this mail is to inform the TC that we want to move to this direction & let us know if there is something we need to sort out for the model change. Thanks, Előd Illés irc: elodilles

2 1

PTG October 2022 Teams List
by Kendall Nelson 30 Aug '22

30 Aug '22

Hello Everyone! The October 2022 Project Teams List is official! Projects + Teams: - Computing Force Network (CFN) Working Group - Diversity& Inclusion Working Group - Environmental Sustainability Working Group - Kata Containers - Magma - OpenInfra Edge Computing Group - OpenStack Teams - - Ansible OpenStack Modules - Barbican - Blazar - Cinder - CloudKitty - Designate - First Contact SIG - Glance - Heat - Horizon - Interop WG - Ironic - Keystone - Kolla - Kuryr - Manila - Neutron - Nova/Placement - Octavia - OpenStack Charms - OpenStack Helm - OpenStack Operators - OpenStack SDK/CLI - OpenStack Security SIG - OpenStack Technical Committee - Openstack-Ansible - OpenStack-Helm - QA - Release Management - Swift - Tacker - Telemetry - TripleO - StarlingX If your team was planning to meet and isn’t in this list, please contact ptg(a)openinfra.dev IMMEDIATELY. Soon I will be contacting moderators to sign up for time via the PTGBot[1] once I have it configured for the teams that are signed up to attend the event. Otherwise, please don't forget to register[2] — its FREE! As usual, feel free to let us know if you have any questions. Thanks! -Kendall (diablo_rojo) [1] PTGBot Docs: https://github.com/openstack/ptgbot#open-infrastructure-ptg-bot [2] PTG Registration: https://openinfra-ptg.eventbrite.com

1 0

[election][Neutron] PTL candidacy for Antelope cycle
by Rodolfo Alonso Hernandez 30 Aug '22

30 Aug '22

Hello all: I would like to announce my candidacy for the role of PTL of Neutron for the Antelope cycle. Let me introduce myself first. I started contributing to OpenStack in Liberty release (2015). I've contributed to several projects, mainly Neutron, neutron-lib, os-ken and os-vif, in addition to Nova and devstack. During the last two years I've been focused on the ML2/OVN integration, QoS and Placement related features and helping on the Neutron CI improvement and stabilization. For this new release, those are the main goals I would like to focus on: * Take care and focus on the approved and merged Neutron specs [1]. Those RFEs should be actively attended by the community, from the spec proposal to the code review. In order to increase the attention of the community on these new RFEs, new ways of tracking them should be proposed (a topic that should be discussed during the PTG). For example, having a core reviewer “godfather” for each RFE. * Continue with the improvement of CI stability. The job done during the last 2 or 3 releases has been impressive, probably the hardest and the most continued effort on the CI in the Neutron community ever. We *must* continue with this effort and the current processes to track the healthiness of the CI. * Start working on the smart NIC / hardware offload testing. The number of backends (ML2/OVS, ML2/OVN, ML2/SR-IOV) make non-viable to test any possible combination. But at least, depending on the available hardware, we would be able to test the stability of those backends with the newest hardware offload NICs. Note: that will imply an external CI support. * Work with users and operators, providing an active channel with them. The goal is to attract customers to be actively involved in the community, participating in the Neutron meetings (team meeting, CI meeting, drivers meeting) or even creating a specific meeting with them in order to capture new needs or issues. * Live migration improvement, specially in ML2/OVN. This feature is still being tested and has not proven to be very stable. There are several core OVN and Neutron efforts right now but we still need to make this feature stable enough to be delivered to customers. A part from those main goals, we should always keep an eye on: * The SQLAlchemy 2.0 migration and any possible issue detected. * The Neutron's stadium ecosystem alive and healthy: this is a permanent goal in any release. The Neutron ecosystem is wide and diverse and it is maintained with few resources. We should focus on those active projects and communities that support their respective repositories. * Still closing the ML2/OVS - ML2/OVN feature gap, that is smaller every cycle. Thank you in advance. Rodolfo Alonso Hernandez (ralonsoh, ralonsoh(a)redhat.com)

1 0

[TripleO] quay.io namespace local mirror using harbor. Quay.io do not list repos/images
by Ruslanas Gžibovskis 30 Aug '22

30 Aug '22

Hi all, I am trying to make a local repo/copy to be able to deploy OSP onsite behind firewall. I have found out from harbor, that Quay.io do not return repos/image anonymously also I have created account in quay.io with my RH account. Later reset quay.io password, so quay.io connection verify works. I can get it as a proxy, or exact image, but not full offline installation. Could you help/suggest any tool that could do a local repo? I have also tried foreman, but it only can sync repo in namespace, not whole namespace. Thank you for your advice and comments. -- Ruslanas Gžibovskis +370 6030 7030

2 1

[kolla] [nova] Rogue AggregateMultiTenancyIsolation filter
by Albert Braden 30 Aug '22

30 Aug '22

We're running kolla train, and we use the AggregateMultiTenancyIsolation for some aggregates by setting filter_tenant_id. Today customers reported build failures when they try to build VMs in a non-filtered region. I am able to duplicate the issue: os server create --image <image> --flavor medium --network private --availability-zone open alberttest1 | 5dd44105-2045-4d53-be43-5f521ddb420b | alberttest1 | ERROR | | <image> | medium | 2022-08-26 18:39:38.977 30 INFO nova.filters [req-342d065a-cd47-4edf-bc4b-3f84b34ab97c 25b53bdb96fb5f9f6e7331d7e03eee0a12c45746a9e8b978858b2140a5275a09 fdcf1553db504c8f82a2b54851a4c262 - 8793b235debf49e6aba6bd1e2bf65360 8793b235debf49e6aba6bd1e2bf65360] Filtering removed all hosts for the request with instance ID '5dd44105-2045-4d53-be43-5f521ddb420b'. Filter results: ['ComputeFilter: (start: 50, end: 50)', 'RetryFilter: (start: 50, end: 50)', 'AggregateNumInstancesFilter: (start: 50, end: 50)', 'AvailabilityZoneFilter: (start: 50, end: 6)', 'AggregateInstanceExtraSpecsFilter: (start: 6, end: 6)', 'ImagePropertiesFilter: (start: 6, end: 6)', 'ServerGroupAntiAffinityFilter: (start: 6, end: 6)', 'ServerGroupAffinityFilter: (start: 6, end: 6)', 'AggregateMultiTenancyIsolation: (start: 6, end: 0)'] Region "open" does not have any properties specified, so the AggregateMultiTenancyIsolation filter should not be active. qde3:admin]$ os aggregate show open|grep properties | properties | This is what we would see if it had the filter active: :qde3:admin]$ os aggregate show closed|grep properties | properties | filter_tenant_id='1c41e088b35f4b438023d081a6f70292,3e9727aaf03e4459a176c28dbdb3965e,f9b4b7dc8c614bb09d66657afc3b21cd,121a5da3dd0b489986908bee7eea61ae,d580ccc4b07e478a9efc2d71acf04cc1,107e14eeda01400988e58f5aac8b2772', closed='true' What could be causing this filter to remove hosts when we haven't set filter_tenant_id for that aggregate?

2 2

[cinder] This week's meeting will be in video+IRC
by Rajat Dhasmana 30 Aug '22

30 Aug '22

Hello Argonauts, As we keep last meeting of the month in video + IRC mode, this week's meeting (tomorrow) will be held in video + IRC mode with details as follows: Date: 31st August, 2022 Time: 1400 UTC Meeting link: https://bluejeans.com/556681290 IRC Channel: #openstack-meeting-alt Make sure you're connected to both the bluejeans meeting and IRC since we do roll call and also discuss topics on IRC (if the author is more comfortable in written format). Thanks and regards Rajat Dhasmana

1 0

[election][nova][placement] Candidating for the Antelope cycle.
by Sylvain Bauza 30 Aug '22

30 Aug '22

Hi Nova and Placement folks, Yet again, I want to help our community for this cycle by working on papers. If you accept me for being Antelope Nova/Placement PTL, it would be my last cycle for it after already two of them (unless nobody runs for this). For the moment, we are not yet done with Zed but I'm happy to see that we have 13 open blueprints that are reviewed and where some of them are from contributors that aren't everyday Nova developers. That's the reason why I wanted to help those on-off contributors that have not a large time for upstream work and that's why we added a Gerrit review label value for them (saying "I want to review as a contributor"). We also tried a new way for discussing about open changes creating a new API microversion and even if it hadn't really needed, I think we could use this way next time if needed. So, what would I like for us to discuss during Antelope then ? Well, at least three points : - given Antelope will be the first 'tick' release, I want to make sure we won't have any issues in Nova or Placement for this cycle, and I also would like to prepare for the 'tock' release. - I would like to discuss with our community how to find some opportunities for new contributors that would like to work on Nova. - as we discussed with operators in the Berlin Summit, I would like to find a way for them to discuss with us and see how they could be in our community even if they're not developers. At least, I'd love to see some operators in our meetings and in our PTG sessions. Thanks, -Sylvain (again, not a leader but just a herder.)

1 0

[all] [oslo.messaging] Interest in collaboration on a NATS driver
by Tobias Urdin 30 Aug '22

30 Aug '22

Hello, Please note that the list provided was just from my own notes and I didn’t put much emphasis on making it complete or accurate. If you think back to the early days of OpenStack the pain was in OpenStack itself, today it’s a challenge instead to manage OpenStack scale and fit into the things we see, like moving OpenStack into containers (for example managed by Kubernetes). I would like OpenStack design to more embrace the distributed, cloud-native approach that Ceph and Kubernetes brings, and the resiliency of Ceph (and yes, I’m a major Ceph enthusiast) and there I’m seeing messaging and database as potential blockers to continue on that path. I’m not saying that’s the only thing, for example stuff like [1] _really_ matter in real world deployments so working on other OpenStack parts for resilience is also crucial. There is things I’m interested in that would impact the overall design, I can list some of them but I think it might be to broad of a subject for this thread. * Like brought up my Mohammed Naser before, I would like to investigate an effort for containers as an OpenStack deliverable for projects * Investigate cloud-native, highly available and resilient alternatives for messaging and database * Make OpenStack more resilient with above and [1] is a great example on what I mean I’ll respond to your questions with my views inline below. P.S The opionions stated here is my own personal opinions and should not be assumed to be the opinions of any other entity. Best regards Tobias [1] https://bugs.launchpad.net/neutron/+bug/1987780 Begin forwarded message: From: Radosław Piliszek <radoslaw.piliszek(a)gmail.com<mailto:radoslaw.piliszek@gmail.com>> Subject: Re: [all] [oslo.messaging] Interest in collaboration on a NATS driver Date: 29 August 2022 at 18:33:15 CEST To: Tobias Urdin <tobias.urdin(a)binero.com<mailto:tobias.urdin@binero.com>> Cc: openstack-discuss <openstack-discuss(a)lists.openstack.org<mailto:openstack-discuss@lists.openstack.org>> Hi Tobias, Good to see RMQ alternatives appearing. A couple of questions from me. On Mon, 29 Aug 2022 at 15:47, Tobias Urdin <tobias.urdin(a)binero.com<mailto:tobias.urdin@binero.com>> wrote: • Do retries and acknowledgements in the library (since NATS does NOT persist messages like RabbitMQ could) What do you mean? Is NATS only a router? (I have not used this technology yet.) It does not persist messages, if there is no backend to respond, the message will be dropped without any action hence why I want the RPC layer in oslo.messaging (that already does acknowledge calls in the driver) to notify client side that it’s being processed before client side waits for reply. • Find or maintain a NATS python library that doesn't use async like the official one does Why is async a bad thing? For messaging it's the right thing. This is actually just myself, I would love to just being able to use the official that is async based instead it’s just me that doesn’t understand how that would be implemented. https://github.com/nats-io/nats.py instead of the one in POC https://github.com/Gr1N/nats-python which has a lot of shortcomings and issues, my idea was just to investigate if was even possible to implement in a feasible way. Finally, have you considered just trying out ZeroMQ? Does not exist anymore. I mean, NATS is probably an overkill for OpenStack services since the majority of them stay static on the hosts they control (think nova-compute, neutron agents - and these are also the pain points that operators want to ease). I don’t think it it, or even if it is, why not use a better solution or stable approach than RabbitMQ? This is also the whole point, I don’t want OpenStack to become or be static, I want it to be more dynamic and cloud-native in it’s approach and support viable integrations that takes it there, we cannot live in the past forever, let’s envision and dream of the future as we want it! :) NATS seems to me to cater for a different use case. It actually caters to a lot of use cases. I might be wrong because I have read only the front page but that is the feeling I have. Cheers, Radek -yoctozepto Begin forwarded message: From: Radosław Piliszek <radoslaw.piliszek(a)gmail.com<mailto:radoslaw.piliszek@gmail.com>> Subject: Re: [all] [oslo.messaging] Interest in collaboration on a NATS driver Date: 29 August 2022 at 20:20:15 CEST To: Sean Mooney <smooney(a)redhat.com<mailto:smooney@redhat.com>> Cc: Tobias Urdin <tobias.urdin(a)binero.com<mailto:tobias.urdin@binero.com>>, openstack-discuss <openstack-discuss(a)lists.openstack.org<mailto:openstack-discuss@lists.openstack.org>> On Mon, 29 Aug 2022 at 20:03, Sean Mooney <smooney(a)redhat.com<mailto:smooney@redhat.com>> wrote: Finally, have you considered just trying out ZeroMQ? ZeroMQ used to be supported in the past but then it was remvoed if i understand correctly it only supprot notificaiton or RPC but not both i dont recall which but perhapse im miss rememebrign on that point. I believe it would be better suited for RPC than notifications, at least in the simplest form. As it’s advertised as scalable and performant I would argue that, why not use it for notifications as well? If anything according to your observations above it’s more suited for that than RPC, even though request-reply (that we can use for RPC) is a strong first-class implementation in NATS as well. I mean, NATS is probably an overkill for OpenStack services since the majority of them stay static on the hosts they control (think nova-compute, neutron agents - and these are also the pain points that operators want to ease). its not any more overkill then rabbitmq is True that. Probably. I agree with that, also if you think about it, how many issues related to stability, performance and outages is related to RabbitMQ? It’s quite a few if you ask me. Just the resource utilization and clustering in RabbitMQ makes me feel bad. It’s here that I mean that the cloud-native and scalable implementation would shine, you should be able to rely on it, if sometimes dies so what, things should just continue to work and that’s not my experience with RabbitMQ but it is my experience with Ceph because in the end the design really matters. i also dont know waht you mean when you say "majority of them stay static on the hosts they control" NATS is intended a s a cloud native horrizontally scaleable message bus. which is exactly what openstack need IMO. NATS seems to be tweaked for "come and go" situations which is an exception in the OpenStack world, not the rule (at least in my view). I mean, one normally expects to have a preset number of hypervisors and not them coming and going (which, I agree, is a nice vision, could be a proper NATS driver, with more awareness in the client projects I believe, would be an enabler for more dynamic clouds). It could, but it also doesn’t have to be that. Why not strive for more dynamic? I don’t think anybody would argue that more dynamic is a bad thing even if you were to have a more static approach to your cloud. Cheers, Radek -yoctozepto

2 2

[publiccloud-sig] Bi-weekly meeting reminder
by Tobias Rydberg 30 Aug '22

30 Aug '22

Hi all, Tomorrow we will have our bi-weekly meeting at 0800 UTC in #openstack-operators. Agenda can be fond here [0]. Feel free to suggest topics to the agenda if you like. Hope to chat with you tomorrow! [0] https://etherpad.opendev.org/p/publiccloud-sig-meeting BR, Tobias Rydberg

1 0

RE: Openstack OVN (Open Virtual Network) HA deployment - running OVN in active/passive mode?
by 박경원 30 Aug '22

30 Aug '22

1 0