- openstack-discuss - lists.openstack.org

[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