- openstack-discuss - lists.openstack.org

Re: [openstack]Share about OSS which used for my Openstack
by Nguyễn Hữu Khôi 30 Jun '25

30 Jun '25

Hello, My Openstack system is on bare metal nodes. Nguyen Huu Khoi On Mon, Jun 30, 2025 at 9:01 PM Winicius Allan <winiciusab12(a)gmail.com> wrote: > So do you have a controller baremetal that you create virtual machines on > top of it to use as controller nodes? > > Regards. > > On Mon, Jun 30, 2025, 10:40 Nguyễn Hữu Khôi <nguyenhuukhoinw(a)gmail.com> > wrote: > >> Hello, >> >> I would like to share some open-source software (OSS) that I used for my >> OpenStack environment. >> >> >> https://github.com/nguyenhuukhoi/openstack-note/blob/main/Cloud%20System%20… >> >> >> I hope this will be helpful for you, especially those who are getting >> started with OpenStack. >> Nguyen Huu Khoi >> >

1 0

[oslo][mistral][keystone] broken library gate
by Elõd Illés 30 Jun '25

30 Jun '25

Hi teams in $SUBJECT, The release team usually checks the gate health of libraries which did not have merged patches recently and it seems you have a project with broken gate: oslo.utils: https://review.opendev.org/c/openstack/oslo.utils/+/952914 python-mistralclient: https://review.opendev.org/c/openstack/python-mistralclient/+/952927 python-keystoneclient: https://review.opendev.org/c/openstack/python-keystoneclient/+/952923 Could you please check and fix the gate so that we don't release 2025.2 Flamingo with a broken state. Thanks in advance, Előd Illés irc: elodilles @ #openstack-release

3 2

[keystone][horizon] OPENSTACK_KEYSTONE_DOMAIN_DROPDOWN security impact
by Pierre Riteau 30 Jun '25

30 Jun '25

Hello, The documentation for the OPENSTACK_KEYSTONE_DOMAIN_DROPDOWN option in Horizon [1] has this warning: > It is strongly advised NOT to enable this for public clouds, as advertising enabled domains to unauthenticated customers irresponsibly exposes private information. This should only be used for private clouds where the dashboard sits behind a corporate firewall. In a context where this option enables one or multiple domains that would be publicly documented anyway, is there really any issue with using this option on a publicly-accessible Horizon deployment? Thanks, Pierre Riteau (priteau) [1] https://docs.openstack.org/horizon/latest/configuration/settings.html#opens…

1 0

"tag" API in OpenStack, case sensitive
by Rodolfo Alonso Hernandez 30 Jun '25

30 Jun '25

Hello all: I initially found this issue in Neutron [1] but it seems to be more of an OpenStack wide problem. In Neutron, when you try to create a tag with different case (upper, lower), the API fails: $ openstack port create --network private port_tags $ openstack port set --tag tag1 port_tags $ openstack port set --tag TAG1 port_tags # this command will fail with the following message: ConflictException: 409: Client Error for url: http://192.168.10.100/networking/v2.0/ports/21788aea-98b7-4606-bcf4-5f963ce…, Failed to create a duplicate Tag: for attribute(s) ['tags.PRIMARY'] with value(s) 47-TAG1 That happens because in Neutron we don't sanitize the input "tags" and we consider that "tag1" is different to "Tag1", as recommended by [2]: "Tags are case sensitive". But checking the table definitions in OpenStack (for example [3][4][5]), all projects seem to have the same problem: we define the tuple (resource, tag) as the primary key. But if we use a case insensitive table collation (for example "utf8_general_ci" or "utf8mb3_general_ci"), the comparison between "tag1" and "TAG1" will match. In the Neutron API, because we don't consider this scenario, the API raises the mentioned exception. In Nova, for example, the command succeeds but the new tag is not added. So the question here is: * Do we change the API definition to make it case insensitive? That will need, most probably, to revisit all stored tags and convert them to lower case. It will also require sanitizing the API input and making all tags lower case. * Do we enforce a charset and collation case sensitive for these specific tables? Regards. [1]https://bugs.launchpad.net/neutron/+bug/2114819 [2] https://specs.openstack.org/openstack/api-wg/guidelines/tags.html#tags-rest… [3] https://github.com/openstack/neutron/blob/39b183645e071f9c2926f0bd870723fb6… [4] https://github.com/openstack/nova/blob/64ca204c9cf497b0dcfff2d3a24b0dd795a5… [5] https://github.com/openstack/octavia/blob/2fb6ba9343e39f60f058a781afd14b906…

2 1

nova-ovs-hybrid-plug CI jobs failing for Nova
by Michael Still 30 Jun '25

30 Jun '25

Hi, over the weekend it appears that nova-ovs-hybrid-plug CI jobs have been failing for Nova, I think because of this error: "Failed to contact the endpoint at https://200.225.47.11/image for discovery. Fallback to using that endpoint as the base url." https://zuul.opendev.org/t/openstack/build/fcc678f62f584bbb9726821f5992ae90 is an example of such a failure. The CI job then executes: openstack --os-compute-api-version 2.74 server create --image --flavor --nic net-id= --host np0041269081 --wait evacuate-test Which is invalid because it doesn't have an argument to the --image flag. I am unsure who owns 200.225.47.11. Is it possible its offline? Thanks, Michael

3 3

[neutron] Bug deputy report for week 26 of 2025 (June 23th)
by Lajos Katona 30 Jun '25

30 Jun '25

Hi Neutrinos! Last week (week 26, from 23 june) I was the Neutron bug deputy, please check the report for that week. * *Unassigned*: ** https://bugs.launchpad.net/neutron/+bug/2115411 ([ovn-octavia-provider] Exception observe when there no IP available for VIP ): TL;DR: shall we throw http500 or 409 when there's no available IP. ** https://bugs.launchpad.net/neutron/+bug/2115241 (test_spawn_rate_limited_metadata_proxy unit test fails randomly ) ** High Bugs* ** https://bugs.launchpad.net/neutron/+bug/2115327 ([fullstack] Migrate the fullstack tests to other FWs ) ** Medium Bugs* ** https://bugs.launchpad.net/neutron/+bug/2115184 ([S-RBAC] Custom role can't get resources which belongs to different projects ) Owner: Slaweq ** https://bugs.launchpad.net/neutron/+bug/2115189 ( [OVN] ``sync_port_qos_policies`` and ``sync_fip_qos_policies`` only have "repair" mode), owner: Rodolfo, https://review.opendev.org/c/openstack/neutron/+/953081 ** https://bugs.launchpad.net/neutron/+bug/2115242 ([FT] Random errors in ``test_floatingip_mac_bindings``), owner: Rodolfo, https://review.opendev.org/q/Ia153b48aaec72e6a073b313ef2aea8efac6dbbae ** https://bugs.launchpad.net/neutron/+bug/2115510 ([neutron][os-ken] Bug on the BGP loop prevention), assigned: Anas Jouhdy, https://review.opendev.org/c/openstack/os-ken/+/953631 Best wishes, Lajos Katona (lajoskatona)

1 0

[tc][all] OpenStack Technical Committee Weekly Summary and Meeting Agenda (2025.2/R-13)
by Goutham Pacha Ravi 30 Jun '25

30 Jun '25

Hello Stackers, We're thirteen weeks away from the coordinated release of OpenStack 2025.2 "Flamingo" [1]. This Thursday marks Milestone-2 of the release cycle. This is a bug-targeting milestone for OpenStack project teams, as well as a checkpoint for the OpenStack Release Management team to line up deliverables that will be part of the coordinated release at the end of this development cycle. Currently, the number of deliverables to be released has only changed slightly from the OpenStack 2025.1 release. No significant deliverables have been deprecated or removed. In the past week, the OpenStack Technical Committee did not make any new governance changes; however, several proposals are under the community's review. Most significantly, today (2025-06-30) marks the end of the OpenStack Contributor License Agreement (CLA). The CLA was adopted in July 2010 (do you feel old yet?) [2], and thousands of contributors have signed it. However, for over a decade, we've felt encumbered by how it was arcane, perceived to be more permissive than Apache v2 and caused friction with individuals and organizations. We believe it has limited contributor involvement. Today, we join several other open source projects in requiring the "Developer Certificate of Origin" as a way to sign off your contributions. As we close the lid on the CLA regime, you'll need to "git commit -s" each of your contributions from 2025-07-01 to adhere to the DCO [3][4]. We do anticipate hiccups and request your cooperation in ironing out any issues in the code review system and contributor tooling during this transition. If you notice something broken, please chime in on this mailing list or on OFTC's #opendev channel. === Weekly Meeting === The last weekly meeting of the OpenStack Technical Committee was held on 2025-06-24 [5]. The meeting was well attended and covered several topics. The proposal to mark the Cyborg project as inactive [6] was withdrawn after critical CI fixes were merged. While activity has resumed for this cycle, there are concerns about the project’s long-term maintenance, particularly in light of future OpenStack-wide changes like eventlet removal and dependency updates. It was opined that Cyborg is not "feature complete" and must stay responsive to ongoing ecosystem changes, even if its core functionality appears stable. The upcoming cycle's elections will serve as a checkpoint to reassess the project’s trajectory and whether new maintainers need onboarding. We then discussed the timeline of the ongoing effort to phase out eventlet. A new governance patch [7] proposes a timeline that aligns with operator and distro expectations, especially in light of Python 3.13 adoption. Python 3.12 will continue to be a fallback for some time, but when supporting Python 3.13, we hope not to depend on eventlet across the board. The TC emphasized that continued discussion on the Gerrit change is necessary to finalize acceptable timelines. The next major topic concerned setuptools changes that will impact PBR (Python Build Reasonableness). Setuptools will remove "ScriptWriter" and "pkg_resources" by October 31, 2025. These removals break current functionality in PBR and could jeopardize CI and release workflows. A critical bug was reported against PBR by maintainers of setuptools [8]. The TC discussed options ranging from vendoring replacements to rewriting PBR logic or adopting upstream tools despite performance tradeoffs. A key concern is that PBR’s CI is currently broken and must be fixed before any meaningful changes can be implemented. We'd like to seek a volunteer to resolve this issue. Please chime in on OFTC's #openstack-tc or #openstack-oslo if you're keen to help with this. In closing, we discussed the OpenInfra Summit 2025 CFP for Forum Sessions and Project Updates. CFP submissions must be made before 23:45 PST on 2025-07-08 [9]. The next meeting of the OpenStack Technical Committee will be held on 2025-07-01 at 1700 UTC. This meeting will be hosted simultaneously over Meetpad and IRC. You're welcome to join whichever platform you prefer. The Meetpad session will be recorded, and the recording will be shared on the TC's YouTube channel [10]. Please find the agenda and joining information on the meeting's wiki page [11]. I hope you'll be able to join us there. === Governance Proposals === ==== Open for review ==== - Add service-types-authority to SDK deliverables | https://review.opendev.org/c/openstack/governance/+/953548 - Deprecate shade, os-client-config | https://review.opendev.org/c/openstack/governance/+/953549 - Remove Monasca from active project | https://review.opendev.org/c/openstack/governance/+/953671 - Make Eventlet removal deadlines more acceptable for operators | https://review.opendev.org/c/openstack/governance/+/952903 - Require declaration of affiliation from TC Candidates | https://review.opendev.org/c/openstack/governance/+/949432 === Upcoming Events === - 2025-07-03: OpenStack's 15th Birthday, Colombia User Group: https://www.meetup.com/colombia-openinfra-user-group/events/308383244 - 2025-07-08: OpenInfra Board meeting: https://board.openinfra.org/ - 2025-07-19: OpenInfra Days, Indonesia: https://2025.openinfra.id/ Thank you very much for reading! On behalf of the OpenStack TC, Goutham Pacha Ravi (gouthamr) OpenStack TC Chair [1] 2025.2 "Flamingo" Release Schedule: https://releases.openstack.org/flamingo/schedule.html [2] OpenStack and its CLA: https://wiki.openstack.org/wiki/OpenStackAndItsCLA [3] OpenStack will replace CLA with DCO: https://governance.openstack.org/tc/resolutions/20250520-replace-the-cla-wi… [4] OpenStack Contributor Guide to DCO: https://docs.openstack.org/contributors/common/dco.html [5] TC Meeting IRC Log 2025-06-24: https://meetings.opendev.org/meetings/tc/2025/tc.2025-06-24-17.00.html [6] Cyborg will not be marked inactive: https://review.opendev.org/c/openstack/governance/+/952798 [7] Timeline changes for the Eventlet Removal goal: https://review.opendev.org/c/openstack/governance/+/952903 [8] PBR setuptools incompatibility: https://bugs.launchpad.net/pbr/+bug/2107732 [9] CFP for OpenInfra Summit 2025: https://summit2025.openinfra.org/cfp/ [10] OpenStack TC YouTube Channel: https://www.youtube.com/@openstack-tc [11] TC Meeting Agenda, 2025-07-01: https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting

1 0

[ops][largescale-sig][scientific-sig] Ops Radio Hour on June 27, 2025
by Ildiko Vancsa 29 Jun '25

29 Jun '25

Hi OpenStack community, I'm reaching out to you with a friendly reminder that the next OpenStack Ops Radio Hour[1] is scheduled to happen on __June 27th, 2025 at 1300UTC.__ The call series is a casual setting for operators, engineers, and contributors to come together, share knowledge, and collaborate on the complexities of managing and deploying OpenStack environments. Topics the next gathering will dive into: - Networking: switches and transitioning to OVN - RabbitMQ upgrade - OpenInfra Summit Forum session planning What other topics should we add to the agenda? A few reminders: - The group on the call agreed to try out Matrix as a chat platform for more synchronous communication outside calls + You can access the Matrix room here: https://matrix.to/#/#openstack-ops:opendev.org + Further details are here: https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… - If you would like to read and catch up on notes from previous calls, you can find them in this etherpad: https://etherpad.opendev.org/p/openstack_ops_radiohour See you on the call on June 27th! Bets Regards, Ildikó [1] https://wiki.openstack.org/wiki/Operations/Meetups

1 2

[keystone] Status of External OAuth2 grant support
by Waines, Greg 29 Jun '25

29 Jun '25

What is the status and forecast of the work on this 'approved' spec ? https://specs.openstack.org/openstack/keystone-specs/specs/keystonemiddlewa… Greg.

1 0

Floating IP randomly becomes unreachable from external network (OSA AIO 30.0.2, Ubuntu 24.04)
by christophel＠silival.com 28 Jun '25

28 Jun '25

Hello, I’m currently running an OpenStack-Ansible All-In-One deployment (version 30.0.2) on Ubuntu 24.04. The environment hosts several virtual machines across multiple tenant networks. Each VM is assigned a floating IP from a public 172.x.x.x range, which allows access from the controller host and external clients. The issue From time to time, a VM becomes unreachable via its floating IP. The instance is still: Running normally. Reachable from other VMs on the same internal tenant network using its private IP (10.x.x.x). Associated with the same security groups and port configuration as before. This happens without any apparent trigger or configuration change. I can still ping and SSH to other VMs’ floating IPs, so the problem is isolated to one instance at a time. Workaround The only way I’ve found to restore external access is: Disassociate and delete the current floating IP. Allocate a new floating IP from the same pool. Associate it to the same VM port. Once the new floating IP is set, the VM becomes immediately reachable again. This has now occurred several times across different VMs. I’m concerned it will keep happening randomly. Question Has anyone encountered similar behavior with floating IPs in an OpenStack-Ansible AIO setup? Is there a known root cause, or any specific logs or areas I should investigate? If this mailing list is not the right place for this type of question, I’d also appreciate guidance on where to report it or who to contact. Thanks in advance for your help, Christophe.

3 7