March 2025 - openstack-discuss - lists.openstack.org

[nova] nova-manage fails when upgrading to Antelope
by Roby G 01 Apr '25

01 Apr '25

Hello everyone, I´m trying to upgrade to Antelope and have a problem when executing the db migrations. `nova-manage db sync` fails when upgrading from Zed to Antelope (same for Yoga --> Antelope) - Nova: 27.4.0 - Database: PostgreSQL 16 - Operating System: Ubuntu 22.04 - OpenStack Zed --> Antelope Full Log. /var/log/nova-manage.log: ``` 2025-03-04 11:42:14.963 2519974 INFO alembic.runtime.migration [None req-0e1f6874-3bac-49db-b525-94aebf9e0b51 - - - - - -] Context impl PostgresqlImpl. 2025-03-04 11:42:14.964 2519974 INFO alembic.runtime.migration [None req-0e1f6874-3bac-49db-b525-94aebf9e0b51 - - - - - -] Will assume transactional DDL. 2025-03-04 11:42:14.967 2519974 INFO alembic.runtime.migration [None req-0e1f6874-3bac-49db-b525-94aebf9e0b51 - - - - - -] Running upgrade ccb0fa1a2252 -> 960aac0e09ea, de-duplicate_indexes_in_instances__console_auth_tokens 2025-03-04 11:42:14.970 2519974 WARNING oslo_db.sqlalchemy.exc_filters [None req-0e1f6874-3bac-49db-b525-94aebf9e0b51 - - - - - -] DBAPIError exception wrapped.: psycopg2.errors.DependentObjectsStillExist: cannot drop index uuid because other objects depend on it DETAIL: constraint block_device_mapping_instance_uuid_fkey on table block_device_mapping depends on index uuid constraint consoles_instance_uuid_fkey on table consoles depends on index uuid constraint fixed_ips_instance_uuid_fkey on table fixed_ips depends on index uuid constraint instance_actions_instance_uuid_fkey on table instance_actions depends on index uuid constraint instance_extra_instance_uuid_fkey on table instance_extra depends on index uuid constraint instance_faults_instance_uuid_fkey on table instance_faults depends on index uuid constraint instance_info_caches_instance_uuid_fkey on table instance_info_caches depends on index uuid constraint instance_metadata_instance_uuid_fkey on table instance_metadata depends on index uuid constraint instance_system_metadata_instance_uuid_fkey on table instance_system_metadata depends on index uuid constraint migrations_instance_uuid_fkey on table migrations depends on index uuid constraint security_group_instance_association_instance_uuid_fkey on table security_group_instance_association depends on index uuid constraint virtual_interfaces_instance_uuid_fkey on table virtual_interfaces depends on index uuid HINT: Use DROP ... CASCADE to drop the dependent objects too. 2025-03-04 11:42:14.970 2519974 ERROR oslo_db.sqlalchemy.exc_filters Traceback (most recent call last): 2025-03-04 11:42:14.970 2519974 ERROR oslo_db.sqlalchemy.exc_filters File "/usr/lib/python3/dist-packages/sqlalchemy/engine/base.py", line 1802, in _execute_context 2025-03-04 11:42:14.970 2519974 ERROR oslo_db.sqlalchemy.exc_filters self.dialect.do_execute( 2025-03-04 11:42:14.970 2519974 ERROR oslo_db.sqlalchemy.exc_filters File "/usr/lib/python3/dist-packages/sqlalchemy/engine/default.py", line 732, in do_execute 2025-03-04 11:42:14.970 2519974 ERROR oslo_db.sqlalchemy.exc_filters cursor.execute(statement, parameters) 2025-03-04 11:42:14.970 2519974 ERROR oslo_db.sqlalchemy.exc_filters psycopg2.errors.DependentObjectsStillExist: cannot drop index uuid because other objects depend on it 2025-03-04 11:42:14.970 2519974 ERROR oslo_db.sqlalchemy.exc_filters DETAIL: constraint block_device_mapping_instance_uuid_fkey on table block_device_mapping depends on index uuid 2025-03-04 11:42:14.970 2519974 ERROR oslo_db.sqlalchemy.exc_filters constraint consoles_instance_uuid_fkey on table consoles depends on index uuid 2025-03-04 11:42:14.970 2519974 ERROR oslo_db.sqlalchemy.exc_filters constraint fixed_ips_instance_uuid_fkey on table fixed_ips depends on index uuid 2025-03-04 11:42:14.970 2519974 ERROR oslo_db.sqlalchemy.exc_filters constraint instance_actions_instance_uuid_fkey on table instance_actions depends on index uuid 2025-03-04 11:42:14.970 2519974 ERROR oslo_db.sqlalchemy.exc_filters constraint instance_extra_instance_uuid_fkey on table instance_extra depends on index uuid 2025-03-04 11:42:14.970 2519974 ERROR oslo_db.sqlalchemy.exc_filters constraint instance_faults_instance_uuid_fkey on table instance_faults depends on index uuid 2025-03-04 11:42:14.970 2519974 ERROR oslo_db.sqlalchemy.exc_filters constraint instance_info_caches_instance_uuid_fkey on table instance_info_caches depends on index uuid 2025-03-04 11:42:14.970 2519974 ERROR oslo_db.sqlalchemy.exc_filters constraint instance_metadata_instance_uuid_fkey on table instance_metadata depends on index uuid 2025-03-04 11:42:14.970 2519974 ERROR oslo_db.sqlalchemy.exc_filters constraint instance_system_metadata_instance_uuid_fkey on table instance_system_metadata depends on index uuid 2025-03-04 11:42:14.970 2519974 ERROR oslo_db.sqlalchemy.exc_filters constraint migrations_instance_uuid_fkey on table migrations depends on index uuid 2025-03-04 11:42:14.970 2519974 ERROR oslo_db.sqlalchemy.exc_filters constraint security_group_instance_association_instance_uuid_fkey on table security_group_instance_association depends on index uuid 2025-03-04 11:42:14.970 2519974 ERROR oslo_db.sqlalchemy.exc_filters constraint virtual_interfaces_instance_uuid_fkey on table virtual_interfaces depends on index uuid 2025-03-04 11:42:14.970 2519974 ERROR oslo_db.sqlalchemy.exc_filters HINT: Use DROP ... CASCADE to drop the dependent objects too. 2025-03-04 11:42:14.970 2519974 ERROR oslo_db.sqlalchemy.exc_filters 2025-03-04 11:42:14.970 2519974 ERROR oslo_db.sqlalchemy.exc_filters ``` Any suggestions? Thanks!

3 3

[Octavia]
by Vincent Godin 01 Apr '25

01 Apr '25

Hello Octavia Team, We have an Openstack infrastructure with 3 Nova AZ and 3 Cinder AZ. Furthermore, Octavia will use cinder for Amphora disk. Is there a way to create an Amphora so that the Compute AZ match the Cinder AZ ? As the storage is AZ specific, it's not possible to launch an Amphora on a Compute AZ with a storage on an alternate AZ. As a client, there is no need to fix where the Amphora will be launched, we just want to be sure that if the Amphora is planned to be launched on a specific AZ, its storage will be selected on the corresponding AZ too ! Vincent

3 2

[tc][all] OpenStack Technical Committee Weekly Summary and Meeting Agenda (2025.1/R+0)
by Goutham Pacha Ravi 31 Mar '25

31 Mar '25

Hello Stackers, The release team will be tagging the GA release for all cycle-with-rc projects for 2025.1 ("Epoxy") on 2025-04-02 [1][2]. Remarkably, this will be the 31st release of OpenStack and one of two that will mark 15 years of the community! There will be an OpenInfra Live event on 2025-04-03, where a few project maintainers will reflect on how the release cycle went, what it will bring to users, and project priorities for the 2025.2 ("Flamingo") release cycle [3]. Alongside project teams, the OpenStack Technical Committee has been preparing for the upcoming virtual Project Teams Gathering. We're still gathering topics, so please add yours if you're interested in seeding a relevant discussion. You can find all the discussion etherpads linked on the PTG Website [4]. In the past week, we completed the community testing goal to upgrade CI integration testing ("migrate-to-noble") [5]. Kudos to our goal champion, Ghanshyam Mann (gmann), and to everyone who helped with the effort! === Weekly Meeting === The last weekly meeting of the OpenStack TC was held over IRC in OFTC's #openstack-tc channel on 2025-03-25 [6]. We added a discussion topic on operator engagement to the os-operators' PTG slot. We caught up on CI issues that needed attention from several quarters, including a kernel regression that prevented release-critical patches from merging in Neutron and Kolla and warranted a workaround. A breaking change in Setuptools 78 impacted many projects on Zuul; however, OpenStack was minimally affected before the issue was resolved in Setuptools. A broken CentOS 9 mirror briefly caused problems due to an inconsistent state from an upstream source. It was brought to the TC's attention that the Skyline project commits pre-built static files (e.g., JavaScript bundles generated using Yarn) directly into its repository. This manual intervention creates a potential security risk similar to the XZ backdoor attack since there is no verifiable way to check whether these builds contain malicious code. The TC brainstormed that it would be better to offload the build process to Zuul, preventing manual intervention, and to ensure the yarn.lock file is always included in releases for better traceability. Operators and project contributors must be aware of this issue and the fact that builds are currently not reproducible, complicating packaging. There was a suggestion that OpenStack governance should enforce standardized project security practices. Since we haven't identified concrete steps to resolve the current issue, we'll revisit this topic in a future discussion. The next meeting of the OpenStack TC is today, 2025-04-01, at 1700 UTC. Please note the change in timing—it is an hour earlier than our past meetings. This meeting will be held simultaneously on Video (Zoom) and IRC (OFTC's #openstack-tc channel). Please find the conference details and agenda on the meeting's wiki page [7]. I hope you'll be able to join us there. === Governance Proposals === ==== Merged ==== - Mark CI migration to Ubuntu Noble goal complete | https://review.opendev.org/c/openstack/governance/+/945641 ==== Open for Review ==== - [resolution] Extend scope of VMT to cover all project teams | https://review.opendev.org/c/openstack/governance/+/944817 === Upcoming Events === - 2025-04-01 - 2025-04-04: KubeCon+CloudNativeCon EU: https://events.linuxfoundation.org/kubecon-cloudnativecon-europe/ - 2025-04-02: OpenStack 2025.1 ("Epoxy") Release - 2025-04-03: OpenInfra LIVE - Epoxy release [3] - 2025-04-08: OpenInfra Board Meeting: https://board.openinfra.org/ - 2025-04-07 - 2025-04-12: OpenInfra PTG Thank you very much for reading! On behalf of the OpenStack TC, Goutham Pacha Ravi (gouthamr) OpenStack TC Chair [1] 2025.1 "Epoxy" Release Schedule: https://releases.openstack.org/epoxy/schedule.html [2] 2025.1 Release tags: https://review.opendev.org/c/openstack/releases/+/945949 [3] Introducing OpenStack 2025.1 Epoxy on OpenInfra Live: https://openinfra.org/live/ [4] OpenInfra Flamingo vPTG: https://ptg.opendev.org/ptg.html [5] "migrate to noble" community goal: https://governance.openstack.org/tc/goals/completed/2025.1/migrate-ci-jobs-… [6] TC Meeting IRC Log 2025-03-25: https://meetings.opendev.org/meetings/tc/2025/tc.2025-03-25-18.00.log.html [7] TC Meeting Agenda 2025-04-01: https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting

1 0

[scientific-sig] Wiki update
by Jimmy McArthur 31 Mar '25

31 Mar '25

Hi Scientific Folks! I was trying to direct someone to your meetings, but noticed the wiki page is quite out of date: https://wiki.openstack.org/wiki/Scientific_SIG I know you all are meeting at the PTG, is this something that could be added to the agenda? I’ve got a few orgs that I’d like to send your way. Cheers, Jimmy

1 0

[openstack-helm] Merge openstack-helm and openstack-helm-infra git repos
by Vladimir Kozhukalov 31 Mar '25

31 Mar '25

Hi dear Openstack-Helmers, I would like to suggest merging the two project git repos: https://opendev.org/openstack/openstack-helm-infra.git https://opendev.org/openstack/openstack-helm.git At some point it seemed reasonable to have separate git repos for openstack and infrastructure charts. But now it looks like we are experiencing more cons than pros. When working on some features we are forced to prepare sets of interdependent patches. Some code can be deduplicated. Also when we publish charts we append two commit hashes as package metadata. Also we can reduce the number of test jobs if we have all chats in one repo. Other people also proposed this earlier. So if there are no objections let's make it done. I understand this is going to affect many of our users. Please express your opinions so we don't break any downstream. If we all agree about this, then I would say we can do this in the mid of March/2025 before 2025.2 PTG. The procedure is going to be smth. like 1. Freeze the infra repo and prepare retirement PSs for it 2. Merge openstack-helm-infra repo into openstack-helm ``` git clone https://opendev.org/openstack/openstack-helm.git cd openstack-helm git remote add infra https://opendev.org/openstack/openstack-helm-infra.git git fetch infra git checkout -b infra infra/master git checkout master git merge --allow-unrelated-histories infra # resolve not so many conflicts git review ``` 3. Accept merger PS 4. Update documentation 5. Accept infra retirement PSs (openstack-helm-infra and project-config) -- Best regards, Kozhukalov Vladimir

4 10

[neutron] Bug deputy report March 24 - March 30
by Oleg Bondarev 31 Mar '25

31 Mar '25

Hello Neutron Team, Bug report for the week of March 24 is below: *High:* - https://bugs.launchpad.net/neutron/+bug/2104019 - random failures in L3 HA fullstack failover tests - Confirmed - assigned to Miguel Lavalle - https://bugs.launchpad.net/neutron/+bug/2104134 - ovs/linuxbridge jobs running on ubuntu noble broken with latest kernel 6.8.0-56.58 - Confirmed - unassigned (looks like yatin is tracking it) - https://bugs.launchpad.net/neutron/+bug/2105383 - [OVN] The filter to add the MTU to a LRP changes the options dictionary population - In progress - patch from Rodolfo Alonso: https://review.opendev.org/c/openstack/neutron/+/945905 - https://bugs.launchpad.net/neutron/+bug/2104160 - [DB] Stop expand migrations with field drop exceptions - Confirmed - unassigned ---------- *Low:* - https://bugs.launchpad.net/neutron/+bug/2104927 - [OVN] HA_Chassis_Group creation returns an exception in the logs Edit - In progress - patch from Rodolfo Alonso: https://review.opendev.org/c/openstack/neutron/+/945837 - https://bugs.launchpad.net/neutron/+bug/2104979 - Possible deadlock on closing ip_monitor thread - Triaged - unassigned ---------- *Undecided:* - https://bugs.launchpad.net/neutron/+bug/2104037 - Unable to open stream to ssl::6641 to retrieve schema: Exec format error - Incomplete Thanks, Oleg

1 0

PCI passthrough - flavor not found
by Francesco Di Nucci 31 Mar '25

31 Mar '25

Hi all, I am trying to setup PCI passthrough with Nova, following guides such as this <https://superuser.openinfra.org/articles/a-comprehensive-guide-to-configuri…> and this <https://medium.com/@thomasal14/gpu-passthrough-in-openstack-da2a98a16f7b>: * installed a GPU on a compute node, configured kernel etc and now it is using the vfio-pci driver * set [pci]/device_spec = { "vendor_id": "10de", "product_id": "1ff2" } on compute node (formerly [pci]/passthrough_whitelist) and restarted openstack-nova-* * On the controller node set [pci]/alias: { "vendor_id":"10de", "product_id":"1ff2", "device_type":"type-PCI", "name":"nvidia-t400" }, [filter_scheduler]/enabled_filters = PciPassthroughFilter, [filter_scheduler]/available_filters = nova.scheduler.filters.all_filters and restarted openstack-nova-* * Created a flavor with openstack flavor create --vcpus 4 --ram 8192 --disk 40 --property "pci_passthrough:alias"="nvidia-t400:1" gpu_flavor, it is shown with openstack flavor list * Created an image with --property img_hide_hypervisor_id=true * Tried to create an instance with openstack server create --flavor gpu_flavor --image Almalinux_GPU --key-name "My Key" --network my_network test-gpu (also with --availability-zone nova:my-gpu-node.example.com) * VM creation fails with this errors on the controller node /nova-api.log/ HTTP exception thrown: Flavor gpu_flavor could not be found. /nova-scheduler.log/ Filter PciPassthroughFilter returned 0 hosts Filtering removed all hosts for the request with instance ID '131d5c1c-1927-42c0-bb48-618c05d31c2a'. Filter results: ['PciPassthroughFilter: (start: 19, end: 0)'] /nova-conductor.log/ Failed to schedule instances: nova.exception_Remote.NoValidHost_Remote: No valid host was found. There are not enough hosts available. If I understand correctly it's a cascading error generating from the flavor not found, even though it exists... Anyone has encountered something like this/has suggestions? Am I missing some config? Thanks in advance -- Francesco Di Nucci System Administrator Compute & Networking Service, INFN Naples Email:francesco.dinucci@na.infn.it

6 10

[nova][manila] How to deploy the new Manila virtio-fs driver?
by Thomas Goirand 31 Mar '25

31 Mar '25

Hi, I've quickly discussed with Shean on IRC, and he told me the new virtio-fs driver for Manila was part of Epoxy. This is very exciting. Thanks to everyone who worked on it. I'd like to deploy it, however, I have no clue how. Note that I already implemented the generic driver using (puppet-manila). But I haven't been able to read any doc about it. Is there anything I should know? Also, is there any pending patches that should get on top of Epoxy? Shean already told me about these 2: https://review.opendev.org/c/openstack/python-openstackclient/+/881540 https://review.opendev.org/c/openstack/openstacksdk/+/880056 It'd be IMO super nice if we could them in Epoxy proper (even though I could manage to sneak them as Debian specific patches into my Debian packages). Cheers, Thomas Goirand (zigo)

2 1

[openstack][magnum][keystone] Fail to create clusters with Openstack 2025.1
by Nguyễn Hữu Khôi 29 Mar '25

29 Mar '25

Hello. I am testing magnum_cluster_api v0.29.3 with OPS 2025.1.but I encounter this error:keystoneauth1.exceptions.http.BadRequest: Invalid input for field/attribute trust. Value: {'roles': [{'id': '00c3da32a3384e298256b4293d7d0b9a', 'name': 'load-balancer_member', 'domain_id': None, 'description': None, 'options': {}, 'links': {'self': ' https://k.com:5000/v3/roles/00c3da32a3384e298256b4293d7d0b9a'}}, {'id': '32e8b1f999ae4d2f8d50ffd5a7065e38', 'name': 'manager', 'domain_id': None, 'description': None, 'options': {'immutable': True}, 'links': {'self': ' https://k.com:5000/v3/roles/32e8b1f999ae4d2f8d50ffd5a7065e38'}}, {'id': '4dc61b50010540c4a0e614a1fb23d1ef', 'name': 'admin', 'domain_id': None, 'description': None, 'options': {'immutable': True}, 'links': {'self': ' https://k.com:5000/v3/roles/4dc61b50010540c4a0e614a1fb23d1ef'}}, {'id': '2d722357d74f4c39aab4bc18b5cbe391', 'name': 'member', 'domain_id': None, 'description': None, 'options': {'immutable': True}, 'links': {'self': ' https://k.com:5000/v3/roles/2d722357d74f4c39aab4bc18b5cbe391'}}, {'id': 'efa3d956f74e41b6aa999262d456063b', 'name': 'heat_stack_owner', 'domain_id': None, 'description': None, 'options': {}, 'links': {'self': ' https://k.com:5000/v3/roles/efa3d956f74e41b6aa999262d456063b'}}, {'id': '30b6b07e181e414099a79d0d83cec4a1', 'name': 'reader', 'domain_id': None, 'description': None, 'options': {'immutable': True}, 'links': {'self': ' https://k.com:5000/v3/roles/30b6b07e181e414099a79d0d83cec4a1'}}], 'delegation_depth': 0, 'id': '65fc7dbe686c4efca6f8501ca2b0f4c9', 'trustor_user_id': '36e0dee5ff45410e89ee85c403131b92', 'trustee_user_id': 'b3a05e45b78b4ad1bfd537c84f2ebfa2', 'project_id': '16d98639e9154413843795fd1a4a9bcb', 'impersonation': True, 'expires_at': None, 'remaining_uses': None, 'deleted_at': None, 'redelegated_trust_id': None, 'redelegation_count': 0, 'roles_links': {'self': ' https://k.com:5000/v3/65fc7dbe686c4efca6f8501ca2b0f4c9/roles', 'next': None, 'previous': None}, 'links': {'self': ' https://k.com:5000/v3/OS-TRUST/trusts/65fc7dbe686c4efca6f8501ca2b0f4c9'}}. Additional properties are not allowed ('delegation_depth' was unexpected) (HTTP 400) (Request-ID: req-7520e8ee-8073-4164-b023-4f353721a6c5) 2025-03-29 21:03:54.879 1081 ERROR oslo_messaging.rpc.server 2025-03-29 21:03:54.879 1081 ERROR oslo_messaging.rpc.server During handling of the above exception, another exception occurred: 2025-03-29 21:03:54.879 1081 ERROR oslo_messaging.rpc.server 2025-03-29 21:03:54.879 1081 ERROR oslo_messaging.rpc.server Traceback (most recent call last): 2025-03-29 21:03:54.879 1081 ERROR oslo_messaging.rpc.server File "/var/lib/kolla/venv/lib/python3.12/site-packages/magnum/conductor/handlers/common/trust_manager.py", line 34, in create_trustee_and_trust 2025-03-29 21:03:54.879 1081 ERROR oslo_messaging.rpc.server trust = osc.keystone().create_trust( 2025-03-29 21:03:54.879 1081 ERROR oslo_messaging.rpc.server ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 2025-03-29 21:03:54.879 1081 ERROR oslo_messaging.rpc.server File "/var/lib/kolla/venv/lib/python3.12/site-packages/magnum/common/keystone.py", line 218, in create_trust 2025-03-29 21:03:54.879 1081 ERROR oslo_messaging.rpc.server raise exception.TrustCreateFailed( 2025-03-29 21:03:54.879 1081 ERROR oslo_messaging.rpc.server magnum.common.exception.TrustCreateFailed: Failed to create trust for trustee b3a05e45b78b4ad1bfd537c84f2ebfa2. 2025-03-29 21:03:54.879 1081 ERROR oslo_messaging.rpc.server 2025-03-29 21:03:54.879 1081 ERROR oslo_messaging.rpc.server During handling of the above exception, another exception occurred: 2025-03-29 21:03:54.879 1081 ERROR oslo_messaging.rpc.server 2025-03-29 21:03:54.879 1081 ERROR oslo_messaging.rpc.server Traceback (most recent call last): 2025-03-29 21:03:54.879 1081 ERROR oslo_messaging.rpc.server File "/var/lib/kolla/venv/lib/python3.12/site-packages/oslo_messaging/rpc/server.py", line 174, in _process_incoming 2025-03-29 21:03:54.879 1081 ERROR oslo_messaging.rpc.server res = self.dispatcher.dispatch(message) 2025-03-29 21:03:54.879 1081 ERROR oslo_messaging.rpc.server ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 2025-03-29 21:03:54.879 1081 ERROR oslo_messaging.rpc.server File "/var/lib/kolla/venv/lib/python3.12/site-packages/oslo_messaging/rpc/dispatcher.py", line 309, in dispatch 2025-03-29 21:03:54.879 1081 ERROR oslo_messaging.rpc.server return self._do_dispatch(endpoint, method, ctxt, args) 2025-03-29 21:03:54.879 1081 ERROR oslo_messaging.rpc.server ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 2025-03-29 21:03:54.879 1081 ERROR oslo_messaging.rpc.server File "/var/lib/kolla/venv/lib/python3.12/site-packages/oslo_messaging/rpc/dispatcher.py", line 229, in _do_dispatch 2025-03-29 21:03:54.879 1081 ERROR oslo_messaging.rpc.server result = func(ctxt, **new_args) 2025-03-29 21:03:54.879 1081 ERROR oslo_messaging.rpc.server ^^^^^^^^^^^^^^^^^^^^^^ 2025-03-29 21:03:54.879 1081 ERROR oslo_messaging.rpc.server File "/var/lib/kolla/venv/lib/python3.12/site-packages/osprofiler/profiler.py", line 159, in wrapper 2025-03-29 21:03:54.879 1081 ERROR oslo_messaging.rpc.server result = f(*args, **kwargs) 2025-03-29 21:03:54.879 1081 ERROR oslo_messaging.rpc.server ^^^^^^^^^^^^^^^^^^ 2025-03-29 21:03:54.879 1081 ERROR oslo_messaging.rpc.server File "/var/lib/kolla/venv/lib/python3.12/site-packages/magnum/conductor/handlers/cluster_conductor.py", line 66, in cluster_create 2025-03-29 21:03:54.879 1081 ERROR oslo_messaging.rpc.server trust_manager.create_trustee_and_trust(osc, cluster) 2025-03-29 21:03:54.879 1081 ERROR oslo_messaging.rpc.server File "/var/lib/kolla/venv/lib/python3.12/site-packages/magnum/conductor/handlers/common/trust_manager.py", line 42, in create_trustee_and_trust 2025-03-29 21:03:54.879 1081 ERROR oslo_messaging.rpc.server raise exception.TrusteeOrTrustToClusterFailed( 2025-03-29 21:03:54.879 1081 ERROR oslo_messaging.rpc.server magnum.common.exception.TrusteeOrTrustToClusterFailed: Failed to create trustee or trust for Cluster: 65eec76d-a811-420a-8d9f-7cefdd050f35 2025-03-29 21:03:54.879 1081 ERROR oslo_messaging.rpc.serverCould I have some ideas for this? Thank you. [image: white_check_mark][image: eyes][image: raised_hands] NEW Nguyen Huu Khoi

2 1

[openstack-ansible]: openstack-ansible upgrade from Yoga to Zed
by Rambo Rambo 28 Mar '25

28 Mar '25

Hi Team We are planning openstack-ansible upgrade from Yoga to Zed. Distribution:openstack-ansible Release: Yoga OS - Ubuntu 20.04 I was checking the release notes and can see below point related to neutron linux bridge. We are having linux bridge at the moment. https://docs.openstack.org/releasenotes/openstack-ansible/zed.html =========================================================== - With marking ML2/LinuxBridge driver as ‘Experimental’ in the upstream Neutron project OpenStack-Ansible has switched a default mechanism driver to ML2/OVN. In order to upgrade any existing deployment that was relying on defaults to the new OpenStack-Ansible version you must ensure that following variables are defined explicitly to ensure parity with existing functionality: neutron_plugin_type: ml2.lxbneutron_ml2_drivers_type: "flat,vlan,vxlan,local"neutron_plugin_base: - router - metering Failure to define any of these variables will result in playbook failures and neutron misconfiguration. We have covered this step with upgrade script that will create a user_neutron_migration.yml file with assumed defaults. =================================================== As per above point we need to add new parameters into user_variables file . also it is written "We have covered this step with upgrade script" *Current Configuration:* /etc/neutron/plugins/ml2# *cat ml2_conf.ini* [ml2] type_drivers = flat,vlan,vxlan,local tenant_network_types = vxlan,flat *mechanism_drivers = linuxbridge,l2population* # ML2 flat networks extension_drivers = port_security,subnet_dns_publish_fixed_ip *user_variable file* only has below related parameters : neutron_l2_population: true neutron_plugin_base: - router - neutron_dynamic_routing.services.bgp.bgp_plugin.BgpPlugin neutron_ml2_conf_ini_overrides: ml2: extension_drivers: - port_security - subnet_dns_publish_fixed_ip Can someone please confirm what should be done to take care of above point of the release notes? Regards

2 1