May 2024 - openstack-discuss - lists.openstack.org

Live migration fails
by Szabo, Istvan (Agoda) 06 Aug '24

06 Aug '24

Hi, I have couple of compute nodes where the live migration fails with existing vms. When I quickly spawn a vm and try live migration it works so I assume shouldn't be a big problem with the compute node. However I have many existing vms where it fails with a servername not found. /var/log/nova/nova-conductor.log:2021-04-21 14:47:12.605 227612 ERROR nova.conductor.tasks.migrate [req-f4067a26-a233-4673-8c07-9a8a290980b0 dce35e6eceea4312bb0baa0510cef363 ca7e35079f4440c78bd9870724b9638b - default default] [instance: 1517a2ac-3b51-4d8d-80b3-89a5614d1ae0] Unable to find record for source node servername on servername: ComputeHostNotFound: Compute host servername could not be found. /var/log/nova/nova-conductor.log:2021-04-21 14:47:12.605 227612 WARNING nova.scheduler.utils [req-f4067a26-a233-4673-8c07-9a8a290980b0 dce35e6eceea4312bb0baa0510cef363 ca7e35079f4440c78bd9870724b9638b - default default] Failed to compute_task_migrate_server: Compute host servername could not be found.: ComputeHostNotFound: Compute host servername could not be found. /var/log/nova/nova-conductor.log:2021-04-21 14:47:12.605 227612 WARNING nova.scheduler.utils [req-f4067a26-a233-4673-8c07-9a8a290980b0 dce35e6eceea4312bb0baa0510cef363 ca7e35079f4440c78bd9870724b9638b - default default] [instance: 1517a2ac-3b51-4d8d-80b3-89a5614d1ae0] Setting instance to ACTIVE state.: ComputeHostNotFound: Compute host servername could not be found. /var/log/nova/nova-conductor.log:2021-04-21 14:47:12.672 227612 ERROR oslo_messaging.rpc.server [req-f4067a26-a233-4673-8c07-9a8a290980b0 dce35e6eceea4312bb0baa0510cef363 ca7e35079f4440c78bd9870724b9638b - default default] Exception during message handling: ComputeHostNotFound: Compute host am-osfecn-4025 Tried with this command: nova live-migration --block-migrate id. Any idea? Thank you. ________________________________ This message is confidential and is for the sole use of the intended recipient(s). It may also be privileged or otherwise protected by copyright or other legal rules. If you have received it by mistake please let us know by reply email and delete it from your system. It is prohibited to copy this message or disclose its content to anyone. Any confidentiality or privilege is not waived or lost by any mistaken delivery or unauthorized disclosure of the message. All messages sent to and from Agoda may be monitored to ensure compliance with company policies, to protect the company's interests and to remove potential malware. Electronic messages may be intercepted, amended, lost or deleted, or contain viruses.

5 16

[openstack][kolla-ansible]about upgrading openstack
by Nguyễn Hữu Khôi 04 Aug '24

04 Aug '24

Hello. I read this doc about upgrading openstack https://docs.openstack.org/kolla-ansible/latest/user/operating-kolla.html But I would like to know if We install a new kolla-ansible(version to upgrade) on the new deployment host, apply changes with password.yml, global.yml and multinode and keep old /etc/kolla/config. Finally, we use kolla-ansible deploy instead of kolla-ansible upgrade. Are these steps ok? Pls correct me if I am wrong. Thank you. Regards Nguyen Huu Khoi

3 8

[kuryr][tc] Final call for Kuryr PTL/DPL liaisons
by Ghanshyam Mann 05 Jul '24

05 Jul '24

Hello Everyone, Kuryr project ends up being a leaderless project for the 2024.2 Dalmatian cycle[1]. There is no volunteer to serve as PTL or DPL liaisons yet. As the next step, I have proposed to mark this project Inactive: - https://review.opendev.org/c/openstack/governance/+/916945 If you would like to serve as a leader and help maintain this project, this is the right time to step up by replying to this email or commenting in gerrit change 916945. [1] https://etherpad.opendev.org/p/2024.2-leaderless#L99 Ref: https://governance.openstack.org/tc/reference/emerging-technology-and-inact… -gmann

4 9

[kolla-ansible][letsencrypt] containers are running but not getting certificates.
by Jonathan Proulx 03 Jul '24

03 Jul '24

Hi All, I'm trying to do a test multinode deploy using 2023.2 I have letsencrypt_webserver and letsencrypt_lego contsainers running and I'm seeing random traffic in the /var/log/kolla/letsencrypt/letsencrypt-webserver-access.log so fairly confident they're plumbed through to the public internet properly, but I don't seem to be getting certificates. how can I trigger a renewal attempt so I can maybe see what I've screwed up? Thanks, -Jon -- Jonathan Proulx (he/him) Sr. Technical Architect The Infrastructure Group MIT CSAIL

3 6

[tc][all][monasca ] Retiring the Monasca project
by Ghanshyam Mann 03 Jul '24

03 Jul '24

Hello everyone, As you might know, the Monasca project is not active and was marked 'inactive' since 2024.1 cycle[1]. In this cycle also, this project is leaderless[2] and no maintainer stepped up to maintain it. As discussed in the Leaderless project etherpad[2], the next step is to retire the project. I'm sending this email to propose the Monasca retirement and based on the response, I will proceed next. [1] https://governance.openstack.org/tc/reference/emerging-technology-and-inact… [2] https://etherpad.opendev.org/p/2024.2-leaderless#L72 -gmann

6 14

[barbican][openstack-helm][tacker] Request to Include Barbican Installation Guide in OpenStack-Helm Documentation
by JUSO WATARU(十楚　航) 20 Jun '24

20 Jun '24

Hello, We are presently in the process of enhancing the official OpenStack-Helm documentation by including a procedural guide for deploying Tacker using helmchart. Through discussions with members of the openstack-helm community, it has been emphasized that Barbican is an indispensable component for Tacker. Hence, it would be highly beneficial for users to have comprehensive instructions for installing Barbican with helmchart included in the official OpenStack-Helm documentation [1]. Consequently, we suggest that the Barbican community integrate the installation guide for the Barbican component into the official OpenStack-Helm documentation. This addition is poised to significantly enhance the clarity and accessibility of deployment procedures for users. We eagerly welcome your opinions and feedback on this proposal, as we aim to ensure that the documentation for openstack deployment with helmchart meets the needs of our community. [1] https://docs.openstack.org/openstack-helm/latest/install/openstack.html Regards, Wataru

2 2

Issue in Stack.sh
by Lohit S 13 Jun '24

13 Jun '24

How to fix this issue while stack.sh is executed +functions-common:_run_under_systemd:1655 sudo systemctl start devstack(a)q-svc.service +functions-common:run_process:1687 time_stop run_process +functions-common:time_stop:2421 local name +functions-common:time_stop:2422 local end_time +functions-common:time_stop:2423 local elapsed_time +functions-common:time_stop:2424 local total +functions-common:time_stop:2425 local start_time +functions-common:time_stop:2427 name=run_process +functions-common:time_stop:2428 start_time=1716869530330 +functions-common:time_stop:2430 [[ -z 1716869530330 ]] ++functions-common:time_stop:2433 date +%s%3N +functions-common:time_stop:2433 end_time=1716869534546 +functions-common:time_stop:2434 elapsed_time=4216 +functions-common:time_stop:2435 total=16163 +functions-common:time_stop:2437 _TIME_START[$name]= +functions-common:time_stop:2438 _TIME_TOTAL[$name]=20379 +lib/neutron:start_neutron_service_and_check:640 neutron_url= http://192.168.122.150:9696/ +lib/neutron:start_neutron_service_and_check:642 is_service_enabled tls-proxy +functions-common:is_service_enabled:2077 return 1 +lib/neutron:start_neutron_service_and_check:646 '[' '!' -z networking ']' +lib/neutron:start_neutron_service_and_check:647 neutron_url= http://192.168.122.150:9696/networking +lib/neutron:start_neutron_service_and_check:649 echo 'Waiting for Neutron to start...' Waiting for Neutron to start... +lib/neutron:start_neutron_service_and_check:651 local 'testcmd=wget --no-proxy -q -O- http://192.168.122.150:9696/networking' +lib/neutron:start_neutron_service_and_check:652 test_with_retry 'wget --no-proxy -q -O- http://192.168.122.150:9696/networking' 'Neutron did not start' 60 +functions-common:test_with_retry:2359 local 'testcmd=wget --no-proxy -q -O- http://192.168.122.150:9696/networking' +functions-common:test_with_retry:2360 local 'failmsg=Neutron did not start' +functions-common:test_with_retry:2361 local until=60 +functions-common:test_with_retry:2362 local sleep=0.5 +functions-common:test_with_retry:2364 time_start test_with_retry +functions-common:time_start:2407 local name=test_with_retry +functions-common:time_start:2408 local start_time= +functions-common:time_start:2409 [[ -n '' ]] ++functions-common:time_start:2412 date +%s%3N +functions-common:time_start:2412 _TIME_START[$name]=1716869535329 +functions-common:test_with_retry:2365 timeout 60 sh -c 'while ! wget --no-proxy -q -O- http://192.168.122.150:9696/networking; do sleep 0.5; done' +functions-common:test_with_retry:2366 die 2366 'Neutron did not start' +functions-common:die:285 local exitcode=0 [Call Trace] ./stack.sh:1322:start_neutron_service_and_check /home/lohit22/opensource/openstack/devstack/Org/devstack/lib/neutron:652:test_with_retry /home/lohit22/opensource/openstack/devstack/Org/devstack/functions-common:2366:die [ERROR] /home/lohit22/opensource/openstack/devstack/Org/devstack/functions-common:2366 Neutron did not start exit_trap: cleaning up child processes Error on exit

2 2

[openstack charm][tc] openstack-charms still need PTL appointment
by Ghanshyam Mann 11 Jun '24

11 Jun '24

Hello Felipe, openstack-charm team, I tried to reach out to you on IRC but could not connect. This is regarding openstack-charm PTL appointment for the 2024.2 cycle. I am not sure if you noticed or not but there are some comments for you to fix on your PTL appointment. Please check the below Gerrit change and fix the same or let us know if there is a change in the plan. - https://review.opendev.org/c/openstack/governance/+/914254 -gmann

2 3

[swift] clean up orphan segment parts
by Rafael Tavares Oliveira 07 Jun '24

07 Jun '24

Hey there! We've been using swift and we came across this bug https://bugs.launchpad.net/swift/+bug/1813202. We decided to work it out and have an ongoing patch to solve this issue alongside ronaldo.maia(a)luizalabs.com, we would like to share and get some feedback before we submit it. To solve this, we took inspiration in obj/expirer.py: In S3 controllers we register task objects in an internal account, each task object points to an orphaned slo object, which can be created in two situations, when a multipart-upload is not completed or when a multipart object is overwritten. These tasks will be checked by the daemon (a new one we made called "s3-slo-expirer") after some time and deleted from the base accounts. Rafael

2 2

[all][tc] Eventlet migration: Call to action
by Jay Faulkner 07 Jun '24

07 Jun '24

Hi all, As you may have read in Goutham's TC summary, the existing eventlet goal[0] is unlikely to gain consensus to merge. This appears to be due to the difference in needs between OpenStack projects, and belief that it's unlikely a single solution would serve them all. Our current situation is: 1) Eventlet usage must be discontinued. The temporary maintainers are just that -- temporary -- and we should not expect eventlet to continue to be a valid path moving forward. 2) We have basic agreement that shared tooling, such as oslo libraries, should not dictate a specific threading model. In lieu of specific technical leadership and guidance from the TC, this leaves it to individual projects to decide what threading model to use instead of eventlet monkey patching. The unmerged spec[0] may be a good starting point if you're wondering where to start. Importantly: do not let this work wait! It is a significant change and will take a long time to complete. Thanks, Jay Faulkner 0: https://review.opendev.org/c/openstack/governance/+/902585

6 7