robscott

robscott

Member Since 11 years ago

@Google, Sunnyvale, CA

Experience Points
74
follower
Lessons Completed
16
follow
Lessons Completed
287
stars
Best Reply Awards
38
repos

445 contributions in the last year

Pinned
⚡ Repository for the next iteration of composite service (e.g. Ingress) and load balancing APIs.
⚡ Production-Grade Container Scheduling and Management
⚡ A simple CLI that provides an overview of the resource requests, limits, and utilization in a Kubernetes cluster
⚡ Validation of best practices in your Kubernetes clusters
⚡ A Kubernetes operator that simplifies the management of Role Bindings and Service Accounts.
⚡ Easily find roles and cluster roles attached to any user, service account, or group name in your Kubernetes cluster
Activity
May
23
11 hours ago
Activity icon
issue

robscott issue comment kubernetes/enhancements

robscott
robscott

Topology Aware Hints

Enhancement Description

/sig network

robscott
robscott

/remove-lifecycle stale /lifecycle frozen

May
19
4 days ago
open pull request

robscott wants to merge kubernetes-sigs/gateway-api

robscott
robscott

[WIP] Add HTTP Rewrite and Redirect Filter guide

What type of PR is this? /kind documentation

What this PR does / why we need it: Adds a guide for GEP-726 features, including the changes currently under review in #1124

It is a WIP for two reasons:

  • For HTTP->HTTPS redirects, are implementations expected to not redirect requests that are already HTTPS, or does the spec allow misconfigurations that result in redirect loops? If so, how should users properly set up their HTTPRoutes and Gateway Listener configuration to only match these redirect rules on HTTP requests? I expect this generalizes to path/hostname/etc. also, but this was the most prominent case I could think of.
  • Do we care about path types for path modifiers? It seems that you can use prefix modifiers for exact paths, though it's probably pointless (if harmless), and I'm not sure whether RegularExpression paths would be considered prefixes here (i.e. ReplacePrefixMatch changes only the path segment matching the regex).
  • I added the text suggested in #928 mostly as-is, but it raises the question "what status must we set?". It seems like we need a new RouteConditionType for filter-related statuses if we want this, or a new RouteConditionReason (it doesn't seem like it'd fit under any of the existing types unless we reject routes with invalid filters entirely, and I wouldn't expect to since they're per-rule and since the text indicates this should just be a warning, not an error).

As a side note, I have bad timing and will be out from 5/18-5/28, so it may make sense to use this as a starting point for someone else if review takes time or it needs significant changes. Edit: then I forgot this is the week that a bunch of people are at Kubecon :slightly_smiling_face: I should actually be able to check things on the 26th even though I'm still technically out.

Which issue(s) this PR fixes: Fixes #1038 Fixes #928

Does this PR introduce a user-facing change?:

NONE
robscott
robscott

This should be included from a separate yaml file so we can ensure that it stays valid. You can see some of the other guides for examples, but in general, the inclusion should look like this:

{% include 'v1alpha2/http-routing/gateway.yaml' %}
open pull request

robscott wants to merge kubernetes-sigs/gateway-api

robscott
robscott

[WIP] Add HTTP Rewrite and Redirect Filter guide

What type of PR is this? /kind documentation

What this PR does / why we need it: Adds a guide for GEP-726 features, including the changes currently under review in #1124

It is a WIP for two reasons:

  • For HTTP->HTTPS redirects, are implementations expected to not redirect requests that are already HTTPS, or does the spec allow misconfigurations that result in redirect loops? If so, how should users properly set up their HTTPRoutes and Gateway Listener configuration to only match these redirect rules on HTTP requests? I expect this generalizes to path/hostname/etc. also, but this was the most prominent case I could think of.
  • Do we care about path types for path modifiers? It seems that you can use prefix modifiers for exact paths, though it's probably pointless (if harmless), and I'm not sure whether RegularExpression paths would be considered prefixes here (i.e. ReplacePrefixMatch changes only the path segment matching the regex).
  • I added the text suggested in #928 mostly as-is, but it raises the question "what status must we set?". It seems like we need a new RouteConditionType for filter-related statuses if we want this, or a new RouteConditionReason (it doesn't seem like it'd fit under any of the existing types unless we reject routes with invalid filters entirely, and I wouldn't expect to since they're per-rule and since the text indicates this should just be a warning, not an error).

As a side note, I have bad timing and will be out from 5/18-5/28, so it may make sense to use this as a starting point for someone else if review takes time or it needs significant changes. Edit: then I forgot this is the week that a bunch of people are at Kubecon :slightly_smiling_face: I should actually be able to check things on the 26th even though I'm still technically out.

Which issue(s) this PR fixes: Fixes #1038 Fixes #928

Does this PR introduce a user-facing change?:

NONE
robscott
robscott

Same comment as above - move to separate file.

open pull request

robscott wants to merge kubernetes-sigs/gateway-api

robscott
robscott

[WIP] Add HTTP Rewrite and Redirect Filter guide

What type of PR is this? /kind documentation

What this PR does / why we need it: Adds a guide for GEP-726 features, including the changes currently under review in #1124

It is a WIP for two reasons:

  • For HTTP->HTTPS redirects, are implementations expected to not redirect requests that are already HTTPS, or does the spec allow misconfigurations that result in redirect loops? If so, how should users properly set up their HTTPRoutes and Gateway Listener configuration to only match these redirect rules on HTTP requests? I expect this generalizes to path/hostname/etc. also, but this was the most prominent case I could think of.
  • Do we care about path types for path modifiers? It seems that you can use prefix modifiers for exact paths, though it's probably pointless (if harmless), and I'm not sure whether RegularExpression paths would be considered prefixes here (i.e. ReplacePrefixMatch changes only the path segment matching the regex).
  • I added the text suggested in #928 mostly as-is, but it raises the question "what status must we set?". It seems like we need a new RouteConditionType for filter-related statuses if we want this, or a new RouteConditionReason (it doesn't seem like it'd fit under any of the existing types unless we reject routes with invalid filters entirely, and I wouldn't expect to since they're per-rule and since the text indicates this should just be a warning, not an error).

As a side note, I have bad timing and will be out from 5/18-5/28, so it may make sense to use this as a starting point for someone else if review takes time or it needs significant changes. Edit: then I forgot this is the week that a bunch of people are at Kubecon :slightly_smiling_face: I should actually be able to check things on the 26th even though I'm still technically out.

Which issue(s) this PR fixes: Fixes #1038 Fixes #928

Does this PR introduce a user-facing change?:

NONE
robscott
robscott

Same comment as above about needing a separate file.

open pull request

robscott wants to merge kubernetes-sigs/gateway-api

robscott
robscott

[WIP] Add HTTP Rewrite and Redirect Filter guide

What type of PR is this? /kind documentation

What this PR does / why we need it: Adds a guide for GEP-726 features, including the changes currently under review in #1124

It is a WIP for two reasons:

  • For HTTP->HTTPS redirects, are implementations expected to not redirect requests that are already HTTPS, or does the spec allow misconfigurations that result in redirect loops? If so, how should users properly set up their HTTPRoutes and Gateway Listener configuration to only match these redirect rules on HTTP requests? I expect this generalizes to path/hostname/etc. also, but this was the most prominent case I could think of.
  • Do we care about path types for path modifiers? It seems that you can use prefix modifiers for exact paths, though it's probably pointless (if harmless), and I'm not sure whether RegularExpression paths would be considered prefixes here (i.e. ReplacePrefixMatch changes only the path segment matching the regex).
  • I added the text suggested in #928 mostly as-is, but it raises the question "what status must we set?". It seems like we need a new RouteConditionType for filter-related statuses if we want this, or a new RouteConditionReason (it doesn't seem like it'd fit under any of the existing types unless we reject routes with invalid filters entirely, and I wouldn't expect to since they're per-rule and since the text indicates this should just be a warning, not an error).

As a side note, I have bad timing and will be out from 5/18-5/28, so it may make sense to use this as a starting point for someone else if review takes time or it needs significant changes. Edit: then I forgot this is the week that a bunch of people are at Kubecon :slightly_smiling_face: I should actually be able to check things on the 26th even though I'm still technically out.

Which issue(s) this PR fixes: Fixes #1038 Fixes #928

Does this PR introduce a user-facing change?:

NONE
robscott
robscott
open pull request

robscott wants to merge kubernetes-sigs/gateway-api

robscott
robscott

[WIP] Add HTTP Rewrite and Redirect Filter guide

What type of PR is this? /kind documentation

What this PR does / why we need it: Adds a guide for GEP-726 features, including the changes currently under review in #1124

It is a WIP for two reasons:

  • For HTTP->HTTPS redirects, are implementations expected to not redirect requests that are already HTTPS, or does the spec allow misconfigurations that result in redirect loops? If so, how should users properly set up their HTTPRoutes and Gateway Listener configuration to only match these redirect rules on HTTP requests? I expect this generalizes to path/hostname/etc. also, but this was the most prominent case I could think of.
  • Do we care about path types for path modifiers? It seems that you can use prefix modifiers for exact paths, though it's probably pointless (if harmless), and I'm not sure whether RegularExpression paths would be considered prefixes here (i.e. ReplacePrefixMatch changes only the path segment matching the regex).
  • I added the text suggested in #928 mostly as-is, but it raises the question "what status must we set?". It seems like we need a new RouteConditionType for filter-related statuses if we want this, or a new RouteConditionReason (it doesn't seem like it'd fit under any of the existing types unless we reject routes with invalid filters entirely, and I wouldn't expect to since they're per-rule and since the text indicates this should just be a warning, not an error).

As a side note, I have bad timing and will be out from 5/18-5/28, so it may make sense to use this as a starting point for someone else if review takes time or it needs significant changes. Edit: then I forgot this is the week that a bunch of people are at Kubecon :slightly_smiling_face: I should actually be able to check things on the 26th even though I'm still technically out.

Which issue(s) this PR fixes: Fixes #1038 Fixes #928

Does this PR introduce a user-facing change?:

NONE
robscott
robscott

Indentation looks off here, maybe a combination of tabs and spaces going on here?

open pull request

robscott wants to merge kubernetes-sigs/gateway-api

robscott
robscott

[WIP] Add HTTP Rewrite and Redirect Filter guide

What type of PR is this? /kind documentation

What this PR does / why we need it: Adds a guide for GEP-726 features, including the changes currently under review in #1124

It is a WIP for two reasons:

  • For HTTP->HTTPS redirects, are implementations expected to not redirect requests that are already HTTPS, or does the spec allow misconfigurations that result in redirect loops? If so, how should users properly set up their HTTPRoutes and Gateway Listener configuration to only match these redirect rules on HTTP requests? I expect this generalizes to path/hostname/etc. also, but this was the most prominent case I could think of.
  • Do we care about path types for path modifiers? It seems that you can use prefix modifiers for exact paths, though it's probably pointless (if harmless), and I'm not sure whether RegularExpression paths would be considered prefixes here (i.e. ReplacePrefixMatch changes only the path segment matching the regex).
  • I added the text suggested in #928 mostly as-is, but it raises the question "what status must we set?". It seems like we need a new RouteConditionType for filter-related statuses if we want this, or a new RouteConditionReason (it doesn't seem like it'd fit under any of the existing types unless we reject routes with invalid filters entirely, and I wouldn't expect to since they're per-rule and since the text indicates this should just be a warning, not an error).

As a side note, I have bad timing and will be out from 5/18-5/28, so it may make sense to use this as a starting point for someone else if review takes time or it needs significant changes. Edit: then I forgot this is the week that a bunch of people are at Kubecon :slightly_smiling_face: I should actually be able to check things on the 26th even though I'm still technically out.

Which issue(s) this PR fixes: Fixes #1038 Fixes #928

Does this PR introduce a user-facing change?:

NONE
robscott
robscott

I think we do need to provide some kind of guidance here. Ideally we would make it very difficult to write config that would result in a redirect loop. I'm not sure how broadly implementable this is, but could we interpret this as a "redirect if not already at this destination/scheme/etc"?

open pull request

robscott wants to merge kubernetes-sigs/gateway-api

robscott
robscott

[WIP] Add HTTP Rewrite and Redirect Filter guide

What type of PR is this? /kind documentation

What this PR does / why we need it: Adds a guide for GEP-726 features, including the changes currently under review in #1124

It is a WIP for two reasons:

  • For HTTP->HTTPS redirects, are implementations expected to not redirect requests that are already HTTPS, or does the spec allow misconfigurations that result in redirect loops? If so, how should users properly set up their HTTPRoutes and Gateway Listener configuration to only match these redirect rules on HTTP requests? I expect this generalizes to path/hostname/etc. also, but this was the most prominent case I could think of.
  • Do we care about path types for path modifiers? It seems that you can use prefix modifiers for exact paths, though it's probably pointless (if harmless), and I'm not sure whether RegularExpression paths would be considered prefixes here (i.e. ReplacePrefixMatch changes only the path segment matching the regex).
  • I added the text suggested in #928 mostly as-is, but it raises the question "what status must we set?". It seems like we need a new RouteConditionType for filter-related statuses if we want this, or a new RouteConditionReason (it doesn't seem like it'd fit under any of the existing types unless we reject routes with invalid filters entirely, and I wouldn't expect to since they're per-rule and since the text indicates this should just be a warning, not an error).

As a side note, I have bad timing and will be out from 5/18-5/28, so it may make sense to use this as a starting point for someone else if review takes time or it needs significant changes. Edit: then I forgot this is the week that a bunch of people are at Kubecon :slightly_smiling_face: I should actually be able to check things on the 26th even though I'm still technically out.

Which issue(s) this PR fixes: Fixes #1038 Fixes #928

Does this PR introduce a user-facing change?:

NONE
open pull request

robscott wants to merge kubernetes-sigs/gateway-api

robscott
robscott

[WIP] Add HTTP Rewrite and Redirect Filter guide

What type of PR is this? /kind documentation

What this PR does / why we need it: Adds a guide for GEP-726 features, including the changes currently under review in #1124

It is a WIP for two reasons:

  • For HTTP->HTTPS redirects, are implementations expected to not redirect requests that are already HTTPS, or does the spec allow misconfigurations that result in redirect loops? If so, how should users properly set up their HTTPRoutes and Gateway Listener configuration to only match these redirect rules on HTTP requests? I expect this generalizes to path/hostname/etc. also, but this was the most prominent case I could think of.
  • Do we care about path types for path modifiers? It seems that you can use prefix modifiers for exact paths, though it's probably pointless (if harmless), and I'm not sure whether RegularExpression paths would be considered prefixes here (i.e. ReplacePrefixMatch changes only the path segment matching the regex).
  • I added the text suggested in #928 mostly as-is, but it raises the question "what status must we set?". It seems like we need a new RouteConditionType for filter-related statuses if we want this, or a new RouteConditionReason (it doesn't seem like it'd fit under any of the existing types unless we reject routes with invalid filters entirely, and I wouldn't expect to since they're per-rule and since the text indicates this should just be a warning, not an error).

As a side note, I have bad timing and will be out from 5/18-5/28, so it may make sense to use this as a starting point for someone else if review takes time or it needs significant changes. Edit: then I forgot this is the week that a bunch of people are at Kubecon :slightly_smiling_face: I should actually be able to check things on the 26th even though I'm still technically out.

Which issue(s) this PR fixes: Fixes #1038 Fixes #928

Does this PR introduce a user-facing change?:

NONE
robscott
robscott

I think this might read better if you merged the content from before and after the example, something like this:

can change the upstream request hostname and/or path. For example, the following HTTPRoute will accept...

Same comment applies elsewhere.

open pull request

robscott wants to merge kubernetes-sigs/gateway-api

robscott
robscott

[WIP] Add HTTP Rewrite and Redirect Filter guide

What type of PR is this? /kind documentation

What this PR does / why we need it: Adds a guide for GEP-726 features, including the changes currently under review in #1124

It is a WIP for two reasons:

  • For HTTP->HTTPS redirects, are implementations expected to not redirect requests that are already HTTPS, or does the spec allow misconfigurations that result in redirect loops? If so, how should users properly set up their HTTPRoutes and Gateway Listener configuration to only match these redirect rules on HTTP requests? I expect this generalizes to path/hostname/etc. also, but this was the most prominent case I could think of.
  • Do we care about path types for path modifiers? It seems that you can use prefix modifiers for exact paths, though it's probably pointless (if harmless), and I'm not sure whether RegularExpression paths would be considered prefixes here (i.e. ReplacePrefixMatch changes only the path segment matching the regex).
  • I added the text suggested in #928 mostly as-is, but it raises the question "what status must we set?". It seems like we need a new RouteConditionType for filter-related statuses if we want this, or a new RouteConditionReason (it doesn't seem like it'd fit under any of the existing types unless we reject routes with invalid filters entirely, and I wouldn't expect to since they're per-rule and since the text indicates this should just be a warning, not an error).

As a side note, I have bad timing and will be out from 5/18-5/28, so it may make sense to use this as a starting point for someone else if review takes time or it needs significant changes. Edit: then I forgot this is the week that a bunch of people are at Kubecon :slightly_smiling_face: I should actually be able to check things on the 26th even though I'm still technically out.

Which issue(s) this PR fixes: Fixes #1038 Fixes #928

Does this PR introduce a user-facing change?:

NONE
pull request

robscott merge to kubernetes-sigs/gateway-api

robscott
robscott

[WIP] Add HTTP Rewrite and Redirect Filter guide

What type of PR is this? /kind documentation

What this PR does / why we need it: Adds a guide for GEP-726 features, including the changes currently under review in #1124

It is a WIP for two reasons:

  • For HTTP->HTTPS redirects, are implementations expected to not redirect requests that are already HTTPS, or does the spec allow misconfigurations that result in redirect loops? If so, how should users properly set up their HTTPRoutes and Gateway Listener configuration to only match these redirect rules on HTTP requests? I expect this generalizes to path/hostname/etc. also, but this was the most prominent case I could think of.
  • Do we care about path types for path modifiers? It seems that you can use prefix modifiers for exact paths, though it's probably pointless (if harmless), and I'm not sure whether RegularExpression paths would be considered prefixes here (i.e. ReplacePrefixMatch changes only the path segment matching the regex).
  • I added the text suggested in #928 mostly as-is, but it raises the question "what status must we set?". It seems like we need a new RouteConditionType for filter-related statuses if we want this, or a new RouteConditionReason (it doesn't seem like it'd fit under any of the existing types unless we reject routes with invalid filters entirely, and I wouldn't expect to since they're per-rule and since the text indicates this should just be a warning, not an error).

As a side note, I have bad timing and will be out from 5/18-5/28, so it may make sense to use this as a starting point for someone else if review takes time or it needs significant changes. Edit: then I forgot this is the week that a bunch of people are at Kubecon :slightly_smiling_face: I should actually be able to check things on the 26th even though I'm still technically out.

Which issue(s) this PR fixes: Fixes #1038 Fixes #928

Does this PR introduce a user-facing change?:

NONE
robscott
robscott

Thanks @rainest, this is really great!

pull request

robscott merge to kubernetes-sigs/gateway-api

robscott
robscott

[WIP] Add HTTP Rewrite and Redirect Filter guide

What type of PR is this? /kind documentation

What this PR does / why we need it: Adds a guide for GEP-726 features, including the changes currently under review in #1124

It is a WIP for two reasons:

  • For HTTP->HTTPS redirects, are implementations expected to not redirect requests that are already HTTPS, or does the spec allow misconfigurations that result in redirect loops? If so, how should users properly set up their HTTPRoutes and Gateway Listener configuration to only match these redirect rules on HTTP requests? I expect this generalizes to path/hostname/etc. also, but this was the most prominent case I could think of.
  • Do we care about path types for path modifiers? It seems that you can use prefix modifiers for exact paths, though it's probably pointless (if harmless), and I'm not sure whether RegularExpression paths would be considered prefixes here (i.e. ReplacePrefixMatch changes only the path segment matching the regex).
  • I added the text suggested in #928 mostly as-is, but it raises the question "what status must we set?". It seems like we need a new RouteConditionType for filter-related statuses if we want this, or a new RouteConditionReason (it doesn't seem like it'd fit under any of the existing types unless we reject routes with invalid filters entirely, and I wouldn't expect to since they're per-rule and since the text indicates this should just be a warning, not an error).

As a side note, I have bad timing and will be out from 5/18-5/28, so it may make sense to use this as a starting point for someone else if review takes time or it needs significant changes. Edit: then I forgot this is the week that a bunch of people are at Kubecon :slightly_smiling_face: I should actually be able to check things on the 26th even though I'm still technically out.

Which issue(s) this PR fixes: Fixes #1038 Fixes #928

Does this PR introduce a user-facing change?:

NONE
robscott
robscott

Thanks @rainest, this is really great!

Activity icon
issue

robscott issue comment kubernetes-sigs/gateway-api

robscott
robscott

Wildcard hostname matching behavior is not clearly specified

What would you like to be added: As @howardjohn noted in Slack, our hostname matching behavior is not clearly specified. Other than saying "exact matches must be processed before wildcard matches", we don't really cover how wildcard matches should be implemented. Specifically, which of the following should *.example.com match?

  1. a.example.com
  2. a.b.example.com

We recently added a conformance test that stated that only 1 should match. On further thought, I'm not sure that's what we want.

Here's my understanding of the default behavior for a variety of different products:

  1. nginx defaults to match 1 and 2 ref
  2. envoy defaults to match 1 and 2 ref
  3. haproxy can definitely support suffix matching (hdr_end), I'm not sure about the other ref
  4. GCP can only support suffix matching (not well documented yet)

Given the above, it seems that most underlying implementations treat wildcard host matching as suffix matching as the default, and some may only be able to support that approach. My suggestion would be to adjust the spec and conformance tests to reflect that.

Why this is needed: This is an important gap in our spec today.

robscott
robscott

I agree that this was at one point specified in the API, and I'm not actually sure how it ended up being removed from the spec - I think it must have been part of a larger restructuring or rewording. With that said, my strong bias here is to use the most broadly supportable interpretation of this, which is essentially a suffix match.

From what I can tell, both GCP and Azure are only able to interpret a wildcard match as a suffix match. That also matches the default behavior of nginx and envoy. Although this would differ from the Ingress spec, I think it would be more in line with how wildcard matches are interpreted across different providers.

Because this is a critical decision, I'm going to add it to the v0.5.0 milestone. I think there are two possible actions that could be sufficient to unblock the v0.5.0 for this:

  1. Remove the conformance tests that require single label matching as an interpretation of wildcard matching.
  2. Add guidance to the spec on how wildcard matching should be implemented.

I would prefer 2, but if we can't easily reach consensus on this, I think 1 may be sufficient.

Activity icon
issue

robscott issue comment kubernetes-sigs/gateway-api

robscott
robscott

test: fix skip format

/kind cleanup

Does this PR introduce a user-facing change?:

NONE
robscott
robscott

I think this was fixed by #1167. Feel free to reopen if not.

/close

pull request

robscott pull request kubernetes-sigs/gateway-api

robscott
robscott

Bumping golangci-lint, making related fixes

What type of PR is this? /kind bug /kind failing-test

What this PR does / why we need it: This fixes golangci-lint and the related presubmit.

Does this PR introduce a user-facing change?:

NONE
Activity icon
created branch

robscott in robscott/gateway-api create branch dep-update

createdAt 4 days ago
May
18
5 days ago
Activity icon
issue

robscott issue comment kubernetes-sigs/gateway-api

robscott
robscott

Add webhook validation to ensure that ReplacePathPrefix in rewrites has corresponding prefix match

When a URLRewrite filter is specified on a Route rule and it includes ReplacePathPrefix configuration, we should verify that exactly one path prefix match is specified on the same Route rule. We should also verify that no other path matches are specified as part of this.

robscott
robscott

This work should probably be based on https://github.com/kubernetes-sigs/gateway-api/pull/1124, or just wait for that PR to merge.

Activity icon
issue

robscott issue kubernetes-sigs/gateway-api

robscott
robscott

Add webhook validation to ensure that ReplacePathPrefix in rewrites has corresponding prefix match

When a URLRewrite filter is specified on a Route rule and it includes ReplacePathPrefix configuration, we should verify that exactly one path prefix match is specified on the same Route rule. We should also verify that no other path matches are specified as part of this.

Activity icon
issue

robscott issue comment kubernetes-sigs/gateway-api

robscott
robscott

Confusing of HTTPPathModifier

https://github.com/kubernetes-sigs/gateway-api/blob/c7da26bec21093f2eec792dd49386c344982ea9e/apis/v1alpha2/httproute_types.go#L719-L733

How could i rewrite url like /foo/bar prefixed with foo to /bar , it does not allow setting match value

robscott
robscott

Good question. That would be an invalid configuration. We should probably add some webhook validation to prevent that from happening.

Activity icon
issue

robscott issue comment kubernetes-sigs/gateway-api

robscott
robscott

Confusing of HTTPPathModifier

https://github.com/kubernetes-sigs/gateway-api/blob/c7da26bec21093f2eec792dd49386c344982ea9e/apis/v1alpha2/httproute_types.go#L719-L733

How could i rewrite url like /foo/bar prefixed with foo to /bar , it does not allow setting match value

robscott
robscott

Thanks for the question @hzxuzhonghu! I think #1124 and #1162 will help make this a bit clearer. The value that is being replaced is from the path match. So if you want to use a prefix match to rewrite requests starting with /foo/bar to /bar, you could use config like this:

apiVersion: gateway.networking.k8s.io/v1alpha2
kind: HTTPRoute
metadata:
  name: http-filter-rewrite
spec:
  rules:
    - matches:
      - path:
          type: PathPrefix
          value: /foo/bar
      filters:
      - type: URLRewrite
         urlRewrite:
           path:
             type: ReplacePathPrefix
             replacePathPrefix: /bar
      backendRefs:
      - name: example-svc
        weight: 1
        port: 80
May
17
6 days ago
Activity icon
issue

robscott issue comment kubernetes-sigs/gateway-api

robscott
robscott

[WIP] Add HTTP Rewrite and Redirect Filter guide

What type of PR is this? /kind documentation

What this PR does / why we need it: Adds a guide for GEP-726 features, including the changes currently under review in #1124

It is a WIP for two reasons:

  • For HTTP->HTTPS redirects, are implementations expected to not redirect requests that are already HTTPS, or does the spec allow misconfigurations that result in redirect loops? If so, how should users properly set up their HTTPRoutes and Gateway Listener configuration to only match these redirect rules on HTTP requests? I expect this generalizes to path/hostname/etc. also, but this was the most prominent case I could think of.
  • Do we care about path types for path modifiers? It seems that you can use prefix modifiers for exact paths, though it's probably pointless (if harmless), and I'm not sure whether RegularExpression paths would be considered prefixes here (i.e. ReplacePrefixMatch changes only the path segment matching the regex).
  • I added the text suggested in #928 mostly as-is, but it raises the question "what status must we set?". It seems like we need a new RouteConditionType for filter-related statuses if we want this, or a new RouteConditionReason (it doesn't seem like it'd fit under any of the existing types unless we reject routes with invalid filters entirely, and I wouldn't expect to since they're per-rule and since the text indicates this should just be a warning, not an error).

As a side note, I have bad timing and will be out from 5/18-5/28, so it may make sense to use this as a starting point for someone else if review takes time or it needs significant changes.

Which issue(s) this PR fixes: Fixes #1038 Fixes #928

Does this PR introduce a user-facing change?:

NONE
open pull request

robscott wants to merge kubernetes-sigs/gateway-api

robscott
robscott

conformance: add hostname intersection test

What type of PR is this? /area conformance

What this PR does / why we need it: Adds a conformance test that validates hostname intersection between HTTPRoutes and Listeners.

Also updates the "WaitsForConsistency" helper to retry immediately after a successful request, to speed up test execution.

Which issue(s) this PR fixes: Updates #1104

Does this PR introduce a user-facing change?:

NONE
pull request

robscott merge to kubernetes-sigs/gateway-api

robscott
robscott

conformance: add hostname intersection test

What type of PR is this? /area conformance

What this PR does / why we need it: Adds a conformance test that validates hostname intersection between HTTPRoutes and Listeners.

Also updates the "WaitsForConsistency" helper to retry immediately after a successful request, to speed up test execution.

Which issue(s) this PR fixes: Updates #1104

Does this PR introduce a user-facing change?:

NONE
robscott
robscott

Thanks @rainest! This mostly looks good to me. I'd like to reach some kind of consensus on #1159 before adding more tests related to it, hopefully we can cover that in our next community meeting.

pull request

robscott merge to kubernetes-sigs/gateway-api

robscott
robscott

conformance: add hostname intersection test

What type of PR is this? /area conformance

What this PR does / why we need it: Adds a conformance test that validates hostname intersection between HTTPRoutes and Listeners.

Also updates the "WaitsForConsistency" helper to retry immediately after a successful request, to speed up test execution.

Which issue(s) this PR fixes: Updates #1104

Does this PR introduce a user-facing change?:

NONE
robscott
robscott

Thanks @rainest! This mostly looks good to me. I'd like to reach some kind of consensus on #1159 before adding more tests related to it, hopefully we can cover that in our next community meeting.

open pull request

robscott wants to merge kubernetes-sigs/gateway-api

robscott
robscott

conformance: add hostname intersection test

What type of PR is this? /area conformance

What this PR does / why we need it: Adds a conformance test that validates hostname intersection between HTTPRoutes and Listeners.

Also updates the "WaitsForConsistency" helper to retry immediately after a successful request, to speed up test execution.

Which issue(s) this PR fixes: Updates #1104

Does this PR introduce a user-facing change?:

NONE
started
started time in 5 days ago
Activity icon
issue

robscott issue comment kubernetes-sigs/gateway-api

robscott
robscott

test: fix skip format

/kind cleanup

Does this PR introduce a user-facing change?:

NONE
robscott
robscott

Thanks!

/ok-to-test /lgtm /approve

May
13
1 week ago
Activity icon
issue

robscott issue comment robscott/kube-capacity

robscott
robscott

incorrect data

in some cases, memory values for a node will not include the 'Mi' suffix:

10.145.197.168   42125m (75%)     148700m (265%)     221838Mi (82%)          416923Mi (154%)
10.145.197.169   45325m (80%)     121200m (216%)     62346Mi (23%)           180263Mi (66%)
10.145.197.170   14425m (25%)     37700m (67%)       45346Mi (16%)           100345Mi (37%)
162.150.14.214   13790m (24%)     45700m (81%)       39411368960000m (29%)   106336625408000m (78%)
162.150.14.215   13790m (24%)     39700m (70%)       38874498048000m (28%)   90767368960000m (67%)
162.150.14.216   16790m (29%)     42700m (76%)       46390690816000m (34%)   98283561728000m (72%)
162.150.14.217   12490m (22%)     39200m (70%)       38606062592000m (28%)   91841110784000m (68%)

In these cases, the report is wrong. need to change the logic here: https://github.com/robscott/kube-capacity/blob/master/pkg/capacity/resources.go#L356

for example, use more specific requestString and limitString so the code does not fall on the wrong unit: Example: add requestStringM() and limitStringM() that only converts Memory units to avoid the problem::

func (tp *tablePrinter) printClusterLine() {
	tp.printLine(&tableLine{
		node:           "*",
		namespace:      "*",
		pod:            "*",
		container:      "*",
		cpuRequests:    tp.cm.cpu.requestString(tp.availableFormat),
		cpuLimits:      tp.cm.cpu.limitString(tp.availableFormat),
		cpuUtil:        tp.cm.cpu.utilString(tp.availableFormat),
		memoryRequests: tp.cm.memory.requestStringM(tp.availableFormat),
		memoryLimits:   tp.cm.memory.limitStringM(tp.availableFormat),
		memoryUtil:     tp.cm.memory.utilString(tp.availableFormat),
		podCount:       tp.cm.podCount.podCountString(),
	})
}

func (tp *tablePrinter) printNodeLine(nodeName string, nm *nodeMetric) {
	tp.printLine(&tableLine{
		node:           nodeName,
		namespace:      "*",
		pod:            "*",
		container:      "*",
		cpuRequests:    nm.cpu.requestString(tp.availableFormat),
		cpuLimits:      nm.cpu.limitString(tp.availableFormat),
		cpuUtil:        nm.cpu.utilString(tp.availableFormat),
		memoryRequests: nm.memory.requestStringM(tp.availableFormat),
		memoryLimits:   nm.memory.limitStringM(tp.availableFormat),
		memoryUtil:     nm.memory.utilString(tp.availableFormat),
		podCount:       nm.podCount.podCountString(),
	})
}
robscott
robscott

Hey @christiancadieux, thanks for reporting this! I'm not sure how soon I'll be able to fix this, but very open to PRs.

Activity icon
issue

robscott issue comment robscott/kube-capacity

robscott
robscott

Is possible to use the tool without listing nodes?

Hi community,

With my limited permissions, I have this error

kubectl resource-capacity --sort cpu.limit --util --pods                     
Error listing Nodes: nodes is forbidden: User "320144150" cannot list resource "nodes" in API group "" at the cluster scope

Is possible to use the tool with my limited RBAC permission?

Best regards, Jizu

robscott
robscott

Hey @jizusun, I think we could potentially add that as an option. I think it would take some refactoring to make it work. Open to any PRs if anyone can make it work.

Previous