An idea, let’s simplify the feature flag that people need to use to enable feature flags. The current one is unwieldy and all of the documentation surrounding them notes that they are experimental, e.g.:
JUJU_DEV_FEATURE_FLAGS
This setting takes effect on an environment only at bootstrap time. Unstable or pre-release features are enabled only when the feature flag is enabled prior to bootstrapping the environment.
I like this - I think any particular feature can itself be labelled experimental with the relevant warnings, but to categorise the whole concept of using a feature flag as dangerous limits the ability to use it to turn on certain things like Actions UX v2, which is stable but breaks compatibility so needs to be opt in.
The reason we had DEV in the name as to indicate very clearly that they are developer feature flags.
There is a problem with the environment variable in that the flags are also copied to the controller and all the agents that it deploys, and they can’t be updated.
New style feature flags are perhaps the way to go. If we used JUJU_FEATURES as the client side feature flag, and made them the default for the controller feature flags, then I’d be prepared to say yes to this.
Yes, we do still need JUJU_DEV_FEATURE_FLAGS for all the purposes for which it is currently used.
We are just advocating for an additional more user friendly version for opt in to “stable” features that would otherwise break compatibility so can’t be activated by default until Juju 3.
I would also like to see dump-model for example added as a JUJU_FEATURE flag option. I personally don’t see why that needs to be considered a DEV thing. Or even provide that command OOTB.
Note, in the case of exposing the new Actions UX, there is no controller feature flag that needs to be set. But yes, we would make the controller feature flags default to the value of JUJU_FEATURES. This enables for example the use of “k8s-operators” without having to remember to set the controller flags each time.
Also, any new use of flags should IMO use the controller feature flags which can be toggled as needed. IMO the JUJU_DEV_FEATURE_FLAGS env var could (should?) be considered deprecated - is there still any use case where it needs to be used by an agent? If agents need access to feature flag settings, they can and should use the controller feature flags.
I agree that the current JUJU_DEV_FEATURE_FLAGS doesn’t quite do what we want, as it is hard to toggle them on and off in an active system. If we want to remap it to JUJU_FEATURES for client side and ‘juju controller-config features’ that sounds like a better place to be in.
I would avoid punning the two, because I think that is what made DEV so awkward (sometimes you want it, but you don’t really want to set it globally, because it affects bootstrap, which then cannot upgrade, etc.)
What do you mean by “punning”?
Having ‘controller-config features’ (if not otherwise set to something else) be initialised to content of JUJU_FEATURES at bootstrap time?
Given controller features can be toggled on/off, I would personally find it helpful if I were to have JUJU_FEATURES set to opt in to stable features, that that include the server side settings.
I think we need to be very careful about magic flags that make things work “correctly”. Its fine for experimentation, but as soon as it is something that you set so that you get the behavior you want, then we stop noticing that it isn’t how everything works for everyone else.
I can see your point about seeding the controller feature flags, but that also means that people aren’t aware of what they are doing behind the scenes.
This feels quite a bit like change for change’s sake, and I’m concerned whether we actually end up significantly better, vs just a bit different.
The driver here is to make it easy for people to use the new Actions UX. We can’t change it by default but we want it to be the pseudo-default experience, so need to make the opt-in as easy and seamless as possible. So the reason for doing it is not just to make a change, but with a specific purpose in mind. Anything “dev” sounds no ready or risky but that’s not the case here. And past Actions UX, it would be nice to take the same approach with the next such Juju UX improvement.
