Define standard PolicyAncestor status type for Policy objects

[youngnick]

Spun out of #2813 (Specifically, #2813 (comment)).

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]

For additional context, an initial implementation of this pattern was first introduced in #2448

[mikemorris]

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 #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]

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

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

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

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

/lifecycle stale

[k8s-triage-robot]

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:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle rotten
• Close this issue with /close
• Offer to help out with Issue Triage

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

/lifecycle rotten

[mikemorris]

/remove-lifecycle rotten

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

[youngnick]

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