November 2023 - openstack-discuss

[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

Kindly share the current roadmap for neutron
by habib ELalfy 07 Nov '23

07 Nov '23

Dears, Good day, Could you please add me to neutron mailing list and share with me the current roadmap for neutron, thanks. Best Regards, Habib

3 2

[nova] Nov 7 is a spec review day and Nov 14 is implementation review day
by Sylvain Bauza 06 Nov '23

06 Nov '23

Hey folks, I feel a bit sad to had no time yet to provide you a summary for our PTG, but please wait a bit more :-) That said, something you should already know, we will have two spec review days this cycle and two implementation review days as well, so please mark your calendars for the first to come : - Nov 7 will be a spec review day. Please ensure your specs are ready for reviews - Nov 14 will be an implementation review day. Mark your patches up ! As a reminder, the idea behind those review days is to synchronize our efforts between owners and reviewers so people can discuss at the same time. Thanks, -Sylvain

1 1

[tc] Next meeting of TC tomorrow, Tues Nov 7, 1800 UTC
by Jay Faulkner 06 Nov '23

06 Nov '23

Hi all, The next meeting of the TC is tomorrow, Tuesday November 7th at 1800 UTC. As it is our first meeting of the month, it will be held via a Zoom video call, with minutes kept in #openstack-tc on OFTC IRC. Use the following link to connect: https://us06web.zoom.us/j/87108541765?pwd=emlXVXg4QUxrUTlLNDZ2TTllWUM3Zz09 While it is TC practice to hold one video meeting a month to accommodate those who prefer that mode of communication, as always, all official TC decisions are made via commits to governance repositories. *Please note that for most US residents, this will be an hour earlier than it was before our DST switch.* The proposed agenda for the meeting is: - Roll call - Follow up on tracked action items: https://meetings.opendev.org/meetings/tc/2023/tc.2023-10-31-18.00.html - JayF: Before next video meeting, write up a short document on pros/cons of moving TC video meetings to jitsi-meet. - Gate health check - Leaderless projects (gmann) - Implementation of Unmaintained branch statuses - draft email to openstack-discuss while we figure this out: https://etherpad.opendev.org/p/early-caracal-unmaintained-transition - PTG follow-ups - https://etherpad.opendev.org/p/tc-ptg-october-2023 - https://etherpad.opendev.org/p/tc-leaders-interaction-2024-1 - https://etherpad.opendev.org/p/oct2023-ptg-os-dbperf-crossproject - Open Discussion and Reviews Thanks all, Jay Faulkner TC Chair

1 0

[kolla-ansible][Announcement] IMPORTANT! do not install from pypi!
by Sven Kieske 06 Nov '23

06 Nov '23

Hi there! I have seen many issues[0] over the past weeks because people still do "pip install kolla-ansible" or "pip install kolla- ansible==16.1.0". Please don't do that! We currently lack the workforce to do regular releases to pypi, but bugs get fixed in git, so you might miss important fixes! Please use the documented installation procedure[0], e.g. this: "pip install git+https://opendev.org/openstack/kolla-ansible@stable/2023.1" Thanks [0]: https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… [1]: https://docs.openstack.org/kolla-ansible/2023.1/user/quickstart.html#instal… -- Sven Kieske Senior Cloud Engineer Mail: kieske(a)osism.tech Web: https://osism.tech OSISM GmbH Teckstraße 62 / 70190 Stuttgart / Deutschland Geschäftsführer: Christian Berendt Unternehmenssitz: Stuttgart Amtsgericht: Stuttgart, HRB 756139

5 7

[publiccloud-sig] Reminder - next meeting November 08th - 0800 UTC
by Felix Kronlage-Dammers 06 Nov '23

06 Nov '23

Hi everyone, this Wednesday the next meeting of the public cloud sig is going to happen. We meet on IRC in #openstack-operators at 0800 UTC. A preliminary agenda can be found in the pad: https://etherpad.opendev.org/p/publiccloud-sig-meeting See also here for all other details: https://wiki.openstack.org/wiki/PublicCloudSIG I’ll be attending the SCS Hackathon in Dresden, so I’ll not be around but Tobias (tobberydberg) will be there and facilitate the meeting. Since we did have couple of good rounds at the vPTG (as well as a good discussion in the nova operators hour with some of us joining there) we should still send out a summary - I’ll see to get that out of to this list tomorrow. felix -- Felix Kronlage-Dammers Product Owner IaaS & Operations Sovereign Cloud Stack Sovereign Cloud Stack — standardized, built and operated by many Ein Projekt der Open Source Business Alliance - Bundesverband für digitale Souveränität e.V. Tel.: +49-30-206539-205 | Matrix: @fkronlage:matrix.org | fkr(a)osb-alliance.com

1 0

[neutron] bug deputy report of week 2023-10-30
by Bence Romsics 06 Nov '23

06 Nov '23

Hi Team, We only had a handful of new bug reports last week: Unassigned: * https://bugs.launchpad.net/neutron/+bug/2041861 [ovn] instance in a shared network owned by another project is unreachable via floating IP * https://bugs.launchpad.net/neutron/+bug/2042647 doc: Options described in "DHCP High-availability" are outdated Invalid: * https://bugs.launchpad.net/neutron/+bug/2042089 neutron : going to shared network is working, going back not * https://bugs.launchpad.net/neutron/+bug/2042598 neutron_server container suspended in health:starting state Cheers, Bence (rubasov)

1 0