Bug 1366347

Summary:	[RFE] preserve boot order when setting a boot device
Product:	Red Hat OpenStack	Reporter:	Kambiz Aghaiepour <kambiz>
Component:	instack-undercloud	Assignee:	James Slagle <jslagle>
Status:	CLOSED DUPLICATE	QA Contact:	Arik Chernetsky <achernet>
Severity:	high	Docs Contact:
Priority:	high
Version:	9.0 (Mitaka)	CC:	athomas, bfournie, dbecker, dsneddon, jeder, kambiz, mburns, mcornea, morazi, racedoro, rhel-osp-director-maint, sasha, smalleni, tvignaud, wfoster
Target Milestone:	Upstream M2	Keywords:	Triaged
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:	aos-scalability-34
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2017-10-20 11:00:43 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	1473267

Description Kambiz Aghaiepour 2016-08-11 17:37:28 UTC

Description of problem:

We have an environment which has multiple PXE interfaces.  We start off with the boot order of:

BootSeq=NIC.Integrated.1-1-1,NIC.Integrated.1-2-1,HardDisk.List.1-1

(these are Dell servers)

After initial deployment, the boot order is not returned to the above order.  Sometimes hosts are left with the boot order:

BootSeq=NIC.Integrated.1-2-1,HardDisk.List.1-1,NIC.Integrated.1-1-1

and other hosts are set as:

BootSeq=HardDisk.List.1-1,NIC.Integrated.1-2-1,NIC.Integrated.1-1-1



The reason we want to use nic1,nic2,disk is to allow for a foreman deployment to occur if the host is marked for rebuild via foreman.  However if the host is not marked for rebuild, the system will continue to nic2, and then finally disk.  This boot order should never be modified, as it allows for the most flexibility in how hosts are provisioned, while still allowing for a director deployment to occur over nic2.

Somewhere in the director code (sorry I don't know exactly where) the current boot order is not being preserved.  I believe it to be related to:

https://github.com/openstack/instack-undercloud/blob/62b3b28e1525896fdfc9b03a9cca2621299c916e/instack_undercloud/undercloud.py#L1016


Version-Release number of selected component (if applicable):


How reproducible:
each time.

Steps to Reproduce:
1.  setup hosts that boot from nic1,nic2, disk
2.  deploy using director
3.  observe the changed boot order.

Comment 6 Sai Sindhur Malleni 2016-08-22 14:19:09 UTC

Seeing this RHOP 10 as well.

Comment 8 Kambiz Aghaiepour 2016-08-30 12:08:41 UTC

One possible workaround was to unset the boot_option in the flavors.  However this seems to break things before we can even introspect.  Running the following on a newly installed undercloud and pinning flavors to host:

    $ nova flavor-key control unset capabilities:boot_option
    $ nova flavor-key compute unset capabilities:boot_option
    $ nova flavor-key baremetal unset capabilities:boot_option
    $ nova flavor-key block-storage unset capabilities:boot_option
    $ nova flavor-key ceph-storage unset capabilities:boot_option
    $ nova flavor-key swift-storage unset capabilities:boot_option

causes the introspection to barf entirely, eg.

377dbddf-7d96-4ca9-8e2e-cf284108809e: Unexpected exception ValueError during processing: dictionary update sequence element #0 has length 1; 2 is required
080e3c79-0993-4f9d-8b73-f8d73703c7ed: Unexpected exception ValueError during processing: dictionary update sequence element #0 has length 1; 2 is required
f33da2b7-539d-4631-a116-eedf696ad354: Unexpected exception ValueError during processing: dictionary update sequence element #0 has length 1; 2 is required
cf4d467e-6fde-44a4-ac07-89269f39a3ba: Unexpected exception ValueError during processing: dictionary update sequence element #0 has length 1; 2 is required

Also:

$ openstack overcloud profiles list
dictionary update sequence element #0 has length 1; 2 is required

Comment 9 Will Foster 2016-12-01 12:35:12 UTC

Checking in here, any updates on this please?

Comment 11 Dmitry Tantsur 2017-10-20 11:00:43 UTC

Hi! This is actually a whole RFE. What complicates it is that not all drivers even allow to change the boot order (vs changing the boot device). We have an existing request for Dell.

*** This bug has been marked as a duplicate of bug 1394884 ***