Remove alpha feature gate from projected workspaces

[0xFelix]

Changes

This removes the alpha feature gate that is currently guarding projected workspaces so they become a beta/stable feature.

Closes #5524

Submitter Checklist

As the author of this PR, please check off the items in this checklist:

• Has Docs included if any changes are user facing
• Has Tests included if any functionality added or changed
• Follows the commit message standard
• Meets the Tekton contributor standards (including
  functionality, content, code)
• Has a kind label. You can add one by adding a comment on this PR that contains /kind <type>. Valid types are bug, cleanup, design, documentation, feature, flake, misc, question, tep
• Release notes block below has been updated with any user facing changes (API changes, bug fixes, changes requiring upgrade notices or deprecation warnings)
• Release notes contains the string "action required" if the change requires additional action from users switching to the new release

Release Notes

Projected workspaces are promoted to beta/stable API

[0xFelix]

/kind feature

[tekton-robot]

Hi @0xFelix. Thanks for your PR.

I'm waiting for a tektoncd member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

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/test-infra repository.

[lbernick]

/ok-to-test
/approve

[tekton-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: lbernick

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [lbernick]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[0xFelix]

/retest

[abayer]

/retest

[abayer]

/lgtm

[afrittoli]

Changes

This removes the alpha feature gate that is currently guarding projected workspaces so they become a beta/stable feature.

What does beta/stable means? beta is not stable, we don't have a stable release yet.

This change means that the feature will implicitly be marked as stable once v1 is released.
Our current feature gate design requires features to go through alpha, then beta and then stable (once v1 is released).

I don't have any particular concern about projected volumes themselves, but I would like to make sure we follow our own processes for this - or amend the processes if we think that's what's best.

@tektoncd/core-maintainers

[0xFelix]

It means the feature is now useable in beta and stable without a feature gate.

I did not add a beta feature gate because the stable / v1 API is not release yet and the docs say a beta feature gate is not needed until then.

No concerns were raised before merging it, so I thought this is following our processes.

[afrittoli]

Maybe I'm confused because v1 is in flux since we have the code base for it but it's not yet released.

My point is that we should not release to beta and to stable at the same time.
I don't think we've really discussed how to handle these cases either though - we're having a related discussion on #5515.

[vdemeester]

@afrittoli if v1 wasn't created yet, we would have no beta value for the enable-api-fields for example (we still do not have it tbh). So we would straight up promoting to beta. One or two release later and we create / promote / publish v1. In that case, did we "promote" to both beta and stable at the same time ? When we would create that v1 (stable), would we decide to not include that feature but it was recently promoted to beta which was the latest thing available at that time ?

Stable doesn't exist, it is in the making (as we are starting to put code for v1, …) but it doesn't exist yet. This is also why, as commented on #5515, I feel the flag (and its value) is, looking back, confusing to say the least.

[afrittoli]

@afrittoli if v1 wasn't created yet, we would have no beta value for the enable-api-fields for example. So we would straight up promoting to beta. One or two release appear and we create / promote / publish v1, in that case, did we "promote" to both beta and stable at the same time ? When we would create that v1 (stable), would we decide to not include that feature but it was recently promoted to beta which was the latest thing available at that time ?

We haven't discussed a cut date for features to make it into v1 but it feels like we should have, otherwise everything we add to beta until the last second will end up in v1 right away which does not feel right to me, as we should have features in beta for sometime before promoting them to v1.

The way we have today to manage this is via the enable-api-fields flag. While we build the codebase for v1 we can add features promoted to beta under the beta feature flag. If by the time we actually release v1 any of these features have been in beta long enough, then we would remove the flag.

The alternative is to do it via API versions, i.e. freeze v1beta1 at some point and add anything new to v1beta2 only. Once we cut v1 do it from based on what's in v1beta1. Then we can start promoting from v1beta2 into v1.

Stable doesn't exist, it is in the making (as we are starting to put code for v1, …) but it doesn't exist. This is also why, as commented on #5515, I feel the flag (and its value) is, looking back, confusing to say the least.

It's in the making but the codebase is there, and anything we include there without a flag is implicitly made part of the stable to be. We decided to use the flag because we didn't want to have to manage many different API versions and we did not find a working solution for the conversion of APIs. I disagree that introducing v1 makes the flag more confusing than before; it's not ideal, but the alternative wasn't either.
If we can design a working alternative, I'd be happy to get rid of the flag.

[0xFelix]

If the goal is to stop development on the v1beta version of the API once v1 is out, why not get rid of the alpha / beta terminology and use something like feature gates for specific features instead? I think this is way more intuitive, as for example with the way it currently is implemented I can only enable none or all alpha/beta features, even if I only want to use one specific feature that is guarded.

We do that in kubevirt for example:

https://github.com/kubevirt/kubevirt/blob/main/docs/deprecation.md#feature-gates
https://github.com/kubevirt/kubevirt/blob/main/pkg/virt-config/feature-gates.go

[afrittoli]

The reason we opted for a global flag, as opposed to feature-specific ones, is that we wanted to avoid exploding the test matrix. We do have feature flags, we but only use them for features that are not API driven, since those may have an impact across the API surface.

I don't think there is any concern with regards to the feature flags, the options for API fields are:

• keep using the existing flag
• tie new features to API versions

If we decide to go for the latter, we will need to find a way to manage the conversions.