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

[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