GEP: Add Name to HTTPRouteRule and HTTPRouteMatch

[hzxuzhonghu]

What would you like to be added:

Add a name field to HTTPRouteRule and HTTPRouteMatch structs to allow users to identify different routes

Why this is needed:

• Policy Attachment

• Route Attachment/Delegation: Ability to have more fine grained matches for policy references IF we add sectionName to the policy object

• Improved Debugging: Ability to add debugging information, such as adding the route matched to some access log

[mehabhalodiya]

/assign @hzxuzhonghu

[k8s-triage-robot]

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/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 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

[k8s-triage-robot]

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/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 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

[shaneutt]

If I'm understanding correctly based on the closed PR, we've decided not to move forward with this at this time. If that's not the case, please feel free to drop a comment and we can re-open.

[robscott]

I think we decided this would be reasonable if we had a bigger use case associated with it. This will likely end up being included as part of route delegation in #1058.

[shaneutt]

Ok, then let's consider this closed in favor of the implementation in #1058 👍

[howardjohn]

/reopen

Route delegation is not moving forward, this is still useful

[k8s-ci-robot]

@howardjohn: Reopened this issue.

In response to this:

/reopen

Route delegation is not moving forward, this is still useful

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]

I think it makes sense in general, but will need careful writing of the spec - we can't add the new field as required, but what value should be used in contexts where it's expected (like log messages or telemetry) if it's not set?

[howardjohn]

"", "-", "unknown", nil - not sure. It may be usage specific, some systems have different ways to describe "not present" I would think, which makes it hard to prescribe against them.

[swathinsankaran]

@shaneutt @youngnick @howardjohn We would appreciate having this in the next version of the HTTPRoute. We have a similar requirement to apply some policies per rule as mentioned in the description.

cc: @apalsule

[maleck13]

Within the Kuadrant project, we also see value in adding this to support policy. Would really like to see it in the next version also

[robscott]

One of the most common arguments against this feature is that we really shouldn't be encouraging users to have large Routes. Routes with lots of rules are remarkably hard to deal with in cases like partially invalid config where many Route rules are valid, but one is not. We still have not solved this problem so the API only provides guidance for when a Route is invalid.

It seems like any request for attaching policies and other resources to a specific Route Rule name has to answer this key question: Why not just use more than one Route? Any Route that has 10 rules could also be equally represented by 10 Routes with 1 rule each, or 5 Routes with 2 rules each, or 2 Routes with 5 rules each, etc. I'm concerned that adding name to Route rules would encourage even larger Routes, which would only exacerbate other problems that we have not solved yet like partially valid Routes.

[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

[maleck13]

/remove-lifecycle stale

[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

[maleck13]

/remove-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

[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

[guicassolato]

/remove-lifecycle stale

[mikemorris]

Can this be closed now that #2985 has been released in v1.2, or is there any more to do here?

[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

[mikemorris]

/remove-lifecycle stale

Should this stay open until the feature graduates to standard, or close now?

[robscott]

Should this stay open until the feature graduates to standard, or close now?

We should leave GEP issues open until they graduate to standard, thanks!