kubernetes-sigs
Gateway Finalizer
What would you like to be added: A Gateway finalizer similar to the GatewayClass finalizer.
Why this is needed: The GatewayClass finalizer ensures that a GatewayClass is not deleted when Gateways are attached. A Gateway finalizer should be specified to ensure Gateways are not deleted when HTTPRoutes are attached.
What would you like to be added: A Gateway finalizer similar to the GatewayClass finalizer.
Why this is needed: The GatewayClass finalizer ensures that a GatewayClass is not deleted when Gateways are attached. A Gateway finalizer should be specified to ensure Gateways are not deleted when HTTPRoutes are attached.
Also for TLSRoute, TCPRoute, and UDPRoute?
IMO we shouldn't do this.
- Core k8s types do not (PDB and deployment for example). The one I know that does, Namespace, is a unique case.
- Generally finalizer is for the controller to cleanup. But the controller cannot delete the HTTPRoute - the user must. However, the user also cannot delete them since there is a persona split between gateway admin and app admin
- Finalizer generally provide a poor UX, IMO
Generally finalizer is for the controller to cleanup. But the controller cannot delete the HTTPRoute - the user must.
This is not the case for GatewayClassFinalizerGatewaysExist.
However, the user also cannot delete them since there is a persona split between gateway admin and app admin
The persona split is not a requirement of Gateway API, e.g. a user can be responsible for managing the infra and app routing. Even in a split persona use case, I can see value in a Gateway finalizer to avoid an infra admin user from deleting Gateways with routes that were attached by app dev users.
This is not the case for GatewayClassFinalizerGatewaysExist.
FWIW I don't think this should exist either :slightly_smiling_face:
The persona split is not a requirement of Gateway API
I don't think there is anything stopping an implementation from adding a finalizer if they want to, right? If you specifically want one (maybe you don't have persona split or don't care), you can always add one today?
After thinking about this for a bit, I agree with @howardjohn to some extent - I don't think that the relationship implied by parentRef is strong enough for it to include a finalizer.
The only action on a Gateway being removed should probably be to remove the associated status references as the Route falls out of scope. We could maybe use a small spec update to include that.
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.
This bot triages issues and PRs according to the following rules:
- After 90d of inactivity,
lifecycle/staleis applied - After 30d of inactivity since
lifecycle/stalewas applied,lifecycle/rottenis applied - After 30d of inactivity since
lifecycle/rottenwas applied, the issue is closed
You can:
- Mark this issue or PR as fresh with
/remove-lifecycle stale - Mark this issue or PR as rotten with
/lifecycle rotten - Close this issue or PR with
/close - Offer to help out with Issue Triage
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.
This bot triages issues and PRs according to the following rules:
- After 90d of inactivity,
lifecycle/staleis applied - After 30d of inactivity since
lifecycle/stalewas applied,lifecycle/rottenis applied - After 30d of inactivity since
lifecycle/rottenwas applied, the issue is closed
You can:
- Mark this issue or PR as fresh with
/remove-lifecycle rotten - Close this issue or PR with
/close - Offer to help out with Issue Triage
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle rotten
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.
This bot triages issues according to the following rules:
- After 90d of inactivity,
lifecycle/staleis applied - After 30d of inactivity since
lifecycle/stalewas applied,lifecycle/rottenis applied - After 30d of inactivity since
lifecycle/rottenwas applied, the issue is closed
You can:
- Reopen this issue with
/reopen - Mark this issue as fresh with
/remove-lifecycle rotten - Offer to help out with Issue Triage
Please send feedback to sig-contributor-experience at kubernetes/community.
/close not-planned
@k8s-triage-robot: Closing this issue, marking it as "Not Planned".
In response to this:
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.
This bot triages issues according to the following rules:
- After 90d of inactivity,
lifecycle/staleis applied- After 30d of inactivity since
lifecycle/stalewas applied,lifecycle/rottenis applied- After 30d of inactivity since
lifecycle/rottenwas applied, the issue is closedYou can:
- Reopen this issue with
/reopen- Mark this issue as fresh with
/remove-lifecycle rotten- Offer to help out with Issue Triage
Please send feedback to sig-contributor-experience at kubernetes/community.
/close not-planned
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.
