- openstack-discuss - lists.openstack.org

[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 28 Oct '24

28 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 25 Oct '24

25 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 25 Oct '24

25 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