December 2023 - openstack-discuss

[neutron] Bug Deputy Report December 4 - December 10
by Lajos Katona 11 Dec '23

11 Dec '23

Hi Neutrinos, I was the Neutron bug deputy last week, and I send the report of last week's bugs. - High prio bugs - Unassigned: https://bugs.launchpad.net/neutron/+bug/2045549 (OVS jobs randomly fails as Guest VMs not(or delayed) configured with DHCP) - https://bugs.launchpad.net/neutron/+bug/2045725 (scenario jobs randomly fails downloading ubuntu image) - related devstack patch: https://review.opendev.org/c/openstack/devstack/+/901699 - Medium prio bugs: - https://bugs.launchpad.net/neutron/+bug/2045811 (neutron-ovn-db-sync-util can fail with KeyError) - https://review.opendev.org/c/openstack/neutron/+/902841 - https://bugs.launchpad.net/neutron/+bug/2045889 ([OVN] ML2/OVN mech driver does not set the OVS bridge name in the port VIF details) - related mail thread: https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… - https://bugs.launchpad.net/neutron/+bug/2045950 (Security group performance issue for iptables driver due to "stateless feature") - performance issue with stateless security-groups. Best wishes Lajos Katona (lajoskatona)

1 0

[all] Ussuri and Train EOL
by Elõd Illés 11 Dec '23

11 Dec '23

Hi, With the new TC resolution '2023-07-24 Unmaintained status replaces Extended Maintenance' [1] the last 3 EM branches (Xena, Wallaby, Victoria) will transition to Unmaintained, but older branches (Ussuri, Train) should move to End of Life unless someone steps up as maintainer of this branch for this project. (In that case the branch of that project will transition to unmaintained/{ussuri,train}) To signal this, please add a -1 for the given generated EOL patch [2][3] if you or the team want to keep this branch open for further maintenance. If there is no response from anyone within a reasonable time frame, then PTLs/release liaisons will be asked to confirm the EOL transition with their +1. Thanks, Előd Illés irc: elodilles @ #openstack-stable / #openstack-release [1] https://governance.openstack.org/tc/resolutions/20230724-unmaintained-branc… [2] https://review.opendev.org/q/topic:train-eol [3] https://review.opendev.org/q/topic:ussuri-eol

1 0

[docs]OpenStack compatible list
by steven.wang＠gigacomputing.com 11 Dec '23

11 Dec '23

Hi, For OpenStack compatible check, how should we know the connection with base OS? Example; If the machine support RHEL9 and OpenStack Wallaby, can we say it is compatible to the newest OpenStack than Wallaby? So it should be no problem with Xena, Yoga, Zed, Antelope and Bobcat? Or please kindly let me know where can find the similar document? Thanks. Steven

2 2

System configuration in OpenStack
by lostghost1 10 Dec '23

10 Dec '23

Hi all, Sorry if this has been asked already, but is it feasible to use OpenStack to configure running systems - including virtual instances, containers, and the physical nodes themselves. I know that conceptually OpenStack takes a hands-off approach - it deals with images in abstract and further configuration is delegated to tools such as Ansible. Same for bare metal nodes - you provision them with Ironic, flash an image to them, and that's where configuaration ends for OpenStack. At least this is how I understand it, may be wrong. I was thinking about introducing systems configuration as a first-class concept into OpenStack - that means integration with the package manager, writing of config files from templates, filesystem management in general. The most well thought-out "solution" that there is for systems configuration is Nix in my opinion. I could intergrate it into OpenStack, I could write my own package manager. I haven't decided yet, these are just ideas for a pet project. So if I were to do such a thing, how would I go about achieving it? Obviously I would need to write a Horizon console module for the web UI. But beyond that I'd also need integration with other components. What do you all think?

1 0

Redundancy and high availability of basic services...
by Jorge Visentini 09 Dec '23

09 Dec '23

Hello everybody. I've been studying for some time now, reading official and third-party documentation about deploying and day-to-day maintenance of openstack. What I don't usually read about is the redundancy and high availability of basic services, such as the database, keystone, neutron... I wanted to better understand how it works in a small deployment scenario... I mean... 5 or 10 nodes and 3 controllers, for example... Here we use block storage fiber channel, so we won't use ceph... Of course, I won't implement it in production overnight, but I would like to hahaha but I would like to better understand this part of service redundancy. Thank you all for the emails sent every day. I learn a lot from them. -- Att, Jorge Visentini +55 55 98432-9868

1 0

[all] [ironic] Heads-up: another eventlet-related issue on Stream 8
by Dmitry Tantsur 09 Dec '23

09 Dec '23

Hi stackers, I've noticed this some time ago, but somehow decided that it wouldn't affect OpenStack upstream. Early sign of burn-out? Anyway... Red Hat has fixed CVE 2023-40217 in its Python 3.6 packages (used by default on CentOS Stream 8). Unfortunately, it was done in a way that breaks TLS in eventlet (more details in https://issues.redhat.com/browse/OCPBUGS-20486) It manifests in the following traceback: Traceback (most recent call last): File "/usr/lib64/python3.6/ssl.py", line 754, in __init__ self.getpeername() OSError: [Errno 107] Transport endpoint is not connected During handling of the above exception, another exception occurred: Traceback (most recent call last): <... SNIP ...> File "/usr/lib/python3.6/site-packages/oslo_service/wsgi.py", line 173, in start self.dup_socket = sslutils.wrap(self.conf, self.dup_socket) File "/usr/lib/python3.6/site-packages/oslo_service/sslutils.py", line 104, in wrap return ssl.wrap_socket(sock, **ssl_kwargs) # nosec File "/usr/lib/python3.6/site-packages/eventlet/green/ssl.py", line 422, in wrap_socket return GreenSSLSocket(sock, *a, **kw) File "/usr/lib/python3.6/site-packages/eventlet/green/ssl.py", line 117, in __init__ ca_certs, do_handshake_on_connect and six.PY2, *args, **kw) File "/usr/lib64/python3.6/ssl.py", line 759, in __init__ blocking = (self.gettimeout() != 0) File "/usr/lib/python3.6/site-packages/eventlet/green/ssl.py", line 145, in gettimeout return self._timeout AttributeError: 'GreenSSLSocket' object has no attribute '_timeout' The fix should be rather simple IMO: just remove the condition on Python 2 from here: https://github.com/eventlet/eventlet/blob/master/eventlet/green/ssl.py#L108. But I'm not sure, given the state of eventlet community, we can land anything these. The issue affects, for example. ironic-python-agent on stable/yoga. We're considering our options, the most likely is to use a non-default Python, which is 3.9. Xena and older did not support 3.9, so they're probably out in the cold... Thoughts, ideas? Dmitry

3 5

[goals][kolla][tripleo][all] Migrating from WSGI scripts to module paths
by Stephen Finucane 08 Dec '23

08 Dec '23

o/ For anyone that hasn't been following along, there are changes coming down the line in the Python packaging world that look likely to break pbr's 'wsgi_scripts' entrypoint functionality. As things stand, if we do nothing then at some point these auto-generated scripts will no longer end up in 'bin' when pip installed (as we do with e.g. DevStack). From where I'm standing, we appear to have two options: we can either invest time in pbr to re-implement this functionality from scratch, or we can drop the idea of auto-generating wsgi scripts from our packaging tool and instead start using module paths. Having looked at the former, I suspect it is going to be a *lot* of work that will require implementing our own PEP-517 compatible build backend instead of cribbing setuptools' one as we do now. Personally, I don't think this is a good investment of anyone's time, and it gives us more stuff to maintain for the many years ahead (Did you know that pbr *still* technically supports Python 2. Fun story that). As such, I think we should instead look to the former. I've proposed some patches for Nova [1][2], which I am hoping will provide a blueprint for the other services, and patch for DevStack to enable the new Nova functionality [3]. As you'll see, these patches are relatively small and hopefully easy to grok. The biggest downside I see to this approach is that tooling which deploys Apache+mod_wsgi rather than uWSGI used by e.g. DevStack will need to start packaging their own wsgi script. This is because mod_wsgi does not appear to support configuration by module paths. On the flipside, gunicorn does not support configuration by wsgi script so we get that for free. I would like to hear other's opinions on this approach. As this is something that likely affects all services, I suspect that if there's consensus that this is the correct way to go, there should probably be a small goal drafted for the current cycle. In my opinion, it would be good to do the migration consistently: in nova's case, I have proposed placing wsgi objects in the 'nova.wsgi' module and IMO if all projects could adopt the same convention we would make the lives of our deployment tooling colleagues easier. Please do let me know if you have any questions or concerns. Cheers, Stephen [1] https://review.opendev.org/c/openstack/nova/+/902687/2 [2] https://review.opendev.org/c/openstack/nova/+/902688/2 [3] https://review.opendev.org/c/openstack/devstack/+/902758/1

10 23

[keystone] Reviewathon canceled today
by Dave Wilde 08 Dec '23

08 Dec '23

Hi folks, I'm on PTO today and will be canceling the reviewathon unless someone else would like to run it. The Google Meet link will still work but I won't be there to run the meeting. Thanks! /Dave

1 0

Cyborg nova reports mdev-capable resource is not available
by Karl Kloppenborg 08 Dec '23

08 Dec '23

Hi Cyborg Team! Karl from Helm Team. When creating a VM with the correct flavor, the mdev gets created by cyborg agent and I can see it in the nodedev-list --cap mdev. However Nova then fails with: nova.virt.libvirt.driver [<removed>- - default default] Searching for available mdevs... _get_existing_mdevs_not_assigned /var/lib/openstack/lib/python3.10/site-packages/nova/virt/libvirt/driver.py :8357 2023-09-21 14:34:47.808 1901814 INFO nova.virt.libvirt.driver [<removed> - - default default] Available mdevs at: set(). 2023-09-21 14:34:47.809 1901814 DEBUG nova.virt.libvirt.driver [<removed> - - default default] No available mdevs where found. Creating an new one... _allocate_mdevs /var/lib/openstack/lib/python3.10/site-packages/nova/virt/libvirt/driv er.py:8496 2023-09-21 14:34:47.809 1901814 DEBUG nova.virt.libvirt.driver [<removed> - - default default] Attempting to create new mdev... _create_new_mediated_device /var/lib/openstack/lib/python3.10/site-packages/nova/virt/libvirt/driver.py:8385 2023-09-21 14:34:48.455 1901814 INFO nova.virt.libvirt.driver [<removed> - - default default] Failed to create mdev. No free space found among the following devices: ['pci_0000_4b_03_1', … <truncated list>]. 2023-09-21 14:34:48.456 1901814 ERROR nova.compute.manager [<removed> - - default default] [instance: 2026e2a2-b17a-43ab-adcb-62a907f58b51] Instance failed to spawn: nova.exception.ComputeResourcesUnavailable: Insufficient compute resources: mdev-capable resource is not available. Once this happened, ARQ removes the mdev and cleans up. I’ve got Cyborg 2023.2 running and have a device profile like so: karl@Karls-Air ~ % openstack accelerator device profile show e2b07e11-fe69-4f33-83fc-0f9e38adb7ae +-------------+---------------------------------------------------------------------------+ | Field | Value | +-------------+---------------------------------------------------------------------------+ | created_at | 2023-09-21 13:30:05+00:00 | | updated_at | None | | uuid | e2b07e11-fe69-4f33-83fc-0f9e38adb7ae | | name | VGPU_A40-Q48 | | groups | [{'resources:VGPU': '1', 'trait:CUSTOM_NVIDIA_2235_A40_48Q': 'required'}] | | description | None | +-------------+---------------------------------------------------------------------------+ karl@Karls-Air ~ % I can see the allocation candidate: karl@Karls-Air ~ % openstack allocation candidate list --resource VGPU=1 | grep A40 | 41 | VGPU=1 | 229bf15f-5689-3d2c-b37b-5c8439ea6a71 | VGPU=0/1 | OWNER_CYBORG,CUSTOM_NVIDIA_2235_A40_48Q | karl@Karls-Air ~ % Am I missing something critical here? Because I cannot seem to figure this out… have I got a PCI address wrong, or something? Any help from the Cyborg or Nova teams would be fantastic. Thanks, Karl.

4 9

RE: openstack-discuss Digest, Vol 62, Issue 5 Netwok Configuration Isssue | Urgent
by Asma Naz Shariq 08 Dec '23

08 Dec '23

Hi openstack community, I have deployed Multinode cluster of Openstack through kolla-ansible zed release. The problem I am facing is instances created cannot pick any Ip addresses from the assigned networks which I have created provider and self-service flat network type. Hence, I may not be able to ping and ssh instance from the controller node and these instances won’t be able to connect to the internet. Can anyone guide me how to resolve this issue by pinpointing the initial network configurations settings. -----Original Message----- From: Asma Naz Shariq <asma.naz(a)techavenue.biz> Sent: Wednesday, December 6, 2023 10:42 AM To: 'openstack-discuss(a)lists.openstack.org' <openstack-discuss(a)lists.openstack.org> Subject: RE: openstack-discuss Digest, Vol 62, Issue 5 Netwok Configuration Isssue | Urgent Hi openstack community, I have deployed Multinode cluster of Openstack through kolla-ansible zed release. The problem I am facing is instances created cannot pick any Ip addresses from the assigned networks which I have created provider and self-service flat network type. Hence, I may not be able to ping and ssh instance from the controller node and these instances won’t be able to connect to the internet. Can anyone guide me how to resolve this issue by pinpointing the initial network configurations settings. -----Original Message----- From: openstack-discuss-request(a)lists.openstack.org <openstack-discuss-request(a)lists.openstack.org> Sent: Tuesday, December 5, 2023 9:30 PM To: openstack-discuss(a)lists.openstack.org Subject: openstack-discuss Digest, Vol 62, Issue 5 Send openstack-discuss mailing list submissions to openstack-discuss(a)lists.openstack.org To subscribe or unsubscribe via email, send a message with subject or body 'help' to openstack-discuss-request(a)lists.openstack.org You can reach the person managing the list at openstack-discuss-owner(a)lists.openstack.org When replying, please edit your Subject line so it is more specific than "Re: Contents of openstack-discuss digest..." Today's Topics: 1. Re: [Neutron] - Getting bridge_name of the port from Java sdk (smooney(a)redhat.com) 2. Re: [cinder][nova][glance][ironic] restricting image metadata values to 255 chars (Jorge Merlino) 3. [nova] Spec review day is TOMORROW (Sylvain Bauza) ---------------------------------------------------------------------- Message: 1 Date: Tue, 05 Dec 2023 11:41:06 +0000 From: smooney(a)redhat.com Subject: Re: [Neutron] - Getting bridge_name of the port from Java sdk To: Rodolfo Alonso Hernandez <ralonsoh(a)redhat.com> Cc: Mahudeeswaran Palanisamy <mahudees(a)gmail.com>, openstack-discuss(a)lists.openstack.org Message-ID: <dc8b7b75904590a3124212668e89129080e3aaf9.camel(a)redhat.com> Content-Type: text/plain; charset="UTF-8" On Tue, 2023-12-05 at 11:53 +0100, Rodolfo Alonso Hernandez wrote: > Ok, I'll raise this issue in the Neutron team today during the > networking meeting. just to be clear we have not deprecated the options in nova yet i have been to busy with other work so we wont be removing this in nova in the near term. i may propose a depercation patch depending on your disucssion but we are in no rush. long term however it would be preferabel if neutron alwasy told use what bridge to use and we nolonger had to keep the nova.conf and neutron.conf/ovsdb in sync to have this work. > On Tue, Dec 5, 2023 at 11:45 AM <smooney(a)redhat.com> wrote: > > > On Tue, 2023-12-05 at 09:04 +0100, Rodolfo Alonso Hernandez wrote: > > > Hello Sean: > > > > > > The bridge name in the port VIF details was added for the VLAN > > > aware VMs feature. [1] is the patch adding this functionality in > > > Nova. This is also used with bridge type ports (for hybrid plug). > > yes but we then asked for this to always be set so we coudl > > eventually remove our config options for this. > > > > https://github.com/openstack/neutron/commit/995744c576503b1de90c922d > > becf690ad49f244f > > https://bugs.launchpad.net/neutron/+bug/1788009 > > > > this change is requried to eventualy allow live migration between > > ml2/ovs and ml2/ovn when using vlan networkign > > https://lists.openstack.org/pipermail/openstack-dev/2018-August/1335 > > 46.html > > > > i have 0 time to accutually fix all th things to make that work > > generically sicne that would also like need use to make it work for geneve too. > > > > > But there is no requirement > > > to include the name of the OVS bridge in this dictionary and we > > > are not doing that for any other directly attached ports, not in > > > ML2/OVS nor in ML2/OVN. If Nova requires that, then it should be > > > needed to create an RFE in Neutron to always include it. > > we have discuss this in the past and asked that this alwasy be set > > for ml2/ovn and any other ml2 driver that manage ovs. > > if ml2/ovs does not always set it even when trunk port are not used > > then > > https://bugs.launchpad.net/neutron/+bug/1788009 hwas been regressed > > and we shoudl fix that. > > > > > > Regards. > > > > > > [1]https://review.opendev.org/c/openstack/nova/+/260700 > > > > > > On Mon, Dec 4, 2023 at 6:55 PM <smooney(a)redhat.com> wrote: > > > > > > > On Mon, 2023-12-04 at 16:13 +0100, Rodolfo Alonso Hernandez wrote: > > > > > Hello Mahudeeswaran: > > > > > > > > > > This topic is being discussed in [1]. The patch [2] you are > > referring to > > > > is > > > > > not changing the previous code related to the mentioned > > > > > parameter > > "bridge > > > > > name". Please check [3]. > > > > > > > > > > Also consider that this value was populated when using Trunk > > > > > ports, > > to > > > > > store the Trunk bridge name created on the port description. > > > > > In > > ML2/OVN, > > > > > all ports are attached to the integration bridge (there is a > > > > configuration > > > > > parameter to define the integration name bridge called > > > > > "integration_bridge", that by default is "br-int"). > > > > just to be clear from a nova perspective i would expect the > > > > value to always be populated when ovn binds the prot normally. > > > > > > > > nova may have config options for the default bridge name to use > > > > but we should not be relying on them. so as apart of the ml2/ovs > > > > to ml2/ovn migration the bridge_name > > in > > > > the port binding should get > > > > update to the correct value for the current cloud. > > > > > > > > we have not formally deprcated > > > > > > https://docs.openstack.org/nova/latest/configuration/config.html#neu > > tron.ovs_bridge > > > > but > > > > we likely shold do that now that we can rely on neutron ml2 > > > > backend > > that > > > > supprot ovs always settign this. > > > > > > > > > > > > > > Regards. > > > > > > > > > > [1] > > > > > > > > > > > https://lists.openstack.org/archives/list/openstack-discuss@lists.op > > enstack.org/thread/X4GT7LA523FZWJCGEF2IKTG7VF5WSZWK/ > > > > > [2] > > > > > > > > > > > https://github.com/openstack/neutron/commit/569bafbbd5f90a458d781f1e > > 49f099f96c363683#diff-3fb0e47430c01037fddef45c2ce7314f50a3df5ac41dbd > > 604f9581d90f2985bb > > > > > [3] > > > > > > > > > > > https://github.com/openstack/neutron/commit/569bafbbd5f90a458d781f1e > > 49f099f96c363683#diff-3fb0e47430c01037fddef45c2ce7314f50a3df5ac41dbd > > 604f9581d90f2985bbR33 > > > > > > > > > > > > > > > > > > > > On Mon, Dec 4, 2023 at 3:50 PM Mahudeeswaran Palanisamy < > > > > mahudees(a)gmail.com> > > > > > wrote: > > > > > > > > > > > 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/569bafbbd5f90a458d781f1e > > 49f099f96c363683#diff-3fb0e47430c01037fddef45c2ce7314f50a3df5ac41dbd > > 604f9581d90f2985bb > > > > > > > > > > > > Thanks, > > > > > > Mahudees > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------ Message: 2 Date: Tue, 5 Dec 2023 13:27:49 -0300 From: Jorge Merlino <jorge.merlino(a)canonical.com> Subject: Re: [cinder][nova][glance][ironic] restricting image metadata values to 255 chars To: Erno Kuvaja <ekuvaja(a)redhat.com> Cc: OpenStack Discuss <openstack-discuss(a)lists.openstack.org> Message-ID: <4da4c94e-81bf-4660-887b-53c2a00e25f4(a)canonical.com> Content-Type: text/plain; charset=UTF-8; format=flowed On 30/11/23 19:34, Erno Kuvaja wrote: > On Thu, 30 Nov 2023 at 20:55, Jorge Merlino > <jorge.merlino(a)canonical.com <mailto:jorge.merlino@canonical.com>> wrote: > > 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 > <https://review.opendev.org/c/openstack/cinder/+/868485> > > > Hi Jorge & all, > > To be very frank here, this sounds like a nova problem and your > approach to fix the issue in Cinder seemed to be sensible and > generally accepted there. > > The metadefs basic concepts are explained in [0], Compute defines > subsection of that, all predefined metadefs can be found from [1] > > The very arrogant and false claim from your patch reviews that Nova > would define all image properties and that definition would limit it > to > 255 characters is, well, hilarious. > > Even the field definitions in the code do not specify such max size > for most of those properties Nova _expects_ it might see and knows how > to use, like Sean pointed out, it just happens to be limited how much > of that Nova is able to store in their own database due to the field > restriction at their DB layer. Lots of them properties are things like > booleans or enumerations of values for Nova and thus have practical > limitations. There are also fields like ListOfStrings, no max length > defined. > > Restricting the image properties from all the other consumers because > Nova can't handle storing the copies of them, and thus breaking the > Images API v2 and any use cases that uses image properties outside of > Nova's fairly narrow scope would just be unacceptable. Either Nova > should overcome their internal limitations and figure out how to deal > with the resources or at very least understand to ignore them > properties they have no capacity or interest handling. > > Good luck and thanks for your patience to fight the windmills trying > to get a simple fix in, Erno "jokke" Kuvaja > > [0] > https://docs.openstack.org/glance/latest/user/metadefs-concepts.html > <https://docs.openstack.org/glance/latest/user/metadefs-concepts.html> > [1] https://github.com/openstack/glance/tree/master/etc/metadefs > <https://github.com/openstack/glance/tree/master/etc/metadefs> I'll tend to agree with you, but I see some consistency problems from the user's point of view. For example, if they create a server from an image with long metadata values and then create an image (snapshot) from that server, the new image gets the same metadata parameters as the original image but truncated to 255 chars. Thinking from the perspective of a Openstack user (that does not care what particular service implements what) it would be nice if there was some kind of global policy regarding this. As the shortest length supported right now is nova's, a simple (but maybe not the best?) solution would be to adapt to that length everywhere. Regards Jorge ------------------------------ Message: 3 Date: Tue, 5 Dec 2023 17:21:49 +0100 From: Sylvain Bauza <sbauza(a)redhat.com> Subject: [nova] Spec review day is TOMORROW To: OpenStack Discuss <openstack-discuss(a)lists.openstack.org> Message-ID: <CALOCmumwKP9ifF10P91QZP4AkbyybBZAjnxAPaZCkVW=LHRRzA(a)mail.gmail.com> Content-Type: multipart/alternative; boundary="0000000000005bff15060bc5a231" 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

Kolla Ansible Zed release
by Wada Akor 07 Dec '23

07 Dec '23

I need help fix the error that occurred during deployment from Rabbitmq "attempts": 5, "censored": "the output has been hidden due to the fact that 'no_log: true' was specified for this result", "changed": false } fatal: [localhost -> {{ service_rabbitmq_delegate_host }}]: FAILED! => { "censored": "the output has been hidden due to the fact that 'no_log: true' was specified for this result", "changed": false Thanks

1 0

[Next Week] OpenInfra Live: Large Scale Ops Deep Dive Ft: Samsung SDS Dec. 14 at 15UTC
by Kristin Barrientos 07 Dec '23

07 Dec '23

Hi everyone, Thanks for watching the OpenInfra Live PTG Recap! Many exciting discussions happened, and can’t wait for another PTG in 2024. Thank you again to all of the PTLs who presented. In case you missed the episode, you can find it here: https://www.youtube.com/watch?v=thidlQGX29M If you have any questions for the PTLs, feel free to send them to the OpenStack or StarlingX mailing list. Links are below: https://lists.openstack.org/mailman3/lists/openstack-discuss.lists.openstac… https://lists.starlingx.io/mailman3/lists/starlingx-discuss.lists.starlingx… ———— Tune in next week for another OpenInfra Live, brought to you by the Large Scale SIG. Episode: In the "Large Scale Ops Deep Dive" series, a panel of OpenStack operators invites special guests to talk about their deployment and discuss their operations. For this episode, our guest will be Dan Paik from Samsung SDS. Date and time: Thursday, Dec 14, 15 UTC YouTube: https://www.youtube.com/watch?v=RI9SwY8VdCY LinkedIn:https://www.linkedin.com/events/7125892582139654144/comments/ WeChat: The recording will be posted on OpenInfra Foundation WeChat after the live stream Speakers: Dan Paik, Arnaud Morin, Felix Huettner, Thierry Carrez, Kristin Barrientos Thanks, Kristin Barrientos Marketing Coordinator OpenInfra Foundation

1 0

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

07 Dec '23

Hi All, Looks like as part of 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 “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 This message may contain confidential and privileged information. If it has been sent to you in error, please reply to advise the sender of the error and then immediately delete it. If you are not the intended recipient, do not read, copy, disclose or otherwise use this message. The sender disclaims any liability for such unauthorized use. NOTE that all incoming emails sent to Gigamon email accounts will be archived and may be scanned by us and/or by external service providers to detect and prevent threats to our systems, investigate illegal or inappropriate behavior, and/or eliminate unsolicited promotional emails (“spam”).

3 4

RE: openstack-discuss Digest, Vol 62, Issue 5 Netwok Configuration Isssue | Urgent
by Asma Naz Shariq 07 Dec '23

07 Dec '23

Hi openstack community, I have deployed Multinode cluster of Openstack through kolla-ansible zed release. The problem I am facing is instances created cannot pick any Ip addresses from the assigned networks which I have created provider and self-service flat network type. Hence, I may not be able to ping and ssh instance from the controller node and these instances won’t be able to connect to the internet. Can anyone guide me how to resolve this issue by pinpointing the initial network configurations settings. -----Original Message----- From: openstack-discuss-request(a)lists.openstack.org <openstack-discuss-request(a)lists.openstack.org> Sent: Tuesday, December 5, 2023 9:30 PM To: openstack-discuss(a)lists.openstack.org Subject: openstack-discuss Digest, Vol 62, Issue 5 Send openstack-discuss mailing list submissions to openstack-discuss(a)lists.openstack.org To subscribe or unsubscribe via email, send a message with subject or body 'help' to openstack-discuss-request(a)lists.openstack.org You can reach the person managing the list at openstack-discuss-owner(a)lists.openstack.org When replying, please edit your Subject line so it is more specific than "Re: Contents of openstack-discuss digest..." Today's Topics: 1. Re: [Neutron] - Getting bridge_name of the port from Java sdk (smooney(a)redhat.com) 2. Re: [cinder][nova][glance][ironic] restricting image metadata values to 255 chars (Jorge Merlino) 3. [nova] Spec review day is TOMORROW (Sylvain Bauza) ---------------------------------------------------------------------- Message: 1 Date: Tue, 05 Dec 2023 11:41:06 +0000 From: smooney(a)redhat.com Subject: Re: [Neutron] - Getting bridge_name of the port from Java sdk To: Rodolfo Alonso Hernandez <ralonsoh(a)redhat.com> Cc: Mahudeeswaran Palanisamy <mahudees(a)gmail.com>, openstack-discuss(a)lists.openstack.org Message-ID: <dc8b7b75904590a3124212668e89129080e3aaf9.camel(a)redhat.com> Content-Type: text/plain; charset="UTF-8" On Tue, 2023-12-05 at 11:53 +0100, Rodolfo Alonso Hernandez wrote: > Ok, I'll raise this issue in the Neutron team today during the > networking meeting. just to be clear we have not deprecated the options in nova yet i have been to busy with other work so we wont be removing this in nova in the near term. i may propose a depercation patch depending on your disucssion but we are in no rush. long term however it would be preferabel if neutron alwasy told use what bridge to use and we nolonger had to keep the nova.conf and neutron.conf/ovsdb in sync to have this work. > On Tue, Dec 5, 2023 at 11:45 AM <smooney(a)redhat.com> wrote: > > > On Tue, 2023-12-05 at 09:04 +0100, Rodolfo Alonso Hernandez wrote: > > > Hello Sean: > > > > > > The bridge name in the port VIF details was added for the VLAN > > > aware VMs feature. [1] is the patch adding this functionality in > > > Nova. This is also used with bridge type ports (for hybrid plug). > > yes but we then asked for this to always be set so we coudl > > eventually remove our config options for this. > > > > https://github.com/openstack/neutron/commit/995744c576503b1de90c922d > > becf690ad49f244f > > https://bugs.launchpad.net/neutron/+bug/1788009 > > > > this change is requried to eventualy allow live migration between > > ml2/ovs and ml2/ovn when using vlan networkign > > https://lists.openstack.org/pipermail/openstack-dev/2018-August/1335 > > 46.html > > > > i have 0 time to accutually fix all th things to make that work > > generically sicne that would also like need use to make it work for geneve too. > > > > > But there is no requirement > > > to include the name of the OVS bridge in this dictionary and we > > > are not doing that for any other directly attached ports, not in > > > ML2/OVS nor in ML2/OVN. If Nova requires that, then it should be > > > needed to create an RFE in Neutron to always include it. > > we have discuss this in the past and asked that this alwasy be set > > for ml2/ovn and any other ml2 driver that manage ovs. > > if ml2/ovs does not always set it even when trunk port are not used > > then > > https://bugs.launchpad.net/neutron/+bug/1788009 hwas been regressed > > and we shoudl fix that. > > > > > > Regards. > > > > > > [1]https://review.opendev.org/c/openstack/nova/+/260700 > > > > > > On Mon, Dec 4, 2023 at 6:55 PM <smooney(a)redhat.com> wrote: > > > > > > > On Mon, 2023-12-04 at 16:13 +0100, Rodolfo Alonso Hernandez wrote: > > > > > Hello Mahudeeswaran: > > > > > > > > > > This topic is being discussed in [1]. The patch [2] you are > > referring to > > > > is > > > > > not changing the previous code related to the mentioned > > > > > parameter > > "bridge > > > > > name". Please check [3]. > > > > > > > > > > Also consider that this value was populated when using Trunk > > > > > ports, > > to > > > > > store the Trunk bridge name created on the port description. > > > > > In > > ML2/OVN, > > > > > all ports are attached to the integration bridge (there is a > > > > configuration > > > > > parameter to define the integration name bridge called > > > > > "integration_bridge", that by default is "br-int"). > > > > just to be clear from a nova perspective i would expect the > > > > value to always be populated when ovn binds the prot normally. > > > > > > > > nova may have config options for the default bridge name to use > > > > but we should not be relying on them. so as apart of the ml2/ovs > > > > to ml2/ovn migration the bridge_name > > in > > > > the port binding should get > > > > update to the correct value for the current cloud. > > > > > > > > we have not formally deprcated > > > > > > https://docs.openstack.org/nova/latest/configuration/config.html#neu > > tron.ovs_bridge > > > > but > > > > we likely shold do that now that we can rely on neutron ml2 > > > > backend > > that > > > > supprot ovs always settign this. > > > > > > > > > > > > > > Regards. > > > > > > > > > > [1] > > > > > > > > > > > https://lists.openstack.org/archives/list/openstack-discuss@lists.op > > enstack.org/thread/X4GT7LA523FZWJCGEF2IKTG7VF5WSZWK/ > > > > > [2] > > > > > > > > > > > https://github.com/openstack/neutron/commit/569bafbbd5f90a458d781f1e > > 49f099f96c363683#diff-3fb0e47430c01037fddef45c2ce7314f50a3df5ac41dbd > > 604f9581d90f2985bb > > > > > [3] > > > > > > > > > > > https://github.com/openstack/neutron/commit/569bafbbd5f90a458d781f1e > > 49f099f96c363683#diff-3fb0e47430c01037fddef45c2ce7314f50a3df5ac41dbd > > 604f9581d90f2985bbR33 > > > > > > > > > > > > > > > > > > > > On Mon, Dec 4, 2023 at 3:50 PM Mahudeeswaran Palanisamy < > > > > mahudees(a)gmail.com> > > > > > wrote: > > > > > > > > > > > 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/569bafbbd5f90a458d781f1e > > 49f099f96c363683#diff-3fb0e47430c01037fddef45c2ce7314f50a3df5ac41dbd > > 604f9581d90f2985bb > > > > > > > > > > > > Thanks, > > > > > > Mahudees > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------ Message: 2 Date: Tue, 5 Dec 2023 13:27:49 -0300 From: Jorge Merlino <jorge.merlino(a)canonical.com> Subject: Re: [cinder][nova][glance][ironic] restricting image metadata values to 255 chars To: Erno Kuvaja <ekuvaja(a)redhat.com> Cc: OpenStack Discuss <openstack-discuss(a)lists.openstack.org> Message-ID: <4da4c94e-81bf-4660-887b-53c2a00e25f4(a)canonical.com> Content-Type: text/plain; charset=UTF-8; format=flowed On 30/11/23 19:34, Erno Kuvaja wrote: > On Thu, 30 Nov 2023 at 20:55, Jorge Merlino > <jorge.merlino(a)canonical.com <mailto:jorge.merlino@canonical.com>> wrote: > > 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 > <https://review.opendev.org/c/openstack/cinder/+/868485> > > > Hi Jorge & all, > > To be very frank here, this sounds like a nova problem and your > approach to fix the issue in Cinder seemed to be sensible and > generally accepted there. > > The metadefs basic concepts are explained in [0], Compute defines > subsection of that, all predefined metadefs can be found from [1] > > The very arrogant and false claim from your patch reviews that Nova > would define all image properties and that definition would limit it > to > 255 characters is, well, hilarious. > > Even the field definitions in the code do not specify such max size > for most of those properties Nova _expects_ it might see and knows how > to use, like Sean pointed out, it just happens to be limited how much > of that Nova is able to store in their own database due to the field > restriction at their DB layer. Lots of them properties are things like > booleans or enumerations of values for Nova and thus have practical > limitations. There are also fields like ListOfStrings, no max length > defined. > > Restricting the image properties from all the other consumers because > Nova can't handle storing the copies of them, and thus breaking the > Images API v2 and any use cases that uses image properties outside of > Nova's fairly narrow scope would just be unacceptable. Either Nova > should overcome their internal limitations and figure out how to deal > with the resources or at very least understand to ignore them > properties they have no capacity or interest handling. > > Good luck and thanks for your patience to fight the windmills trying > to get a simple fix in, Erno "jokke" Kuvaja > > [0] > https://docs.openstack.org/glance/latest/user/metadefs-concepts.html > <https://docs.openstack.org/glance/latest/user/metadefs-concepts.html> > [1] https://github.com/openstack/glance/tree/master/etc/metadefs > <https://github.com/openstack/glance/tree/master/etc/metadefs> I'll tend to agree with you, but I see some consistency problems from the user's point of view. For example, if they create a server from an image with long metadata values and then create an image (snapshot) from that server, the new image gets the same metadata parameters as the original image but truncated to 255 chars. Thinking from the perspective of a Openstack user (that does not care what particular service implements what) it would be nice if there was some kind of global policy regarding this. As the shortest length supported right now is nova's, a simple (but maybe not the best?) solution would be to adapt to that length everywhere. Regards Jorge ------------------------------ Message: 3 Date: Tue, 5 Dec 2023 17:21:49 +0100 From: Sylvain Bauza <sbauza(a)redhat.com> Subject: [nova] Spec review day is TOMORROW To: OpenStack Discuss <openstack-discuss(a)lists.openstack.org> Message-ID: <CALOCmumwKP9ifF10P91QZP4AkbyybBZAjnxAPaZCkVW=LHRRzA(a)mail.gmail.com> Content-Type: multipart/alternative; boundary="0000000000005bff15060bc5a231" 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

2 1

Where might a find the data model for neutron database.
by Gautam Thaker 07 Dec '23

07 Dec '23

I am trying to understand all the tables (including references from one table to another) that are in a standard/typical neutron instance in a standard openstack environment. Where might I find this? I understand underlying relational tables are used mainly by ORM in python using SQLAlchemy. So details/diagrams at either tables or ORM level are welcome.

2 1

[Glance] Deprecating Cachemanage Middleware
by Pranali Deore 07 Dec '23

07 Dec '23

Hello Everyone, We have also discussed during Caracal PTG about the deprecation of cachemanage middleware since Cache operations (CR(u)D) is now part of glance API, even though we need to depend on cache middleware to enable it. There are two middlewares related to caching, one is `cache` and other is `cachemanage` and we can now get rid of `cachemanage` middleware and glance-cache-manage command line utility. In this cycle we are going to deprecate cachemanage middleware and api pipeline `keystone+cachemanage` (defined in glance-api-paste.ini) and `glance-cache-manage` command line utility. A deprecation warning message will be added to each command of `glance-cache-manage` utility as well as during initialization of `cachemanage` middleware. The spec-lite has been submitted for the same [1] Please let us know if you have any comments/suggestions on the plan above. [1]: https://review.opendev.org/c/openstack/glance-specs/+/899805 Thanks and Regards, Pranali Deore

1 1

[Glance] Deprecating Location Startegy
by Pranali Deore 07 Dec '23

07 Dec '23

Hello Everyone, Glance core team have discussed and decided during Caracal PTG[1] about the deprecation of location strategy since in Bobcat we added support for the weighing mechanism to glance store[2]. To use this new feature we decided to deprecate location strategy in this cycle and remove it in 'D' (2024.2) development cycle[3]. In this cycle we are going to deprecate following configuration options related to location strategy: * location_strategy * store_type_preference Also a warning message regarding deprecation will be added to`location_order` and `store_type` strategy module during the initiation phase. Please let us know if you have any comments on the plan above. [1]: https://etherpad.opendev.org/p/oct2023-ptg-glance#L74 [2]: https://review.opendev.org/c/openstack/glance-specs/+/886040 [3]: https://review.opendev.org/c/openstack/glance-specs/+/899804 Thanks & Regards, Pranali Deore

1 1

[openstack-ansible] overriding host vars for compute_hosts
by pi3.14＠tuta.io 06 Dec '23

06 Dec '23

Hey folks, Unfortunately, I am not able to specify host specific variables for the compute hosts. I am trying to specify the `nova_user_ssl_*` variables for each compute node. When these variables are specified in `user_variables.yml` and then specified in `openstack_user_config.yml`, they don't actually end up overriding the variables. But they are recognised correctly in `openstack_inventory.json`. When I remove the variables from `user_variables.yml`, everything works correctly. Is it not possible to specify general variables in `user_variables.yml` and then overwrite them in `openstack_user_config.yml`? Example for `openstack_user_config.yml` (same Problem when using `host_vars` instead of `container_vars`): ``` compute_hosts: compute1: ip: 192.168.1.2 container_vars: nova_user_ssl_cert: "/path/to/cert1" nova_user_ssl_key: "/path/to/key1" nova_user_ssl_ca_cert: "/path/to/ca1" ``` thanks Roby

2 1

beginning with [masakari]
by Shubham Kumar Yadav 06 Dec '23

06 Dec '23

Hi, i have recently started working on Masakari so i wanted some help with it please i was trying to test the masakari-instance_monitor & masakari-host-monitor but having trouble with it logs from host monitor pods Stdout: '' Stderr: 'Connection to the CIB manager failed: Transport endpoint is not connected\nInit failed, could not perform requested operations\n': oslo_concurrency.processutils.ProcessExecutionError: Unexpected error while running command. 2023-12-05 14:36:50.199 1 WARNING masakarimonitors.hostmonitor.host_handler.handle_host [-] hostmonitor skips monitoring hosts. 2023-12-05 14:38:50.299 1 INFO masakarimonitors.hostmonitor.host_handler.handle_host [-] Works on pacemaker-remote. 2023-12-05 14:38:50.309 1 WARNING masakarimonitors.hostmonitor.host_handler.handle_host [-] Exception caught: Unexpected error while running command. Command: cibadmin --query Exit code: 102 logs from instance monitor pod 2023-12-05 14:04:38.340 1 ERROR masakarimonitors.ha.masakari [-] Exception caught: BadRequestException: 400: Client Error for url: http://masakari-api.openstack.svc.cluster.local:15868/v1/7b473b7ad14846938c…, Host with name lab-11053-26006-cmp-2 could not be found.: openstack.exceptions.BadRequestException: BadRequestException: 400: Client Error for url: http://masakari-api.openstack.svc.cluster.local:15868/v1/7b473b7ad14846938c…, Host with name lab-11053-26006-cmp-2 could not be found. masakari-instance-monitor-kbfkv masakari-instance-monitor 2023-12-05 14:04:38.340 1 ERROR masakarimonitors.ha.masakari Traceback (most recent call last): masakari-instance-monitor-kbfkv masakari-instance-monitor 2023-12-05 14:04:38.340 1 ERROR masakarimonitors.ha.masakari File "/var/lib/openstack/lib/python3.8/site-packages/masakarimonitors/ha/masakari.py", line 60, in send_notification masakari-instance-monitor-kbfkv masakari-instance-monitor 2023-12-05 14:04:38.340 1 ERROR masakarimonitors.ha.masakari response = client.create_notification( masakari-instance-monitor-kbfkv masakari-instance-monitor 2023-12-05 14:04:38.340 1 ERROR masakarimonitors.ha.masakari File "/var/lib/openstack/lib/python3.8/site-packages/openstack/instance_ha/v1/_proxy.py", line 65, in create_notification masakari-instance-monitor-kbfkv masakari-instance-monitor 2023-12-05 14:04:38.340 1 ERROR masakarimonitors.ha.masakari return self._create(_notification.Notification, **attrs) masakari-instance-monitor-kbfkv masakari-instance-monitor 2023-12-05 14:04:38.340 1 ERROR masakarimonitors.ha.masakari File "/var/lib/openstack/lib/python3.8/site-packages/openstack/proxy.py", line 459, in _create masakari-instance-monitor-kbfkv masakari-instance-monitor 2023-12-05 14:04:38.340 1 ERROR masakarimonitors.ha.masakari return res.create(self, base_path=base_path) masakari-instance-monitor-kbfkv masakari-instance-monitor 2023-12-05 14:04:38.340 1 ERROR masakarimonitors.ha.masakari File "/var/lib/openstack/lib/python3.8/site-packages/openstack/resource.py", line 1343, in create masakari-instance-monitor-kbfkv masakari-instance-monitor 2023-12-05 14:04:38.340 1 ERROR masakarimonitors.ha.masakari self._translate_response(response, has_body=has_body) masakari-instance-monitor-kbfkv masakari-instance-monitor 2023-12-05 14:04:38.340 1 ERROR masakarimonitors.ha.masakari File "/var/lib/openstack/lib/python3.8/site-packages/openstack/resource.py", line 1158, in _translate_response masakari-instance-monitor-kbfkv masakari-instance-monitor 2023-12-05 14:04:38.340 1 ERROR masakarimonitors.ha.masakari exceptions.raise_from_response(response, error_message=error_message) masakari-instance-monitor-kbfkv masakari-instance-monitor 2023-12-05 14:04:38.340 1 ERROR masakarimonitors.ha.masakari File "/var/lib/openstack/lib/python3.8/site-packages/openstack/exceptions.py", line 236, in raise_from_response masakari-instance-monitor-kbfkv masakari-instance-monitor 2023-12-05 14:04:38.340 1 ERROR masakarimonitors.ha.masakari raise cls( masakari-instance-monitor-kbfkv masakari-instance-monitor 2023-12-05 14:04:38.340 1 ERROR masakarimonitors.ha.masakari openstack.exceptions.BadRequestException: BadRequestException: 400: Client Error for url: http://masakari-api.openstack.svc.cluster.local:15868/v1/7b473b7ad14846938c…, Host with name lab-11053-26006-cmp-2 could not be found. PS: i have installed pacemaker-remote on all computes if you could take a look and respond where i went wrong please im mailing you this as i couldnt find any masakari specific channel Thanking you Shubham

2 1

[manila] Cancelling Dec 7th weekly meeting
by Carlos Silva 06 Dec '23

06 Dec '23

Hello Zorillas, As we discussed last week, a bunch of Zorillas will be unable to attend tomorrow's meeting, so we are cancelling it. We will be back with our regular schedule on December 14th. Thanks and regards, carloss

1 0

[Reminder] OpenInfra Live: PTG Recap, Dec 7 at 15 UTC
by Kristin Barrientos 06 Dec '23

06 Dec '23

Hi Everyone, Tune in this week for another episode of OpenInfra Live, brought to you by the OpenStack and StarlingX community! Episode: Join us for a Project Teams Gathering (PTG) recap! Project leaders from Ironic, Technical Committee, Nova, Sunbeam, Manila, Cinder, StarlingX and Neutron will provide recaps from discussions held during the PTG. Date and time: Thursday, Dec 7, 15 UTC YouTube: https://www.youtube.com/live/thidlQGX29M?feature=shared LinkedIn: https://www.linkedin.com/events/7132754094531747840/comments/ WeChat: The recording will be posted on OpenInfra Foundation WeChat after the live stream Speakers: Kendall Nelson, Jay Faulkner, Sylvain Bauza, James Page, Carlos da Silva, Rajat Dhasmana, Steve Geary and Brian Haley Thanks, Kristin Barrientos Marketing Coordinator OpenInfra Foundation

1 0

[keystone] Weekly meeting canceled
by Dave Wilde 06 Dec '23

06 Dec '23

Hello, Unfortunately I have a meeting conflict today and need to cancel the weekly meeting. Please let me know if there is anything y'all need. Thank you! /Dave

2 1

[cinder] 2024.1 (Caracal) R-17 virtual mid cycle (6 Dec, 2023)
by Rajat Dhasmana 06 Dec '23

06 Dec '23

Hello Argonauts, We will be conducting the first midcycle of 2024.1 (Caracal) on 6th December, 2023. Following are the details: Date: 6th December, 2023 Time: 1400-1600 UTC Meeting link: https://meet.google.com/auq-jiem-zxy Etherpad: https://etherpad.opendev.org/p/cinder-caracal-midcycles We have 2 weeks so please add your topics timely. Thanks Rajat Dhasmana

1 1

[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