Adaptec RAID controller is missing from available drives

[Yury Konov]

Using MOS 6.1 to deploy on Supermicro server with Adaptec RAID controller.
Fuel filters out existing drive - "Disks 0 drives, 0 bytes total".

Server config:
- chassis Super Micro CSE-826BE16-R920LPB
- motherboard SuperMicro MBD-X9SCM-F-B Bulk
- RAID controller Adaptec ASR-8405 SQL RAID 0/1/1Е/10/6/6/50/60, 4i ports 1Gb (2277600-R)
- CPU Intel Original LGA1155 Xeon E3-1230v2 (3.3GHz/8M) (SR0P4) OEM
- RAM Kingston DIMM 8GB 1600MHz DDR3 ECC CL11 w/TS KVR18E11/8
- HDD Hitachi SATA-II 1Tb HUA722010CLA330 Ultrastar A7K200G (7200rpm) 32Mb 3.5" Raid Edition
- NIC INTEL I350T2BLK Ethernet Server Adapter I350-T2

On that node:
[root@bootstrap ~]# cat /sys/block/sda/removable
1
[root@bootstrap ~]#

[Yury Konov (yukonoff)]

output from 'udevadm info --export-db'

[Alexander Gordeev (a-gordeev)]

ID_VENDOR=ASR8405

however,
adding only 'ASR8405' to the following lists https://github.com/stackforge/fuel-nailgun-agent/blob/master/agent#L46-L48
https://github.com/stackforge/fuel-agent/blob/master/fuel_agent/utils/hardware.py#L43-L45

will just unblock this particular ASR8405 raid device.

As an alternative, we could compare vendors by regexp, so adding something like 'ASR*' will allow fuel to recognize the most of ASRXXXX devices properly. But still, the rest of other devices made by Adaptec could have another ID_VENDOR and we still need to add them explicitly.

[Yury Konov (yukonoff)]

Suggestion:
It might be useful to give user an explicit opportunity to deploy on removable drives by enabling a check-box like "Enable removable drives" on a per-node basis.
That will prevent such situations in future.

[Alexander Gordeev (a-gordeev)]

there's another suggestion. To filter out all removable devices from USB and accept all removable device from PCI bus.

[Andrey Maximov (maximov)]

Guys, let's don't change status to In Progress unless we have code on review

[OpenStack Infra (hudson-openstack)]

Related fix proposed to branch: master
Review: https://review.openstack.org/216307

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/216307
Committed: https://git.openstack.org/cgit/stackforge/fuel-nailgun-agent/commit/?id=d7027952870a35db8dc52f185bb1158cdd3d1ebd
Submitter: Jenkins
Branch: master

commit d7027952870a35db8dc52f185bb1158cdd3d1ebd
Author: Alexander Gordeev <email address hidden>
Date: Mon Aug 24 18:17:11 2015 +0300

    Accept removable block devices by PCI vendor ID

    The issue is that, for particular raid controller obtaning vendor of
    block device from sysfs attributes is not realible.

    Once every raid controller is connected to PCI bus directly,
    it's more realible to look at vendor ID of that controller to which
    removable block device belongs.

    For example, Adaptec is a perfect canditate to be added to a list of
    removable PCI vendor IDs, since it's manufacturing RAID controllers
    mostly.

    Change-Id: Ib1018abbb46c65d909e594ad1d8921c8c5a139fc
    Related-Bug: #1486601

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/216806
Committed: https://git.openstack.org/cgit/stackforge/fuel-agent/commit/?id=1e8f38bbb864ed99aa8fe862b6367e82afec3263
Submitter: Jenkins
Branch: master

commit 1e8f38bbb864ed99aa8fe862b6367e82afec3263
Author: Alexander Gordeev <email address hidden>
Date: Tue Aug 25 20:26:15 2015 +0300

    Don't filter removable block devices

    list_block_devices should report all devices that it can find.
    If an error occurs during block device analysing,
    then it should be silently ignored and the device should be skipped.

    This change will let provisioning to proceed if this skipped device
    is not required for provisioning purposes.

    Change-Id: I9399b1e0855493289e82f40ffd8c892f89412f1c
    Related-Bug: #1486601

[Alexander Gordeev (a-gordeev)]

specific h/w required to verify: ASR8405 or slightly different model of RAID adapter made by Adaptec for which

$ cat /sys/block/<disk name>/device/vendor

returns something different from 'Adaptec', 'IBM', 'ServeRA'.

Expected result: deployment should succeed on slave nodes with that kind of h/w.

[Nastya Urlapova (aurlapova)]

Due agreement that if we don't have proper hardware we marked it as Fix Released with comment.