Yea, the configdrive is a non-issue for us since we don’t use those. The multi-drive issue is the only one really affecting us. While removing the second drive and reattaching it after boot is probably a good solution, I think it’s likely the issue will come back after a hard reboot or migration. Probably better to wait before I start converting my multi-disk instances to virtio-scsi. If I am not mistaken, this should also be an issue in Pike and master, right?
Jean-Philippe Méthot Openstack system administrator Administrateur système Openstack PlanetHoster inc. > Le 26 janv. 2018 à 14:23, Logan V. <lo...@protiumit.com> a écrit : > > There is a small patch in the bug which resolves the config drive > ordering. Without that patch I don't know of any workaround. The > config drive will always end up first in the boot order and the > instance will always fail to boot in that situation. > > For the multi-volume instances where the boot volume is out of order, > I don't know of any patch for that. One workaround is to detach any > secondary data volumes from the instance, and then reattach them after > booting from the one and only attached boot volume. > > Logan > > On Thu, Jan 25, 2018 at 10:21 PM, Jean-Philippe Méthot > <jp.met...@planethoster.info> wrote: >> Thank you, it indeed seems to be the same issue. I will be following this >> bug report. A shame too, because we were waiting for the patch to allow us >> to setup 2 drives on virtio-scsi before starting to make the change. In the >> meantime, have you found a way to circumvent the issue? Could it be as easy >> as changing the drive order in the database? >> >> >> Jean-Philippe Méthot >> Openstack system administrator >> Administrateur système Openstack >> PlanetHoster inc. >> >> >> >> >> Le 26 janv. 2018 à 13:06, Logan V. <lo...@protiumit.com> a écrit : >> >> https://bugs.launchpad.net/nova/+bug/1729584 >> >>
_______________________________________________ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators