March 2019 - openstack-discuss - lists.openstack.org

[nova][operators] Upcoming change breaking out of tree virt drivers in Nova
by Jim Rollenhagen 01 Mar '19

01 Mar '19

Hi, There's a nasty race condition when using the ironic driver with Nova.[0] The patch to fix it[1] adds a use_cache argument to the virt driver's get_info method. This is caught and handled so that we can backport the fix, but a follow-up change on master[2] removes the error handling. You'll need to update your out-of-tree virt drivers, if you have one, to add this argument to work with the Stein release. And if your virt driver caches instance information, it would be worth skipping or refreshing that cache when use_cache=True is passed. Sorry for the inconvenience. :) [0] https://bugs.launchpad.net/nova/+bug/1815791 [1] https://review.openstack.org/#/c/636699 [2] https://review.openstack.org/#/c/640043 // jim

1 0

[nova] snapshots default to qcow2
by Eugen Block 01 Mar '19

01 Mar '19

Hi all, this still seems to be related to a thread I created last year [1]. There was a part left which I didn't understand and couldn't reproduce, now a colleague seems to have created an instance where I can reproduce the issue. I also found [2] and [3] referring to this, both were marked as invalid, but this is not resolved IMO. I'll try to explain: We have a volume backed instance, its base image was in raw format (all non-raw images were updated after I learned about the consequences): # nova show output | image | Attempt to boot from volume - no image supplied | | os-extended-volumes:volumes_attached | [{"id": "ccca4607-3296-472b-a521-fdc3e76451a2"}] | The respective volume has the following meta-data: # cinder show output | volume_image_metadata | {'container_format': 'bare', 'min_ram': '0', 'disk_format': 'raw', 'image_name': '###_SLES12-SP3-JeOS', 'image_id': '9ed2b16e-c939-42e7-9e09-4a732caf2449', 'checksum': 'e3282f363c62194c1e4dea1bacccdda6', 'min_disk': '0', 'size': '1084227584'} | I also double-checked the (exported) volume with qemu-img info that it's indeed a raw formatted volume. Now when I create a nova snapshot either with Horizon or the CLI it results in a qcow2 image: control:~ # nova image-create d1d4e694-3920-47e6-8338-060015c4eb71 test-image control1:~ # openstack image show 7de2fd37-1124-4382-9fb4-66fde8c92676 | grep disk_format | disk_format | qcow2 I changed 'snapshot_image_format' from '<None>' to 'raw' in nova.conf on both control and compute node, although nova states to use the source image's format: # If set, this decides what format is used when sending the snapshot to the # image service. # If not set, defaults to same type as source image. Obviously, this doesn't work as expected, so the question is which component is responsible for the qcow2 format? I couldn't find related cinder config options, could [2] be a valid bug report after all? Thanks for any thoughts on this! Regards, Eugen [1] https://www.mail-archive.com/openstack@lists.openstack.org/msg20935.html [2] https://bugs.launchpad.net/nova/+bug/1332558 [3] https://ask.openstack.org/en/question/65451/snapshot-defaults-to-qcow2/

1 1

[kolla] - Ceph bootstrap monitor is not properly configured
by Tyler Bishop 01 Mar '19

01 Mar '19

Trying to deploy a new cluster using the bootstrapping for ceph but running into issues with the admin keys being incorrectly deployed. Successful ansible deploy up until: TASK [ceph : Getting ceph mgr keyring] ****************************************************************************************************************************** failed: [osctlr.home.visualbits.net -> osctlr.home.visualbits.net] (item= osctlr.home.visualbits.net) => {"changed": false, "item": " osctlr.home.visualbits.net", "msg": "Failed to call command: ['docker', 'exec', 'ceph_mon', 'ceph', '--format', 'json', 'auth', 'get-or-create', ' mgr.osctlr.home.visualbits.net', 'mds', 'allow *', 'mon', 'allow profile mgr', 'osd', 'allow *'] returncode: 1 output: stdout: \"\", stderr: \"[errno 1] error connecting to the cluster\n\""} Errors in log from ceph: TASK [ceph : Getting ceph mgr keyring] ****************************************************************************************************************************** failed: [osctlr.home.visualbits.net -> osctlr.home.visualbits.net] (item= osctlr.home.visualbits.net) => {"changed": false, "item": " osctlr.home.visualbits.net", "msg": "Failed to call command: ['docker', 'exec', 'ceph_mon', 'ceph', '--format', 'json', 'auth', 'get-or-create', ' mgr.osctlr.home.visualbits.net', 'mds', 'allow *', 'mon', 'allow profile mgr', 'osd', 'allow *'] returncode: 1 output: stdout: \"\", stderr: \"[errno 1] error connecting to the cluster\n\""} keyrings look proper: (openstack) [root@osctlr ~]# md5sum /etc/kolla/ceph-mon/ceph.client.admin.keyring 4658c01282c791bce9c75678df9e21c9 /etc/kolla/ceph-mon/ceph.client.admin.keyring (openstack) [root@osctlr ~]# md5sum /var/lib/docker/volumes/ceph_mon_config/_data/ceph.client.admin.keyring 4658c01282c791bce9c75678df9e21c9 /var/lib/docker/volumes/ceph_mon_config/_data/ceph.client.admin.keyring I've removed the docker container, volume and kolla config directories multple times with the same error. I can't even run ceph status from the container bash itself. Any ideas?

2 2

RE: [nova] NUMA live migration - mostly how it's tested
by Zhong, Luyao 01 Mar '19

01 Mar '19

Hi all, There was something wrong with the live migration when using 'dedicated' cpu_policy in my test. Attached file contains the details. (I remove the original mail message otherwise the email message body will be so big that it will be held)

1 0

nimble PyPI status
by Devin Shanahan 01 Mar '19

01 Mar '19

Dear maintainer of nimble: I am reaching out since you are listed as a maintainer of nimble <https://pypi.org/project/nimble/> on PyPI. I am currently working on a project and we are exploring releasing our distribution under the same name. Our project is a library of data science and machine learning tools. It has been under development and used internally at our company for 7 years, and we are now considering providing it as an open-source project. Nimble is a metaphor for our team's vision for the project, and we would very much prefer to use that exact name on PyPI over a similar, but more complicated name, that could cause confusion. Since PyPI shows that nimble has not had a new release or been updated since August 10, 2016, I would like to know if you would be willing to relinquish the name, nimble, so that we could provide our project in that namespace on PyPI. It's a simple process and if you are willing to do this, we would be extremely grateful. I also completely understand if this is not something that you are willing to do, or if I have misinterpreted the status of nimble and it is in fact in active development. I would really appreciate hearing your reply either way, whether or not you would be willing to consider transferring ownership of nimble over to us. Thank you very much for your time. Devin

3 2

Router not allowing traffic in reverse
by John Carew 01 Mar '19

01 Mar '19

I have setup OpenStack with OVS. I have a single Hyper-V server running the controller and three CentOS instances(10.0.0.x) on a private subnet. I created a router in OpenStack with SNAT disabled, as I only want it to route traffic between the private subnet(10.0.0.x) and the external subnet(172.16.1.x)/internet. All of the instances can ping each other along with the external network(172.16.1.x). From the external network, I can ping the interface of the ovs router on the external network. I can not though ping inside the private network. A trace route stops at the IP of the OVS router. With wireshark, I do not see anything coming from the external pc’s IP. If I trace route it, I see packets making all the way to the OVS router and then stop. Since I can ping one way, and not the other; I believe there is something in the router/OVS that is stopping the packets to route into the private subnet. What do I need to look at? (I have disabled all firewalls on all OSes involved.) Here is a sudo design of the setup. Does respond to ping VM OVS Router priv int OVS Router ext int External PC 10.0.0.14 -> 10.0.0.1 -> 172.16.1.1 -> 172.16.1.10 Does not respond to ping External PC OVS Router ext int OVS Router priv int VM 172.16.1.10 -> 172.16.1.1 -> 10.0.0.1 -> 10.0.0.14

1 0