Description of problem: openstack baremetal import should not require pm_user and pm_password when redfish is used in the imported json file instackenv.json snippet: { "name": "compute-0", "mac": ["52:54:00:36:06:39"], "cpu": "4", "memory": "6144", "disk": "50", "arch": "x86_64", "pm_type": "redfish", "pm_addr": "http://192.168.24.1:8001", "pm_system_id": "/redfish/v1/Systems/compute-0", "pm_user": "admin", "pm_password": "admin" } pm_user and pm_password here are just placeholders, because they are not required by redfish. The import command, however, does require them and will fail when these fields are not present. To improve user experience with redfish based systems these two fields should not be mandatory when "pm_type": "redfish" is set for a node Version-Release number of selected component (if applicable): OSP12 openstack-nova-placement-api-16.0.3-0.20171028031400.60d6e87.el7ost.noarch openstack-glance-15.0.0-3.el7ost.noarch openstack-swift-account-2.15.1-2.el7ost.noarch openstack-heat-api-9.0.1-0.20171023060845.be1e2e9.el7ost.noarch python-openstackclient-3.12.0-1.el7ost.noarch openstack-neutron-common-11.0.1-3.el7ost.noarch openstack-swift-proxy-2.15.1-2.el7ost.noarch openstack-ironic-api-9.1.2-0.20171025074857.cf3665f.el7ost.noarch openstack-tripleo-image-elements-7.0.1-0.20171020101256.2e61e31.el7ost.noarch openstack-mistral-engine-5.1.1-0.20171027222844.fd979d9.el7ost.noarch openstack-nova-common-16.0.3-0.20171028031400.60d6e87.el7ost.noarch puppet-openstacklib-11.3.1-0.20170921022915.6e2b844.el7ost.noarch openstack-puppet-modules-11.0.0-0.20170828113154.el7ost.noarch openstack-tripleo-heat-templates-7.0.3-0.20171024200825.el7ost.noarch openstack-nova-scheduler-16.0.3-0.20171028031400.60d6e87.el7ost.noarch openstack-swift-object-2.15.1-2.el7ost.noarch openstack-neutron-11.0.1-3.el7ost.noarch openstack-neutron-openvswitch-11.0.1-3.el7ost.noarch openstack-heat-engine-9.0.1-0.20171023060845.be1e2e9.el7ost.noarch openstack-ironic-conductor-9.1.2-0.20171025074857.cf3665f.el7ost.noarch openstack-tempest-17.1.0-1.el7ost.noarch openstack-mistral-executor-5.1.1-0.20171027222844.fd979d9.el7ost.noarch openstack-zaqar-5.0.1-0.20171027110724.4f07aed.el7ost.noarch openstack-tripleo-common-containers-7.6.3-0.20171028055750.el7ost.noarch openstack-keystone-12.0.0-2.el7ost.noarch openstack-tripleo-common-7.6.3-0.20171028055750.el7ost.noarch openstack-nova-conductor-16.0.3-0.20171028031400.60d6e87.el7ost.noarch openstack-swift-container-2.15.1-2.el7ost.noarch openstack-heat-common-9.0.1-0.20171023060845.be1e2e9.el7ost.noarch openstack-ironic-inspector-6.0.1-0.20170920142417.77e2b1a.el7ost.noarch openstack-mistral-common-5.1.1-0.20171027222844.fd979d9.el7ost.noarch openstack-tripleo-ui-7.4.3-2.el7ost.noarch openstack-tripleo-validations-7.4.1-2.el7ost.noarch openstack-selinux-0.8.11-0.20171013192233.ce13ba7.el7ost.noarch openstack-tripleo-puppet-elements-7.0.1-0.20171020122223.82d7e6c.el7ost.noarch puppet-openstack_extras-11.3.1-0.20170906070209.b99c3a4.el7ost.noarch openstack-ironic-common-9.1.2-0.20171025074857.cf3665f.el7ost.noarch python-openstackclient-lang-3.12.0-1.el7ost.noarch openstack-mistral-api-5.1.1-0.20171027222844.fd979d9.el7ost.noarch openstack-nova-api-16.0.3-0.20171028031400.60d6e87.el7ost.noarch openstack-nova-compute-16.0.3-0.20171028031400.60d6e87.el7ost.noarch openstack-neutron-ml2-11.0.1-3.el7ost.noarch openstack-heat-api-cfn-9.0.1-0.20171023060845.be1e2e9.el7ost.noarch python-openstacksdk-0.9.17-1.el7ost.noarch puppet-tripleo-7.4.3-0.20171025110207.el7ost.noarch python-tripleoclient-7.3.3-1.el7ost.noarch How reproducible: always Steps to Reproduce: 1. set up a redfish based system 2. populate instackenv.json with the relevand fields, omitting pm_user and pm_password 3. try to import Actual results: fail Expected results: should work for redfish nodes Additional info:
Correcting the component. Actually, I don't think I agree. Any sane production installation will require a user name and a password. For virtual testing we can use fake user/password as you did.
(In reply to Dmitry Tantsur from comment #1) > Correcting the component. > > Actually, I don't think I agree. Any sane production installation will > require a user name and a password. For virtual testing we can use fake > user/password as you did. I'm not saying we shouldn't use a user/password fields at all, I'm saying they should not be required in this case, and a user should not have to push in fake details to satisfy a hardcoded limitation - that's textbook bad UX.
> Any sane production installation will require a user name and a password. Thinking aloud: authentication credentials can theoretically take many different shapes. For example, kerberos would require just user ID. Or it can be an authentication token (jwt) or a HTTP cookie. TLS connection may require a pair of X.509 certificates. SNMP authentication ranges from just community name up to username + two keys + context ID. So you got my point. ;) May be we could take this mis/feature as an opportunity to generalize BM authenticator configuration somehow?
Removing keyword as not triaged yet.
The command to import is 'openstack overcloud node import' To verify this bug - need to wait until https://bugzilla.redhat.com/show_bug.cgi?id=1640826 gets closed.
Verified: Environment: openstack-tripleo-common-9.4.1-0.20181002162541.5a9c7aa.el7ost.noarch Was able to import a node with pm_type redfish and no pm_user/pm_password: { "nodes": [ { "name": "controller-9", "cpu": "4", "memory": "32768", "disk": "40", "arch": "x86_64", "pm_addr": "192.168.24.1", "pm_system_id": "12", "pm_type": "redfish" } ] } (undercloud) [stack@undercloud ~]$ openstack baremetal node list|grep controller-9 | f9eba5cf-768a-439c-be4a-5bebab2da14c | controller-9 | None | None | enroll | False | Note that 'pm_system_id' is mandatory for redfish.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHEA-2019:0045