- openstack-discuss - lists.openstack.org

[nova] what nova filter scheduler are you using?
by Satish Patel 13 Nov '23

13 Nov '23

Folks, Just curious about what schedulers people using in their cloud for better distribution or management of VMs? And why? In entire my life I never touch that config also go with default but just curious what people doing and how?

1 0

[kolla-ansible] Galera DR across multiple datacenters
by Jahns, Jay 13 Nov '23

13 Nov '23

We currently run OpenStack on top of two datacenters, and we need to ensure we have datacenter redundancy for the database. With this, we would have 2-3 nodes in each DC running galera. Its been recommended by multiple people that we use an externally managed database server (or cluster) that has its own redundancies built around the two DC layout, and not have kolla manage that. Is there a way we can use kolla to deploy a galera cluster per DC, and use that to provide redundancy in the event that we lose one of the DCs? We were currently looking at proxysql but folks have recommended against it. Thanks.

4 4

[neutron] Bug Deputy Report November 06 - 12
by Lucas Alvares Gomes 13 Nov '23

13 Nov '23

Hi, This is the Neutron bug report from November 6th to 12th. Quieter week than usual. High: * https://bugs.launchpad.net/neutron/+bug/2042938 - "[OVN] Neutron Service Restart Disrupts Octavia OVN Load Balancer Floating IP" Unassigned * https://bugs.launchpad.net/neutron/+bug/2042941 - "neutron-{ovn,ovs}-tempest-with-sqlalchemy-master jobs not installing sqlalchemy/alembic from source" Unassigned * https://bugs.launchpad.net/neutron/+bug/2043141 - " neutron-lib unit tests need update for sqlalchemy 2.0" Assigned to: Brian Haley Medium: * https://bugs.launchpad.net/neutron/+bug/2042925 - "DNS Integration throws expection logs entries were warnings would be sufficient" Assigned to: Jayce Houtman * https://bugs.launchpad.net/neutron/+bug/2042947 - "[stable branches] nftables job inherits from openvswitch-iptables_hybrid master job" Assigned to: Yatin Cheers, Lucas

1 0

[neutron][ovs][kolla-ansible] Does neutron-openvswitch-agent required for sriov only compute node
by Satish Patel 12 Nov '23

12 Nov '23

Folks, I have an openstack cloud just running SRIOV workload, We don't have a requirement to run standard vms on compute nodes. Currently I have noticed neutron-sriov-agent and openvswitch-agent running on all compute nodes. Technically in my case I don't have any use of openvswitch-agent so I am planning to get rid of those agents to reduce pressure on the neutron-server. Just wanted to check with export if that is ok to not run ovs agent. I hope neutron-server won't freak out.

2 2

[release] Release countdown for week R-20, Nov 13-17
by Elõd Illés 10 Nov '23

10 Nov '23

Development Focus ----------------- The Caracal-1 milestone is next week, on November 16th, 2023! Project team plans for the 2024.1 Caracal cycle should now be solidified. General Information ------------------- Libraries need to be released at least once per milestone period. Next week, the release team will propose releases for any library which had changes but has not been otherwise released since the 2023.2 Bobcat release. PTL's or release liaisons, please watch for these and give a +1 to acknowledge them. If there is some reason to hold off on a release, let us know that as well, by posting a -1. If we do not hear anything at all by the end of the week, we will assume things are OK to proceed. NB: If one of your libraries is still releasing 0.x versions, start thinking about when it will be appropriate to do a 1.0 version. The version number does signal the state, real or perceived, of the library, so we strongly encourage going to a full major version once things are in a good and usable state. Upcoming Deadlines & Dates -------------------------- Caracal-1 milestone: November 16th, 2023 Előd Illés irc: elodilles @ #openstack-release

1 0

[OpenstackAnsible][cinder][newtron][nova]
by Tecstim 10 Nov '23

10 Nov '23

Hi, I am testing to deploy a multi-node environment. I tried openstack-helm because I thought it was cool to have containers and virtual machines in the same environment, but it is not very stable and seems difficult to operate. Now I am testing with openstack ansible. I just deployed AIO in a VM. I want to achieve this: Use a physical interface for networks with vlans, and the gateway and dhcp are managed outside openstack. Use NetApp NFS as storage for persistent data of lxd containers of the openstack-ansible, images for VMs and deplyment and use this https://docs.openstack.org/cinder/2023.2/configuration/block-storage/driver… to create volumes for vms.

1 0

[neutron] CI meeting for next week is cancelled
by Yatin Karel 10 Nov '23

10 Nov '23

Hello Neutron Team !! Next Tuesday we have a Public Holiday so I will not be available to chair the meeting. So, the next Neutron CI Meeting will be on 21st November, 2023. Thanks and Regards Yatin Karel

1 0

[all] Failing sqlalchemy-tips jobs should now be passing again
by Stephen Finucane 10 Nov '23

10 Nov '23

Just FYI, for projects that have sqlalchemy-tips jobs that have been failing recently, they should now be passing again. The root cause was neither sqlalchemy nor alembic but rather oslo.utils [1]. It was fixed in oslo.utils 6.3.0 which was released [2] roughly an hour ago. A recheck should be sufficient to clear errors and as these tips jobs only run on master there should be no issues with stable branches. A further point to add: while I appreciate that broken gates are never a good thing, I would be careful making these jobs non-voting. I've already seen a few instances where SQLAlchemy 2.0 support has regressed and I for one have no desire to re-herd cats as we push to get SQLAlchemy uncapped in the coming weeks. If this happens again then we can re-examine things, naturally. Cheers, Stephen [1] https://review.opendev.org/c/openstack/oslo.utils/+/900343 [2] https://review.opendev.org/c/openstack/releases/+/900382

2 2

[kolla-ansible] group_vars question
by Satish Patel 09 Nov '23

09 Nov '23

Folks, I have multiple kinds of nic in cloud and want to configure SRIOV so instead of defining the following variable for each compute node, I would like to create a group and apply config to the groups. Am I right here to define groups like the following or is there a better way to handle this? What is the default path of group_vars and hosts_vars in kolla-ansible? # vi /etc/kolla/group_vars/sriov_eno49.yml neutron_sriov_physnet_mappings: physnet1: eno49 # vi /etc/kolla/group_vars/sriov_eno50.yml neutron_sriov_physnet_mappings: physnet1: eno50 # vi multinode [sriov_eno49] comp1 comp2 comp3 [sriov_eno50] comp4 comp5 comp6

2 2

[Diversity] Diversity and Inclusion WG November Meeting Change and New Time
by Amy Marrich 09 Nov '23

09 Nov '23

Due to travel next week we are bumping the D&I WG meeting to November 21st at our new winter time of 15:00 UTC. As always we welcome members of all the OpenInfra projects to join us to discuss diversity and WG related topics. Amy (spotz)

1 0

[kolla-ansible] Not to install openvswitch on sriov_agent compute nodes
by Satish Patel 09 Nov '23

09 Nov '23

Folks, I have pure sriov compute nodes where I don't want to deploy openvswitch because SRIOV agents do pass through PCI bugs to VM directly. Currently all my SRIOV compute nodes have two agents running. neutron_openvswitch_agent neutron_sriov_agent I don't think "neutron_openvswitch_agent" has any role on sriov compute nodes. If I want to tell kolla-ansible not to deploy neutron_openvswitch_agent on X compute node then how do I tell. Are there any easy ways to turn it off? ~S

1 0

hi
by Tecstim 09 Nov '23

09 Nov '23

1 0

[kolla-ansible] sriov setup
by Satish Patel 09 Nov '23

09 Nov '23

Folks, I am following this guide to deploy sriov compute with kolla-ansible (I am not using kayobe) - https://www.stackhpc.com/sriov-kayobe.html In the above doc last section neutron sriov agent, I am using the same code but those variables are not reflecting. It just prints everything as it is. # cat /etc/kolla/host_vars/os1-bos-sriov-comp-001.yml neutron_sriov_physnet_mappings: physnet1: eno49 # cat /etc/kayobe/kolla/config/neutron/sriov_agent.ini {% raw %} [sriov_nic] physical_device_mappings = {% for dev, physnet in sriov_physnet_mappings.items() %}{{ (loop.index0 > 0)|ternary(',','') }}{{ physnet }}:{{ dev }}{% endfor %} exclude_devices = {% endraw %} After running deploy it just prints the entire file as its in sriov_agent.ini file instead of proper values of variable. Does kolla-ansible support the above code?

2 2

[ptls] [tc] 2023 OpenStack Deployment Data
by Allison Price 09 Nov '23

09 Nov '23

Hi everyone, Apologies for sending this during the PTG as I intended to send this prior, but below is a link to the anonymized data including responses to many project or TC contributed questions. I have removed a significant number of fields to preserve the anonymity of the organizations, but if there is a particular data point that would help your team, please let me know. Cheers, Allison https://docs.google.com/spreadsheets/d/1ehlabuqOnNK4M7xtN1GXvhLoeHn4JBaISih…

2 1

[ironic] Hold approvals for various gate breakages
by Jay Faulkner 08 Nov '23

08 Nov '23

Hey Ironicers, We have a couple of gate unhappinesses: - bifrost gate is busted until this lands: https://review.opendev.org/c/openstack/bifrost/+/900487 - Ironic gate is busted until the new oslo.utils is released and added to requirements (we vote on a sqlalchemy 2x job) -- https://review.opendev.org/c/openstack/releases/+/900382 appears to be the next change in that chain. Just ensuring folks know what's going on! Please avoid approving changes to these repos until the issues are resolved. Thanks, Jay Faulkner Ironic PTL

1 0

[ironic] 2024.1 vPTG Notes & Work Items
by Jay Faulkner 08 Nov '23

08 Nov '23

Hi all, In typical Ironic tradition, we've documented the outcome of the PTG in a spec: https://specs.openstack.org/openstack/ironic-specs/priorities/2024-1-workit… -- please review it for information on work we plan on at least trying to start this cycle :). For full notes, please see the etherpad: https://etherpad.opendev.org/p/ironic-ptg-october-2023. Thanks, Jay Faulkner Ironic PTL

1 0

[FOSDEM] Call for participation: Virtualization and Cloud infrastructure Room at FOSDEM 2024
by Piotr Kliczewski 08 Nov '23

08 Nov '23

We are excited to announce that the call for proposals is now open for the Virtualization and Cloud infrastructure devroom at the upcoming FOSDEM 2024, to be hosted on February 3rd 2024. This devroom is a collaborative effort, and is organized by dedicated folks from projects such as OpenStack, Xen Project, KubeVirt, QEMU, KVM, and Foreman. We would like to invite all those who are involved in these fields to submit your proposals by December 8th, 2023. About the Devroom The Virtualization & IaaS devroom will feature session topics such as open source hypervisors or virtual machine managers such as Xen Project, KVM, bhyve and VirtualBox as well as Infrastructure-as-a-Service projects such as KubeVirt, Apache CloudStack, OpenStack, QEMU and OpenNebula. This devroom will host presentations that focus on topics of shared interest, such as KVM; libvirt; shared storage; virtualized networking; cloud security; clustering and high availability; interfacing with multiple hypervisors; hyperconverged deployments; and scaling across hundreds or thousands of servers. Presentations in this devroom will be aimed at developers working on these platforms who are looking to collaborate and improve shared infrastructure or solve common problems. We seek topics that encourage dialog between projects and continued work post-FOSDEM. Important Dates Submission deadline: 8th December 2023 Acceptance notifications: 10th December 2023 Final schedule announcement: 15th December 2023 Devroom: 3rd February 2024 Submit Your Proposal All submissions must be made via the Pretalx event planning site[1]. It is a new submission system so you will need to create an account. If you submitted proposals for FOSDEM in previous years, you won’t be able to use your existing account. During submission please make sure to select Virtualization and Cloud infrastructure from the Track list. Please fill out all the required fields, and provide a meaningful abstract and description of your proposed session. Submission Guidelines We expect more proposals than we can possibly accept, so it is vitally important that you submit your proposal on or before the deadline. Late submissions are unlikely to be considered. All presentation slots are 30 minutes, with 20 minutes planned for presentations, and 10 minutes for Q&A. All presentations will be recorded and made available under Creative Commons licenses. In the Submission notes field, please indicate that you agree that your presentation will be licensed under the CC-By-SA-4.0 or CC-By-4.0 license and that you agree to have your presentation recorded. For example: "If my presentation is accepted for FOSDEM, I hereby agree to license all recordings, slides, and other associated materials under the Creative Commons Attribution Share-Alike 4.0 International License. Sincerely, <NAME>." In the Submission notes field, please also confirm that if your talk is accepted, you will be able to attend FOSDEM and deliver your presentation. We will not consider proposals from prospective speakers who are unsure whether they will be able to secure funds for travel and lodging to attend FOSDEM. (Sadly, we are not able to offer travel funding for prospective speakers.) Code of Conduct Following the release of the updated code of conduct for FOSDEM, we'd like to remind all speakers and attendees that all of the presentations and discussions in our devroom are held under the guidelines set in the CoC and we expect attendees, speakers, and volunteers to follow the CoC at all times. If you submit a proposal and it is accepted, you will be required to confirm that you accept the FOSDEM CoC. If you have any questions about the CoC or wish to have one of the devroom organizers review your presentation slides or any other content for CoC compliance, please email us and we will do our best to assist you. Questions? If you have any questions about this devroom, please send your questions to our devroom mailing list. You can also subscribe to the list to receive updates about important dates, session announcements, and to connect with other attendees. See you all at FOSDEM! [1] <https://penta.fosdem.org/submission/FOSDEM17> https://pretalx.fosdem.org/fosdem-2024/cfp [2] virtualization-devroom-manager at fosdem.org

1 0

The difference between kolla-ansible deploy and kolla-ansible upgrade
by bryansoong21＠gmail.com 08 Nov '23

08 Nov '23

Hello team, I have noticed this for the kolla operation documentation: https://docs.openstack.org/kolla-ansible/zed/user/operating-kolla.html This procedure is for upgrading from series to series, not for doing updates within a series. Inside a series, it is usually sufficient to just update the kolla-ansible package, rebuild (if needed) and pull the images, and run kolla-ansible deploy again. Please follow release notes to check if there are any issues to be aware of. We have two different kolla images and the OpenStack version are all Zed, while one container base image si Rocky 9.2 and another is CentOS 9. Based on kolla documentation, we should use kolla-ansible deploy if we want to switch different kolla images. We also tried to run kolla-ansible upgrade and all VMs have been stopped, just wondering what's the difference when running these two commands and why the upgrade shutdown all the VMs? Thanks

1 0

[ironic][nova] A few notes about the Ironic<>Nova driver
by Jay Faulkner 08 Nov '23

08 Nov '23

Hey all, Julia Kreger, John Garbutt, and myself met today in a trio-coding session to review the Ironic virt driver in Nova, as a follow-up to some of the concerns we developed when sharding support was reverted in Bobcat. I wanted to ensure both communities knew about what we discussed. Notes were taken in the Ironic PTG etherpad starting at line 654. *Fix a Bug in list_instances/list_instance_uuids* We found a bug around list_instances and list_instance_uuids in the Ironic driver, and tracked that its main impact was performance. The bug has been documented in https://bugs.launchpad.net/nova/+bug/2043036 and we will work to ensure it's resolved this cycle. *Completing the Partially completed ironicclient -> SDK migration* The Ironic virt driver in Nova began migrating to openstacksdk, but this migration was not completed. This left the driver in a strange, in-between state which made it much easier to misunderstand microversion interactions. Even more unfortunately, we even have places where we're checking the available microversion using ironicclient, then making the actual call with openstacksdk (which may negotiate another microversion altogether). Completing this migration will be a priority; and we will attempt to complete it, barring unforeseen technical issues, before re-proposing the sharding changes. *Sharding re-proposal and testing* For sharding's re-proposal in Caracal, we discussed some details around validation and testing. Primarily, we want to ensure Ironic's sharding API has tempest test coverage, and that we have more complex testing coverage around the integrated Nova/Ironic sharding case, for when it's reproposed. As sharding will be the primary scaling method for integrated Ironic<>Nova users, it's important it's exercised well in our CI. *Pass more metadata to Ironic at provisioning* Ironic implemented several features around RBAC recently, but those have not been available for users of Nova-integrated Ironic installations. We want to change that. John proposed a blueprint, https://blueprints.launchpad.net/nova/+spec/ironic-guest-metadata , which we hope to be approved as specless, which would make the metadata set in Ironic's instance_info more consistent with what is set on a libvirt guest. With that metadata, Ironic developers could make the "automatic_lessee" feature work with Nova and unlock RBAC-goodness for users of fully integrated Ironic<>Nova clouds and Ironic deployers have a new tool they can use to troubleshoot failures using instance_info from Ironic's API. Thanks for reading. This is just a summary of our discussion and links to some artifacts from it; obviously none of this is going to happen until the blueprints are approved, code is written and lands -- but we thought the community might appreciate hearing about what we're thinking about ahead of time. Thanks, Jay Faulkner Ironic PTL

1 1

Cinder Bug Report 2023-11-08
by Jon Bernard 08 Nov '23

08 Nov '23

Hello Argonauts, Cinder Bug Meeting Etherpad <https://etherpad.opendev.org/p/cinder-bug-squad-meeting> Undecided - NetApp doesn't update the backend LUN name during generic migration <https://bugs.launchpad.net/cinder/+bug/2042662> - Status: New Thanks, -- Jon

1 0

[tc][ptg] 2024.1 PTG Recap: TC Sessions
by Jay Faulkner 08 Nov '23

08 Nov '23

Hi all, The OpenStack Technical Committee met for two three hour sessions during the vPTG, covering a handful of topics. This email serves as an extremely high level recap of those topics. If you want full information on the discussions, please review the full etherpad notes[0]. The TC will be tracking long-term projects, related to these discussion items and otherwise, in the 2024.1 TC Tracker[1]. As always; no official TC policy changes can be made via a meeting. PTGs and other synchronous meetings are useful for rapidly gaining context and consensus, which then must be reflected in a resolution and merged when that consensus results in a policy change. *Leaderless Projects[2]* The TC discussed the multiple projects who did not have a PTL elected, and the various reasons that could cause that. A few interesting items were discussed which may need future action by the TC. First, concerns were raised over the ec2-api PTL candidate not being an Active Contributor in title, despite showing stewardship over a relatively "complete" project. This is an example of how our process of identifying active contributors can be flawed. A workaround in the interim of a PTL in this situation nominating themselves as an extra-AC was identified. Secondly, the recurring issue of smaller projects missing elections, and generally being less active, was a topic of discussion. The TC decided that as a regular course of action, any project that did not successfully participate in electing a PTL would also have the activity of its project reviewed as part of the PTL appointment process -- with a default towards marking such projects inactive[3] unless they have clear signs of activity. *Follow-ups from 2023.2 TC Tracker[4]* There are some ongoing items which the TC has continued to work on cross cycle. Their status was evaluated and discussed; items which needed additional tracking were pulled forward to 2024.1. *Managing Divergence between documented runtime and reality* This was a session originally inspired by a mailing list post from Herve[5] about how the listed versions of some libraries on the releases page for bobcat[6] were not the versions compatible with bobcat. After significant discussion, it became apparent that there was confusion and lack of communication around a change that was not intended to merge yet, and did anyway, breaking project compatibility which had not yet done the SQLAlchemy 2.0 migration. The TC agreed that proposing a new step in the release schedule where we integrate and test libraries with projects before cutting library releases is a potential solution to this problem. *More predictable python minimum supported version* Currently, our documentation indicates we drop support when there is "a solid reason", but recent mailing list discussions[7] make it clear that is not a clear line. After significant discussion, the consensus was that unit testing the minimum supported version of python does very little harm but provides a benefit. While it was desired to have a general pattern we could follow, the realities of testing on LTS platforms make it so that we should continue to look at python version support on a case-by-case basis, comparing support lifecycles in python upstream, our current tested LTS, and the OpenStack release in question. Similarly for new python versions, selecting what new ones to support is a technical concern rooted in library, distro, and ecosystem support moreso than what we'd desire OpenStack to support. *Communication* Communication to/from the TC was raised as a topic due to a misunderstanding around language used around a TC action decided on in a meeting. For OpenStack community members who don't frequent TC meetings, or interact with the TC process often, it can be confusing, but we should always be clear: binding decisions are not made in synchronous meetings. Other items discussed around this communication topic included how more virtual communication methods, such as vPTG, may be limiting our cross-project communication and ability to reach larger groups. *Election Retrospective* This topic also covers many items covered in the communication topic; but essentially, many projects have missed elections -- the TC wants to find a root cause and address it if possible. During the discussions, it became clear there was a significant cultural disconnect. Many pieces of documentation needed for OpenStack leaders -- including election reminder emails, governance docs, and this summary(!) -- are only available in English. Additionally, there is a concern that there are cultural conflicts that extend past language. One set of solutions discussed were alternative PTL models, such as DPL. Some attendees indicated a dislike of the DPL model due to it potentially masking inactivity issues by removing the periodic check-in inherent to the elections process. An idea of electing a PTL for multiple cycles was raised as well, but did not gain wide consensus. Additionally, we discussed how to get new leaders onboarded. A suggestion was made for the TC to send an incoming PTL email, with information and expectations for incoming PTLs. This is a process that traditionally has been handled well, albeit ad-hoc, in larger projects, but is often missed in smaller projects, especially if there is no handoff from one PTL to another. Finally, there was a discussion about the size of our electorate being artificially small. Despite having 580 contributors in bobcat, OpenStack TC only had 309 eligible voters (AC+Foundation Member), and of those 309, only 91 people had opted-in to receive a ballot. Some suggestions were to revise our definition of who is eligible to vote in elections to include OIF non-members, but still require PTLs or TC candidates to be OIF members. *Shadowing Program* There was some discussion as well about the OpenInfra Diversity working group[8] piloting a shadowing program. Many TC members indicated a willingness to be shadowed, but a lack of people willing to take on leadership roles. (Along these lines; if you're reading this and want to shadow someone; ask!) There were suggestions that perhaps the prestige of being a TC member or PTL has gone down, making it difficult to take on those responsibilities or justify them to management. We discussed several ways to try and re-engage people into leadership and contribution with OpenStack. *Footnotes:* 0: https://etherpad.opendev.org/p/tc-ptg-october-2023 1: https://etherpad.opendev.org/p/tc-2024.1-tracker 2: https://etherpad.opendev.org/p/2024.1-leaderless 3: https://governance.openstack.org/tc/reference/emerging-technology-and-inact… 4: https://etherpad.opendev.org/p/tc-2023.2-tracker 5: https://lists.openstack.org/pipermail/openstack-discuss/2023-September/0351… 6: https://releases.openstack.org/bobcat/index.html 7: https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… 8: https://etherpad.opendev.org/p/diversity-leadership If you made it this far; thanks! -- Jay Faulkner OpenStack TC Chair

1 0

[Glance] Cancelling Weekly Meeting -9th Nov
by Pranali Deore 08 Nov '23

08 Nov '23

Hello All, Cancelling tomorrow's weekly meeting as most of the team members will not be around for the meeting. Thanks, Pranali Deore

1 0

[publiccloud-sig][ptg] 2024.1 Caracal vPTG summary
by Felix Kronlage-Dammers 07 Nov '23

07 Nov '23

Hi, my attempt at giving an overview of what we discussed in the publiccloud-sig vPTG meeting. We’ve met once on Tuesday for couple hours and used the regular Wednesday slot for a re-cap of the discussion on the day before as well as what we’ve learned in the nova operator hour - but more on that further down below. We've set out to discuss the following topics: - Standard set of properties - way forward - Domain admin support - Alignment of activities of Public Cloud SIG The etherpad for the 2024.1 vPTG is here: https://etherpad.opendev.org/p/oct2023-ptg-publiccloud-sig # Standard Set of properties We've discussed how we (PublicCloud-SIG) think the way forward should look like and aligned ourselves that we need to write the proper specs for nova and glance. As part of the discussion, aside from the SCS (Sovereign Cloud Stack) initiative on standardizing items here, we were made aware of the efforts within gaia-x to standardize properties here[1][2]. With that in mind we (gtema and fkr) joined the nova-operator hour (which was directly after the PublicCloud-SIG meeting)[3]. The outcome of the nova operator hour was then something completely different. It was agreed[3] that we look at the metadefs and possibly also look into a new nova api that gives back flavors based on standard traits and resources (min/max)[4]. # Domain admin support For the domain admin support there is currently quite a bit of activity from the SCS Side of things[5]. From those efforts also items like [6] are coming. # Alignment of activites of Public Cloud SIG From the discussion in the PublicCloud SIG it became apparent to us that with the touch points that the PublicCloud SIG has it is to us to 'represent' the stakeholders of PublicCloud-functionality towards the development efforts of OpenStack projects. Driving this thought further, we (Public Cloud SIG) should become more active and see wether we can fulfil the role of a ProductOwner towards the OpenStack projects to work towards an better alignment between them in order to provide an overall better experience for entities operating public clouds with OpenStack. We will ask OpenInfra wether they can provide us a list of contacts of people at entities that operate public clouds with OpenStack or wether they could mail them for us in order to foster more involvement in the publiccloud SIG meetings. Thanks to everyone who participates as well as the people from the nova operator hour for the insights. felix [1] <url: https://github.com/SovereignCloudStack/gx-self-description-generator/issues…> [2] <url: https://gitlab.com/gaia-x/technical-committee/service-characteristics/-/blo…> [3] <url: https://etherpad.opendev.org/p/oct2023-ptg-operator-hour-nova#L106> [4] <url: https://etherpad.opendev.org/p/oct2023-ptg-operator-hour-nova#L120> [5] <url: https://github.com/SovereignCloudStack/standards/blob/main/Standards/scs-03…> [6] <url: https://bugs.launchpad.net/keystone/+bug/2041611>

1 0

[docs] Encourage search engines to show newest version of OpenStack docs first
by Jake Yip 07 Nov '23

07 Nov '23

Hi all, I am not sure if this is encountered by others, but often when I search for something regarding OpenStack, the first few results are of older versions. For example, my last search was "keystone config service_token_roles_required", which returns a Pike[1] URL as first result. For older versions, the documentation does have a header which is something like "This release is no longer supported by the community. The current supported release is 2023.2." It links to new documentation[2], but drops me to the docs root instead of the new version of this page and usually is not useful for me. (I understand it is not possible to drop at the same page as documentation moves around). I often try to change the version in the URL to 'latest' which works sometimes. I wonder if we can help to fix this? Looking at other people with this issue[3], a few strategies seems to have help. (Disclaimer: I am not a SEO expert). 1. Prevent Google from indexing the older versions by using `noindex`[4] 2. Removing old documentation so it is flushed from Google Regards, Jake [1] https://docs.openstack.org/keystone/pike/admin/identity-auth-token-middlewa… [2] https://docs.openstack.org/2023.2/ [3] https://github.com/crossplane/docs/issues/107 [4] https://developers.google.com/search/docs/crawling-indexing/block-indexing -- Jake Yip Technical Lead, Nectar Research Cloud

4 4

[Telemetry][Requirements][TC] When did we stop caring about backwards compatibility
by Erno Kuvaja 07 Nov '23

07 Nov '23

Hi all, I'd like to bring the conversation to a wider audience as the current state is really not sustainable. Since I've got involved with Telemetry project early this year, I honestly think our gates have been blocked more than not and most of that has been due to requirements bumps where the dependencies break backwards compatibility and that is not obvious, like major version bump (pyparsing being the current example [0] [1]), or are just not tested before bumped (like the recent Sphinx/WSME episode [2]). While I do recognize Dr. Harbott's concerns around gnocchi [1] I'd like to point out that a) it's still currently our only supported time series database for metrics and b) providing alternative solution has not been an exactly smooth road either [3]. Unfortunately gnocchi is still very tightly coupled in our Telemetry testing (something I'm working on) and not having an operational gate makes it very difficult to even work on those tests across the Aodh and Telemetry-tempest-plugin repos. We have been capping and blacklisting broken dependencies for years, so I'd like to hear what has changed recently so that we do not care anymore but prefer "the latest" over the "latest working". In my understanding the upper constraints was supposed to be "the latest dependencies you can stand up a functional and working cloud with" not "the latest dependencies existing regardless of what they break". Back to Dr. Harbott's remarks of gnocchi being an acceptable requirement [1], without a working gate we cannot even deprecate it. And yet we would need an appropriate deprecation period before removing it. Should we be forced to rip out our only TS database (gnocchi) to be able to focus on developing support for the alternative (Prometheus) I would really like to see TC resolution for this so we can point the impacted users to it, avoiding all the blame falling to the Telemetry project team. I would also like to see the Telemetry job being in the Requirements gate so we get warnings when something is about to break, rather than a jammed gate because of an upper constraints bump. Thanks, Erno "jokke" Kuvaja [0] https://github.com/pyparsing/pyparsing/issues/504 [1] https://review.opendev.org/c/openstack/requirements/+/898699 [2] https://review.opendev.org/c/openstack/requirements/+/896018 [3] https://review.opendev.org/c/openstack/requirements/+/891291

4 4