baremetal: Add platform credentials check for BMC

[russellb]

Original issue from @stbenjam - openshift-metal3/kni-installer#162

In the baremetal platform, a user provides us BMC credentials. Like other platforms, we should do a credential check to make sure they work before getting further down the install process.

See: #1873 (comment)

[openshift-bot]

Issues go stale after 90d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle stale

[openshift-bot]

Stale issues rot after 30d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle rotten
/remove-lifecycle stale

[stbenjam]

We do have some BMC validation now, #3232, but just on the quality of the data (not duplicated, all required fields present, etc).

Because the installer has the ability to launch a VM on a remote libvirt and this is a use case we want ot support, it very well may be that libvirt host has access to the BMC's but there are zero guarantees the installer does. In fact, you probably want access to the BMC's limited as much as possible.

Given that I'd be inclined to close this -- what do you think @russellb @dhellmann?

[dhellmann]

I agree it's not always going to be possible for the installer to be able to communicate with the BMCs. Maybe if we get a routing or connection error we ignore it, but if we can connect and the credentials don't work we report that?

From a general error handling perspective, how much status do we report back from Ironic through the installer? If a host ends up in a bad state for any reason and we know that's going to cause the deployment to fail, can we exit with an error and give the reason back to the user? I feel like I've seen some errors from ironic when a deployment fails, but only after waiting.

The ACM team is interested in reporting more "activity" from the installer generally, so we can also think about it in those terms. Since it can take quite a long time, can we provide information about what's going on at different phases of the installation so it can be reflected in the UI to reassure a user that something is happening?

[stbenjam]

The installer doesn't have access to that today, #2679 tracks bubbling up more information, but if we tackle that it'll be part of 4.6 or later.

This issue is specifically to connect to the BMC's from the installer, and I don't see that as viable -- failing if auth explitly fails but not that you can't connect isn't very valuable, IMHO. What if a user gave us a bad IP? It's a big can of worms I'd rather not open. Implementing this also requires writing handlers in the installer for a myriad of protocols, iDRAC, iLO, IPMI, and Redfish.

[stbenjam]

Also: what if there's ACL's on the iLO side that make auth fail based on network rules, although the actual connection itself succeeds?

Seems like managing this is best left to Ironic, and getting more information bubbled up in #2679

[dhellmann]

OK, I agree with all of your reasoning and with the conclusion that we can close this.

[stbenjam]

Thanks

/close

[openshift-ci-robot]

@stbenjam: Closing this issue.

Details

In response to this:

Thanks

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.