October 2024 - openstack-discuss - lists.openstack.org

Re: [barbican][vault]
by Andy Speagle 29 Oct '24

29 Oct '24

On Thu, 2024-10-24 at 18:06 -0700, melanie witt wrote: > On 10/24/24 16:43, Andy Speagle wrote: > > Hey Folks, > > > > I'm having some trouble getting barbican to generate and/or store > > keys > > in our hashicorp vault in our charmed openstack environment. I have > > issues with both TPM and SSL related keys. > > > > I get extremely generic errors back that I can't seem to figure out > > how > > to troubleshoot: > > > > 'Traceback (most recent call last):\n File "/usr/lib/python3/dist- > > packages/nova/conductor/manager.py", line 688, in build_instances\n > > scheduler_utils.populate_retry(\n File "/usr/lib/python3/dist- > > packages/nova/scheduler/utils.py", line 998, in populate_retry\n > > raise > > exception.MaxRetriesExceeded(reason=msg)\nnova.exception.MaxRetries > > Exce > > eded: Exceeded maximum number of retries. Exceeded max scheduling > > attempts 3 for instance 0c50b2d7-8ac5-41a2-90ab-1e33f7aa1c22. Last > > exception: Key manager error: Internal Server Error: Secret > > creation > > failure seen - please contact site administrator.\n' > > Just FYI this is the generic MaxRetriesExceeded error which means > that > the server action failed on nova-compute(s). So you'll want to look > in > your nova-compute.log for the error that triggered the retries and > eventual MaxRetriesExceeded. > > > I'm using barbican 14.0.2 in yoga/stable ... anyone have an ideas > > how > > to troubleshoot this? > > I'm guessing in nova-compute.log you will see an error 403 forbidden > for > creating a barbican secret. If so, the most common reason I have seen > for this is if you have in your barbican.conf > [oslo.policy]enforce_new_defaults = False, then secret creates > require > the requester to have the 'creator' role assigned to them (you can do > this by 'openstack role add <options> <role>' [1]). > > When [oslo.policy]enforce_new_defaults = True, the 'creator' role is > not > required. Yup... nailed it. I really appreciate the insight. :) > The tl;dr is 'enforce_new_defaults' means to use the newer secure > RBAC > policies and the secure RBAC changes are shown in the Wallaby release > notes:

1 0

[neutron] Moving CI Meeting to Monday 1500 UTC
by Yatin Karel 29 Oct '24

29 Oct '24

Hello Neutron Team !! As discussed/agreed over the last Neutron CI meeting, pushed the changes[1][2] for the new timing. [1] https://review.opendev.org/c/opendev/irc-meetings/+/933637 [2] https://etherpad.opendev.org/p/neutron-ci-meetings -- Thanks and Regards Yatin Karel

1 0

[qa][ptg] QA 2025.1 vPTG Summary
by Martin Kopec 29 Oct '24

29 Oct '24

Hi everyone, here is a summary of the discussions. The full agenda can be found here [1]. == Dalmatian (2024.2) Retrospective == At the beginning of the cycle a devstack optimization change was merged [2] that uses the OSC service. If you haven't already, give it a try and enable it in your jobs. If it doesn't work for your project, let us know. == Migrating upstream CI/CD jobs to Ubuntu Noble (24.04) == Details about the migration can be found in [3] and [4] together with the testing status of all projects. We have time until Nov 29th to test the newer Ubuntu version and deal with any issues, after that, QA would like to proceed with the migration. == Triage previous and write new priority items == The list of the priority items planned for this cycle as well as the ones which were carried over from the previous cycles, can be found here [5]. == Open Discussion == There have been issues with a few jobs and tests that made an assumption of having the amount of certain resources, such as CPUs, guaranteed. However, that's not the case and the amount of the resources is not guaranteed in the upstream CI. No tests or jobs should make this assumption. Apart from CPUs, the same applies on floating ips, public addresses etc. [1] https://etherpad.opendev.org/p/oct2024-ptg-os-qa [2] https://review.opendev.org/c/openstack/devstack/+/676016 [3] https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… [4] https://etherpad.opendev.org/p/migrate-to-noble [5] https://etherpad.opendev.org/p/qa-epoxy-priority Thank you all for attending the PTG and contributing to the discussion, -- Martin Kopec Red Hat EMEA IM: kopecmartin

1 0

[nova][ptg] 2025.1 Epoxy PTG summary
by Sylvain Bauza 29 Oct '24

29 Oct '24

(resending the email as the previous one was blocked to an attached etherpad backup txtfile larger than the max size) Hey all, First, thanks for having joined us if you were in the vPTG. We had 15-20 people every day for our nova sessions, I was definitely happy to see new folks :-) If you want to see our PTG etherpad, please rather look at https://etherpad.opendev.org/p/r.4f297ee4698e02c16c4007f7ee76b7c1 instead of the main nova etherpad as I don't want that the etherpad would have a wrong traduction or having some paragraphs to be removed. As I say every cycle, just take a coffee (or a tea) now as the summary will be large. ### Dalmatian retrospective and Epoxy planning ### 6 of 15 approved blueprints were eventually implemented. We also merged more than 31 bugfixes during Dalmatian. We agreed to be explaining on the IRC channel when we have meetings for discussing some feature series (like the one we did every week for the manila/virtiofs series) and providing some public invitations. We could do this again this cycle for other features, we'll see. We will also try to have a periodic integration-compute job that pulls OSC and SDK from master. Our Epoxy deadlines will be : two spec review days (R-16, R-2), a soft spec approval freeze by R-16 and then hard spec approval freeze by R-12. That means that contributors really need to provide their specs before mid-December. Bauzas (me) will add these deadlines into the Epoxy schedule : https://releases.openstack.org/epoxy/schedule.html ### vTPM live migration ### We agreed on the fact that a vTPM live-migration feature is a priority for Epoxy given Windows 11. artom will create a spec proposing an image metadata property saying 'do I want to share my secret with nova service user ?' and also providing a new `nova-manage image_property set migratable_something` command so operators could migrate the existing instances for getting the Barbican secrets, if really the operators wants. ### Unified limits wrap-up ### We already have two changes needing to be merged before we can modify the default quota driver (in order to default to use unified limits). We agreed on reviewing both patches (one for treating unset limits as unlimited, the other about adding a nova-manage command for automatically creating nova limits) but we also discussed about a latter patch that would eventually say which nova resources need to be eventually set (so we *have to* enforce them anyway). melwitt agreed on working on that latter patch. ### per-process health checks ### We already had one series and we discussed it again. Gibi agreed on taking over it and he will re-propose the existing spec as it is. We also discussed the first checks we would have, like RPC failures and DB connection issues, we'll review those when they are in Gerrit. ### sustainable computing (a.k.a. power mgmt) ### When someone (I won't say who [1]) implemented power management in Antelope, this was nice but we eventually found a long list of bugs that we fixed. Since we don't really want to reproduce that experience, we had this kind of post-mortem where we eventually agreed on two things that could avoid reproducing that problem : a weekly periodic job will run whitebox tempest plugins [2] with nova-compute restarts also covered by a whitebox tempest plugin. Nobody is committed against those two actions but we hope to identify someone soon. As a side note, gibi mentioned RAPL MSR support [3], notifying us that we would have to support that in a later release (as the libvirt implementation is not merged yet) ### nvidia's vGPU vfio-pci variant driver support ### Long story short, since the linux kernel removed some feature in release 5.18 (IOMMU backend support for vfio-mdev) this impacted the nvidia driver which now detects that and then creates vfio-pci devices instead of vfio-mdev devices (as vGPUs). This has a dramatic impact on Nova as we relied on the vfio-mdev framework for abstracting virtual GPUs. By the next release, Nova will need to inventorize the GPUs by rather looking at SRIOV virtual functions which are specific to the nvidia driver (we call them vfio-pci variant driver resources). The nova PTG session focused on the required efforts to do so. We agreed on the fact it will require operators to propose different flavors for vGPU where they would require distinct resource classes (all but VGPU). Fortunately, we'll reuse existing device_spec PCI config options [4] where the operator would define custom resource classes which would match the PCI addresses of the nvidia-generated virtual functions (don't freak out, we'll also write documentation). We'll create another device type (something like type-VF-migratable) for describing such specific nvidia VFs. Accordingly the generated domain XML will correctly write the device description (amending the "managed=no" flag for that device). There will be an upgrade impact: existing instances will need to be resized to that new flavor (or instances will need to be shelved, updated for changing the embedded flavor and unshelved). In order to be on par with existing vGPU features, we'll also need to implement vfio-pci live-migration by detecting the VF type on the existing SRIOV live-migration. Since that effort is quite large, bauzas will incept a subteam of interested parties that would help him implement all of those bits in the short timeframe that is one upstream cycle. ### Graceful shutdowns ### A common pitfall that was told by tobian-urdin is when you want to stop nova-compute services. In general, before stopping the service, we should be sure that all RPC calls are done, which means we would no longer accept RPC calls after asking to stop the nova-compute and just awaiting the current calls to be done before stopping the service. For that, we need to create a backlog spec for discussing that design and we would also need to modify oslo.service for unsubscribing the RPC topics. Unfortunately, this cycle we won't have any contributor for working on it, but gibi could try to at least document this. ### horizon-nova x-p session ### We mostly discussed the Horizon feature gaps [5]. The first priority would be Horizon to use OpenStackSDK instead of novaclient, but then supporting all of the new Nova API microversions. Unfortunately, we are no sure that we could have Horizon contributors that could fix those, but if you're a contributor and you want to help Horizon to be better, maybe you could do this ? If so, please ping me. ### Ironic-nova x-p session ### We didn't really have topics for this x-p session. We just quickly discussed some points, like Graphical Console support. Nothing really worth noting, maybe just that it would be nice that we could have readonly graphical console. We were just happy to say that the ironic driver now works better thanks to some features that were merged last cycles. Kudos to those who did them. ### HPC/AI optimized hypervisor "slices" ### A large topic to explain, I'll try to keep it short. Basically, how Nova slices the NUMA affinity between guests is nice but hard for HPC usecases where sometimes you need to better explain how to slice the NUMA dependent devices depending on the various PCI topologies. Eventually, we agreed on some POC that johnthetubaguy could work on by trying to implement a specific virt driver that would do something different from the existing NUMA affinities. ### Cinder-nova x-p session ### Multiple topics were discussed there. First, abishop wanted to enhance cinder's retyping of in-use boot volumes which means that the Nova os-attachments API to get a new parameter. We said that he needs to create a new spec and we agreed on the fact that the cinder contributors need to discuss with QEMU folks to know about the qemu writes. We also discussed about a new nova spec which is about adding burst length support to Cinder QoS [6]. We said that we need to both (nova and cinder) review this spec. About left residues when detaching a volume, we also agreed on the fact this is not a security flaw and the fact that os-brick should delete them, not nova (even if nova need to ask os-brick to look at that, either by a periodic run or when attaching/detaching). whoami-rajat will provide a spec for it. ### Python 3.13 support ### We discussed a specific issue for py3.13, the fact that the crypt module is no longer in stlib for py3.13, which impacts nova due to some usage in nova.virt.disk.api module for passing an admin password for file injection. Given file injection is deprecated, we have three possibilities: either removing admin password file injection (or even file injection as a whole), adding the new separate crypt package in upper-constraints or using oslo_uitls.secretutils module. bauzas (me) will provide an email to openstack-discuss for asking operators whether they are OK with deprecating file injection or just admin password injection and then we'll see the direction. bauzas or sean-k-mooney will also try to have py3.13 non-voting jobs for unittests/functtests. ### Eventlet removal steps in Nova ### I won't explain why we need to remove eventlet, you already know, right ? We rather discussed about the details in our nova components, including nova-api, nova-compute and other nova services. We agreed on removing direct eventlet imports where possible, move nova entrypoints that don't use eventlet to separate modules that don't monkeypatch the stdlib, look at what we can do with all our scatter_gather methods which asynchronously calling cells DB for using threads instead and check whether those calls are blocking on DB (and not on the MQ side). Gibi will shepherd that effort and provide some audit on the eventlet usage in order to avoid any unexpected but unfortunate late discoveries. ### Libvirt image backend refactor ### If you like spaghettis, you should pay attention to the libvirt image backend code. Lots of assumptions and conditionals make any change to that module hard to be written and hard to be reviewed, leading to errorprone situations like the ones we had when fixing some recent CVEs. We all agreed on the quite urgent necessity to refactor that code and melwitt proposed a multi-stage effort about that. We agreed on the proposal for the first two steps with some comments, leading to future revisions of the proposal's patches. The crucial bits with the refactor are about test coverage. ### IOThreads tuning for libvirt instances ### An old spec was already proposed for defining iothreads to guests. We agreed on reviving that spec, where a config option would define either no iothread or one iothread per instance (with a potential for a latter option value to be "one iothread per disk"). Depending on whether emulator_thread_policy is provided in the flavor/image, we would set the iothread on that policy or we would put the iothread floating over the shared CPU set. If no shared CPUs are configured but the operator wants iothreads, nova-compute would refuse to start. lajoskatona will work on such an implementation that will be designed in a blueprint that doesn't require a spec. ### OpenAPI schemas progress ### Nothing specific to say here, bauzas and gmann will review the series this cycle. That's it. I'm gone, I'm dead [7] (a cyclist metaphor) but I eventually skimmed the very large nova etherpad. Of course, 99% of chances that I'll write some notes incorrectly, so please correct if I'm wrong, I won't feel offended, just tired. Thanks all (and I hope your coffee or tea was good) -Sylvain [1] https://geek-and-poke.com/geekandpoke/2013/11/24/simply-explained [2] https://opendev.org/openstack/whitebox-tempest-plugin [3] https://www.qemu.org/docs/master/specs/rapl-msr.html [4] https://docs.openstack.org/nova/latest/configuration/config.html#pci.device… [5] https://etherpad.opendev.org/p/horizon-feature-gap#L69 [6] https://review.opendev.org/c/openstack/nova-specs/+/932653 [7] https://www.youtube.com/watch?v=HILcYXf8yqc

1 0

[neutron] How to disable Floating IP?
by yardalgedal＠gmail.com 28 Oct '24

28 Oct '24

Hi, Openstack Team, Is there a way how to temporarily disable floating ip? Like we have admin_state_up for many resources, but we don't have it for floating ip. admin_state_up of floating_port_id not working in Wallaby and I'm not sure it's working in later releases.

2 1

[tc][all] OpenStack Technical Committee Weekly Meeting Agenda (2025.1/R-22)
by Goutham Pacha Ravi 28 Oct '24

28 Oct '24

Hello Stackers, As you're aware, we concluded the virtual Project Teams Gathering event last week. This week, we’ll start addressing the to-do lists we created. The Technical Committee met for six hours, in addition to participating in several discussions with various project teams. I’m working on sharing a summary of the week’s proceedings with you via this mailing list. In the meantime, we’ll be catching up on 2024-10-29 at the TC’s weekly IRC meeting in OFTC’s #openstack-tc channel. The agenda for this meeting is available on the Meeting Wiki [1]. I hope you’ll be able to join us. === Governance Proposals === ==== Merged ==== - Retire kuryr-kubernetes and kuryr-tempest-plugin | https://review.opendev.org/c/openstack/governance/+/922507 - Propose a pop-up team for eventlet-removal | https://review.opendev.org/c/openstack/governance/+/931978 ==== Open for Review ==== - Add Cinder Huawei charm | https://review.opendev.org/c/openstack/governance/+/867588 - Add watcher DPL for Epoxy | https://review.opendev.org/c/openstack/governance/+/933018 - Add Axel Vanzaghi as PTL for Mistral | https://review.opendev.org/c/openstack/governance/+/927962 - Propose to select the eventlet-removal community goal | https://review.opendev.org/c/openstack/governance/+/931254 Thank you very much for reading! On behalf of the OpenStack TC, Goutham Pacha Ravi (gouthamr) OpenStack TC Chair P.S: OpenStack TC PTG YouTube Playlist is shaping up here [2]. Please feel free to browse through [1] TC Meeting Agenda, 2024-10-29: https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting [2] https://youtube.com/playlist?list=PLhwOhbQKWT7XGjIwT0mtPpixpuY-tKYoh&featur…

1 0

[glance] Hold your rechecks
by Abhishek Kekane 28 Oct '24

28 Oct '24

Hi Team, Currently glance gate is failing for glance-cinder-multistore-import job with quota exceeding issue. The quota issue seems to be occurring from a recent change in devstack (removing volumev3 endpoint) causing issues with openstack client commands (set quotas). The details of the issue and fix are in this release patch https://review.opendev.org/c/openstack/releases/+/933578 Until this release patch is merged, kindly avoid posting recheck on your patch. Thanks & Best Regards, Abhishek Kekane

1 1

[Neutron] Bug Deputy Oct 21 - 27
by Miro Tomaska 28 Oct '24

28 Oct '24

Hello All, Here is the report for the week from Oct 21 - 27. We had a busy week. *Critical:* https://bugs.launchpad.net/neutron/+bug/2085462 - [OVN] "test_trunk_subport_lifecycle" unstable Assigned: Rodolfo Alonso https://bugs.launchpad.net/neutron/+bug/2085543 - [OVN] Port device_owner is not set in the Trunk subport Assigned: Yatin Karel *High*: https://bugs.launchpad.net/neutron/+bug/2084977 - Deleting a security group fails "cannot find port_group" Unassigned https://bugs.launchpad.net/neutron/+bug/2085422 - [OVN] "test_overlapping_sec_grp_rules" is unstable Unassigned https://bugs.launchpad.net/neutron/+bug/2084977 - Deleting a security group fails with "Cannot find Port_Group with name=pg_<id>" when neutron-api is run by httpd + mod_wsgi Assigned: Terry Willson https://bugs.launchpad.net/neutron/+bug/2085422 - test_overlapping_sec_grp_rules" is unstable Unassigned *Medium*: https://bugs.launchpad.net/neutron/+bug/2085491 - How to run neutron fwaasV2 ovn driver Unassigned *Low*: https://bugs.launchpad.net/neutron/+bug/2085099 -[OVN] E/W traffic fragmentation for routed traffic Assigned: Rodolfo Alonso https://bugs.launchpad.net/neutron/+bug/2085447 - Fast exit ``_ensure_external_network_default_value_callback`` if network not external Assigned to Rodolfo Alonso *Undecided:* https://bugs.launchpad.net/neutron/+bug/2085421 - Tempest failing at teardown -- Miro Tomaska Senior Software Engineer

1 0

#eventlet-removal - PTG October 2024 Summary
by Herve Beraud 28 Oct '24

28 Oct '24

Last week was the OpenStack PTG. The Eventlet removal initiative ran two PTG sessions. The first session [1] was a presentation of the initiative, where the second session [2] was a technical open discussion. Please find out below the main key points and the proposed answers. ## Key Points The first key point made during these PTG sessions is that without consistency in our choices and decisions we will create more complexity than anything else. It is crucial to avoid having multiple ways to start services across different projects. A unified approach will simplify maintenance and enhance user experience. Leading us to the following questions: - how to remove the WSGI features provided by Eventlet and how to move to another HTTP server (WSGI/ASGI); - how to manage tasks. The WSGI/HTTP server discussion just come in time with the proposal made by Stephen Finucane to Deprecate/remove non-uWSGI deployment mechanisms from Devstack: https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… We think that this topic overlaps with the WSGI aspects of Eventlet removal, for this reason, with the aim to answer these questions we propose to create specialized working groups (see the section below). We also made comparisons between available alternatives, here is an example with the SGI question https://wiki.openstack.org/wiki/SGI-servers-comparison. Find out all our comparisons in the official wiki page: https://wiki.openstack.org/wiki/Eventlet-removal#The_HTTP_SGI_Working_Group ## Specialized working groups The main role of these working groups is to avoid having multiple ways to manage things. Groups would be responsible for producing a unified approach that will simplify maintenance and enhance user experience. Our discussions have brought out 3 specialized working groups: - The HTTP SGI Working Group - The Tasks/Process Working Group - The Architecture, Interoperability and Technical Standardization Working Group If you are interested in one or many of these specialized working groups, then, please raise your hand and join the discussions. Please also take a look to the official page: https://wiki.openstack.org/wiki/Eventlet-removal#Specialized_Working_Groups… ## Latest Updates - Glance took full advantage of the PTG discussion. They got an overview of their WSGI migration options and they gain a better understanding of their current situation (https://etherpad.opendev.org/p/oct2024-ptg-glance#L277) and the Glance team were able to set up a migration plan: https://etherpad.opendev.org/p/oct2024-ptg-glance#L340 - Ironic Python Agent (IPA), is also experimenting about their Eventlet removal, their works is strongly related to the WSGI feature replacement: https://review.opendev.org/c/openstack/ironic-python-agent/+/924634 - The threading executor of oslo.messaging could shorten our migration path concerning the RPC aspects. For this reason we proposed to start the deprecation of the Eventlet executor within oslo.messaging. https://review.opendev.org/c/openstack/oslo.messaging/+/933399 - Another topic that arose during the PTG is how to manage timeouts. Some proposal have been made, they propose to rely on SQLAlchemy or Ceph to handle timeout management: https://etherpad.opendev.org/p/oct2024-ptg-eventlet-removal#L103 https://etherpad.opendev.org/p/oct2024-ptg-os-tc#L298 ## Important Dates Nov. 5th is the first IRC meeting on #openstack-eventlet-removal, do not hesitate to join us. We will cover all the topics addressed in this mailing thread. ## SLURP vs non-SLURP The PTG sessions came with timeline and cadence discussions. For this reason we made some proposal about workload regulation: https://wiki.openstack.org/wiki/Eventlet-removal#Workload_regulation_2 In substance we propose to base our cadence on SLURP and non-SLURP releases. Epoxy is a SLURP release, for this reason we should not expect breaking changes happening during this series, however, SLURP series are good opportunities to deprecate things, remove useless workaround, and start small clean up in preparation of wider changes. ## Final Thoughts We strongly encourage a collaborative selection of our candidate(s) for HTTP server replacement .This selection will dictate how we deal with server gateway interfaces for the coming decade, so we should focus our coming discussion on this specification, for this reason we invite you to join the specialized working groups. Thanks to all the people who joined the various discussions. Thank you for your dedication and hard work! [1] https://etherpad.opendev.org/p/oct2024-ptg-os-tc#L195 [2] https://etherpad.opendev.org/p/oct2024-ptg-eventlet-removal -- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/

1 0

[FOSDEM] Call for participation: Virtualization and Cloud infrastructure Room at FOSDEM 2025
by Piotr Kliczewski 28 Oct '24

28 Oct '24

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

1 0

[neutron][ironic] Network VLAN ranges discussion during the PTG
by Rodolfo Alonso Hernandez 28 Oct '24

28 Oct '24

Hello all: During the PTG it was discussed how to handle the static configuration of the allowed VNI ranges for a network type. In particular it was discussed the VLAN ID ranges, that has the particularity of being defined by a physical network (unlike the tunnelled protocols that have a set of ranges but without any network association). During the PTG it was mentioned the possibility of creating an API to handle the VLAN network ranges. After a quick talk with Slawek, he pointed me to the network segment ranges API [1]. This API allows the creation of new segment ranges not configured in the static "ml2_type_vlan.network_vlan_ranges" configuration variable (again, I'm focusing only on the VLAN type network). It is possible, for example, not to define any range statically and then create, per physical network, a set of allowed ranges. Some considerations: * The configured value in "ml2_type_vlan.network_vlan_ranges" (static configuration) will be read during the Neutron API start process and will create a "default" network segment range register. This register is immutable and cannot be modified nor deleted. * Each network segment range will have a "used" reference, that is the number of VLAN IDs assigned in this range. If there is one single network with a VLAN ID on this range, it won't be possible to update or delete this network segment range register. * These ranges apply to the auto allocation functionality. If an admin (that is by default an admin privilege configured in the policies) creates a network with a defined VLAN outside any set of ranges, that will be allowed. I hope that will help you. And if you have a proposal to upgrade the current API, that will be welcome. Regards. [1] https://docs.openstack.org/neutron/latest/admin/config-network-segment-rang…

1 0

[glance] Epoxy PTG summary
by Abhishek Kekane 28 Oct '24

28 Oct '24

Hi Team, We had our Epoxy virtual PTG between 21st to 25th October 2024. Thanks to everyone who joined the virtual PTG sessions. Using gmeet we had lots of discussion around different topics for glance, glance + cinder, eventlet removal etc. You can find the topics discussed in etherpad [1] with Notes from the session and which also includes the recordings of each discussion. Here I am going to highlight a few important topics which we are going to target this cycle. # Property protection Access to extra properties through Glance’s public API calls may be restricted to certain sets of users, using a property protections configuration file. It can be either role based protection or policy based protection. During this session we have decided to conduct a survey to verify who is using this feature, whether they are using role based or policy based protection. Can we remove either of the protection and do the refactoring? If not then glance will update the documentation for property protection to include reserved properties. Recording: https://drive.google.com/file/d/1WrhkM2dVk6E8KQVDJCt1Bc2aaHi-txGJ/view?usp=… # Periodic job for cache-cleaner and cache-pruner At the moment we have command line utilities to perform these jobs which need to be configured as cron jobs. If we move this under service as a periodic job we can eliminate maintenance of these command line tools and avoid external configuration processes. In this session we decided to introduce two new admin only API calls which will help to clean the cached images. This will help to have an easier deployment process. Recording: https://drive.google.com/file/d/1pmYmVD72zl97gdXRWegYZskDvP50wi6E/view?usp=… # New API to list cached images on all glance nodes As we now have a centralized database as one of the cache drivers, we can now have an api to list images cached on different nodes to give end user overall view of the cache. The actual plan was to list all images cached across the nodes but during the session we found that it is better to get a picture of a single image cached on the nodes. Here we will add a new API call (admin only?) which will accept image id as an input and return the node details where the said image is cached. Recording: https://drive.google.com/file/d/1fv0tBEWbtHcKKfMVLVwc8lPHwN5OM3uh/view?usp=… # Distributed image download if filesystem is enabled We already use distributed imports to avoid configuring shared staging areas across glance nodes, similarly we can use this mechanism to download the image if the filesystem driver is used and the operator wants to avoid configuring shared filesystem in case we have more than one glance node. We have decided to introduce a new configuration option `distributed_download_strategy` with options `None,proxy,redirect`. If it is None then we will return a 404 File Not Found error to the user. If it is a proxy then we will proxy the request to the node where image data is actually present. If it is redirect then we will return a fully accessible image url to the user which he can use to issue a new download request. Recording: https://drive.google.com/file/d/1W5mwifcEfne5HJfNRJ84EyuYGc7NCDJK/view?usp=… # Remove deprecated features/options * sqlite cache driver - Remove in F cycle * Glance scrubber - Remove in Epoxy * Windows support - Sync with gmann to check whether we should remove it now or follow deprecation process of 2 cycles * glance-cache-prefetcher, glance-cache-cleaner, glance-cache-pruner - Deprecate these in Epoxy and remove those in G cycle Recording: https://drive.google.com/file/d/1DFmpy6JRIZw9OTPaw19FD4bW7SR36iNF/view?usp=… # Deprecating python-glanceclient We need to merge pending patches in OSC on priority basis. We will be announcing the deprecation of glance client on openstack mailing list which will help stakeholders to plan OSC migration in next two cycles. Plan is to deprecate the shell in Epoxy with a deprecation warning to each command and then remove the glance client in G cycle. Recording: https://drive.google.com/file/d/1gL6oEpoRL1igjervLFLkNE6eHVWJp3A2/view?usp=… # Horizon Feature Gaps - Cross project session with Horizon team Horizon team is stepping up to provide user interface for new features introduced in glance. You can find the details about it in etherpad [2]. Glance team will help them to migrate from glance-client to OSC and verify and review new user interface. Recording: https://drive.google.com/file/d/12AeTnaQytUhG_tHWN06G78kFYg2YuSGl/view?usp=… # S3 support In this session we have discussed the feature gaps in S3 and other backends of glance. Plan is to find out how we can configure S3 store using swift or ceph and then add a CI job upstream to find out if there are any failures in current supported features. Recording: https://drive.google.com/file/d/1MKEGh7qR9HgCnlhsa4MDjH6Rpl0OaUXe/view?usp=… # Add Glance as first-line defense for image format attacks Here we want glance to act as primary defender for any kind of security vulnerability. You can find the initial idea about it in glance spec [3]. In this session we discussed; * adding new disk-format `gpt` * leaves raw as unstructured data which will be rejected by nova to boot from it. * Migration of existing images from raw to gpt * LUKS inspector (see image encryption session for more details) * Impact on image conversion plugin if gpt disk-format is added Recording: https://drive.google.com/file/d/1xWM7IMCuZ_UenlMUd_rh1KmeuLY6bzSS/view?usp=… # Image Encryption(cross project session with cinder and nova) Here we have discussed the changes in current proposed design with CVE-2024-32498 and how to inspect an image if it is encrypted. Plan is to re-propose the spec with current changes like; * Keep the qcow format as it is and discover the encrypted qcow through metadata (encryption_key_id) * Introduce LUKS as new disk-format Recording: To be updated* # New Location APIs Adoption in Nova and Cinder As Image encryption cross project session took much of the time, we have decided to discuss this topic in the following weekly meeting. Plan is to make nova and cinder use this new location API call so that we can get rid of split deployment (glance internal vs glance external) in this cycle. # Eventlet removal It is a community goal to remove eventlet from OpenStack by 2027.2 (see https://governance.openstack.org/tc/goals/proposed/remove-eventlet.html) Eventlet is causing issues with every new CPython release (at the time of writing, tests are hanging on CPython 3.13). This is a SLURP release so we cannot have "big" changes, but: * we can get "easy" fixes out of the way * we should start working on this so we can merge patches right at the start of the F cycle Glance planning for eventlet removal: * WSGI server Make sure all jobs are running on uwsgi Deprecate/disable the wsgi eventlet server Remove it in 3/4 cycles * Plan for epoxy cycle Deprecate eventlet/wsgi related config option Devstack to by default configure uwsgi Migrate jobs to use uwsgi Migrate from eventlet threadpool to native or io thread pool * Plan for F cycle Fix any issues if occurs for uwsgi * Plan for G cycle Remove wsgi functionality Recording: https://drive.google.com/file/d/1J5nYOCwp2MrrFZAIIvg1YGH4UnaVpk6s/view?usp=… Apart from above topics you can find other miscellaneous topics discussed in PTG etherpad [1]. If you have any questions/suggestions then please join us in our weekly meeting (each Thursday #openstack-meeting irc channel at 1400 UTC). *PS: Since Image encryption was a cross-project session with cinder and nova, once cinder publishes recordings I will update it here on thread. [1] https://etherpad.opendev.org/p/oct2024-ptg-glance [2] https://etherpad.opendev.org/p/horizon-feature-gap [3] https://review.opendev.org/c/openstack/glance-specs/+/925111 Thanks and Regards, Abhishek Kekane

1 0

[tacker] Cancelling weekly IRC meeting
by Yasufumi Ogawa 27 Oct '24

27 Oct '24

Hi tacker team, Thank you for joining the vPTG last week. Since I'm not available in the afternoon tomorrow, so going to cancel the meeting. Thanks, Yasufumi

1 0

Request for Scientific Resources on OpenStack Cost Efficiency Compared to Public Cloud Providers
by HAMMOUMI TARIK 27 Oct '24

27 Oct '24

Dear OpenStack Community, I am currently working on a case study as part of my software engineering course, where I aim to examine the cost efficiency of OpenStack as a private infrastructure solution in comparison to public cloud services such as AWS, Google Cloud, and Azure. My goal is to determine whether OpenStack can be more cost-effective in the long term, particularly for organizations that rely heavily on sustained workloads. In my initial research, I encountered challenges finding scientific studies or published articles that provide a clear, data-driven comparison between the Total Cost of Ownership (TCO) of OpenStack and that of leading public cloud providers. During a recent discussion with my professor, they emphasized the importance of using concrete, peer-reviewed sources and precise financial comparisons to validate claims about cost savings or trade-offs between owning physical resources and cloud-based infrastructure. I would appreciate it if anyone could point me to peer-reviewed research, published case studies, or white papers that analyze OpenStack’s TCO, especially in comparison to major public cloud providers. Insights on maintenance and operational costs for OpenStack in practical, high-utilization scenarios would be particularly helpful. Thank you in advance for any assistance or direction on reliable resources. I look forward to contributing to this ongoing discussion and hopefully sharing insights from my findings with the community. Best regards, Tarik HAMMOUMI (https://itstarik.tech)

1 0

The CFP for OpenInfra Days North America 2025 closes in ONE WEEK!
by Helena Spease 25 Oct '24

25 Oct '24

Hi everyone, OpenInfra Days North America[1] is returning in March 2025 and will be co-located with SCaLE in Pasadena, CA! SCaLE takes place March 6-9, 2025. OpenInfra Days North America will take place 2 days during that timeframe, but the exact timing has not been determined. The CFP[2] for OpenInfra Days North America 2025 is currently open until NOVEMBER 1, 2024! OpenInfra Days North America is being jointly organized by the OpenInfra communities from the United States, Mexico, and Canada. We are looking for sessions that will cover open-source projects used to build data center infrastructure including OpenStack, Kubernetes, Linux, Kata Containers, StarlingX, Ceph, and many more! A few hot topics we would love to hear about include: - VMWare Migration to OpenStack - OpenStack and Kubernetes - AI and HPC workloads - Zuul CI - Baremetal & Ironic - OpenStack 2024.2, Dalmatian - OpenStack upgrade/SLURP demos - OpenStack cost/labor savings - Government and healthcare compliance stories Registration[3] and sponsorship[4] opportunities are also now available! If you have any questions about the event, please feel free to let me know. Cheers, Helena helena(a)openinfra.dev Community Programs Coordinator The OpenInfra Foundation [1] https://www.socallinuxexpo.org/scale/22x/events/open-infra-days [2] https://www.socallinuxexpo.org/scale/22x/call-presenters [3] https://register.socallinuxexpo.org/reg6/ [4] https://openinfra.dev/events/sponsorship#OIDNA

1 0

[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

[i18n] i18n SIG PTG Schedule & Key Topics for Discussion
by Seongsoo Cho 24 Oct '24

24 Oct '24

Hi i18n SIG Team I’m pleased to announce the i18n SIG schedule for the upcoming PTG. Here are the details: Dates: • October 23rd: 13:00 - 15:00 UTC • October 24th: 13:00 - 15:00 UTC We encourage you to check the meeting minutes and contribute to the discussion by accessing the following Etherpad: https://etherpad.opendev.org/p/oct2024-ptg-i18n Key Discussion Topics: 1. Weblate Migration: We will discuss the progress and steps needed for migrating to Weblate. 2. Enhancing Translation Engagement: We’ll focus on strategies to improve the engagement and translation rates for OpenStack projects. Potential ideas, such as incorporating LLM (Large Language Models), will also be explored. We look forward to your participation and contributions to these discussions. Best Regards Seongsoo -- Seongsoo Cho OpenStack Korea User Group / Community Leader IRC #seongsoocho

2 2

[barbican][vault]
by Andy Speagle 24 Oct '24

24 Oct '24

Hey Folks, I'm having some trouble getting barbican to generate and/or store keys in our hashicorp vault in our charmed openstack environment. I have issues with both TPM and SSL related keys. I get extremely generic errors back that I can't seem to figure out how to troubleshoot: 'Traceback (most recent call last):\n File "/usr/lib/python3/dist- packages/nova/conductor/manager.py", line 688, in build_instances\n scheduler_utils.populate_retry(\n File "/usr/lib/python3/dist- packages/nova/scheduler/utils.py", line 998, in populate_retry\n raise exception.MaxRetriesExceeded(reason=msg)\nnova.exception.MaxRetriesExce eded: Exceeded maximum number of retries. Exceeded max scheduling attempts 3 for instance 0c50b2d7-8ac5-41a2-90ab-1e33f7aa1c22. Last exception: Key manager error: Internal Server Error: Secret creation failure seen - please contact site administrator.\n' I'm using barbican 14.0.2 in yoga/stable ... anyone have an ideas how to troubleshoot this? -- Andy Speagle

2 1

[cloudkitty] 2025.01 PTG summary
by Rafael Weingärtner 23 Oct '24

23 Oct '24

Dear all, The CloudKitty project had a great PTG meeting [1]. Thanks to the OpenInfra Foundation for holding it. Also, thanks to all who have dedicated precious time to attend. We started the meeting by revisiting the latest release and discussing the review format we have adopted in the past years. Looking at the result of our process, we decided to maintain it, as it seems to bring results, and concentrate our efforts on getting CloudKitty better and evolving over time. Furthermore, as the current CloudKitty team is a bit small, we have decided to focus on the following topics for the next cycle. - State of Elasticsearch - We want to make sure the CloudKitty CI tests Elasticsearch v8, driver was last tested on v6/7. - OpenSearch/Elasticsearch datastreams -- It looks like this feature is present in both OpenSearch and Elasticsearch. Therefore, we will make an effort to concentrate on these two drivers, instead of replicating their codebase, and separate between them just the differences. - Epoxy (2025.1) supported runtimes -- we will drop the unsupported Python releases/versions. - oslo.policy RBAC new defaults -- We will need to address these new supports in the upcoming release. - Horizon dashboard improvements -- Borrow ideas from Catnip? https://github.com/ObjectifLibre/catnip, and maybe discuss with other agents from the community. In summary that is the outcome of our small, but efficient PTG meeting. Let's keep improving and making CloudKitty better. If I missed something, please do not hesitate to reply back. Also, if somebody needs any help, you can always ping me :) See you guys. Have a nice week! [1] https://etherpad.opendev.org/p/oct2024-ptg-cloudkitty -- Rafael Weingärtner

1 0

Openstack haproxy customization
by Gaurav Sharma 23 Oct '24

23 Oct '24

I have deployed openstack multinode using kolla-ansible ,you know when we run deploy command then haproxy configuration generated by default, now i want to customize the by default configuration by custom file(if create). Please provide better steps to customize haproxy. i have tried many steps but did't get success, one thing i have docker not systemctl .

1 0

[ironic] Core team split into reviewers/approvers
by Jay Faulkner 23 Oct '24

23 Oct '24

OpenStack & Ironic community, Ironic has not added a core reviewer in years. We've had new contributors during this time, but none who has, as yet, risen to the level of being given core review access -- which reflects how steep the learning/responsibility curve is to being a core on an OpenStack project. I'd like to propose, on behalf of many Ironic cores and our PTL Riccardo, a new core review structure for Ironic projects. The goal being to provide an on-ramp for newer cores into the community. The existing ironic-core group will be removed and replaced with two new groups: - ironic-reviewers will contain contributors permitted to perform core reviews (+2/-2) against patches in ironic projects. This group will be initially populated with two new code reviewers (should they accept), CID and cardoe. - ironic-approvers will contain contributors permitted to both perform core reviews and workflow (+A) patchsets. This group will be initially populated with the existing membership of ironic-core. I hope that by providing a middle point on the route to being an approver, we'll be able to extend trust to new contributors more quickly and give them incentive to code review more often -- since their reviews will be able to have a positive impact on landing code more quickly. I've proposed a change here: https://review.opendev.org/c/openstack/project-config/+/931991which makes the first step in adjusting ACLs to split the groups. I've also as part of this change unified more ironic-related projects under the ironic core review banner after auditing those core groups and seeing some inactive contributors in them. Ironic cores have already discussed this privately, and we have a lazy consensus to perform this change. This email serves as both notice to the larger community and as a formal way to gain consensus. If there are any questions or concerns please let us know. Thanks, Jay Faulkner

8 12

[kolla-ansible][haproxy][2024.1] HAProxy template error
by Satish Patel 22 Oct '24

22 Oct '24

I am deploying kolla-ansible latest release 2024.1 on Ubuntu 22.04 and getting strange error at following task When I am running kolla-ansible -i multinode deploy TASK [include_role : glance] ***************************************************************************************************************************************************************** task path: /usr/local/share/kolla-ansible/ansible/site.yml:168 redirecting (type: modules) ansible.builtin.firewalld to ansible.posix.firewalld TASK [haproxy-config : Copying over glance haproxy config] *********************************************************************************************************************************** task path: /usr/local/share/kolla-ansible/ansible/roles/haproxy-config/tasks/main.yml:2 The full traceback is: Traceback (most recent call last): File "/usr/local/lib/python3.10/dist-packages/ansible/plugins/action/template.py", line 152, in run resultant = templar.do_template(template_data, preserve_trailing_newlines=True, escape_backslashes=False, overrides=overrides) File "/usr/local/lib/python3.10/dist-packages/ansible/template/__init__.py", line 1010, in do_template res = myenv.concat(rf) File "/usr/local/lib/python3.10/dist-packages/ansible/template/native_helpers.py", line 83, in ansible_concat return ''.join([to_text(v) for v in nodes]) File "/usr/local/lib/python3.10/dist-packages/ansible/template/native_helpers.py", line 83, in <listcomp> return ''.join([to_text(v) for v in nodes]) File "<template>", line 436, in root File "/usr/local/lib/python3.10/dist-packages/ansible/template/__init__.py", line 381, in call return super().call(obj, *args, **kwargs) File "/usr/local/lib/python3.10/dist-packages/jinja2/runtime.py", line 303, in call return __obj(*args, **kwargs) File "/usr/local/lib/python3.10/dist-packages/jinja2/runtime.py", line 768, in __call__ return self._invoke(arguments, autoescape) File "/usr/local/lib/python3.10/dist-packages/jinja2/runtime.py", line 782, in _invoke rv = self._func(*arguments) File "<template>", line 193, in macro File "/usr/local/lib/python3.10/dist-packages/ansible/template/__init__.py", line 295, in wrapper ret = func(*args, **kwargs) File "/usr/local/lib/python3.10/dist-packages/jinja2/filters.py", line 1030, in do_format return soft_str(value) % (kwargs or args) File "/usr/local/lib/python3.10/dist-packages/markupsafe/__init__.py", line 165, in __mod__ return self.__class__(super().__mod__(value)) File "/usr/local/lib/python3.10/dist-packages/markupsafe/__init__.py", line 370, in __str__ return str(self.escape(self.obj)) File "/usr/local/lib/python3.10/dist-packages/markupsafe/__init__.py", line 235, in escape rv = escape(s) File "/usr/local/lib/python3.10/dist-packages/markupsafe/__init__.py", line 45, in escape return Markup(_escape_inner(str(s))) SystemError: <built-in function _escape_inner> returned NULL without setting an exception failed: [os2-bos-ctrl01] (item={'key': 'glance-api', 'value': {'container_name': 'glance_api', 'group': 'glance-api', 'host_in_groups': True, 'enabled': True, 'image': ' registry.example.com/kolla/glance-api:2024.1-ubuntu-jammy', 'environment': {'http_proxy': '', 'https_proxy': '', 'no_proxy': 'localhost,127.0.0.1,10.0.52.11,10.0.52.10'}, 'privileged': False, 'volumes': ['/etc/kolla/glance-api/:/var/lib/kolla/config_files/:ro', '/etc/localtime:/etc/localtime:ro', '/etc/timezone:/etc/timezone:ro', 'glance:/var/lib/glance/', '', 'kolla_logs:/var/log/kolla/', '', ''], 'dimensions': {}, 'healthcheck': {'interval': '30', 'retries': '3', 'start_period': '5', 'test': ['CMD-SHELL', 'healthcheck_curl http://10.0.52.11:9292'], 'timeout': '30'}, 'haproxy': {'glance_api': {'enabled': True, 'mode': 'http', 'external': False, 'port': '9292', 'frontend_http_extra': ['timeout client 6h'], 'backend_http_extra': ['timeout server 6h'], 'custom_member_list': ['server os2-bos-ctrl01 10.0.52.11:9292 check inter 2000 rise 2 fall 5', '']}, 'glance_api_external': {'enabled': True, 'mode': 'http', 'external': True, 'external_fqdn': 'openstack-bos-2.example.com', 'port': '9292', 'frontend_http_extra': ['timeout client 6h'], 'backend_http_extra': ['timeout server 6h'], 'custom_member_list': ['server os2-bos-ctrl01 10.0.52.11:9292 check inter 2000 rise 2 fall 5', '']}}}}) => { "ansible_loop_var": "item", "changed": false, "item": { "key": "glance-api", "value": { "container_name": "glance_api", "dimensions": {}, "enabled": true, "environment": { "http_proxy": "", "https_proxy": "", "no_proxy": "localhost,127.0.0.1,10.0.52.11,10.0.52.10" }, "group": "glance-api", "haproxy": { "glance_api": { "backend_http_extra": [ "timeout server 6h" ], "custom_member_list": [ "server os2-bos-ctrl01 10.0.52.11:9292 check inter 2000 rise 2 fall 5", "" ], "enabled": true, "external": false, "frontend_http_extra": [ "timeout client 6h" ], "mode": "http", "port": "9292" }, "glance_api_external": { "backend_http_extra": [ "timeout server 6h" ], "custom_member_list": [ "server os2-bos-ctrl01 10.0.52.11:9292 check inter 2000 rise 2 fall 5", "" ], "enabled": true, "external": true, "external_fqdn": "openstack-bos-2.example.com", "frontend_http_extra": [ "timeout client 6h" ], "mode": "http", "port": "9292" } }, "healthcheck": { "interval": "30", "retries": "3", "start_period": "5", "test": [ "CMD-SHELL", "healthcheck_curl http://10.0.52.11:9292" ], "timeout": "30" }, "host_in_groups": true, "image": " registry.example.com/kolla/glance-api:2024.1-ubuntu-jammy", "privileged": false, "volumes": [ "/etc/kolla/glance-api/:/var/lib/kolla/config_files/:ro", "/etc/localtime:/etc/localtime:ro", "/etc/timezone:/etc/timezone:ro", "glance:/var/lib/glance/", "", "kolla_logs:/var/log/kolla/", "", "" ] } }, "msg": "SystemError: <built-in function _escape_inner> returned NULL without setting an exception" }

1 1

[zaqar]Proposing Takashi Kajinami as Zaqar core member
by hao wang 22 Oct '24

22 Oct '24

Hello, everyone, I would like to propose Takashi Kajinami for the OpenStack Zaqar core member. Takashi has contributed to the Zaqar project since 2021 and has done a great job of improving this project. It is very important to Zaqar to keep it stable and reliable. I am so excited that we can have such a great contributor and I believe we can do more valuable work to the Zaqar project. Thank you for your contributions. Regards, Hao Wang -- Best Wishes For You!

1 0

[nova][ptg] Nova sessions on Wednesday
by Sylvain Bauza 22 Oct '24

22 Oct '24

Hi, Given most of the nova cores will attend the eventlet-removal session at 1300UTC, we'll defer the nova sessions to start at 1400UTC instead of 1300UTC. Please stay online in #openstack-nova IRC channel or please take a look at https://ptg.opendev.org/ptg.html to see the exact time when we spawn again the nova conversations. Thanks, -Sylvain (who just unbooked the austin room for Wed-B1)

1 0

[Horizon] Cancelling weekly meeting tomorrow
by Tatiana Ovchinnikova 22 Oct '24

22 Oct '24

Hello team, Since we have vPTG sessions, I'm cancelling our weekly meeting tomorrow. With kind regards, Tatiana

1 0