January 2024 - openstack-discuss - lists.openstack.org

[kolla-ansible] Static haproxy configuration for manually deployed services
by Jan Wasilewski 29 Jan '24

29 Jan '24

Hi, I wanted to inquire about the possibility of configuring the haproxy service for a non-standard OpenStack service. Specifically, I'm referring to Vault, which I use as a backend for the Barbican service. I would like to configure the haproxy settings somewhat "statically," but I want this configuration to be applied during deployment with kolla-ansible. While inserting non-standard configurations for OpenStack services like Cinder or Barbican in the directory */etc/kolla/config/<openstack_service>/<openstack_service.conf>* works, the same approach doesn't seem to work for haproxy. I have created a configuration for vault.cfg as outlined in [1], but when executing: kolla-ansible -i multinode --tags common,haproxy deploy the configured settings are not being read into the haproxy settings. Am I doing something wrong, or is this functionality not possible in this manner, requiring a different configuration approach? I would appreciate any advice and guidance on this matter. Best regards, /JW References: [1] https://paste.openstack.org/show/bU3ytwRvAopM78S7lg34/

3 3

[kolla-ansible] remove a service and container
by garcetto 29 Jan '24

29 Jan '24

good morning, is it possible to remove a service with kolla-ansible? got the same problems as here ( https://stackoverflow.com/questions/64930136/what-is-the-proper-way-to-remo…) and seems there is no solution ( https://bugs.launchpad.net/kolla-ansible/+bug/1874044) thank you.

2 1

[tc] Technical Committee Meeting Jan 30, 2024 at 1800UTC
by Jay Faulkner 29 Jan '24

29 Jan '24

Hi all, The next meeting of the Technical Committee will be tomorrow, Tuesday January 30 at 1800 UTC in #openstack-tc on OFTC. Please see the proposed agenda below: Agenda - Roll call - Follow up on tracked action items - No action items from Jan 24 meeting. - Gate health check - Implementation of Unmaintained branch statuses - project team guide change: https://review.opendev.org/c/openstack/project-team-guide/+/897505 (in HTML <https://45faea0ad451d95614b7-e39b4e99c90af072f68eb1bcdd078a04.ssl.cf2.rackc…> ) - 2024.1 TC Tracker - https://etherpad.opendev.org/p/tc-2024.1-tracker - Open Discussion and Reviews Thanks, Jay Faulkner OpenStack TC Chair

1 0

Cinder multi availability_zone, nova lookup problems
by Henrik Hansen 29 Jan '24

29 Jan '24

Good evening, we are currently deploying openstack in a two AZ setup, in this setup we have two different SAN FC Boxes which are only reachable via the corresponding zone. Means, we have two cinder instances, each one is configured with a backend service towards the storage. In cinder.conf [storage] we have backend_availability_zone set, towards the correct zone name. If i create two bootable volumes, cinderis selecting the right cinder-schueduler with the right storage: (venv-kolla)# openstack volume create --size 10 --image cirros --availability-zone DUS --bootable DUS_1 +---------------------+--------------------------------------+ | Field | Value | +---------------------+--------------------------------------+ | attachments | [] | | availability_zone | DUS | | bootable | false | | consistencygroup_id | None | | created_at | 2024-01-23T22:22:21.979063 | | description | None | | encrypted | False | | id | 217943c3-44dd-4a8c-aad7-2ab33b17bab3 | | migration_status | None | | multiattach | False | | name | DUS_1 | | properties | | | replication_status | None | | size | 10 | | snapshot_id | None | | source_volid | None | | status | creating | | type | __DEFAULT__ | | updated_at | None | | user_id | 47f5bd8b0f154da69bb2375fcc3a3baf | +---------------------+--------------------------------------+ (venv-kolla)# openstack volume create --size 10 --image cirros --availability-zone LEV --bootable LEV_1 +---------------------+--------------------------------------+ | Field | Value | +---------------------+--------------------------------------+ | attachments | [] | | availability_zone | LEV | | bootable | false | | consistencygroup_id | None | | created_at | 2024-01-23T22:23:12.327244 | | description | None | | encrypted | False | | id | 7850da99-43d0-4b58-9134-a7e7bc930cf0 | | migration_status | None | | multiattach | False | | name | LEV_1 | | properties | | | replication_status | None | | size | 10 | | snapshot_id | None | | source_volid | None | | status | creating | | type | __DEFAULT__ | | updated_at | None | | user_id | 47f5bd8b0f154da69bb2375fcc3a3baf | +---------------------+--------------------------------------+ if i create servers with boot-from-volume and a availability-zone, the job failed. (venv-kolla)# openstack server create --image cirros --boot-from-volume 10 --network fw --flavor m1.tiny --availability-zone DUS DUS1 +-------------------------------------+--------------------------------------+ | Field | Value | +-------------------------------------+--------------------------------------+ | OS-DCF:diskConfig | MANUAL | | OS-EXT-AZ:availability_zone | DUS | | OS-EXT-SRV-ATTR:host | None | | OS-EXT-SRV-ATTR:hypervisor_hostname | None | | OS-EXT-SRV-ATTR:instance_name | | | OS-EXT-STS:power_state | NOSTATE | | OS-EXT-STS:task_state | scheduling | | OS-EXT-STS:vm_state | building | | OS-SRV-USG:launched_at | None | | OS-SRV-USG:terminated_at | None | | accessIPv4 | | | accessIPv6 | | | addresses | | | adminPass | gKsNQTfC6vYe | | config_drive | | | created | 2024-01-23T22:29:47Z | | flavor | m1.tiny (1) | | hostId | | | id | a838b078-cda0-47de-bf5d-0b6cc632425c | | image | N/A (booted from volume) | | key_name | None | | name | DUS1 | | progress | 0 | | project_id | e435c2936cbf4eb9abc38a48181ab9bf | | properties | | | security_groups | name='default' | | status | BUILD | | updated | 2024-01-23T22:29:47Z | | user_id | 47f5bd8b0f154da69bb2375fcc3a3baf | | volumes_attached | | +-------------------------------------+--------------------------------------+ (venv-kolla)# openstack server create --image cirros --boot-from-volume 10 --network fw --flavor m1.tiny --availability-zone LEV LEV1 +-------------------------------------+--------------------------------------+ | Field | Value | +-------------------------------------+--------------------------------------+ | OS-DCF:diskConfig | MANUAL | | OS-EXT-AZ:availability_zone | LEV | | OS-EXT-SRV-ATTR:host | None | | OS-EXT-SRV-ATTR:hypervisor_hostname | None | | OS-EXT-SRV-ATTR:instance_name | | | OS-EXT-STS:power_state | NOSTATE | | OS-EXT-STS:task_state | scheduling | | OS-EXT-STS:vm_state | building | | OS-SRV-USG:launched_at | None | | OS-SRV-USG:terminated_at | None | | accessIPv4 | | | accessIPv6 | | | addresses | | | adminPass | L6vDvCoevTBC | | config_drive | | | created | 2024-01-23T22:30:11Z | | flavor | m1.tiny (1) | | hostId | | | id | 2434f84f-08f3-4e8d-8c8d-67a6b78f2cbe | | image | N/A (booted from volume) | | key_name | None | | name | LEV1 | | progress | 0 | | project_id | e435c2936cbf4eb9abc38a48181ab9bf | | properties | | | security_groups | name='default' | | status | BUILD | | updated | 2024-01-23T22:30:11Z | | user_id | 47f5bd8b0f154da69bb2375fcc3a3baf | | volumes_attached | | +-------------------------------------+--------------------------------------+ in cinder-scheduler.log i see following: Task 'cinder.scheduler.flows.create_volume.ExtractSchedulerSpecTask;volume:create' (93b2aa0f-5cdb-4f13-abdf-416c2b226917) transitioned into state 'SUCCESS' from state 'RUNNING' with result '{'request_spec': RequestSpec(CG_backend=<?>,availability_zones=['nova'] ... The creation of a bootable volume, results in the following log entry: Task 'cinder.scheduler.flows.create_volume.ExtractSchedulerSpecTask;volume:create' (7d6130e8-f9d9-4d3b-bca1-e899690e7855) transitioned into state 'SUCCESS' from state 'RUNNING' with result '{'request_spec': RequestSpec(CG_backend=<?>,availability_zones=['LEV']... So from my understanding, the create request towards nova, results in AvailabilityZone=nova, which the cinder AvailabilityZoneFilter can't handle. Does someone have a idea, how i can fix this behaviour? Thanks in advance! -- Mit freundlichen Grüßen Henrik Hansen

2 1

[devstack] how to change from ovn to ovs?
by garcetto 29 Jan '24

29 Jan '24

good morning, devstack by default install ovn (and in particular l3 ovn agent), BUT i would like to install fwaas v2, that does NOT support ovn, so i would like to set devstack to use plain old ovs, IS IT POSSIBLE? thank you.

3 3

[masakari] How to add blueprint link on masakari meeting agenda?
by 김도균 29 Jan '24

29 Jan '24

3 2

VMs shut themselves down
by Karera Tony 28 Jan '24

28 Jan '24

Hello Team, I have an openstack environment with 4 compute Nodes however yesterday out of the blue, the Instances on one of the compute nodes started shutting themselves down. Then I realized the the compute service was disabled when I checked in Horizon. I enabled it and restarted the instances and all was well but I cant figure out what caused it. I have attached the nova_compute logs here incase someone would like to support https://paste.openstack.org/show/bxqpgjvqT3DlOYWoeejc/ Regards Tony Karera

3 6

[tc][releases][ptl][all] Yoga transition to 'Unmaintained' status
by Brian Rosmaita 26 Jan '24

26 Jan '24

Hello Stackers, The release team has proposed patches to all projects to transition Yoga to Unmaintained status: https://review.opendev.org/q/topic:%22yoga-unmaintained%22 These patches tag stable/yoga with 'yoga-eom' and create the unmaintained/yoga branch. Here is the key takeaway from this email: PLEASE DO NOT MERGE ANYTHING INTO stable/yoga in the short period after it's been tagged yoga-eom and before the stable/yoga branch is deleted. Other to-dos/info: Abandon any open reviews on stable/yoga immediately. (The release team called for final yoga releases back in November 2023 [0].). Feel free to leave a note that abandoned patches can be re-proposed to unmaintained/yoga if the proposer is still interested. This will speed up the branch deletion process. Otherwise, the release team will have to abandon reviews before stable/yoga can be deleted, which obviously will dump more work on the release team that they'll have to squeeze in around all their normal activities. The stable/yoga branches will be deleted by the release team. The global openstack-unmaintained-core team will, by default, handle maintenance of unmaintained/yoga branches (both CI and merging patches). If your project wants to have its own <project>-unmaintained-core team, it's allowed, but you have to create it yourself. For an example, see https://review.opendev.org/c/openstack/project-config/+/902796 More information about Unmaintained branches is contained in this patch to the project-team-guide: https://review.opendev.org/c/openstack/project-team-guide/+/897505 (Given that this is the first time we're doing the transition-to-Unmaintained process, it would be helpful for all interested people to look at the above patch and leave comments and/or requests for clarifications.) Thanks for your attention to this email! [0] https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack…

1 0

Instances Shutting down themselves
by Karera Tony 26 Jan '24

26 Jan '24

Hello Team, For some reason today morning VMs on one of my compute Nodes started shutting down themselves. When I checked in Horizon, I realized that that particular Compute was disabled and I enabled it. I restarted the Instances and all is well now. I have attached the Logs for nova-compute in case someone would like to help. Regards Tony Karera

2 1

[masakari] [masakari-monitors] Feature to monitor hosts by kubernetes
by 김도균 25 Jan '24

25 Jan '24

1 0