April 2025 - openstack-discuss - lists.openstack.org

[heat][ptg][ops] Flamingo PTG summary
by Takashi Kajinami 16 Apr '25

16 Apr '25

Hello, Last week during the PTG the heat team gathered to discuss a few topics. Thank you all who attended the session and the valuable discussions. The details can be found in https://etherpad.opendev.org/p/apr2025-ptg-heat but I'll leave some summary. There are a few plans about which we want to ask for any feedback from operators so I'm adding [ops] tag here. 1. Eventlet removal During the session we reviewed the current global plan to remove/replace eventlet and discussed the plan to follow it in heat. Our current idea is to remove/deprecate unmaintained code first so that we can shrink the scope. At this moment we aim to deprecate and remove the following items. - Standalone heat-api and heat-cfn-api - These are deprecated due to deprecation of WSGI server implementation from oslo.service, which depends on eventlet. Users can run api server by external server mechanism such as mod_wsgi or uwsgi. - heat-all service - This is deprecated due to deprecation of WSGI server implementation from oslo.service, which depends on eventlet. We expect this is not really used in production - legacy engine - This was deprecated in favor of convergence. Note that removing this means we no longer support adopt/abandon/check feature. Question to operators: Does anyone have concern about deprecating/removing these items ? Please be aware that the current heat team is quite small and we need actual help to replace eventlet for these features. 2. CFN API We discussed the current status of heat-cfntool which heavily depends on unmaintained boto library. However we also agreed that replacing boto by boto3 requires some effort due to the fact that boto3 does not allow overriding endpoint quite easily. While we aim to deprecate CFN api, we agreed that we still have to asses the impact because CFN API is used for signaling by default. Question to operators: Is anyone using CFN API in any other use case than signaling ? For the first topic, if we don't hear any objections, we'll follow the plan to move the removal work forward. Thank you, Takashi -- Takashi Kajinami irc: tkajinam github: https://github.com/kajinamit launchpad: https://launchpad.net/~kajinamit

1 0

[ironic][ptg] 2025.2 (Flamingo) PTG Summary
by Julia Kreger 16 Apr '25

16 Apr '25

Greetings everyone! Last week Ironic had a wildly successful PTG! We averaged around fifteen attendees most days, we drew upwards of 22 attendees for most of Wednesday while we discussed a number of related topics around networking. Overall, networking aspects seem to show the most current interest. This is the result in a change in market ecosystem where vendors are less focused on SDN integrations, and also deliberate limitations inside of ironic in order to limit scope creep and still attempt to meet the majority of infrastructure operator requirements when the original networking multi-tenancy effort was executed back in 2015-2016. Other major topics were Eventlet, some operator feedback on quarks of features, which highlighted some possible bugs and areas for improvement. We also got into some areas which have been a bit contentious in the past, but we reached some reasonable compromises which allowed us to find better paths forward. Monday: We largely discussed where we were at and where we were going. To highlight, ironic-lib has now been retired. Redfish based Graphical Console support merged and we identified some more work was likely needed. Bootable Container support *and* support for artifacts from an OCI container registry support was also viewed as completed during the cycle which ultimately improves options to infrastructure operators who are operating in mixed environments or with mixed requirements outside of the classical "everything is a VM in OpenStack" context. We've improved the linting across the majority of project repositories. Out of band inspection rules likely need more work around ensuring data structures are what we expect, but otherwise we are re-affirming our deprecation of ironic-inspector as a standalone project. Work to support Kea as a DHCP backend has paused for now. The plan exists, but realistically the contributor working in that area has a different focus at the moment which is okay! Container based IPA steps also didn't make it into the Epoxy cycle release, but are almost done already in Flamingo. Schema validation and OpenAPI work is also still underway and we broadly expect this to merge into Flamingo. In-band disk encryption as part of the ``direct`` deploy interface also didn't make any forward progress due to shifting contributor priorities. As a note, the bootable container work did extend this as a possible option, however it remains unclear if that will solve the overall need for the contributor who did propose adding support for encrypted volumes to the ``direct`` interface. Efforts to find an alternative to TinyCore usage in CI also stalled out. Turns out is less of a trivial problem to make a super-low memory ramdisk, and other fixes to the build jobs improved general reliability in the meantime so it is less pressing. We also didn't make any progress on Project Mercury as it was likely framed to try and keep too many options open for operators while we also lost contributor velocity due to some CVE work this past cycle. Having discussed what we achieved, this allowed us to focus on key aspects contributors know they needed to focus on this next cycle. Networking was the biggest topic in this area. Promptly followed by eventlet removal. There was also a consensus that we needed to ensure we're working together a bit better, but also don't explicitly block any one aspect, as there is power in user/operator choice as well. Some possible interest was also expressed around extending network device firmware upgrades, further delineating/improving metrics, possibly supporting more of a "push" firmware update model which more vendors are adopting. We promptly shifted to CI, and discussed challenges and path forward. Generally, there is some interest in trying to make some of our job executions a bit more selective, and also to dial back our reliance upon integration scenario jobs. Overall, it is a broad area of work which will require some further discussion to try and frame an ideal future state. In this we also discussed Centos Stream 10, python versions, and ultimately possible paths forward to at least highlighting other options which may enable maintenance activities to ensure these cases work. Afterwards, we shifted to CI knowledge sharing later in the day outside of the PTG schedule, to help spread overall context among newer members of the team. Tuesday! We started Tuesday with the topic of supporting a use case desired by some operators wishing to "allocate" baremetal nodes into a state which, to Ironic signifies the node has been deployed. The use case behind that is a bit odder, more for research and academic cases where other tools may be desired to meet very specific requirements. The discussion yielded an operator in the scientific space which could benefit, so some ideas and a possible path was identified. Then we got into the world of eventlet and a mini-retrospective of the challenges and identification of future steps. What we thought would be simple, turned out to be the hardest problem. Ironic Python Agent, originally identified as a good candidate for an early eventlet migration, has turned out to be extremely difficult due to it's need to spawn it's own WSGI server late in the process. Upon further reflection; Ironic itself has this issue as well, because we actually have two places a WSGI server might be spun up: ironic-api (obviously) and the conductor when using json-rpc. It was clear that solving that technical problem was the first step in our migration. We found some examples of gunicorn used in this way; that may be what we look to for an initial prototype. We then spoke about node / hardware monitoring patterns that operators are using and interested in. Redfish based hardware supports sending a notification to a web service on a threshold violation so we discussed adding a listener into Ironic that could receive these and integrate this into the current hardware event notifications. We agreed that a spec would be necessary and we would craft one and proceed from there. Further improvements around making it easier for operators to separate monitoring/events of the services from the hardware itself was discussed but oslo_messaging does not allow for this type of split routing today. We spoke about looking further into ironic-prometheus-exporter to see how it could be configured to potentially support this separation. To wrap up Tuesday, we drifted into discussion of the serial console support which Ironic has today. In essence, there is quite a bit of room for possible improvement there and some operators who are not using Nova wouldn't mind this area to see attention moving forward. The broad idea is we might explore creation of a new interface which enables SSH connections to be proxied through to the IPMI Serial-over-LAN capabilities in a BMC. This distinctly would require IPMI, since there really is not a great answer to serial console/interface access with Redfish. Ultimately this may also mean we extend redfish to support an IPMI interface as well, which seems weird, but discussion was in broad agreement that this space has unique challenges where this makes sense. Some initial ideas were entered into an spec document for discussion and refinement as some of the interested parties are also on the perimeter of the Ironic project. Wednesday! Wednesday was our deep dive into networking! Our very first topic was focused on improving the capabilities around the intentional limitations which were encoded in Ironic's early multi-tenant networking work. The early work was mainly focused on ensuring tenant level isolation on to separate L2 domains, such as VLANs. In large part, this boils down to the mapping, scheduling, and ultimately the dynamic assembly of a port grouping (bonded interfaces). We came into this session with a specification document from a discussion which occurred a few weeks prior and there was general consensus in this option and discussion highlighted a few other intertwined aspects which need to be accounted for. We then dove into ACL support for Networking Generic Switch. Overall, consensus resulted. This discussion also highlighted a number of aspects we also likely need to keep in mind, and potentially may start best be described as overall needs for additional documentation. There are also some further discussions which may need to be revisited networking wise. Ultimately, this is very much an "integrated" use case which was only appealing to about half of the attendees, which is typical given the variety of use cases Ironic solves and is able to support. Then we reached the topic of Standalone Switch management. This quickly became a retrospective into why we didn't make progress with Mercury, and then drove into what are the real minimal requirements which would need to be taken into account. Some of the discussion revolved around questions which were semi-answered in the mercury plan itself, to try and provide enough overlap to generally be usable in more than one use model/case while also enabling or preventing fragmentation. This discussion also crossed over into support of DPUs and how to support them, in large part because the overall model is very different. Some discussion also sort of shifted into maybe merging and tools together. Ultimately this topic requires much more discussion, and to make solid progress on networking aspects we need to enable ourselves to move together in two directions at once, while not blocking each other. With this in mind, we're forming up into two sub-teams which will focus on each area with their own advocates/champions. The goal being to report back to the community each week in a quick update style of engagement. Thursday! Thursday marked our final day of PTG for Ironic. We started by wrapping up some of the networking discussions, in large part the focus on how to make progress. We used this time to identify our high level organizational plans, determine broad interest levels and ultimately outreach. One key aspect which was highlighted, is the initial primary focus for some will likely be making progress on eventlet before shifting gears into networking. We then shifted gears to discussing interest and requirements of mapping storage volumes to overall hosts via DPU devices, which somewhat crossed over into the networking topics. The broad idea was presented with a potential need to frame compound drivers around facilitating broadly different configuration actions. For example, directly via SSH to invoke commands, or for example update a CRD in a distinct OpenShift cluster. Overall, the discussion yielded that maybe invoking a CRD update was not worthwhile given the flux those areas can experience along with competing requirements. Ultimately this is an area in early discussion and would require investment in time and hardware to move forward, but there were really no objections to doing so if we could model and extend what already exists in a useful and applicable way. We then drifted back into networking with our next topic, bridging distinctly different types of fabric together. This was raised much more as a question to see if there was an interest/need and/or requirement. In essence, this is similar to the original l2gw project. A huge highlight of embracing or extending into a more ideal model is the reality that if this existed, it might not be necessary for VXLAN to be considered on the physical side. Discussions then shifted to improving servicing interactions. Servicing functionality was added to Ironic during one of the recent past development cycles to enable firmware upgrades to take place on deployed nodes. In discussion, it was highlighted that in the current model this could take five or more reboots to facilitate the deployment as the current mechanism is largely modeled on the use of agent heartbeats. The discussion shifted to how we could avoid this. And the obvious answer was "add a periodic". Then concerns over adding more periodic queries and jobs shifted the discussion into how we can address that challenge. Ultimately, this may end up with us in a better place for tasks which need to follow-up on state changes in hardware and revisit the state before proceeding with the next step to execute. As the final topic, we dove into deploy steps. This really boiled down to "how do I know what will occur" when I ask Ironic to do something along with "how do I know what occurred". Consensus reached that largely the key aspect to highlight back to the user is "what was done" or "what do we expect to be done" in terms of steps. An idea was raised to record this into node history, which is a historical record list of actions/errors to a node which has existed in Ironic for a number of cycles now, but is most useful if you're trying to figure out prior events without going to logs. Consensus was that doing it this way would be a "quick win". At some point, Ironic contributors also sat down and reviewed jammed outside of the PTG schedule to review/discuss and merge existing items sitting awaiting reviews. Overall, the week was extremely productive! Thanks to everyone who took part. Additional thanks to everyone who collaborated on this summary, and everyone who also helped push our project priorities published for this work cycle[3]. Please remember if you have action items to follow-up. And onward to Flamingo! - The Ironic Team [0]: https://etherpad.opendev.org/p/ironic-ptg-april-2025 [1]: https://review.opendev.org/c/openstack/ironic-specs/+/945642 [2]: https://review.opendev.org/c/openstack/ironic-specs/+/946723 [3]: https://specs.openstack.org/openstack/ironic-specs/priorities/2025-2-workit…

1 0

[glance] Flamingo PTG summary
by Cyril Roelandt 15 Apr '25

15 Apr '25

Hi, We have just had our virtual PTG. The full list of topics, along with notes, can be found on our Etherpad[1]. Here is a summary of the topics that will be targeted during this cycle. If you would like to view one of the recordings, please reach out to us so we can figure out a way to share it. # glance-tempest-plugin work There has not been a lot of activity on the Glance Tempest Plugin for a while. We decided to put more effort into it this cycle. The first step is to decide what stale patches to abandon or rebase. We will also try to add tests for newer APIs added in the past cycles (location, quota, cache). # Eventlet removal While Glance can already be deployed in production without eventlet, this library is still required for half of our functional tests, as well as for non-core features (namely the scrubber). We will be focusing on migrating our functional tests away from eventlet during this cycle. # Image encryption Not much progress has been made on this topic in the past cycle. The original authors of this feature are willing to spend time working on the required patches during the Flamingo cycle; the Glance core dev will make it a priority to quickly review the required patches so that we can finally merge the feature. # Glanceclient chunked transfer By default, the Glance client transfers data to the Glance API in chunks. This may force the Cinder backend to resize the volume multiple times, slowing down the upload. Providing the total size of the image will allow us to fix this issue. # Cinder common configuration options Operators often have parameters set to the exact same values for multiple Cinder backends. We plan on making it possible to configure "common configuration options", thus allowing operators not to repeat configuration snippets. # Freeze glanceclient development As we approach feature parity between the Glance client and the OpenStack unified client, we believe it will be best to freeze development of the Glance client. In the future, we will only fix bugs and security issues. During this cycle, we will work on actually reaching feature parity with the unified client. # new location API (Cinder & Nova) Glance has introduced two new Location APIs in the Dalmatian cycle. We can use these APIs to address OSSN-0090 and OSSN-0065. Patches for Nova and Cinder must still be merged, hopefully during the Flamingo cycle. # freeze glance client development Cinder and Nova will need to use the OpenStack SDK instead of the glanceclient. There is no need to complete this work during this cycle, but we should at least have a good idea of what APIs are currently being used, so that we can have a plan for the next cycles. # cache-cleaner/pruner We discussed possible minor improvements to both the cache-pruner and the cache-cleaner. This work is not going to be a priority for this cycle. # Deprecate the filesystem_store_datadirs configuration option This option has not been needed since the introduction of multistore support. Happy Hacking! Cyril Roelandt [1] https://etherpad.opendev.org/p/apr2025-ptg-glance

1 0

[horizon] Launch instance: some port names not displayed
by Eugen Block 15 Apr '25

15 Apr '25

Hi *, I've been searching for an existing bug report but haven't found one yet. OpenStack Zed (Antelope 2023.1 is also affected) openstack-dashboard versions 23.0.0 and also 23.2.0 Both environments have been upgraded from Victoria relatively quick, that's why we haven't noticed it until now, but apparently there have been major workflow changes between Victoria and Wallaby how network ports are displayed in Horizon (Launch Instance). When we open the "Launch Instance" dialog in Horizon, and we want to attach an existing port (created via CLI) to the instance, only some of the ports in the list are displayed with a name, many don't have one, although all ports were created with a name via CLI (it would have failed without providing a name). A colleague of mine helped debugging and he suspects a JavaScript error, I'm translating his statement: > Some sort of cache is built, coming from an array which is supposed > to store all relevant ports. Apparently, not all ports have been > stored yet in that array in time, leading to this inconsistency. If > there's a missing "async" or "await" somewhere, it would explain > this behavior. He then points to these functions: getPortsObj, isPortsObjGenerated which are called by getNameOrId. I found those calls here: /usr/lib/python3/dist-packages/openstack_dashboard/dashboards/project/static/dashboard/project/workflow/launch-instance/networkports/ports.controller.js and here /usr/lib/python3/dist-packages/openstack_dashboard/dashboards/project/static/dashboard/project/workflow/launch-instance/networkports/ports.spec.js Is anyone aware of an existing bug report for this? I can create one, if necessary. Thanks! Eugen

2 2

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

15 Apr '25

Hello Stackers, Welcome back from a week of design confabulations. In the past couple of weeks, we moved quickly from the coordinated release of OpenStack 2025.1 "Epoxy" to the virtual Project Teams Gathering to plan the next release, OpenStack 2025.2 "Flamingo." We've got 24 weeks to go [1] to implement these plans. Now is a good time for project teams to add any project-specific deadlines to the release schedule. As PTG summaries slowly trickle in, I wanted to send out a brief note about the TC's weekly meeting that happened prior to the PTG, and our plans for the next one. === Weekly Meeting === The last weekly meeting of the OpenStack Technical Committee was held simultaneously on Zoom [2] and IRC [3] on 2025-04-01. The committee discussed security concerns with UI projects, mainly Skyline. Our attempts to independently rebuild the project failed partially because JavaScript libraries included had changed, and there were no build trackers. We didn't get an opportunity to continue this discussion at the PTG. For now, we'll try to keep the conversation on the mailing list and simultaneously explore solutions with the Skyline project team. The rest of the meeting was used to discuss CI updates, updates to the TC's tracker, and scheduling conversations for the vPTG. I'll share the minutes of the TC's PTG proceedings with you soon. In the meanwhile, please feel free to peruse the etherpad [4] or the playlist with recordings of the proceedings [5]. The next meeting of the OpenStack TC is today, 2025-04-15 at 1700 UTC. Please note the change in timing — it is an hour earlier than our past meetings used to be. This meeting will be held on IRC (OFTC's #openstack-tc channel). Please find the agenda on the meeting's wiki page [6]. I hope you'll be able to join us there. === Governance Proposals === ==== Merged ==== - Fix nova PTL IRC nick | https://review.opendev.org/c/openstack/governance/+/946175 ==== Open for Review ==== - [resolution] Extend scope of VMT to cover all project teams | https://review.opendev.org/c/openstack/governance/+/944817 - Fix Dan Smith's email | https://review.opendev.org/c/openstack/governance/+/946960 - Add aetos to telemetry project | https://review.opendev.org/c/openstack/governance/+/946744 === Upcoming Events === - 2025-04-29: StackConf https://stackconf.eu/ - 2025-04-29: SCS Hackathon / OpenStack Birthday: https://events.sovereigncloudstack.org/hackathon5-2025/ - 2025-05-13: OpenInfra Board Meeting: https://board.openinfra.org/ - 2025-05-22: OpenInfra UG Meetup, Sweden: https://www.meetup.com/openinfra-user-group-sweden/events/306139678/ 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] TC Meeting Video Recording, 2025-04-01: https://youtu.be/HcWJY2DeLYc [3] TC Meeting IRC Log 2025-04-01: https://meetings.opendev.org/meetings/tc/2025/tc.2025-04-01-17.00.html [4] OpenStack TC's 2025.2 PTG Etherpad: https://etherpad.opendev.org/p/r.51cb4e74dd9980932d32e9a9f4e8a0ce [5] OpenStack TC's 2025.2 PTG recordings: https://www.youtube.com/playlist?list=PLhwOhbQKWT7XYzqrx21j1uizxNxnbDf5Q [6] TC Meeting Agenda, 2025-04-15: https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting

1 0

[I18n] Broken ko_KR translation for OpenStack-Ansible
by Dmitriy Rabotyagov 15 Apr '25

15 Apr '25

Hey folks, Today it was brought to my attention that OpenStack-Ansible does not get any periodic updates for translations for around 2 years now. Once I've checked the result of periodic job, it seems that a ko_KR translation makes Zuul job to fail: https://zuul.opendev.org/t/openstack/build/fc90cb4be70e45e8bec07e981eaff01e Specifically, following translations are containing the error (/n in translated version, which are not present in original message): * resource-id:3db2c4ee55f9791e84ff3137e05be661 * resource-id:9f3ab9a8642b37abfcdc47804c05a49f * resource-id:8cd037448cc79d28322aeb8ec25dac58 * resource-id:182414aa5a44b5a113335bc17346b853 It would be much appreciated if somebody with access to ko_KR could fix that as soon as possible. Or, alternatively, grant me permissions to translations of the project, as to PTL. Thanks in advance!

2 2

[Magnum] Issues with Magnum (K8s 1.21.11 Clusters)
by Oliver Weinmann 14 Apr '25

14 Apr '25

Hi all, We’re running a Kolla-Ansible 2023.2 deployment with Magnum. While we primarily use CAPI, we also have some older Kubernetes 1.21.11 clusters. In these clusters, we’re encountering two specific issues: Random Crashes of openstack-cloud-controller-manager Pod In one of the older clusters, the openstack-cloud-controller-manager pod is crashing intermittently with the following error: F0410 12:02:45.673777 1 main.go:84] Cloud provider could not be initialized: could not init cloud provider "openstack": Post "http://openstack.xxxxxxx:5000/v3/auth/tokens": dial tcp 172.xxx.xxx.xxx:5000: i/o timeout However, when I manually test connectivity to the Keystone API from the master node, it appears to work fine: while true; do status=$(curl -s -o /dev/null -w "%{http_code}" http://172.xxx.xxx.xxx:5000/v3 2>/dev/null) || status="failed" echo "$(date): Keystone API status: $status" sleep 10 done Sample output: Thu Apr 10 19:19:50 UTC 2025: Keystone API status: 200 Thu Apr 10 19:20:00 UTC 2025: Keystone API status: 200 Thu Apr 10 19:20:10 UTC 2025: Keystone API status: 200 ... Despite the API being reachable, the pod continues to crash sporadically with the timeout error. "Too Many Open Files" Error in Pods Users running pods in these clusters are reporting frequent "Too many open files" errors. Since Kubernetes 1.21.11 relies on CoreOS, I’m looking for a way to permanently increase the maximum number of open file descriptors on CoreOS. Any guidance or suggestions on how to address these issues would be greatly appreciated! Best regards, Oliver

2 2

[openstack-ansible][ptg] Flamingo PTG results
by Dmitriy Rabotyagov 14 Apr '25

14 Apr '25

Hey folks, Last week along with other teams we had a PTG session where a development focus for the project was discussed. I want to thank everyone who attended the session and participated in discussions. Despite the small amount of time scheduled for the session, it was very productive and you might find the summary below. Finalizing Epoxy release As OpenStack-Ansible does have a trailing release model, we still have some time left for releasing the Epoxy, with the deadline being set at June 6, 2025. With that a few topics were highlighted to be worked on for the release to be finished: * Finalize migration for Ansible to use FQCN. While this is not obligatory as of today nor a blocker for further development - we decided to adopt our roles to the new standard introduced with ansible-core 2.10. And this topic is pretty much merged at the moment: https://review.opendev.org/q/topic:%22osa/fqcn%22 * Deprecate openstack-ansible-tests repo to avoid releasing it for Epoxy. At the moment, the only useful data in the repo is the sync tool (proposal bot). We agreed to move the content/functionality we need to the integrated repository. * Finalize migration of services to HTTPD role. At the moment, only Keystone and Horizon are left for the migration (the toughest ones). One of the challenges for the migration was highlighted the need to install/gather list of required modules for HTTPD once, to avoid service restarts needed for loading new modules vs reloads for vhosts updates. Though it still should not be a hard blocker for the migration, as this issue persists today anyway. * Linux Bridge Removal. While main patches for removal were merged: https://review.opendev.org/q/topic:%22osa/lxb_cleanup%22 we still have a Zun relying on LXB tests, which is obviously broken now. Some love needs to be given for tests to pass. * Fix compressed upload of CoreOS for Magnum Heat driver tests. As CoreOS is compressed out of the box, and Glance has no support for uploads of compressed files anymore, we need to implement decompression logic to the openstack_resources roles. Topic https://review.opendev.org/q/topic:%22osa/decompress_image%22 is created to track progress. * Document ceph source & version constraints for Noble, as there are no community repositories, only "native" one with ceph reef. Scoped for the Flamingo (2025.2): * PKI * driver for hashi-vault to be scoped for Flamingo as it requires quite a refactoring and we're too late into the release now. * Refactor standalone to create CSR and private key on the service side only * Issue certificate on the deploy host * Upgrade script to remove secret data from the deploy host * Reload libvirt config on certificates change to address VNC isuses * Shorter lifetimes * Drop Ubuntu 22.04 early in the cycle, as it is a blocker now for ansible-core 2.18 * ceph jobs are still running jammy * Add support for CentOS Stream 10 / Rocky 10 * We need to handle / create nodeset with infra to target only supported providers for tests * modular libvirt support * Use smaller nodes for molecule tests * Import Freezer role from https://github.com/noonedeadpunk/openstack-ansible-os_freezer once central scheduler support is merged to Freezer itself. * Continue coverage with Molecule tests * HAProxy role is smth we need to cover next * Complexity for TLS backends logic * IPv6/Multiple frontends * Coverage for individual roles inside of the plugins repository

1 0

[openstack][kolla-ansible][neutron] router ha was split brain when restarting l3 agent docker
by Nguyễn Hữu Khôi 14 Apr '25

14 Apr '25

Hello., I deploy a multi node cluster with 2 network nodes separately with l3_ha=true and max_l3_agents_per_router=2. It is ok but when I restart neutron_l3_agent on a host which has an active router then 2 routers become standby-standby or active-active. I feel 2 network nodes very easily to split brain. Could I have some ideas on this problem. Thank you. openstack 2025.1-master kolla-ansible2025.1 master ubuntu 22.04 Nguyen Huu Khoi

2 5

[Swift] S3/Swift compatibility: getBucketPolicy
by coolnodje＠gmail.com 14 Apr '25

14 Apr '25

I'm meeting some issues providing S3 compatible storage on OpenStack with editor solutions requiring getBucketPolicy in their S3 usage. I'm checking what can be done from the editor side, but I'd like to know if there exists a roadmap where getBucketPolicy would become supported. Thanks

1 0