search

metal3-io / baremetal-operator

Bare metal host provisioning integration for Kubernetes
Apache License 2.0
592 stars 253 forks source link

RFE: support keystone authentication (external keystone only) #1218

Open ydp opened 1 year ago

ydp commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

@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 commented 1 year ago

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 commented 1 year ago

@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 commented 1 year ago

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

dtantsur commented 1 year ago

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 commented 1 year ago

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

In response to [this](https://github.com/metal3-io/baremetal-operator/issues/1218#issuecomment-1471877233): >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](https://git.k8s.io/community/contributors/guide/pull-requests.md). If you have questions or suggestions related to my behavior, please file an issue against the [kubernetes/test-infra](https://github.com/kubernetes/test-infra/issues/new?title=Prow%20issue:) repository.
metal3-io-bot commented 1 year ago

Issues go stale after 90d of inactivity. Mark the issue as fresh with /remove-lifecycle stale. Stale issues will close after an additional 30d of inactivity.

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

/lifecycle stale

Rozzii commented 1 year ago

/help /remove-lifecycle stale /lifecycle frozen

metal3-io-bot commented 1 year ago

@Rozzii: This request has been marked as needing help from a contributor.

Please ensure the request meets the requirements listed here.

If this request no longer meets these requirements, the label can be removed by commenting with the /remove-help command.

In response to [this](https://github.com/metal3-io/baremetal-operator/issues/1218): >/help > /remove-lifecycle stale > /lifecycle frozen Instructions for interacting with me using PR comments are available [here](https://git.k8s.io/community/contributors/guide/pull-requests.md). If you have questions or suggestions related to my behavior, please file an issue against the [kubernetes/test-infra](https://github.com/kubernetes/test-infra/issues/new?title=Prow%20issue:) repository.