Detailed bug description:
apparently, fuel-agent installs grub stage0 on all of disks nailgun knows of.
https://github.com/openstack/fuel-agent/blob/master/fuel_agent/drivers/nailgun.py#L340-L341
it's done intentionally, this step allows us to boot from any of those disks. Without that, operator/administrator have to set proper boot order for disks in BIOS/UEFI setup utility for every single node.
it looks like grub-install spends a lot of time with analyzing all of disks with os-proper scripts. OS-prober scripts try to find presence of any other OS (operating system) to add it then to grub menu, thus allowing the user to choose which OS to boot. It seems it's not a case for Fuel as grub.conf file will be configured by fuel-agent https://github.com/openstack/fuel-agent/blob/master/fuel_agent/utils/grub.py#L230-L254
So, we're dealing with O(n^2) time complexity as every single call of grub-install will cause OS-prober to analyze all disks unconditionally.
I propose to tune OS-proper scripts or just disable them completely (Not sure which way is more better and easier to achieve). As fuel-agent controls everything explicitly in a data driven way. We're not in a need of additional logic from GRUB. Fuel-agent better knows where to install and how to configure GRUB bootloader for Fuel.
Steps to reproduce:
provision a node with huge number of disks. 20 or 30 may be good enough. Last stage of provisioning could take few minutes.
Expected results:
provisioning time won't be tied directly to a number of disks.
Actual result:
provisioning time is increasing. The latest step of provisioning, which usually lasts just a dozen of seconds, is almost squared.
Reproducibility:
every single time on a node with huge number of disks
Workaround:
unknown
Impact:
the last step of provisioning could take more amount of time than the provisioning itself. Horrible UX.
version: 9.0 (6.1+)
CHeck timestamps , on system with 64 drives:
2016-03-18 13:39:25.030 8862 DEBUG fuel_agent.
....
2016-03-18 13:47:41.209 8862 DEBUG fuel_agent.