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

[openstack-helm] Cleanup OSH ingress chart
by Vladimir Kozhukalov 20 Apr '24

20 Apr '24

Hi dear colleagues, Some time ago we switched all our test deployment jobs to using the upstream Ingress-nginx chart. So it looks like we can recommend using one of the third party ingress controller charts to all our users. The deployment requirements for third party ingress controllers like ingress class name and ingress pod labels are described in the documentation [1] and this script [2] can be used as an example. I suggest removing the OSH ingress chart to reduce the code base that we need to support. Opinions are very welcome. [1] https://docs.openstack.org/openstack-helm/latest/install/deploy_ingress_con… [2] https://opendev.org/openstack/openstack-helm/src/branch/master/tools/deploy… -- Best regards, Kozhukalov Vladimir

4 4

[kolla][kolla-ansible] Promethus libvirt_export with project_name label
by Satish Patel 19 Apr '24

19 Apr '24

Folks, I am collecting metrics of libvirt using prometheus_libvirt_exporter and it works but I am trying to add project_name tag in each libvirt label so I can shorten them by project_name. It Looks like kolla default image of prometheus libvirt version doesn't have that option to send project name. Based on this repo - https://github.com/kumina/libvirt_exporter?tab=readme-ov-file We can add --libvirt.export-nova-metadata flag to send project_name label in each job. Do I need different versions of libvirt_exporter to make it work or am I missing something? # /opt/libvirt-exporter --help usage: libvirt_exporter [<flags>] Prometheus metrics exporter for libvirt Flags: --help Show context-sensitive help (also try --help-long and --help-man). --web.listen-address=":9177" Address to listen on for web interface and telemetry. --web.telemetry-path="/metrics" Path under which to expose metrics. --libvirt.uri="qemu:///system" Libvirt URI from which to extract metrics. --version Show application version.

1 0

[tc] TC vPTG 2024.2 Summary / Notes
by Jay Faulkner 19 Apr '24

19 Apr '24

Hi all, We had TC PTG sessions during the vPTG last week. I'm going to give an extremely high level summary of topics/action items here, as always for full context please see the etherpad: https://etherpad.opendev.org/p/apr2024-ptg-os-tc -- and, as always, remember TC decisions are made via gerrit patches; PTG conversations just help us rapidly spin up context for input to those decisions. # TC <> Community Interaction session Job failures were a hot topic during this session, with TC and community members discussing strategies for helping newer contributors troubleshoot and understand the importance of troubleshooting intermittent gate failures. Several suggestions were made, but no concrete actions were identified to take. Getting things done in Openstack / 'modernization' was the other topic discussed in this session. Some contributors identified that changes such as more strict typing may not be considered a straightforward benefit over duck-typed python. Generally there was no conclusion here either for the whole of OpenStack, however, individual projects should not feel like they need to wait for "permission" to perform these kinds of modernization activities. # OpenStack - where are we, where are we going ## User Survey Analysis Slaweq summarized the user survey in a governance patch, https://review.opendev.org/c/openstack/governance/+/900516, as usual (thank you!) and the TC members and community discussed it. It was noted that as he was summarizing the survey results, Slaweq indicated he found some comments which went against community spirit, attributing a lack of contribution to "not helping competition". Some of the other comments were around data and the validity thereof; such as the 24% of users who responded they don't upgrade OpenStack potentially answering that because they replace the cluster in-place. ACTION: Goutham volunteered to help reword the questions to avoid pitfalls mentioned during the session. ## Re-Visioning OpenStack aka "What is OpenStack Now" JayF, in proposing this topic, suggested that the mission of OpenStack had gotten so large, and the projects so varied, that it's difficult to know what OpenStack itself means -- much less manage it as a whole. This reality was potentially proven via the unfixed Murano CVE during the last cycle. We had some discussion around what being in OpenStack means, and it was reiterated that OpenStack projects are not required to have security issues managed by the VMT or their process. It was pointed out that one of the side effects is that it's difficult to determine what common OpenStack components to teach given the number on the periphery. There was a suggestion that the TC should be doing project reviews to address this concern, but no concrete action was taken. # TC - Specific new governance issues ## Affiliation Diversity Handling in OpenStack TC As most reading this likely already know, during the last TC election there was an issue where affiliation diversity requirements combined with the elected TC members came into conflict. While Bauzas resolved this conflict by stepping aside, we want to prevent this kind of situation from deadlocking in the future. There was a large amount of async discussion and comments on this topic, so I hesitate to summarize them here. Please review the etherpad directly for the myriad of ideas and issues presented by the large amount of engagement in this issue. ACTION: gmann offered to propose guidelines for resolving this in the TC charter. ## Raising the bar for Activity This topic was proposed in response to the Murano CVE and the PTL not participating in a security fix. This raises the question as to how we assessed Murano was an active project, and how to prevent this kind of issue in the future. No consensus was reached on any of the larger-scoped items, however, it was indicated by Julia that the new Cyber Resiliancy Act guidelines, when they are released, may require us to take some kind of action on this front. There were some small items which garnered consensus, such as marking all leaderless projects as inactive by default -- as originally discussed in the 2024.1 PTG. This was another very active discussion with lots of both sync and async engagement -- I strongly suggest you read the direct comments for this topic to get a full feeling of the breadth of this issue. ACTION: https://review.opendev.org/c/openstack/governance/+/914726 was proposed by gmann, which implements the consensus idea to mark leaderless projects as inactive by default. ## Eventlet/AsyncIO migration goal This issue was raised to give a venue for https://review.opendev.org/c/openstack/governance/+/902585 to get synchronous comments/discussion. Dan indicated he had not voted in favor of the change, and didn't plan to until he felt it had a reasonable likelihood to succeed in OpenStack -- early tests of this functionality failed. Jay indicated that his primary concern was elimination of eventlet; the new maintainer group does not plan on keeping eventlet alive forever. Bauzas pointed out that this is more than a goal -- we need dedicated effort in order to execute on this idea. Sean Mooney indicated that we need a non-wsgi service to migrate as an example. Along these lines, we had agreement to reduce scope of the goal to remove eventlet dependencies/requirements from shared OpenStack libraries to enable individual projects to have an easier time with proof of concepts, and revisit the larger goal after such a proof of concept exists. ACTION: JayF to propose a new, smaller scoped goal around removing eventlet dependencies. # Follow-ups from Ongoing TC Activities ## Unmaintained Migration pain points There have been some lingering pain points while migrating from the Extended Maintenance model to Unmaintained. Firstly, despite these branches being "unmaintained", we've set a minimum requirement of green CI with no Zuul config errors in order for a project to continue having their branch open for submission. This does not dictate a minimum level of testing; only that such tests are running and passing. These issues must be repaired in order for an unmaintained branch to remain open, but there are significant numbers that are failing. Please see Elod's recent email to the list for more information and deadlines on these cases. Secondly, tooling for unmaintained branch EOL still needs to have automation completed -- the etherpad contains a full list of the items needed. This goes along with the overall sentiment of this session: the unmaintained branch migration has created an enormous amount of extra work. ACTION: Please go look at Elod's email! This email being sent was a primary action related to this PTG session. ## PyPI Maintainer Cleanup The PyPi maintainer cleanup effort, detailed here: https://etherpad.opendev.org/p/openstack-pypi-maintainers-cleanup has been ongoing for over a year. As of March 15, 2024, we still have 232 project/maintainer pairs to cleanup and 110 separate humans who have access to at least one openstack pypi deliverable. The TC discussed next steps; consensus was that in cases where openstackci holds owner permissions, we are in favor of using those permissions to cleanup where possible. However, in cases where openstackci does not hold owner permissions, it gets a bit more difficult and we have fewer options: either engage with the PSF's process to recover the pypi account, which could take months; or migrate to a different pypi deliverable name. Both are difficult and time-consuming. ACTION: TC to encourage PTLs to once again reach out to any pypi owners/maintainers who have not yet acted to attempt to cleanup their access. ## Revise the project inactive state process This was some specific, targeted discussion around if we needed to revise inactive policy to include the case which happened to Murano -- because our process dictates that inactive projects are only removed from the release prior to milestone-2, finding out Murano was inactive and removing it from the release after M-2 was a special case. This discussion centered primarily around whether any revision to the policy was needed. In the end, no specific action items were created. ## Leaderless projects Details on this item are in https://etherpad.opendev.org/p/2024.2-leaderless and have been sent to the list separately. # Allowing other languages for client facing tools (rust) Notes in the etherpad for this topic was minimal. Essentially, there is no restriction on what languages can be used -- the runtimes document is meant to be specific information about those languages, not restricting other languages that could be used. There were two primary concerns around this item, JayF asked why we were looking into new rust-based tooling instead of integrating with the existing openstack-rust community. Other contributors expressed concerns around being able to understand or debug code in different languages. No action items came out of this discussion. # OpenAPI in OpenStack There was minimal discussion around this item. There appeared to be clear consensus with moving forward with OpenAPI on a project-by-project basis, with any efforts towards creating a goal being pushed until after there is more adoption. # Deprecate all native clients in favor of OpenStackSDK/openstackclient Again, minimal discussion on this item. There seemed to be little objection to just getting it done, but there were no immediate volunteers to do the work. See the etherpad for some specific examples of gaps that need to be resolved. Thank you all for participating in the TC PTG. Please do not let these items fall by the wayside; if you had an idea that didn't reach consensus in the PTG, one possible way to move it forward is a concrete proposal where folks can discuss -- either to the governance repo, or to the mailing list. -- Jay Faulkner OpenStack TC

1 0

[kolla-ansible][Antelope][Heat] Heat UpdateWaitConditionHandle Problems
by Devin Patterson 19 Apr '24

19 Apr '24

Hello, We are attempting to use Heat stacks with wait conditions with nested stacks. We have a test stack similar to this one https://github.com/openstack/heat-templates/tree/master/hot/autohealing where we are scaling a template. We are testing with the proposed fix in the link below. https://review.opendev.org/c/openstack/heat/+/915209/2/heat/engine/resource… Problem being faced is when updating the heat stack, all of the resources are replaced. This is not ideal as we would like the server resources to update with rolling updates. The rolling updates do take place as described in the auto-scaling group, but only after all resources are replaced. Seems the _needs_update call for the wait handle is triggering a replaced for all resources in the nested stack which is not the desired outcome. 2024-04-19 18:12:03Z [stack_1-j190L]: UPDATE_IN_PROGRESS Stack UPDATE started 2024-04-19 18:12:03Z [stack_1-j190L.asg]: UPDATE_IN_PROGRESS state changed 2024-04-19 18:12:04Z [stack_1-j190L.asg]: UPDATE_IN_PROGRESS Stack UPDATE started 2024-04-19 18:12:04Z [stack_1-j190L.asg.4s52xugnxsrl]: UPDATE_IN_PROGRESS state changed 2024-04-19 18:12:05Z [stack_1-j190L.asg.fpe6jz2dccpg]: UPDATE_IN_PROGRESS state changed 2024-04-19 18:12:05Z [stack_1-j190L.asg.4s52xugnxsrl]: UPDATE_IN_PROGRESS Stack UPDATE started 2024-04-19 18:12:06Z [stack_1-j190L.asg.4s52xugnxsrl.wait_handle]: CREATE_IN_PROGRESS state changed 2024-04-19 18:12:06Z [stack_1-j190L.asg.o7dhu7neswv4]: UPDATE_IN_PROGRESS state changed 2024-04-19 18:12:06Z [stack_1-j190L.asg.fpe6jz2dccpg]: UPDATE_IN_PROGRESS Stack UPDATE started 2024-04-19 18:12:07Z [stack_1-j190L.asg.4s52xugnxsrl.wait_handle]: CREATE_COMPLETE state changed 2024-04-19 18:12:07Z [stack_1-j190L.asg.fpe6jz2dccpg.wait_handle]: CREATE_IN_PROGRESS state changed 2024-04-19 18:12:07Z [stack_1-j190L.asg.4s52xugnxsrl.instance1]: UPDATE_IN_PROGRESS state changed 2024-04-19 18:12:07Z [stack_1-j190L.asg.4s52xugnxsrl.wait_condition]: UPDATE_IN_PROGRESS state changed 2024-04-19 18:12:07Z [stack_1-j190L.asg.4s52xugnxsrl.wait_condition]: UPDATE_COMPLETE The Resource wait_condition requires replacement. 2024-04-19 18:12:07Z [stack_1-j190L.asg.4s52xugnxsrl.wait_condition]: CREATE_IN_PROGRESS state changed 2024-04-19 18:12:07Z [stack_1-j190L.asg.o7dhu7neswv4]: UPDATE_IN_PROGRESS Stack UPDATE started 2024-04-19 18:12:07Z [stack_1-j190L.asg.fpe6jz2dccpg.wait_handle]: CREATE_COMPLETE state changed 2024-04-19 18:12:08Z [stack_1-j190L.asg.o7dhu7neswv4.wait_handle]: CREATE_IN_PROGRESS state changed 2024-04-19 18:12:08Z [stack_1-j190L.asg.fpe6jz2dccpg.instance1]: UPDATE_IN_PROGRESS state changed 2024-04-19 18:12:08Z [stack_1-j190L.asg.fpe6jz2dccpg.wait_condition]: UPDATE_IN_PROGRESS state changed 2024-04-19 18:12:08Z [stack_1-j190L.asg.fpe6jz2dccpg.wait_condition]: UPDATE_COMPLETE The Resource wait_condition requires replacement. 2024-04-19 18:12:08Z [stack_1-j190L.asg.fpe6jz2dccpg.wait_condition]: CREATE_IN_PROGRESS state changed 2024-04-19 18:12:08Z [stack_1-j190L.asg.o7dhu7neswv4.wait_handle]: CREATE_COMPLETE state changed 2024-04-19 18:12:09Z [stack_1-j190L.asg.o7dhu7neswv4.instance1]: UPDATE_IN_PROGRESS state changed 2024-04-19 18:12:09Z [stack_1-j190L.asg.o7dhu7neswv4.wait_condition]: UPDATE_IN_PROGRESS state changed 2024-04-19 18:12:09Z [stack_1-j190L.asg.o7dhu7neswv4.wait_condition]: UPDATE_COMPLETE The Resource wait_condition requires replacement. 2024-04-19 18:12:09Z [stack_1-j190L.asg.o7dhu7neswv4.wait_condition]: CREATE_IN_PROGRESS state changed 2024-04-19 18:12:11Z [stack_1-j190L.asg.4s52xugnxsrl.instance1]: UPDATE_COMPLETE The Resource Server "instance1" [27bbecab-bca3-48f0-9b1b-75d240d741a4] Stack "stack_1-j190L-asg-fmddtpch4ekg-4s52xugnxsrl-n56r3c5cxvwm" [8c4b9dcb-d4e3-4ff5-a442-c2b4f6302c38] requires replacement. 2024-04-19 18:12:11Z [stack_1-j190L.asg.4s52xugnxsrl.instance1]: CREATE_IN_PROGRESS state changed 2024-04-19 18:12:11Z [stack_1-j190L.asg.fpe6jz2dccpg.instance1]: UPDATE_COMPLETE The Resource Server "instance1" [58cffc7c-9278-43eb-bc36-fbbf9537a580] Stack "stack_1-j190L-asg-fmddtpch4ekg-fpe6jz2dccpg-7ipvlcpw237k" [1fd36182-6ac6-4f7b-aa3c-8ddaac1d933c] requires replacement. 2024-04-19 18:12:11Z [stack_1-j190L.asg.fpe6jz2dccpg.instance1]: CREATE_IN_PROGRESS state changed 2024-04-19 18:12:12Z [stack_1-j190L.asg.o7dhu7neswv4.instance1]: UPDATE_COMPLETE The Resource Server "instance1" [61dbda35-f20e-4018-85ad-66ba2e03c506] Stack "stack_1-j190L-asg-fmddtpch4ekg-o7dhu7neswv4-bqwgkjmslxkq" [c4b73bac-fdc8-4a78-8c18-1963054bc2fe] requires replacement. Regards, Devin

1 0

[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 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