Fuel 9.2 fails to recognise disks on additional controller

[Robert Jesacher]

Detailed bug description:
 I did a fresh install of MOS 9.0 and upgraded to 9.2
 There are hosts with an additional disk-controller installed, and in Fuel only 2 disks instead of 6 are shown. Two other hosts have 3 disks installed and also only 2 are recognised.
With a shell on the servers, I see, that the disks are recognised by the bootstrap-OS, but not in Fuel.
When using a MOS 9.0 installation this works as expected.

Steps to reproduce:
Install MOS 9.0, upgrade to 9.2
Boot hosts and let them come up with bootstrap-image
-> check a host in fuel, disks are missing

Expected results:
6 disks recognised
(or 2nd case: 3 disks recognised)

Actual result:
only 2 disk are recognised (also for the 2nd case)

Reproducibility:
did try 2 times with the same result
(also brought up a fresh 9.0 to check if it still works there)

Workaround:
1) in case of using CEPH: add disks manually (untested)
or 2) install MOS 9.0 let host come up with bootstrap from 9.0
then switch to 9.2 on Fuel-master (I have two virtualbox-images). As soon as the hosts are talking to the 9.2 master, they are recognised correctly.

Impact:
disks cannot be used or only by manual intervention per ssh.
This seems to be only an issue for fresh 9.2 installations.

Description of the environment:
MOS 9.0 or 9.2 Fuel-master on virtualbox (to switch between versions)
3x small HW-boxes with 2x3 disks and 1x6disks

Additional information:
somehow this makes me suspect, that something changed between the bootstrap-image of 9.0 and 9.2, that causes that behaviour. unfortunately I was not able to test on 9.1

PLMK if you need additional information.

br,
Robert

[Robert Jesacher (jesacher)]

I can now confirm, that the workaround with the Fuel Master on MOS 9.0 works:
* you need a 9.0 fuel master
* boot the systems while on MOS 9.0 and wait, until they are recognised by the fuel-master.
* shut down only the 9.0 master
* boot up the 9.2 master and wait until the nodes report to that master.
* create an environment and proceed on MOS 9.2

[Max Yatsenko (myatsenko)]

Unfortunatelly, I was not able to reproduce this issue.

To reproduce it I tried the following:

1
1.1 MOS9.0 environment was deployed: 1Controller, 3Computes
1.2 Slave nodes were turned off and additional block devices were added to the slaves
1.3 Slaves were started
1.4 All block devices were identified by Fuel
1.5 MOS9.0 environment was updated upto MOS9.2
1.6 All slave nodes were rebooted
1.7 All block devices on every slave node were identified by Fuel

2
2.1 MOS9.0 environment was deployed: 1Controller, 3Computes
    and it was updated upto MOS9.2
2.2 Slave nodes were turned off and additional block devices were added to the slaves
2.3 Slaves were started
2.4 All block devices on every slave node were identified by Fuel

3
3.1 MOS9.2 environment was deployed: 1Controller, 3Computes
3.2 Slave nodes were turned off and additional block devices were added to the slaves
3.3 Slaves were started
3.4 All block devices on every slave node were identified by Fuel

I set this bug to Incomplete as it was not reproduced.
Please provide more information about this issue and more detailed steps to reproduce
this problem.

[Robert Jesacher (jesacher)]

Hi Max,

maybe I was not precise enough: the issue is not 9.2 adding block devices itself, the problem arises, if there are more then 1 disk-controllers in the system.

If there is a system with 2 disk-controllers and disks on both, it will not show the disks of the 2nd one after booting from bootstrap (however the disk-devices are visible on the OS level of the booted image)

I did not have time to check if this is also true for virtual-only environments, but for the physical systems i have, it was reproducible. Meanwhile I tried to export a 9.0 bootstrap image and import it in 9.2 - in this way it correctly identifies the disks on both disk-controllers. So my best guess is that there was some change in the bootstrap between 9.0 and 9.2 (again I could not test 9.1)

Please let me know if I can provide more info, or be of any other assistance.

br,
Robert