RFE: support keystone authentication (external keystone only)

[ydp]

User Story

As a [developer/user/operator] I would like to have baremetal-operator support keystone auth, because currently it seems that keystone is necessary to support multiple conductor deployment for large scale, or is my understanding wrong?

Detailed Description

Support external ironic deployment with keystone auth, so that multiple conductor can be added to support large scale deployment.

Anything else you would like to add:

This is the doc https://docs.openstack.org/ironic/latest/install/install-ubuntu.html#install-and-configure-components I experimented and got current thoughts.

I guess to support this, we should first add multiple conductor support in bifrost, which seems to me not support yet, I did not find a good guide on how to add additional conductor in bifrost scenario, only the above page in ironic doc.

Currently, I installed ironic with bifrost on one node, then installed additional ironic with dhcp (inspector) disabled on another node, and modify the additional ironic config (database connection) to connect to the first ironic database, then I can see 2 conductor showed up, but to get it to work, I need to setup a keystone service, and modify both ironic configs (rpc_transport, auth_strategy) to use keystone auth, this seems to work on ironic side, at least the baremetal node command works fine now, however, baremetal-operator cannot use keystone auth to connect to my ironic deployment, please help suggest the best way to do this. Thank you!

[Miscellaneous information that will assist in solving the issue.]

/kind feature

[ydp]

The reason to use multiple conductor is as the doc https://docs.openstack.org/ironic/latest/install/refarch/common.html#performance suggested:

We recommend a target of 100 bare metal nodes per conductor for maximum reliability and performance. There is some tolerance for a larger number per conductor. However, it was reported 1 2 that reliability degrades when handling approximately 300 bare metal nodes per conductor.

to support large scale.

[ydp]

I think I got it work that only communication between ironic-api and ironic-conductor uses keystone, external access to ironic-api still uses http basic. Hope this helps someone like me.

[dtantsur]

@ydp I think you're a bit confused. Nothing current uses keystone in the way metal3 normally sets up Ironic. It would actually be pretty cool for baremetal-operator to support Keystone authentication, although it's a non-trivial amount of work. I think the feature request is valid.

[dtantsur]

But you're right that keystone support has nothing to do with the multiple conductor story (which is another thing we want to have).

[ydp]

@dtantsur Yes, I was not clear about how those components interact at the time, and set up external Ironic with multiple conductor, but anyway, it works now! Thank you for explaining!

[ydp]

Just found another reason to support keystone, using ironic-ui with dashboard...

[dtantsur]

I can provide you with an even more interesting reason: using the ironic multi-tenancy, so that e.g. your baremetal-operator does not access nodes that belong to someone else. Let's keep this open.

/triage accepted
/kind enhancement

[metal3-io-bot]

@dtantsur: The label(s) kind/enhancement cannot be applied, because the repository doesn't have them.

Details

In response to this:

I can provide you with an even more interesting reason: using the ironic multi-tenancy, so that e.g. your baremetal-operator does not access nodes that belong to someone else. Let's keep this open.

/triage accepted
/kind enhancement

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.