Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Remove claim adoption feature gate #3480

Open
ShellyKa13 opened this issue Oct 28, 2024 · 2 comments
Open

Remove claim adoption feature gate #3480

ShellyKa13 opened this issue Oct 28, 2024 · 2 comments
Labels
kind/enhancement

Comments

@ShellyKa13
Copy link
Contributor

Claim adoption should be the general behavior without a need for a feature gate.
We should remove it over the course of several kubevirt releases.
ShellyKa13 added a commit to ShellyKa13/containerized-data-importer that referenced this issue Oct 28, 2024
@ShellyKa13
webhooks/datavolume: comment about remove check of claim adoption
0da05aa 
There is an open issue in github to remove the claim
adoption feature gate:
kubevirt#3480
Once the FG is removed we should remove the check in the webhook
that verifies if it allowed to have an existing PVC.

Signed-off-by: Shelly Kagan <[email protected]>
@ShellyKa13 ShellyKa13 mentioned this issue Oct 28, 2024
Merged
kubevirt-bot pushed a commit that referenced this issue Oct 28, 2024
@ShellyKa13
webhooks/datavolume: comment about remove check of claim adoption (#3481
495b44a 
)

There is an open issue in github to remove the claim
adoption feature gate:
#3480
Once the FG is removed we should remove the check in the webhook
that verifies if it allowed to have an existing PVC.

Signed-off-by: Shelly Kagan <[email protected]>
universal-itengineer pushed a commit to deckhouse/3p-containerized-data-importer that referenced this issue Oct 29, 2024
@ShellyKa13 @universal-itengineer
webhooks/datavolume: comment about remove check of claim adoption (ku…
f8a64e2 
…bevirt#3481)

There is an open issue in github to remove the claim
adoption feature gate:
kubevirt#3480
Once the FG is removed we should remove the check in the webhook
that verifies if it allowed to have an existing PVC.

Signed-off-by: Shelly Kagan <[email protected]>
universal-itengineer pushed a commit to deckhouse/3p-containerized-data-importer that referenced this issue Oct 29, 2024
@ShellyKa13 @universal-itengineer
webhooks/datavolume: comment about remove check of claim adoption (ku…
8897c0b 
…bevirt#3481)

There is an open issue in github to remove the claim
adoption feature gate:
kubevirt#3480
Once the FG is removed we should remove the check in the webhook
that verifies if it allowed to have an existing PVC.

Signed-off-by: Shelly Kagan <[email protected]>
@aglitke
Copy link
Member

aglitke commented Nov 18, 2024

It seems that the next step would be to turn this FG on by default for at least one release. @EdDev wdyt? Do we have a formal policy in place for aging feature gates?

@EdDev
Copy link
Member

EdDev commented Nov 18, 2024 •
edited
Loading

We have this: https://github.com/kubevirt/community/blob/main/design-proposals/feature-lifecycle.md#release-stage-transition-table

Unlike Kubernetes, we have not recommended to enable a FG by default in Beta.
Reasoning that even if in Beta, there is still a risk of the feature to be dropped, causing backward compatibility issues with the users. By having the FG enabled by default, we leave no decision on the user side, taking on the admin behalf the risk, which seems wrong.

If there is a D/S project/deployment that uses this feature already, enabling it and exercising it in the field, I think it can give you the confident to go ahead and GA it without the need to do anything special.

Said that, you could have an exception and decide otherwise. Just make sure you give a good reason so it will not become the standard unintentionally.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
kind/enhancement
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@aglitke @EdDev @ShellyKa13