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

[designate] Support for DNSSEC // Bump in the wire signer via BIND9 or Knot
by Christian Rohmann 18 Apr '24

18 Apr '24

Hello, I was wondering is anybody knew about the current state of DNSSEC signing for Designate-managed zones. Since Designate MDNS serves as primary they actually should do the signing / provide already signed zones via zone transfers. Adding support for DNSSEC this was last discussed for Kilo [1], but that spec was never finished, DNSSEC support never implemented. One approach to do this is using a bump in the wire signer [2][3][4] and have an intermediate BIND9 or Knot server doing the signing. Has anybody implemented something of this kind? If so, how do your users receive their initial DS / DNSKEY for the parent zone? Regards Christian [1] https://review.opendev.org/c/openstack/designate-specs/+/132571 [2] https://bind9.readthedocs.io/en/latest/dnssec-guide.html#bump-in-the-wire-s… [3] https://jpmens.net/2023/07/22/adieu-opendnssec-bienvenido-knot-dns/ [4] https://labs.ripe.net/author/anandb/dnssec-signer-migration/

4 7

[kolla] openstack centralized logging
by Eugen Block 18 Apr '24

18 Apr '24

Hi, I'm trying to find out how the "Venus" project could work. Unfortunately, there's not much to find yet. There's no installation guide as for other projects although it already exists since Zed release. I tried enabling it in my kolla all-in-one test deployment (2023.1), the api and manager container are running, but I have no idea how to get some data into or out of it. My conclusion is that it's not a mature project yet, could anyone comment on that? As an alternative, I enabled centralized logging in the same deployment as well, but unfortunately I can't use the dashboard because of [1]. So I don't really know what I can get out of opensearch in order to have a centralized logging. If possible, I would like to adapt that to a non-containerized openstack deployment. How can I change the opensearch version in my kolla deployment to be able to login and inspect what I got? Any pointers and comments are highly appreciated! Thanks! Eugen [1] https://bugs.launchpad.net/kolla-ansible/+bug/2060306

4 9

[tacker][ptg] Dalmatian PTG Summary
by Yasufumi Ogawa 17 Apr '24

17 Apr '24

Hi all, Here is a summary of Tacker team's two days discussion during vPTG 2024.2[1]. # Revise FTs We've tried to revise functional tests on zuul for the latest cycles to reduce the burden of rechecks for unexpected failures which are sometimes happened especially at the end of the cycles. We have several targets for the revise, such as clean dir structure, reduce the amount of test scenarios or so, and share the status of each tasks. # Progress report for Legacy API deprecating/obsoleting Done dropping all the regacy codes from tacker and its client, but still remained in tacker-horizon. We're going to complete this task in this release. # Opentelemetry plugin Support for opentelemetry's observability was proposed in Caracal, but couldn't be finished because of some more higher priority tasks. We've agreed to change the plan to release the feature is this release. # Support devstack install for Cilium as a CNI of Kubernetes VIM We released a sample VNF package using Cilium CNI for demonstrating VNF applications can communicate via Cilium's high performance connectivity for considering vRAN usecases. # Demonstration for tacker-horizon NFV Orchestration API v2.0 Shared the latest GUI support of tacker-horizon for managing NFV orchestration via ETSI SOL v2.0 APIs. # TOSCA 1.3 support Tacker supports TOSCA as a VNF descriptor defined in OASIS standards[2], but the latest version in the support is TOSCA 1.2. Although there are two choices for us for newer ones, 1.3 or 2.x, we've agree to introduce 1.3 which is considered as the most active version currently and shared the implementation plan in this release. # Proposal for adding Tacker installation with openstack-helm in offical OpenStack-helm document We added tacker support in openstack-helm without documentation in the previous cycle. So, we'll complete the remained task in Dalmatian. # Fix schema definition error of TST 2.6.1 repository TST is an ETSI compliance test suites and each of its versions is compatible with SOL specification's as a maintenance policy in the community. We're going to complete to implement TST 2.6.1. The problem is that there is unexpected data field `virtualLinkDescId` in TST is incompatible with SOL standards. It should be in TST while keeping the versions. We'll propose the issue and fix to the standards. # Performance improvement of "list" APIs There is a performance issue in APIs for retrieving entries from a user feedback and it can be a problem especially in commercial usecases managing large amount of objects. There are several possibility of the performance issue such as lack of database optimization or implementation design is not still well considered. For the issue, we've started to figure out the cause of the issue from some more detailed experimentation. [1] https://etherpad.opendev.org/p/apr2024-ptg-tacker [2] https://groups.oasis-open.org/communities/tc-community-home2?CommunityKey=f…

1 0

[all][unmaintained] Gate status of Unmaintained branches
by Elõd Illés 17 Apr '24

17 Apr '24

Hi, Recently, based on the 'Unmaintained replaces Extended Maintenance' resolution [1], old branches (Xena, Wallaby, and Victoria), originally in Extended Maintenance, moved to Unmaintained, together with Yoga branch that transitioned directly from maintained to Unmaintained as a first such branch. From now on, there is the possibility for folks who are interested in further maintaining these old branches (in the so called 'Unmaintained' state :)). For that, maintainers need to sign up to be a member of openstack-unmaintained-core group (or the project specific group, if such exists). There is no requirement to be part of that group, but we would like to ask 'unmaintainers' to follow the stable policy [2], if possible, for unmaintained/* branches as well (*if the given project follows it on maintained branches). To signal your interest, please write a mail to this mailing list, or ping openstack-unmaintained-core group members (for example me :)) on IRC. As a first important thing, i would like to call attention to the following part of the resolution: 'The CI for all branches must be in good standing at the time of opt-in. At a minimum this needs to contain all integrated jobs, unit tests, pep8, and functional testing. However, as this is a best-effort CI and to preserve resources, Unmaintained branches will include periodic jobs of no higher than monthly frequency.' [1] However, while many gates look healthy [3] (i.e. patches have merged), there are still a significant number of failing CI gates [4]. So, to these projects and their unmaintained/.* branches, to be eligible to kept open for further maintenance and be able to opt-in in the next cycle for maintenance, these gates have to be fixed as soon as possible. Otherwise project branches need to be deleted and transitioned to End of Life. As an example for a simple gate fix, many project/branch need to drop their failing 'lower-constraints' job (or fix them). Also a good starter is to fix zuul config errors [5] if there exists any. Final note from me: as the above quote shows, the concept of good standing CI is quite minimal. Any further CI jobs (devstack based tempest jobs) add value to these branches for those who consume them. So any such work is really appreciated. If you have any question, feel free to ask, either here, on the mailing list, or ping me or the TC on IRC. Thanks for reading this, Előd Illés irc: elodilles @ #openstack-release #openstack-stable #openstack-unmaintained [1] https://governance.openstack.org/tc/resolutions/20230724-unmaintained-branc… [2] https://docs.openstack.org/project-team-guide/stable-branches.html [3] https://review.opendev.org/q/branch:%5Eunmaintained/.*+label:Verified%252B2… [4] https://review.opendev.org/q/branch:%5Eunmaintained/.*+label:Verified-1,225 [5] https://zuul.opendev.org/t/openstack/config-errors?branch=unmaintained%2Fyo…

1 0

[heat] Parametrization of Neutron trunk subports scaling down
by Lajos Katona 17 Apr '24

17 Apr '24

Hi, With Hot templates we run into a scaling issue with Neutron trunk subports. The task is to create Neutron trunks with "vlan_count" number of subports, and with stack update be able to add or remove subports of the created trunk. We tried with resourceGroup, and that works well if we increase the number of subports. The problem comes with decrease, as with resourceGroups I can't (my lack of knowledge) tell heat_engine that first update the trunk and remove the subport and after that delete the port. And Neutron API gives back conflict as the port which heat_engine tries to delete is still used by the trunk. Do you know a way to accomplish such an operation with Hot templates? Thanks in advance for the help. Best wishes Lajos Katona (lajoskatona)

2 4

[magnum] Dalmatian PTG summary
by Jake Yip 17 Apr '24

17 Apr '24

Hi all, Magnum held our PTG on 2024-04-10 0600-0800 UTC. I have summarised some points that may be of interest. 1. Magnum team is small, we welcome help with reviews, documentation, deprecation. 2. In Caracal, we have done a lot of work improving the CI. This allowed us to confidently remove old code that has been dragging us down. A big shout out to mnasiadka for this effort. For Dalmatian, we are improving this further with sonobuoy tests, etc. 3. In Caracal, we enhanced the driver code to support multiple drivers. Historically, Magnum drivers were in tree. It was difficult to support out-of-tree drivers without clashing. With Caracal, now an operator can have multiple active drivers in their installation, and can also move to new drivers in the future. 4. ClusterAPI driver There are two ClusterAPI drivers developed by different organisations (outside Magnum). - magnum-capi-helm - out-of-tree, in governance - https://github.com/openstack/magnum-capi-helm - magnum-cluster-api - out-of-tree, outside goverance - https://github.com/vexxhost/magnum-cluster-api StackHPC as kindly offered to move their magnum-capi-helm driver to OpenStack governance, and will work with Magnum team to get it working in CI in Dalmatian. Thanks mnasiadka, mkjpryor, johnthetubaguy, travisholton, for this work. A number of users are also reporting success with magnum-cluster-api driver. Feel free to try this out and ask questions on ML. Thanks mnaser who have been active on the ML answering questions. 3. Heat driver Currently the Heat driver supports Kubernetes v1.27 in Caracal. We aim to get v1.28 supported in Dalmatian. v1.29 is already supported in both ClusterAPI drivers. Heat driver still needs to be supported for possibly one/two cycles once ClusterAPI driver is available, so we target F for removal of Heat driver. For more information, please see the etherpad [1], or join the Magnum meeting if you have any questions. Regards, Jake

1 0

[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