search

kubernetes-sigs / gateway-api

Repository for the next iteration of composite service (e.g. Ingress) and load balancing APIs.
https://gateway-api.sigs.k8s.io
Apache License 2.0
1.78k stars 461 forks source link

Define standard PolicyAncestor status type for Policy objects #2923

Open youngnick opened 6 months ago

youngnick commented 6 months ago

Spun out of #2813 (Specifically, https://github.com/kubernetes-sigs/gateway-api/pull/2813#discussion_r1520568442).

What would you like to be added:

We need either an update to GEP-713, GEP-2648, and GEP-2649 or to make a small GEP under this issue to properly discuss the idea of a PolicyAncestorStatus field, as in BackendTLSPolicy.

The PolicyAncestorStatus field is a status field, based on the ParentStatus in Route objects, that describes its status relative to the named ancestor object. "Ancestor" is used instead of "Parent" (as in Route) because for Policy objects, the relevant object for status is not always going to be the targetRef of the Policy.

Why this is needed: To further ease the use of the Policy Attachment API pattern.

mikemorris commented 6 months ago

For additional context, an initial implementation of this pattern was first introduced in https://github.com/kubernetes-sigs/gateway-api/pull/2448

mikemorris commented 6 months ago

Finally taking some time to dig deeper into this, and my initial thought is that at a minimum the name for this type feels incorrect (and should instead be PolicyAffectedStatus), because the current name only feels applicable to policies which are targeted at a lower-hierarchy resource which have implications on the behavior of a higher-hierarchy resource, and would not be appropriate for modelling an inverse relationship or peer relationships (such as an AuthorizationPolicy between a Pod/workload and a Service or other Pod/workload).

I understand the utility of this status reporting, but it does feel like a bit of an odd fit for a Direct Policy to communicate an impact on resources other than the policy target (even if no defaults or overrides inheritance needs to be considered). It also feels like there's tension between this approach and the suggestion for Inherited Policies in https://github.com/kubernetes-sigs/gateway-api/pull/2813 for a controller to directly modify the conditions of affected resources by setting a *PolicyAffected condition or label on the affected resource rather than centralized in the Policy status.

k8s-triage-robot commented 3 months ago

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

You can:

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

k8s-triage-robot commented 2 months ago

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

You can:

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

mikemorris commented 2 months ago

/remove-lifecycle rotten

This is probably duplicative of #738 now, but not sure how to best consolidate.

youngnick commented 1 month ago

Agreed, let's definitely keep this open to come back to in the 1.13 timeframe.