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.
Seeing this RHOP 10 as well.
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
Checking in here, any updates on this please?
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 ***