September 2024 - openstack-discuss

[largescale-sig]scaling story
by Alex Song (宋文平) 25 Oct '24

25 Oct '24

Hi everyone, we want to share our scaling story. Please refer the link: https://etherpad.opendev.org/p/large-scale-inspur Thanks, Alex Song

6 8

[nova][libvirtd] internal error: unable to execute QEMU command 'query-named-block-nodes'
by Satish Patel 22 Oct '24

22 Oct '24

Folks, I have a ceph cluster and recently I configured rbd-mirror to replicate all data to remove ceph cluster for disaster recovery. Yesterday for POC we did a hard cutover on ceph and point openstack to the new cluster. All other vms came back up fine but 2 vms stuck in this error state in libvirt logs 2024-01-31 22:44:37.591+0000: 474597: error : qemuMonitorJSONCheckErrorFull:399 : internal error: unable to execute QEMU command 'query-named-block-nodes': cannot read image start for probe: Permission denied If it's a wider issue than it should impact all the vms but why only two VM stuck and not starting and libvirt giving me this error in logs nova-compute logs also showing same error 2024-01-31 22:44:40.925 7 INFO nova.compute.manager [None req-b33485b5-8740-48ae-8b5b-a440de3f11a4 c48fcfb9347f413f92fcece065644b00 ca5c652478c7429e964257990800e9cb - - default default] [instance: 2de0f880-77c7-4d2c-9e01-898c57ad3693] Successfully reverted task state from powering-on on failure for instance. 2024-01-31 22:44:40.944 7 ERROR oslo_messaging.rpc.server [None req-b33485b5-8740-48ae-8b5b-a440de3f11a4 c48fcfb9347f413f92fcece065644b00 ca5c652478c7429e964257990800e9cb - - default default] Exception during message handling: libvirt.libvirtError: internal error: unable to execute QEMU command 'query-named-block-nodes': cannot read image start for probe: Permission denied

3 8

[all][dev][ops][tc] Bridging the gap between community and contributing orgs
by Jeremy Stanley 22 Oct '24

22 Oct '24

The tl;dr on this is that I'm opening a broad community discussion on how we can, collectively through improved communication, better bring together our established contributors with casual and prospective contributors who struggle to find successful patterns of contribution, so that we might all support each other in order to benefit OpenStack as a whole. Read on for details... OpenStack's TC has requested that foundation staff, when in conversation with representatives of member organizations, encourage participation in the project and collect feedback on any related challenges those organizations encounter in their attempts to do so. In order to better understand the feedback and brainstorm achievable recommendations for the broader community[*], Community Managers on the foundation staff started to work with a small focus group of established contributors with a solid understanding of what successful patterns of contribution look like. It also came to light that established contributors experience many of the same sorts of challenges, even more so if they don't have the luxury of focusing full-time upstream, and so success often comes down to knowing how to effectively navigate those challenges. The community's goal with this exercise is to improve everyone's experience, and your help is needed to do that! The most common themes reported by those struggling to contribute are not related to tooling or workflow confusion, but instead seem to come down to basic communication challenges. Ideas so far to address these gaps include: * Review bandwidth - Ensure contributors and companies understand the importance and benefits of code review - Incentivize and credit meaningful "+1" reviews more - Understand that the volume of changes and limited reviewer bandwidth often means proposals aren't reviewed quickly (or at all), and their proponents may need some additional tenacity and engagement with the team to get their work noticed - Utilize "review dashboards" as a way to find stale changes which have fallen through the cracks * Review strategy and etiquette - Be clear about the meaning of votes on changes, especially negative ones, and set explicit timelines for things like "procedural -2" or WIP blocks when their approval needs to be delayed - Focus on comments and requests that affect whether or not the change can be merged after the fixes are submitted, rather than requesting trivial adjustments to an unsuitable change which has more fundamental problems - Reciprocate with reviews of changes from new reviewers you see leaving insubstantial reviews, demonstrating to them what deeper and more meaningful reviewing looks like * Mentoring newcomers - Established contributors with sufficient bandwidth can help mentoring newcomers, potential core reviewers and new leaders - Mentoring can happen as part of internship programs as well as by helping newcomers determined to become active contributors; both ways should be embraced and utilized What challenges are you facing? And, how would you improve them? Two weeks from now, we'll have a forum session at the OpenInfra Summit Asia in Suwon[**] where our community can refine these possible approaches and integrate others, as well as bring attention to them and promote their application. I've also proposed a similar forum session for OpenInfra Days North America in Indianapolis a month after that, where we can hopefully continue this conversation. The goal for this multi-stage effort is to improve the contribution experience for established participants, casual contributors and newcomers alike. While it's easy to jump to blaming in these situations, it will be far more productive if we can focus on the challenges and experiences that we would each like to remove or improve for ourselves and others in our community. As we find ways together to improve our efficiency, we can reduce the load on all contributors and lower the barriers for people to join and participate. [*] https://etherpad.opendev.org/p/r.2205024e55689bccb82c20c960853cb5 [**] https://2024.openinfraasia.org/a/schedule#view=calendar&title=Bridging%20th… -- Jeremy Stanley

2 4

[kuryr][tc] Final call for Kuryr PTL/DPL liaisons
by Ghanshyam Mann 15 Oct '24

15 Oct '24

Hello Everyone, Kuryr project ends up being a leaderless project for the 2024.2 Dalmatian cycle[1]. There is no volunteer to serve as PTL or DPL liaisons yet. As the next step, I have proposed to mark this project Inactive: - https://review.opendev.org/c/openstack/governance/+/916945 If you would like to serve as a leader and help maintain this project, this is the right time to step up by replying to this email or commenting in gerrit change 916945. [1] https://etherpad.opendev.org/p/2024.2-leaderless#L99 Ref: https://governance.openstack.org/tc/reference/emerging-technology-and-inact… -gmann

4 10

Kolla Ansible on Ubuntu 20.04 - cloud-init & other network issues
by Tobias McNulty 10 Oct '24

10 Oct '24

Hi, I'm attempting to use Kolla Ansible 14.6.0 to deploy OpenStack Yoga on a small 3-node Ubuntu 20.04 cluster. The nodes have 128 GB RAM each, dual Xeon processors, and dual 10G Intel NICs. The NICs are connected to access ports on a 10G switch with separate VLANs for the local and external networks. All the playbooks run cleanly, but cloud-init is failing in the Ubuntu 20.04 and 22.04 VMs I attempt to boot. The VM images are unmodified from https://cloud-images.ubuntu.com/, and cloud-init works fine if I mount a second volume with user-data. The error is a timeout attempting to reach 169.254.169.254. This occurs both when booting a VM in an internal routed network and directly in an external network. I tried various neutron plugin agents (ovn, linuxbridge, and openvswitch both with and without firewall_driver = openvswitch <https://docs.openstack.org/kolla-ansible/latest/reference/networking/neutro…>) first with a clean install of the entire OS each time, all with the same result. Running tcpdump looking for 169.254.169.254 shows nothing. As a possible clue, the virtual NICs are unable to pass any traffic (e.g., to reach an external DHCP server) unless I completely disable port security on the interface (even if the associated security group is wide open). But disabling port security does not fix cloud-init (not to mention I don't really want to disable port security). Are there any additional requirements related to deploying OpenStack with Kolla on Ubuntu 20.04? This is a fairly vanilla configuration using the multinode inventory as a starting point. I tried to follow the Quick Start <https://docs.openstack.org/kolla-ansible/yoga/user/quickstart.html> as closely as possible; the only material difference I see is that I'm using the same 3 nodes for control + compute. I am using MAAS so it's easy to get a clean OS install on all three nodes ahead of each attempt. I plan to try again with the standard (non-HWE) kernel just in case, but otherwise I am running out of ideas. In case of any additional clues, here are my globals.yml and inventory file, along with the playbook I'm using to configure the network, images, VMs, etc., after bootstrapping the cluster: https://gist.github.com/tobiasmcnulty/7dbbdbc67abc08cbb013bf5983852ed6 Thank you in advance for any advice! Cheers, Tobias

5 9

Improving stestr... or switching to a (better) compatible test runner?
by Thomas Goirand 09 Oct '24

09 Oct '24

Hi, This is the 2nd time I'm opening a thread about it. Sorry for this, but it really bothers me. Today, running tempest, I got these stats from stestr: - Worker 0 (132 tests) => 0:24:49.209885 - Worker 1 (100 tests) => 0:17:14.791845 - Worker 2 (124 tests) => 0:42:52.690906 - Worker 3 (189 tests) => 0:41:21.307241 - Worker 4 (159 tests) => 0:45:49.503031 - Worker 5 (143 tests) => 0:28:13.282371 - Worker 6 (156 tests) => 3:16:52.364976 - Worker 7 (103 tests) => 0:46:05.366089 So, thread #1 ran 17 minutes, sitting idle for the rest of the 3 hours run of thread #6. While I thought stestr was deviding the number of tests by the number of thread, I don't get why worker #1 only had 100 tests assigned. All together, all tests could have been ran within maybe less than an hour of time (rather than 3h16 above), if not-yet-ran-tests were reassigned to idle treads. I'm currently spending a lot of time on running tempest. Indeed, I'm running tempest on each OpenStack upgrade, from Victoria up to Dalmatian. With the current way stestr run, it may take 2 full days to do that (and that's not even counting when upgrade will fail and will need fixing...), when it could be done in maybe 8 hours (if I count 1h per OpenStack release). So, knowing the above, it might be a good use of my time to dig into stestr and see if I can fix this... or not! Does anyone have a suggestion for another test runner, that's compatible with stestr, at least for the tests selection with a regular expression? As much as I know, pytest cannot take a regexp for test selection, can it? Or is there maybe a plugin for it? If there's no compatible test runner, where should I dig in the stestr code to rewrite things in a smarter way? Cheers, Thomas Goirand (zigo) P.S: On Caracal today, I just had this: ============== Worker Balance ============== - Worker 0 (117 tests) => 0:59:32.291385 - Worker 1 (147 tests) => 1:22:28.228980 - Worker 2 (125 tests) => 0:45:20.969397 - Worker 3 (114 tests) => 1:46:21.667579 - Worker 4 (170 tests) => 0:45:27.577738 - Worker 5 (190 tests) => 2:28:39.744920 - Worker 6 (182 tests) => 2:29:01.402255 - Worker 7 (152 tests) => 2:29:10.183359 this looks better, but that's probably 1/ random 2/ still not perfect, with worker #0, #2 and #4 doing nothing 2/3rd of the time.

2 1

[tc][watcher] No leaders for project team, heading to retirement
by Goutham Pacha Ravi 09 Oct '24

09 Oct '24

Hello Stackers, The "watcher" project [1] did not have any volunteers to lead the project in the 2025.1 election cycle. In the past few years, the project's team has slowly disbanded and there have been no significant changes proposed/merged in the project's repositories [2]. We noticed that there were three deployers that noted their use of Watcher in production in the past user survey [3]. It's possible that the project failed to gather any significant adoption, and hence there's less interest in contributing to, and maintaining the project. I'm sending this notification pursuant to the OpenStack governance recommendations [4] to retire project teams. We can mark a project team "inactive", however, an "inactive" project must have some contributors aiming to build-back a maintainers team around it - and it must pick a project team lead, or adopt a distributed project leadership model by nominating liaisons. Since there are no PTL nominees, we think marking this project "inactive" serves no purpose. Is there any objection to retiring the "openstack/watcher" project (and associated deliverables: python-watcherclient, watcher-dashboard and watcher-tempest-plugin)? Once the project is retired, configuration management and deployment projects can drop their integrations as well. Thanks, On behalf of the OpenStack TC, Goutham Pacha Ravi [1] https://wiki.openstack.org/wiki/Watcher [2] https://review.opendev.org/q/(project:%5Eopenstack/watcher.*+OR+project:ope… [3] https://governance.openstack.org/tc/user_survey/analysis-2023.html [4] https://governance.openstack.org/tc/reference/dropping-projects.html

5 7

Stop bumping major versions when dropping EOL Python versions
by Stephen Finucane 04 Oct '24

04 Oct '24

o/ Python 3.8 is going EOL (upstream, anyway) next month. We've been working to drop support for this from various SDK deliverables, and I'm guessing (though don't yet know for sure) that this will happen across other project deliverables before long (if it hasn't started happening already). One side-effect of this change is that we will be expected to raise the major version of the affected dependencies on our next release. This is annoying for projects like openstacksdk that use the release-with-intermediary release model because it forces us to have a major version release earlier than we would like to. To give a concrete example, we have a RemovedInSDK50Warning deprecation warning that we are using to indicate (as you might guess) things that we plan to remove in openstacksdk 5.0.0. We need to wait 6 months/1 OpenStack release before removing anything flagged with this warning, so this has been mainly applied to legacy deprecation warnings to put a concrete timeline on their removal. However, because we just dropped Python 3.8 support, it is currently expected that our next release be 5.0.0. We last deprecated something new ~2 months ago, so this means we either cannot release a new version of openstacksdk for 3-4 months (to allow 6 months to pass) or we need to either rename RemovedInSDK50Warning to RemovedInSDK60Warning or add a new RemovedInSDK60Warning and move the offending deprecations to this. None of these are nice options and to be honest, I don't think the major version bump really provides all that much value to end-users: they already have a much better signal for the removal of a Python version in the 'python_requires' marker in setup.py/setup.cfg/pyproject.toml/(other build system file). By using this, we ensure that a user simply can't install a version of a package that doesn't support their chosen Python version. I'd be in favour of getting rid of this particular constraint, and instead focusing on API changes when deciding whether to bump the major version. Is this a reasonable suggestion, and if so what would we need to do to tweak our policy to allow it? Cheers, Stephen

4 3

[Kolla-Ansible] [Ironic] Node Deploy Failed with MissingAuthPlugin
by Ali Hussain 01 Oct '24

01 Oct '24

Hi Kolla and Ironic folks, While playing with stable/kolla release to fix the No VIF found error. Looks like adding Readers role to ironic user fixed it. But run into Missing Auth plugin [2] issue while image is being deployed to ironic node. Openstack endpoint list command [1] shows the correct IP of the controller. My question is: 1. Kolla-Ansible needs explicite Ironic keystone configuration in Ironic.conf? Following this link <https://docs.openstack.org/kolla-ansible/yoga/reference/bare-metal/ironic-g…> which does not seems to need any keystone configurations. This issue is observed when 1. --boot-interface redfish-virtual-media 2. --deploy-interface ramdisk 3. --driver-info deploy_iso= 4. -instance-info kernel & ramdisk 2. My passwords.yaml has 1. ironic_database_password: 2. ironic_inspector_database_password: 3. ironic_inspector_keystone_password: 4. ironic_keystone_password: Any suggestions please. Thank you. Ali [1] openstack endpoint list | grep ironic | <ID> | <Region> | ironic-inspector | baremetal-introspection | True | internal | http://<IP>:5050 | | <ID> | <Region> | ironic | baremetal | True | public | http://<IP>:6385 | | <ID> | <Region> | ironic-inspector | baremetal-introspection | True | public | http://<IP>:5050 | | <ID> | <Region> | ironic | baremetal | True | internal | http://<IP>:6385 [2] *Error: *Detected change in error condition on node Node1. Deploy step deploy.deploy failed with MissingAuthPlugin: An auth plugin is required to determine endpoint URL.. An unhandled exception was encountered while aborting. More information may be found in the log file.

2 6

[largescale-sig] Next meeting: September 18, 9utc
by Thierry Carrez 01 Oct '24

01 Oct '24

Hi everyone, The Large Scale SIG will be meeting this Wednesday in #openstack-operators on OFTC IRC, at 9UTC. You can doublecheck how that UTC time translates locally at: https://www.timeanddate.com/worldclock/fixedtime.html?iso=20240918T09 Feel free to add topics to the agenda: https://etherpad.opendev.org/p/large-scale-sig-meeting Regards, -- Thierry Carrez

3 3

[tc][all] OpenStack Technical Committee Weekly Summary and Meeting Agenda (2024.2/R-0)
by Goutham Pacha Ravi 30 Sep '24

30 Sep '24

Hello Stackers, After 26 weeks of effort across the community, we're finally at the release week for the 2024.2 release [1], codenamed 'Dalmatian'. I'll cue "Who Let the Dogs Out" for 2024-10-02 and toast the successful delivery of the 30th release of OpenStack with all of you. Congratulations, and thank you for your contributions in making this yet another on-time release. Please tune into the OpenInfra Live episode at 1400 UTC on 2024-10-03 [2], where you'll hear from a few Project Team Leads about the new and exciting things included in this release. Over the past week, the OpenStack TC assisted the release team in tagging a few deliverables, and on its behalf, I'd like to commend the release team for pulling out all the stops to ensure yet another on-time release. It takes a village, as Jeremy Stanley (fungi) noted on IRC — the happy, buzzing Stackerton village. We also merged some governance changes in the meantime. Notably, we adopted a community goal to move all existing Ubuntu testing to the latest LTS [3], and we retired several charms repositories after their consolidation into the Sunbeam-charms project [4]. I am pleased to welcome Dmitriy Rabotyagov (noonedeadpunk) as the Vice Chair for the TC, and I thank the outgoing Vice Chair, Dr. Jens Harbott (frickler), for his contributions during the 2024.2 release cycle. Next week, as we step into the 2025.1 ("Epoxy") release cycle formally [5], we'll switch into PTG and planning mode and chart out the remaining release priorities early. === Weekly Meeting === The Technical Committee's weekly meeting was held over IRC on 2024-09-24 [6]. We began the meeting by welcoming new members and thanking outgoing ones. We appointed a TC Chair (me) and a Vice Chair (noonedeadpunk) for the 2025.1 release cycle. We then worked through several 2024.2 release issues. We were presented with a peculiar, but familiar problem involving release deliverables that couldn't proceed without help from project maintainers who were unavailable during the release crunch. The release team prepares release candidate patches a week before the RC1 deadline and encourages project maintainers to vote on them. They also submit changes to the respective repositories to verify the state of the CI system to prevent releasing broken code. However, when a project team doesn't respond, there's a risk to the coordinated release. We brainstormed strategies to deal with the current conundrum. Thanks to noonedeadpunk and the attentiveness of project maintainers in Zun and Barbican, we were able to fix broken CI jobs and tag release candidates for some projects. However, we couldn't determine the state of "kuryr-kubernetes" and "kuryr-tempest-plugin." These projects, flagged earlier as unmaintained, are expected to be retired soon, so there are no releases from these projects in the 2024.2 release stream. If you depend on these projects, please let us know. We are looking for maintainers who can commit to reviving the CI and furthering these projects. The next OpenStack TC meeting is on 2024-10-01 at 1800 UTC. This meeting will be held simultaneously via video and IRC. Please find the agenda and other meeting details in our meeting wiki [7]. I hope you'll be able to join us. Remember, you can always edit the agenda and propose new topics! === Governance Proposals === ==== Merged ==== - Retire all single charm repositories | https://review.opendev.org/c/openstack/governance/+/903490 - Select community-wide goal: migrate CI/CD jobs to Ubuntu Noble | https://review.opendev.org/c/openstack/governance/+/929703 - Add 2025.1 TC chair and vice-chair | https://review.opendev.org/c/openstack/governance/+/930376 - Add chair nomination folder for 2025.1 | https://review.opendev.org/c/openstack/governance/+/929970 - Add GouthamR nomination for 2025.1 TC chair | https://review.opendev.org/c/openstack/governance/+/929971 ==== Open for Review ==== - Appoint Tim Burke as PTL for Swift | https://review.opendev.org/c/openstack/governance/+/928881 - Add Axel Vanzaghi as PTL for Mistral | https://review.opendev.org/c/openstack/governance/+/927962 - Mark kuryr-kubernetes and kuryr-tempest-plugin as Inactive | https://review.opendev.org/c/openstack/governance/+/929698 - Retire kuryr-kubernetes and kuryr-tempest-plugin | https://review.opendev.org/c/openstack/governance/+/922507 === Upcoming Events === - 2024-10-02: OpenInfra Live - Introducing OpenStack Dalmatian 2024.2 [2] - 2024-10-08: OpenInfra Monthly Board Meeting: https://board.openinfra.dev/ - 2024-10-15: OpenInfra Days NA, Indianapolis: https://ittraining.iu.edu/explore-topics/titles/oid-iu/ - 2024-10-21: OpenInfra Project Teams Gathering https://openinfra.dev/ptg/ === How to Contact the TC === You can reach the TC in several ways: 1. Email: send an email with the tag [tc] on this mailing list. 2. Ping us using the 'tc-members' keyword on the #openstack-tc IRC channel. 3. Join us at our weekly meeting: The Technical Committee meets every week on Tuesdays at 1800 UTC [7]. Thank you very much for reading! On behalf of the OpenStack TC, Goutham Pacha Ravi (gouthamr) OpenStack TC Chair [1] 2024.2 "Dalmatian" Release Schedule: https://releases.openstack.org/dalmatian/schedule.html [2] Introducing OpenStack Dalmatian 2024.2: https://openinfra.dev/live/ [3] Goal: migrate CI/CD jobs to Ubuntu Noble: https://review.opendev.org/c/openstack/governance/+/929703 [4] Retire all single charm repositories: https://review.opendev.org/c/openstack/governance/+/903490 [5] 2025.1 "Epoxy" Release Schedule: https://releases.openstack.org/epoxy/schedule.html [6] TC Meeting IRC Log, 2024-09-24: https://meetings.opendev.org/meetings/tc/2024/tc.2024-09-24-17.59.log.html [7] TC Meeting Agenda, 2024-10-01: https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee

1 0

Nova placement
by engineer2024 30 Sep '24

30 Sep '24

Is there a way to get back the correct used resources allocation data, in case of loosing the db ? Does placement update the allocation details after restarting the compute nodes to get the latest resources usage for that node ? Thanks elinux

2 2

[neutron] Proposing Ihar Hrachyshka as neutron stable core reviewer
by Brian Haley 30 Sep '24

30 Sep '24

Hello Neutrinos, I would like to nominate Ihar Hrachyshka for Neutron stable core reviewer (again). Ihar previously led the neutron stable core reviewer team a number of years ago, and I think he'd be a great re-addition to the team. Please vote with a +1/-1. Thanks, -Brian, Neutron PTL

6 6

[kolla] Proposing Matt Crees for Kayobe core
by William Szumski 30 Sep '24

30 Sep '24

Greetings Kayobians, I would like to propose Matt Crees as a core reviewer for Kayobe. With Mark Goddard stepping back from Kayobe maintenance duties, we have a slot to fill in the core team. In my opinion, Matt Crees is the strongest candidate for the position, having provided numerous reviews and contributions over the past few cycles. Please register any objections to this decision before the kolla meeting on 25th of September, otherwise I will proceed with making formal arrangements to get him added. Thanks Will Szumski will(a)stackhpc.com

6 6

[neutron] Bug Deputy report Sep 23 - 29th
by Oleg Bondarev 30 Sep '24

30 Sep '24

Hello Team, Nothing critical this week, 3 High bugs need assignees, 1 RFE to review by Drivers team. Full report for the week of Sep 23 is below: High: - https://bugs.launchpad.net/neutron/+bug/2081868 - LoggingDBApiTestCase.test_get_logs_bound_sg fails - Confirmed - unassigned - https://bugs.launchpad.net/neutron/+bug/2081870 - TestProcessMonitor.test_respawn_handler failed - Confirmed - unassigned - https://bugs.launchpad.net/neutron/+bug/2081871 - TestHAL3Agent.test_ha_router failed - Confirmed - unassigned - https://bugs.launchpad.net/neutron/+bug/2081945 - [postgresql] AttributeError: 'NoneType' object has no attribute 'id' - In progress: https://review.opendev.org/c/openstack/neutron/+/930408 - assigned to Rodolfo Alonso Medium: - https://bugs.launchpad.net/neutron/+bug/2082066 - Logging not supported in unmaintained branches - In progress: https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/930546 - assigned to Rodolfo Alonso - https://bugs.launchpad.net/neutron/+bug/2082070 - [unmaintained] Errors in the "neutron-tempest-plugin-scenario-ovn" job - In progress: https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/930548 - assigned to Rodolfo Alonso - https://bugs.launchpad.net/neutron/+bug/2082344 - [unmaintained] ``NetworkWritableMtuTest`` test don't work in ML2/OVN - In progress: https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/930594 - assigned to Rodolfo Alonso - https://bugs.launchpad.net/neutron/+bug/2082880 - [ovn-octavia-provider] config registration hit DuplicateOptError - In progress: https://review.opendev.org/c/openstack/ovn-octavia-provider/+/930670 - assigned to Rico Lin Low: - https://bugs.launchpad.net/neutron/+bug/2082883 - neutron-tempest-plugin: KeyError caused by missing 'previous' ref Edit - Confirmed - unassigned RFEs: - https://bugs.launchpad.net/ironic/+bug/2081847 - [RFE] Implement a new DHCP backend for Ironic and Neutron Edit - New - unassigned Thanks, Oleg

1 0

[kolla] [kolla-ansible]
by dariusz.bursztynowski＠pw.edu.pl 30 Sep '24

30 Sep '24

Hello, Are there plans for kolla-ansible to support Ubuntu 24.04 / ARM64 (to have LTS support for Raspberry Pi 5)? Best regards, Dariusz Bursztynowski

4 3

[Openstack] [Keystone] [Shibboleth] Assistance with Configuring Multiple IdPs in DevStack with Shibboleth Integration
by Abubakur Sait 29 Sep '24

29 Sep '24

Hi all, I have installed DevStack (release 2023.2) on Ubuntu 22.04 and integrated Shibboleth (the federation solution) with it. Everything works fine for a single IdP. However, I am looking to expand the setup to support multiple IdPs. I have read the Keystone documentation, but it doesn’t seem to cover this specific case. In my current setup, I have DevStack and Shibboleth integrated for a single IdP. I have read the shib-sp documentation as well. It mentions the need for a Discovery Service (DS) if we intend to use multiple IdPs which will be handled by the shib-SP software. This is the issue I am facing right now. Please see the following comments to get my point. Here’s the scenario I have so far: 1. A user accesses Horizon (Service Provider -- SP) at: http://192.168.4.103/dashboard/auth/login/?next=/dashboard/. 2. A drop-down list allows the user to choose the authentication method. The user selects the SAML IdP method. 3. The user is redirected to the IdP’s page where they authenticate. 4. The user is redirected back to the SP and successfully accesses the system. 5. The issue I’m facing is how to configure multiple IdPs so that users can choose from them at step (2). I understand that we can add a list of IdPs in the ~/horizon/openstack_dashboard/local/local_settings.py file to display in Horizon, but this doesn’t fully resolve the issue since the Shibboleth SP application itself doesn’t seem to handle multiple IdPs. Shibboleth SP typically expects a DS for multiple IdPs, but given that we already have a dropdown list in Horizon, do we still need the DS in this case? If not, how can we proceed with adding multiple IdPs in the system? Any guidance or advice would be greatly appreciated. Thank you for your help! Best regards, Bakur Sait

1 0

[octavia] Lose of some jobs by worker
by Payne Max 28 Sep '24

28 Sep '24

Hi, OpenStack community, I’ve faced a problem when some of our jobs can get lost by a worker, for example from the screenshot, SIGTERM was called in several seconds after receiving a job by a worker. [cid:image001.png@01DB1013.D648A630] Then there were no new log messages related to this job. Then our client complained that LB stucked in PENDING_UPDATE for several days and we started investigation. Our MySQL (persistent storage) is clean, but in our Redis, I can see several jobs without TTL and I think they are related to the «lost» jobs. [cid:image002.png@01DB1014.1DFF1BD0] Is it an ok situation? Can it be related to the https://github.com/openstack/octavia/blob/master/octavia/common/base_taskfl… Let’s discuss it!

4 6

kolla-ansible support for Ubuntu 2024.04/ARM64 ?
by dariusz.bursztynowski＠pw.edu.pl 28 Sep '24

28 Sep '24

Hello, Are there plans for kolla-ansible to support Ubuntu 24.04 / ARM64 (e.g., to have LTS support for Raspberry Pi 5)? Best regards, Dariusz Bursztynowski

1 0

[openstack]Problem with launching instances from VMDK
by Nguyễn Hữu Khôi 27 Sep '24

27 Sep '24

Hello I am trying create instance from vmdk but I have this error: The image format was claimed to be 'vmdk' but the image data appears to be in a different format. My cloud is Openstack 2023.1. This happened when We applied patches for CVE-2024-40767. Nguyen Huu Khoi

3 4

[release] Release countdown for week R+0
by Thierry Carrez 27 Sep '24

27 Sep '24

Development Focus ----------------- We will be releasing the coordinated OpenStack 2024.2 Dalmatian release next week, on October 2nd, 2024. Thanks to everyone involved in the Dalmatian cycle! We are now in pre-release freeze, so no new deliverable will be created until final release, unless a release-critical regression is spotted. Otherwise, teams attending the virtual PTG in a few weeks should start to plan what they will be discussing there, by creating and filling team etherpads. You can access the list of PTG etherpads at: https://ptg.opendev.org/etherpads.html General Information ------------------- On release day, the release team will produce final versions of deliverables following the cycle-with-rc release model, by re-tagging the commit used for the last RC. A patch doing just that will be proposed. PTLs and release liaisons should watch for that final release patch from the release team. While not required, we would appreciate having an ack from each team before we approve it on the 2nd, so that their approval is included in the metadata that goes onto the signed tag. Upcoming Deadlines & Dates -------------------------- Final 2024.2 Dalmatian release: October 2nd, 2024 Project Teams Gathering: October 21-25, 2024 -- Thierry Carrez (ttx)

1 0

help
by Gyan Dev Mishra 27 Sep '24

27 Sep '24

hi sir, was facing an issue with launching an instance in OpenStack. When I try to launch an instance using a Ubuntu Server 22.04 ISO image, I am getting the error. Even if I try with the default Cirros image, the instance launches, but when I attempt to access it from the console, I encounter a network error. I was trying to run it using an IP in the 10.x.x range, but it is fetching an IP in the 192.168.x range. I have attached the screenshot for the your reference. How can I resolve this issue? DISCLAIMER: This communication may contain confidential or copyright information. If you are not an intended recipient, you must not keep, forward, copy, use, save or rely on this communication. Any such action is unauthorized and prohibited. If you have received this communication in error please delete it. Reasonable precautions have been taken to ensure no viruses are present in this email, the company cannot accept responsibility for any loss or damage arising from the use of this email or attachments.

1 0

(외부메일) [heat][heat-cinder] How can I use the Cinder volume extend in Heat?
by 박광우 27 Sep '24

27 Sep '24

3 3

[ptl][release] OpenStack Dalmatian OpenInfra Live
by Allison Price 26 Sep '24

26 Sep '24

Hi everyone, I wanted to gather interest from PTLs to participate in an OpenStack Dalmatian OpenInfra Live on Thursday, October 3 after Wednesday’s release. Like past episodes (you can see Caracal here [1]), we will give interested PTLs the opportunity to present the progress their team made in 2024.2 Dalmatian as well as present upcoming priorities for 2025.1 Epoxy. The episode will air on Thursday at 1400 UTC, so interested participants would need to be available 1330-1500 UTC on Thursday, October 3. If you are interested, please let me know. Thanks! Allison [1 ] https://www.youtube.com/watch?v=3BgAXbFaVqw

5 6

Potential Mentorship Opportunities (Jan - May 2025)
by Kendall Nelson 26 Sep '24

26 Sep '24

Hello Party People! It's very early, but I wanted to float the information ahead of time :) Coming up for the next semester (Spring semester in Northern Hemisphere; Jan to May) we have the opportunity to propose projects to students at North Dakota State University to work on. Students will be in the last couple semesters before graduation with a Bachelor's degree in CS. Good projects would be scoped to a small group of students 3-5 working together for around 4.5 months (maybe 4 with onboarding, midterms etc). Mentors on these projects do not have to work alone - often I have two or three community members working together to mentor the students (ask Manila, they are a good example). I will want to start collecting project proposals (and mentor volunteers) in December before everyone leaves for the holidays but that still gives a fair amount of time for questions if anyone has them. I already have one team interested (Hi, Swift!) but would love a couple others to get involved. Let me know what questions you have or if you are interested in mentoring! -Kendall Nelson (diablo_rojo)

1 0