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

[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 18 Apr '24

18 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

[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