GEP-713 resurrected

[guicassolato]

What type of PR is this?
/kind gep

What this PR does / why we need it:
Resurrects GEP-713 all the way from being a Memorandum straight to Standard, while it buries its forks GEP-2648 and GEP-2649.

Which issue(s) this PR fixes:
Related to #713

Does this PR introduce a user-facing change?:

Updates and promotes GEP-713 to Standard, along with moving its previous forks GEP-2648 and GEP-2649 to becoming Memoranda.

Addresses most of the up voted suggestions discussed at https://github.com/kubernetes-sigs/gateway-api/discussions/2927, such as:
* merging Direct and Inherited back into a single spec;
* introducing the concept of **merge strategy**

Additionally to:
* targetRef supporting label selectors as an option;
* reduction of targetRef.sectionName to the base case of "it's just another (virtual) resource kind"; and
* algorithm for calculating effective meta resources (effective policies)

And general enhacements to the spec aiming to:
* acknowledge the current known support of the pattern across Gateway API implementations;
* broaden the definitions to potentially welcome known implementation of other meta resource-like concepts into the pattern (or at least acknowledge their similarities with Gateway API)

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: guicassolato
Once this PR has been reviewed and has the lgtm label, please assign mlavacca for approval. For more information see the Code Review Process.

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

Needs approval from an approver in each of these files:

• OWNERS

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

[howardjohn]

it's a bit unclear to me why we are being prescriptive on conflict resolution here? It seems like we have previously said an implementation can make it's own choices on how to merge or not merge resources - shouldn't it be allowed to have it's own mechanics for conflict too?

[howardjohn]

The whole section at L213 seems to contradict this as well (or likely I just misunderstood) - that seems to say an implementation can make it's own conflict resolution choices, and one choice is "merge" which implies we are not doing the things listed here

[guicassolato]

Implementations still get to choose.

Criteria 1 to 3 following this line establish (try to establish) the distinction between a conflict of policies at different levels of the hierarchy (e.g. xPolicy1 -> Gateway <- HTTPRoute <- xPolicy2) versus a conflict that happens at the same level (e.g. 2 xPolicy resources that target the exact same HTTPRouteRule.)

When the policies are at different levels, the merge strategy dictates how the merge will happen (or not happen). The merge strategy can be one of the "prescribed" ones or implementation-specific. To this rule, I'm adding that the higher policy controls the strategy, which I think has always been implied. E.g. if the Gateway policy says defaults (or nothing at all), then the merge strategy will be "gateway defaults", regardless of what the HTTPRoute policy says. The HTTPRoute policy may say defaults or overrides (or again nothing at all), and it will still be merged as gateway defaults, not because of what the HTTPRoute policy says, but because of what the Gateway policy does.

As for policies conflicting at the same level, I chose to stick with two of the existing criteria of resolving based on creation timestamp and then namespaced names, dropping only the 'overrides always beats defaults' one, which has been shown to be confusing to wrap our heads around (as I mentioned in the community call a couple weeks ago.)

I can try some different writing to make this clearer but from my POV I think it's significantly more permissive now in favour of the implementations than before. I guess the TLDR is: custom merge strategies for policies conflicting at different levels of the hierarchy if necessary and one less imposition for same level policies.

[howardjohn]

what does this mean? an implementation should or must have these? Or if they want similar concepts they should consider these names for consistency

[guicassolato]

This basically means I'm a coward 😜 I didn't want to push for a particular closed set of meta resource/policy status conditions, but to take a step back and collect more feedback first.

What you see here is my take on what can be done to enhance the current proposed conditions (which only has one prescribed condition really – i.e.,Accepted), and that is still generic enough IMO that all implementations could consider implementing (a bold guess of mine perhaps).

Do you have an opinion on MUST, SHOULD, MAY (...want to consider adopting similar concepts)? Or even on the list of conditions itself?

[howardjohn]

We cannot require an implementation to write an annotation to an object they don't own IMO. It may make sense in some cases but I cannot imagine users would be too happy with write access to secrets in most cases for example

[guicassolato]

Can change it to SHOULD.

[howardjohn]

can we give some examples of this? I think I understand it but not certain