October 2020 - openstack-discuss - lists.openstack.org

Ubuntu Focal Ussuri can't create a snapshot from running instance
by Cristina Mayo Sarmiento 20 Oct '20

20 Oct '20

Hi all, I don't have a lot experience with Openstack. I've installed Ussuri on my cloud. I have 1 controller node and 2 compute nodes. I'm not able to create a snapshot from a running instance, but it works perfectly if the instance is turned off. I checked the logs on controller node about glance-api and POST method executes fine, but suddenly appears a DELETE that seems remove the image: "POST /v2/images HTTP/1.1" 201 1254 0.045379 "GET /v2/images/c647160b-416d-4c98-bbe2-6302a509f 941 HTTP/1.1" 200 1097 0.014154 WARNING glance.api.v2.images [req-e29704f9-e147-42df-914c-6217c60ada30 c63d05ad0e9d43ebb0fd31f442156a2a c2 b7d6242f3140f09d283e8fbb88732a - default default] After upload to backend, deletion of staged image data has failed because it cannot be found at /tmp/staging//c647160b-416d-4c98-bbe2-6302a509f941 "DELETE /v2/images/c647160b-416d-4c98-bbe2-6302a5 09f941 HTTP/1.1" 204 213 0.140731 I have these versions installed: - python3-glance-store/focal,now 2.0.0-0ubuntu1 all [instalado, automático] - python3-glance/focal-updates,now 2:20.0.1-0ubuntu1 all [instalado, automático] Could anyone help me? Thanks in advance, Regards,

3 3

[largescale-sig] "Share your OpenStack scaling story" forum session
by Thierry Carrez 20 Oct '20

20 Oct '20

Hi everyone, In a few hours at 14:30UTC we'll have a Forum session where everyone is invited to share their scaling story. As you add nodes to an OpenStack cluster, at one point you hit scaling limitations that force you to scale out to multiple clusters, cells or zones. What breaks first? At which scale? The Large Scale SIG is working on pushing back the scaling limits within a single cluster. To that effect, it is collecting scaling stories from OpenStack deployers. This should lead to identifying common cases, usual suspects that the SIG can focus on, in order to raise scaling limitations within one cluster and reduce the need to scale out to multiple clusters too early. Join fellow OpenStack operators and share your experience and horror stories, adding nodes to OpenStack clusters! In case the event platform plays games again, you can access the session directly at: https://zoom.us/j/94011749848?pwd=Qmo5c1ZMK3RJWnVRSjZzZWFkTng3QT09 And the etherpad is at: https://etherpad.opendev.org/p/vSummit2020_OpenStackScalingStory See you all there! -- Thierry Carrez (ttx)

1 1

[neutron] bug deputy report (week of Oct 12)
by Akihiro Motoki 20 Oct '20

20 Oct '20

Hi, I was a bug deputy in neutron last week. Here is a summary. It was a quiet week and fixes have been proposed for medium or higher priority bugs. I see no bug to be raised from POV of bug triaging. [In Progress] https://bugs.launchpad.net/neutron/+bug/1899967 L3HA Router in primary state on all nodes Critical, In Progress, slaweq proposed a fix https://bugs.launchpad.net/neutron/+bug/1899917 neutron-tempest-plugin-scenario-linuxbridge jobs are broken on rocky/queens branches Critical, In Progress, slaweq proposed a fix https://bugs.launchpad.net/neutron/+bug/1899775 Ovs agent import error on Windows High, In Progress, a fix was proposed for review https://bugs.launchpad.net/neutron/+bug/1899864 Smartnic port's MTU is not set correctly Medium, In Progress, a fix was proposed for review [Confirmed] https://bugs.launchpad.net/neutron/+bug/1899502 router_centralized_snat ports do not have project_id Low, Confirmed, Assigned to the bug author Looks like we agree it is a valid bug. [Wishlist] These are bugs for tracking refactoring. https://bugs.launchpad.net/neutron/+bug/1900270 Implement "find_child_pids" natively Wishlist, In Progress, Assigned to ralonsoh https://bugs.launchpad.net/neutron/+bug/1900268 Implement "find_parent_pid" natively Wishlist, In Progress, Assigned to ralonsoh https://bugs.launchpad.net/neutron/+bug/1900269 Implement "get_process_count_by_name" natively Wishlist, In Progress, Assigned to ralonsoh Thanks, Akihiro Motoki (irc: amotoki)

1 0

[openstack][stein][cinder] python2-os-brick issue orphaned device
by Ignazio Cassano 20 Oct '20

20 Oct '20

Hello Guys, I am using cinder on centos7 stein with Dell unity iscsi driver. When I migrate vm from a kvm node to another, orphaned devices are left on source kvm node. I initialized debug on nova compute and i thing the issue si in the following lines (2020-10-20 09:52:33.078 132171 DEBUG os_brick.initiator.connectors.iscsi [-] Disconnecting from: []): connectors/iscsi.py:1111 2020-10-20 09:52:33.078 132171 DEBUG os_brick.initiator.connectors.iscsi [-] Resulting device map defaultdict(<function <lambda> at 0x7f4f1b1f7cf8>, {(u'10.138.215.17:3260', u'iqn.1992-04.com.emc:cx.ckm00184400687.a2'): (set([]), set([u'sdg', u'sdi'])), (u'10.138.209.47:3260', u'iqn.1992-04.com.emc:cx.ckm00184400687.b3'): (set([]), set([u'sdo', u'sdq'])), (u'10.138.209.48:3260', u'iqn.1992-04.com.emc:cx.ckm00184400687.a3'): (set([]), set([u'sdd', u'sdb'])), (u'10.138.215.18:3260', u'iqn.1992-04.com.emc:cx.ckm00184400687.b2'): (set([]), set([u'sdm', u'sdk']))}) _get_connection_devices /usr/lib/python2.7/site-packages/os_brick/initiator/connectors/iscsi.py:844 2020-10-20 09:52:33.078 132171 DEBUG os_brick.initiator.connectors.iscsi [-] Disconnecting from: [] _disconnect_connection /usr/lib/python2.7/site-packages/os_brick/initiator/connectors/iscsi.py:1099 The version of package is: python2-os-brick-2.8.7-1.el7.noarch Please, any help ? Ignazio

1 0

[Automation SIG] BoF today! feel free to join
by Rico Lin 20 Oct '20

20 Oct '20

Hi all, Automation SIG is hosting a BoF on Tue 20, 1:00pm - 1:45pm (18:00 - 18:45 UTC) - Virtual - Virtual Floor - Forum Room 2 https://summit.openinfra.dev/a/event/24753 Please join if you're interested. -- May The Force of OpenStack Be With You, *Rico Lin*irc: ricolin

1 0

[Multi-arch SIG][OpenInfra Summit] BoF today! Feel free to join us
by Rico Lin 20 Oct '20

20 Oct '20

Hi all As a forming SIG, we hope to have more hands or resources to keep pushing things forward. In this summit, we will host a BoF on Tuesday this week and hope to have people to join. Multi-arch SIG Tue 20, 12:15pm - 1:00pm (17:15 - 18:00 UTC) - Virtual - Virtual Floor - Forum Room Multi-arch SIG BoF https://summit.openinfra.dev/a/event/24752 Also if you would like to see some related sessions here's some you can consider: Multi-Arch Support in OpenStack https://summit.openinfra.dev/a/event/24708 The Progress for Cloud Computing on Arm architecture https://summit.openinfra.dev/a/event/24719 Cloud-hypervisor: A new choice for virtual machine monitor https://summit.openinfra.dev/a/event/24684 -- May The Force of OpenStack Be With You, *Rico Lin*irc: ricolin

1 0

[nova] NUMA scheduling
by Eric K. Miller 20 Oct '20

20 Oct '20

Hi, I'm at a loss for finding good information about how a VM's vCPUs and Memory are assigned to NUMA nodes within a scheduled physical host. I think Libvirt does this, and the Nova Scheduler simply finds the right physical host to run the VM, and thus Nova has no input on which NUMA node to choose. So this might be a Libvirt question. We are running Stein and have the issue where VMs launch on NUMA Node 0, and not on NUMA Node 1, in physical hosts with two processors, and are simply looking for a way to tell Libvirt to consider NUMA Node 1 when scheduling a VM, since there is nearly all of the memory available on NUMA Node 1. Our flavors are defined with hw:numa_nodes='1' since we want all vCPUs+Memory to land on a single NUMA Node, and so the guest OS has visibility that a single NUMA Node is being used. We are "not" looking for a way to pin a VM to a specific NUMA node (such as for SR-IOV purposes). Any suggestions where to look for the solution? Thanks! Eric

5 17

[qa] Weekly meeting cancelled because of Summit and PTG
by Masayuki Igawa 20 Oct '20

20 Oct '20

Hi, We'll skip the meetings both this and next week because of the summit and PTG. See you there :) -- Masayuki Igawa

1 0

[openstack-helm] No meeting this week and next week
by Gage Hugo 19 Oct '20

19 Oct '20

Hello everyone, due to the summit and PTG there will be no meeting this week or next week. We will meet again on November 3rd at the usual time, thanks!

1 0

[Security SIG] No meeting this week or next week
by Gage Hugo 19 Oct '20

19 Oct '20

Hello everyone, due to the summit and PTG there will be no meeting this week or next week. We will meet again on November 5th at the usual time, thanks!

1 0