April 2024 - openstack-discuss - lists.openstack.org

[qa][ptg] QA Dalmatian vPTG Summary
by Martin Kopec 17 Apr '24

17 Apr '24

Hi everyone, here is a summary of the discussions. The full agenda can be found here [1]. == Caracal Retrospective == We still manage making releases, doing code reviews and bug triaging even with only a few active contributors. Kudos to them. == Simplify grenade skip level jobs == It was agreed that we want to run grenade-skip-level job always as voting by default in template and project can opt-out for non-SLURP release. == Replace paramiko with libssh2 == It was agreed that the priority of getting rid of paramiko should take place at services' side first. After all services are done with this change, then we can proceed with this on tempest's side. In the meantime, we at least know that tempest works with the FIPS environment [2]. == Triage previous and write new priority items == The list of the priority items planned for this cycle as well as the ones which were carried over from the previous cycles, can be found here [3]. [1] https://etherpad.opendev.org/p/apr2024-ptg-qa [2] https://zuul.openstack.org/builds?job_name=tempest-centos9-stream-fips&skip… [3] https://etherpad.opendev.org/p/qa-caracal-priority Thank you all for attending the PTG and contributing to the discussion, -- Martin Kopec Principal Software Quality Engineer Red Hat EMEA IM: kopecmartin

1 0

volume in use
by kjme001＠gmail.com 16 Apr '24

16 Apr '24

helllo, I have the following problem that after deleting the instance, the volume remains in use and is connected to an instance that does not exist. I have to execute the command: cinder reset-state --state available --attach-status detached name_volume then the volume becomes available and is not connected to the instance. How to solve this problem? Regards

2 1

[manila] 2024.2 Dalmatian PTG summary
by Carlos Silva 16 Apr '24

16 Apr '24

Hello everyone, Thank you for participating in the PTG last week! You can check the notes in our PTG etherpad [0], and the recording for all sessions is available in the OpenStack Manila youtube channel [1]. Here is a brief summary of what we discussed and the action items: *# Caracal Retrospective:* *Highlights:* Great internship rounds (manila-ui, docs, SDK and bandit testing). SQLAlchemy 2.0 migration is close to completion and we are planning to backport it. Doc bug squash was a success. We managed to close almost 70% of the bugs we signed up for. FFEs are allowing little time for testing and we are willing to take some different actions. *AIs:* - Schedule a mid cycle check-in with our PTG etherpad to ensure all the topics we brought up are being addressed. - Collaborative review sessions now should be proposed alongside the feature when submitting the features to gerrit. - Bug squashes and hackathons will be announced earlier, so we can try to have more traction. *# Enhance PoolWeigher to respect current share network* The PoolWeigher doesn't take into consideration the share server per share network allocation. As a result, the weigher will take one of these approaches: - Stack: create all shares in a pool even though a newly added pool is available until it is full - Spread: create shares in the pool with fewer shares Instead of looking if there is already any share server on the pool, weigh according to if there is already any share server of the same share network on the pool *AIs:* - carthaca will create a launchpad blueprint with these notes for permanence. - Enhance the poolweigher to consider the share network in the request. *# NetApp Snaplock/WORM feature* An RFE has been filed for supporting WORM shares [2] Retention time should be configurable. We can implement such things through extra specs or new APIs for such shares. *AIs*: - NetApp/SAP will ask around if there are other vendors that have the same feature. - If they don't, we should take the extra spec route and add the NetApp specific metadata keys. *# Cross-service-request-id + Enhancements to logging* We need to enable x-openstack-request-id, and use it when making cross service requests (to cinder/glance/neutron) for better tracking in the cross-service logs. We could have an implementation in Manila similar to what is available in Nova and Cinder [3]. This could become an internship theme. *AIs:* - carthaca will report a bug to document this request *# Backend driver operations based on resource metadata update API* Metadata currently is being used as tags to refer to db resources and when it is updated, we don't check if the share back end needs to update anything in the share. The backends should be notified of metadata modifications in case there is need to update something in the shares. Where metadata changes should be reflected to Backend drivers: snapshot policy, show-mount option *AIs:* - kpdev will document the proposed new behavior into a specification *# Technical Debt - SRBAC* gouthamr talked us through all of the work that is complete and what are the next steps in the next few cycles. *AIs:* - Increase test coverage. - Set "[oslo_policy]/enforce_new_defaults=True" as a default and see if it works. - Introduce the manager role for reset-state, promote out of sync replicas, force-delete resources. *# Retrospective on internship projects* We discussed what we have been working on with the ~10 interns we had in Manila at the end of the Caracal cycle, as well as our plans for Dalmatian There are also some mentoring opportunities in case people are interested. Please reach out :) *# All things CephFS* ashrodri talked us through the updates from the previous cycle and all the testing she has been doing with CI and enhancing the CI jobs, as well as introducing the ingress daemon service and so on. We are hitting some package issues for testing, and we are trying to figure those out. On new features we are planning: *- Manage/unmanage implementation in the CephFS driver* - This is already available to other drivers but we need to implement this to the CephFS drivers. We expect to be able to start on this work during the Dalmatian cycle*.* *- **Impact of the new ensure shares API in the CephFS driver* - Ensure shares comes from a request from CERN, while they had their Ceph Mon IPs changing but they needed to restart the services to reconstruct the export locations. - It ended up becoming a feature that will be used by many people and we are trying to make this as generic as possible, as it can also be useful for backend migrations. - A spec is being worked on by carloss [4] and we expect to complete this work during the Dalmatian cycle. *- DHSS=True implementation with the CephFS driver*. - We received several requests to have DHSS=True available for the CephFS driver and we are willing to start on this work after another request showed up [5]. - *AI*: gouthamr will propose a spec to document how it will work. *- NFSv3 known issue* - NFSv3 has a large number of deficiencies that NFS-Ganesha can't fill - there are external services like rpcbind, statd that handle portions of the NFS protocol that are natively supported in NFSv4.1+ - However, Microsoft Windows doesn't have a native NFSv4.1+ client; which means Windows guests can't mount CephFS/NFS shares - until now. - With Ceph Reef, the NFS service enables v4 and v3 export rules; which means a share can be mounted with NFS v3 or NFS v4.1+ - It isn't advised to mount with both protocols at the same time, nor is it advised to use NFSv3 outside of windows - because there's no recovery in case there's a failover in the NFS server *- Async mirroring* - This feature will use cephfs mirroring [6], which sounds like share replication but it has some differences. - It works similarly to the way it was designed in Cinder [7]. - *AI*: ashrodri will work on a blueprint to track this effort. *# Backup APIs* Backups are available for some releases, and NetApp + SAP are planning some enhancements and are willing to include a new backup type entity in Manila, similar to share types We agreed that the backup type properties should reuse the metadata mechanism to reuse code and UX, so we will end up also having backup type metadata. Migrations can be a concern, as the backup types were configuration blocks in the manila.conf file, so we will rely on administrators to properly migrate that, or even provide a script to do such migration. *AIs*: - NetApp will work on a specification for the backup updates *# Backup driver implementation with CBACK* CERN is working on adding a driver that integrates with their backup solution (CBACK) to manila, which uses Ceph storages as the backups backend. Zach showed us some findings during the implementation and talked about his plans and some challenges. The plan is to introduce the new backup driver during the Dalmatian cycle and also start testing on CI with it. *# Bug management stats and cycle reports* vhari shared the bug stats after the previous cycle and how encouraging they are. We reflected on the data and had a suggestion to expand our bugsquash events to two in a cycle, so that can help us reduce the bug backlog quicker. We had great stats on reducing doc bugs backlog with the help of a bugsquash late in the previous cycle. We also talked about possible role rotation and discussed what it means to be the Manila bug representative. *# Provide support for efficiency policy on NetApp shares* NetApp is figuring out a way to determine efficiency policies during the creation of shares individually. They want to implement this by introducing new share type extra specs to configure such things. DHSS=True is still being discussed, and this feature will be worked on for DHSS=False first. NetApp intends to implement this feature during the Dalmatian cycle. *# Technical Debt - sqlalchemy 2.0* Thanks to stephenfin and zzzek, all changes for sqlalchemy 2.0 were merged in the beginning of the Dalmatian release, as some issues showed up in the process and we couldn't figure them out. We will be backporting the changes that didn't make it to Caracal, so sqlalchemy 2.0 will also be supported by Manila. There are no current plans for backporting this further. We also need to evaluate removing the backref to back_populates. *AIs:* - Complete the backport of the changes to 2024.1 caracal *# Add response schema validation* The SDK team would like to generate OpenAPI schemas stored in-tree, to ensure things are complete and up-to-date, and to avoid landing another large deliverable on the SDK team, and to allow service teams to fix their own issues. OpenAPI 3.1 is a superset of JSONSchema, which means we can use the same tooling we currently use for this. *AIs*: - stephenfin will work on a spec and on bootstraping it, and more people would be able to pick it up. *# Shares encryption* We had a brief discussion about the design of this feature for Manila, which the spec is already merged. kpdev has already proposed two patches for this change [8] *AIs:* schedule a collaborative review early in the cycle so we can start reviewing it as early as possible. *# DB migration script squash * tkajinam brough to our attention during the previous cycle that there was room for enhancement in our migration scripts, as there are 70+ of them now and we could squash them. We are also considering automated ways to do this with sqlalchemy. *AIs*: - gouthamr/tkajinam will reach out to zzzek and stephenfin and ask if there is an automated way to make this process easier. [0] https://etherpad.opendev.org/p/dalmatian-ptg-manila [1] https://www.youtube.com/@openstackmanila/ [2] https://bugs.launchpad.net/manila/+bug/2060027 [3] https://blueprints.launchpad.net/nova/+spec/cross-service-request-id [4] https://review.opendev.org/c/openstack/manila-specs/+/915480 [5] https://github.com/nfs-ganesha/nfs-ganesha/issues/1087 [6] https://docs.ceph.com/en/latest/dev/cephfs-mirroring/ [7] https://docs.openstack.org/cinder/latest/contributor/replication.html [8] https://review.opendev.org/q/topic:%22bp/share-encryption%22 If you have questions, please feel free to reach out. Looking forward to a very productive release cycle with you! Regards, carloss

1 0

[kolla-ansible][Antelope][Heat] Heat UpdateWaitConditionHandle Issues
by Devin Patterson 16 Apr '24

16 Apr '24

Hello, We are creating a workflow to use Heat auto-scaling groups with wait conditions. The ideal goal would be to have the wait condition clear and require another signal when the Heat stack is updated. Trying to use the resource OS::Heat::UpdateWaitConditionHandle instead of OS::Heat::WaitConditionHandle. This works during initial creation, but when I udpdate the stack with a new configuration, I get the following error. UpdateWaitConditionHandle.update() got an unexpected keyword argument 'new_template_id' Any ideas on how to use wait conditions during stack updates or to fix the above error. Thanks in advance. Devin

2 2

[Glance] Dalmatian PTG Summary
by Pranali Deore 16 Apr '24

16 Apr '24

Hello Everyone, We had our Dalmatian virtual PTG between 9th APRIL to 12th APRIL 2024. Thanks to everyone who joined the virtual PTG sessions. Using Opendev Meetpad we had all the discussion around different topics for glance. Here is the short summary of the discussions. Tuesday , APRIL 9th 2024 # Caracal Retrospective On a positive note we have completed few important things like adding support of new centralized_db cache driver which will be enabled default for caching related operations and stop using sqlite database from caracal release onwards and deprecated Sqlite cache driver, we also have deprecated glance-cache-manage command in favor of the new Cache API, glance scrubber utility and its associated configuration options, location_strategy option since in Bobcat, we added new weighing mechanism which made the location strategy no longer required and continued working on adding new location API support which will replace the image-update mechanism for consumers like cinder and nova for OSSN-0090 and OSSN-0065. On the other side we decided to speed up the work we've had in flight and speed up the reviews. # Add missing CLI support for some Glance API in Openstack Client The migration work for adding missing CLI was initiated in the antelope cycle. We have added the SDK support for cache API , images API and metadef API There are image-create-via-import, image-upload, member commands & metadef tags patches are under review. This cycle we are hoping to get all the above mentioned patches merged and mark this work complete. # Introduce new sub-store NFS for filesystem store Currently in glance when we configure nfs store, we do not store any information about what server nfs is configured, what mount point is configured, if it is available or not. From the beginning nfs is treated as a local FS store in glance. So if the NFS server is down , we don't have any idea about that, we write the image to the local FS store and it doesn't get reflected to the nfs store if nfs is down. We decided to have this support similar to cinder, when it configures nfs backend it checks at the initial level whether mount point is available or not and again checks during volume upload whether connected to nfs mount point We will enhance file system store by introducing some config parameters to store this information by creating separate ini file which can have information related to nfs server store with which we can check nfs server is reachable or not with the use of os-brick library. # Driver test coverage Currently glance has CI coverage for 'cinder', 'rbd', 'swift' stores and functional tests for FS store. Vmware driver is deprecated in 2024.1 but we decided to keep it and revise the status after updating the existing thread with the outcome in manila ptg. For S3 driver, we decided to ask for any interest in maintaining s3 driver (with adding CI, fixing bugs, etc) and depending on the response we will go ahead and add the coverage. # DB Migration script cleanup Glance has been using alembic migrations on the upgrading database schema from old version to the new version, currently glance maintains migration scripts from liberty and upgraded as we moved ahead cycle wise. So we decided to squash some of these[1] until the oldest release not EOLed and which is wallaby currently and decided to document this and from now onwards we will support migration scripts post EOL cycle and scrub the migration once the cycle is EOL. Wednesday April 10th , 2024 # Migrate existing images to new store at once Glance currently supports copying existing images to another available store via import workflow but one image at a time. If the deployer wants to desommision the existing store and add a new one, then all the images need to be copied to the new store and delete those one by one from the existing one. In onder to solve this problem we decided to provide glance-manage command line utility by introducing new operation copy-images to copy all or selective images in newly added store and if we add a flag 'delete_from_source' and set it to true we can delete all the images from the source store Example: glance-manage copy_images --source-store store_1 --destination-store store_2 --delete_from_source After all images are copied we will print the stat on the console - copied images, deleted images, ignored- images ( if user deletes any image in between the copy operation then, we will raise and catch the NotFound exception and add it to the ignored stores. Admin can check the ignored images issue and incase it's present then the process can be reinitiated) # Introduce common configuration option(s) at base store level which can be used/accessible as a common for all available stores? Since glance supports separate configuration options for each store incase of multi store enabled with the same store type. So we decided to introduce common configuration options at base store level which can be used/accessible as a common for all available stores similar to cinder [2] # Generic Image migration + Optimization for same store migration Currently the preferred way of migration in glance is two step 1. Copy the image from source store to destination store 2. delete the image from source store With the above approach there are 2 problems: 1. requires manual intervention from operators after waiting for image copy to finish and then delete the image from source store 2. No way for stores to optimize the operation We decided to address it by introducing a migration operation in glance which will have two features [3] 1. A generic migration workflow where we will perform the image copy and delete in the same API operation 2. Allow an interface for glance store methods to optimize the migration if possible else it will fall back to the generic workflow # New Location APIs We have decided to have support of new location apis which will replace the image-update mechanism for consumers like cinder and nova for OSSN-0090 and OSSN-0065. The implementation patches are up for review along with the unit/functional tests, documentation, api version bump, client & sdk side support and tempest coverage[2] The Poc patches of nova and cinder are also there to test this new location api functionality. During last cycle we have noticed few issues with cinder store while testing the cinder side POC patches, so the glance_store & cinder side fix is up for review, and once those patches are merged and glance_store is released, we can merged the New Location API patches after getting approval from Nova & Cinder side since both are the consumers of these 2 new APIs. We also decided to have a new CI job where all newly added tempest tests for these new APIs are passed and add command line utility to re-calculate the hash of the active images which are without hash if hash calculation fails during location-import. Thursday April 11th , 2024 # Add support to test whether swift is deployed or not We have noticed that when glance is configured to use swift as a glance store and swift service is not enabled/deployed/down then glance api service starts but image creation fails and image will remain in importing state forever. In case of import we upload the data at staging store first and then we try to import it to swift store, at that time We decided to add the support at the store side to check at the startup if swift is up and running and if it's not running then log a warning and disabled the store for adding & delete opearetion. # Deprecate and remove 'metadata_encryption_key' and related functionality 'metadata_encryption_key' config option and its related functionality was added quite a long back ago and even though as per the description it encrypts the location metadata, it actually encrypts location url. It encrypts the location url only for image upload/import/download/show APIs, doesn't encrypt url on location APIs. If it gets enabled during upgrade then it will break the existing deployment since existing image urls are not being encrypted. Hence we decided to deprecate it in this cycle and if there is no objection seen then we will remove it in the next cycle or may this the current cycle as well. # Shelved instance image protection This is an Optional feature proposal to prevent deletion of shelved instance's image. Currently when an instance is shelved its image can be removed and afterwards an instance cannot be booted again. Glance team has suggested checking the implementation of 'cinder_encryption_key_deletion_policy' and check whether it is possible to implement on a similar count and update the existing spec[4] accordingly. Apart from above topics you can find other miscellaneous topics discussed in PTG etherpad [5] and the recordings of all the sessions and milestone wise priorities at the end. If you have any questions/suggestions then please join us in our weekly meeting(each Thursday on #openstack-meeting irc channel at 1400 UTC) [1]: https://review.opendev.org/q/topic:%22db-migration-squash%22 [2]: https://opendev.org/openstack/cinder/src/commit/935f08e032b31d4628881d3a053… [3] : https://review.opendev.org/c/openstack/glance-specs/+/914639 [4]: https://review.opendev.org/c/openstack/glance-specs/+/915475/1/specs/2024.2… [5]: https://etherpad.opendev.org/p/apr2024-ptg-glance#L1

1 0

[ironic][PTG] Ironic 2024.2 PTG summary
by Riccardo Pittau 16 Apr '24

16 Apr '24

Hello Ironicers! Here's a summary of the discussions around the major topics at the Ironic PTG 2024.2 # Caracal retrospective # We took our time to look back at the Caracal development cycle, how it was for the ironic project, celebrate what we've accomplished, and of course also understand if some of the work started during Caracal needed to be continued in Dalmatian. We're quite happy to say that most of the goals we've set for Caracal have been reached, and we've actually been able to do much more than planned! For example we delivered the HttpBoot support for Redfish, we've been able to tackle a lot of old bugs and keep pace with the migration from storyboard to launchpad, almost finished the merge of Inspector into Ironic, and marked multiple old drivers for removal. # Present and Future of Ironic # We've analyzed the current status of Ironic and asked ourselves: "Where do we want Ironic to go?" In the past years we started looking beyond Openstack and we've took some steps to get into that direction, and we can say that Ironic went over the Openstack borders, becoming more independent. Currently Ironic can be used in three ways: - Openstack Integrated, the more clear and established way - as the core engine of Metal3, with good documentation for various use cases, but still growing and with margin for improvement - standalone, which still requires some work, a much clearer path forward and requirements We really want to keep investing in standalone Ironic more in the future, but to do that we need to take some decisions based on the vision we have on server provisioning from here to 5 years. Lots of questions we asked ourselves on how to resolve some problems connected to having a standalone bare metal provisioning service, mostly related to networking (e.g. secureboot, virtualmedia), will expand and find possible answers in other topics. # Redfish topics # Talking about present and future, Redfish is the current constantly evolving and improving standard protocol to directly communicate with controllers of bare metal devices. Ironic supports it since a while and of course there's more and more demand for new features to support or to expand the current capabilities. The discussion was mainly around an alternative, and possibly easier way to provide images for firmware updates and virtual media boot using a "push" model instead of the current "pull", with two proposals: - using the UpdateService already present in the Redfish standard - using the Virtual Media Push as a new feature currently under discussion with DMTF Another major topic is the support for TLS connection to the BMC, which already has a design proposal from one major contributor, Fujitsu. In addition we'll also have to explore the "other side" of the connection, so from the BMC to the ironic services, which will be one of the goals for Dalmatian. # CI related topics# CI has always had great importance for the Ironic project being one of the major consumers in terms of resources. It's not a case that that first related topic was how to slim down the CI usage! During the Caracal cycle we've been able to reduce the number of jobs run by the Ironic project, but we've also added some more. We came to the conclusion that we need to take an approach where we stack more tests in fewer jobs, trying to consolidate down jobs as much as possible and minimize boot interface variation testing. During the Dalmatian cycle we'll work first on trying to have Redfish and ipmi in a single ironic job, and update the list of jobs to understand where we can avoid duplication. At some point we'll also have to make space for some more deep tests on ARM machines. We've also decided to give Codespell tests a try, and explore the possibility of having some pre-commit hooks, and, after some technical considerations, move away from Tinycore as our base for the IPA ramdisk in CI, gentoo being the most likely candidate as a replacement. # xPUs # With xPUs in this case we mean IPU and DPU (not to be confused with TPU or GPU) which are some Processing Units that are designed for specific applications and data types. Usually DPUs are embedded in edge network cards, while IPUs are specifically designed for Artificial Intelligence/Machine Learning. There are multiple challenges in order to support those devices, depending on the "vision" of the vendors, some view them having full Operating Systems, some as having an OS just as "firmware", most or all of them would like remote management, which is where Ironic can really make an impact. Even though there are multiple use cases and scenarios where the use of xPUs is highly valued, and the wishlist of potential features is quite long, the first step we need to take is to get some real hardware and start testing, which is the real challenge we'll have to deal with next. # Secure Boot # We've made huge steps forward in supporting Secure Boot, the next big one would be supporting custom keys and providing means to upload and update them. Before doing that we need to clarify some aspects of Secure Boot, especially the "security vs convenience". In the Dalmatian cycle will focus mainly on updating our documentation, provide a better picture to users, and start exploring possible solutions for the secure custom keys management. # Future of Networking # Reconnecting to the future of Ironic, networking represents the next step for a truly standalone Ironic. This means finding alternatives to Openstack-integrated scenarios and therefore to Neutron. In Metal3 we're solving the problem using a separate IPAM, but this is still not enough for a complete Ironic standalone, in the end what we really need is flat network control, which at the moment we don't really have an alternative for. We realized that the topic is vast, we've just scratched the surface and we need to invest much more time on it, having more discussions to go deeper into it and start researching alternatives and tools for our goal. That is (almost) all folks! You can find all the topics and more details in the discussions notes here: https://etherpad.opendev.org/p/ironic-ptg-april-202 Feel free to answer directly in this thread in case you have questions or comments, or contact the ironic team on IRC. Thanks to everyone who participated in the PTG! Have a great Dalmatian development cycle! Ciao Riccardo

1 0

[publiccloud-sig] Reminder - next meeting April 17th - 0700 UTC
by Felix Kronlage-Dammers 16 Apr '24

16 Apr '24

Hi everyone, This Wednesday (April 17th) the next meeting of the public cloud sig is going to happen. We’ll be meeting at 0700 UTC here: https://meetpad.opendev.org/publiccloud-sig See also here for all other details: https://wiki.openstack.org/wiki/PublicCloudSIG See you tomorrow! felix -- Felix Kronlage-Dammers Sovereign Cloud Stack — standardized, built and operated by many Ein Projekt der Open Source Business Alliance - Bundesverband für digitale Souveränität e.V. Tel.: +49-30-206539-205 | Matrix: @fkronlage:matrix.org | fkr(a)osb-alliance.com

1 0

[all] ORM apocalypse mostly averted (a.k.a. SQLAlchemy 2.0 is here)
by Stephen Finucane 15 Apr '24

15 Apr '24

o/ A whole 2 years and 8 months to the day after I first communicated about it [1], it would appear the requirements bump to SQLAlchemy 2.0 [2] is finally ready to go. I suspect most if not all service projects are familiar with SQLAlchemy 2.0 at this point, having needed to fix whatever compatibility issues were seen. For those that aren't, I suggest reading my previous emails on the matter. So what happens next? Hopefully for the vast majority of projects the answer should be "nothing": many projects now have sqlalchemy-tips jobs that are designed to run unit and/or integration tests with the latest versions of SQLAlchemy, Alembic and oslo.db so the switchover should be seamless. I foresee three situations: * For projects that continue working as-is post-bump, you may wish to delete the sqlalchemy-tips jobs now. The jobs were designed as a stop gap measure to prevent projects regressing on SQLAlchemy 2.0 support while we got other projects over the line. While there is some limited value in keeping these jobs around, they do consume resources and - to the best of my knowledge - the SQLAlchemy community is not planning to release a 3.0 version of SQLAlchemy (or 2.0 version of Alembic) any time soon :) The requirements jobs gates on many projects and should identify compatibility issues with these libraries going forward, so it's probably best to drop them from the projects. I'll push a couple of patches shortly to do just this. Feel free to accept or reject them as you see fit. * For projects that are supposed to be SQLAlchemy 2.0 Ready (TM) but start seeing issues that the sqlalchemy-tips jobs didn't catch (because, say, the job was running unit tests rather than functional tests and the unit tests are missing coverage), I'd encourage you to look through what is now a fairly extensive repository of patches [3] that we've built up while addressing SQLAlchemy 2.0 compatibility issues. These are mostly all tagged with the sqlalchemy-20 topic and there's a very good chance that a patch addressing your specific issue has already been submitted to another project. * For projects that were not in the gating queue for requirements bumps, have not prepped for SQLAlchemy, and start failing catastrophically post-bump: have you not been listening to me?! :) You've got some work to do but fortunately that work should be relatively simple (if a bit tedious). As noted above, there are a *lot* of patches that you can look through to identify solutions to your compatibility issues. My preferred strategy - which is the one also advocated for by the SQLAlchemy 2.x docs [4] - has been to configure the warnings filter to raise an error for all SQLAlchemy deprecation warnings then filter out those that we actually hit and iteratively work to remove these filters. That won't work now that SQLAlchemy 2.0 is in upper-constraints so you're going to have to fix it all in one go. You may wish to adopt the standard approach locally though, before squashing all the commits upon review. This has already consumed far (far!) too much of my time so I won't offer to undertake the migration of any outstanding projects. I am, however, happy to field questions and point to existing patches that resolve a given issue. Hopefully none of it will be necessary though. Cheers, Stephen [1] https://lists.openstack.org/pipermail/openstack-discuss/2021-August/024122.… [2] https://review.opendev.org/c/openstack/requirements/+/879743 [3] https://review.opendev.org/q/topic:sqlalchemy-20 [4] https://docs.sqlalchemy.org/en/20/changelog/migration_20.html

11 13

[openstack-helm] 2024.2 PTG summary
by Vladimir Kozhukalov 15 Apr '24

15 Apr '24

Dear Openstack-helmers, Here is the short summary of our discussion during PTG 2024.2. If you would like to further discuss some of these topics or have any other questions you are welcome to continue the discussion either in this mailing thread or start a new one. ## Migration from legacy Ceph OSH charts to Rook During 2024.1 we developed the migration procedure which seems to work well at least for some configurations. At the moment we have a doc [1] that describes the procedure and also there is a script [2] which can be used as an example. The procedure is obviously quite dangerous and we decided to put some efforts to create a test job for this. Anyway, at this point it is recommended to use Rook for managing Ceph clusters. Once we have the migration test job and we are sure it works well enough we will officially deprecate the legacy Ceph charts with the deprecation period of one or two release cycles. ## MariaDB operator At the moment the OSH MariaDB chart [3] is recommended by default for managing MariaDB clusters. We are not yet ready to switch to the MariaDB-operator [4] (and the mariadb-cluster OSH chart [5]) by default for our test jobs. We will continue supporting MariaDB-operator test job and will try to work closer with the operator community. Ideally, we would like the MariaDB-operator project to provide their own Helm chart which we could utilize. ## OVN Our OVN test deployment jobs seem to work well and we can recommend using OVN as the default Openstack networking backend. However, migrating from OVS to OVN is not trivial and assumes addressing at least the following two points: - Currently we don't have the migration procedure like, for example, this [6], [7] in the context of OSH. It would be great to have a volunteer to contribute this. - Some of our users have OVS customizations which seem not to have 1-1 feature parity with OVN. So, even if we have the migration strategy, the feature alignment is going to take some time. We agreed to continue supporting OVS and OVN jobs 50/50 in this release cycle. Also it seems to worth it to initiate a wider discussion about the migration itself and about the timeline. ## Tacker documentation and testing During 2023.2 we added the Tacker chart [8] but it is not mentioned in the user deployment documetation. We agreed that the Tacker team will contribute the Tacker and the Barbican sections to the OSH deployment documentation (Barbican is needed for Tacker). There is a deployment test job for Tacker [9] although it is not currently a part of the check pipeline. We agreed to improve it so it not only deploys the Tacker project but also it should run some test scenarios against it. ## Third party RabbitMQ chart Our long term strategy is to focus more on Openstack charts and to use third parties for manging backend infrastructure wherever possible. So it looks like it worth it to do research regarding possible usage of the RabbitMQ operator [10]. We agreed that we are going to put efforts during 2024.2 release cycle to give it a try and probably to create a test job that will utilize this operator. ## Improve end user experience Most of our users consume the OSH charts as part of their CI/CD infrastructure and consider OSH as a Openstack managing framework rather than end-to-end solution. However, for the new users who would like to try the Openstack running on top of K8s with the minimal efforts it is important to have an experience similar to what they usually have with other Helm charts. This assumes the following - a user has a K8s cluster (possibly with some prerequisites) and the K8s API endpoint - a user has kubectl/helm command line tools configured (to connect to K8s API endpoint) and ready to use (probably from a remote host) - a user is not supposed to clone any git repositories to deploy the Openstack - a user is able to consume Helm charts published on a Helm repo During 2024.1 we have been working to imporove the deploy-env Ansible role to support single/multi-node environments, to make it possible to run kubectl/helm CLI tools from a remote node, to expose Openstack services via Metallb, etc. At this point we are ready to have a test job that will imitate the end user behavior with the only exception that for test jobs we heavily rely on two scripts `get-values-overrides.sh` [11] and `wait-for-pods.sh` [12]. They are not absolutely necessary but still users can benefit from using them and it looks like we can easily move this functionality to a Helm plugin. So, eventually the deployment can be performed with minimal efforts using pre-published charts. ## Widen the range of K8s configurations used for Openstack deployment Now all the test jobs are run with the same K8s configuration (Calico as a CNI, Ingress-Nginx as a ingress controller) and we are trying to stay as less K8s details dependent as possible. At the same time we could probably create test jobs that will exercise some other K8s configurations like for example - Cilium/Kube-Router as a CNI implementation - HAProxy as an ingress controller This seems to be minor, but still volunteers are welcome to contribute. [1] https://docs.openstack.org/openstack-helm/latest/troubleshooting/migrate-ce… [2] https://opendev.org/openstack/openstack-helm-infra/src/branch/master/tools/… [3] https://opendev.org/openstack/openstack-helm-infra/src/branch/master/mariadb [4] https://github.com/mariadb-operator/mariadb-operator [5] https://opendev.org/openstack/openstack-helm-infra/src/branch/master/mariad… [6] https://docs.openstack.org/neutron/latest/ovn/migration.html [7] https://opendev.org/openstack/neutron/src/branch/master/tools/ovn_migration [8] https://opendev.org/openstack/openstack-helm/src/branch/master/tacker [9] https://opendev.org/openstack/openstack-helm/src/branch/master/zuul.d/base.… [10] https://www.rabbitmq.com/kubernetes/operator/install-operator [11] https://opendev.org/openstack/openstack-helm-infra/src/branch/master/tools/… [12] https://opendev.org/openstack/openstack-helm-infra/src/branch/master/tools/… -- Best regards, Kozhukalov Vladimir

1 0

[tc] Next Meeting of Technical Committee Tomorrow, April 16
by Jay Faulkner 15 Apr '24

15 Apr '24

Hi all, The next scheduled meeting of the OpenStack Technical Committee is Tomorrow, Tuesday April 16 at 1800 UTC in #openstack-tc on OFTC. The proposed agenda is: * Roll call * Follow up on tracked action items ** gmann to add grenade skip level job simplification topic in QA PTG ** gmann will send an email to the openstack-discuss list to cancel next week's TC IRC meeting * Gate health check * TC vPTG 2024.2 Follow-ups ** https://etherpad.opendev.org/p/apr2024-ptg-os-tc * TC Chair Election ** https://governance.openstack.org/tc/reference/charter.html#tc-chair * Open Discussion and Reviews See you there! -- Jay Faulkner OpenStack TC Chair

1 0

Red hat Configuration with Ceph(Cephadm tool on ubuntu
by Adivya Singh 15 Apr '24

15 Apr '24

Hi All, Regarding red hat open stack integration with ubuntu ceph installed with ceph adm tool Can you please guide me on this, What file changes need to be in Storage -config, Storage Environment for a Deployer script to pick it up regarding Cinder integration with Ceph Regards Adivya Singh

3 7

[neutron] Bug deputy report (week starting on April 8)
by Bernard Cafarelli 15 Apr '24

15 Apr '24

Hey neutrinos, here is the list of bugs filled during the PTG week - not too long as apparently people were busy attending the PTG sessions! The first 2 bugs are currently unassigned Medium * OVN DNS not working as documented - https://bugs.launchpad.net/neutron/+bug/2059405 Needs further triaging * [OVN] Changing public network MTU does not update router port gateway_mtu option - https://bugs.launchpad.net/neutron/+bug/2060828 Unassigned, reproducer described in bug Low * [ML2][OVS] more precise flow table cleaning - https://bugs.launchpad.net/neutron/+bug/2060587 Patch in progress https://review.opendev.org/c/openstack/neutron/+/915302 Opened RFE * Add 'trusted_vif' field to the port attributes - https://bugs.launchpad.net/neutron/+bug/2060916/ Opinion * already associated floating ip can be associated to another server without check or warning - https://bugs.launchpad.net/neutron/+bug/2060808 * removing floating ip from server does not check the server - https://bugs.launchpad.net/neutron/+bug/2060812 Linked bugs (one for removal, one for reassigning), discussed last week in PTG, waiting on nova team opinion Needs more info * neutron-dhcp-agent attemps to read pid.haproxy but can't - https://bugs.launchpad.net/neutron/+bug/2060974 Discussed on IRC last week, waiting for confirmation but this should soon be closed -- Bernard Cafarelli

1 0

[release] Release countdown for week R-24
by Thierry Carrez 12 Apr '24

12 Apr '24

Welcome back to the release countdown emails! These will be sent at major points in the 2024.2 "Dalmatian" development cycle, which should conclude with a final release on October 2nd, 2024. Development Focus ----------------- At this stage in the release cycle, focus should be on planning the 2024.2 "Dalmatian" development cycle, assessing Dalmatian community goals and approving Dalmatian specs. General Information ------------------- The Dalmatian cycle is of pretty standard length, 26 weeks. In case you haven't seen it yet, please take a look over the schedule for this release: https://releases.openstack.org/dalmatian/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 2024.1 "Caracal" release are continued in 2024.2 "Dalmatian" with a similar release model. Upcoming Deadlines & Dates -------------------------- Dalmatian-1 milestone: May 16 -- Thierry Carrez (ttx)

1 0

[cinder][vmt] updating the cinder core security contacts team
by Brian Rosmaita 12 Apr '24

12 Apr '24

Greetings to all people interested in cinder security, The “Cinder Core security contacts” team [0] is a proper subset of the cinder core team who are notified when the OpenStack VMT assigns a private security bug to cinder following the vulnerability management process [1]. The VMT prefers that this group be kept small, so often adding someone entails removing someone else. I propose the following changes: add: - Jon Bernard (current cinder core, and Cinder PTL for Dalmatian) remove: the following people, who have not worked on security bugs over the past few development cycles: - Ivan Kolodyazhny - Sean McGinnis - Walt Boring The Cinder project team thanks Ivan, Sean, and Walt for their past security service to the project. If you have any comments or concerns, please reply on the mailing list before 12:00 UTC Friday 12 April 2024. cheers, brian [0] https://launchpad.net/~cinder-coresec/+members [1] https://security.openstack.org/vmt-process.html

3 3

[openstack][kolla-ansible]
by Nguyễn Hữu Khôi 12 Apr '24

12 Apr '24

Hello. I am testing a case when I lost all my openstack cluster. I just have a full db backup and volumes(my storage node still alive). I deploy a new cluster with same node's name after that I recover db from backup and the cluster is up but I cannot see my instances. When I click on instance tab or volume tab, I see errors: [image: image.png] I hope you will share experiences. Nguyen Huu Khoi

1 2

[openstacksdk][older pythons] Reverting a small mypy change in openstackapi
by Michael Still 12 Apr '24

12 Apr '24

Hi, I discovered the issue fixed by https://review.opendev.org/c/openstack/openstacksdk/+/915199 accidentally while rebased Kerbside patches, and I am wondering who I should ask nicely for a review. Its a relatively small change, but does regress mypy support in return for working correctly on python versions below python 3.10, which we promise to support right now. Thanks, Michael

1 0

[Glance] Dalmatian vPTG Updates
by Pranali Deore 11 Apr '24

11 Apr '24

Hello Everyone, We have concluded Glance Dalmatian vPTG yesterday. I will share the summary early next week. You can find tentative milestone wise priorities for glance in PTG etherpad[1]. Join us in the weekly meeting on Thursday(1400 UTC) if you have any doubts/suggestions. Thanks & Regards, Pranali Deore [1: https://etherpad.opendev.org/p/apr2024-ptg-glance#L390

1 0

[i18n][PTG] I18n SIG 2024.2 (Dalmatian) PTG Planning
by Ian Y. Choi 11 Apr '24

11 Apr '24

Hi, PTG is happening this week. @seongsoo and I have blocked time slots (Thu 21-22 UTC & Fri 14-16 UTC). Anyone can check via https://ptg.opendev.org/ptg.html and please let me know if more discussion is needed during PTG. Those are topics what I am thinking currently but it is open - feel free to suggest any topic to be discussed: - Moving forward on open reviews for i18n: at least, there are several pending items on openstack/i18n repo - openstack/i18n repository structure discussion to embrace the use of weblate - wlc library on tools/weblate and others including the addition of tox environment and corresponding requirements.txt - Pilot work progress discussion on governance translation support on weblate platform - Overall feasible migration plan discussion to sunset translate.openstack.org earlier than zanata.translate.org Discussions will be shared via Etherpad: https://etherpad.opendev.org/p/apr2024-ptg-i18n . Lastly, please don't forget to register if you have forgotten: https://ptg2024.openinfra.dev/ :) Looking forward to a productive PTG with I18n. Thank you, /Ian

2 1

[all][tc] Modernize Python Stack
by Niklas Schwarz 10 Apr '24

10 Apr '24

Hello, I have just ran over the mailing listing post OpenStack 2024.2 testing runtime by Ganshyam Mann [1] on dropping support for python3.8 for the upcoming Openstack 2024.2 release. This post and some small contributions to some openstack components have lead me to write this post. What I would like to suggest to modernize the Python-Stack used for OpenStack. Such a modernization includes: - A current python version - A modern and up to date static code analysis - Introduce type annotations Let me explain what I mean: A current python version: The current supported Python versions are Python 3.8 to Python 3.11 [2]. As of writing, OpenStack Yoga was just moved to unmaintained. To install this release, e.g. on an Ubuntu Jammy operating system the packages are included in the Ubuntu-Packages. The default Python version on an Ubuntu 22.04 operating system is Python3.10. And looking at the support of the Python versions [3] Python 3.8 to 3.10 only receive security updates but the end is near for Python 3.8 to be out of support. The policy defined which Python version should be used for testing [4] will result that Python 3.8 is still used for the OpenStack 2024.1 release [5]. And this will also result in required support for Python3.8 in the upcoming releases of OpenStack. I my opinion the policy should be reworked and the OpenStack releases should be more aggressive on dropping support for older Python versions. Modern features of the language cannot be otherwise be used, therefor improvements in speed, security and general toolchain/ecosystem cannot be fully leveraged. By defining the lower bound of the Python Version we are limiting ourself to this version but we might also reduce the features we can use because of deprecations of the newer versions . A modern and up to date static code analysis: Currently flake8 and pylint are used both of which are modern analysis tools. But their configuration is in my opinion not up to date. Lets have a look at the configuration of the neutron-lib [6]. As seen a lot of rules are disabled by the configuration and are needed at the current moment at the state of the project. In addition some rules need to be adjusted such as the line length (80 characters is a very aggressive limit and on most modern displays a line length of 100 to 120 can fit without any problems, personal opinion). The adjustment of the static code analysis besides opinionated rules will lead me to my third point to modernize the Python stack used Introduce type annotations Python type annotations are well supported in the current Python versions and through the typing package additional types are added. The introduction of type annotations will improve the developer experience. This is also motivated by the Python foundation in pep-484 [7]. Because of the type annotation all modern IDEs can provide (more precise) type hints. The type hints can and in in my experience will reduce the introduction of bugs (accessing members or calling methods, no logical bugs) and will shorten the time to develop a new feature or fix a logical bug and do not run in runtime exceptions. The datatypes passed to a method are clear and we do not need to dig down a rabbithole to find out what is passed to a method. The name of a variable does not always tell the truth. As an example I want to look at a patch [8] for the neutron-vpnaas component. Christian Rohmann and I worked on this patch for the component together (this has also lead me to write this email) to improve the reconciling for VPNaaS. It took as along time to find out that a RouterInformation object is passed in to a method instead of a router but the variable was named router. We both agreed on that in the first place the naming of the variable was wrong but type annotations would have saved us a good amount of time. This does not mean that the naming is not important and that type annotations will save the world, the context which includes the name of variables is important and type annotations will add additional information to the context. And I have just touched the surface on what is possible with the introduction of type annotations, thinking of automatic document generation, test generation, even code generation,... As a reference to my point modernizing the static analysis this can then also include the introduction of mypy to check the types used. Of course such a change cannot be done in one big commit and needs time but I suggest to start adding type annotations and improve the overall code quality of the OpenStack services, starting with the oslo packages as they are used by mostly all OpenStack components. Of course such changes cannot be done for such a huge project in one day. It took a long time to remove support for Python 2. So I do not expect such changes to happen immediately. But it would be nice to have a discussion about it and maybe create a road map and adjust some policy on supported Python versions and create new policies how to write Python code and what additional tools should be used. I can also understand if not everything is possible but the last two points need to be addressed in my opinion. These changes will lead overall to better code quality but most important the introduction to the big code base will be easier for new developers and reviewers will also have a better time. Best regards Niklas [1] https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… [2] https://docs.openstack.org/tempest/latest/supported_version.html [3] https://devguide.python.org/versions/ [4] https://governance.openstack.org/tc/resolutions/20181024-python-update-proc… [5] https://governance.openstack.org/tc/reference/runtimes/2024.1.html [6] https://github.com/openstack/neutron-lib/blob/master/.pylintrc [7] https://peps.python.org/pep-0484/#rationale-and-goals [8] https://review.opendev.org/c/openstack/neutron-vpnaas/+/875745

15 27

[manila] Cancelling Apr 11th and Apr 18 weekly meetings
by Carlos Silva 10 Apr '24

10 Apr '24

Hello, zorillas! As this is PTG week, let's cancel this week's upstream meeting and also next week's meeting as we usually do. Thank you! carloss

1 0

[kolla-ansible][horizon]Create instance default parameters
by Franck VEDEL 10 Apr '24

10 Apr '24

Hi, With horizon, is it possible de have this default parameter when you create an instance: in source, create a new volume: « No ». And.. if it’s possible, how configure this with kolla-ansible ? Thank’s for your help. Franck

2 4

[keystone] Weekly meeting canceled 10-April-2024
by Dave Wilde 10 Apr '24

10 Apr '24

Hello all, I'm canceling this weeks keystone meeting in lieu of the PTG sessions we're holding today and tomorrow. Hope to see you there! /Dave

1 0

[kolla][kolla-ansible] How to debug container crashing or restarting
by Satish Patel 10 Apr '24

10 Apr '24

Folks, As soon as I deployed opensearch on the Zed release of openstack and found the opensearch_dashborad container kept restarting. So my question is how do I troubleshoot this kind of container crashing issue. Are there any guides to follow like stop container restart tasks and then get inside container check logs etc? I have checked docker logs <container_name> but didn't find any strange issue and logs are empty in /var/log/kolla/opensearch_dashborad/ In short I am clueless and I would like to change restart policy in docker so I can manually restart daemon to debug my issue. This is what logs showing in docker logs opensearch_dashboard INFO:__main__:Setting permission for /usr/share/opensearch-dashboards/node_modules/ajv/dist/refs/json-schema-2020-12/index.js INFO:__main__:Setting permission for /usr/share/opensearch-dashboards/node_modules/ajv/dist/refs/json-schema-2020-12/meta/meta-data.json INFO:__main__:Setting permission for /usr/share/opensearch-dashboards/node_modules/ajv/dist/refs/json-schema-2020-12/meta/core.json INFO:__main__:Setting permission for /usr/share/opensearch-dashboards/node_modules/ajv/dist/refs/json-schema-2020-12/meta/unevaluated.json INFO:__main__:Setting permission for /usr/share/opensearch-dashboards/node_modules/ajv/dist/refs/json-schema-2020-12/meta/content.json INFO:__main__:Setting permission for /usr/share/opensearch-dashboards/node_modules/ajv/dist/refs/json-schema-2020-12/meta/applicator.json INFO:__main__:Setting permission for /usr/share/opensearch-dashboards/node_modules/ajv/dist/refs/json-schema-2020-12/meta/format-annotation.json INFO:__main__:Setting permission for /usr/share/opensearch-dashboards/node_modules/ajv/dist/refs/json-schema-2020-12/meta/validation.json INFO:__main__:Setting permission for /usr/share/opensearch-dashboards/node_modules/ajv/dist/refs/json-schema-2019-09/meta INFO:__main__:Setting permission for /usr/share/opensearch-dashboards/node_modules/ajv/dist/refs/json-schema-2019-09/schema.json INFO:__main__:Setting permission for /usr/share/opensearch-dashboards/node_modules/ajv/dist/refs/json-schema-2019-09/index.js INFO:__main__:Setting permission for /usr/share/opensearch-dashboards/node_modules/ajv/dist/refs/json-schema-2019-09/meta/meta-data.json INFO:__main__:Setting permission for /usr/share/opensearch-dashboards/node_modules/ajv/dist/refs/json-schema-2019-09/meta/core.json INFO:__main__:Setting permission for /usr/share/opensearch-dashboards/node_modules/ajv/dist/refs/json-schema-2019-09/meta/content.json INFO:__main__:Setting permission for /usr/share/opensearch-dashboards/node_modules/ajv/dist/refs/json-schema-2019-09/meta/applicator.json INFO:__main__:Setting permission for /usr/share/opensearch-dashboards/node_modules/ajv/dist/refs/json-schema-2019-09/meta/validation.json INFO:__main__:Setting permission for /usr/share/opensearch-dashboards/node_modules/ajv/dist/refs/json-schema-2019-09/meta/format.json INFO:__main__:Setting permission for /usr/share/opensearch-dashboards/node_modules/ajv/dist/vocabularies/core INFO:__main__:Setting permission for /usr/share/opensearch-dashboards/node_modules/ajv/dist/vocabularies/format INFO:__main__:Setting permission for /usr/share/opensearch-dashboards/node_modules/ajv/dist/vocabularies/discriminator INFO:__main__:Setting permission for /usr/share/opensearch-dashboards/node_modules/ajv/dist/vocabularies/jtd INFO:__main__:Setting permission for /usr/share/opensearch-dashboards/node_modules/ajv/dist/vocabularies/validation INFO:__main__:Setting permission for /usr/share/opensearch-dashboards/node_modules/ajv/dist/vocabularies/applicator INFO:__main__:Setting permission for /usr/share/opensearch-dashboards/node_modules/ajv/dist/vocabularies/dynamic INFO:__main__:Setting permission for /usr/share/opensearch-dashboards/node_mo

2 1

[ironic] PTG schedula
by Riccardo Pittau 10 Apr '24

10 Apr '24

Hello ironicers! A quick reminder on the Ironic PTG schedule for this week: Tuesday 09/04 13-17 UTC Wednesday 10/04 13-17 UTC Thursday 11/04 13-16 UTC You can find the full schedule and topics here https://etherpad.opendev.org/p/ironic-ptg-april-2024 Ciao Riccardo

1 2

[Glance] Cancelling Weekly Meeting for this Week
by Pranali Deore 09 Apr '24

09 Apr '24

Hello, As discussed during last week's meeting, cancelling the meeting for this week(11th April) since we all are meeting in PTG. See you all at PTG ! Thanks & Regards, Pranali

1 0

[Octavia] weekly meeting cancelled
by Gregory Thiemonge 09 Apr '24

09 Apr '24

Hi Folks, Tomorrow's weekly meeting is cancelled because of the PTG. Thanks, Greg

1 0

[kolla] cancelling weekly meeting on 10th April
by Michał Nasiadka 09 Apr '24

09 Apr '24

Hello, Since we all met on PTG sessions - let’s cancel weekly meeting this week. See you on 17th April Michał Nasiadka mnasiadka(a)gmail.com

1 0

[all] Package reproducibility: shall we hard-wire our CI to avoid it in the future?
by Thomas Goirand 09 Apr '24

09 Apr '24

Hi, It used to be that a number of packages were not reproducible. If you do not know why reproducibility of packages is important, please read on: https://reproducible-builds.org/ This has been patched numerous times in numerous packages. However, it looks like the community is still not aware of the problem, and how to avoid it. One of the very common pitfall, is adding a default in an oslo.config string, that leaks properties of the build host, like for example the hostname, the number of CPU cores, and so on. Here's a very common example that was commited last summer: https://review.opendev.org/c/openstack/oslo.messaging/+/889425/9/oslo_messa… Yet the fix is super simple, thanks to oslo.messaging sample_default: https://review.opendev.org/c/openstack/oslo.messaging/+/915314 If I'm writing this, it is *not* to point at anyone, especially *not* the commiter of the above patch. it just happen to be the latest occurrence I noticed thanks to the Debian bug report: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1068377 This message is only to raise awareness of the problem, and avoid having it happen again. I also wonder: would it be possible to have our CI avoid this type of mistake? It wouldn't be so hard to have the doc build twice, with different hostname, CPUs, etc. configuration, would it? (note: I'm not volunteering, just pushing for the idea...) Cheers, Thomas Goirand (zigo)

2 1

[openstack-helm] PTG schedule
by Vladimir Kozhukalov 08 Apr '24

08 Apr '24

Hey team, This is just a reminder that we booked two hours on Wednesday 04/10/2024 at 13:00 UTC and 14:00 UTC in the Cactus meeting room. Etherpad is here [1]. Feel free to add your topics for the discussion. Booking table is here [2]. [1] https://etherpad.opendev.org/p/apr2024-ptg-os-helm [2] https://ptg.opendev.org/ptg.html -- Best regards, Kozhukalov Vladimir

1 0

OpenStack OVN add secondary external network
by damage.alders-0j＠icloud.com 08 Apr '24

08 Apr '24

I've setup OpenStack version 2023.2 with with devstack on a Ubuntu 22.04 baremetal. I originally had one NIC (eth1, 192.XX.XX.XX) that works fine. Now I added a second NIC (eth2, 10.XX.XX.XX) to my machine and tried to add a secondary external network through: sudo ovs-vsctl add-br br-ex2 sudo ovs-vsctl add-port br-ex2 eth2 sudo ovs-vsctl set open . external-ids:ovn-bridge-mappings=public2:br-ex2 sudo ovs-vsctl set open . external-ids:ovn-cms-options="enable-chassis-as-gw" then my whole machine (including host and all instances) lost dns service, I can only ping ip addresses such as 8.8.8.8 instead of google.com. To be precise, I found out I lose dns service after `sudo ovs-vsctl add-port br-ex2 eth2` command. (Yes, I've moved ip from eth2 to br-ex2, but didn't help) I kept on creating a network and a router: openstack network create public2 --provider-network-type flat --provider-physical-network public2 --external openstack subnet create public2-subnet --network public2 --subnet-range 10.XX.XX.0/24 --no-dhcp --gateway 10.XX.XX.1 --allocation-pool start=10.XX.XX.10,end=10.XX.XX.30 openstack router create bridge-router --external-gateway public2 openstack router add subnet bridge-router shared-public2-subnet At this point, the router is accessible from eth2 after `sudo ovs-vsctl set open . external-ids:ovn-bridge-mappings=public2:br-ex2` command, but after I tried to allocate a floating ip from public2 to any instance, the instance is just not accessible from that ip. My ultimate goal is to be able to allocate floating ip to instances from eth2, so I can access instances from both eth1 and eth2 networks, but now I lost dns service and I'm unable to access instances from the allocated eth2 floating ip. Any suggestions?

1 0

[kolla] Dalmatian vPTG reminder
by Michał Nasiadka 08 Apr '24

08 Apr '24

Hello Koalas, This year the PTG slots are following: Kolla/Kolla-Ansible: Monday, 8th April, 13:00 - 17:00 UTC Kayobe: Tuesday, 9th April, 13:00 - 15:00 UTC You can check the slots always on the PTG website - https://ptg.opendev.org/ Etherpad link: https://etherpad.opendev.org/p/kolla-dalmatian-ptg See you on Monday!

2 1

[neutron] CI Meeting cancelled this week
by Yatin Karel 08 Apr '24

08 Apr '24

Hello Neutron Team !! As discussed over the previous meeting cancelling this week CI meeting for vPTG. -- Thanks and Regards Yatin Karel

1 0

Nova filter based on VM metadata?
by Ken D'Ambrosio 08 Apr '24

08 Apr '24

Hey, all. I'm looking for a way to to filter to a particular aggregate based on arbitrary VM metadata. (E.g., maybe FACTER facts from Puppet that we pass to the VM as metadata.) Could someone point me toward documentation that might outline how to accomplish that? As I see it, there's really one thing I need to understand -- the rest I can probably glean from extant filters: how (or if) a filter could access a given VM's metadata from the API creation request (if that's even possible). Thanks! -Ken

3 3

[nova][ptg] Nova at the Dalmatian vPTG
by Sylvain Bauza 08 Apr '24

08 Apr '24

Hey folks, During this week, the Nova community will discuss on their own topics in between Tuesday-Friday 1300-1700UTC, all of the slots being in the Diablo room. You can find the related connection details and the proposed schedule in the etherpad [1] but here's a rough schedule for people interested in attending our sessions : - *Tuesday* *13:00 UTC - 17:00 UTC* - Nova sessions - retro + dalmatian schedule - nova above k8s - unified limits - *Wednesday 13:00 UTC - 17:00 UTC*: Nova sessions - vmware discussions about scheduling and metadata api - cleaning old microversions ? - ephemeral encryption status and next steps - memory encryption next steps - *Thursday 13:00 UTC - 17:00 UTC* - Nova sessions - stateless firmware support - vTPM detection by libvirt - Gap between legacy deprecated live migration options vs new live migration options - event actions missing in our API - OpenAPI schemas support - *Friday 13:00 UTC - 17:00 UTC* - Nova sessions - SPICE-direct console support + remote-consoles problem - userdata update - volume-backed instance migration requiring SSH conn - can we push removal of tunnelled libvirt migrations in dalmatian or do we need to wait for next slurp? - no validation if queued oslo.messaging messages are targeted for this specific nova-compute (based on hostname) As also said in the etherpad, you're free to add your own topics to the etherpad (at the bottom please) so I can schedule them, but fwiw our sessions will already be pretty packed with a lot of things to discuss so maybe some of the topics will be on a temptative effort. [1] https://etherpad.opendev.org/p/nova-dalmatian-ptg Thanks, -Sylvain

1 1

Fix for arguments for subnet module for Ansible
by George Shuklin 08 Apr '24

08 Apr '24

Hello everyone. I wrote a small fix for subnet Ansible module to allow use of cidr together with subnet_pool, with tests and so on. I got an approval, it passed CI, but it is not merged. What steps are required to have it merged? https://review.opendev.org/c/openstack/ansible-collections-openstack/+/9073… Sorry for nagging.

1 2

[kolla] [Wallaby] Openstack operations 2x slower after rebuilding from RHEL8/Train to RHEL9/Wallaby
by Albert Braden 08 Apr '24

08 Apr '24

After rebuilding a couple of our clusters, moving from Train on RHEL8 to Wallaby on RHEL9, we see all openstack operations taking 2x longer. Even simple database reads such as "openstack user show" average 1.5 seconds on old regions and 3 seconds on rebuilt regions. I enabled debug and poked around in the logs but nothing is jumping out at me. I was thinking maybe mariadb needed to be tuned differently from RHEL8->9 but if I log into the mariadb container and query the database it seems equally fast; I can do 100 simple queries in a second. Where should I be looking for the source of this delay?

5 10

Re:[skyline] Running a Skyline in "subdirectory"
by 吴文相 08 Apr '24

08 Apr '24

Hello, Dmitriy Rabotyagov Sorry for late response, dev team will raise a ticket and update the conclusion later. Thanks Best Regrads Wu Wenxiang Original: From：Dmitriy Rabotyagov <noonedeadpunk(a)gmail.com>Date：2024-03-16 02:45:49(中国 (GMT+08:00))To：openstack-discuss <openstack-discuss(a)lists.openstack.org>Cc：Subject：[skyline] Running a Skyline in "subdirectory"Hey folks, I was looking into a way to make both Horizon and Skyline work at the same time, and found out that I'm not really able to make Skyline to run in sub-URL. So for instance the plan was to place Horizon under /horizon (which is easily doable) and then Skyline under /skyline. However so far I haven't found any setting or anything that would allow me to do so. Basically, I've realized that static content is _really_ static, which means it does have hardcoded URIs: https://opendev.org/openstack/skyline-console/src/branch/master/skyline_con… So either I'm just not realizing the very simple technique which allows to overcome hardcoded in static files URIs (like some rewrite?), or just serving Skyline from a subdirectory is not possible by design... Would be great if someone could share their experience about Skyline and if anyone managed to do what I'm looking for. Thanks in advance

2 1

[neutron][zun] Container not able to communicate via dummy interface
by James Leong 07 Apr '24

07 Apr '24

Hi all, Using the OpenStack dashboard, we have launched two containers, Container-1 and Container-2, on two different hosts, Host-1 and Host-2. We attached both containers to a virtual network called VirtualNet (10.10.20.0/24). During container creation, both of them get an IP address via DHCP, as provided in the figure attached. Container-1 can successfully ping to 10.10.20.176 (Container-2 eth0 address) and Container-2 can successfully ping to 10.10.20.113 (Container-1 eth0 address). After this, we created a dummy interface (dummy0) on Container-1 and assigned an IP address (192.168.20.113). We want to ping 192.168.20.113 from Container-2. Therefore, we added a route in Container-2 using the command "ip add route 192.168.20.113 via 10.10.20.113 dev eth0." The ping is not successful. We captured the packets in Container-1 using tcpdump command on eth0, and we were able to observe that the icmp echo requests are received and the icmp echo replies are generated. However, the responses are not reaching back to Container-2. The screenshot of the tcpdump on eth0 for Container-1 is attached herewith. In the security groups, we added a rule allowing all ICMP traffic (ingress and egress) to 0.0.0.0/0. Any recommendations or suggestions are greatly appreciated. Best, James

1 0

[security-sig] PTG schedule
by Jeremy Stanley 07 Apr '24

07 Apr '24

Quick reminder that the Security SIG has a couple of sessions scheduled at the PTG this week: * Thursday, 2024-04-11, 21:00-22:00 UTC * Friday, 2024-04-12, 13:00-14:00 UTC There are no particular items on the agenda; feel free to join if you have something OpenStack security-related you want to talk about. The relevant Meetpad and Etherpad URLs can be found on https://ptg.opendev.org/ as usual. -- Jeremy Stanley

1 0

[neutron] Bug Deputy Report April 1 - April 7
by Miro Tomaska 07 Apr '24

07 Apr '24

Hello All Below is the bug deputy report for the week of April 1 High: - https://bugs.launchpad.net/neutron/+bug/2060163 - Partially confirmed, making it high since sporadically affects CI Medium: - https://bugs.launchpad.net/neutron/+bug/206005 - Owner: iulhaq RFE: - https://bugs.launchpad.net/neutron/+bug/2059897 - I don't see this being a bug, maybe an RFE? Undecided: - https://bugs.launchpad.net/neutron/+bug/2059902 - Waiting on more validation using filter-validation extension -- Miro Tomaska Senior Software Engineer

1 0

[all] Review dependencies without update for long time
by Takashi Kajinami 07 Apr '24

07 Apr '24

Hello, I recently spent some time reviewing the packages currently in the requirements repo and found some packages which haven't been updated for multiple years. This is a good indication that we have to review the features dependent on these packages to determine if the features should be re-implemented by a different package or dropped. Keeping such features with unmaintained library may likely cause problems in future maintenance (Python 3.12 support is a good example). Ideally we should have done this during 2024.1 cycle because of SLURP, but the sooner is always the better. I'd suggest that all projects spend some time to review the packages which haven't get updated for long time. I quickly grepped the packages which haven't get any bump in 202X and got the list which shows number of libraries. $ git blame -e upper-constraints.txt | grep -e '201[0-9]-' | sed -e 's/.* 201/201/' | sort 2015-06-08 22:09:46 +1200 500) simplegeneric===0.8.1 2016-05-19 06:30:24 +0000 169) extras===1.0.0 2016-11-14 17:07:49 +0000 69) XStatic-Font-Awesome===4.7.0.0 2016-12-18 07:20:50 +0000 583) xvfbwrapper===0.2.9 2017-02-21 14:05:54 -0600 118) pyinotify===0.9.6 2017-02-21 14:05:54 -0600 146) jsonpath-rw===1.4.0 2017-02-21 14:05:54 -0600 150) traceback2===1.4.0 2017-02-21 14:05:54 -0600 163) XStatic-roboto-fontface===0.5.0.0 2017-02-21 14:05:54 -0600 208) unittest2===1.1.0 2017-02-21 14:05:54 -0600 226) XStatic-objectpath===1.2.1.0 2017-02-21 14:05:54 -0600 256) dib-utils===0.0.11 2017-02-21 14:05:54 -0600 283) XStatic-Angular-Schema-Form===0.8.13.0 2017-02-21 14:05:54 -0600 287) XStatic-bootswatch===3.3.7.0 2017-02-21 14:05:54 -0600 290) XStatic-term.js===0.0.7.0 2017-02-21 14:05:54 -0600 317) pydotplus===2.0.2 2017-02-21 14:05:54 -0600 332) murano-pkg-check===0.3.0 2017-02-21 14:05:54 -0600 347) testscenarios===0.5.0 2017-02-21 14:05:54 -0600 354) nose-exclude===0.5.0 2017-02-21 14:05:54 -0600 357) elasticsearch===2.4.1 2017-02-21 14:05:54 -0600 366) XStatic-tv4===1.2.7.0 2017-02-21 14:05:54 -0600 367) XStatic-JSEncrypt===2.3.1.1 2017-02-21 14:05:54 -0600 380) linecache2===1.0.0 2017-02-21 14:05:54 -0600 390) openstack.nose-plugin===0.11 2017-02-21 14:05:54 -0600 403) testrepository===0.0.20 2017-02-21 14:05:54 -0600 41) requests-aws===0.1.8 2017-02-21 14:05:54 -0600 420) zake===0.2.2 2017-02-21 14:05:54 -0600 448) proboscis===1.2.6.0 2017-02-21 14:05:54 -0600 465) XStatic-smart-table===1.4.13.2 2017-02-21 14:05:54 -0600 487) testresources===2.0.1 2017-02-21 14:05:54 -0600 60) pysendfile===2.0.1 2017-02-21 14:05:54 -0600 613) XStatic-D3===3.5.17.0 2017-02-21 14:05:54 -0600 70) nose===1.3.7 2017-02-21 14:05:54 -0600 88) nosexcover===1.0.11 2017-02-21 14:05:54 -0600 96) Tempita===0.5.2 2017-06-28 10:13:14 +0000 576) logutils===0.3.5 2017-09-10 10:31:03 +0000 514) repoze.lru===0.7 2017-11-22 13:05:07 +0000 184) whereto===0.4.0 2017-11-24 06:19:46 +0000 501) python-pcre===0.7 2018-01-08 14:19:08 +0000 203) oslosphinx===4.18.0 2018-01-30 00:00:05 +0000 486) requestsexceptions===1.4.0 2018-03-01 06:25:09 +0000 537) CouchDB===1.2 2018-03-01 06:25:09 +0000 540) ws4py===0.5.1 2018-03-01 06:25:09 +0000 97) ply===3.11 2018-03-28 06:24:01 +0000 349) sadisplay===0.4.9 2018-05-11 06:33:27 +0000 236) threadloop===1.0.2 2018-05-13 06:27:38 +0000 289) XStatic-JS-Yaml===3.8.1.0 2018-05-13 06:27:38 +0000 309) XStatic-Angular-UUID===0.0.4.0 2018-05-13 06:27:38 +0000 524) XStatic-Json2yaml===0.1.1.0 2018-05-13 06:27:38 +0000 579) XStatic-Angular-Vis===4.16.0.0 2018-05-13 06:27:38 +0000 64) XStatic-FileSaver===1.3.2.0 2018-06-02 06:29:39 +0000 262) lockfile===0.12.2 2018-07-09 06:36:15 +0000 408) python-consul===1.1.0 2018-07-14 06:36:14 +0000 525) boto===2.49.0 2018-09-11 06:22:11 +0000 381) oauth2client===4.1.3 2019-01-01 06:10:54 +0000 471) cotyledon===1.7.3 2019-02-14 06:49:02 +0000 299) XStatic-mdi===1.6.50.2 2019-02-14 06:51:11 +0000 113) XStatic-Jasmine===2.4.1.2 2019-04-15 06:20:25 +0000 362) pysmi===0.3.4 2019-04-23 13:47:12 +0100 572) sphinx-testing===1.0.1 2019-05-12 12:14:16 +0000 343) os-service-types===1.7.0 2019-05-14 06:11:31 +0000 275) retryz===0.1.9 2019-05-14 06:11:31 +0000 400) bitmath===1.3.3.1 2019-05-14 06:11:31 +0000 535) cachez===0.1.2 2019-05-26 06:27:47 +0000 195) URLObject===2.4.3 2019-05-26 06:27:47 +0000 215) pact===1.12.0 2019-05-26 06:27:47 +0000 30) vintage===0.4.1 2019-05-26 06:27:47 +0000 313) capacity===1.3.14 2019-05-26 06:27:47 +0000 365) infi.dtypes.iqn===0.4.0 2019-05-26 06:27:47 +0000 422) flux===1.3.5 2019-05-26 06:27:47 +0000 442) api-object-schema===2.0.0 2019-05-26 06:27:47 +0000 46) waiting===1.4.1 2019-05-26 06:27:47 +0000 481) sentinels===1.0.0 2019-05-26 06:27:47 +0000 609) confetti===2.5.3 2019-05-26 06:27:47 +0000 84) infi.dtypes.wwn===0.1.1 2019-07-13 06:50:09 +0000 53) jsonpath-rw-ext===1.2.2 2019-08-15 06:36:56 +0000 528) mitba===1.1.1 2019-09-05 07:13:47 +0000 293) gossip===2.4.0 2019-10-07 06:11:48 +0000 112) rsd-lib===1.2.0 2019-10-07 06:11:48 +0000 74) pysnmp===4.4.12 2019-10-22 21:19:25 +0000 336) sqlalchemy-migrate===0.13.0 2019-11-01 17:20:28 +0200 71) nosehtmloutput===0.0.7 2019-11-30 06:10:48 +0000 513) ndg-httpsclient===0.5.1 -- Takashi Kajinami irc: tkajinam github: https://github.com/kajinamit launchpad: https://launchpad.net/~kajinamit

3 3

[openstack][cinder-backup] How check backup retain size.
by Nguyễn Hữu Khôi 07 Apr '24

07 Apr '24

Hello. I use s3 as cinder backup driver. My volume size is 2TB and It runs forever. I would like to know if we can check how many mb retain in this job. Thank you. Regards Nguyen Huu Khoi

1 0

[openstack][cinder][backup] ransomware with cinder volume
by Nguyễn Hữu Khôi 06 Apr '24

06 Apr '24

Hello, I would like to know if volumes which were attached to compute nodes and they will be impacted by ransomware. Could I have some sharing in this scenario? Currently, I just backup configure instance configure and create a new one with this configuration. Thank you. Nguyen Huu Khoi

2 2

[Diversity] PTG Schedule
by Amy Marrich 06 Apr '24

06 Apr '24

The Diversity and Inclusion working group will hold a session Tuesday, April 9th at 14:00 UTC in the Cactus room. Agenda is available[0], please add any topics. Amy 0 - https://etherpad.opendev.org/p/apr2024-ptg-diversity

1 0

Re: [all] Review dependencies without update for long time
by Sean McGinnis 06 Apr '24

06 Apr '24

> Subject: Re: [all] Review dependencies without update for long time In case it's not known, there is a script in the repo that was created to help find some of this information: https://opendev.org/openstack/requirements/src/branch/master/tools/get-heal… > > > > I recently spent some time reviewing the packages currently in the requirements repo > > and found some packages which haven't been updated for multiple years. This is a good > > indication that we have to review the features dependent on these packages to determine > > if the features should be re-implemented by a different package or dropped. Keeping such > > features with unmaintained library may likely cause problems in future maintenance > > (Python 3.12 support is a good example). > > > > > > $ git blame -e upper-constraints.txt | grep -e '201[0-9]-' | sed -e 's/.* 201/201/' | sort > > 2015-06-08 22:09:46 +1200 500) simplegeneric===0.8.1 > > 2016-05-19 06:30:24 +0000 169) extras===1.0.0 > > 2016-11-14 17:07:49 +0000 69) XStatic-Font-Awesome===4.7.0.0 > > 2016-12-18 07:20:50 +0000 583) xvfbwrapper===0.2.9 > > 2017-02-21 14:05:54 -0600 118) pyinotify===0.9.6 > > 2017-02-21 14:05:54 -0600 146) jsonpath-rw===1.4.0 > > 2017-02-21 14:05:54 -0600 150) traceback2===1.4.0 > > 2017-02-21 14:05:54 -0600 163) XStatic-roboto-fontface===0.5.0.0 > > 2017-02-21 14:05:54 -0600 208) unittest2===1.1.0 > > 2017-02-21 14:05:54 -0600 226) XStatic-objectpath===1.2.1.0 > > 2017-02-21 14:05:54 -0600 256) dib-utils===0.0.11 > > 2017-02-21 14:05:54 -0600 283) XStatic-Angular-Schema-Form===0.8.13.0 > > 2017-02-21 14:05:54 -0600 287) XStatic-bootswatch===3.3.7.0 > > 2017-02-21 14:05:54 -0600 290) XStatic-term.js===0.0.7.0 > > 2017-02-21 14:05:54 -0600 317) pydotplus===2.0.2 > > 2017-02-21 14:05:54 -0600 332) murano-pkg-check===0.3.0 > > 2017-02-21 14:05:54 -0600 347) testscenarios===0.5.0 > > 2017-02-21 14:05:54 -0600 354) nose-exclude===0.5.0 > > 2017-02-21 14:05:54 -0600 357) elasticsearch===2.4.1 > > 2017-02-21 14:05:54 -0600 366) XStatic-tv4===1.2.7.0 > > 2017-02-21 14:05:54 -0600 367) XStatic-JSEncrypt===2.3.1.1 > > 2017-02-21 14:05:54 -0600 380) linecache2===1.0.0 > > 2017-02-21 14:05:54 -0600 390) openstack.nose-plugin===0.11 > > 2017-02-21 14:05:54 -0600 403) testrepository===0.0.20 > > 2017-02-21 14:05:54 -0600 41) requests-aws===0.1.8 > > 2017-02-21 14:05:54 -0600 420) zake===0.2.2 > > 2017-02-21 14:05:54 -0600 448) proboscis===1.2.6.0 > > 2017-02-21 14:05:54 -0600 465) XStatic-smart-table===1.4.13.2 > > 2017-02-21 14:05:54 -0600 487) testresources===2.0.1 > > 2017-02-21 14:05:54 -0600 60) pysendfile===2.0.1 > > 2017-02-21 14:05:54 -0600 613) XStatic-D3===3.5.17.0 > > 2017-02-21 14:05:54 -0600 70) nose===1.3.7 > > 2017-02-21 14:05:54 -0600 88) nosexcover===1.0.11 > > 2017-02-21 14:05:54 -0600 96) Tempita===0.5.2 > > 2017-06-28 10:13:14 +0000 576) logutils===0.3.5 > > 2017-09-10 10:31:03 +0000 514) repoze.lru===0.7 > > 2017-11-22 13:05:07 +0000 184) whereto===0.4.0 > > 2017-11-24 06:19:46 +0000 501) python-pcre===0.7 > > 2018-01-08 14:19:08 +0000 203) oslosphinx===4.18.0 > > 2018-01-30 00:00:05 +0000 486) requestsexceptions===1.4.0 > > 2018-03-01 06:25:09 +0000 537) CouchDB===1.2 > > 2018-03-01 06:25:09 +0000 540) ws4py===0.5.1 > > 2018-03-01 06:25:09 +0000 97) ply===3.11 > > 2018-03-28 06:24:01 +0000 349) sadisplay===0.4.9 > > 2018-05-11 06:33:27 +0000 236) threadloop===1.0.2 > > 2018-05-13 06:27:38 +0000 289) XStatic-JS-Yaml===3.8.1.0 > > 2018-05-13 06:27:38 +0000 309) XStatic-Angular-UUID===0.0.4.0 > > 2018-05-13 06:27:38 +0000 524) XStatic-Json2yaml===0.1.1.0 > > 2018-05-13 06:27:38 +0000 579) XStatic-Angular-Vis===4.16.0.0 > > 2018-05-13 06:27:38 +0000 64) XStatic-FileSaver===1.3.2.0 > > 2018-06-02 06:29:39 +0000 262) lockfile===0.12.2 > > 2018-07-09 06:36:15 +0000 408) python-consul===1.1.0 > > 2018-07-14 06:36:14 +0000 525) boto===2.49.0 > > 2018-09-11 06:22:11 +0000 381) oauth2client===4.1.3 > > 2019-01-01 06:10:54 +0000 471) cotyledon===1.7.3 > > 2019-02-14 06:49:02 +0000 299) XStatic-mdi===1.6.50.2 > > 2019-02-14 06:51:11 +0000 113) XStatic-Jasmine===2.4.1.2 > > 2019-04-15 06:20:25 +0000 362) pysmi===0.3.4 > > 2019-04-23 13:47:12 +0100 572) sphinx-testing===1.0.1 > > 2019-05-12 12:14:16 +0000 343) os-service-types===1.7.0 > > 2019-05-14 06:11:31 +0000 275) retryz===0.1.9 > > 2019-05-14 06:11:31 +0000 400) bitmath===1.3.3.1 > > 2019-05-14 06:11:31 +0000 535) cachez===0.1.2 > > 2019-05-26 06:27:47 +0000 195) URLObject===2.4.3 > > 2019-05-26 06:27:47 +0000 215) pact===1.12.0 > > 2019-05-26 06:27:47 +0000 30) vintage===0.4.1 > > 2019-05-26 06:27:47 +0000 313) capacity===1.3.14 > > 2019-05-26 06:27:47 +0000 365) infi.dtypes.iqn===0.4.0 > > 2019-05-26 06:27:47 +0000 422) flux===1.3.5 > > 2019-05-26 06:27:47 +0000 442) api-object-schema===2.0.0 > > 2019-05-26 06:27:47 +0000 46) waiting===1.4.1 > > 2019-05-26 06:27:47 +0000 481) sentinels===1.0.0 > > 2019-05-26 06:27:47 +0000 609) confetti===2.5.3 > > 2019-05-26 06:27:47 +0000 84) infi.dtypes.wwn===0.1.1 > > 2019-07-13 06:50:09 +0000 53) jsonpath-rw-ext===1.2.2 > > 2019-08-15 06:36:56 +0000 528) mitba===1.1.1 > > 2019-09-05 07:13:47 +0000 293) gossip===2.4.0 > > 2019-10-07 06:11:48 +0000 112) rsd-lib===1.2.0 > > 2019-10-07 06:11:48 +0000 74) pysnmp===4.4.12 > > 2019-10-22 21:19:25 +0000 336) sqlalchemy-migrate===0.13.0 > > 2019-11-01 17:20:28 +0200 71) nosehtmloutput===0.0.7 > > 2019-11-30 06:10:48 +0000 513) ndg-httpsclient===0.5.1

1 0

[ptg][openstack-ansible] OpenStack-Ansible vPTG time and date
by Dmitriy Rabotyagov 06 Apr '24

06 Apr '24

Hi folks, Sorry for the late scheduling of vPTG this time. I've booked an Icehouse room for Tuesday, April 9 from 16:00 (4PM) till 18:00 (6PM) UTC. You can find the meeting link below [1]. An etherpad with some agenda is here: [2] [1] https://meetpad.opendev.org/apr2024-ptg-os-ansible [2] https://etherpad.opendev.org/p/osa-dalmatian-ptg

1 0

[opnestack][kolla-ansible]Mix compute inventory
by Nguyễn Hữu Khôi 05 Apr '24

05 Apr '24

Hello. I am reading about Kolla Ansible Inventory https://docs.openstack.org/kolla-ansible/latest/user/multinode.html In my environment, Controllers and Compute01>>>03 have same network interfaces But from compute04>>06 have different interface neutron_external_interface=*eth0.1 *api_interface=*eth0.2 *tunnel_interface= *eth0.3* Which is the best group for my case? [compute-custom] compute04 neutron_external_interface=*eth0.1 *api_interface=*eth0.2 * tunnel_interface=*eth0.3* compute05 neutron_external_interface=*eth0.1 *api_interface=*eth0.2 * tunnel_interface=*eth0.3* compute06 neutron_external_interface=*eth0.1 *api_interface=*eth0.2 * tunnel_interface=*eth0.3* Then put them to same block services which have Nova? I see the we prefer to use host_vars or*group_vars. *Do we have some examples about it? Thank you. Nguyen Huu Khoi

1 0

[Nova][Kolla][VDI] Introducing Kerbside delivery of VDI console sessions
by Michael Still 05 Apr '24

05 Apr '24

Hi all, for the longest time I've thought it was super cool that you could do something like this with Google Cloud: `gcloud compute ssh ...instance...` This causes a SSH session to run in your terminal that transparently proxies you through to the instance. It even orchestrates SSH authentication using a CA, but that's a story for another day. Aptira had a similar business need, but with more of a focus on virtual desktop environments, and therefore kindly supported my development work on a SPICE protocol native proxy I've called Kerbside [1][2]. The proxy works by scraping various clouds' REST APIs for "VDI capable" instances, and then making those available via short lived session tokens. The intention is that a service like Horizon or Skyline could request a session token for a specific instance, which is returned to the user as a `.vv` style virt-viewer configuration file. The user then opens the configuration file and a connection to the console on the relevant hypervisor is provided by Kerbside. Kerbside can do more than that of course. It has a simple management UI and API, which allows for things like forced termination of a console session once setup, logging and audit history, TLS support, and so forth. Kerbside and all associated work is licensed under the Apache 2 license, just the same as OpenStack, and positions clouds to offer Citrix-like virtual desktops to their users in a seamless manner. Why a SPICE proxy? As best as I can tell, SPICE still provides the richest virtual desktop experience. It supports high resolution desktops, multi-screen desktops, USB device passthrough, sound, multiple user connections to a single console, and so forth. Why not the current HTML5 transcoding proxy as used by Horizon? Unfortunately, the current HTML5 SPICE client does not support most of the features listed in the previous paragraph. While originally intended for the purposes of my personal Shaken Fist project, Kerbside now supports OpenStack and oVirt as well. In the case of OpenStack, this required a number of patches to OpenStack projects to get working [3]. Specifically I'd like to propose a new Nova API microversion to support a new "spice-direct" console type. I intend to work through the Nova specs process for the Nova related changes, and have created a blueprint [4] to track that work. I am working on a draft spec at the moment [5], but do not see the required changes to Nova as particularly invasive. You can of course assess that yourself by reading the proof of concept patches in the kerbside-patches repository. This raises some questions for me. Specifically: - is this functionality interesting to others? Or is it just me? - what is the process of proposing changes like this for Kolla and Kolla-Ansible? I chose to build my proof of concept on that platform, so I also have a number of aligned deployment patches there. - I've been out of the OpenStack universe for a while now. Is it too late to propose this work for Dalmation? Thanks, Michael 1: https://github.com/shakenfist/kerbside and https://github.com/shakenfist/kerbside-client 2: Why Kerbside? Well because Horizon and Skyline are distant things, whereas I wanted to create something closer... Like Kerbside pickup from a shop. 3: https://github.com/shakenfist/kerbside-patches 4: https://blueprints.launchpad.net/nova/+spec/libvirt-spice-direct-consoles 5: https://github.com/shakenfist/kerbside-patches/blob/develop/nova-specs/patc…

3 3

[blazar][ptg] Dalmatian PTG schedule
by Pierre Riteau 05 Apr '24

05 Apr '24

Hello, I have booked a PTG slot on Thursday, April 11 from 1500 to 1700 UTC for the Blazar project. The meeting will be held in the Bexar room. The initial agenda can be found here: https://etherpad.opendev.org/p/apr2024-ptg-blazar Please add any topics you would like to discuss. Anyone interested in Blazar is welcome to join. Cheers, Pierre Riteau (priteau)

1 0

[ptg][tacker]Dalmatian vPTG Planning
by Yasufumi Ogawa 05 Apr '24

05 Apr '24

Hi all, I've booked the slots[1] from Apr 9th to 11th, 6-8 UTC all the days, and setup the etherpad[2] for Tacker team. Please feel free to add your topics. [1] https://ptg.opendev.org/ptg.html [2] https://etherpad.opendev.org/p/apr2024-ptg-tacker Thanks, Yasufumi

1 0

[swift][ptg] Ops Feedback Session - 10th April at 1300 UTC
by Matthew Oliver 04 Apr '24

04 Apr '24

As we've done in PTGs past, we're getting devs and ops together to talk about Swift: what's working, what isn't, and what would be most helpful to improve. We're meeting in the dalmation swift meetpad room ( https://meetpad.opendev.org/swift-ptg-dalmatian) on Wednesday at 13:00UTC -- if you run a Swift cluster, we hope to see you there! Even if you can't make it, we'd appreciate it if you can offer some feedback on the etherpad ( https://etherpad.opendev.org/p/swift-dalmation-ops-feedback) This has always been a highlight at every PTG for us swift devs. Have your say and help make Swift even better! Matt

1 0

[kolla] [mariadb] Backups failing if they take over an hour
by Chris DiLorenzo 04 Apr '24

04 Apr '24

Were using the mariadb_backup command of kolla-ansible to backup the database. We're doing daily, full backups. It's been working fine until recently. Now we are getting this error: 2024-04-03 21:16:33 0 [Note] InnoDB: Read redo log up to LSN=317647271424 2024-04-03 21:16:48 0 [Note] InnoDB: Read redo log up to LSN=317647424512 2024-04-03 21:17:03 0 [Note] InnoDB: Read redo log up to LSN=317647586304 2024-04-03 21:17:18 0 [Note] InnoDB: Read redo log up to LSN=317647733248 [01] 2024-04-03 21:17:23 ...done [00] FATAL ERROR: 2024-04-03 21:17:23 failed to execute query SET SESSION lock_wait_timeout=31536000: Server has gone away It started as soon as the DB backup took more than 1 hour. In our other environments where the backup is < 1hr, it works fine. There are no errors in the logs when this happens, other then the above output from mariabackup Any suggestions? Thanks, Chris

2 1

[neutron] Dalmatian vPTG reminder
by Brian Haley 04 Apr '24

04 Apr '24

Hello Neutrinos, This year our vPTG slots are: Tuesday, April 9th, 13:00 - 17:00 UTC Wednesday, April 10th, 13:00 - 17:00 UTC Thursday, April 11th, 13:00 - 17:00 UTC (if necessary) See https://ptg.opendev.org/ptg.html for room info and other teams' sessions. Etherpad is at https://etherpad.opendev.org/p/apr2024-ptg-neutron - please add anything you would like to discuss by tomorrow so I can create a schedule. See you on Tuesday! -Brian

1 0

[manila] Dalmatian vPTG Schedule
by Carlos Silva 04 Apr '24

04 Apr '24

Hello, Zorillas and interested stackers, I would like to share with you our agenda for next week's PTG [1]. In case you would like a topic to be moved around, please let me know and I'll be happy to accommodate changes. [1] https://etherpad.opendev.org/p/dalmatian-ptg-manila Looking forward to having many productive discussions with you! Regards, carloss

1 0

help
by Carita Ndibe 04 Apr '24

04 Apr '24

I am trying to customize my dashboard but keep getting this error: uncompressableFileError at auth/login static/dashboard/scss/custom.scss' could not be found in the COMPRESS_ROOT '/opt/stack/horizon/static' or with staticfiles I previously had an offline compression error by i resolved be settion COMPRESSION_ENABLED to False. how can I resolve this?

1 0

[release]OpenStack Caracal 2024.1 Highlights on OpenInfra Live
by Allison Price 04 Apr '24

04 Apr '24

Hi everyone, Happy OpenStack Caracal 2024.1 release day! Tomorrow, at 1400 UTC, there will be an OpenInfra Live episode [1] to cover some of the project highlights from this project cycle and what can be expected for OpenStack Dalmatian 2024.2. Here is a lineup of the OpenStack community leaders and the updates they will be covering: Sylvain Bauza (Nova), Ghanshyam Mann (Technical Committee), Riccardo Pittau (Ironic), Rajat Dhasmana (Cinder), Carlos Silva (Manila) Join us as we celebrate OpenStack’s 29th release! Cheers, Allison [1] https://www.youtube.com/watch?v=3BgAXbFaVqw

1 1

[openstack-ansible] : Ussuri minor version update.
by keshav bareja 04 Apr '24

04 Apr '24

Hi Team I am planning to update my environment from the current ussuri minor version to the latest minor version available for the Ussuri. I found the procedure below. https://docs.openstack.org/openstack-ansible/ussuri/admin/upgrades/minor-up… I have some queries on this: 1. How to find the current minor release version of the Ussuri deployed on my environment? Is there any command or way that can help? 2. What is the latest minor version available for Ussuri? In the Ussuri release notes page I could see 2.10, can someone please confirm if 2.10 is the latest version? 3. Also I need to know the bug fixes between my current release to the latest minor ussuri release. 4. Can someone confirm what all pre-requisite I need to take care of before going with the update. 5. Anyone having experience with such minor updates , Please share precaution and recommendations, Ussuri Series Release Notes <https://docs.openstack.org/releasenotes/openstack-ansible/victoria.html> <https://docs.openstack.org/releasenotes/openstack-ansible/train.html> <https://bugs.launchpad.net/openstack-ansible/+filebug?field.title=Ussuri%20…> 21.2.10 <https://docs.openstack.org/releasenotes/openstack-ansible/ussuri.html#relno…>Security Issues <https://docs.openstack.org/releasenotes/openstack-ansible/ussuri.html#secur…> - This release eliminates following security issues: - OSSA-2021-005: https://security.openstack.org/ossa/OSSA-2021-005.html - OSSA-2021-006: https://security.openstack.org/ossa/OSSA-2021-006.html

2 5

Panko Service get_events function returning none
by Sandesh Kulkarni 03 Apr '24

03 Apr '24

Hi Openstack Team, I am using Panko for events retrieval, but I am getting None from the below query. My current SqlAlchemy version is 1.4.31. Could you please guide me in retrieving the correct events from the database? Output from the panko events api :- { "message_id": "2b4d83b4-3e23-4326-bedb-557a405c16db", "event_type": "audit.http.response", "traits": [ { "name": "action", "value": "None", "type": "string" }, { "name": "eventTime", "value": "2024-03-27T03:59:52.192750", "type": "datetime" }, { "name": "eventType", "value": "None", "type": "string" }, { "name": "id", "value": "None", "type": "string" }, { "name": "initiator_host_address", "value": "None", "type": "string" }, { "name": "initiator_id", "value": "None", "type": "string" }, { "name": "initiator_name", "value": "None", "type": "string" }, { "name": "initiator_typeURI", "value": "None", "type": "string" }, { "name": "observer_id", "value": "None", "type": "string" }, { "name": "outcome", "value": "None", "type": "string" }, { "name": "project_id", "value": "None", "type": "string" }, { "name": "reason_code", "value": "None", "type": "string" }, { "name": "requestPath", "value": "None", "type": "string" }, { "name": "request_id", "value": "None", "type": "string" }, { "name": "service", "value": "None", "type": "string" }, { "name": "target_id", "value": "None", "type": "string" }, { "name": "target_name", "value": "None", "type": "string" }, { "name": "target_typeURI", "value": "None", "type": "string" }, { "name": "typeURI", "value": "None", "type": "string" }, { "name": "user_id", "value": "None", "type": "string" } ], "generated": "2024-03-27T03:59:52.693294", "raw": {} } Query Link :- https://github.com/openstack/panko/blob/4d0c0d66da6833e5283d71fe5bdee9594e4… Thanks and Regards, Sandesh Kulkarni

1 0

[all][elections][tc] 2024.2 Dalmatian Technical Committee Election Results
by Ian Y. Choi 03 Apr '24

03 Apr '24

Please join me in congratulating the 5 newly elected members of the Technical Committe (TC). Amy Marrich (spotz) Goutham Pacha Ravi (gouthamr) Dmitriy Rabotyagov (noonedeadpunk) Artem Goncharov (gtema) (replacing Sylvain Bauza - bauzas as per the TC resolution) [1] Slawek Kaplonski (slaweq) Full results: https://civs1.civs.us/cgi-bin/results.pl?id=E_f8044ce7af316bf3 Election process details and results are also available here: https://governance.openstack.org/election/ Note that we encountered a situation where not all members as elected could be seated which requires TC resolution. More details on the resolution are explained in [1], and thank you all for the understanding and support in resolving this matter. Thank you to all of the candidates, having a good group of candidates helps engage the community in our democratic process. Thank you to all who voted and who encouraged others to vote. We need to ensure your voice is heard. Thank you for another great round. [1] https://governance.openstack.org/tc/resolutions/20240322-adjudication-of-20…

1 0

OpenStack 2024.1 Caracal is officially released!
by Herve Beraud 03 Apr '24

03 Apr '24

Hello OpenStack community, The official OpenStack 2024.1 Caracal release announcement has been sent out: https://lists.openstack.org/archives/list/openstack-announce@lists.openstac… Thanks to all who were a part of the 2024.1 Caracal development cycle! This marks the official opening of the openstack/releases repository for 2024.2 Dalmatian releases, and freezes are now lifted. stable/2024.1 is now a fully normal stable branch, and the normal stable policy applies from now on. Thanks, -- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/

3 2

User survey 2023 - TC questions
by Sławek Kapłoński 03 Apr '24

03 Apr '24

Hi, I am doing analysis of the TC questions in the 2023 user survey [1] and I need some additonal information. In the results of the survey which I some time ago got from Allison there are only short "names" of the questions, like e.g. "TCContributions" but no full question which was asked. This is ok for me for the questions which were in the survey in previous years but this year TC added couple of new questions for which I don't have full questions at all. Short names of those questions are: - TCConsumingOpenStack - TCConsumingOpenStackOther - TCInteractOpenStack - TCInteractOpenStack - TCInteractOpenStackSkyline - TCInteractOpenStackSkylineList - TCInteractSkylineOther - TCInteractOpenStackInternal - TCInteractOpenStackInternalOther - TCCloudServices Can You maybe share with me what were those full questions in the survey? Or point me to the place where I can maybe find it? Thx in advanve for help with this. [1] https://review.opendev.org/c/openstack/governance/+/900516 -- Slawek Kaplonski Principal Software Engineer Red Hat

2 2

[all][tc] Next week TC meeting is canceled
by Ghanshyam Mann 02 Apr '24

02 Apr '24

Hello Everyone, As next week is vPTG happening, we are canceling next week's (April 9th) TC meeting. -gmann

1 0

[freezer] Project status update
by Dmitriy Rabotyagov 02 Apr '24

02 Apr '24

Hey there! In a previous email thread [1] an interest toward reviving the Freezer project was raised. As a result of the thread we've organized a first sync meeting with interested parties. It was a quite productive discussion and we came up with a couple of action points as a result of it. You can find more information in the etherpad [2] Among everything, one of the most important parts for now, is to step into the PTL role or move a project to a distributed leadership. At the moment the project is leadless, since there was no candidacy submitted for this election. We also agreed to schedule the next meeting on April 2 from 16-00 till 17-00 UTC and discuss progress and blockers which were found. I'm attaching an invitation to the meeting to the email. If it doesn't work, you can join on the mentioned time via the link [3] Hope to see you there and thanks for everyone who participated and stepped in for the project! [1] https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… [2] https://etherpad.opendev.org/p/freezer-status [3] https://meet.google.com/ckc-gevi-epe

1 2

[cinder] Canceling this week's meeting (3rd April)
by Rajat Dhasmana 02 Apr '24

02 Apr '24

Hello Argonauts, Given that tomorrow is the 2024.1 Caracal release and PTG coming up next week, we decided in last week's meeting to cancel the cinder meeting, which was going to be held on 3rd April, 2024. See you all next week at the PTG! Thanks Rajat Dhasmana

1 0

[neutron] Proposing Ihar Hrachyshka as neutron core reviewer
by Brian Haley 02 Apr '24

02 Apr '24

Hello Neutrinos, I would like to nominate Ihar Hrachyshka for Neutron core reviewer (again). He's been leaving some very useful comments lately, moved-up in the reviewer stats over the past 90 days [0], and has a lot of OVN knowledge. Ihar was previously a core reviewer from 2015-2018 so most might already know him. I think he'd be a great re-addition to the team. Please vote with a +1/-1. [0] https://www.stackalytics.io/report/contribution?module=neutron-group&projec… Thanks, -Brian, Neutron PTL

8 8

Re: [neutron][magnum][mcapi] floating IP delete permission issue
by Satish Patel 02 Apr '24

02 Apr '24

Thank you Mohammed, It would be really good if we have a flag in template to say release floating IP instead of delete. Technically operator assign floating IPs to project and only that project should use them as per need instead of delete floating ips and put it back to book. Let’s see if we can get some eyeballs on this feature. But this is very important feature for us to control public IP usage. On Mon, Apr 1, 2024 at 10:16 PM Mohammed Naser <mnaser(a)vexxhost.com> wrote: > Hi Satish, > > This is actually something that would have to be handled on the Cluster > API level, since it is the one that owns that resource. > > I would start raising an issue there first, if that gets traction then we > can integrate that with the driver after, however, if it doesn't make sense > for it to be there, we can maybe include a config flag to handle this (but > I'm not sure what other implications this would have) > > Thanks > Mohammed > ------------------------------ > *From:* Satish Patel <satish.txt(a)gmail.com> > *Sent:* April 1, 2024 10:09 PM > *To:* OpenStack Discuss <openstack-discuss(a)lists.openstack.org> > *Subject:* [neutron][magnum][mcapi] floating IP delete permission issue > > Folks, > > For regulatory purposes we set a neutron policy to not let normal users > delete their public floating IPs because they are assigned to specific > customers and we don't want them to delete them. So far that policy works. > > But now when it comes to magnum / mcapi. I am able to create a cluster but > not able to delete because when magnum is going to delete floating IP I am > getting an error saying you are not allowed to delete floating IP and k8s > are stuck in deleting state. > > Is there any way magnum can do floating IP release instead of delete? > > Following error I am seeing in CAPI logs. > > I0402 01:50:03.412447 1 recorder.go:104] "events: Failed to delete > floating IP 101.xx.xx.70: Request forbidden: [DELETE > https://os2.example.com:9696/v2.0/floatingips/492b2c4c-151b-437e-acfc-4778a…] > error message: {\"NeutronError\": {\"type\": \"PolicyNotAuthorized\", > \"message\": \"rule:delete_floatingip is disallowed by policy\", > \"detail\": \"\"}}" type="Warning" > object={"kind":"OpenStackMachine","namespace":"magnum-system","name":"kube-6aqje-csgft-nkz6s","uid":"97acabe1-e547-4bbc-8406-aebc563212cd","apiVersion":" > infrastructure.cluster.x-k8s.io/v1alpha7","resourceVersion":"31170690"} > reason="Faileddeletefloatingip" >

1 0

how to use policy.json in kolla
by mohammad kokabi 02 Apr '24

02 Apr '24

Hello, I'm using OpenStack Kolla Ansible, and I want to define a specific level of access for each user, but I couldn't find any documentation on this matter. For example, I have two users named David and Adrian, and I want the user David to have the ability to delete an instance, while the user Adrian should not have this access. Both users are members of a shared project. The only documentation I found is a sample policy.yaml file, which states that it should be placed in the /etc/nova directory. Could you please clarify where this file should be located for OpenStack Kolla Ansible? https://docs.openstack.org/nova/latest/configuration/sample-policy.html

1 0

[neutron] Bug Deputy Report March 25 - March 31
by Yatin Karel 02 Apr '24

02 Apr '24

Hi Neutrinos, Below is the bug deputy report for last week:- High ------ - https://bugs.launchpad.net/neutron/+bug/2058908 fix auto_scheduler_network understanding dhcp_agents_per_network Assigned to Sahid Orentino Medium ---------- - https://bugs.launchpad.net/neutron/+bug/2058712 [openvswitch-agent] Trunk extension should not be loaded if service plugin is disabled Assigned to Julien Cosmao Low ----- - https://bugs.launchpad.net/neutron/+bug/2059236 Add a RBAC action field in the query hooks Assigned to Rodolfo Alonso Undecided -------------- - https://bugs.launchpad.net/neutron/+bug/2059716 [ovn] Multihomed backend (IPv4 + IPv6) with floating IP unreachable, requested more information. -- Thanks and Regards Yatin Karel

1 0

[sunbeam][PTG] Sunbeam Dalmatian 2024.2 PTG schedule
by Hemanth N 02 Apr '24

02 Apr '24

Hi All, OpenStack PTG has been scheduled for next week Apr 8th to Apr 12th 2024 [1] and I have scheduled the following time slots for the OpenStack Sunbeam project. Wednesday 10 April 2024 0500 UTC to 0700 UTC Thursday 11 April 2024 1400 UTC to 1600 UTC The meeting links and details are in ptg link [2] or etherpad [3]. Feel free to add the topics of interest to discuss in the etherpad [3]. [1] https://openinfra.dev/ptg/ [2] https://ptg.opendev.org/ptg.html [3] https://etherpad.opendev.org/p/apr2024-ptg-sunbeam Looking forward to seeing you next week! Best Regards, Hemanth Nakkina

1 0

[publiccloud-sig] Reminder - next meeting April 4th - 0700 UTC
by Felix Kronlage-Dammers 02 Apr '24

02 Apr '24

Hi everyone, This Wednesday (April 4th) the next meeting of the public cloud sig is going to happen. We’ll be meeting at 0700 UTC here: https://meetpad.opendev.org/publiccloud-sig See also here for all other details: https://wiki.openstack.org/wiki/PublicCloudSIG This week we’ll likely prepare the vPTG Sessions for next week. This will include our own sessions that happen on Tuesday (April 9th) at 07:00 UTC and Thursday (April 11th) at 14:00 UTC. regards felix -- Felix Kronlage-Dammers Sovereign Cloud Stack — standardized, built and operated by many Ein Projekt der Open Source Business Alliance - Bundesverband für digitale Souveränität e.V. Tel.: +49-30-206539-205 | Matrix: @fkronlage:matrix.org | fkr(a)osb-alliance.com

1 1

[qa][ptg] Virtual Dalmatian vPTG Planning
by Martin Kopec 02 Apr '24

02 Apr '24

Hello everyone, here is [1] our etherpad for the Dalmatian/2024.2 virtual PTG. Please, add your topics there if there is anything you would like to discuss / propose ... You can also vote for time slots for our sessions so that they fit your schedule at [2]. We will most likely go with 1-hour slot per day, as they usually fit easier into everyone's schedule. The number of slots will depend on the number of topics proposed in [1]. [1] https://etherpad.opendev.org/p/apr2024-ptg-qa [2] https://framadate.org/pklG59pH47w6ZdJI Thanks, -- Martin Kopec Principal Software Quality Engineer Red Hat EMEA IM: kopecmartin

1 1

[all][tc] Technical Committee next weekly meeting on April 2nd 2024 at 1800 UTC
by Ghanshyam Mann 01 Apr '24

01 Apr '24

Hello Everyone, Below is the agenda for the next TC meeting scheduled on April 2nd 2024 at 1800 UTC Location: Zoom Video Meeting: https://us06web.zoom.us/j/87108541765?pwd=emlXVXg4QUxrUTlLNDZ2TTllWUM3Zz09 * Roll call * Follow up on past action items * Gate health check * Implementation of Unmaintained branch statuses * TC vPTG 2024.2 ** https://etherpad.opendev.org/p/apr2024-ptg-os-tc * TC Chair Election ** Incoming TC needs to select a new chair and vice chair: https://governance.openstack.org/tc/reference/charter.html#tc-chair *Open Discussion and Reviews -gmann

1 0

[neutron][magnum][mcapi] floating IP delete permission issue
by Satish Patel 01 Apr '24

01 Apr '24

Folks, For regulatory purposes we set a neutron policy to not let normal users delete their public floating IPs because they are assigned to specific customers and we don't want them to delete them. So far that policy works. But now when it comes to magnum / mcapi. I am able to create a cluster but not able to delete because when magnum is going to delete floating IP I am getting an error saying you are not allowed to delete floating IP and k8s are stuck in deleting state. Is there any way magnum can do floating IP release instead of delete? Following error I am seeing in CAPI logs. I0402 01:50:03.412447 1 recorder.go:104] "events: Failed to delete floating IP 101.xx.xx.70: Request forbidden: [DELETE https://os2.example.com:9696/v2.0/floatingips/492b2c4c-151b-437e-acfc-4778a…] error message: {\"NeutronError\": {\"type\": \"PolicyNotAuthorized\", \"message\": \"rule:delete_floatingip is disallowed by policy\", \"detail\": \"\"}}" type="Warning" object={"kind":"OpenStackMachine","namespace":"magnum-system","name":"kube-6aqje-csgft-nkz6s","uid":"97acabe1-e547-4bbc-8406-aebc563212cd","apiVersion":" infrastructure.cluster.x-k8s.io/v1alpha7","resourceVersion":"31170690"} reason="Faileddeletefloatingip"

1 0

[manila] PTG topics reminder
by Carlos Silva 01 Apr '24

01 Apr '24

Hello, Zorillas! Sending this kind last reminder to please add your topics to the PTG topics etherpad [1] by tomorrow (Apr 2nd). I will be working on the slots on Wednesday and intend to share the agenda with you in this Thursday's weekly meeting. [1] https://etherpad.opendev.org/p/dalmatian-ptg-manila-planning Thank you! Regards, carloss

1 0

One Week Out! PTG April 2024 Registration & Schedule
by Kendall Nelson 01 Apr '24

01 Apr '24

Hello Everyone! The April 2024 Project Teams Gathering is right around the corner and the schedule has been largely set up! Slots are going fast, so make sure to get your time booked ASAP! You can find the schedule and available slots on the PTGbot website [1]. *REMINDER: The default meeting rooms are no longer Zoom rooms, they are meetpad rooms. When the PTGbot was setup initially, the meetpad rooms had been configured to match the etherpads auto generated by the bot. If your team has updated the etherpad and also wants to maintain the meetpad integration, your meetpad room URL will need to be updated as well. One thing to keep in mind about this integration - meetpad is not case sensitive, but etherpad is so to keep the integration your etherpad URL should be all lowercase. Your team does not HAVE to use meetpad (or make use of the integration with etherpad) however; just as before, the URL can be updated by your team moderator to use a different meeting tool.* The PTGbot site is regularly updated both before *and* during the PTG. Be sure to bookmark the page so you can keep track of what's being discussed and any last-minute schedule changes. It is driven via commands in the #openinfra-events IRC channel (on the OFTC network) where the PTGbot listens. If you have questions about the commands that you can give the bot, check out the documentation here[2]. Also, if you haven’t connected to IRC before, here are some docs on how to get setup![3] Lastly, please don't forget to register[4] - It’s FREE. Please let us know if you have any questions via email to ptg(a)openinfra.dev. Thanks! -Kendall (diablo_rojo) [1] PTGbot Site: https://ptg.opendev.org/ptg.html [2] PTGbot Documentation: https://opendev.org/openstack/ptgbot/src/branch/master/README.rst [3] Setup IRC: https://docs.openstack.org/contributors/common/irc.html [4] PTG Registration: https://ptg2024.openinfra.dev/

1 0

openstacksdk, ironicclient, os-fault: Please replace python3-appdirs dependency with platformdirs
by Thomas Goirand 01 Apr '24

01 Apr '24

Hi, 3 bugs have been opened in Debian to get appdirs replaced by platformdirs: https://bugs.debian.org/1067995 https://bugs.debian.org/1067999 https://bugs.debian.org/1068000 Here's the bug report content: > python3-appdirs is dead upstream[1] and its Debian maintainer has > indicated that it should not be included in trixie[2]. A recommended > replacement is python3-platformdirs[3], which is a fork of appdirs > with a very similar API. > > Please migrate from appdirs to platformdirs or some other replacement, > so that appdirs can be removed. > > Thanks, > smcv > > [1] https://github.com/ActiveState/appdirs/commit/8734277956c1df3b85385e6b308e9… > [2] https://bugs.debian.org/1060427 >[3] https://pypi.org/project/platformdirs/ Can we do that in upstream OpenStack, during the Dalmatian cycle? Cheers, Thomas Goirand (zigo)

3 3

[Glance][PTG] Glance Dalmatian 2024.2 PTG Schedule
by Pranali Deore 01 Apr '24

01 Apr '24

Hello All, Dalmatian (2024.2) virtual PTG is going to start next week and we have created our PTG etherpad [1] and also added day wise topics along with timings we are going to discuss. Kindly let me know if you have any concerns with allotted time slots. Friday is reserved for any unplanned discussions. So please feel free to add your topics if you haven't added yet. As a reminder, these are the time slots for our discussion. Tuesday 9 APRIL 2024 1400 UTC to 1700 UTC Wednesday 10 APRIL 2024 1400 UTC to 1700 UTC Thursday 11 APRIL 2024 1400 UTC to 1700 UTC Friday 12 APRIL 2024 1400 UTC to 1700 UTC NOTE: At the moment we don't have any sessions scheduled on Friday, if there are any last moment request(s)/topic(s) we will discuss that on Friday else we will conclude our PTG on Thursday 11th APRIL. The meeting URL is mentioned in etherpad [1] and will be the same throughout the PTG. [1]: https://etherpad.opendev.org/p/apr2024-ptg-glance#L1 Hope to see you there!! Thanks & Regards, Pranali Deore

1 0