Adding SectionName to PolicyTargetReference

[zhaohuabing]

This allows attaching policies to a specific section within the targeted object.

Related issue: #2147

What type of PR is this?
/kind feature

What this PR does / why we need it:

What this PR does:

This PR allows attaching policies to a specific section within the targeted object.

Why we need it:

Lacking SectionName in PolicyTargetReference is blocking my current work. I'm implementing a direct policy attachment and need to target a specific listener inside a gateway.

NONE

[k8s-ci-robot]

Welcome @zhaohuabing!

It looks like this is your first PR to kubernetes-sigs/gateway-api 🎉. Please refer to our pull request process documentation to help your PR have a smooth ride to approval.

You will be prompted by a bot to use commands during the review process. Do not be afraid to follow the prompts! It is okay to experiment. Here is the bot commands documentation.

You can also check if kubernetes-sigs/gateway-api has its own contribution guidelines.

You may want to refer to our testing guide if you run into trouble with your tests not passing.

If you are having difficulty getting your pull request seen, please follow the recommended escalation practices. Also, for tips and tricks in the contribution process you may want to read the Kubernetes contributor cheat sheet. We want to make sure your contribution gets all the attention it needs!

Thank you, and welcome to Kubernetes. 😃

[k8s-ci-robot]

Hi @zhaohuabing. Thanks for your PR.

I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

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.

[robscott]

Hey @zhaohuabing, thanks for working on this! If I'm understanding correctly, it looks like you're trying to take on a couple of separate issues:

1. Adding SectionName to PolicyTargetReference (Update TargetREf in Policy GEP #2147)
2. Adding Name to Route Rules (GEP: Add Name to HTTPRouteRule and HTTPRouteMatch #995)

I think we mostly have consensus on 1, but we're waiting for #2128 to merge before moving forward. On 2, I don't think we quite have enough consensus to move forward yet. Maybe once #2128 merges you can check in with @arkodg to see if he needs any help with the implementation of #2147.

It may also be helpful to take a look at our documentation for the GEP process. All API changes have to go through that process so we can't start directly with a PR to change the API itself without first having an approved GEP in an "implementable" state.

[zhaohuabing]

@robscott Thanks for the guidelines! What I really need is to have a SectionName field in the PolicyTargetReference API. Right now, its absence is causing a bit of a roadblock for me as I'm trying to set up a direct policy attachment and want to target a specific listener within a gateway.

Since the community have already reached agreement on 1, could we consider adding this field as a first step? This matter is quite time-sensitive for me, and I'm a bit worried that it will take a while to get #2128 merged. Moreover, PR 2128 is mainly about the discoverability and isn't related to the SectionName field at all, so it shouldn't block adding this field.

For the GEP process, since GEP-713 already mentions SectionName in the Apply Policies to Sections of a Resource (Future Extension) section, is it ok that I modify this part to reflect this change if the above approach is acceptable?

[arkodg]

hey @zhaohuabing can you also edit

gateway-api/geps/gep-713.md

Line 685 in 4651e91

### Apply Policies to Sections of a Resource (Future Extension)

to now account for SectionName . Imo, since this PR is in draft mode, it shouldn't distract others from reviewing the Policy Discoverability PR first

[youngnick]

Yes, we use "most specific wins" in other places, so I am very much in favor.

@zhaohuabing, sorry, but you'll need to include some information in the SectionName part of GEP-713 about this behavior. Something like:

When multiple Policies of the same type target the same object, one with a SectionName specified, and one without, the one with a SectionName is more specific, and so will have all its settings apply. The less-specifc Policy will not attach to the target.

I'll also take a note to add or extend conflict-resolution rules for direct policy attachment further up, with the "more specific wins" rule. (I have more updates to do to GEP-713 already, this will add to the pile).

[youngnick]

Thanks for that last change @zhaohuabing, this LGTM.

/lgtm

[youngnick]

Ping @robscott for one more check, then we can remove the hold.

[zhaohuabing]

/retest-required

[k8s-ci-robot]

@zhaohuabing: Cannot trigger testing until a trusted user reviews the PR and leaves an /ok-to-test message.

In response to this:

/retest-required

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.

[youngnick]

/ok-to-test

[youngnick]

@zhaohuabing, you'll need to rerun make generate and commit the result for CI to pass.

[robscott]

Thanks for all the work on this @zhaohuabing! As much as I'm hesitant to add additional complexity here, this does feel inevitable. Have a few nits, but this looks good overall. In general just trying to at least make sure we have some guidance in here that ensures this is only used when it's actually necessary.

Would also appreciate some feedback from @kflynn on this because they've raised some important concerns about the complexity of our existing policy attachment model, so want to be careful when adding more.

[robscott]

Thanks @zhaohuabing!

/lgtm
/hold cancel