Open Stack

On Wed, Apr 06, 2016 at 10:28:44AM +0200, Dmitry Tantsur wrote:
> Hi OOO'ers!
> 
> I'd like to get your permission to backport
> https://review.openstack.org/#/c/288417/ to stable/{liberty,mitaka} or seek
> alternative suggestions on how to make life easier for folks upgrading for
> Kilo.
> 
> The context of the problem is the following. In the Liberty release we (with
> the whole Ironic world) have switched from the old bash-based Ironic deploy
> ramdisk to IPA. I can't talk enough about benefits that it brought us, but
> today I want to talk about one drawback.
> 
> IPA has a different logic for choosing the root device for deployment, when
> several root devices are present. The old ramdisk always tried to find a
> disk by name present in the Ironic disk_devices configuration option,
> defaulting to something like "sda,hda,vda". IPA takes the smallest device
> which is greater than 4 GiB. Obviously, it's not guaranteed to be the same.
> 
> What it means is that when people upgrade their undercloud from Kilo and
> Liberty and beyond, and rebuild an overcloud node, this node may end up with
> a different root device picked by default. In the absence of cleaning, that
> will probably result in deployment failure (e.g. due to duplicated config
> drive).
> 
> A side note: the same was possible and actually happened back in Kilo,
> because device names are not reliable, and can change between reboots.
> 
> Now, the Ironic team has always recommended using root device hints for
> several root devices. However, there are valid complaints from users that
> running node-update on every node is not really convenient. And he is the
> patch in question: it adds a new flag to 'baremetal configure boot' to
> bulk-set root device hints based on a strategy or list of device names. The
> root device information is fetched from the introspection data. This allows
> people upgrading from Kilo to just do:
> 
>  openstack baremetal configure boot --root-device=sda,hda,vda
> 
> to create root device hints matching the previous behavior. I suggest we
> backport this patch to simplify life for people.

+1 - I think we can consider this a bug, e.g from a user perspective
choosing the wrong/different device after upgrade is a bug, and this
provides a way around it.

So I'd suggest you raise a bug (if one doesn't already exist) and propose
the backports.

Also it would appear from a quick look at the patch that it's low-risk from
a backport perspective, as it adds new options which a user may ignore if
they desire the default (current) behavior instead.

Thanks!

Steve