[openstack-dev] [ironic] [inspector] RFC: deprecating "set IPMI credentials" feature in ironic-inspector
Dmitry Tantsur
dtantsur at redhat.com
Tue Dec 13 12:40:36 UTC 2016
Hi folks!
Since nearly its beginning, ironic-inspector has had a controversial feature: we
allow a user to request changing IPMI credentials of the node after
introspection. The new credentials are passed back from inspector to the
ramdisk, and the ramdisk calls "ipmitool" to set them.
Now I realize that the feature has quite a few substantial drawbacks:
1. It's a special case in ironic-inspector. It's the only thing that runs after
introspection, and it requires special state machine states and actions.
2. There is no way to signal errors back from the ramdisk. We can only poll the
nodes to see if the new credentials match.
3. This is the only place where ironic-inspector modifies physical nodes (as
opposed to modifying the ironic database). This feels like a violation of our goal.
4. It depends on ipmitool actually being able to update credentials from within
the node without knowing the current ones. I'm not sure how wildly it's
supported. I'm pretty sure some hardware does not support it.
5. It's not and never will be tested by any CI. It's not possible to test on VMs
at all.
6. Due to its dangerous nature, this feature is hidden behind a configuration
option, and is disabled by default.
The upside I see is that it may play nicely with node autodiscovery. I'm not
sure they work together today, though. We didn't end up using this feature in
our products, and I don't recall being approached by people using it.
I suggest deprecating this feature and removing it in Pike. The rough plan is as
follows:
I. Ocata:
* Deprecate the configuration option enabling this feature.
* Create an API version that returns HTTP 400 when this feature is requested.
* Deprecate the associated arguments in CLI.
* Issue a deprecating warning in IPA when this feature is used.
II. Pike:
* Remove the feature from IPA and ironic-inspector.
* Remove the feature from CLI.
Please respond with your comments and/or objects to this thread. I'll soon
prepare a patch on which you'll also be able to comment.
Dmitry.
More information about the OpenStack-dev
mailing list