Public bug reported: Description ===========
Our application require a number of Cinder volumes to be attached to the Nova instance. They always need to be attached in the same order, the order matter to the software defined storage application. How they are presented in our application determines what "disk" the Cinder volume becomes in the application (our software defined storage VM has boot, root, coredump, data disks, etc.) We use the OpenStack API to create the resources (Cinder, Neutron, Nova, etc.) and attach them with a Nova server create call. Most of the time the volumes are attached in the correct order, but about 1 out of 10 times, the order of the volumes as they are presented in the nova API call (Python list) is not preserved. This causes our SDS VM to fail booting because it does not get the disks it expects in the correct order. Most VMs do not care about the order in which the cinder volumes are presented in the VM, in our case it is significant. Steps to reproduce ================== This has been done using the OpenStack API, which is the best way to programmatically reproduce the problem, but could likely be done with OS CLI as well. 1. Create a number of Cinder volumes in a way which they can be uniquely identified in the VM instance (different sizes, etc. 2. Attach volumes to Nova instance and boot. 3. repeat steps 1 & 2 enough times, and the cinder volumes will be attached to the nova instance in a different order than what was specified. This can be verified by checking the libvirt XML file that is generated by nova (virsh dumpxml <domain name>). Expected result =============== Given an ordered list of Cinder volumes to be attached to a nova instance, the expected result is that they are attached in the specified order every time. Actual result ============= Most times the expected result is true, about 1 out of 10 times, the order the volumes are attached to the nova instance is not what is expected. Environment =========== RedHat RDO - Liberty openstack-nova-compute-12.0.4-1.el7.noarch 1. Exact version of OpenStack you are running. See the following list for all releases: http://docs.openstack.org/releases/ 2. Which hypervisor did you use? Libvirt + KVM libvirt-daemon-2.0.0-10.el7_3.5.x86_64 libvirt-daemon-2.0.0-10.el7_3.5.x86_64 qemu-kvm-common-rhev-2.6.0-28.el7_3.9.x86_64 qemu-kvm-rhev-2.6.0-28.el7_3.9.x86_64 libvirt-daemon-driver-qemu-2.0.0-10.el7_3.5.x86_64 2. Which storage type did you use? Cinder NFS driver for Netapp FAS; Cinder iSCSI driver for SolidFire 3. Which networking type did you use? Neutron with openvswitch. Logs & Configs ============== N/A ** Affects: nova Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1697580 Title: Cinder volumes not always attached to instance in order presented Status in OpenStack Compute (nova): New Bug description: Description =========== Our application require a number of Cinder volumes to be attached to the Nova instance. They always need to be attached in the same order, the order matter to the software defined storage application. How they are presented in our application determines what "disk" the Cinder volume becomes in the application (our software defined storage VM has boot, root, coredump, data disks, etc.) We use the OpenStack API to create the resources (Cinder, Neutron, Nova, etc.) and attach them with a Nova server create call. Most of the time the volumes are attached in the correct order, but about 1 out of 10 times, the order of the volumes as they are presented in the nova API call (Python list) is not preserved. This causes our SDS VM to fail booting because it does not get the disks it expects in the correct order. Most VMs do not care about the order in which the cinder volumes are presented in the VM, in our case it is significant. Steps to reproduce ================== This has been done using the OpenStack API, which is the best way to programmatically reproduce the problem, but could likely be done with OS CLI as well. 1. Create a number of Cinder volumes in a way which they can be uniquely identified in the VM instance (different sizes, etc. 2. Attach volumes to Nova instance and boot. 3. repeat steps 1 & 2 enough times, and the cinder volumes will be attached to the nova instance in a different order than what was specified. This can be verified by checking the libvirt XML file that is generated by nova (virsh dumpxml <domain name>). Expected result =============== Given an ordered list of Cinder volumes to be attached to a nova instance, the expected result is that they are attached in the specified order every time. Actual result ============= Most times the expected result is true, about 1 out of 10 times, the order the volumes are attached to the nova instance is not what is expected. Environment =========== RedHat RDO - Liberty openstack-nova-compute-12.0.4-1.el7.noarch 1. Exact version of OpenStack you are running. See the following list for all releases: http://docs.openstack.org/releases/ 2. Which hypervisor did you use? Libvirt + KVM libvirt-daemon-2.0.0-10.el7_3.5.x86_64 libvirt-daemon-2.0.0-10.el7_3.5.x86_64 qemu-kvm-common-rhev-2.6.0-28.el7_3.9.x86_64 qemu-kvm-rhev-2.6.0-28.el7_3.9.x86_64 libvirt-daemon-driver-qemu-2.0.0-10.el7_3.5.x86_64 2. Which storage type did you use? Cinder NFS driver for Netapp FAS; Cinder iSCSI driver for SolidFire 3. Which networking type did you use? Neutron with openvswitch. Logs & Configs ============== N/A To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1697580/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : [email protected] Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
