December 2023 - openstack-discuss

[oslo] the eventlet story
by Herve Beraud 06 Dec '23

06 Dec '23

Hello Osloers, Just a heads up to you about the eventlet topic. If it is not already the case, I'd recommend that you keep an eye on the current discussions [1][2] about this topic. Indeed it could impact the Oslo world sooner than expected. Obviously I invite you to join the discussions and share your thoughts there [2]. Thanks [1] https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… [2] https://review.opendev.org/c/openstack/governance/+/902585 -- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/

1 0

how to remove volume from postgress in OpenStack
by kjme001＠gmail.com 06 Dec '23

06 Dec '23

Hello, I need to remove a volume from a postgress database on OpenStack. I found instructions on how to do it on mysql database: https://cloud.garr.it/support/kb/openstack/forceDeleteVolume/ but I don't know how to do it on a postgress database, could someone give me a hint? Greetings

1 0

[tc] Winter Holiday Meeting Schedule
by Jay Faulkner 05 Dec '23

05 Dec '23

Hi all, Due to the numerous TC members on PTO during the end of the year holidays, the TC is cancelling our meetings for December 26, 2023 and January 2, 2024. As always, the TC can be reached in #openstack-tc on OFTC or via the mailing list regardless of if we have a meeting. Thanks! Jay Faulkner OpenStack TC Chair

1 0

[cinder][nova][glance][ironic] restricting image metadata values to 255 chars
by Jorge Merlino 05 Dec '23

05 Dec '23

Hello stackers, It has come to our attention recently that nova, cinder, and glance treat image properties differently. This came up in a discussion on a patch to extend the allowable length of image metadata values in cinder [0]. Briefly: - glance allows image property values to be unrestricted in the schema, but effectively limited to 65535 bytes by the database. - cinder restricts the length of an image property value to 255 chars (by request schema) if you try to update the volume_image_properties on a volume, but if you create a volume from an image, cinder happily copies over all the image properties from glance, giving them an effective limit of 65535 bytes. - nova mostly truncates image properties values to 255 chars (it's a bit more complicated, but we can consider that to be nova's behavior for the purposes of this discussion). (We're not sure what ironic does, but they're in the subject line as a consumer of images and volumes.) Note that we're talking about metadata *values* here; the metadata keys are already restricted by charset to basically US-ASCII and 255 length. Values are allowed to be unicode. The point of this email is that it would be good for the services to be consistent about image metadata values. Thus, we propose that all services should restrict image metadata values to 255 unicode characters. (Which is sort of happening already, but not consistently.) The further point of this email is to find out what the impact of this restriction would be on current users. So please respond if you have a use case that would be affected by this change, and could not be addressed by, for example, instead of having one enormous value for a single key, the metadata was broken into a number of key/value pairs that would satisfy the 255 char restriction. Thanks for your attention to this! [0] https://review.opendev.org/c/openstack/cinder/+/868485

2 2

[nova] Spec review day is TOMORROW
by Sylvain Bauza 05 Dec '23

05 Dec '23

Hi folks, We'll run our second spec review day tomorrow. Please make sure that your specs are online and in a reviewable state if you want us to look at them. Please also check your Gerrit emails or be around on IRC in case we have any questions. Cores, you know your duty. Thanks, -Sylvain

1 0

[Neutron] - Getting bridge_name of the port from Java sdk
by Mahudeeswaran Palanisamy 05 Dec '23

05 Dec '23

Hi All, Looks like as part of the below commit, bridge_name info has been removed from port binding vif_details dictionary. Is there any way that we can get the bridge_name info of a port? As far as checked we can get this info by checking if port UUID is part of the “ports” array in “sudo ovs-vsctl list br” output. But there is no equivalent way to get from Java SDK. https://github.com/openstack/neutron/commit/569bafbbd5f90a458d781f1e49f099f… Thanks, Mahudees

3 6

[neutron] Bug Deputy Report November 27 - December 3
by Nurmatov Mamatisa 05 Dec '23

05 Dec '23

Hi, Below is the week summary of bug deputy report for last week. 1 rfe was proposed. Details: High ---- - https://bugs.launchpad.net/neutron/+bug/2044896 - [metadata_rate_limiting] options are absent from sample config files - Fix released: https://review.opendev.org/c/openstack/neutron/+/902013 - Assigned to Takashi Kajinami - https://bugs.launchpad.net/neutron/+bug/2045270 - [xena/yoga/zed] devstack-tobiko-neutron job broken - In progress - Assigned to Eduardo Olivares - https://bugs.launchpad.net/neutron/+bug/2045415 - ovn-octavia-provider lacks a sync script like Neutron - Unassigned Medium ------ https://bugs.launchpad.net/neutron/+bug/2045237 - [bulk] there is no clean operation if bulk create ports fails - Unassigned RFE --- - https://bugs.launchpad.net/neutron/+bug/2045058 - [RFE] Use call_monitor_timeout of oslo.messaging RPCClient instead of custom backoff mechanism and hardcoded timeouts - Triaged - Unassigned Best regards, isabek

1 0

[nova][ci][gate] Recent gate CI instability: an incomplete list of failures
by melanie witt 04 Dec '23

04 Dec '23

Hey all, Last week I spent some time parsing through an assortment of recent CI failures on Nova patches and made a list, if anyone else is interested in looking at issues: https://etherpad.opendev.org/p/nova-ci-failures-minimal I didn't link specific job runs logs because those can and will expire after ~10 days, so for each item I included an OpenSearch query term that can be used to find sample logs and get an idea of the frequency of a given failure. Note that some query terms will register more than one appearance in a Gerrit change -- this can be due to failure in multiple jobs on the same change or the query might not be unique enough. I tried to make the queries as unique as possible. You can add columns like "build_change" and "build_name" to the search result by clicking "+" on the left bar "Available fields" to see duplication or to make comparisons. To search for a list of build failures, go to the OpenSearch dashboard: https://opensearch.logs.openstack.org/_dashboards/app/discover?security_ten… and login with Username: openstack and Password: openstack: Then copy paste the OpenSearch query into the search box and adjust the time range (the default of the last 30 minutes will probably have no results): -melwitt

1 0

[tc] Weekly TC Meeting tomorrow, Dec 5, 1800 UTC
by Jay Faulkner 04 Dec '23

04 Dec '23

Hi all, The weekly meeting of the Technical Committee is tomorrow, December 5, at 1800 UTC. This is the first meeting of the month, and will be held in a zoom video meeting -- you can attend by unredacting the following link: https://us06web (dot) zoom (dot) us/j/87108541765?pwd=emlXVXg4QUxrUTlLNDZ2TTllWUM3Zz09 -- the link will also be pasted in OFTC #openstack-tc before the meeting. As always, minutes will be kept in #openstack-tc during the meeting. The proposed agenda is: - Roll call - Follow up on tracked action items: https://meetings.opendev.org/meetings/tc/2023/tc.2023-11-28-18.00.html - Rosmaita work with fungi on the gerrit meta-acls (for unmaintained branch statuses) - Gate health check - Leaderless projects (gmann) - Implementation of Unmaintained branch statuses - 2024.1 TC Tracker - https://etherpad.opendev.org/p/tc-2024.1-tracker - Open Discussion and Reviews Thanks, Jay Faulkner

1 0

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