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

[openstack-ansible][magnum-cluster-api]
by pahrialtkj＠gmail.com 19 Apr '24

19 Apr '24

I tried magnum-cluster-api on openstack ansible with Antelope version, I have finished creating the k8s control plane containers and then Run the magnum-cluster-api deployment, but at the time of running it an error was found, where the role openstack.osa.lxc_container_setup is not available, anyone knows how to solve it? root@aio1:/opt/openstack-ansible# openstack-ansible osa_ops.mcapi_vexxhost.k8s_install Variable files: "-e @/etc/openstack_deploy/user_secrets.yml -e @/etc/openstack_deploy/user_variables.yml -e @/etc/openstack_deploy/user_variables_octavia.yml " [WARNING]: Unable to parse /etc/openstack_deploy/inventory.ini as an inventory source [WARNING]: running playbook inside collection osa_ops.mcapi_vexxhost ERROR! the role 'openstack.osa.lxc_container_setup' was not found in osa_ops.mcapi_vexxhost:ansible.legacy:/etc/ansible/ansible_collections/osa_ops/mcapi_vexxhost/playbooks/roles:/etc/ansible/roles:/etc/ansible/roles/ceph-ansible/roles:/etc/ansible/ansible_collections/osa_ops/mcapi_vexxhost/playbooks The error appears to be in '/etc/ansible/ansible_collections/osa_ops/mcapi_vexxhost/playbooks/k8s_install.yml': line 36, column 15, but may be elsewhere in the file depending on the exact syntax problem. The offending line appears to be: - import_role: name: openstack.osa.lxc_container_setup ^ here EXIT NOTICE [Playbook execution failure] ************************************** ===============================================================================

2 5

[PTL][release][stable] Transition Zed to Unmaintained
by Elõd Illés 19 Apr '24

19 Apr '24

Hi teams, As 2024.1 Caracal was released recently and we are in a less busy period, now is the good time to call your attention to the following: In less than 2 weeks Zed is planned to transition to Unmaintained [1] state as planned date is May 2nd, 2024. (For details about Unmaintained state please see: [2][3]). I have generated the transition patches [4] for Zed's every deliverables. After the transition it will not be possible anymore to release off of Zed branch. So it is strongly recommended to do a *final* Zed release if there are any merged or open patches that would fix a significant bug. On the other hand, please be careful to not to release any breaking changes as there won't be possible to do another release! Please mark the transition patch with a -1 if your team plans to do such final release, or +1 if the team is ready for the transition. The schedule from now on is as follows: * patches with +1 from PTL / release liaison will be merged, thus those repositories will transition to Unmaintained * at the planned deadline (May 2nd) the Release Team will merge all transition patches (even the ones without any response!) * unmaintained/zed branch will be cut from HEAD of stable/zed * after the transition, stable/zed will be *deleted*! * there won't be official releases anymore for Zed Don't forget, that: * backports can be pushed to unmaintained/zed branch * openstack-unmaintained-core (or <project>-unmaintained-core groups if such exists) have the rights to merge patches (please see my former mail about Unmaintained gates [5]) *NOTE*: teams, please focus on wrapping up your libraries first if there is any concern about the changes, in order to avoid broken (final!!) releases! [1] https://releases.openstack.org [2] https://docs.openstack.org/project-team-guide/stable-branches.html#unmainta… [3] https://governance.openstack.org/tc/resolutions/20230724-unmaintained-branc… [4] https://review.opendev.org/q/topic:zed-unmaintained [5] https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… Thanks for reading this, Előd irc: elodilles @ #openstack-release

1 0

[openstack-ansible][magnum-cluster-api] magnum-cluster-api deployment role 'openstack.osa.lxc_container_setup' not found
by pahrialtkj＠gmail.com 19 Apr '24

19 Apr '24

I tried magnum-cluster-api on openstack ansible with Antelope version, I have finished creating the k8s control plane containers and then Run the magnum-cluster-api deployment, but at the time of running it an error was found, where the role openstack.osa.lxc_container_setup is not available, anyone knows how to solve it? root@aio1:/opt/openstack-ansible# openstack-ansible osa_ops.mcapi_vexxhost.k8s_install Variable files: "-e @/etc/openstack_deploy/user_secrets.yml -e @/etc/openstack_deploy/user_variables.yml -e @/etc/openstack_deploy/user_variables_octavia.yml " [WARNING]: Unable to parse /etc/openstack_deploy/inventory.ini as an inventory source [WARNING]: running playbook inside collection osa_ops.mcapi_vexxhost ERROR! the role 'openstack.osa.lxc_container_setup' was not found in osa_ops.mcapi_vexxhost:ansible.legacy:/etc/ansible/ansible_collections/osa_ops/mcapi_vexxhost/playbooks/roles:/etc/ansible/roles:/etc/ansible/roles/ceph-ansible/roles:/etc/ansible/ansible_collections/osa_ops/mcapi_vexxhost/playbooks The error appears to be in '/etc/ansible/ansible_collections/osa_ops/mcapi_vexxhost/playbooks/k8s_install.yml': line 36, column 15, but may be elsewhere in the file depending on the exact syntax problem. The offending line appears to be: - import_role: name: openstack.osa.lxc_container_setup ^ here EXIT NOTICE [Playbook execution failure] ************************************** ===============================================================================

1 0

[oslo][release][requirements] broken watch_log_file depends on unmaintained pyinotify
by Takashi Kajinami 19 Apr '24

19 Apr '24

Hello, # This is mainly a oslo topic but I'm adding release team and requirements # team because we likely need new stable/2024.1 release of oslo.log. I looked into an old oslo.log bug[1] during the weekend and noticed that the watch_log_file option in oslo.log has been broken for some time. Looking into the problem further, I leaned that pyinotify[1] library, which is used in this feature, hasn't been updated for 9 years (!!). What is worse, pyinotify dependes on asynccore which has been removed from Python 3.12 and I'm skeptical that we can fix pyinotify to make it work with Python 3.12. There was an old discussion to replace pyinotify by inorify[3] but itnofiy hasn't been updated for 4 years and looks also unmaintained. I think the only option we have here is deprecating the functionality in 2024.1 so that we can remove it in early phase of 2024.2. Because we are quite close to 2024.1 GA, we have to make the decision early. I've already proposed the change for deprecation[4]. If you have any concerns then please reply to this email or leave your comments in the review. Thank you, Takashi [1] https://bugs.launchpad.net/oslo.log/+bug/1740111 [2] https://github.com/seb-m/pyinotify [3] https://github.com/dsoprea/PyInotify [4] https://review.opendev.org/c/openstack/oslo.log/+/914788 -- Takashi Kajinami irc: tkajinam github: https://github.com/kajinamit launchpad: https://launchpad.net/~kajinamit

3 5

[policy][ptg] RBAC 2024.1 Dalmatian cycle vPTG discussions summary
by Ghanshyam Mann 19 Apr '24

19 Apr '24

Hello Everyone, I am summarizing the RBAC discussion that happened on Wednesday. Complete notes can be found @ https://etherpad.opendev.org/p/rbac-2024.2-ptg Goal document: https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rb… Tracking: https://etherpad.opendev.org/p/rbac-goal-tracking Total Attendees: 10-15 Current progress: --------------------- There are a few projects that progress in various phases, one of them is Tacker completed the phase-1. Current progress can be found @ https://etherpad.opendev.org/p/rbac-goal-tracking Phase-2 (service role): -------------------------- This has two parts, 1. Change APIs policy default which is meant for service-to-service usage only to allow for service roles. 2. Use service tokens to interact with other services. In 2nd case, we need to use both the user token and as well as service token. Service token will be used for authentication purposes only and user token to do all other operations. Slaweq updated that Neutron changed the policy but needs to change the token to be used by interaction with other service. Action item: - gmann to add the job to make service user token (have service role only) to validate/capture any failure while we do service token/policy changes. Enable 'enforce_scope' by default & drop this config option: ---------------------------------------------------------------------- We discussed the plan to drop the enforce_scope config option. Scope enforcement needs to be enabled by default and should not be configurable. I have proposed the plan in the below review, please review and level your feedback. - https://review.opendev.org/c/openstack/governance/+/915179 Before doing that we have one dependency[1] and Takashi needs to test the heat jobs to make sure enabling the enforce_scope by default does not break anything. AGREE: - Takashi to add a heat job to find if enforce_scope=True works perfectly and after that only we can enable the flag in oslo policy. - Based on the above testing results, change the default value to True to be done in oslo policy and release oslo policy so that CI adopts the new default value. Domain Manager Persona ------------------------------- Details are in the keystone spec[2], there are no objections to this use case. Request to review the spec and provide your feedback. Global reader ---------------- We discussed it at the Vancouver Summit also. There is no objection to adding it but we need spec to be up with details including the new role name. This new global reader can be added like 'admin OR global-reader OR project-reader' AGREE: - 'admin OR global-reader OR project-reader' approach sounds good, especially not to split the admin role and avoid breaking existing use cases. - johnthetubaguy will propose the keystone spec with the details. - gmann to help in implementation. I host the RBAC biweekly meeting[3], feel free to add any topic to the meeting etherpad ('Biweekly meeting' section) - https://etherpad.opendev.org/p/rbac-goal-tracking#L169 [1] https://bugs.launchpad.net/keystone/+bug/2059780 [2] https://review.opendev.org/c/openstack/keystone-specs/+/903172 [3] https://wiki.openstack.org/wiki/Consistent_and_Secure_Default_Policies_Popu… -gmann

2 2

Whitepaper Collaboration - Linux, OpenStack & Kubernetes
by Kendall Nelson 18 Apr '24

18 Apr '24

Hello Folks, As you hopefully know, the OpenInfra Foundation has a history of helping to define patterns and new usage patterns in our ecosystem through its collaboration on whitepapers. With the user survey, we have seen a distinct pattern of users leveraging an entirely open source stack to meet their needs - Kubernetes, OpenStack and Linux together. So, we are planning the compilation of a whitepaper further explaining this integration, planning to publish in September of this year. Continuing on the theme of collaboration, I would love help with both the writing and the reviewing of two sections in particular - the introduction and integration sections of the whitepaper. Other sections that will be included are model architectures and user case studies from OpenInfra member companies making use of this infrastructure pattern. If you are interested in collaborating on this whitepaper, please contact me directly and I will get you in the loop! Drop me an email to knelson(a)openinfra.dev -Kendall

1 0

[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