December 2023 - openstack-discuss

A few questions about OpenStack projects archival strategy
by arabat50＠gmail.com 04 Dec '23

04 Dec '23

Dear OpenStack team, I hope this email finds you well. I am Ali Arabat, a PhD student in Software Engineering at École de Technologie Supérieure in Montreal, University of Quebec, Canada, conducting research studies on the evolution of multi-component systems, among which OpenStack plays a significant role. Through this email, we would like to ask a few questions related to our study on OpenStack. Our study revealed a significant increase in the number of cross-component changes over time. However, Such cross-component changes have decreased after archiving a large number of projects beyond 500. Therefore, we would like to have clarification and answers to a few questions as follows: What are the main factors in archiving OpenStack projects? Are there any policies established by OpenStack to archive such projects i.e., end of life? Who generally decides to abandon a given project? We highly value your input and we genuinely appreciate your time. Thank you for considering our request, and we look forward to your valuable input. Best regards, --------------------------------------- Ali Arabat Ph.D. student in Software Engineering Department of Software Engineering and IT École de Technologie Supérieure (ÉTS) | University of Quebec 1100, rue Notre-Dame Ouest, Montréal, QC H3C 1K3, Canada

2 1

[cinder]Need help for BP and Bug review
by hao wang 02 Dec '23

02 Dec '23

Hi, folkers There is some help needed for BP and Bug review, please see the links below. Those bps are introduced for enhancing the query ability of Cinder resources. We have finished and merged a part of it years ago. But there is still some work to do, I have been working on them for almost three years and updated them according to the reviewing comments many times. So, if there are no more updates required, please help me to finish those works, and it's very appreciated to merge them into Cinder project. Thank you very much. [1] bp: https://review.opendev.org/c/openstack/cinder/+/740146 [2] bp: https://review.opendev.org/c/openstack/cinder/+/733062 [3] bug: https://review.opendev.org/c/openstack/cinder/+/734415 -- Best Wishes For You!

1 0

[charms] OpenStack Charms 2023.2 (Bobcat) release is now available
by Peter Matulis 01 Dec '23

01 Dec '23

The 2023.2 (Bobcat) release of the OpenStack Charms is now available. Please see the release notes for full details: https://docs.openstack.org/charm-guide/latest/release-notes/2023.2-bobcat.h… == Highlights == * OpenStack 2023.2 (Bobcat) OpenStack Bobcat is now supported on Ubuntu 22.04 LTS (via UCA) and Ubuntu 23.10 natively. * Two charms promoted to stable Both the watcher and watcher-dashboard charms have been promoted to stable. * Keystone role cache configuration The keystone charm now supports configuring the Keystone '[role] cache_time' option using a new 'role-cache-expiration' charm configuration option. If not set, this defaults to the global expiration_time (configurable by the 'dogpile-cache-expiration' charm configuration option). * Designate-bind allow-transfer configuration The designate-bind charm now supports configuring the BIND9 allow-transfer option. If not set, the corresponding feature is disabled. * Improved Vault snap channel refresh The refresh mechanism for the Vault snap managed within the vault charm has been improved. It now properly stops the service before performing a snap refresh. * Glance custom image properties The glance charm now supports configuring automatic custom image properties for imported images. * magnum charm: new option to expose cluster_user_trust The magnum charm has gained a new configuration option (cluster-user-trust) to control whether to assign a trust to the cluster user or not (upstream cluster_user_trust option). * nova-cloud-controller charm: new relation to openstack-dashboard A new relation informs the cloud of what hosts and IP addresses that can potentially access the OpenStack Dashboard. The nova-cloud-controller units use this information to configure the nova-serialproxy daemon to allow dashboard requests from web browsers. * Documentation updates The Charm Guide and the Deploy Guide were updated for OpenStack 2023.2 and Juju 3.x. Regular improvements and bug fixes. == OpenStack Charms team == The OpenStack Charms team can be contacted via real time chat: https://chat.charmhub.io/charmhub/channels/openstack-charms The Juju user forum is also popular for diagnosing technical issues: https://discourse.charmhub.io/c/juju/ == Thank you == Lots of thanks to the 34 contributors below who squashed bugs, enabled new features, and improved the documentation! Alex Litvinov Alex Kavanagh Brett Milford Chi Wai, Chan Chris MacNaughton Corey Bryant Dmitrii Shcherbakov Dmytro Kazantsev Edward Hope-Morley Facundo Ciccioli Felipe Reyes Frode Nordahl Fulvio Galeazzi Jadon Naas James Lin James Page Jesper Schmitz Mouridsen Jorge Merlino Joshua Zhang Liam Young Luciano Lo Giudice Martin Kalcok Neil Campbell Nobuto Murata Peter Matulis Peter Sabaini Rafael Lopez Rodrigo Barbieri Samuel Walladge Utkarsh Bhatt Wong Hong Han Yamen Hatahet Yoshi Kadokawa -- OpenStack Charms Team

1 0

[ironic] multi-conductor architecture, standalone and DHCP
by Dmitry Tantsur 01 Dec '23

01 Dec '23

Hi folks, This is detailed context on the discussions we've had recently about multi-conductor in metal3. I'm sending it to potentially interested people and cc'ing the openstack ML. The metal3 side is https://github.com/dtantsur/ironic-operator/issues/3 (although that covers a few more different issues). In metal3 we have Ironic without Neutron (or really any other OpenStack components). So far, we have only supported a single Ironic instance in a cluster, but we want to move towards a multi-conductor setup where every Kubernetes control plane node will host an Ironic (so, 3 Ironics in a normal deployment). The biggest problem stems from DHCP for the provisioning network. With Neutron, Ironic can configure it to direct a node to boot from a specific iPXE server. With Metal3, we have a static DHCP configuration. If we keep it the way it is, it will always direct a node to boot from the iPXE server on the same machine as dnsmasq (regardless of how many dnsmasq replicas we run). This has to be changed. I see several options, none of which are straightforward. (1) iPXE-level fix: boot config API This is what https://bugs.launchpad.net/ironic/+bug/2044561 proposes. If we stop using static iPXE scripts and start going through the Ironic API instead, Ironic can reach out to the correct conductor internally, always serving the right script. (2) dnsmasq DHCP implementation Ironic now has a non-neutron managed DHCP implementation through DHCP host and options files: https://opendev.org/openstack/ironic/src/branch/master/ironic/dhcp/dnsmasq.…. This could be a half of the solution. Since Metal3 does not support new node auto-discovery, we can run 3 copies of dnsmasq with dhcp-ignore=!known and rely on this DHCP provider to configure only 1 dnsmasq for each node. The other 2 will ignore the requests. The problem is in the DHCP range. As far as I understand, the 3 dnsmasqs must be configured with disjoint ranges to prevent leases from clashing. This seems non-trivial with Kubernetes which expects to create identical pods. Adam has suggested using annotations from inside ironic-operator, which could work if we find a way to read them inside the pod after it has started (which seems to pose a chicken-and-egg problem). Other workarounds are possible if we go down this path. E.g. ironic-operator could split the DHCP range and creating a mapping hostIP:subrange,hostIP2:subrange2 and pass it to pods. Then each pod will pick its subrange based on its IP address. Huge downside: every time a Kubernetes control plane node is replaced or changes its IP, the whole Ironic installation will get restarted. (2.1) Pre-created leases Another Metal3 contributor has suggested requiring an IPAM implementation (metal3 actually has one) that will create leases centrally, allowing us to use the same DHCP range. The only problem: how to pass them to dnsmasq in runtime without restarting all pods? We could probably have a small sidecar container next to dnsmasq that watches the Kubernetes API for new leases in IPAM. Or... (2.2) Dynamic DHCP and Kea The same contributor is working on Kea support for their deployment: https://hackmd.io/@7RNIJtmvSIeNpSOMTW9oqA/SkWhyr7Hp. There seem to be limitations in the free version, which caused them to write a tiny downstream plugin: https://gitlab.com/Orange-OpenSource/kanod/kanod-kea/-/blob/controlled-leas…. Changing the DHCP server is a dramatic step, I'm not sure if our small community can afford that. It may also pose problems for downstreams like OpenShift, requiring Metal3 to support both servers in the long run. Any thoughts are welcome. Dmitry

3 3