February 2024 - openstack-discuss

[election][ptl][sunbeam] non-candidacy for Sunbeam
by James Page 23 Feb '24

23 Feb '24

Hi All I'm not going to stand for PTL of the Sunbeam project for the upcoming cycle in order to allow others in the core dev team to stand for this position. Cheers James

1 0

[all][diversity] Final call for mentors and projects for the May 2024 Outreachy round
by Dmitry Tantsur 22 Feb '24

22 Feb '24

Hi folks, Sorry for the late heads-up. We don't currently have any projects submitted for OpenStack this cycle. If you have a project and would like to contribute to make the world a better place, please submit at https://www.outreachy.org/communities/cfp/openstack/ until tomorrow, Feb 23rd, 4pm UTC. Don't hesitate to reach out with any questions! Dmitry

1 0

[antelope][kolla-ansible][magnum]Multidomain problem
by Franck VEDEL 22 Feb '24

22 Feb '24

Hello I'm coming back to you with a new problem, which has already been submitted. I thought it worked with Antelope but maybe not. I have a kolla-ansible installation, antelope, on Ubuntu22.04, multinode. everything works as I want. If I leave only one domain (Default), I add heat and magnum. This works (with /etc/kolla/config/magnum.conf and cluster_user_trust = True). I add a second domain (users from an Active Directory). And there, adding magnum no longer works. When I do a "kolla-ansible reconfigure.....), I get the error: "action": "os_user_role", "changed": false OK, a search gives me this link: https://github.com/ansible/ansible/issues/57099 But I'm in the antelope version. Is this problem still relevant? How can we solve it? Thanks for your advices. Franck.

1 0

kolla-ansible all in one reconfigure fails
by KK CHN 22 Feb '24

22 Feb '24

I have a kolla-ansible all-in-one openstack installation working on a Virtual Machine (Ubuntu22.04 on a ESXi 7.0 host) Reference: https://kifarunix.com/create-and-upload-custom-linux-image-into-openstack/?… All went well and able to get the horizon dashboard and default Cirros image and demo networks up and running. Able to create instances using the default image. To create cloud OS images from the ISO files , I have done additionally the following iinstallation in the same Ubuntu22.04 VM . STEP 1. *$ sudo apt install -y qemu-kvm virt-manager libvirt-daemon-system virtinst libvirt-clients bridge-utils* $ sudo systemctl enable --now libvirtd $ sudo systemctl start libvirtd Everything went well. I am able to get virt-manager up and running and able to create the Cloud Image from an Ubuntu22.04 Server ISO. Then I uploaded this cloud image to the All-IN-ONE kolla-ansible openstack horizon dashboard, the image creation was successful. 2. But when I tried to create an instance by using this image through the horizon dashboard the instance dialog doesn't show any availability zone (nova). I am sure before doing the step 1 I am able to create Linux instances using the default Cirros image multiple times and the instances up and running successfully with the default availability zone "nova" ( I mean kolla-ansible all-in-one openstack installation was working fine before doing the step 1). But now there is no availability zones showing in horizon for creating new instances. Availability Zone There are no Availability Zones. I checked in CLI also $ openstack hypervisor list //it also shows ( down) availability zones also down 3. So I decided to reconfigure the $ kolla-ansible -i all-in-one reconfigure step, but the step fails with the following. RUNNING HANDLER [nova-cell : Restart nova-ssh container] *********************** changed: [localhost] RUNNING HANDLER [nova-cell : Restart nova-libvirt container] ******************* changed: [localhost] RUNNING HANDLER [nova-cell : Checking libvirt container is ready] ************** FAILED - RETRYING: [localhost]: Checking libvirt container is ready (10 retries left). FAILED - RETRYING: [localhost]: Checking libvirt container is ready (9 retries left). FAILED - RETRYING: [localhost]: Checking libvirt container is ready (8 retries left). FAILED - RETRYING: [localhost]: Checking libvirt container is ready (7 retries left). FAILED - RETRYING: [localhost]: Checking libvirt container is ready (6 retries left). FAILED - RETRYING: [localhost]: Checking libvirt container is ready (5 retries left). FAILED - RETRYING: [localhost]: Checking libvirt container is ready (4 retries left). FAILED - RETRYING: [localhost]: Checking libvirt container is ready (3 retries left). FAILED - RETRYING: [localhost]: Checking libvirt container is ready (2 retries left). FAILED - RETRYING: [localhost]: Checking libvirt container is ready (2 retries left). FAILED - RETRYING: [localhost]: Checking libvirt container is ready (1 retries left). fatal: [localhost]: FAILED! => {"attempts": 10, "changed": true, "cmd": "set -o pipefail && docker exec -i nova_libvirt ls /run/libvirtd.pid\n", "delta": "0:00:00.016249", "end": "2024-02-21 16:21:22.750454", "msg": "non-zero return code", "rc": 1, "start": "2024-02-21 16:21:22.734205", "stderr": "Error response from daemon: container 46d139a236f57e41cfcf3121b3879ea01eae774d771415c5418b003c839f3257 is not running", "stderr_lines": ["Error response from daemon: container 46d139a236f57e41cfcf3121b3879ea01eae774d771415c5418b003c839f3257 is not running"], "stdout": "", "stdout_lines": []} Each time I do reconfigure, the reconfiguration fails by reaching the step RUNNING HANDLER [nova-cell : Restart nova-libvirt container] ******************* changed: [localhost] 4. Why it fails, what the root cause of it, I suspect due to step 1 all the errors happened . 4. How can I recover the all-in-one openstack installation back and be able to create instances and images as earlier? Only option is to fresh deploy the kolla-ansible -i all-in-one ? Then all the current VM and images will all be lost ? ( If it in production what the method is to recover ?? OR will loss all data in production by running deployment again ? ) Greetings, Krish

1 1

[manila] Collab Review discussion for Snapshot/Replication based backups for NetApp shares and Generic solution for human readable export locations
by Saravanan Manickam 21 Feb '24

21 Feb '24

Hello Zorillas and other interested stackers, We'll have collab review discussion on a couple of features the NetApp team is building in Caracal release. * Snapshot/Replication based backups for NetApp shares (Gireesh Awasthi) * Generic solution for human readable export locations and relevant implementation for NetApp and LVM drivers (Jayaanand Borra) Date: 22nd February 2024 Time: 1400 UTC https://etherpad.opendev.org/p/ptg-backup-manila https://etherpad.opendev.org/p/manila-share-backup <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fetherpad.…> https://etherpad.opendev.org/p/caracal-ptg-manila-human-readable-export-loc… Zoom: https://netapp.zoom.com/j/96908608436?pwd=aCtNSngxMWVTVlV6Ykx6OW85UDZndz09 Thanks, Saravanan

1 0

[largescale-sig] Next meeting: February 21, 16utc
by Thierry Carrez 21 Feb '24

21 Feb '24

Hi everyone, The Large Scale SIG will be meeting this Wednesday in #openstack-operators on OFTC IRC, at 16UTC, our EU+US time. You can doublecheck how that UTC time translates locally at: https://www.timeanddate.com/worldclock/fixedtime.html?iso=20240221T16 Feel free to add topics to the agenda: https://etherpad.opendev.org/p/large-scale-sig-meeting Regards, -- Thierry Carrez

1 1

Cinder Bug Report 2024-02-21
by Jon Bernard 21 Feb '24

21 Feb '24

Hello Argonauts, Cinder Bug Meeting Etherpad <https://etherpad.opendev.org/p/cinder-bug-squad-meeting> Undecided - IBM SVf : Enable support for force detach of a volume <https://bugs.launchpad.net/cinder/+bug/2054317> - Status: New Thanks, -- Jon

1 0

[keystone] Weekly meeting canceled 21-Feb-24
by Dave Wilde 21 Feb '24

21 Feb '24

Hi folks, Due to a family emergency I’m not able to host the keystone weekly meeting this week and so I am canceling it. Please reach out via email if you need anything from me as my ability to access IRC is limited right now. Thanks! /Dave

1 0

Openstack ansible service variables
by Gk Gk 21 Feb '24

21 Feb '24

Hi, We have an OSA setup. I see that common-playbooks/haproxy-service-config.yml has the following: --- - hosts: "{{ service_group }}" gather_facts: false run_once: true tasks: - name: "Temporarily copy haproxy_service_configs value from {{ service_group }} to haproxy_all" add_host: name: "{{ item }}" haproxy_service_configs: "{{ hostvars[inventory_hostname][service_variable] }}" with_items: "{{ groups['haproxy_all'] }}" How does the openstack ansible collect haproxy configuration for a specific service as in this case for repo service ? Where is this defined in the code ? How does it even generate specific haproxy variables for each service ? How does it specifically know what haproxy variables to collect ?

2 1

Haproxy and rabbitmq
by Gk Gk 21 Feb '24

21 Feb '24

Hi, We have the latest version of openstack setup. The rabbitmq backend health check is getting successful even though the curl to its ssl url is failing as shown below: ---- backend rabbitmq_mgmt-back mode http balance leastconn stick-table type ipv6 size 256k expire 10s store http_err_rate(10s) http-request track-sc0 src http-request deny deny_status 429 if { sc_http_err_rate(0) gt 20 } !{ src 192.168.0.0/16 } !{ src 172.16.0.0/12 } !{ src 10.0.0.0/8 } option forwardfor option httpchk HEAD / HTTP/1.0\r\nUser-agent:\ osa-haproxy-healthcheck server rabbit_mq_container-527affef <ip>:15671 check port 15671 inter 12000 rise 3 fall 3 ssl check-ssl verify none server rabbit_mq_container-68b39094 <IP>:15671 check port 15671 inter 12000 rise 3 fall 3 ssl check-ssl verify none server rabbit_mq_container-83661288 <IP>:15671 check port 15671 inter 12000 rise 3 fall 3 ssl check-ssl verify none ------ But the ssl curl to its ip and port 15671 is failing: 1234567 curl -vvv 172.21.152.187:15671 * Trying 172.21.152.187:15671... * TCP_NODELAY set * connect to 172.21.152.187 port 15671 failed: Connection refused * Failed to connect to 172.21.152.187 port 15671: Connection refused * Closing connection 0 curl: (7) Failed to connect to 172.21.152.187 port 15671: Connection refused How then, the haproxy is still able to detect it as green and status ok in the haproxy stats page ?

3 6