Installation of BMO can be made easier and better documented

[vidarno]

User Story

As an operator, I want a simple, reproducible, and supported way to install and upgrade Bare Metal Operator (BMO) using mechanisms that are commonly used and well-understood in other Kubernetes projects.

Detailed Description

The currently documented installation method for BMO involves cloning the repository and running deploy.sh, which renders manifests and applies them directly (optionally including Ironic).

From an operator perspective, this approach has a few drawbacks:

1. Operational ergonomics

• Requiring a local clone of the repository and execution of a script feels clunky compared to the installation workflows used by many other Kubernetes operators.

• The documentation does not strongly guide users towards deploying Ironic via IRSO, which can lead to less optimal or inconsistent setups.

2. Image versioning / reproducibility

• The manifests generated by deploy.sh do not set an explicit image tag, which results in the controller using :latest.

• This can lead to breakage on Pod restart if a newer image is pulled that expects CRDs or behavior not yet present in the cluster.

• We recently experienced exactly this scenario.

• Notably, the release artifacts already generated by the project do pin the image tag, so the project clearly already has a concept of versioned, reproducible manifests.

Proposed Improvements

I’d like to suggest a small, incremental improvement, as well as a possible longer-term direction:

1. Short-term: pin the image tag in deploy.sh

As an immediate safety improvement, deploy.sh should set the image tag explicitly (for example via an environment variable or derived from the release version), instead of defaulting to latest.

This would:

• Prevent accidental upgrades on Pod restart

• Align deploy.sh behavior with the already existing release artifacts

• Reduce the risk of CRD / controller version skew

2. Medium-term: offer a more conventional installation path

In addition to (not necessarily replacing) deploy.sh, consider one or both of the following:

• Static, versioned manifests per release, published as release artifacts and documented as the recommended install/upgrade path (similar to cert-manager and other operators).

• A Helm chart for BMO without Ironic, where:

  • CRDs are managed separately (as is already common practice and consistent with earlier concerns),

  • Helm is used only for the controller, RBAC, and related resources.

This is not a proposal for Helm to manage CRD lifecycle automatically, but rather to provide an optional, familiar packaging format for users who already operate clusters using Helm or GitOps tools.

Anything else you would like to add:

• I am aware of earlier discussions and concerns around Helm support for BMO, and I believe those concerns are still valid — especially around CRD ownership and lifecycle.

• The intention here is not to remove or replace the existing deployment approach, but to:

  • improve safety and reproducibility of the current script, and

  • optionally provide a more conventional and discoverable installation path for new users.

• There is also an existing SUSE Helm chart for BMO, but it is currently outdated. Many users are understandably uncomfortable relying on third-party charts for core infrastructure components.

/kind feature

[Rozzii]

/triage accept
Please use this issue as a tracker issue, and create sub issue so that the individual tasks and problems are easier to follow. Please also link the old issues that are related to the same problem domain

[metal3-io-bot]

@Rozzii: The label(s) triage/accept cannot be applied, because the repository doesn't have them.

Details

In response to this:

/triage accept
Please use this issue as a tracker issue, and create sub issue so that the individual tasks and problems are easier to follow. Please also link the old issues that are related to the same problem domain

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-sigs/prow repository.

[Rozzii]

/triage accepted

[vidarno]

Older issues on the same topic, ie helm:
#1987
#1649

The problem with deploy.sh is being handled in a separate issue #2970

I would like to create a separate issue for the lack of a helm chart and possibly propose an updated version of the SUSE helm chart as a solution.
In the community meeting a good suggestion was to support kustomize as well, which should probably be its own issue.

The bigger discussion surrounding how to deploy metal3 in its entirety or to provide an umbrella chart for BMO which also included IRSO can be left in Discussions until a more concrete suggestion is on the table.

Is this a good summary of what was agreed upon during the meeting and a path forward? Anything missing?

[Rozzii]

Older issues on the same topic, ie helm: #1987 #1649

The problem with deploy.sh is being handled in a separate issue #2970

I would like to create a separate issue for the lack of a helm chart and possibly propose an updated version of the SUSE helm chart as a solution. In the community meeting a good suggestion was to support kustomize as well, which should probably be its own issue.

Sounds good, please do so!

The bigger discussion surrounding how to deploy metal3 in its entirety or to provide an umbrella chart for BMO which also included IRSO can be left in Discussions until a more concrete suggestion is on the table.

Yes, please open a GH discussion about this topic.

Is this a good summary of what was agreed upon during the meeting and a path forward? Anything missing?

Good summary for now.