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

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 29 Jan '24

29 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 27 Jan '24

27 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 김도균 26 Jan '24

26 Jan '24

1 0

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

26 Jan '24

1 0

[masakari] [masakari-monitors] Feature to monitor hosts by kubernetes
by d0gyun.kim＠samsung.com 26 Jan '24

26 Jan '24

Hi team masakari I'm do-gyun kim working on SAMSUNG SDS in Seoul. We are using openstack on kubernetes and also masakari for HA. We have developed a function internally to masakari-monitors for k8s-native openstack and want to contribute! blueprint: https://blueprints.launchpad.net/masakari/+spec/host-monitors-by-kubernetes

1 0

[swift][acl][s3api] Manage Container ACL
by Thiago De Moraes Teixeira 26 Jan '24

26 Jan '24

Hi, How can I grant access for other users in my bucket, using s3api, using tempauth (locally tests) and keystone? With: *aws s3api put-bucket-acl --bucket bucket --grant-full-control id=test:tester* (tempauth) I can confirm that this acl was updated inside the container metadata, in container.db, like this *"X-Container-Sysmeta-S3Api-Acl": [ "{\"Owner\":\"thiago:th\",\"Grant\":[{\"Permission\":\"FULL_CONTROL\",\"Grantee\":\"test:tester\"}]}", "1706210273.48975" ]* But when authenticated by test:tester, I can't read/write to that container. -- _‘Esta mensagem é direcionada apenas para os endereços constantes no cabeçalho inicial. Se você não está listado nos endereços constantes no cabeçalho, pedimos-lhe que desconsidere completamente o conteúdo dessa mensagem e cuja cópia, encaminhamento e/ou execução das ações citadas estão imediatamente anuladas e proibidas’._ * **‘Apesar do Magazine Luiza tomar todas as precauções razoáveis para assegurar que nenhum vírus esteja presente nesse e-mail, a empresa não poderá aceitar a responsabilidade por quaisquer perdas ou danos causados por esse e-mail ou por seus anexos’.*

1 0