Adding pxe_ucs to enabled_hardware_types in undercloud.conf results in empty driver list. Environment: python-ironic-lib-2.12.1-1.el7ost.noarch instack-undercloud-8.4.3-3.el7ost.noarch python2-ironic-neutron-agent-1.0.0-1.el7ost.noarch openstack-ironic-conductor-10.1.3-3.el7ost.noarch python-ironic-inspector-client-3.1.1-1.el7ost.noarch puppet-ironic-12.4.0-2.el7ost.noarch openstack-ironic-common-10.1.3-3.el7ost.noarch openstack-ironic-staging-drivers-0.9.0-4.el7ost.noarch openstack-ironic-api-10.1.3-3.el7ost.noarch openstack-ironic-inspector-7.2.1-2.el7ost.noarch python2-ironicclient-2.2.1-1.el7ost.noarch Steps to reproduce: Add the following line to undercloud.conf: enabled_hardware_types = ipmi,redfish,ilo,idrac,pxe_ucs and run/re-run 'openstack undercloud install' Once completed: (undercloud) [stack@undercloud-0 ~]$ openstack baremetal driver list (undercloud) [stack@undercloud-0 ~]$ Expected result: A list of drivers. If you remove pxe_ucs from the line leaving only "enabled_hardware_types = ipmi,redfish,ilo,idrac", then after re-running 'openstack undercloud install' you'll get the list of drivers. (undercloud) [stack@undercloud-0 ~]$ openstack baremetal driver list +---------------------+-----------------------+ | Supported driver(s) | Active host(s) | +---------------------+-----------------------+ | idrac | localhost.localdomain | | ilo | localhost.localdomain | | ipmi | localhost.localdomain | | pxe_drac | localhost.localdomain | | pxe_ilo | localhost.localdomain | | pxe_ipmitool | localhost.localdomain | | redfish | localhost.localdomain | +---------------------+-----------------------+
Hi! If the logs were posted to this bug ;) you'd see that ironic-conductor crashed because pxe_ucs (like anything starting with pxe_) is a classic driver, not a hardware type. Use enabled_drivers for it or use the cisco-ucs-managed hardware type (OSP 14+).
If you add 'foo' to the list, the driver list also becomes empty. Can we use this bug to add validation instead of successfully running and ending with an empty list? Re-opening for now.
Let's rephrase accordingly then. However, since any change will be breaking, I doubt we'll do it.
Is the issue that setting an invalid string, i.e. not a valid hardware type, in enabled_hardware_types causes a ironic-conductor crash?
> Is the issue that setting an invalid string, i.e. not a valid hardware type, in enabled_hardware_types causes a ironic-conductor crash? This is by design. I assumed Sasha is talking about returning something more obvious than an empty list from the 'driver list' command.
Right, best would be to show error even before running undercloud installation. Otherwise, IMHO we should just fail during uc installation. Note: enabled_drivers is deprecated and isn't even shown in OSP14 sample file.
It's actually a good question why the installation proceeds even if one service failed to start.
Given the age of this item, it seems like we're not going to change the command as originally requested. Realistically tooling around changing these settings should be validating the contents of the list and the driver list changing any behavior would be a breaking change regardless, which as noted is unlikely to be accepted upstream. Marking Closed/Wontfix.