RFC: feature enablement and feature gating in BMO?

[Dmitry Tantsur]

Hi team,

I touched upon this topic during the weekly meeting, but since attendance was light and I didn't have a fully formed proposal yet, I want to bring it to the wider community now.

# TL;DR

I suggest we establish a standard way to

1. Turn optional features on and off

2. Gate features that are not fully implemented yet

# Prior art

IrSO has feature gates already [1]. I don't remember what I used as inspiration, but since it uses component-base, I assume it's reasonably consistent with Kubernetes itself.

We have two quite inconsistent ways to enable features:

1. HostClaims use CLI flag -hostclaims

2. ToR switch management uses environment variable IRONIC_NETWORKING_ENABLED

Both features are good candidates for the proposed change because they are incomplete and span several pull requests. My HostOperations work may become the next candidate.

# Feature gates

A feature gate is a way to *temporary* disable a feature while it's being implemented and tested. It stays off by default except for operators that explicitly opt into it. I suggest we simply follow the pattern established by IrSO and start with two feature gates: HostClaims and IronicNetworking, both off by default.

I'm not 100% sure whether we should prevent creating new resources when the feature gate is off. I think we should, otherwise users could end up with objects that are never reconciled. Feedback welcome.

# Feature enablement

While feature gates are designed to be temporary and start off by default, feature enablement aims to give operators flexibility. For instance, operators may want to never enable host claims or enable them only on some controllers.

I suggest that while host claims and networking are gated, we come up with a uniform way to enable these and future features. I favour CLI flags over environment variables because CLI flags are easily discoverable. We could use `-hostclaims` as a blueprint or base it on the feature gates format (which is `-feature-gates HostClaims=true,IronicNetworking=false`).

Opinions?

Dmitry

[1] https://github.com/metal3-io/ironic-standalone-operator/blob/main/api/v1alpha1/features.go

--

Red Hat GmbH, Registered seat: Werner von Siemens Ring 12, D-85630 Grasbrunn, Germany  
Commercial register: Amtsgericht Muenchen/Munich, HRB 153243,
Managing Directors: Ryan Barnhart, Charles Cachera, Avril Crosse O'Flaherty 

[Lennart Jern]

Hi!

This is a good idea!

I prefer the --feature-gates style. It makes it easy to find all feature gates in one place and avoids an explosion of flags. It is also the same style used by Kubernetes and CAPI if I'm not mistaken.

Regarding environment variables or config files, I would leave them out of the initial implementation. If there is demand for controlling the feature gates in these ways later, we can always add them.

The timing is also good. Let's get this sorted before it turns into a mess.

Br,

Lennart

---

From: 'Dmitry Tantsur' via Metal3 Development List <metal...@googlegroups.com>
Sent: Thursday, August 20, 2026 15:17
To: Metal3 Development List <metal...@googlegroups.com>
Cc: Allain Legacy <ale...@redhat.com>; pierre...@orange.com <pierre...@orange.com>
Subject: [metal3-dev] RFC: feature enablement and feature gating in BMO?

 

--
You received this message because you are subscribed to the Google Groups "Metal3 Development List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to metal3-dev+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/metal3-dev/CACNgkFz%2B5%3DMH8xK103cmS_fkyieipy_oD-Mh6VWD85gt2rKrQw%40mail.gmail.com.

[Allain Legacy]

I also prefer the `--feature-gates` style as it tends to be less noisy in the --help.  

Allain

Allain Legacy

he/him/his

Principal Software Engineer

ale...@redhat.com

[Kashif Khan]

Hi Dmitry,

+1 on feature-gates.

On the feature enablement, is the idea that some features would stay Default: false permanently even after they're stable, as a deliberate opt-in? Just want to understand if that's the distinction you're drawing between gates and enablement, or if you're thinking of a separate mechanism entirely.

BR

Kashif

---

From: 'Dmitry Tantsur' via Metal3 Development List <metal...@googlegroups.com>

Sent: Thursday, August 20, 2026 3:17 PM

To: Metal3 Development List <metal...@googlegroups.com>
Cc: Allain Legacy <ale...@redhat.com>; pierre...@orange.com <pierre...@orange.com>
Subject: [metal3-dev] RFC: feature enablement and feature gating in BMO?

--

[Dmitry Tantsur]

Hi all,

I think I need an important clarification: we're discussing adding *two different things*:

1) Feature gates are designed to be removed eventually. They protect operators from features that are not ready or well tested. All large features should use them initially.

2) Feature enablement flags are to stay. They provide flexibility to operators. Not all features will be opt-in in the long term.

A feature may have both, either, or neither. So we may end up with situation like `-feature-gates HostClaims=true -enable-features HostClaims=true` (or `-feature-gates HostClaims=true -hostclaims` in the 2nd variant), where the first part is temporary.

Dmitry

[pierre...@orange.com]

Ok for the gate approach but what is the difference between features and enablement in their behavior ? I may have a clue to answer my own question: the enablement gate only controls the controller, the feature-gate should also disable behavior in other controllers that refer to the resource (the scheme should not be even recognized and the associated CRD should not be needed). But that may not be easy to implement/test.

If on the other hand, there is no difference but the fact one is temporary, I am not sure that we need both (removing the feature-gate is may be a change of the default value of the enablement).

I also think that every controller should be controlled by an enablement gate/flag even bmh for example. A use-case is enabling hostclaim cluster-scope without BMH controller and several BMH controllers namespace scoped. When networking will evolve, I would not be surprised to see the same need.

Pierre

--

Pierre Crégut
INNOV/NET/CISS/IIE/NAVI
pierre...@orange.com

____________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

[Dmitry Tantsur]

Okay, so we basically take the approach I initially used with IrSO, which is subtly different from Kubernetes (IIUC):

We only use feature gates, and they're not removed when the feature matures. Instead, they start as disabled, eventually *maybe* become enabled, and remain like that so that operators can always change them if they need to.

Did I get this right?

I guess the only potential issues are webhooks. Ideally, we should prevent creating gated resources if the gate is disabled. I'm not sure it will work with the idea of having different features enabled across different BMO instances.

Dmitry

--

You received this message because you are subscribed to the Google Groups "Metal3 Development List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to metal3-dev+...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/metal3-dev/61634b16-5ba5-4e59-b89d-81ec3b0c234e%40orange.com.

[pierre...@orange.com]

Your summary is right but you have a valid point with webhooks. Feature gates could just prevent the creation of resources at webhook level: no resource implies no reconciliation even if the controller is active (but there is no reason to keep it active). On the other hand enabling would act on controllers and not webhooks.