June 2022 - openstack-discuss - lists.openstack.org

[cinder] Failed to delete volume
by Michal Arbet 15 Jun '22

15 Jun '22

Hi, I would like to ask if someone saw issue when volume failed to delete, log below : This is happening from time to time. LOG : https://paste.opendev.org/show/b1jRCxuBFnnVzf64i9yV/ Thanks, Michal Arbet Openstack Engineer Ultimum Technologies a.s. Na Poříčí 1047/26, 11000 Praha 1 Czech Republic +420 604 228 897 michal.arbet(a)ultimum.io *https://ultimum.io <https://ultimum.io/>* LinkedIn <https://www.linkedin.com/company/ultimum-technologies> | Twitter <https://twitter.com/ultimumtech> | Facebook <https://www.facebook.com/ultimumtechnologies/timeline>

4 5

[qa][refstack][python-tempestconf] adding image
by Mohammed Naser 15 Jun '22

15 Jun '22

Hi there, I'm wondering if the python-tempestconf team is open to publishing Docker images that contain `python-tempestconf`. This is something that we have a need for downstream but we'd be happy to contribute upstream. The main thing is that we'd need to setup an organization on Docker hub to publish things to. Is that something that the team is interested in? We can contribute it if that is the case. Thanks, Mohammed -- Mohammed Naser VEXXHOST, Inc.

3 2

New install on CentOS: what versions, etc.?
by Ken D'Ambrosio 15 Jun '22

15 Jun '22

Hey, all. We're currently running (I hope you're sitting) Juno, and we're thinking about rolling out a new OpenStack version. My boss has asked me if CentOS 7.9 a) would be supported for control/compute nodes, and, if so, if there are any long-term potential issues, and b) if there would be any concerns about versions of client OSes. Thanks! -Ken

3 2

[interop][refstack][summit] Interoperability testing feedback
by Martin Kopec 15 Jun '22

15 Jun '22

Hi everyone, we got great feedback during the summit, if you wanna check the topics we discussed, see this etherpad [1]. Feel also free to add additional concerns with the current interop processes. I was happy to see that many of you are thinking about interoperability and want to improve the testing in this regard. IWG has been seeking feedback from operators as well as users for some time now to make sure it helps with interoperability as much as possible. If you haven't already, please fill out this short (2-3 min) questionnaire [2]. Public Cloud SIG hosted an interesting session in terms of interoperability testing as well, see their etherpad [3]. I'm sure that you'll see further communication in that regard soon. I look forward to future collaboration between IWG and Public Cloud SIG. [1] https://etherpad.opendev.org/p/Berlin2022-Forum-InteropWG [2] https://forms.gle/YW95Hb2LoppaiLxv8 [3] https://etherpad.opendev.org/p/berlin-summit-future-public-cloud-sig Regards, -- Martin Kopec Senior Software Quality Engineer Red Hat EMEA IM: kopecmartin

1 0

[keystone] Getting a token from existing token
by hai wu 14 Jun '22

14 Jun '22

Is it possible to get a new token from an existing token, and at the same time, to have the new token expiration time extended? (token renewal from existing token) It seems the token expiration time is not extended when trying the same curl command as shown in section "Getting a token from a token" in this doc: https://docs.openstack.org/keystone/train/api_curl_examples.html. Quote: curl -i \ -H "Content-Type: application/json" \ -d ' { "auth": { "identity": { "methods": ["token"], "token": { "id": "'$OS_TOKEN'" } } } }' \ "http://localhost:5000/v3/auth/tokens" ; echo

1 0

Re: snapshot problem
by Eugen Block 14 Jun '22

14 Jun '22

You should respond to the list so other users can try to support you. So nova is trying to live snapshot the instance: > 2022-06-12 16:25:55.603 7 INFO nova.compute.manager > [req-5ecfdf74-7cf3-481a-aa12-140deae202f7 > 4dbffaa9c14e401c8c210e23ebe0ab7b ef940663426b4c87a751afaf13b758e0 - > default default] [instance: 25c8d676-e20a-4238-a45c-d51daa62b941] > instance snapshotting > [...] [instance: 25c8d676-e20a-4238-a45c-d51daa62b941] Beginning > live snapshot process But I don't see any 'rbd snap create' command. Either the rbd image doesn't support it or there is some setting to keep all rbd images "flat". Can you check any relevant configs you might have in nova? Also can you show the output of 'rbd info <pool>/25c8d676-e20a-4238-a45c-d51daa62b941_disk' ? Then to test if the underlying rbd functions work as expected you could try to create a live snapshot manually: rbd snap create <pool>/25c8d676-e20a-4238-a45c-d51daa62b941_disk@test-snap And paste any relevant output here. Zitat von Parsa Aminian <p.aminian.server(a)gmail.com>: > Its not working for any instances and all of them are paused . I enable > debug logs please check the logs : > > 2022-06-12 16:16:13.478 7 DEBUG nova.compute.manager > [req-2ecf34c3-72e7-4f33-89cb-9b250cd6d223 - - - - -] Triggering sync for > uuid 25c8d676-e20a-4238-a45c-d51daa62b941 _sync_power_states > /var/lib/kolla/venv/lib/python3.6/site-packages/nova/compute/manager.py:9693 > 2022-06-12 16:16:13.506 7 DEBUG oslo_concurrency.lockutils [-] Lock > "25c8d676-e20a-4238-a45c-d51daa62b941" acquired by > "nova.compute.manager.ComputeManager._sync_power_states.<locals>._sync.<locals>.query_driver_power_state_and_sync" > :: waited 0.000s inner > /var/lib/kolla/venv/lib/python3.6/site-packages/oslo_concurrency/lockutils.py:359 > 2022-06-12 16:16:43.562 7 DEBUG nova.compute.resource_tracker > [req-2ecf34c3-72e7-4f33-89cb-9b250cd6d223 - - - - -] Instance > 25c8d676-e20a-4238-a45c-d51daa62b941 actively managed on this compute host > and has allocations in placement: {'resources': {'VCPU': 1, 'MEMORY_MB': > 1024, 'DISK_GB': 20}}. _remove_deleted_instances_allocations > /var/lib/kolla/venv/lib/python3.6/site-packages/nova/compute/resource_tracker.py:1539 > 2022-06-12 16:25:55.104 7 DEBUG nova.compute.manager > [req-5ecfdf74-7cf3-481a-aa12-140deae202f7 4dbffaa9c14e401c8c210e23ebe0ab7b > ef940663426b4c87a751afaf13b758e0 - default default] [instance: > 25c8d676-e20a-4238-a45c-d51daa62b941] Checking state _get_power_state > /var/lib/kolla/venv/lib/python3.6/site-packages/nova/compute/manager.py:1569 > 2022-06-12 16:25:55.603 7 INFO nova.compute.manager > [req-5ecfdf74-7cf3-481a-aa12-140deae202f7 4dbffaa9c14e401c8c210e23ebe0ab7b > ef940663426b4c87a751afaf13b758e0 - default default] [instance: > 25c8d676-e20a-4238-a45c-d51daa62b941] instance snapshotting > 63426b4c87a751afaf13b758e0 - default default] [instance: > 25c8d676-e20a-4238-a45c-d51daa62b941] Beginning live snapshot process > default default] Lazy-loading 'pci_devices' on Instance uuid > 25c8d676-e20a-4238-a45c-d51daa62b941 obj_load_attr > /var/lib/kolla/venv/lib/python3.6/site-packages/nova/objects/instance.py:1101 > 2022-06-12 16:25:57.250 7 DEBUG nova.objects.instance > [req-5ecfdf74-7cf3-481a-aa12-140deae202f7 4dbffaa9c14e401c8c210e23ebe0ab7b > ef940663426b4c87a751afaf13b758e0 - default default] Lazy-loading > 'pci_devices' on Instance uuid 25c8d676-e20a-4238-a45c-d51daa62b941 > obj_load_attr > /var/lib/kolla/venv/lib/python3.6/site-packages/nova/objects/instance.py:1101 > 2022-06-12 16:25:57.317 7 DEBUG nova.virt.driver [-] Emitting event > <LifecycleEvent: 1655034957.3158934, 25c8d676-e20a-4238-a45c-d51daa62b941 > => Paused> emit_event > /var/lib/kolla/venv/lib/python3.6/site-packages/nova/virt/driver.py:1704 > 2022-06-12 16:25:57.318 7 INFO nova.compute.manager [-] [instance: > 25c8d676-e20a-4238-a45c-d51daa62b941] VM Paused (Lifecycle Event) > 2022-06-12 16:25:57.389 7 DEBUG nova.compute.manager > [req-40444d74-f2fa-4569-87dd-375139938e81 - - - - -] [instance: > 25c8d676-e20a-4238-a45c-d51daa62b941] Checking state _get_power_state > /var/lib/kolla/venv/lib/python3.6/site-packages/nova/compute/manager.py:1569 > 2022-06-12 16:25:57.395 7 DEBUG nova.compute.manager > [req-40444d74-f2fa-4569-87dd-375139938e81 - - - - -] [instance: > 25c8d676-e20a-4238-a45c-d51daa62b941] Synchronizing instance power state > after lifecycle event "Paused"; current vm_state: active, current > task_state: image_pending_upload, current DB power_state: 1, VM > power_state: 3 handle_lifecycle_event > /var/lib/kolla/venv/lib/python3.6/site-packages/nova/compute/manager.py:1299 > 2022-06-12 16:25:57.487 7 INFO nova.compute.manager > [req-40444d74-f2fa-4569-87dd-375139938e81 - - - - -] [instance: > 25c8d676-e20a-4238-a45c-d51daa62b941] During sync_power_state the instance > has a pending task (image_pending_upload). Skip. > 2022-06-12 16:26:02.039 7 DEBUG oslo_concurrency.processutils > [req-5ecfdf74-7cf3-481a-aa12-140deae202f7 4dbffaa9c14e401c8c210e23ebe0ab7b > ef940663426b4c87a751afaf13b758e0 - default default] Running cmd > (subprocess): qemu-img convert -t none -O raw -f raw > rbd:vms/25c8d676-e20a-4238-a45c-d51daa62b941_disk:id=cinder:conf=/etc/ceph/ceph.conf > /var/lib/nova/instances/snapshots/tmpv21b_i59/8717dec4c99c4ef7bac752e2a48690ad > execute > /var/lib/kolla/venv/lib/python3.6/site-packages/oslo_concurrency/processutils.py:384 > 2022-06-12 16:26:17.075 7 DEBUG nova.virt.driver [-] Emitting event > <LifecycleEvent: 1655034962.0316682, 25c8d676-e20a-4238-a45c-d51daa62b941 > => Stopped> emit_event > /var/lib/kolla/venv/lib/python3.6/site-packages/nova/virt/driver.py:1704 > INFO nova.compute.manager [-] [instance: > 25c8d676-e20a-4238-a45c-d51daa62b941] VM Stopped (Lifecycle Event) > DEBUG nova.compute.manager [req-f9f8cbf5-6208-4dca-aca6-48dee87f38fa - - - > - -] [instance: 25c8d676-e20a-4238-a45c-d51daa62b941] Checking state > _get_power_state > /var/lib/kolla/venv/lib/python3.6/site-packages/nova/compute/manager.py:1569 > DEBUG nova.compute.manager [req-f9f8cbf5-6208-4dca-aca6-48dee87f38fa - - - > - -] [instance: 25c8d676-e20a-4238-a45c-d51daa62b941] Synchronizing > instance power state after lifecycle event "Stopped"; current vm_state: > active, current task_state: image_pending_upload, current DB power_state: > 1, VM power_state: 4 handle_lifecycle_event > /var/lib/kolla/venv/lib/python3.6/site-packages/nova/compute/manager.py:1299 > INFO nova.compute.manager [req-f9f8cbf5-6208-4dca-aca6-48dee87f38fa - - - - > -] [instance: 25c8d676-e20a-4238-a45c-d51daa62b941] During sync_power_state > the instance has a pending task (image_pending_upload). Skip. > 2022-06-12 16:26:18.539 7 DEBUG nova.compute.manager > [req-2ecf34c3-72e7-4f33-89cb-9b250cd6d223 - - - - -] Triggering sync for > uuid 25c8d676-e20a-4238-a45c-d51daa62b941 _sync_power_states > /var/lib/kolla/venv/lib/python3.6/site-packages/nova/compute/manager.py:9693 > 2022-06-12 16:26:18.565 7 DEBUG oslo_concurrency.lockutils [-] Lock > "25c8d676-e20a-4238 > -a45c-d51daa62b941" acquired by > "nova.compute.manager.ComputeManager._sync_power_states.<locals>._sync.<locals>.query_driver_power_state_and_sync" > :: waited 0.000s inner > /var/lib/kolla/venv/lib/python3.6/site-packages/oslo_concurrency/lockutils.py:359 > 2022-06-12 16:26:18.566 7 INFO nova.compute.manager [-] [instance: > 25c8d676-e20a-4238-a45c-d51daa62b941] During sync_power_state the instance > has a pending task (image_pending_upload). Skip. > 2022-06-12 16:26:18.566 7 DEBUG oslo_concurrency.lockutils [-] Lock > "25c8d676-e20a-4238-a45c-d51daa62b941" released by > "nova.compute.manager.ComputeManager._sync_power_states.<locals>._sync.<locals>.query_driver_power_state_and_sync" > :: held 0.001s inner > /var/lib/kolla/venv/lib/python3.6/site-packages/oslo_concurrency/lockutils.py:371 > 2022-06-12 16:26:25.769 7 DEBUG oslo_concurrency.processutils > [req-5ecfdf74-7cf3-481a-aa12-140deae202f7 4dbffaa9c14e401c8c210e23ebe0ab7b > ef940663426b4c87a751afaf13b758e0 - default default] CMD "qemu-img convert > -t none -O raw -f raw > rbd:vms/25c8d676-e20a-4238-a45c-d51daa6b941_disk:id=cinder:conf=/etc/ceph/ceph.conf > /var/lib/nova/instances/snapshots/tmpv21b_i59/8717dec4c99c4ef7bac752e2a48690ad" > returned: 0 in 23.730s execute > /var/lib/kolla/venv/lib/python3.6/site-packages/oslo_concurrency/processutils.py:423 > default default] [instance: 25c8d676-e20a-4238-a45c-d51daa62b941] Snapshot > extracted, beginning image upload > 2022-06-12 16:26:27.981 7 DEBUG nova.virt.driver > [req-40444d74-f2fa-4569-87dd-375139938e81 - - - - -] Emitting event > <LifecycleEvent: 1655034987.9807608, 25c8d676-e20a-4238-a45c-d51daa62b941 > => Started> emit_event > /var/lib/kolla/venv/lib/python3.6/site-packages/nova/virt/driver.py:1704 > 2022-06-12 16:26:27.983 7 INFO nova.compute.manager > [req-40444d74-f2fa-4569-87dd-375139938e81 - - - - -] [instance: > 25c8d676-e20a-4238-a45c-d51daa62b941] VM Started (Lifecycle Event) > [instance: 25c8d676-e20a-4238-a45c-d51daa62b941] Checking state > _get_power_state > /var/lib/kolla/venv/lib/python3.6/site-packages/nova/compute/manager.py:1569 > 25c8d676-e20a-4238-a45c-d51daa62b941] Synchronizing instance power state > after lifecycle event "Started"; current vm_state: active, current > task_state: image_pending_upload, current DB power_state: 1, VM > power_state: 1 handle_lifecycle_event > /var/lib/kolla/venv/lib/python3.6/site-packages/nova/compute/manager.py:1299 > 2022-06-12 16:26:28.173 7 INFO nova.compute.manager > [req-40444d74-f2fa-4569-87dd-375139938e81 - - - - -] [instance: > 25c8d676-e20a-4238-a45c-d51daa62b941] VM Resumed (Lifecycle Event > 2022-06-12 16:29:00.859 7 DEBUG oslo_concurrency.lockutils > [req-2ecf34c3-72e7-4f33-89cb-9b250cd6d223 - - - - -] Acquired lock > "refresh_cache-25c8d676-e20a-4238-a45c-d51daa62b941" lock > /var/lib/kolla/venv/lib/python3.6/site-packages/oslo_concurrency/lockutils.py:266 > 25c8d676-e20a-4238-a45c-d51daa62b941] Forcefully refreshing network info > cache for instance _get_instance_nw_info > /var/lib/kolla/venv/lib/python3.6/site-packages/nova/network/neutron.py:1833 > 2022-06-12 16:29:03.278 7 DEBUG nova.network.neutron > [req-2ecf34c3-72e7-4f33-89cb-9b250cd6d223 - - - - -] [instance: > 25c8d676-e20a-4238-a45c-d51daa62b941] Updating instance_info_cache with > network_info: [{"id": "aa2fdd7d-ad18-4890-ad57-14bf9888d2c1", "address": > "fa:16:3e:ca:00:d9", "network": {"id": > "b86c8304-a9bd-4b39-b7fc-f70ffe76f2a8", "bridge": "br-int", "label": > "External_Network", "subnets": [{"cidr": "141.11.42.0/24", "dns": > [{"address": "8.8.8.8", "type": "dns", "version": 4, "meta": {}}, > {"address": "217.218.127.127", "type": "dns", "version": 4, "meta": {}}], > "gateway": {"address": "141.11.42.1", "type": "gateway", "version": 4, > "meta": {}}, "ips": [{"address": "141.11.42.37", "type": "fixed", > "version": 4, "meta": {}, "floating_ips": []}], "routes": [], "version": 4, > "meta": {}}], "meta": {"injected": true, "tenant_id": > "ef940663426b4c87a751afaf13b758e0", "mtu": 1500, "physical_network": > "physnet1", "tunneled": false}}, "type": "ovs", "details": {"connectivity": > "l2", "port_filter": true, "ovs_hybrid_plug": true, "datapath_type": > "system", "bridge_name": "br-int"}, "devname": "tapaa2fdd7d-ad", > "ovs_interfaceid": "aa2fdd7d-ad18-4890-ad57-14bf9888d2c1", "qbh_params": > null, "qbg_params": null, "active": true, "vnic_type": "normal", "profile": > {}, "preserve_on_delete": false, "meta": {}}] > update_instance_cache_with_nw_info > /var/lib/kolla/venv/lib/python3.6/site-packages/nova/network/neutron.py:117 > nstance 25c8d676-e20a-4238-a45c-d51daa62b941 actively managed on this > compute host and has allocations in placement: {'resources': {'VCPU': 1, > 'MEMORY_MB': 1024, 'DISK_GB': 20}}. _remove_deleted_instances_allocations > /var/lib/kolla/venv/lib/python3.6/site-packages/nova/compute/resource_tracker.py:1539 > 2022-06-12 16:33:37.595 7 INFO nova.compute.manager > [req-5ecfdf74-7cf3-481a-aa12-140deae202f7 4dbffaa9c14e401c8c210e23ebe0ab7b > ef940663426b4c87a751afaf13b758e0 - default default] [instance: > 25c8d676-e20a-4238-a45c-d51daa62b941] Took 461.98 seconds to snapshot the > instance on the hypervisor. > 2022-06-12 16:36:16.459 7 DEBUG nova.compute.manager > [req-2ecf34c3-72e7-4f33-89cb-9b250cd6d223 - - - - -] Triggering sync for > uuid 25c8d676-e20a-4238-a45c-d51daa62b941 _sync_power_states > /var/lib/kolla/venv/lib/python3.6/site-packages/nova/compute/manager.py:9693 > Lock "25c8d676-e20a-4238-a45c-d51daa62b941" acquired by > "nova.compute.manager.ComputeManager._sync_power_states.<locals>._sync.<locals>.query_driver_power_state_and_sync" > :: waited 0.000s inner > /var/lib/kolla/venv/lib/python3.6/site-packages/oslo_concurrency/lockutils.py:359 > 2022-06-12 16:37:05.365 7 DEBUG nova.compute.resource_tracker > [req-2ecf34c3-72e7-4f33-89cb-9b250cd6d223 - - - - -] Instance > 25c8d676-e20a-4238-a45c-d51daa62b941 actively managed on this compute host > and has allocations in placement: {'resources': {'VCPU': 1, 'MEMORY_MB': > 1024, 'DISK_GB': 20}}. _remove_deleted_instances_allocations > /var/lib/kolla/venv/lib/python3.6/site-packages/nova/compute/resource_tracker.py:1539 > 2022-06-12 09:42:32.687 7 INFO nova.compute.manager > [req-e79e4177-4712-4795-91da-853bc524fac0 93fb420b3c604d4fae408b81135b58e9 > ef940663426b4c87a751afaf13b758e0 - default default] [instance: > 25c8d676-e20a-4238-a45c-d51daa62b941] instance snapshotting > > On Sun, Jun 12, 2022 at 3:36 PM Eugen Block <eblock(a)nde.ag> wrote: > >> Have you tried with debug logs? Has it worked with live snapshots >> before for other instances or did it never work and all snapshots were >> "cold"? >> >> Zitat von Parsa Aminian <p.aminian.server(a)gmail.com>: >> >> > Hi >> > kolla-ansible victoria version with ceph backend without volume >> > >> > On Sun, Jun 12, 2022 at 12:45 PM Eugen Block <eblock(a)nde.ag> wrote: >> > >> >> Hi, >> >> >> >> can you share more details about your environment? Which openstack >> >> version is it? What is the storage backend? In earlier releases there >> >> was an option: >> >> >> >> #disable_libvirt_livesnapshot = false >> >> >> >> but this option has been deprecated. But if you're on an older version >> >> that could explain it. >> >> >> >> Zitat von Parsa Aminian <p.aminian.server(a)gmail.com>: >> >> >> >> > When I snapshot from the instance , server will gone away and its not >> >> > reachable until the snapshot is complete here is the logs : >> >> > 25c8d676-e20a-4238-a45c-d51daa62b941] instance snapshotting >> >> > 2022-06-12 09:42:34.755 7 INFO nova.compute.manager >> >> > [req-786946b1-3d22-489c-bf4d-8b1375b09ecb - - - - -] [instance: >> >> > 25c8d676-e20a-4238-a45c-d51daa62b941] VM Paused (Lifecycle Event) >> >> > 2022-06-12 09:42:34.995 7 INFO nova.compute.manager >> >> > [req-786946b1-3d22-489c-bf4d-8b1375b09ecb - - - - -] [instance: >> >> > 25c8d676-e20a-4238-a45c-d51daa62b941] During sync_power_state the >> >> instance >> >> > has a pending task (image_pending_upload). Skip. >> >> > 2022-06-12 09:42:57.749 7 INFO nova.compute.manager [-] [instance: >> >> > 25c8d676-e20a-4238-a45c-d51daa62b941] VM Stopped (Lifecycle Event) >> >> > 2022-06-12 09:43:06.102 7 INFO nova.virt.libvirt.driver >> >> > [req-e79e4177-4712-4795-91da-853bc524fac0 >> >> 93fb420b3c604d4fae408b81135b58e9 >> >> > ef940663426b4c87a751afaf13b758e0 - default default] [instance: >> >> > 25c8d676-e20a-4238-a45c-d51daa62b941] Snapshot extracted, beginning >> image >> >> > upload >> >> > 2022-06-12 09:43:08.778 7 INFO nova.compute.manager >> >> > [req-786946b1-3d22-489c-bf4d-8b1375b09ecb - - - - -] [instance: >> >> > 25c8d676-e20a-4238-a45c-d51daa62b941] VM Started (Lifecycle Event) >> >> >> >> >> >> >> >> >> >> >> >> >> >> >>

2 8

[VICTORIA][IRONIC] - Can inspect but not deploy
by Gaël THEROND 14 Jun '22

14 Jun '22

Hi everyone! I'm dealing with a strange issue today, we deployed IRONIC on a VICTORIA platform, we activated the dnsmasq pxe filtering option at the inspector level, it works great as only IRONIC listed hosts are then served by the dnsmasq DHCP as those hosts are allowed using the dhcp hosts dir. BUT, I'm having a weird issue now. All my nodes are able to get an IP from the DHCP at the INSPECTION step, however, as soon as the inspection step is finished, the mac related file is once again filled with "<mac>,ignore" which prohibits further operations. This means as soon as I put that node as available and try to deploy an "instance" on it (provision the host), it doesn't work as dnsmasq reject the host boot DHCP requests. So, is there a way to instruct the ironic-conductor to edit/allow the host the way the inspector is able to manipulate this file? Did I missed something? Thanks a lot!

3 6

[Nova] Hardware Architecture Emulation - Summit forum - Emulation beyond just Local QEMU -outcomes
by Race, Jonathan 14 Jun '22

14 Jun '22

Great to see everyone at the summit! For those not in attendance and interested, see the below etherpad that is being used to collect input and requirements as our team moves forward with work. I have also included the outcomes that I have identified. https://etherpad.opendev.org/p/Emulation_going_beyond_local_QEMU Berlin Forum Outcomes I appreciate all the feedback during the forum session, and it was great to have active participation on how to grow and shape this unique feature. We discussed the feature, what it allows, how to actually leverage it, and discussed about further refining the applicable use cases so that operators and users can effectively use it and to help drive interest. A prime example was of a company wanting to shift their infra from x86_64 to arm for the sake of power consumption, and whether this feature could lend its hand to perform some initial fact finding and testing. The answer is yes, you can spin up some of the infra (in your desired arch) on top of your existing deployment and perform your tests and validations. One of the great items that came out of the discussion was that this can not only be to support education, research, and training but it can act as a great 1st step within planning. Meaning when you are going from the drawing board to implementation, you can now model and design your network environments within the cloud for IT and OT systems. This is where refining the use cases really came to light, as our organization leverages OpenStack as a private cloud for hosting extremely customizable network environments (i.e. enterprise iT, IOT, Critical infrastructure, medical devices, etc.) While the feature itself is overall in the experimental phase, it is a great start. This etherpad will remain available and feel free to add to it, as we leverage this year to fact find and identify all further requirements going into the AA release cycle. A snapshot of the discussion points can be found below, and ill be posting the recorded session within the week. * Most operators and providers are running a few releases behind so getting accurate feedback at this time is still ongoing due to this feature only being available in yoga and newer. * Pursuit of additional architectures to be supported (riscv, etc.) * This will require custom firmware support * evaluate current AMI/AKI/ARI functionalities (add ability for leveraging glance if able, and add additional security) * Adding capability for trusted signers of OOVMF file descriptors * evaluating current work related to edk2 oovmf file descriptors * https://github.com/riscv-admin/riscv-uefi-edk2-docs * Expansion and documentation of a valid support matrix * something similar to: (arch x | feat 1 | supported | temptest test 1) * Evaluate requirements for leveraging virtio in relation to scsi/sata devices similar to pci passthrough capabilities Jonathan Race Cyber Range Engineer | Georgia Cyber Range GEORGIA CYBER CENTER 100 Grace Hopper Lane | Augusta, Georgia | 30901 (c) 762-716-7733 www.gacyberrange.org<http://www.gacybercenter.org/> [cid:image001.png@01D87FD1.CF558390]

1 0

[neutron] bug deputy (week of Jun 6)
by Akihiro Motoki 14 Jun '22

14 Jun '22

Hi, I was a bug deputy in neutron. Here is a summary. ## Untriaged * https://bugs.launchpad.net/neutron/+bug/1978088 After ovs-agent restart, table=21 and table=22 on br-tun openflow table is missing This happens when a large number of agents are restarted, but it looks like deeper investigations are needed to understand the situation. (liuyolong and ralonsoh already helped) ## In Progress * https://bugs.launchpad.net/neutron/+bug/1977819 [OVS][QoS] "delete_minimum_bandwidth_queue" uses the incorrect Port UUID High, In Progress * https://bugs.launchpad.net/neutron/+bug/1978519 Create auto allocated topology encounter error when enable ndp_proxy service plugin ## RFE * https://bugs.launchpad.net/neutron/+bug/1978039 [ovn] Floating IP adds distributed attributes ## Fix Released * https://bugs.launchpad.net/neutron/+bug/1977752 [OVS][QoS] Minimum bandwidth backend enforcement does not provide max-rate values * https://bugs.launchpad.net/neutron/+bug/1977969 [OVN] DB sync tool: local variable 'members_to_verify' referenced before assignment" * https://bugs.launchpad.net/neutron/+bug/1978035 remove unused updated_at parameter for AgentCache.update * https://bugs.launchpad.net/neutron/+bug/1978389 Basic networking in Neutron - max VLAN should be 4094, not 4095 * https://bugs.launchpad.net/neutron/+bug/1977831 Response time increasing on new subnets over same network Thanks, Akihiro Motoki (amotoki)

1 0

simple build fails to allocate network interface
by tim+openstack.org＠coote.org 14 Jun '22

14 Jun '22

Hullo I’m trying to spin up a simple OS environment in a single vm and think that I’m making some silly mistake, but cannot spot it. Any hints would be greatly expected. I’ve tried this on a couple of laptops, with the same result, so I suspect that it’s something to do with how I’ve set up my vm, but I cannot identify it. (I think that there may be a few other devstack issues, but I’ve got to get it working to log any bugs). I’m using a vagrant box and VirtualBox on x86 Macs (Monterey), and the devstack install/build process. Everything seems to install, but when I try: `openstack server create --flavor 42 --image cirros-0.5.2-x86_64-disk --nic net-id=2a1a4a3a-a47b-48bd-a7df-c90fc75a1c63 --security-group default wibble` The network id is identified from this: “”" [vagrant@localhost devstack]$ openstack network list +--------------------------------------+---------+----------------------------------------------------------------------------+ | ID | Name | Subnets | +--------------------------------------+---------+----------------------------------------------------------------------------+ | 205fa7d7-7067-4f63-b3d9-6a9b37b4f11f | public | 1bbbfa3c-8e0a-483f-a084-4e38241b3315, eecfc603-c057-4b28-90bd-950a47345410 | | 2a1a4a3a-a47b-48bd-a7df-c90fc75a1c63 | private | e7377bed-3e22-4e8d-9c2d-ea7ba740fcfd, f915b88c-9988-4e1f-9060-a6295465699a | | fab3fb15-cbd2-45fe-8451-3f0063d59454 | shared | 97e6d8e6-0f57-48bc-8f1d-e30587086153 | +--------------------------------------+---------+——————————————————————————————————————+ “”” Using a public network fails with an error that this isn’t allowed. With the private network above, the failure throws out the following errors. “”" [vagrant@localhost devstack]$ sudo journalctl -f |grep ERROR Jun 08 15:33:52 localhost.localdomain nova-compute[87555]: ERROR nova.compute.manager [None req-01294678-b54a-4e40-964c-488ccf03d66c demo demo] [instance: 20e1b5bf-130a-48f9-af4e-9b4c7a475315] Instance failed to spawn: nova.exception.VirtualInterfaceCreateException: Virtual Interface creation failed Jun 08 15:33:52 localhost.localdomain nova-compute[87555]: ERROR nova.compute.manager [instance: 20e1b5bf-130a-48f9-af4e-9b4c7a475315] Traceback (most recent call last): Jun 08 15:33:52 localhost.localdomain nova-compute[87555]: ERROR nova.compute.manager [instance: 20e1b5bf-130a-48f9-af4e-9b4c7a475315] File "/opt/stack/nova/nova/virt/libvirt/driver.py", line 7510, in _create_guest_with_network Jun 08 15:33:52 localhost.localdomain nova-compute[87555]: ERROR nova.compute.manager [instance: 20e1b5bf-130a-48f9-af4e-9b4c7a475315] guest = self._create_guest( Jun 08 15:33:52 localhost.localdomain nova-compute[87555]: ERROR nova.compute.manager [instance: 20e1b5bf-130a-48f9-af4e-9b4c7a475315] File "/usr/lib64/python3.9/contextlib.py", line 126, in __exit__ Jun 08 15:33:52 localhost.localdomain nova-compute[87555]: ERROR nova.compute.manager [instance: 20e1b5bf-130a-48f9-af4e-9b4c7a475315] next(self.gen) Jun 08 15:33:52 localhost.localdomain nova-compute[87555]: ERROR nova.compute.manager [instance: 20e1b5bf-130a-48f9-af4e-9b4c7a475315] File "/opt/stack/nova/nova/compute/manager.py", line 556, in wait_for_instance_event Jun 08 15:33:52 localhost.localdomain nova-compute[87555]: ERROR nova.compute.manager [instance: 20e1b5bf-130a-48f9-af4e-9b4c7a475315] self._wait_for_instance_events( Jun 08 15:33:52 localhost.localdomain nova-compute[87555]: ERROR nova.compute.manager [instance: 20e1b5bf-130a-48f9-af4e-9b4c7a475315] File "/opt/stack/nova/nova/compute/manager.py", line 468, in _wait_for_instance_events Jun 08 15:33:52 localhost.localdomain nova-compute[87555]: ERROR nova.compute.manager [instance: 20e1b5bf-130a-48f9-af4e-9b4c7a475315] actual_event = event.wait() Jun 08 15:33:52 localhost.localdomain nova-compute[87555]: ERROR nova.compute.manager [instance: 20e1b5bf-130a-48f9-af4e-9b4c7a475315] File "/opt/stack/nova/nova/compute/manager.py", line 433, in wait Jun 08 15:33:52 localhost.localdomain nova-compute[87555]: ERROR nova.compute.manager [instance: 20e1b5bf-130a-48f9-af4e-9b4c7a475315] instance_event = self.event.wait() Jun 08 15:33:52 localhost.localdomain nova-compute[87555]: ERROR nova.compute.manager [instance: 20e1b5bf-130a-48f9-af4e-9b4c7a475315] File "/usr/local/lib/python3.9/site-packages/eventlet/event.py", line 125, in wait Jun 08 15:33:52 localhost.localdomain nova-compute[87555]: ERROR nova.compute.manager [instance: 20e1b5bf-130a-48f9-af4e-9b4c7a475315] result = hub.switch() Jun 08 15:33:52 localhost.localdomain nova-compute[87555]: ERROR nova.compute.manager [instance: 20e1b5bf-130a-48f9-af4e-9b4c7a475315] File "/usr/local/lib/python3.9/site-packages/eventlet/hubs/hub.py", line 313, in switch Jun 08 15:33:52 localhost.localdomain nova-compute[87555]: ERROR nova.compute.manager [instance: 20e1b5bf-130a-48f9-af4e-9b4c7a475315] return self.greenlet.switch() Jun 08 15:33:52 localhost.localdomain nova-compute[87555]: ERROR nova.compute.manager [instance: 20e1b5bf-130a-48f9-af4e-9b4c7a475315] eventlet.timeout.Timeout: 300 seconds Jun 08 15:33:52 localhost.localdomain nova-compute[87555]: ERROR nova.compute.manager [instance: 20e1b5bf-130a-48f9-af4e-9b4c7a475315] Jun 08 15:33:52 localhost.localdomain nova-compute[87555]: ERROR nova.compute.manager [instance: 20e1b5bf-130a-48f9-af4e-9b4c7a475315] During handling of the above exception, another exception occurred: Jun 08 15:33:52 localhost.localdomain nova-compute[87555]: ERROR nova.compute.manager [instance: 20e1b5bf-130a-48f9-af4e-9b4c7a475315] Jun 08 15:33:52 localhost.localdomain nova-compute[87555]: ERROR nova.compute.manager [instance: 20e1b5bf-130a-48f9-af4e-9b4c7a475315] Traceback (most recent call last): Jun 08 15:33:52 localhost.localdomain nova-compute[87555]: ERROR nova.compute.manager [instance: 20e1b5bf-130a-48f9-af4e-9b4c7a475315] File "/opt/stack/nova/nova/compute/manager.py", line 2728, in _build_resources Jun 08 15:33:52 localhost.localdomain nova-compute[87555]: ERROR nova.compute.manager [instance: 20e1b5bf-130a-48f9-af4e-9b4c7a475315] yield resources Jun 08 15:33:52 localhost.localdomain nova-compute[87555]: ERROR nova.compute.manager [instance: 20e1b5bf-130a-48f9-af4e-9b4c7a475315] File "/opt/stack/nova/nova/compute/manager.py", line 2487, in _build_and_run_instance Jun 08 15:33:52 localhost.localdomain nova-compute[87555]: ERROR nova.compute.manager [instance: 20e1b5bf-130a-48f9-af4e-9b4c7a475315] self.driver.spawn(context, instance, image_meta, Jun 08 15:33:52 localhost.localdomain nova-compute[87555]: ERROR nova.compute.manager [instance: 20e1b5bf-130a-48f9-af4e-9b4c7a475315] File "/opt/stack/nova/nova/virt/libvirt/driver.py", line 4344, in spawn Jun 08 15:33:52 localhost.localdomain nova-compute[87555]: ERROR nova.compute.manager [instance: 20e1b5bf-130a-48f9-af4e-9b4c7a475315] self._create_guest_with_network( Jun 08 15:33:52 localhost.localdomain nova-compute[87555]: ERROR nova.compute.manager [instance: 20e1b5bf-130a-48f9-af4e-9b4c7a475315] File "/opt/stack/nova/nova/virt/libvirt/driver.py", line 7528, in _create_guest_with_network Jun 08 15:33:52 localhost.localdomain nova-compute[87555]: ERROR nova.compute.manager [instance: 20e1b5bf-130a-48f9-af4e-9b4c7a475315] raise exception.VirtualInterfaceCreateException() Jun 08 15:33:52 localhost.localdomain nova-compute[87555]: ERROR nova.compute.manager [instance: 20e1b5bf-130a-48f9-af4e-9b4c7a475315] nova.exception.VirtualInterfaceCreateException: Virtual Interface creation failed Jun 08 15:33:52 localhost.localdomain nova-compute[87555]: ERROR nova.compute.manager [instance: 20e1b5bf-130a-48f9-af4e-9b4c7a475315] Jun 08 15:33:52 localhost.localdomain nova-compute[87555]: ERROR nova.compute.manager [None req-01294678-b54a-4e40-964c-488ccf03d66c demo demo] [instance: 20e1b5bf-130a-48f9-af4e-9b4c7a475315] Failed to allocate network(s): nova.exception.VirtualInterfaceCreateException: Virtual Interface creation failed Jun 08 15:33:52 localhost.localdomain nova-compute[87555]: ERROR nova.compute.manager [instance: 20e1b5bf-130a-48f9-af4e-9b4c7a475315] Traceback (most recent call last): Jun 08 15:33:52 localhost.localdomain nova-compute[87555]: ERROR nova.compute.manager [instance: 20e1b5bf-130a-48f9-af4e-9b4c7a475315] File "/opt/stack/nova/nova/virt/libvirt/driver.py", line 7510, in _create_guest_with_network Jun 08 15:33:52 localhost.localdomain nova-compute[87555]: ERROR nova.compute.manager [instance: 20e1b5bf-130a-48f9-af4e-9b4c7a475315] guest = self._create_guest( Jun 08 15:33:52 localhost.localdomain nova-compute[87555]: ERROR nova.compute.manager [instance: 20e1b5bf-130a-48f9-af4e-9b4c7a475315] File "/usr/lib64/python3.9/contextlib.py", line 126, in __exit__ Jun 08 15:33:52 localhost.localdomain nova-compute[87555]: ERROR nova.compute.manager [instance: 20e1b5bf-130a-48f9-af4e-9b4c7a475315] next(self.gen) Jun 08 15:33:52 localhost.localdomain nova-compute[87555]: ERROR nova.compute.manager [instance: 20e1b5bf-130a-48f9-af4e-9b4c7a475315] File "/opt/stack/nova/nova/compute/manager.py", line 556, in wait_for_instance_event Jun 08 15:33:52 localhost.localdomain nova-compute[87555]: ERROR nova.compute.manager [instance: 20e1b5bf-130a-48f9-af4e-9b4c7a475315] self._wait_for_instance_events( Jun 08 15:33:52 localhost.localdomain nova-compute[87555]: ERROR nova.compute.manager [instance: 20e1b5bf-130a-48f9-af4e-9b4c7a475315] File "/opt/stack/nova/nova/compute/manager.py", line 468, in _wait_for_instance_events Jun 08 15:33:52 localhost.localdomain nova-compute[87555]: ERROR nova.compute.manager [instance: 20e1b5bf-130a-48f9-af4e-9b4c7a475315] actual_event = event.wait() Jun 08 15:33:52 localhost.localdomain nova-compute[87555]: ERROR nova.compute.manager [instance: 20e1b5bf-130a-48f9-af4e-9b4c7a475315] File "/opt/stack/nova/nova/compute/manager.py", line 433, in wait Jun 08 15:33:52 localhost.localdomain nova-compute[87555]: ERROR nova.compute.manager [instance: 20e1b5bf-130a-48f9-af4e-9b4c7a475315] instance_event = self.event.wait() Jun 08 15:33:52 localhost.localdomain nova-compute[87555]: ERROR nova.compute.manager [instance: 20e1b5bf-130a-48f9-af4e-9b4c7a475315] File "/usr/local/lib/python3.9/site-packages/eventlet/event.py", line 125, in wait Jun 08 15:33:52 localhost.localdomain nova-compute[87555]: ERROR nova.compute.manager [instance: 20e1b5bf-130a-48f9-af4e-9b4c7a475315] result = hub.switch() Jun 08 15:33:52 localhost.localdomain nova-compute[87555]: ERROR nova.compute.manager [instance: 20e1b5bf-130a-48f9-af4e-9b4c7a475315] File "/usr/local/lib/python3.9/site-packages/eventlet/hubs/hub.py", line 313, in switch Jun 08 15:33:52 localhost.localdomain nova-compute[87555]: ERROR nova.compute.manager [instance: 20e1b5bf-130a-48f9-af4e-9b4c7a475315] return self.greenlet.switch() Jun 08 15:33:52 localhost.localdomain nova-compute[87555]: ERROR nova.compute.manager [instance: 20e1b5bf-130a-48f9-af4e-9b4c7a475315] eventlet.timeout.Timeout: 300 seconds Jun 08 15:33:52 localhost.localdomain nova-compute[87555]: ERROR nova.compute.manager [instance: 20e1b5bf-130a-48f9-af4e-9b4c7a475315] Jun 08 15:33:52 localhost.localdomain nova-compute[87555]: ERROR nova.compute.manager [instance: 20e1b5bf-130a-48f9-af4e-9b4c7a475315] During handling of the above exception, another exception occurred: Jun 08 15:33:52 localhost.localdomain nova-compute[87555]: ERROR nova.compute.manager [instance: 20e1b5bf-130a-48f9-af4e-9b4c7a475315] Jun 08 15:33:52 localhost.localdomain nova-compute[87555]: ERROR nova.compute.manager [instance: 20e1b5bf-130a-48f9-af4e-9b4c7a475315] Traceback (most recent call last): Jun 08 15:33:52 localhost.localdomain nova-compute[87555]: ERROR nova.compute.manager [instance: 20e1b5bf-130a-48f9-af4e-9b4c7a475315] File "/opt/stack/nova/nova/compute/manager.py", line 2487, in _build_and_run_instance Jun 08 15:33:52 localhost.localdomain nova-compute[87555]: ERROR nova.compute.manager [instance: 20e1b5bf-130a-48f9-af4e-9b4c7a475315] self.driver.spawn(context, instance, image_meta, Jun 08 15:33:52 localhost.localdomain nova-compute[87555]: ERROR nova.compute.manager [instance: 20e1b5bf-130a-48f9-af4e-9b4c7a475315] File "/opt/stack/nova/nova/virt/libvirt/driver.py", line 4344, in spawn Jun 08 15:33:52 localhost.localdomain nova-compute[87555]: ERROR nova.compute.manager [instance: 20e1b5bf-130a-48f9-af4e-9b4c7a475315] self._create_guest_with_network( Jun 08 15:33:52 localhost.localdomain nova-compute[87555]: ERROR nova.compute.manager [instance: 20e1b5bf-130a-48f9-af4e-9b4c7a475315] File "/opt/stack/nova/nova/virt/libvirt/driver.py", line 7528, in _create_guest_with_network Jun 08 15:33:52 localhost.localdomain nova-compute[87555]: ERROR nova.compute.manager [instance: 20e1b5bf-130a-48f9-af4e-9b4c7a475315] raise exception.VirtualInterfaceCreateException() Jun 08 15:33:52 localhost.localdomain nova-compute[87555]: ERROR nova.compute.manager [instance: 20e1b5bf-130a-48f9-af4e-9b4c7a475315] nova.exception.VirtualInterfaceCreateException: Virtual Interface creation failed Jun 08 15:33:52 localhost.localdomain nova-compute[87555]: ERROR nova.compute.manager [instance: 20e1b5bf-130a-48f9-af4e-9b4c7a475315] Jun 08 15:33:52 localhost.localdomain nova-compute[87555]: ERROR nova.compute.manager [None req-01294678-b54a-4e40-964c-488ccf03d66c demo demo] [instance: 20e1b5bf-130a-48f9-af4e-9b4c7a475315] Build of instance 20e1b5bf-130a-48f9-af4e-9b4c7a475315 aborted: Failed to allocate the network(s), not rescheduling.: nova.exception.BuildAbortException: Build of instance 20e1b5bf-130a-48f9-af4e-9b4c7a475315 aborted: Failed to allocate the network(s), not rescheduling. “”" The Vagrantfile (commented out lines relate to trying this with Ubunutu, which failed the same way, and attempts to use multiple vms): “”" # -*- mode: ruby -*- # vi: set ft=ruby : $script = <<-SHELL dnf update -y #apt update #apt upgrade echo "updated" systemctl disable firewalld systemctl stop firewalld systemctl disable NetworkManager systemctl stop NetworkManager systemctl enable network systemctl start network #dnf config-manager --enable powertools #dnf install -y centos-release-openstack-yoga dnf update -y dnf install -y git python3-pip #dnf install -y openstack-packstack #packstack --provision-demo=n --os-neutron-ml2-type-drivers=vxlan,flat,vlan --gen-answer-file=packstack-answers.txt #sed -i -e 's:10.0.2.15:10.1.0.10:' packstack-answers.txt # not for centos 9 #dnf install -y network-scripts dnf install -y net-tools #cat /vagrant/answers.addon >> packstack-answers.txt # don't want this, but httpd won't start without it setenforce 0 pip3 install invoke #packstack --allinone cd /vagrant # permissions all wrong: ./go.sh # need su - vagrant cd /vagrant && ./go.sh (?) # cd devstack # not working: wrong user ./stack.sh SHELL Vagrant.configure(2) do |config| config.vm.box = "eurolinux-vagrant/centos-stream-9" #config.vm.box = "hashicorp/bionic64" # machines = { # 'node1.example.dd' #'node1.example.dd' => { :ip => '10.1.0.10'}, # 'node2.example.dd' => { :ip =>'10.1.0.12'}, # } config.hostmanager.enabled = true config.hostmanager.manage_host = true config.hostmanager.manage_guest = true config.hostmanager.ignore_private_ip = false config.hostmanager.include_offline = true config.ssh.pty = true config.vm.provision "shell", inline: $script config.vm.network "forwarded_port", guest: 80, host: 8080 # machines.each do | hostname, attrs| # config.vm.define hostname do |machine| # machine.vm.hostname = hostname # machine.vm.network :private_network, :ip => attrs[:ip] # machine.vm.provider "virtualbox" do | v | config.vm.provider "virtualbox" do | v | #v.memory = "4096" #v.memory = "8192" v.memory = "9216" v.cpus = "2" end #end # end end “”” I think that the vm has enough RAM, although there is minimal swap being used, but I think that this is not significant as there is much more RAM used for caching files. Any obvious hints as to why the spin up fails to create the NIC - or somewhere to look for further and better details? Tim

4 6