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

[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

[infra][puppet] Old mirror contents in apt-puppetlabs
by Takashi Kajinami 30 Aug '22

30 Aug '22

Hello Infra team, I noticed the contents in the apt-puppetlabs directory in our CI mirror are old. The mirror repository provides puppet 6.23 while the upstream repository provides newer versions such as 6.28. Recently we bumped puppetlabs-mysql in our CI to 13.0.0 which requires puppet >= 6.24.0 and our Ubuntu jobs are failing now at a quite early stage because of the old puppet package. May someone please look into this ? I've checked mirror.iad3.inmotion.opendev.org and mirror.bhs1.ovh.opendev.org but it seems the contents in the directory have not been synced since July, 2021. Thank you, Takashi

2 3

Skyline apiserver can't connect to keystone and given error endpoint not found
by mahdi n 29 Aug '22

29 Aug '22

Skyline apiserver can't connect to keystone and given endpoint not found I install skyline api server and console But Apiserver get error : endpoint not found I attached pictures of this problem Please help me

1 1

[all][elections][ptl][tc] Combined PTL/TC antelope cycle Election Nominations Last Days
by Amy Marrich 29 Aug '22

29 Aug '22

A quick reminder that we are in the last hours for declaring PTL and TC candidacies. Nominations are open until Aug 31, 2022 23:45 UTC. Should we find that many of the community members were off on vacation this date may get extended pushing the elections out. If you want to stand for election, don't delay, follow the instructions at [1] to make sure the community knows your intentions. Make sure your nomination has been submitted to the openstack/election repository and approved by election officials. Election statistics[2]: Nominations started @ 2022-08-24 23:45:00 UTC Nominations end @ 2022-08-31 23:45:00 UTC Nominations duration : 7 days, 0:00:00 Nominations remaining : 2 days, 5:50:21 Nominations progress : 67.95% --------------------------------------------------- Projects[1] : 52 Projects with candidates : 5 ( 9.62%) Projects with election : 0 ( 0.00%) --------------------------------------------------- Need election : 0 () Need appointment : 47 (Adjutant Barbican Blazar Cinder Cloudkitty Cyborg Designate Freezer Glance Heat Horizon Ironic Keystone Manila Masakari Mistral Monasca Murano Neutron Nova Octavia OpenStackAnsible OpenStackSDK OpenStack_Charms OpenStack_Helm Openstack_Chef Oslo Puppet_OpenStack Quality_Assurance Rally Release_Management Requirements Sahara Senlin Skyline Solum Storlets Swift Tacker Telemetry Tripleo Trove Venus Vitrage Watcher Zaqar Zun) =================================================== Stats gathered @ 2022-08-29 17:54:39 UTC This means that with approximately 2 days left, 47 projects will be deemed leaderless. In this case the TC will oversee PTL selection as described by [3]. Thank you, [1] https://governance.openstack.org/election/#how-to-submit-a-candidacy [2] Any open reviews at https://review.openstack.org/#/q/is:open+project:openstack/election have not been factored into these stats. [3] https://governance.openstack.org/resolutions/20141128-elections-process-for…

1 0

[tacker][elections] PTL candidacy for Antelope cycle
by Yasufumi Ogawa 29 Aug '22

29 Aug '22

Hi, I'd like to propose my candidacy for Tacker PTL for Antelope cycle. I have contributed to Tacker as a PTL from Victoria for providing the latest features of ETSI-NVF standard features to enable operators to deploy their services. In the latest cycles, we have developed several supports for deploying CNFs, multi-version APIs for mixed environment of legacy and cutting edge-products provided by several vendors and more. We also have had several collaborative sessions with ETSI NFV for accelerating each activity of standardization and deployment of required features. In the next release, I would like to focus our target more on to develop features for reliability and avairability such as monitoring physical resources in addition to VMs and containers. Best regards, Yasufumi (yasufum)

1 0