@shawkins This is the initial form of how it could work with the single property.

Thank you for taking this on.

What do you think of expressing this as:

--feature-<name>=vX|enabled|disabled

Is this a real issue? I don't think folks need to enable/disable that many features. If they really do I think we should consider something like also supporting a separate file.

If the argument is that folks will have many features to enable/disable this just makes it even worse IMO as you basically end up with more crud, not less.

Is this not also going to bloat the help completely?

You'd have --features that list all features, then also additionally have a separate option for each feature?

I don't think folks need to enable/disable that many features.

We're starting to add a lot of features. We're also not just talking about people trying things out locally.

Let's say I've been provided a containerized augmented image. Now I want to try out the new serdes optimization feature.

Without knowing the list of features that may already be configured in that augmented image, I cannot simply try out the feature as I may change the feature configuration in unexpected ways.

If they really do I think we should consider something like also supporting a separate file.

That will be more difficult to manage from the operator.

You'd have --features that list all features, then also additionally have a separate option for each feature?

I would vote for eventually getting rid of the list based option.

I don't think folks need to enable/disable that many features.

We're starting to add a lot of features. We're also not just talking about people trying things out locally.

Let's say I've been provided a containerized augmented image. Now I want to try out the new serdes optimization feature.

Without knowing the list of features that may already be configured in that augmented image, I cannot simply try out the feature as I may change the feature configuration in unexpected ways.

That's a good point, but would mean we'd need to handle what happens if the same feature is listed multiple times; could be --features-foo=enabled --features-foo=disabled for example

If they really do I think we should consider something like also supporting a separate file.

That will be more difficult to manage from the operator.

You'd have --features that list all features, then also additionally have a separate option for each feature?

I would vote for eventually getting rid of the list based option.

Please no, that is super convenient and quick to manage if you want to manage enabled/disabled features in one go, which at least personally is what I want

Okay, so @shawkins convinced me that we probably should do this; I do like --feature-<name>=vX|enabled|disabled, but would we also have a shorthand to enable --feature-<name> means it's enabled?

Another thing I'd like to know is how this will look like in the CLI help, and the guide docs needs updating as well.

One proposal would be that help would not list all the --feature-name options, as that would just flood it with those; similarly to help for --features and --features-disabled shows a huge block of text right now (which really has no value has it's so big and messy that I just use the guide instead).

Could we do some separate help command for features? That lists all the features, their description, etc? Something similar to what the guide does?

What do you think of expressing this as: --feature-<name>=vX|enabled|disabled.

Yep, it might be nice. The vX may work only if it's sure that we would not have to disable any specific version of a feature. Right now, you can disable only the whole feature, and not particular feature versions, so it's ok for now.

So, the approach suggested by @shawkins would look like this:

1. Enable Rolling Updates v2: --feature-rolling-updates=v2
2. Enable Transient users: --feature-transient-users=enabled
3. Disable Device flow: --feature-device-flow=disabled

And potentially, as suggested by @stianst, enable the feature like --feature-transient-users that could enable the feature based on the rules on the versions.

Is this not also going to bloat the help completely? ... Another thing I'd like to know is how this will look like in the CLI help, and the guide docs needs updating as well.

The help will be clean. There will be only one option (called wildcard option) that accepts feature names - sth like the --feature-<name>, and no existing features will be listed there. In the description, there will be a note on how to list features (see below)

Could we do some separate help command for features? That lists all the features, their description, etc? Something similar to what the guide does?

Yes, it's on our radar as well as it'd be nice to have the capability of listing features in the distribution itself with some more information + maybe even info whether the feature is enabled or not for already augmented distro. I'll create an issue for this.

I would vote for eventually getting rid of the list based option.

I think these 2 approaches can coexist as you can override the feature state by using this new option.

And potentially, as suggested by @stianst, enable the feature like --feature-transient-users that could enable the feature based on the rules on the versions.

That would need to be done separately. There are several places in our code where we make the assumption that our options must have an argument.

I think these 2 approaches can coexist as you can override the feature state by using this new option.

Ok, sounds like the concensus is to keep both and just add docs around precedence.

That's a good point, but would mean we'd need to handle what happens if the same feature is listed multiple times; could be --features-foo=enabled --features-foo=disabled for example

The cli will prevent duplicate options. Edit: that is not the case for our propertymapper backed options - this could be captured as another issue. The current behavior is the last one will win.

Another current behavior worth mentioning is that a feature cannot appear in both features and features-disabled - which has usability issue from an overriding perspective because you may need to override both lists.

Otherwise the presedence order for sources in general is:

• cli - so if you use --features, --features-disabled, or --feature-name in your start command, those will be forcing
• env
• keycloak.conf

We'd check first for the value of kc.feature-name, then fallback to the list handling. This makes features and features-disabled more akin to "default" feature handling as once you use feature-name, then features and features-disabled aren't applicible to that feature.

And potentially, as suggested by @stianst, enable the feature like --feature-transient-users that could enable the feature based on the rules on the versions.

That would need to be done separately. There are several places in our code where we make the assumption that our options must have an argument.

Exactly. I would not rush this. It is a new concept that we'd allow value-less config options.

What do you think of expressing this as: --feature-<name>=vX|enabled|disabled.

+1 It'd be on par with current --features where we allow enabling a specific version.

Created a follow-up task for the old testsuite:

• Use single property for features in the old testsuite #43645

Not sure if it's worth the effort though.

@shawkins @vmuzikar Should be ready for the review.

@shawkins Fixed help tests. Should be ready for review.

@shawkins Thanks!

@vmuzikar Do you want to do the final review? Thanks

@vmuzikar @shawkins I've updated the code to remove the capability to specify the feature profile via the option --feature-preview.