January 2025 - openstack-discuss - lists.openstack.org

[keystone] Weekly meeting canceled 29-Jan-25
by Dave Wilde 29 Jan '25

29 Jan '25

Hi folks, Apologies for the late notice but I need to cancel the Keystone weekly meeting today due to a scheduling conflict. Please reach out either here or via IRC if you need anything. Thanks!! /Dave

1 0

[rabbitmq] Need help about RabbitMQ quorum HA mode
by İzzettin Erdem 29 Jan '25

29 Jan '25

Hi, In kolla-ansible yoga environment, rabbitmq queues are set to quorum by default instead of classical mirroring, as it seems they are not replicated (per queue has +0 quorum). We tried to find a solution to handle it in configs, but we couldn't find it and we set queues to be replicated by using CLI commands (rabbitmq-queues grow). Now, my questions are: 1- Why do all rabbitmq queues come as non-replicated by default? 2- How can we set HA mode to quorum queues?

5 5

Nova
by engineer2024 29 Jan '25

29 Jan '25

Does nova support flavors where vcpus of a single flavor can be in mixed modes where some of them are pinned and the rest dedicated ? Say, a flavor has 5 vcpus, I want 2 of them to be of dedicated type and the remaining 3 vcpus to be shared

2 2

[neutron][upgrades] IPv6 Prefix Delegation 'dibbler' driver removal
by Brian Haley 29 Jan '25

29 Jan '25

Hi again Stackers, In 2023, during the Bobcat cycle, the Neutron team changed the IPv6 Prefix Delegation (IPv6 PD) 'dibbler' driver to be an experimental feature [0]. The reason was due to it (dibbler) becoming unmaintained/retired upstream, as well as the low level of testing support we had in Neutron for the feature. So what does this mean? We (the neutron cores) have come to the conclusion that it is time to take the next step and remove the driver from the tree [1]. The framework to support IPv6 PD is *not* being removed, but as this is the only in-tree driver the functionality will no longer be available to end-users. We plan on doing this in the current Epoxy cycle. We realize that there may be deployments using IPv6 PD, although we have not to my knowledge ever received a bug against it, so we think any usage is very small. If there is desire to add an in-tree driver back to the code base, there is an open OVN-related bug for that at [2], we have just not had the interest from downstream customers to warrant the investment in this area. Thanks for reading, -Brian, Neutron PTL [0] https://review.opendev.org/c/openstack/neutron/+/879030 [1] https://review.opendev.org/c/openstack/neutron/+/934283 [2] https://bugs.launchpad.net/neutron/+bug/1895972

1 0

[Octavia][magnum] change timeout value
by Satish Patel 29 Jan '25

29 Jan '25

Folks, I am running magnum-cluster-api (mcapi) with openstack to spin up k8s but now I want to change octavia LB timeout. Is there a way to tell magnum to change the timeout value of LB? loadbalancer.openstack.org/timeout-client-data: "120000" loadbalancer.openstack.org/timeout-member-data: "120000"

1 0

[Nova] Nova-compute service flapping on Antelope
by Jakub Darmach 29 Jan '25

29 Jan '25

Hello, Recently I encountered an interesting issue - nova-compute service started to temporarily lose Rabbit connectivity to regain it after a few seconds on Antelope. The issue was replicated on the test environment, without specific steps to replicate though - it just starts to happen after some time. I pasted a log example in the bug I opened [1]. First we can see rabbit logging closing AMQP connection, followed by nova-compute reporting rabbit server being unreachable, with next message being successful reconnection. Restarting nova-compute services helps temporarily, the issue starts to manifest after a few days. Initially disconnects once every few hours, each time in shorter intervals, to the point it happens every minute or so. Did anyone encounter something similar? [1] https://bugs.launchpad.net/nova/+bug/2092297 Pozdrawiam / Best regards, *Jakub Darmach*

3 2

[administrivia] Bounce processing disabled for now
by Jeremy Stanley 29 Jan '25

29 Jan '25

Due to repeated challenges with random messages being rejected by subscribers' mail providers (from DMARC invalidations, lines too long to be forwarded, content misidentified as spam, et cetera), the time required for list administrators to manage the resulting extra work is greater than the benefit we get from Mailman being able to figure out when subscriber addresses become defunct. As such, I've disabled the "bounce processing" feature for the time being, until we can work out solutions to make it less of a burden on our list admins and less confusing/failure prone for the list subscribers. If we do decide to give it another try at some point in the future, after some of the current challenges with it get ironed out, I'll let the list know. -- Jeremy Stanley

1 0

openstack-discuss-owner mailbox
by Albert Braden 29 Jan '25

29 Jan '25

Is anyone manning the openstack-discuss-owner mailbox? I've been writing to that address about the recent glitch that deleted my list subscription and account (and according to the error message, hundreds of others), but I'm not getting a response.

2 3

[publiccloud-sig] Public Cloud SIG Meeting this week
by Felix Kronlage-Dammers 29 Jan '25

29 Jan '25

Hi everyone, This upcoming Wednesday (January 29th) the next meeting of the publiccloud-sig is going to happen or at least would happen: However I’ll not be around tomorrow to facilitate and I did not get any feedback from anyone else on it. Usually we would be meeting at 0800 UTC here: https://meetpad.opendev.org/publiccloud-sig - so give it a shot ;) See also here for all other details: https://wiki.openstack.org/wiki/PublicCloudSIG felix -- Felix Kronlage-Dammers Tel.: +49-30-206539-205 | Matrix: @fkronlage:matrix.org | fkr(a)osb-alliance.com

1 0

[ops][neutron] Neutron-db-manage upgrade from Antelope to Bobcat fails with "foreign key constraint 'porthints_ibfk_1' are incompatible" error
by federica fanzago 28 Jan '25

28 Jan '25

Dear all, we are running an OpenStack deployment Yoga on AlmaLinux 9.5 and we are attempting the upgrade Openstack up to Caracal release, one release at time (Zed--Antelope--Bobcat--Caracal) The procedure we are following is to shut down all openstack services, to remove the "old" openstack release and to install the new one, upgrading all service databases. This procedure works well for Zed and Antelope, but during the installation of the Bobcat release, the Neutron database upgrade fails when creating the new "porthints" table. The command we are using is su -s /bin/sh -c "neutron-db-manage --config-file /etc/neutron/neutron.conf --config-file /etc/neutron/plugins/ml2/ml2_conf.ini upgrade head" neutron and the error message we receive is ... File "/usr/lib/python3.9/site-packages/pymysql/err.py", line 107, in raise_mysql_exception raise errorclass(errno, errval) sqlalchemy.exc.OperationalError: (pymysql.err.OperationalError) (3780, "Referencing column 'port_id' and referenced column 'id' in foreign key constraint 'porthints_ibfk_1' are incompatible.") [SQL: CREATE TABLE porthints ( port_id VARCHAR(36) NOT NULL, hints VARCHAR(4095) NOT NULL, PRIMARY KEY (port_id), FOREIGN KEY(port_id) REFERENCES ports (id) ON DELETE CASCADE )ENGINE=InnoDB ... Our "ports" table uses the collation utf8mb3_general_ci mysql> SHOW FULL COLUMNS FROM ports; +------------------+--------------+--------------------+------+-----+---------+-------+---------------------------------+---------+ | Field | Type | Collation | Null | Key | Default | Extra | Privileges | Comment | +------------------+--------------+--------------------+------+-----+---------+-------+---------------------------------+---------+ | project_id | varchar(255) | utf8mb3_general_ci | YES | MUL | NULL | | select,insert,update,references | | | id | varchar(36) | utf8mb3_general_ci | NO | PRI | NULL | | select,insert,update,references | | | name | varchar(255) | utf8mb3_general_ci | YES | | NULL | | select,insert,update,references | | | network_id | varchar(36) | utf8mb3_general_ci | NO | MUL | NULL | | select,insert,update,references | | | mac_address | varchar(32) | utf8mb3_general_ci | NO | | NULL | | select,insert,update,references | | | admin_state_up | tinyint(1) | NULL | NO | | NULL | | select,insert,update,references | | | status | varchar(16) | utf8mb3_general_ci | NO | | NULL | | select,insert,update,references | | | device_id | varchar(255) | utf8mb3_general_ci | NO | MUL | NULL | | select,insert,update,references | | | device_owner | varchar(255) | utf8mb3_general_ci | NO | | NULL | | select,insert,update,references | | | standard_attr_id | bigint | NULL | NO | UNI | NULL | | select,insert,update,references | | | ip_allocation | varchar(16) | utf8mb3_general_ci | YES | | NULL | | select,insert,update,references | | +------------------+--------------+--------------------+------+-----+---------+-------+---------------------------------+---------+ in Bobcat the collation required for the new "porthints" table is latin1_swedish_ci MariaDB [neutron]> show create table porthints; +-----------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Table | Create Table | +-----------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | porthints | CREATE TABLE `porthints` ( `port_id` varchar(36) NOT NULL, `hints` varchar(4095) NOT NULL, PRIMARY KEY (`port_id`), CONSTRAINT `porthints_ibfk_1` FOREIGN KEY (`port_id`) REFERENCES `ports` (`id`) ON DELETE CASCADE ) ENGINE=InnoDB DEFAULT CHARSET=latin1 COLLATE=latin1_swedish_ci | So, we have tried to create the porthints table in mysql, forcing the collation to utf8mb3_general_ci mysql> CREATE TABLE porthints ( port_id VARCHAR(36) NOT NULL, hints VARCHAR(4095) NOT NULL, PRIMARY KEY (port_id), FOREIGN KEY(port_id) REFERENCES ports (id) ON DELETE CASCADE )ENGINE=InnoDB DEFAULT CHARSET=utf8 DEFAULT COLLATE utf8mb3_general_ci; and commenting out the creation of the new table in the neutron code /usr/lib/python3.9/site-packages/neutron/db/migration/alembic_migrations/versions/2023.2/expand/6f1145bff34c_port_hints.py. In this way, the upgrade works, but we encounter the same kind of problem during the upgrade to Caracal, specifically with the creation of the new table porthardwareoffloadtype. Have you already encountered this issue during the Neutron upgrade? Do you have any suggestions on how to upgrade the neutron DB, without manually creating new tables? Thanks a lot, cheers, Federica -- Federica Fanzago INFN Sezione di Padova Via Marzolo, 8 35131 Padova - Italy Tel: +39 049.967.7367 --

2 3