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

[cinder][PTG] 2024.2 Dalmatian PTG summary
by Jon Bernard 25 Apr '24

25 Apr '24

Hello everyone, thanks for a very productive PTG for the Dalmatian cycle. Below is a brief summary of the highlights. The raw etherpad notes are here[1] and both the summary and transcribed etherpad notes are captured in our wiki here[2]. # Improve driver documentation When proposing new or updating existing drivers, our interface can be confusing. We agreed on an effort to migrate class documentation to the interface definitions, make clear the mandatory and optional methods for drivers, and maintain this documentation going forward. # User visible information in volume types Volume type metadata and extra specs are not visible to users, making it difficult to ascertain whether a volume type will lead to encryption or replication. Agreement was reached on metadata fields similar to Glance's metadefs, allowing drivers to report capabilities in a standard way and allowing that metadata to become visible to admins and users. # Optional backup driver dependencies Although volume driver dependencies are optional, those of our backup drivers are listed in requirements and are therefore always installed irrespective of deployment configuration. Agreement was reached to move these dependencies to driver-requirements. This should simplify efforts of both deployers and packagers. # Simplify deployments A few ideas were proposed to improve our deployment: * When cinder-volume is deployed in an active-active configuration, our `backend_host` parameter must be updated on every backend to have the same value, we would like to remove this additional step. * Use of predictable names to define tenants, instead of unique IDs. * Have dedicated quote section in our configuration for quote-related options. # Response schema validation A spec to add response schema validation in addition to our existing request validation was proposed. With adequate coverage, clients in various languages could be autogenerated (in theory). No significant objects were raised, agreement to review related patches this cycle. # Documentation of Ceph auth requirements We do not provide comprehensive and easy-to-find documentation on exactly what authentication/permission expectations there are between different services, leading deployers troubleshoot themselves and not be able to rely on upstream best practices. Agreement to improve this situation in the current cycle. # Cinder backup improvements An accumulation of bug fixes and performance improvements have stalled in the review queue. We went through the major ones as a team to attempt to bring awareness and unblock the remaining review requirements. See WIKI notes for specific details. # Migrating backups between multiple backends There is desire to support multiple backup backends where new backups go to a new backend while backups in an old backend remain readable. We want to avoid needing to create a full backup in the new backend to support incremental snapshots (and the associated charge). A spec will be proposed for review and work towards this goal will proceed during this cycle. # Cross-project with Glance In a cross-project collaboration with the Glance team, an improved method for image migration was proposed. Agreement to introduce a new migration operation in Glance. Cinder context was provided and a consensus on path forward was reached. # Cross-project with Nova In a cross-project collaboration with both Nova and Glance, the topic of image encryption was discussed. Dan Smith from the Nova team provided input from the Nova side. Cinder and Nova expect LUKS formatted images, but Glance currently supports GPG encrypted images - requiring re-encryption prior to use. It was noted that LUKS encrypted images can be created without root permission and the Glance team is now looking to drop GPG support and consolidate around LUKS as our unified format. # Active-Active support for NetApp A NetApp engineer raised questions about adding active-active support to the driver. Questions were answered and that work should proceed in this cycle. # Performance of parallel clone operations For the clone operation in cinder we're using a single distributed lock to prevent the source volume from being deleted mid-operation. This causes multiple concurrent clone operations to block. Under the right conditions, this can cause a significant performance degradation. Multiple possible solutions were discussed (read-write locks) and a consensus to use the DB was reached. Some details are unclear, awaiting a spec before moving forward. # Volume encryption with user defined keys Cinder does not currently support encryption with key provided by the user. Users could both manage their own keys and data could be recovered even if keys are lost at the deployment. There are several technical challenges to support this. Several of these hurdles were raised, more thought and research is needed before we have a spec that could be reviewed. [1] https://etherpad.opendev.org/p/dalmatian-ptg-cinder [2] https://wiki.openstack.org/wiki/CinderDalmatianPTGSummary -- Jon

2 1

[ironic][neutron] Another networking path for Ironic?
by Julia Kreger 25 Apr '24

25 Apr '24

Greetings folks, During the Ironic PTG last week, Ironic had our busiest PTG session on the topic of networking, and what to do in order to move things forward. I think the best way to frame how we reached the discussion is to keep in mind that projects in our community have been built upon boundaries of delineation. For example, Nova for is virtualization. Ironic’s area has been bare metal machine deployment and lifecycle management. Neutron’s area has been networking. Ironic has always fit a little more awkwardly into this model due to the nature of bare metal – as evidenced by the networking related (networking-generic-switch, networking-baremetal) projects living under Ironic’s governance driven by the need to be able to toggle physical switch ports to ensure a secure provisioning process. Now it's getting even more awkward as the lines between a server and a switch start to blur. Ironic is one of the few OpenStack projects that has significant use cases outside of a fully integrated OpenStack cluster. Additionally, even in the fully integrated case, bare metal is often not the primary use case considered -- quite understandable since virtualized networking is not a trivial problem. This combination of two factors: physical networking being a secondary use case for Neutron, and operators wanting to get physical network automation even without a fully integrated OpenStack, leads to difficulties both on the development side and the operational side. This creates a situation where Ironic’s answer to just basic network automation of “use Neutron and an ML2 plugin” is really not tenable for many infrastructure operators. The underlying challenge is that infrastructure operators need something for just basic management actions like attaching or detaching hosts from physical networks which also works in a model of respecting separation of duties. This is further complicated with DPUs and the changing landscape DPUs are creating by forcing a much more complex interaction when it comes to just basic networking needs for supporting the deployment of a bare metal host. To attach a network to a host, it is no longer just toggle a switchport configuration, it is potentially toggle a switchport *and* toggle configuration on a DPU device. And in this weeks’ Ironic PTG session, “Future of networking”[0], discussion of DPUs helped us reach a tipping point for the discussion. The idea of a separate network interface (for Ironic to use) which was not neutron, reached a point of being a chorus of contributors. So to put it in different words, Ironic is considering implementing functionality for Switch and DPU device network configuration management in terms of device attachment to networks which would likely leverage the existing ML2 plugin model such that Ironic can trigger port attachment and detachment directly. We’re not talking about doing anything beyond attachment and detachment. This means aspects like IPAM, Security Groups, Routing, and so on and so forth are entirely off the table for us. Our answer for such will continue to be “use neutron.” The discussion thus far has focused on not replacing existing plugins, but to enable their use. To use the plugins today, Neutron and the involvement of other OpenStack services are required – which is not viable for approximately half of Ironic’s usage base. For example, a Metal3 user is only using Ironic as an embedded tool, and if their environment requires VXLAN networks to be terminated on a DPU then they would need to create/invent tooling to facilitate that, or we can solve that with Ironic and account for the overall physical machine lifecycle at the same time. We also see a path where we can better integrate with Neutron and help operator’s meet more restrictive security requirements by delineating part of the functionality into Ironic’s scope when leveraging upstream solutions. We realize there are many unknowns, and welcome Neutron contributors to collaborate[1] with us, as this could ultimately impact project scope. Thoughts? Thanks, Julia [0]: https://etherpad.opendev.org/p/ironic-ptg-april-2024#L609 [1]: https://review.opendev.org/c/openstack/ironic-specs/+/916126/

2 2

Instance stuck in BUILD status
by 西岭 25 Apr '24

25 Apr '24

Dear openstack trove module developers, I was having trouble creating a trove instance and kept showing build status. My create command is: trove create mysql_zh-11 1 --size 5 --nic net-id=5f161d13-0cfb-4707-9bd6-f23850d86fbf --databases dbtest --users user:password --datastore mysql --datastore_version mysql-5.6 After entering the trove list command, the final state is: | bdcb298c-86d3-42c5-b7af-1cc0c7f93904 | mysql_zh-11 | mysql | mysql-5.6 | BUILD | 1 | 5 | RegionOne | The image I used was downloaded from the openstack website: trove-train-mysql-ubuntu-xenial Enter the openstack server list command and it will display: 2bf580eb-3c93-4689-9b53-e76307beb241 | mysql_zh-11 | ACTIVE | external-net=192.168.0.56 | trove-train-mysql-ubuntu-xenial | mysql-mini | I don't know the username and password of the image, so I can't see the specific information inside the cloud host. In addition, when I used the tool to change the login username and password of the above image, and created the trove instance with the image, after waiting 3600 seconds, it showed: trove.taskmanager.models [-] Service status: ERROR, service error description: guestagent error: TroveError: Failed to get server 0908ee4e-9f1d-444a-9c69-c8b8cc9d8938 for instance 03c2a10c-87f1-4169-9cf7-13735ff8756c, error: Failed to validate token (HTTP 404) (Request-ID: req-9604fb4c-4aae-4351-8996-5ee4dfbd9ad3) This time, I was able to log in to the cloud host generated during the creation of trove. After entering, I found that the guest-agent service failed to start. The reasons were: sudo chown -R ubuntu:root /etc/trove/conf.d cannot be executed. I wonder if it is because the password of the image has been changed? Then, I used the same image to create the trove instance again, and during the instance creation process, I went to the cloud host and started the guest-agent service manually. The result was the same. What else did I miss when creating the instance? How to solve this problem? See attachment for details of trove log. Thank you very much for your help. ----------------------------------------------------- Xi Ling, from Qingdao, China April 25, 2024

1 0

Secure RBAC manager role
by Sławek Kapłoński 25 Apr '24

25 Apr '24

Hi, I started looking at the S-RBAC today and for the phase 3 [1] especially. My question is - do we have agreement how this MANAGER will look like? In the linked document there is only info that keystone's spec [2] will have to be changed but I'm not sure if this is final now and if we can/should start thinking and implementing policies for the MANAGER role or not yet. [1] https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rb… [2] https://review.opendev.org/c/openstack/keystone-specs/+/818603 -- Slawek Kaplonski Principal Software Engineer Red Hat

3 5

[Glance] Deprecate metadata_encryption_key
by Pranali Deore 25 Apr '24

25 Apr '24

Hello Everyone, Glance core team have discussed and decided during Dalmatian PTG[1] about depreciation of `metadata_encryption_key` config option. We decided to deprecate it in this cycle and remove it in `E` (2025.1) cycle[2]. Problems with `metadata_encryption_key` config option and its related functionality: 1. It was added quite a long time ago and even though as per the description it should encrypt the location metadata but it actually encrypts the location url. 2. It encrypts the location url only for image upload/import/download/show APIs and doesn't encrypt url on location APIs. 3. If it's enabled during upgrade, it will break the existing deployment since the existing image url is not encrypted. 4. It doesn't even work for location url encryption as expected since it does not encrypt the legacy images url on start up, download of that image fails with InvalidLocation error. If there are any objections/suggestions on the above plan kindly please let us know before the spec freeze date of glance which is July 05,2024. If there will be no response till 5th July, we will assume that it's a go forward signal and can merge the spec lite[2] for the same. [1]: https://etherpad.opendev.org/p/apr2024-ptg-glance#L339 [2]: https://review.opendev.org/c/openstack/glance-specs/+/916178 Thanks & Regards, Pranali Deore

2 1

[magnum] Policy doesn't allow certificate:get
by Satish Patel 24 Apr '24

24 Apr '24

Folks, I have recently deployed openstack 2023.1 using kolla-ansible and after setting up magnum I noticed the following policy error when obtaining cards. After reading [1] the policy file looks like it needs a reader role to obtain a certificate. I have assigned the "reader" role to the user but still getting the same error message and no luck. $ openstack role add --user user1 --user-domain mydomain1 --project myproject1 reader # Reload User Creds RC file. $ openstack coe cluster config dev2 Policy doesn't allow certificate:get to be performed (HTTP 403) (Request-ID: req-7445ef3c-52a3-4911-97f6-1fb25d9fac1f) What else could be wrong here? 1. https://docs.openstack.org/magnum/latest/configuration/sample-policy.html

2 5

[tc][ptl][dpl] Policy to reset the DPL model every cycle
by Ghanshyam Mann 24 Apr '24

24 Apr '24

Hello Everyone. In vPTG, TC discussed improving to monitor the DPL model & its liaison's activeness. As per current policy[1], we rely on the liaisons to make sure they update the governance if they are not active in assigned roles or TC members to regularly check the DPL projects. Due to various reasons, this did not help and we saw many projects or liaisons going inactive and are detected very late. To improve the DPL model monitoring, I proposed resetting the DPL model to the PTL model every cycle and project teams need to opt-in DPL model every cycle. I would like to highlight this change to the projects currently on the DPL model or planning to adopt the same in future. Feel free to review and provide your feedback on the gerrit change mentioned below: - https://review.opendev.org/c/openstack/governance/+/916833 [1] https://governance.openstack.org/tc/resolutions/20200803-distributed-projec… -gmann

1 0

[largescale-sig] Next meeting: March 27, 9utc
by Thierry Carrez 24 Apr '24

24 Apr '24

Hi everyone, The Large Scale SIG will be meeting this Wednesday in #openstack-operators on OFTC IRC, at 9UTC. Arnaud Morin will be chairing. You can doublecheck how that UTC time translates locally at: https://www.timeanddate.com/worldclock/fixedtime.html?iso=20240327T09 Feel free to add topics to the agenda: https://etherpad.opendev.org/p/large-scale-sig-meeting Regards, -- Thierry Carrez

2 3

openstack python3-keystone package
by Sari Zidan 24 Apr '24

24 Apr '24

Dear OpenStack Support Team, I'm a DEVOPS engineer who works for Zadara LTD. I hope this email finds you well. I am reaching out to inquire about the python-keystone package provided by OpenStack. Currently, our company utilizes Ubuntu Bionic (18.04.6) on our machines, and we have the python-keystone package installed and in use. However, we are now looking to upgrade to Python 3 and, consequently, need to transition from python-keystone to python3-keystone. In our codebase, we've integrated interfaces and APIs that rely on functions from the python-keystone Python library. However, as we transition to python3-keystone, I've identified several deprecated functions and modules which are no longer supported within the new package. To address this, I'm reaching out for assistance in finding suitable replacements within the new package. The deprecated functions/modules that require replacement (no longer supported by the new package) are: 1. keystone.common.dependency.resolve_future_dependencies() 2. keystone.auth.controllers.Auth.validate_token() 3. keystone.contrib.ec2.controllers.Ec2ControllerV3 - specifically: create_credential(), delete_credential() and get_credential() 4. keystone.resource.controllers.ProjectV3 - specifically: get_project, update_project, delete_project, create_project. 5. keystone.assignment.controllers 6. keystone.token.persistence.PersistenceManager Any guidance or assistance you can provide on this matter would be greatly appreciated. Thank you for your attention to this inquiry, and I look forward to hearing from you soon.

1 0

RDO Caracal 2024.1 Released
by Amy Marrich 24 Apr '24

24 Apr '24

RDO Caracal 2024.1 Released The RDO community is pleased to announce the general availability of the RDO build for OpenStack 2024.1 Caracal for RPM-based distributions, CentOS Stream and Red Hat Enterprise Linux. RDO is suitable for building private, public, and hybrid clouds. Caracal is the 29th release from the OpenStack project, which is the work of more than 1,000 contributors from around the world. The release is already available for CentOS Stream 9 on the CentOS mirror network in: http://mirror.stream.centos.org/SIGs/9-stream/cloud/x86_64/openstack-caraca… The RDO community project curates, packages, builds, tests and maintains a complete OpenStack component set for RHEL and CentOS Stream and is a member of the CentOS Cloud SIG. The Cloud SIG focuses on delivering a great user experience for CentOS users looking to build and maintain their own on-premise, public or hybrid clouds. All work on RDO and on the downstream release, Red Hat OpenStack Platform, is 100% open source, with all code changes going upstream first. The highlights of the broader upstream OpenStack project may be read via https://releases.openstack.org/caracal/highlights.html but here are some highlights: - Drivers with inactive CI were marked unsupported including Windows iSCSI Driver, Windows SMB Driver, Dell SC Series Storage Driver (iSCSI, FC), Dell VNX Storage Driver (FC, iSCSI) and Dell XtremeIO Storage Driver (iSCSI, FC). - New driver features were added, notably, Fujitsu ETERNUS DX extend volume on RAID group, Pure Storage synchronous replication, NetApp iSCSI LUN space allocation, Dell PowerFlex Active-Active support, Dell PowerMax configurable SRDF snapshots. - Designate now supports Catalog Zones (RFC 9432). This can improve the scalability of Designate pools managing a large number of zones and significantly reduce the provisioning time when adding additional DNS servers to a Designate pool. - Horizon now uses Django 4.2 as default and dropped Django 3.2 support. - Ironic has enabled RBAC support by default by changing the default values of [oslo_policy]enforce_scope and [oslo_policy]enforce_new_defaults to True. Additionally, we added [DEFAULT]rbac_service_project_name to define a project where users in that project are treated as having a service role. Please see Ironic release notes for full details. - Ironic has added the ability to drain active tasks from a conductor before shutdown. Sending a SIGUSR2 signal to an ironic-conductor will now attempt to complete running tasks with a timeout of [DEFAULT]drain_shutdown_timeout. No new tasks will be started on the conductor while it’s draining. - Support was added for the external-gateway-multihoming API extension. The L3 service plugins supporting it can now create multiple gateway ports per router. It is currently limited to the L3 OVN plugin. OpenStack Caracal is marked as Skip Level Upgrade Release Process or SLURP. According to this model ( https://governance.openstack.org/tc/resolutions/20220210-release-cadence-ad…) this means that upgrades will only be supported from the Antelope 2023.1 release. RDO Caracal 2024.1 has been built and tested with the recently released Ceph 18.2.0 Reef version (https://docs.ceph.com/en/latest/releases/reef/) which has been published by the CentOS Storage SIG in the official CentOS repositories. *Note:* Follow the instructions in [RDO documentation]( https://www.rdoproject.org/install/install-with-ceph/) to install OpenStack and Ceph services in the same host. During Caracal cycle, some projects have been retired or declared inactive upstream. As such, the following packages for some projects are not present in the RDO Caracal 2024.1 release: - cinderlib - dib-utils - ec2api-tempest-plugin - ec2api - murano - murano-agent - muranoclient - murano-dashboard - murano-tempest-plugin - sahara - sahara-dashboard - sahara-image-elements - sahara-plugin-ambari - sahara-plugin-cdh - sahara-plugin-mapr - sahara-plugin-spark - sahara-plugin-storm - sahara-plugin-vanilla - sahara-tests - senlin - senlinclient - puppet-ec2api - puppet-etcd - puppet-haproxy - puppet-module-data - puppet-murano - puppet-qdr - puppet-rsyslog - puppet-sahara During the next release we will continue working on retiring inactive packages in order to ensure RDO content quality and security. Contributors: - During the Caracal cycle, we saw the following new RDO contributors: - Marihan Girgis - Balazs Gibizer - Fiorella Yanac Welcome to all of you and Thank You So Much for participating! But we wouldn’t want to overlook anyone. A super massive Thank You to all 47 contributors who participated in producing this release. This list includes commits to rdo-packages, rdo-infra, and rdo-website repositories: - Ade Lee - Alfredo Moralejo Alonso - Amy Marrich (spotz) - Arx Cruz - Balazs Gibizer - Bernard Cafarelli - Bohdan Dobrelia - Chandan Kumar - Cyril Roelandt - Daniel Pawlik - Douglas Viroel - Emma Foley - Fabricio Aguiar - Fiorella Yanac - Gregory Thiemonge - Grzegorz Grasza - Harald Jensås - Jiří Podivín - Joan Francesc Gilabert - Joel Capitao - Karolina Kula - Lewis Denny - Lon Hohberger - Luigi Toscano - Luis Tomas Bolivar - Lukáš Piwowarski - Maor Blaustein - Marihan Girgis - Marios Andreou - Martin Kopec - Martin Magr - Mathieu Bultel - Michael Johnson - Nate Johnston - Pablo Rodríguez Nava - Priscila Gutierres - Rabi Mishra - Roberto Alfieri - Ronelle Landy - Shreshtha Joshi - Soniya Vyas - Szymon Datko - Takashi Kajinami - Tobias Urdin - Tristan De Cacqueray - Yatin Karel - Zane Bitter The Next Release Cycle At the end of one release, focus shifts immediately to the next release i.e Dalmatian. Get Started To spin up a proof of concept cloud, quickly, and on limited hardware, try an All-In-One Packstack installation. You can run RDO on a single node to get a feel for how it works. For those that do not have any hardware or physical resources, there is the OpenStack Global Passport Program. This is a collaborative effort between OpenStack public cloud providers to let you experience the freedom, performance and interoperability of open source infrastructure. You can quickly and easily gain access to OpenStack infrastructure via trial programs from participating OpenStack public cloud providers around the world. Get Help The RDO Project has our users(a)lists.rdoproject.org for RDO-specific users and operators. For more developer-oriented content we recommend joining the dev(a)lists.rdoproject.org mailing list. Remember to post a brief introduction about yourself and your RDO story. The mailing lists archives are all available at https://mail.rdoproject.org. You can also find extensive documentation on RDOproject.org. The #rdo channel on OFTC IRC is also an excellent place to find and give help. We also welcome comments and requests on the CentOS devel mailing list and the CentOS IRC channels (#centos, #centos-cloud, #centos-devel in Libera.Chat network), however we have a more focused audience within the RDO venues. Get Involved To get involved in the OpenStack RPM packaging effort, check out the RDO contribute pages, peruse the CentOS Cloud SIG page, and inhale the RDO packaging documentation. Join us in #rdo and on the OFTC IRC network and follow us on Twitter @RDOCommunity. You can also find us on Facebook and YouTube.

1 0