- openstack-discuss - lists.openstack.org

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