From 5fad9a68a0fa97092afcefb7c8733b9aa753cd7a Mon Sep 17 00:00:00 2001 From: Josh Soref <2119212+jsoref@users.noreply.github.com> Date: Fri, 18 Oct 2024 02:51:57 -0400 Subject: [PATCH 01/59] spelling: adding Signed-off-by: Josh Soref <2119212+jsoref@users.noreply.github.com> --- CHANGELOG/1.2-CHANGELOG.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CHANGELOG/1.2-CHANGELOG.md b/CHANGELOG/1.2-CHANGELOG.md index 3d61475690..ee260c649d 100644 --- a/CHANGELOG/1.2-CHANGELOG.md +++ b/CHANGELOG/1.2-CHANGELOG.md @@ -864,7 +864,7 @@ The Experimental `supportedFeatures` field in GatewayClass `status` has changed from being a list of strings to being a list of objects/structs with a `name` field. -This is to allow addding in extra information to each entry at a later date. +This is to allow adding in extra information to each entry at a later date. Relevant PRs: From 783e8df62ff44e291d3561a8d13d0068f58178ee Mon Sep 17 00:00:00 2001 From: Josh Soref <2119212+jsoref@users.noreply.github.com> Date: Wed, 16 Oct 2024 14:09:34 -0400 Subject: [PATCH 02/59] spelling: anymore Signed-off-by: Josh Soref <2119212+jsoref@users.noreply.github.com> --- geps/gep-1364/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/geps/gep-1364/index.md b/geps/gep-1364/index.md index b33fee3850..5afa356347 100644 --- a/geps/gep-1364/index.md +++ b/geps/gep-1364/index.md @@ -42,7 +42,7 @@ these changes. The constants that mark the deprecated types will be also marked as deprecated, and will no longer be tested as part of conformance. They'll still be present, -and will work, but they won't be part of the spec any more. This should give +and will work, but they won't be part of the spec anymore. This should give implementations and users a release to transition to the new design (in UX terms). This grace period should be one release (so, the constants will be removed in v0.7.0.) From 68e2a300af40beccc8e94e6b8087e10dabbbc0bf Mon Sep 17 00:00:00 2001 From: Josh Soref <2119212+jsoref@users.noreply.github.com> Date: Fri, 18 Oct 2024 02:52:47 -0400 Subject: [PATCH 03/59] spelling: approach Signed-off-by: Josh Soref <2119212+jsoref@users.noreply.github.com> --- geps/gep-1686/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/geps/gep-1686/index.md b/geps/gep-1686/index.md index eacf2a723c..d80bdfa042 100644 --- a/geps/gep-1686/index.md +++ b/geps/gep-1686/index.md @@ -23,7 +23,7 @@ The goal of the initial conformance testing is to check the essential behavior a GAMMA intends to introduce a "Mesh" [conformance profile](https://gateway-api.sigs.k8s.io/geps/gep-1709/) to isolate tests specific to East/West functionality from both existing tests focused on North/South functionality and common Gateway API functionality shared by N/S and E/W implementations. A conformance profile is a set of tests that implementations can run to check their conformance to some subset of the Gateway API spec. -This appropach will enable service meshes to certify that an implementation follows the GAMMA spec without requiring a North/South implementation, and importantly avoid any expectation that North/South Gateway API implementations expand their scope to understand GAMMA and E/W traffic flows. +This approach will enable service meshes to certify that an implementation follows the GAMMA spec without requiring a North/South implementation, and importantly avoid any expectation that North/South Gateway API implementations expand their scope to understand GAMMA and E/W traffic flows. Leveraging existing tests for common functionality between N/S and E/W implementations will both ensure consistency across Gateway API implementations and help limit the maintence burden for the conformance testing suite. From 2ab4845cdd6937692e3cb1c108e8ff70d68cfa34 Mon Sep 17 00:00:00 2001 From: Josh Soref <2119212+jsoref@users.noreply.github.com> Date: Fri, 18 Oct 2024 02:53:39 -0400 Subject: [PATCH 04/59] spelling: attached Signed-off-by: Josh Soref <2119212+jsoref@users.noreply.github.com> --- geps/gep-2648/index.md | 2 +- geps/gep-2649/index.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/geps/gep-2648/index.md b/geps/gep-2648/index.md index 681cf15ae5..ae3ebf389c 100644 --- a/geps/gep-2648/index.md +++ b/geps/gep-2648/index.md @@ -95,7 +95,7 @@ the Policy object, the DataplaneConfig object does not affect if the Policy is a Direct one or not. This is because _a user can understand the state of the hierarchy by looking at all the objects in the hierarchy_. DataplaneConfig is _outside_ the hierarchy in terms of understanding the state of the Policy. -Direct Attacthed Policy is intended as a way to _manage the complexity_ of +Direct Attached Policy is intended as a way to _manage the complexity_ of Policy objects and allow a _limited_ set of Policies to follow vastly more simple design patterns _if they meet a set of criteria_. diff --git a/geps/gep-2649/index.md b/geps/gep-2649/index.md index a6f18877f7..6823cfb000 100644 --- a/geps/gep-2649/index.md +++ b/geps/gep-2649/index.md @@ -60,7 +60,7 @@ an Inherited Policy. Note that the same object may be have some properties of both an Inherited Policy _and_ a Direct Policy if it can attach to multiple points of a hierarchy, such -as if the same Policy can be atttached to a Gateway (where it affects all Routes +as if the same Policy can be attached to a Gateway (where it affects all Routes attached to that Gateway) or to a Route (where it affects only that Route). If a Policy _can be_ used as an Inherited Policy, it MUST be treated as an From 016571d563286f8feef25b3019a9821d95532f32 Mon Sep 17 00:00:00 2001 From: Josh Soref <2119212+jsoref@users.noreply.github.com> Date: Fri, 18 Oct 2024 02:56:53 -0400 Subject: [PATCH 05/59] spelling: because Signed-off-by: Josh Soref <2119212+jsoref@users.noreply.github.com> --- geps/gep-1897/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/geps/gep-1897/index.md b/geps/gep-1897/index.md index 63e3102767..9562a085da 100644 --- a/geps/gep-1897/index.md +++ b/geps/gep-1897/index.md @@ -342,7 +342,7 @@ Ref: [TLS Origination](https://www.getambassador.io/docs/emissary/latest/topics/ ### NGINX implementation through CRDs (Comparable to Route or Policy of Gateway API) supports both TLS and mTLS * In the Upstream section of a VirtualServer or VirtualServerRoute (equivalent to HTTPRoute) there is a simple toggle to enable TLS. This does not validate the certificate of the backend and implicitly trusts the backend in order to form the SSL tunnel. This is not about validating the certificate but obfuscating the traffic with TLS/SSL. -* A Policy attachment can be provided when certification validation is required that is called egressMTLS (egress from the proxy to the upstream). This can be tuned to perform various certificate validation tests. It was created as a Policy becuase it implies some type of AuthN/AuthZ due to the additional checks. This was also compatible with Open Service Mesh and NGINX Service Mesh and removed the need for a sidecar at the ingress controller. +* A Policy attachment can be provided when certification validation is required that is called egressMTLS (egress from the proxy to the upstream). This can be tuned to perform various certificate validation tests. It was created as a Policy because it implies some type of AuthN/AuthZ due to the additional checks. This was also compatible with Open Service Mesh and NGINX Service Mesh and removed the need for a sidecar at the ingress controller. * A corresponding 'IngressMTLS' policy also exists for mTLS verification of client connections to the proxy. The Policy object is used for anything that implies AuthN/AuthZ. Ref: [Upstream.TLS](https://docs.nginx.com/nginx-ingress-controller/configuration/virtualserver-and-virtualserverroute-resources/#upstreamtls) From b0aa3cb8c003a5c4e719ac84dfba64d00fb34c1e Mon Sep 17 00:00:00 2001 From: Josh Soref <2119212+jsoref@users.noreply.github.com> Date: Wed, 16 Oct 2024 14:09:47 -0400 Subject: [PATCH 06/59] spelling: cannot Signed-off-by: Josh Soref <2119212+jsoref@users.noreply.github.com> --- CHANGELOG/0.x-CHANGELOG.md | 4 ++-- CHANGELOG/1.0-CHANGELOG.md | 4 ++-- apis/v1/grpcroute_types.go | 2 +- apis/v1/httproute_types.go | 4 ++-- apis/v1/shared_types.go | 6 +++--- apis/v1alpha2/shared_types.go | 4 ++-- apis/v1beta1/shared_types.go | 4 ++-- .../gateway.networking.k8s.io_grpcroutes.yaml | 2 +- .../gateway.networking.k8s.io_httproutes.yaml | 8 ++++---- .../standard/gateway.networking.k8s.io_grpcroutes.yaml | 2 +- .../standard/gateway.networking.k8s.io_httproutes.yaml | 8 ++++---- conformance/apis/v1/conformancereport.go | 10 +++++----- geps/gep-922/index.md | 2 +- pkg/generated/openapi/zz_generated.openapi.go | 4 ++-- site-src/api-types/grpcroute.md | 2 +- site-src/api-types/httproute.md | 2 +- 16 files changed, 34 insertions(+), 34 deletions(-) diff --git a/CHANGELOG/0.x-CHANGELOG.md b/CHANGELOG/0.x-CHANGELOG.md index 20f76c6551..f8432fca88 100644 --- a/CHANGELOG/0.x-CHANGELOG.md +++ b/CHANGELOG/0.x-CHANGELOG.md @@ -226,7 +226,7 @@ For more information refer to - Added the missing ReferenceGrant resource the kustomization.yaml for the standard channel (#2084, @howardjohn) -- Webhook validation now ensures that BackendRefs can not be specified in the +- Webhook validation now ensures that BackendRefs cannot be specified in the same HTTPRoute rule as a Redirect filter (#2161, @slayer321) - GRPCRoute: The default match has been removed as it was invalid (it only specified a type of "Exact" without a corresponding Service or Method). Note @@ -407,7 +407,7 @@ For more information, refer to - Added the missing ReferenceGrant resource the kustomization.yaml for the standard channel (#2084, @howardjohn) -- Webhook validation now ensures that BackendRefs can not be specified in the +- Webhook validation now ensures that BackendRefs cannot be specified in the same HTTPRoute rule as a Redirect filter (#2161, @slayer321) # v0.7.1 diff --git a/CHANGELOG/1.0-CHANGELOG.md b/CHANGELOG/1.0-CHANGELOG.md index 25520bb4eb..f879309752 100644 --- a/CHANGELOG/1.0-CHANGELOG.md +++ b/CHANGELOG/1.0-CHANGELOG.md @@ -142,7 +142,7 @@ Of course there's a lot more in this release: - The condition reason `GatewayReasonAddressNotUsable` for `Programmed` has been added to deal with situations where a static address has been provided for a Gateway which is of a supported type, and is syntactically valid, but for some - reason it can not be used for this Gateway (e.g. the address is already in use + reason it cannot be used for this Gateway (e.g. the address is already in use on the network). (#2412 @shaneutt) @@ -332,7 +332,7 @@ Of course there's a lot more in this release: - The condition reason `GatewayReasonAddressNotUsable` for `Programmed` has been added to deal with situations where a static address has been provided for a Gateway which is of a supported type, and is syntactically valid, but for some - reason it can not be used for this Gateway (e.g. the address is already in use + reason it cannot be used for this Gateway (e.g. the address is already in use on the network). (#2412 @shaneutt) diff --git a/apis/v1/grpcroute_types.go b/apis/v1/grpcroute_types.go index 953ba0243b..21beb95e8a 100644 --- a/apis/v1/grpcroute_types.go +++ b/apis/v1/grpcroute_types.go @@ -230,7 +230,7 @@ type GRPCRouteRule struct { // Specifying the same filter multiple times is not supported unless explicitly // indicated in the filter. // - // If an implementation can not support a combination of filters, it must clearly + // If an implementation cannot support a combination of filters, it must clearly // document that limitation. In cases where incompatible or unsupported // filters are specified and cause the `Accepted` condition to be set to status // `False`, implementations may use the `IncompatibleFilters` reason to specify diff --git a/apis/v1/httproute_types.go b/apis/v1/httproute_types.go index a185e3709f..c24a0edeae 100644 --- a/apis/v1/httproute_types.go +++ b/apis/v1/httproute_types.go @@ -210,7 +210,7 @@ type HTTPRouteRule struct { // they are specified. // // Implementations MAY choose to implement this ordering strictly, rejecting - // any combination or order of filters that can not be supported. If implementations + // any combination or order of filters that cannot be supported. If implementations // choose a strict interpretation of filter ordering, they MUST clearly document // that behavior. // @@ -232,7 +232,7 @@ type HTTPRouteRule struct { // // All filters are expected to be compatible with each other except for the // URLRewrite and RequestRedirect filters, which may not be combined. If an - // implementation can not support other combinations of filters, they must clearly + // implementation cannot support other combinations of filters, they must clearly // document that limitation. In cases where incompatible or unsupported // filters are specified and cause the `Accepted` condition to be set to status // `False`, implementations may use the `IncompatibleFilters` reason to specify diff --git a/apis/v1/shared_types.go b/apis/v1/shared_types.go index 998c7793fe..dcaa1b4b4a 100644 --- a/apis/v1/shared_types.go +++ b/apis/v1/shared_types.go @@ -675,7 +675,7 @@ type GatewayController string // Invalid values include: // // * example~ - "~" is an invalid character -// * example.com. - can not start or end with "." +// * example.com. - cannot start or end with "." // // +kubebuilder:validation:MinLength=1 // +kubebuilder:validation:MaxLength=253 @@ -705,7 +705,7 @@ type AnnotationValue string // Invalid values include: // // * example~ - "~" is an invalid character -// * example.com. - can not start or end with "." +// * example.com. - cannot start or end with "." // // +kubebuilder:validation:MinLength=1 // +kubebuilder:validation:MaxLength=253 @@ -771,7 +771,7 @@ const ( // (see [RFC 5952](https://tools.ietf.org/html/rfc5952)). // // This type is intended for specific addresses. Address ranges are not - // supported (e.g. you can not use a CIDR range like 127.0.0.0/24 as an + // supported (e.g. you cannot use a CIDR range like 127.0.0.0/24 as an // IPAddress). // // Support: Extended diff --git a/apis/v1alpha2/shared_types.go b/apis/v1alpha2/shared_types.go index af04601e41..2fb84d5f3b 100644 --- a/apis/v1alpha2/shared_types.go +++ b/apis/v1alpha2/shared_types.go @@ -313,7 +313,7 @@ type GatewayController = v1.GatewayController // Invalid values include: // // * example~ - "~" is an invalid character -// * example.com. - can not start or end with "." +// * example.com. - cannot start or end with "." // // +kubebuilder:validation:MinLength=1 // +kubebuilder:validation:MaxLength=253 @@ -360,7 +360,7 @@ const ( // (see [RFC 5952](https://tools.ietf.org/html/rfc5952)). // // This type is intended for specific addresses. Address ranges are not - // supported (e.g. you can not use a CIDR range like 127.0.0.0/24 as an + // supported (e.g. you cannot use a CIDR range like 127.0.0.0/24 as an // IPAddress). // // Support: Extended diff --git a/apis/v1beta1/shared_types.go b/apis/v1beta1/shared_types.go index 2dfbb9264a..3dbcc280fc 100644 --- a/apis/v1beta1/shared_types.go +++ b/apis/v1beta1/shared_types.go @@ -313,7 +313,7 @@ type GatewayController = v1.GatewayController // Invalid values include: // // * example~ - "~" is an invalid character -// * example.com. - can not start or end with "." +// * example.com. - cannot start or end with "." // // +kubebuilder:validation:MinLength=1 // +kubebuilder:validation:MaxLength=253 @@ -360,7 +360,7 @@ const ( // (see [RFC 5952](https://tools.ietf.org/html/rfc5952)). // // This type is intended for specific addresses. Address ranges are not - // supported (e.g. you can not use a CIDR range like 127.0.0.0/24 as an + // supported (e.g. you cannot use a CIDR range like 127.0.0.0/24 as an // IPAddress). // // Support: Extended diff --git a/config/crd/experimental/gateway.networking.k8s.io_grpcroutes.yaml b/config/crd/experimental/gateway.networking.k8s.io_grpcroutes.yaml index ad9944737e..958f38c650 100644 --- a/config/crd/experimental/gateway.networking.k8s.io_grpcroutes.yaml +++ b/config/crd/experimental/gateway.networking.k8s.io_grpcroutes.yaml @@ -1099,7 +1099,7 @@ spec: Specifying the same filter multiple times is not supported unless explicitly indicated in the filter. - If an implementation can not support a combination of filters, it must clearly + If an implementation cannot support a combination of filters, it must clearly document that limitation. In cases where incompatible or unsupported filters are specified and cause the `Accepted` condition to be set to status `False`, implementations may use the `IncompatibleFilters` reason to specify diff --git a/config/crd/experimental/gateway.networking.k8s.io_httproutes.yaml b/config/crd/experimental/gateway.networking.k8s.io_httproutes.yaml index 527c795f1d..26630715f7 100644 --- a/config/crd/experimental/gateway.networking.k8s.io_httproutes.yaml +++ b/config/crd/experimental/gateway.networking.k8s.io_httproutes.yaml @@ -1356,7 +1356,7 @@ spec: they are specified. Implementations MAY choose to implement this ordering strictly, rejecting - any combination or order of filters that can not be supported. If implementations + any combination or order of filters that cannot be supported. If implementations choose a strict interpretation of filter ordering, they MUST clearly document that behavior. @@ -1378,7 +1378,7 @@ spec: All filters are expected to be compatible with each other except for the URLRewrite and RequestRedirect filters, which may not be combined. If an - implementation can not support other combinations of filters, they must clearly + implementation cannot support other combinations of filters, they must clearly document that limitation. In cases where incompatible or unsupported filters are specified and cause the `Accepted` condition to be set to status `False`, implementations may use the `IncompatibleFilters` reason to specify @@ -4404,7 +4404,7 @@ spec: they are specified. Implementations MAY choose to implement this ordering strictly, rejecting - any combination or order of filters that can not be supported. If implementations + any combination or order of filters that cannot be supported. If implementations choose a strict interpretation of filter ordering, they MUST clearly document that behavior. @@ -4426,7 +4426,7 @@ spec: All filters are expected to be compatible with each other except for the URLRewrite and RequestRedirect filters, which may not be combined. If an - implementation can not support other combinations of filters, they must clearly + implementation cannot support other combinations of filters, they must clearly document that limitation. In cases where incompatible or unsupported filters are specified and cause the `Accepted` condition to be set to status `False`, implementations may use the `IncompatibleFilters` reason to specify diff --git a/config/crd/standard/gateway.networking.k8s.io_grpcroutes.yaml b/config/crd/standard/gateway.networking.k8s.io_grpcroutes.yaml index 1cd8c79bf6..24818c4160 100644 --- a/config/crd/standard/gateway.networking.k8s.io_grpcroutes.yaml +++ b/config/crd/standard/gateway.networking.k8s.io_grpcroutes.yaml @@ -1012,7 +1012,7 @@ spec: Specifying the same filter multiple times is not supported unless explicitly indicated in the filter. - If an implementation can not support a combination of filters, it must clearly + If an implementation cannot support a combination of filters, it must clearly document that limitation. In cases where incompatible or unsupported filters are specified and cause the `Accepted` condition to be set to status `False`, implementations may use the `IncompatibleFilters` reason to specify diff --git a/config/crd/standard/gateway.networking.k8s.io_httproutes.yaml b/config/crd/standard/gateway.networking.k8s.io_httproutes.yaml index fc68fd8e78..877def0be6 100644 --- a/config/crd/standard/gateway.networking.k8s.io_httproutes.yaml +++ b/config/crd/standard/gateway.networking.k8s.io_httproutes.yaml @@ -1269,7 +1269,7 @@ spec: they are specified. Implementations MAY choose to implement this ordering strictly, rejecting - any combination or order of filters that can not be supported. If implementations + any combination or order of filters that cannot be supported. If implementations choose a strict interpretation of filter ordering, they MUST clearly document that behavior. @@ -1291,7 +1291,7 @@ spec: All filters are expected to be compatible with each other except for the URLRewrite and RequestRedirect filters, which may not be combined. If an - implementation can not support other combinations of filters, they must clearly + implementation cannot support other combinations of filters, they must clearly document that limitation. In cases where incompatible or unsupported filters are specified and cause the `Accepted` condition to be set to status `False`, implementations may use the `IncompatibleFilters` reason to specify @@ -3984,7 +3984,7 @@ spec: they are specified. Implementations MAY choose to implement this ordering strictly, rejecting - any combination or order of filters that can not be supported. If implementations + any combination or order of filters that cannot be supported. If implementations choose a strict interpretation of filter ordering, they MUST clearly document that behavior. @@ -4006,7 +4006,7 @@ spec: All filters are expected to be compatible with each other except for the URLRewrite and RequestRedirect filters, which may not be combined. If an - implementation can not support other combinations of filters, they must clearly + implementation cannot support other combinations of filters, they must clearly document that limitation. In cases where incompatible or unsupported filters are specified and cause the `Accepted` condition to be set to status `False`, implementations may use the `IncompatibleFilters` reason to specify diff --git a/conformance/apis/v1/conformancereport.go b/conformance/apis/v1/conformancereport.go index 94e5e8e064..9eb23704fd 100644 --- a/conformance/apis/v1/conformancereport.go +++ b/conformance/apis/v1/conformancereport.go @@ -90,19 +90,19 @@ type Implementation struct { func (i *Implementation) Validate() error { // TODO: add data validation https://github.com/kubernetes-sigs/gateway-api/issues/2178 if i.Organization == "" { - return errors.New("implementation's organization can not be empty") + return errors.New("implementation's organization cannot be empty") } if i.Project == "" { - return errors.New("implementation's project can not be empty") + return errors.New("implementation's project cannot be empty") } if i.URL == "" { - return errors.New("implementation's url can not be empty") + return errors.New("implementation's url cannot be empty") } if i.Version == "" { - return errors.New("implementation's version can not be empty") + return errors.New("implementation's version cannot be empty") } if len(i.Contact) == 0 { - return errors.New("implementation's contact can not be empty") + return errors.New("implementation's contact cannot be empty") } return nil } diff --git a/geps/gep-922/index.md b/geps/gep-922/index.md index a1afba7965..23b6153111 100644 --- a/geps/gep-922/index.md +++ b/geps/gep-922/index.md @@ -51,7 +51,7 @@ and/or removing old ones as part of a new bundle. ## Limitations of Webhook and CRD Validation CRD and webhook validation is not the final validation i.e. webhook is “nice UX” but not schema enforcement. This validation is intended to provide immediate -feedback to users when they provide an invalid configuration, but can not +feedback to users when they provide an invalid configuration, but cannot completely be relied on because it: * Is not guaranteed to be present or up to date in all clusters. diff --git a/pkg/generated/openapi/zz_generated.openapi.go b/pkg/generated/openapi/zz_generated.openapi.go index 1c4fa188f7..5574a14381 100644 --- a/pkg/generated/openapi/zz_generated.openapi.go +++ b/pkg/generated/openapi/zz_generated.openapi.go @@ -3390,7 +3390,7 @@ func schema_sigsk8sio_gateway_api_apis_v1_GRPCRouteRule(ref common.ReferenceCall }, "filters": { SchemaProps: spec.SchemaProps{ - Description: "Filters define the filters that are applied to requests that match this rule.\n\nThe effects of ordering of multiple behaviors are currently unspecified. This can change in the future based on feedback during the alpha stage.\n\nConformance-levels at this level are defined based on the type of filter:\n\n- ALL core filters MUST be supported by all implementations that support\n GRPCRoute.\n- Implementers are encouraged to support extended filters. - Implementation-specific custom filters have no API guarantees across\n implementations.\n\nSpecifying the same filter multiple times is not supported unless explicitly indicated in the filter.\n\nIf an implementation can not support a combination of filters, it must clearly document that limitation. In cases where incompatible or unsupported filters are specified and cause the `Accepted` condition to be set to status `False`, implementations may use the `IncompatibleFilters` reason to specify this configuration error.\n\nSupport: Core", + Description: "Filters define the filters that are applied to requests that match this rule.\n\nThe effects of ordering of multiple behaviors are currently unspecified. This can change in the future based on feedback during the alpha stage.\n\nConformance-levels at this level are defined based on the type of filter:\n\n- ALL core filters MUST be supported by all implementations that support\n GRPCRoute.\n- Implementers are encouraged to support extended filters. - Implementation-specific custom filters have no API guarantees across\n implementations.\n\nSpecifying the same filter multiple times is not supported unless explicitly indicated in the filter.\n\nIf an implementation cannot support a combination of filters, it must clearly document that limitation. In cases where incompatible or unsupported filters are specified and cause the `Accepted` condition to be set to status `False`, implementations may use the `IncompatibleFilters` reason to specify this configuration error.\n\nSupport: Core", Type: []string{"array"}, Items: &spec.SchemaOrArray{ Schema: &spec.Schema{ @@ -4853,7 +4853,7 @@ func schema_sigsk8sio_gateway_api_apis_v1_HTTPRouteRule(ref common.ReferenceCall }, "filters": { SchemaProps: spec.SchemaProps{ - Description: "Filters define the filters that are applied to requests that match this rule.\n\nWherever possible, implementations SHOULD implement filters in the order they are specified.\n\nImplementations MAY choose to implement this ordering strictly, rejecting any combination or order of filters that can not be supported. If implementations choose a strict interpretation of filter ordering, they MUST clearly document that behavior.\n\nTo reject an invalid combination or order of filters, implementations SHOULD consider the Route Rules with this configuration invalid. If all Route Rules in a Route are invalid, the entire Route would be considered invalid. If only a portion of Route Rules are invalid, implementations MUST set the \"PartiallyInvalid\" condition for the Route.\n\nConformance-levels at this level are defined based on the type of filter:\n\n- ALL core filters MUST be supported by all implementations. - Implementers are encouraged to support extended filters. - Implementation-specific custom filters have no API guarantees across\n implementations.\n\nSpecifying the same filter multiple times is not supported unless explicitly indicated in the filter.\n\nAll filters are expected to be compatible with each other except for the URLRewrite and RequestRedirect filters, which may not be combined. If an implementation can not support other combinations of filters, they must clearly document that limitation. In cases where incompatible or unsupported filters are specified and cause the `Accepted` condition to be set to status `False`, implementations may use the `IncompatibleFilters` reason to specify this configuration error.\n\nSupport: Core", + Description: "Filters define the filters that are applied to requests that match this rule.\n\nWherever possible, implementations SHOULD implement filters in the order they are specified.\n\nImplementations MAY choose to implement this ordering strictly, rejecting any combination or order of filters that cannot be supported. If implementations choose a strict interpretation of filter ordering, they MUST clearly document that behavior.\n\nTo reject an invalid combination or order of filters, implementations SHOULD consider the Route Rules with this configuration invalid. If all Route Rules in a Route are invalid, the entire Route would be considered invalid. If only a portion of Route Rules are invalid, implementations MUST set the \"PartiallyInvalid\" condition for the Route.\n\nConformance-levels at this level are defined based on the type of filter:\n\n- ALL core filters MUST be supported by all implementations. - Implementers are encouraged to support extended filters. - Implementation-specific custom filters have no API guarantees across\n implementations.\n\nSpecifying the same filter multiple times is not supported unless explicitly indicated in the filter.\n\nAll filters are expected to be compatible with each other except for the URLRewrite and RequestRedirect filters, which may not be combined. If an implementation cannot support other combinations of filters, they must clearly document that limitation. In cases where incompatible or unsupported filters are specified and cause the `Accepted` condition to be set to status `False`, implementations may use the `IncompatibleFilters` reason to specify this configuration error.\n\nSupport: Core", Type: []string{"array"}, Items: &spec.SchemaOrArray{ Schema: &spec.Schema{ diff --git a/site-src/api-types/grpcroute.md b/site-src/api-types/grpcroute.md index 0bb4a9b5f7..560d7fe2ef 100644 --- a/site-src/api-types/grpcroute.md +++ b/site-src/api-types/grpcroute.md @@ -185,7 +185,7 @@ Conformance levels are defined by the filter type: Specifying a core filter multiple times has unspecified or custom conformance. -If an implementation can not support a combinations of filters, they must clearly +If an implementation cannot support a combinations of filters, they must clearly document that limitation. In cases where incompatible or unsupported filters are specified and cause the `Accepted` condition to be set to status `False`, implementations may use the `IncompatibleFilters` reason to specify diff --git a/site-src/api-types/httproute.md b/site-src/api-types/httproute.md index 1bdade682a..ba701b7410 100644 --- a/site-src/api-types/httproute.md +++ b/site-src/api-types/httproute.md @@ -198,7 +198,7 @@ implementation-specific conformance. All filters are expected to be compatible with each other except for the URLRewrite and RequestRedirect filters, which may not be combined. If an -implementation can not support other combinations of filters, they must clearly +implementation cannot support other combinations of filters, they must clearly document that limitation. In cases where incompatible or unsupported filters are specified and cause the `Accepted` condition to be set to status `False`, implementations may use the `IncompatibleFilters` reason to specify From 69b6db73dde0ddb0a83bd198d514214859942c92 Mon Sep 17 00:00:00 2001 From: Josh Soref <2119212+jsoref@users.noreply.github.com> Date: Wed, 16 Oct 2024 14:09:58 -0400 Subject: [PATCH 07/59] spelling: case-insensitive Signed-off-by: Josh Soref <2119212+jsoref@users.noreply.github.com> --- apis/v1/httproute_types.go | 4 +-- .../gateway.networking.k8s.io_grpcroutes.yaml | 16 ++++----- .../gateway.networking.k8s.io_httproutes.yaml | 36 +++++++++---------- .../gateway.networking.k8s.io_grpcroutes.yaml | 16 ++++----- .../gateway.networking.k8s.io_httproutes.yaml | 36 +++++++++---------- pkg/generated/openapi/zz_generated.openapi.go | 4 +-- 6 files changed, 56 insertions(+), 56 deletions(-) diff --git a/apis/v1/httproute_types.go b/apis/v1/httproute_types.go index c24a0edeae..005d51f8a1 100644 --- a/apis/v1/httproute_types.go +++ b/apis/v1/httproute_types.go @@ -596,7 +596,7 @@ type HTTPHeaderMatch struct { Type *HeaderMatchType `json:"type,omitempty"` // Name is the name of the HTTP Header to be matched. Name matching MUST be - // case insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). + // case-insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). // // If multiple entries specify equivalent header names, only the first // entry with an equivalent name MUST be considered for a match. Subsequent @@ -947,7 +947,7 @@ const ( // HTTPHeader represents an HTTP Header name and value as defined by RFC 7230. type HTTPHeader struct { // Name is the name of the HTTP Header to be matched. Name matching MUST be - // case insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). + // case-insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). // // If multiple entries specify equivalent header names, the first entry with // an equivalent name MUST be considered for a match. Subsequent entries diff --git a/config/crd/experimental/gateway.networking.k8s.io_grpcroutes.yaml b/config/crd/experimental/gateway.networking.k8s.io_grpcroutes.yaml index 958f38c650..778993eb2a 100644 --- a/config/crd/experimental/gateway.networking.k8s.io_grpcroutes.yaml +++ b/config/crd/experimental/gateway.networking.k8s.io_grpcroutes.yaml @@ -532,7 +532,7 @@ spec: name: description: |- Name is the name of the HTTP Header to be matched. Name matching MUST be - case insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). + case-insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). If multiple entries specify equivalent header names, the first entry with an equivalent name MUST be considered for a match. Subsequent entries @@ -607,7 +607,7 @@ spec: name: description: |- Name is the name of the HTTP Header to be matched. Name matching MUST be - case insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). + case-insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). If multiple entries specify equivalent header names, the first entry with an equivalent name MUST be considered for a match. Subsequent entries @@ -815,7 +815,7 @@ spec: name: description: |- Name is the name of the HTTP Header to be matched. Name matching MUST be - case insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). + case-insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). If multiple entries specify equivalent header names, the first entry with an equivalent name MUST be considered for a match. Subsequent entries @@ -890,7 +890,7 @@ spec: name: description: |- Name is the name of the HTTP Header to be matched. Name matching MUST be - case insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). + case-insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). If multiple entries specify equivalent header names, the first entry with an equivalent name MUST be considered for a match. Subsequent entries @@ -1182,7 +1182,7 @@ spec: name: description: |- Name is the name of the HTTP Header to be matched. Name matching MUST be - case insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). + case-insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). If multiple entries specify equivalent header names, the first entry with an equivalent name MUST be considered for a match. Subsequent entries @@ -1256,7 +1256,7 @@ spec: name: description: |- Name is the name of the HTTP Header to be matched. Name matching MUST be - case insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). + case-insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). If multiple entries specify equivalent header names, the first entry with an equivalent name MUST be considered for a match. Subsequent entries @@ -1463,7 +1463,7 @@ spec: name: description: |- Name is the name of the HTTP Header to be matched. Name matching MUST be - case insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). + case-insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). If multiple entries specify equivalent header names, the first entry with an equivalent name MUST be considered for a match. Subsequent entries @@ -1537,7 +1537,7 @@ spec: name: description: |- Name is the name of the HTTP Header to be matched. Name matching MUST be - case insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). + case-insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). If multiple entries specify equivalent header names, the first entry with an equivalent name MUST be considered for a match. Subsequent entries diff --git a/config/crd/experimental/gateway.networking.k8s.io_httproutes.yaml b/config/crd/experimental/gateway.networking.k8s.io_httproutes.yaml index 26630715f7..4d16463b4d 100644 --- a/config/crd/experimental/gateway.networking.k8s.io_httproutes.yaml +++ b/config/crd/experimental/gateway.networking.k8s.io_httproutes.yaml @@ -524,7 +524,7 @@ spec: name: description: |- Name is the name of the HTTP Header to be matched. Name matching MUST be - case insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). + case-insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). If multiple entries specify equivalent header names, the first entry with an equivalent name MUST be considered for a match. Subsequent entries @@ -599,7 +599,7 @@ spec: name: description: |- Name is the name of the HTTP Header to be matched. Name matching MUST be - case insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). + case-insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). If multiple entries specify equivalent header names, the first entry with an equivalent name MUST be considered for a match. Subsequent entries @@ -960,7 +960,7 @@ spec: name: description: |- Name is the name of the HTTP Header to be matched. Name matching MUST be - case insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). + case-insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). If multiple entries specify equivalent header names, the first entry with an equivalent name MUST be considered for a match. Subsequent entries @@ -1035,7 +1035,7 @@ spec: name: description: |- Name is the name of the HTTP Header to be matched. Name matching MUST be - case insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). + case-insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). If multiple entries specify equivalent header names, the first entry with an equivalent name MUST be considered for a match. Subsequent entries @@ -1461,7 +1461,7 @@ spec: name: description: |- Name is the name of the HTTP Header to be matched. Name matching MUST be - case insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). + case-insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). If multiple entries specify equivalent header names, the first entry with an equivalent name MUST be considered for a match. Subsequent entries @@ -1535,7 +1535,7 @@ spec: name: description: |- Name is the name of the HTTP Header to be matched. Name matching MUST be - case insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). + case-insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). If multiple entries specify equivalent header names, the first entry with an equivalent name MUST be considered for a match. Subsequent entries @@ -1895,7 +1895,7 @@ spec: name: description: |- Name is the name of the HTTP Header to be matched. Name matching MUST be - case insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). + case-insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). If multiple entries specify equivalent header names, the first entry with an equivalent name MUST be considered for a match. Subsequent entries @@ -1969,7 +1969,7 @@ spec: name: description: |- Name is the name of the HTTP Header to be matched. Name matching MUST be - case insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). + case-insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). If multiple entries specify equivalent header names, the first entry with an equivalent name MUST be considered for a match. Subsequent entries @@ -2269,7 +2269,7 @@ spec: name: description: |- Name is the name of the HTTP Header to be matched. Name matching MUST be - case insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). + case-insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). If multiple entries specify equivalent header names, only the first entry with an equivalent name MUST be considered for a match. Subsequent @@ -3572,7 +3572,7 @@ spec: name: description: |- Name is the name of the HTTP Header to be matched. Name matching MUST be - case insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). + case-insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). If multiple entries specify equivalent header names, the first entry with an equivalent name MUST be considered for a match. Subsequent entries @@ -3647,7 +3647,7 @@ spec: name: description: |- Name is the name of the HTTP Header to be matched. Name matching MUST be - case insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). + case-insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). If multiple entries specify equivalent header names, the first entry with an equivalent name MUST be considered for a match. Subsequent entries @@ -4008,7 +4008,7 @@ spec: name: description: |- Name is the name of the HTTP Header to be matched. Name matching MUST be - case insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). + case-insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). If multiple entries specify equivalent header names, the first entry with an equivalent name MUST be considered for a match. Subsequent entries @@ -4083,7 +4083,7 @@ spec: name: description: |- Name is the name of the HTTP Header to be matched. Name matching MUST be - case insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). + case-insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). If multiple entries specify equivalent header names, the first entry with an equivalent name MUST be considered for a match. Subsequent entries @@ -4509,7 +4509,7 @@ spec: name: description: |- Name is the name of the HTTP Header to be matched. Name matching MUST be - case insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). + case-insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). If multiple entries specify equivalent header names, the first entry with an equivalent name MUST be considered for a match. Subsequent entries @@ -4583,7 +4583,7 @@ spec: name: description: |- Name is the name of the HTTP Header to be matched. Name matching MUST be - case insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). + case-insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). If multiple entries specify equivalent header names, the first entry with an equivalent name MUST be considered for a match. Subsequent entries @@ -4943,7 +4943,7 @@ spec: name: description: |- Name is the name of the HTTP Header to be matched. Name matching MUST be - case insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). + case-insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). If multiple entries specify equivalent header names, the first entry with an equivalent name MUST be considered for a match. Subsequent entries @@ -5017,7 +5017,7 @@ spec: name: description: |- Name is the name of the HTTP Header to be matched. Name matching MUST be - case insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). + case-insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). If multiple entries specify equivalent header names, the first entry with an equivalent name MUST be considered for a match. Subsequent entries @@ -5317,7 +5317,7 @@ spec: name: description: |- Name is the name of the HTTP Header to be matched. Name matching MUST be - case insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). + case-insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). If multiple entries specify equivalent header names, only the first entry with an equivalent name MUST be considered for a match. Subsequent diff --git a/config/crd/standard/gateway.networking.k8s.io_grpcroutes.yaml b/config/crd/standard/gateway.networking.k8s.io_grpcroutes.yaml index 24818c4160..273ab5bcdd 100644 --- a/config/crd/standard/gateway.networking.k8s.io_grpcroutes.yaml +++ b/config/crd/standard/gateway.networking.k8s.io_grpcroutes.yaml @@ -485,7 +485,7 @@ spec: name: description: |- Name is the name of the HTTP Header to be matched. Name matching MUST be - case insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). + case-insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). If multiple entries specify equivalent header names, the first entry with an equivalent name MUST be considered for a match. Subsequent entries @@ -560,7 +560,7 @@ spec: name: description: |- Name is the name of the HTTP Header to be matched. Name matching MUST be - case insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). + case-insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). If multiple entries specify equivalent header names, the first entry with an equivalent name MUST be considered for a match. Subsequent entries @@ -728,7 +728,7 @@ spec: name: description: |- Name is the name of the HTTP Header to be matched. Name matching MUST be - case insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). + case-insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). If multiple entries specify equivalent header names, the first entry with an equivalent name MUST be considered for a match. Subsequent entries @@ -803,7 +803,7 @@ spec: name: description: |- Name is the name of the HTTP Header to be matched. Name matching MUST be - case insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). + case-insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). If multiple entries specify equivalent header names, the first entry with an equivalent name MUST be considered for a match. Subsequent entries @@ -1095,7 +1095,7 @@ spec: name: description: |- Name is the name of the HTTP Header to be matched. Name matching MUST be - case insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). + case-insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). If multiple entries specify equivalent header names, the first entry with an equivalent name MUST be considered for a match. Subsequent entries @@ -1169,7 +1169,7 @@ spec: name: description: |- Name is the name of the HTTP Header to be matched. Name matching MUST be - case insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). + case-insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). If multiple entries specify equivalent header names, the first entry with an equivalent name MUST be considered for a match. Subsequent entries @@ -1336,7 +1336,7 @@ spec: name: description: |- Name is the name of the HTTP Header to be matched. Name matching MUST be - case insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). + case-insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). If multiple entries specify equivalent header names, the first entry with an equivalent name MUST be considered for a match. Subsequent entries @@ -1410,7 +1410,7 @@ spec: name: description: |- Name is the name of the HTTP Header to be matched. Name matching MUST be - case insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). + case-insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). If multiple entries specify equivalent header names, the first entry with an equivalent name MUST be considered for a match. Subsequent entries diff --git a/config/crd/standard/gateway.networking.k8s.io_httproutes.yaml b/config/crd/standard/gateway.networking.k8s.io_httproutes.yaml index 877def0be6..84f72350f5 100644 --- a/config/crd/standard/gateway.networking.k8s.io_httproutes.yaml +++ b/config/crd/standard/gateway.networking.k8s.io_httproutes.yaml @@ -477,7 +477,7 @@ spec: name: description: |- Name is the name of the HTTP Header to be matched. Name matching MUST be - case insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). + case-insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). If multiple entries specify equivalent header names, the first entry with an equivalent name MUST be considered for a match. Subsequent entries @@ -552,7 +552,7 @@ spec: name: description: |- Name is the name of the HTTP Header to be matched. Name matching MUST be - case insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). + case-insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). If multiple entries specify equivalent header names, the first entry with an equivalent name MUST be considered for a match. Subsequent entries @@ -873,7 +873,7 @@ spec: name: description: |- Name is the name of the HTTP Header to be matched. Name matching MUST be - case insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). + case-insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). If multiple entries specify equivalent header names, the first entry with an equivalent name MUST be considered for a match. Subsequent entries @@ -948,7 +948,7 @@ spec: name: description: |- Name is the name of the HTTP Header to be matched. Name matching MUST be - case insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). + case-insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). If multiple entries specify equivalent header names, the first entry with an equivalent name MUST be considered for a match. Subsequent entries @@ -1374,7 +1374,7 @@ spec: name: description: |- Name is the name of the HTTP Header to be matched. Name matching MUST be - case insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). + case-insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). If multiple entries specify equivalent header names, the first entry with an equivalent name MUST be considered for a match. Subsequent entries @@ -1448,7 +1448,7 @@ spec: name: description: |- Name is the name of the HTTP Header to be matched. Name matching MUST be - case insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). + case-insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). If multiple entries specify equivalent header names, the first entry with an equivalent name MUST be considered for a match. Subsequent entries @@ -1768,7 +1768,7 @@ spec: name: description: |- Name is the name of the HTTP Header to be matched. Name matching MUST be - case insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). + case-insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). If multiple entries specify equivalent header names, the first entry with an equivalent name MUST be considered for a match. Subsequent entries @@ -1842,7 +1842,7 @@ spec: name: description: |- Name is the name of the HTTP Header to be matched. Name matching MUST be - case insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). + case-insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). If multiple entries specify equivalent header names, the first entry with an equivalent name MUST be considered for a match. Subsequent entries @@ -2142,7 +2142,7 @@ spec: name: description: |- Name is the name of the HTTP Header to be matched. Name matching MUST be - case insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). + case-insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). If multiple entries specify equivalent header names, only the first entry with an equivalent name MUST be considered for a match. Subsequent @@ -3192,7 +3192,7 @@ spec: name: description: |- Name is the name of the HTTP Header to be matched. Name matching MUST be - case insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). + case-insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). If multiple entries specify equivalent header names, the first entry with an equivalent name MUST be considered for a match. Subsequent entries @@ -3267,7 +3267,7 @@ spec: name: description: |- Name is the name of the HTTP Header to be matched. Name matching MUST be - case insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). + case-insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). If multiple entries specify equivalent header names, the first entry with an equivalent name MUST be considered for a match. Subsequent entries @@ -3588,7 +3588,7 @@ spec: name: description: |- Name is the name of the HTTP Header to be matched. Name matching MUST be - case insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). + case-insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). If multiple entries specify equivalent header names, the first entry with an equivalent name MUST be considered for a match. Subsequent entries @@ -3663,7 +3663,7 @@ spec: name: description: |- Name is the name of the HTTP Header to be matched. Name matching MUST be - case insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). + case-insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). If multiple entries specify equivalent header names, the first entry with an equivalent name MUST be considered for a match. Subsequent entries @@ -4089,7 +4089,7 @@ spec: name: description: |- Name is the name of the HTTP Header to be matched. Name matching MUST be - case insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). + case-insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). If multiple entries specify equivalent header names, the first entry with an equivalent name MUST be considered for a match. Subsequent entries @@ -4163,7 +4163,7 @@ spec: name: description: |- Name is the name of the HTTP Header to be matched. Name matching MUST be - case insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). + case-insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). If multiple entries specify equivalent header names, the first entry with an equivalent name MUST be considered for a match. Subsequent entries @@ -4483,7 +4483,7 @@ spec: name: description: |- Name is the name of the HTTP Header to be matched. Name matching MUST be - case insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). + case-insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). If multiple entries specify equivalent header names, the first entry with an equivalent name MUST be considered for a match. Subsequent entries @@ -4557,7 +4557,7 @@ spec: name: description: |- Name is the name of the HTTP Header to be matched. Name matching MUST be - case insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). + case-insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). If multiple entries specify equivalent header names, the first entry with an equivalent name MUST be considered for a match. Subsequent entries @@ -4857,7 +4857,7 @@ spec: name: description: |- Name is the name of the HTTP Header to be matched. Name matching MUST be - case insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). + case-insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). If multiple entries specify equivalent header names, only the first entry with an equivalent name MUST be considered for a match. Subsequent diff --git a/pkg/generated/openapi/zz_generated.openapi.go b/pkg/generated/openapi/zz_generated.openapi.go index 5574a14381..57852ee696 100644 --- a/pkg/generated/openapi/zz_generated.openapi.go +++ b/pkg/generated/openapi/zz_generated.openapi.go @@ -4228,7 +4228,7 @@ func schema_sigsk8sio_gateway_api_apis_v1_HTTPHeader(ref common.ReferenceCallbac Properties: map[string]spec.Schema{ "name": { SchemaProps: spec.SchemaProps{ - Description: "Name is the name of the HTTP Header to be matched. Name matching MUST be case insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2).\n\nIf multiple entries specify equivalent header names, the first entry with an equivalent name MUST be considered for a match. Subsequent entries with an equivalent header name MUST be ignored. Due to the case-insensitivity of header names, \"foo\" and \"Foo\" are considered equivalent.", + Description: "Name is the name of the HTTP Header to be matched. Name matching MUST be case-insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2).\n\nIf multiple entries specify equivalent header names, the first entry with an equivalent name MUST be considered for a match. Subsequent entries with an equivalent header name MUST be ignored. Due to the case-insensitivity of header names, \"foo\" and \"Foo\" are considered equivalent.", Default: "", Type: []string{"string"}, Format: "", @@ -4344,7 +4344,7 @@ func schema_sigsk8sio_gateway_api_apis_v1_HTTPHeaderMatch(ref common.ReferenceCa }, "name": { SchemaProps: spec.SchemaProps{ - Description: "Name is the name of the HTTP Header to be matched. Name matching MUST be case insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2).\n\nIf multiple entries specify equivalent header names, only the first entry with an equivalent name MUST be considered for a match. Subsequent entries with an equivalent header name MUST be ignored. Due to the case-insensitivity of header names, \"foo\" and \"Foo\" are considered equivalent.\n\nWhen a header is repeated in an HTTP request, it is implementation-specific behavior as to how this is represented. Generally, proxies should follow the guidance from the RFC: https://www.rfc-editor.org/rfc/rfc7230.html#section-3.2.2 regarding processing a repeated header, with special handling for \"Set-Cookie\".", + Description: "Name is the name of the HTTP Header to be matched. Name matching MUST be case-insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2).\n\nIf multiple entries specify equivalent header names, only the first entry with an equivalent name MUST be considered for a match. Subsequent entries with an equivalent header name MUST be ignored. Due to the case-insensitivity of header names, \"foo\" and \"Foo\" are considered equivalent.\n\nWhen a header is repeated in an HTTP request, it is implementation-specific behavior as to how this is represented. Generally, proxies should follow the guidance from the RFC: https://www.rfc-editor.org/rfc/rfc7230.html#section-3.2.2 regarding processing a repeated header, with special handling for \"Set-Cookie\".", Default: "", Type: []string{"string"}, Format: "", From 21b74517ee01752297e5f280ddbc199309a96b1a Mon Sep 17 00:00:00 2001 From: Josh Soref <2119212+jsoref@users.noreply.github.com> Date: Wed, 16 Oct 2024 14:10:09 -0400 Subject: [PATCH 08/59] spelling: case-sensitive Signed-off-by: Josh Soref <2119212+jsoref@users.noreply.github.com> --- apis/v1/httproute_types.go | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/apis/v1/httproute_types.go b/apis/v1/httproute_types.go index 005d51f8a1..8037c4f17b 100644 --- a/apis/v1/httproute_types.go +++ b/apis/v1/httproute_types.go @@ -487,7 +487,7 @@ const ( PathMatchExact PathMatchType = "Exact" // Matches based on a URL path prefix split by `/`. Matching is - // case sensitive and done on a path element by element basis. A + // case-sensitive and done on a path element by element basis. A // path element refers to the list of labels in the path split by // the `/` separator. When specified, a trailing `/` is ignored. // From 03a2a28fe37ab6991a0ad96d71cc6e727ac21f13 Mon Sep 17 00:00:00 2001 From: Josh Soref <2119212+jsoref@users.noreply.github.com> Date: Fri, 18 Oct 2024 02:58:54 -0400 Subject: [PATCH 09/59] spelling: certificate Signed-off-by: Josh Soref <2119212+jsoref@users.noreply.github.com> --- apis/v1alpha3/backendtlspolicy_types.go | 2 +- .../gateway.networking.k8s.io_backendtlspolicies.yaml | 2 +- geps/gep-1897/index.md | 4 ++-- pkg/generated/openapi/zz_generated.openapi.go | 2 +- site-src/api-types/backendtlspolicy.md | 8 ++++---- 5 files changed, 9 insertions(+), 9 deletions(-) diff --git a/apis/v1alpha3/backendtlspolicy_types.go b/apis/v1alpha3/backendtlspolicy_types.go index dd52d5d165..2896454a21 100644 --- a/apis/v1alpha3/backendtlspolicy_types.go +++ b/apis/v1alpha3/backendtlspolicy_types.go @@ -112,7 +112,7 @@ type BackendTLSPolicyValidation struct { // // If CACertificateRefs is empty or unspecified, then WellKnownCACertificates must be // specified. Only one of CACertificateRefs or WellKnownCACertificates may be specified, - // not both. If CACertifcateRefs is empty or unspecified, the configuration for + // not both. If CACertificateRefs is empty or unspecified, the configuration for // WellKnownCACertificates MUST be honored instead if supported by the implementation. // // References to a resource in a different namespace are invalid for the diff --git a/config/crd/experimental/gateway.networking.k8s.io_backendtlspolicies.yaml b/config/crd/experimental/gateway.networking.k8s.io_backendtlspolicies.yaml index bdf27aaaac..052c99680b 100644 --- a/config/crd/experimental/gateway.networking.k8s.io_backendtlspolicies.yaml +++ b/config/crd/experimental/gateway.networking.k8s.io_backendtlspolicies.yaml @@ -174,7 +174,7 @@ spec: If CACertificateRefs is empty or unspecified, then WellKnownCACertificates must be specified. Only one of CACertificateRefs or WellKnownCACertificates may be specified, - not both. If CACertifcateRefs is empty or unspecified, the configuration for + not both. If CACertificateRefs is empty or unspecified, the configuration for WellKnownCACertificates MUST be honored instead if supported by the implementation. References to a resource in a different namespace are invalid for the diff --git a/geps/gep-1897/index.md b/geps/gep-1897/index.md index 9562a085da..09f6195fa5 100644 --- a/geps/gep-1897/index.md +++ b/geps/gep-1897/index.md @@ -216,9 +216,9 @@ specified as ""). The use and definition of system certificates is implementati these certificates are obtained from the underlying operating system. CACertificateRefs contains one or more references to Kubernetes objects that contain PEM-encoded TLS certificates, which are used to establish a TLS handshake between the gateway and backend pod. References to a resource in a different namespace are invalid. -If ClientCertifcateRefs is unspecified, then WellKnownCACertificates must be set to "System" for a valid configuration. +If ClientCertificateRefs is unspecified, then WellKnownCACertificates must be set to "System" for a valid configuration. If WellKnownCACertificates is unspecified, then CACertificateRefs must be specified with at least one entry for a valid configuration. -If WellKnownCACertficates is set to "System" and there are no system trusted certificates or the implementation doesn't define system +If WellKnownCACertificates is set to "System" and there are no system trusted certificates or the implementation doesn't define system trusted certificates, then the associated TLS connection must fail. The `Hostname` field is required and is to be used to configure the SNI the Gateway should use to connect to the backend. diff --git a/pkg/generated/openapi/zz_generated.openapi.go b/pkg/generated/openapi/zz_generated.openapi.go index 57852ee696..5171a458c9 100644 --- a/pkg/generated/openapi/zz_generated.openapi.go +++ b/pkg/generated/openapi/zz_generated.openapi.go @@ -7017,7 +7017,7 @@ func schema_sigsk8sio_gateway_api_apis_v1alpha3_BackendTLSPolicyValidation(ref c Properties: map[string]spec.Schema{ "caCertificateRefs": { SchemaProps: spec.SchemaProps{ - Description: "CACertificateRefs contains one or more references to Kubernetes objects that contain a PEM-encoded TLS CA certificate bundle, which is used to validate a TLS handshake between the Gateway and backend Pod.\n\nIf CACertificateRefs is empty or unspecified, then WellKnownCACertificates must be specified. Only one of CACertificateRefs or WellKnownCACertificates may be specified, not both. If CACertifcateRefs is empty or unspecified, the configuration for WellKnownCACertificates MUST be honored instead if supported by the implementation.\n\nReferences to a resource in a different namespace are invalid for the moment, although we will revisit this in the future.\n\nA single CACertificateRef to a Kubernetes ConfigMap kind has \"Core\" support. Implementations MAY choose to support attaching multiple certificates to a backend, but this behavior is implementation-specific.\n\nSupport: Core - An optional single reference to a Kubernetes ConfigMap, with the CA certificate in a key named `ca.crt`.\n\nSupport: Implementation-specific (More than one reference, or other kinds of resources).", + Description: "CACertificateRefs contains one or more references to Kubernetes objects that contain a PEM-encoded TLS CA certificate bundle, which is used to validate a TLS handshake between the Gateway and backend Pod.\n\nIf CACertificateRefs is empty or unspecified, then WellKnownCACertificates must be specified. Only one of CACertificateRefs or WellKnownCACertificates may be specified, not both. If CACertificateRefs is empty or unspecified, the configuration for WellKnownCACertificates MUST be honored instead if supported by the implementation.\n\nReferences to a resource in a different namespace are invalid for the moment, although we will revisit this in the future.\n\nA single CACertificateRef to a Kubernetes ConfigMap kind has \"Core\" support. Implementations MAY choose to support attaching multiple certificates to a backend, but this behavior is implementation-specific.\n\nSupport: Core - An optional single reference to a Kubernetes ConfigMap, with the CA certificate in a key named `ca.crt`.\n\nSupport: Implementation-specific (More than one reference, or other kinds of resources).", Type: []string{"array"}, Items: &spec.SchemaOrArray{ Schema: &spec.Schema{ diff --git a/site-src/api-types/backendtlspolicy.md b/site-src/api-types/backendtlspolicy.md index 7a2e568388..617ff1f865 100644 --- a/site-src/api-types/backendtlspolicy.md +++ b/site-src/api-types/backendtlspolicy.md @@ -37,10 +37,10 @@ The specification of a [BackendTLSPolicy][backendtlspolicy] consists of: WellKnownCACertificates. - [Hostname][hostname] - Defines the Server Name Indication (SNI) that the Gateway uses to connect to the backend. - [CACertificateRefs][caCertificateRefs] - Defines one or more references to objects that contain PEM-encoded TLS certificates, -which are used to establish a TLS handshake between the Gateway and backend Pod. Either CACertficateRefs or +which are used to establish a TLS handshake between the Gateway and backend Pod. Either CACertificateRefs or WellKnownCACertificates may be specified, but not both. - [WellKnownCACertificates][wellKnownCACertificates] - Specifies whether system CA certificates may be used in the TLS -handshake between the Gateway and backend Pod. Either CACertficateRefs or WellKnownCACertificates may be specified, but not both. +handshake between the Gateway and backend Pod. Either CACertificateRefs or WellKnownCACertificates may be specified, but not both. The following chart outlines the object definitions and relationship: ```mermaid @@ -57,7 +57,7 @@ flowchart LR spec -->targetRefs & validation status -->ancestorStatus targetRefs -->service - note[choose only one
caCerticateRefs OR wellKnownCACertificates] + note[choose only one
caCertificateRefs OR wellKnownCACertificates] style note fill:#fff validation -.- note ``` @@ -117,7 +117,7 @@ The BackendTLSPolicyValidation must contain a certificate reference of some kind certificate to use for backend TLS, CACertificateRefs and WellKnownCACertificates. Only one of these may be used per BackendTLSPolicyValidation. -##### CACertficateRefs +##### CACertificateRefs CACertificateRefs refer to one or more PEM-encoded TLS certificates. From 53b7de7572a7dc905940626a5ce6cab909ac2cdf Mon Sep 17 00:00:00 2001 From: Josh Soref <2119212+jsoref@users.noreply.github.com> Date: Fri, 18 Oct 2024 02:59:03 -0400 Subject: [PATCH 10/59] spelling: certificates Signed-off-by: Josh Soref <2119212+jsoref@users.noreply.github.com> --- geps/gep-91/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/geps/gep-91/index.md b/geps/gep-91/index.md index 5999bf9a9b..fd53abc411 100644 --- a/geps/gep-91/index.md +++ b/geps/gep-91/index.md @@ -151,7 +151,7 @@ spec: This section highlights use cases that may be covered in a future iteration of this GEP * Using system CA certificates as the trust anchor to validate the certificates presented by the frontend client. -* Supporting a mode where validating client certficates is optional, useful for debugging and migrating to strict TLS. +* Supporting a mode where validating client certificates is optional, useful for debugging and migrating to strict TLS. * Supporting an optional `subjectAltNames` field within `FrontendTLSValidation` that can be used to specify one or more alternate names to verify the subject identity in the certificate presented by the client. This field falls under Authorization, the initial focus here is on Client Authentication and will be revisited when Authorization is tackled as a whole in the project. * Specifying the verification depth in the client certificate chain. This is being deferred because the default verification depth differs across implementations. From ae864981b767b18fa97d3abf4ddeefc05e9a1dc4 Mon Sep 17 00:00:00 2001 From: Josh Soref <2119212+jsoref@users.noreply.github.com> Date: Fri, 18 Oct 2024 03:02:03 -0400 Subject: [PATCH 11/59] spelling: criteria Signed-off-by: Josh Soref <2119212+jsoref@users.noreply.github.com> --- geps/gep-820/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/geps/gep-820/index.md b/geps/gep-820/index.md index e683060ed8..78b92a9424 100644 --- a/geps/gep-820/index.md +++ b/geps/gep-820/index.md @@ -52,7 +52,7 @@ The following fields and all associated documentation will be removed: - HTTPRouteMatch.ExtensionRef - TCPRouteMatch.ExtensionRef will be removed. This results in a struct without any members: TCPRouteMatch. The struct will be kept as it is expected that - more match criterias might be added to L4 routes. + more match criteria might be added to L4 routes. - Do the same to UDPRoute and TLSRoute From 21350bdb4b4b01d2f197e2df096375ea34b1387c Mon Sep 17 00:00:00 2001 From: Josh Soref <2119212+jsoref@users.noreply.github.com> Date: Fri, 18 Oct 2024 03:02:32 -0400 Subject: [PATCH 12/59] spelling: deterministically Signed-off-by: Josh Soref <2119212+jsoref@users.noreply.github.com> --- geps/gep-1619/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/geps/gep-1619/index.md b/geps/gep-1619/index.md index 389d0a72cf..12316812e7 100644 --- a/geps/gep-1619/index.md +++ b/geps/gep-1619/index.md @@ -978,7 +978,7 @@ spec: This is an invalid configuration as two separate sessions cannot have the same cookie name. Implementations SHOULD address this scenario in manner they deem appropriate. Implementations MAY choose to reject the configuration, or they -MAY non-deterministicly allow one cookie to work (e.g. whichever cookie is configured first). +MAY non-deterministically allow one cookie to work (e.g. whichever cookie is configured first). #### Traffic Splitting with route rule inline sessionPersistence field From 6cf5642740996d849ce0be7a83d3001ce5c42410 Mon Sep 17 00:00:00 2001 From: Josh Soref <2119212+jsoref@users.noreply.github.com> Date: Fri, 18 Oct 2024 03:02:45 -0400 Subject: [PATCH 13/59] spelling: discoverability Signed-off-by: Josh Soref <2119212+jsoref@users.noreply.github.com> --- geps/gep-713/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/geps/gep-713/index.md b/geps/gep-713/index.md index b6dfa8366c..ed0575b3ff 100644 --- a/geps/gep-713/index.md +++ b/geps/gep-713/index.md @@ -555,7 +555,7 @@ that _every_ Policy update does not require a status update. Because Policy Attachment is a pattern for APIs, not an API, and needs to address all the problems above, the strategy this GEP proposes is to define a range of -options for increasing the discoverabilty of Policy resources, and provide +options for increasing the discoverability of Policy resources, and provide guidelines for when they should be used. It's likely that at some stage, the Gateway API CRDs will include some Policy From 36dc69616825c0b3309aa0a6d037878c7892e79e Mon Sep 17 00:00:00 2001 From: Josh Soref <2119212+jsoref@users.noreply.github.com> Date: Fri, 18 Oct 2024 03:03:09 -0400 Subject: [PATCH 14/59] spelling: docs Signed-off-by: Josh Soref <2119212+jsoref@users.noreply.github.com> --- site-src/implementations.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/site-src/implementations.md b/site-src/implementations.md index 778391d298..85e2dfac38 100644 --- a/site-src/implementations.md +++ b/site-src/implementations.md @@ -330,12 +330,12 @@ HAProxy Kubernetes Ingress Controller is an open-source project maintained by HA [Consul][consul], by [HashiCorp][hashicorp], is an open source control plane for multi-cloud networking. A single Consul deployment can span bare metal, VM and container environments. -Consul service mesh works on any Kubernetes distribution, connects multiple clusters, and Consul CRDs provide a Kubernetes native workflow to manage traffic patterns and permissions in the mesh. [Consul API Gateway][consul-api-gw-doocs] supports Gateway API for managing North-South traffic. +Consul service mesh works on any Kubernetes distribution, connects multiple clusters, and Consul CRDs provide a Kubernetes native workflow to manage traffic patterns and permissions in the mesh. [Consul API Gateway][consul-api-gw-docs] supports Gateway API for managing North-South traffic. -Please see the [Consul API Gateway documentation][consul-api-gw-doocs] for current information on the supported version and features of the Gateway API. +Please see the [Consul API Gateway documentation][consul-api-gw-docs] for current information on the supported version and features of the Gateway API. [consul]:https://consul.io -[consul-api-gw-doocs]:https://www.consul.io/docs/api-gateway +[consul-api-gw-docs]:https://www.consul.io/docs/api-gateway [hashicorp]:https://www.hashicorp.com ### Istio From 7c7f8f5c938fc615c74e9ecb5d498eb3a678b67f Mon Sep 17 00:00:00 2001 From: Josh Soref <2119212+jsoref@users.noreply.github.com> Date: Fri, 18 Oct 2024 03:04:09 -0400 Subject: [PATCH 15/59] spelling: encapsulated Signed-off-by: Josh Soref <2119212+jsoref@users.noreply.github.com> --- geps/gep-1016/index.md | 2 +- site-src/api-types/grpcroute.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/geps/gep-1016/index.md b/geps/gep-1016/index.md index afd96ef57d..8ce35205c0 100644 --- a/geps/gep-1016/index.md +++ b/geps/gep-1016/index.md @@ -50,7 +50,7 @@ lower layer protocol already exists. We propose the following criteria for such an addition. - Users of the encapsulated protocol would miss out on significant conventional features from their ecosystem if forced to route at a lower layer. -- Users of the enapsulated protocol would experience a degraded user experience if forced to route at a lower layer. +- Users of the encapsulated protocol would experience a degraded user experience if forced to route at a lower layer. - The encapsulated protocol has a significant user base, particularly in the Kubernetes community. gRPC meets _all_ of these criteria and is therefore, we contend, a strong diff --git a/site-src/api-types/grpcroute.md b/site-src/api-types/grpcroute.md index 560d7fe2ef..4e528bf783 100644 --- a/site-src/api-types/grpcroute.md +++ b/site-src/api-types/grpcroute.md @@ -33,7 +33,7 @@ level, it is acceptable to introduce a route resource at the higher layer when the following criteria are met: - Users of the encapsulated protocol would miss out on significant conventional features from their ecosystem if forced to route at a lower layer. -- Users of the enapsulated protocol would experience a degraded user experience if forced to route at a lower layer. +- Users of the encapsulated protocol would experience a degraded user experience if forced to route at a lower layer. - The encapsulated protocol has a significant user base, particularly in the Kubernetes community. gRPC meets all of these criteria, so the decision was made to include `GRPCRoute`in Gateway API. From 648a33dcdfe7724117546c13d9c43abc55facf4a Mon Sep 17 00:00:00 2001 From: Josh Soref <2119212+jsoref@users.noreply.github.com> Date: Mon, 21 Oct 2024 11:22:26 -0400 Subject: [PATCH 16/59] spelling: feature Signed-off-by: Josh Soref <2119212+jsoref@users.noreply.github.com> --- conformance/utils/suite/suite_test.go | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/conformance/utils/suite/suite_test.go b/conformance/utils/suite/suite_test.go index 639fc6ca2a..951571f7aa 100644 --- a/conformance/utils/suite/suite_test.go +++ b/conformance/utils/suite/suite_test.go @@ -181,7 +181,7 @@ func TestGetAPIVersionAndChannel(t *testing.T) { } const ( - coreFeature features.FeatureName = "coreFature" + coreFeature features.FeatureName = "coreFeature" extendedFeature features.FeatureName = "extendedFeature" testProfileName ConformanceProfileName = "testProfile" From d0628d23c19059f9e1a330503683a8567736ec34 Mon Sep 17 00:00:00 2001 From: Josh Soref <2119212+jsoref@users.noreply.github.com> Date: Fri, 18 Oct 2024 03:04:49 -0400 Subject: [PATCH 17/59] spelling: filesystem Signed-off-by: Josh Soref <2119212+jsoref@users.noreply.github.com> --- site-src/guides/grpc-routing.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/site-src/guides/grpc-routing.md b/site-src/guides/grpc-routing.md index acba8f1105..a0740e6e4a 100644 --- a/site-src/guides/grpc-routing.md +++ b/site-src/guides/grpc-routing.md @@ -69,7 +69,7 @@ missing or does not have the value `canary` then it will be forwarded to `bar-sv Reflection](https://github.com/grpc/grpc/blob/v1.49.1/doc/server-reflection.md) is required to use interactive clients such as [`grpcurl`](https://github.com/fullstorydev/grpcurl) without having a local copy -of the target service's protocol buffers present on your local filesysem. To +of the target service's protocol buffers present on your local filesystem. To enable this, first ensure that you have a gRPC reflection server listening on your application pods, then add the reflection method to your `GRPCRoute`. This is likely to be useful in development and staging environments, but this should From 7125b6806dd19d357cde661532b403f8c7e87b65 Mon Sep 17 00:00:00 2001 From: Josh Soref <2119212+jsoref@users.noreply.github.com> Date: Fri, 18 Oct 2024 03:05:08 -0400 Subject: [PATCH 18/59] spelling: format Signed-off-by: Josh Soref <2119212+jsoref@users.noreply.github.com> --- geps/gep-1731/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/geps/gep-1731/index.md b/geps/gep-1731/index.md index f7785e13d5..0eedeb3ddf 100644 --- a/geps/gep-1731/index.md +++ b/geps/gep-1731/index.md @@ -354,7 +354,7 @@ type HTTPRouteRetry struct { // +kubebuilder:validation:Maximum:=999 type HTTPRouteRetryStatusCode int -// Duration is a string value representing a duration in time. The foramat is +// Duration is a string value representing a duration in time. The format is // as specified in GEP-2257, a strict subset of the syntax parsed by Golang // time.ParseDuration. // From e06c33a54c75e5e8f131ba015fc795ae76d89754 Mon Sep 17 00:00:00 2001 From: Josh Soref <2119212+jsoref@users.noreply.github.com> Date: Fri, 18 Oct 2024 03:43:28 -0400 Subject: [PATCH 19/59] spelling: frankbu Signed-off-by: Josh Soref <2119212+jsoref@users.noreply.github.com> --- geps/gep-1762/metadata.yaml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/geps/gep-1762/metadata.yaml b/geps/gep-1762/metadata.yaml index c38ad6a101..2f5677ef7d 100644 --- a/geps/gep-1762/metadata.yaml +++ b/geps/gep-1762/metadata.yaml @@ -5,7 +5,7 @@ name: In Cluster Gateway Deployments status: Standard authors: - howardjohn - - frakbu + - frankbu relationships: extendedBy: - number: 1867 From 0663ab4e0b1ba8bb55c2a986ed77304935d87fc0 Mon Sep 17 00:00:00 2001 From: Josh Soref <2119212+jsoref@users.noreply.github.com> Date: Wed, 16 Oct 2024 14:10:21 -0400 Subject: [PATCH 20/59] spelling: github Signed-off-by: Josh Soref <2119212+jsoref@users.noreply.github.com> --- conformance/apis/v1/conformancereport.go | 4 ++-- conformance/reports/README.md | 2 +- geps/gep-1709/index.md | 4 ++-- geps/gep-1731/metadata.yaml | 4 ++-- geps/gep-2648/metadata.yaml | 4 ++-- geps/gep-2649/metadata.yaml | 2 +- geps/gep-2659/index.md | 2 +- geps/gep-696/metadata.yaml | 4 ++-- pkg/gep/gepdetail.go | 2 +- site-src/contributing/enhancement-requests.md | 2 +- site-src/faq.md | 4 ++-- site-src/guides/implementers.md | 2 +- 12 files changed, 18 insertions(+), 18 deletions(-) diff --git a/conformance/apis/v1/conformancereport.go b/conformance/apis/v1/conformancereport.go index 9eb23704fd..7f4f4d5325 100644 --- a/conformance/apis/v1/conformancereport.go +++ b/conformance/apis/v1/conformancereport.go @@ -76,10 +76,10 @@ type Implementation struct { // Contact is contact information for the maintainers so that Gateway API // maintainers can get ahold of them as needed. Ideally this should be - // Github usernames (in the form of `@`) or team names (in the + // GitHub usernames (in the form of `@`) or team names (in the // form of `@/`), but when that's not possible it can be email // addresses. - // Rather than Github usernames or email addresses you can provide a URL to the relevant + // Rather than GitHub usernames or email addresses you can provide a URL to the relevant // support pages for the project. Ideally this would be something like the issue creation page // on a repository, but for projects without a publicly exposed repository a general support // page URL can be provided. diff --git a/conformance/reports/README.md b/conformance/reports/README.md index 98e8ffc34a..241ffc9d66 100644 --- a/conformance/reports/README.md +++ b/conformance/reports/README.md @@ -110,7 +110,7 @@ comply with the following rules: - `contact`: it indicates the GitHub usernames of those who are responsible for maintaining this file, so they can be easily contacted when needed (e.g. for relevant release announcements regarding conformance, etc.). Optionally, it - can be an email address or a support URL (e.g. Github new issue page). + can be an email address or a support URL (e.g. GitHub new issue page). - `url`: it must be a valid url for a GitHub repository, or any other website with information related to the project. - `version`: it must be a snapshot of the project, which means it can be a commit, diff --git a/geps/gep-1709/index.md b/geps/gep-1709/index.md index 102a00b2ae..9914da2549 100644 --- a/geps/gep-1709/index.md +++ b/geps/gep-1709/index.md @@ -368,11 +368,11 @@ profiles: > theoretically have multiple projects and should submit separate reports for > each of them. -> **NOTE**: The `contact` field indicates the Github usernames or team +> **NOTE**: The `contact` field indicates the GitHub usernames or team > names of those who are responsible for maintaining this file, so they can be > easily contacted when needed (e.g. for relevant release announcements > regarding conformance, e.t.c.). Optionally, it can be an email address or -> a support URL (e.g. Github new issue page). +> a support URL (e.g. GitHub new issue page). The above report describes an implementation that just released `v1`, uses gateway API `v0.8.0` `experimental` channel, and has `HTTP` `core` and `extended` and `TCP` diff --git a/geps/gep-1731/metadata.yaml b/geps/gep-1731/metadata.yaml index 2bb398026b..d0650085b0 100644 --- a/geps/gep-1731/metadata.yaml +++ b/geps/gep-1731/metadata.yaml @@ -4,7 +4,7 @@ number: 1731 name: HTTPRoute Retries status: Experimental # Any authors who contribute to the GEP in any way should be listed here using -# their Github handle. +# their GitHub handle. authors: - mikemorris relationships: @@ -30,7 +30,7 @@ relationships: name: HTTPRoute Timeouts description: Covers some overlapping considerations around when requests should be retried. # references is a list of hyperlinks to relevant external references. -# It's intended to be used for storing Github discussions, Google docs, etc. +# It's intended to be used for storing GitHub discussions, Google docs, etc. references: - https://www.rfc-editor.org/rfc/rfc9110 - https://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml diff --git a/geps/gep-2648/metadata.yaml b/geps/gep-2648/metadata.yaml index fe9fe84336..7e9b54a867 100644 --- a/geps/gep-2648/metadata.yaml +++ b/geps/gep-2648/metadata.yaml @@ -4,7 +4,7 @@ number: 2648 name: Direct Policy Attachment status: Provisional # Any authors who contribute to the GEP in any way should be listed here using -# their Github handle. +# their GitHub handle. authors: - youngnick - robscott @@ -14,7 +14,7 @@ relationships: number: 713 description: Split out Direct Policy Attachment into its own GEP # references is a list of hyperlinks to relevant external references. -# It's intended to be used for storing Github discussions, Google docs, etc. +# It's intended to be used for storing GitHub discussions, Google docs, etc. references: - "https://github.com/kubernetes-sigs/gateway-api/discussions/2927" # changelog is a list of hyperlinks to PRs that make changes to the GEP, in diff --git a/geps/gep-2649/metadata.yaml b/geps/gep-2649/metadata.yaml index b6eda3b455..403a0c72ec 100644 --- a/geps/gep-2649/metadata.yaml +++ b/geps/gep-2649/metadata.yaml @@ -12,7 +12,7 @@ relationships: number: 713 description: Split out Inherited Policy Attachment # references is a list of hyperlinks to relevant external references. -# It's intended to be used for storing Github discussions, Google docs, etc. +# It's intended to be used for storing GitHub discussions, Google docs, etc. references: - "https://github.com/kubernetes-sigs/gateway-api/discussions/2927" # changelog is a list of hyperlinks to PRs that make changes to the GEP, in diff --git a/geps/gep-2659/index.md b/geps/gep-2659/index.md index b2838a7caf..57fbd19890 100644 --- a/geps/gep-2659/index.md +++ b/geps/gep-2659/index.md @@ -127,7 +127,7 @@ relationships: # covered by an existing relationship. seeAlso: {} # references is a list of hyperlinks to relevant external references. -# It's intended to be used for storing Github discussions, Google docs, etc. +# It's intended to be used for storing GitHub discussions, Google docs, etc. references: {} # featureNames is a list of the feature names introduced by the GEP, if there # are any. This will allow us to track which feature was introduced by which GEP. diff --git a/geps/gep-696/metadata.yaml b/geps/gep-696/metadata.yaml index efcc0d2f03..6bc1cfeb5a 100644 --- a/geps/gep-696/metadata.yaml +++ b/geps/gep-696/metadata.yaml @@ -4,7 +4,7 @@ number: 696 name: GEP template status: Completed # Any authors who contribute to the GEP in any way should be listed here using -# their Github handle. +# their GitHub handle. authors: - bowei - robscott @@ -25,7 +25,7 @@ relationships: # covered by an existing relationship. seeAlso: {} # references is a list of hyperlinks to relevant external references. -# It's intended to be used for storing Github discussions, Google docs, etc. +# It's intended to be used for storing GitHub discussions, Google docs, etc. references: {} # featureNames is a list of the feature names introduced by the GEP, if there # are any. This will allow us to track which feature was introduced by which GEP. diff --git a/pkg/gep/gepdetail.go b/pkg/gep/gepdetail.go index dd79302971..a8c2d1c714 100644 --- a/pkg/gep/gepdetail.go +++ b/pkg/gep/gepdetail.go @@ -56,7 +56,7 @@ type GEPDetail struct { // Valid values are provided in the constants for the GEPStatus type. Status GEPStatus `json:"status"` - // The GEP's authors, listed as their Github handles. + // The GEP's authors, listed as their GitHub handles. Authors []string `json:"authors"` // Relationships describes the possible relationships between this GEP and diff --git a/site-src/contributing/enhancement-requests.md b/site-src/contributing/enhancement-requests.md index de693a5e14..6244e8c788 100644 --- a/site-src/contributing/enhancement-requests.md +++ b/site-src/contributing/enhancement-requests.md @@ -41,7 +41,7 @@ request for enhancement if that enhancement is non-trivial (which we will define as either: _implicates changes to the API specification_ OR _has some kind of end-user impact_). -Please use our [Github Discussions][discussion] forum as the initial place to +Please use our [GitHub Discussions][discussion] forum as the initial place to start, and feel free to bring that discussion up for synchronous conversation in one of our [community meetings][meetings]. If the created request doesn't include reference to a discussion and/or recordings of discussion in our diff --git a/site-src/faq.md b/site-src/faq.md index fa8b72a27e..4610d7d962 100644 --- a/site-src/faq.md +++ b/site-src/faq.md @@ -41,8 +41,8 @@ using an explicit object reference. to use. #### Where can I find Gateway API releases? -Gateway API releases are tags of the [Github -repository](https://github.com/kubernetes-sigs/gateway-api). The [Github +Gateway API releases are tags of the [GitHub +repository](https://github.com/kubernetes-sigs/gateway-api). The [GitHub releases](https://github.com/kubernetes-sigs/gateway-api/releases) page shows all the releases. diff --git a/site-src/guides/implementers.md b/site-src/guides/implementers.md index eed5e62ead..1c82a8eeaf 100644 --- a/site-src/guides/implementers.md +++ b/site-src/guides/implementers.md @@ -101,7 +101,7 @@ Gateway API conformance is version-specific. An implementation that passes conformance for version N may not pass conformance for version N+1 without changes. Implementations SHOULD submit a report from the conformance testing suite back -to the Gateway API Github repo containing details of their testing. +to the Gateway API GitHub repo containing details of their testing. The conformance suite output includes the Gateway API version supported. From 5cd8aeca272a107e5347bebd597e16fddad055ba Mon Sep 17 00:00:00 2001 From: Josh Soref <2119212+jsoref@users.noreply.github.com> Date: Mon, 21 Oct 2024 11:25:04 -0400 Subject: [PATCH 21/59] spelling: grpc Signed-off-by: Josh Soref <2119212+jsoref@users.noreply.github.com> --- geps/gep-1911/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/geps/gep-1911/index.md b/geps/gep-1911/index.md index ed25229444..cdcd8a2803 100644 --- a/geps/gep-1911/index.md +++ b/geps/gep-1911/index.md @@ -116,7 +116,7 @@ This was dropped in favour of supporting Kubernetes Standard Application Protoco ### Multiple Protocol Meta-resources Rather than bundle protocol details into a single resource an alternative would be to create distinct meta resources. -ie. `HTTP2Backend`, `GPRCBackend`, `WebsocketBackend`. +ie. `HTTP2Backend`, `GRPCBackend`, `WebsocketBackend`. The advantages of this approach are: From 181bae352994a181994f9bd1755c0be738ee2d98 Mon Sep 17 00:00:00 2001 From: Josh Soref <2119212+jsoref@users.noreply.github.com> Date: Fri, 18 Oct 2024 03:45:04 -0400 Subject: [PATCH 22/59] spelling: grpcroute Signed-off-by: Josh Soref <2119212+jsoref@users.noreply.github.com> --- site-src/api-types/grpcroute.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/site-src/api-types/grpcroute.md b/site-src/api-types/grpcroute.md index 4e528bf783..d18ce92398 100644 --- a/site-src/api-types/grpcroute.md +++ b/site-src/api-types/grpcroute.md @@ -272,7 +272,7 @@ Multiple GRPCRoutes can be attached to a single Gateway resource. Importantly, only one Route rule may match each request. For more information on how conflict resolution applies to merging, refer to the [API specification][grpcrouterule]. -[grpcroute]: /reference/spec/#gateway.networking.k8s.io/v1.GRPCPRoute +[grpcroute]: /reference/spec/#gateway.networking.k8s.io/v1.GRPCRoute [grpcrouterule]: /reference/spec/#gateway.networking.k8s.io/v1.GRPCRouteRule [hostname]: /reference/spec/#gateway.networking.k8s.io/v1.Hostname [rfc-3986]: https://tools.ietf.org/html/rfc3986 From d1e528a23568d7de902855e1f5be409237fcdd50 Mon Sep 17 00:00:00 2001 From: Josh Soref <2119212+jsoref@users.noreply.github.com> Date: Wed, 16 Oct 2024 14:08:23 -0400 Subject: [PATCH 23/59] spelling: has Signed-off-by: Josh Soref <2119212+jsoref@users.noreply.github.com> --- site-src/blog/2023/0829-mesh-support.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/site-src/blog/2023/0829-mesh-support.md b/site-src/blog/2023/0829-mesh-support.md index 3b8b7741ae..14b5f101de 100644 --- a/site-src/blog/2023/0829-mesh-support.md +++ b/site-src/blog/2023/0829-mesh-support.md @@ -1,7 +1,7 @@ --- description: > We are excited to announce the v0.8.0 release of Gateway API, where service - mesh support has has now reached Experimental status, we've introduced CEL + mesh support has now reached Experimental status, we've introduced CEL validation and a Mesh conformance profile, and more! --- From c2a9a1869fc8d953544cf1e236731ff4e79c8139 Mon Sep 17 00:00:00 2001 From: Josh Soref <2119212+jsoref@users.noreply.github.com> Date: Mon, 21 Oct 2024 11:27:24 -0400 Subject: [PATCH 24/59] spelling: have Signed-off-by: Josh Soref <2119212+jsoref@users.noreply.github.com> --- CHANGELOG/0.x-CHANGELOG.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/CHANGELOG/0.x-CHANGELOG.md b/CHANGELOG/0.x-CHANGELOG.md index f8432fca88..e5f80df856 100644 --- a/CHANGELOG/0.x-CHANGELOG.md +++ b/CHANGELOG/0.x-CHANGELOG.md @@ -1089,7 +1089,7 @@ In this release, we've made two release channels available, `experimental` and `standard`. The `experimental` channel contains all resources and fields, while `standard` -contains only resources that mave moved to beta status. +contains only resources that have moved to beta status. We've also added a way to flag particular fields within a resource as experimental, and any fields marked in this way are only present in the @@ -1274,7 +1274,7 @@ In this release, we've made two release channels available, `experimental` and `standard`. The `experimental` channel contains all resources and fields, while `standard` -contains only resources that mave moved to beta status. +contains only resources that have moved to beta status. We've also added a way to flag particular fields within a resource as experimental, and any fields marked in this way are only present in the From 24733cad4c66308d368af65343feaebe031140b0 Mon Sep 17 00:00:00 2001 From: Josh Soref <2119212+jsoref@users.noreply.github.com> Date: Fri, 18 Oct 2024 03:46:57 -0400 Subject: [PATCH 25/59] spelling: http-route Signed-off-by: Josh Soref <2119212+jsoref@users.noreply.github.com> --- geps/gep-1731/index.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/geps/gep-1731/index.md b/geps/gep-1731/index.md index 0eedeb3ddf..91231cdc35 100644 --- a/geps/gep-1731/index.md +++ b/geps/gep-1731/index.md @@ -391,21 +391,21 @@ Basic support for configuring retries in HTTPRoute up to a specified maximum cou Retrying requests based on HTTP status codes will be gated under the following features: -* `SupportHTTPRRouteRetryBackendTimeout` +* `SupportHTTPRouteRetryBackendTimeout` * Will test that backend requests that exceed a BackendRequest timeout duration are retried if a `retry` stanza is configured. -* `SupportHTTPRRouteRetryBackoff` +* `SupportHTTPRouteRetryBackoff` * Backoff will only be tested that a retry does not start before the duration specified for conformance, not that the backoff duration is precise. * Not currently supportable by NGINX or HAProxy. -* `SupportHTTPRRouteRetryCodes` +* `SupportHTTPRouteRetryCodes` * Only 500, 502, 503 and 504 will be tested for conformance. * Traefik does not seem to support specifying error codes, and will only retry on backend timeouts. -* `SupportHTTPRRouteRetryConnectionError` +* `SupportHTTPRouteRetryConnectionError` * Will test that connections interrupted by a TCP failure, disconnect or reset are retried if a `retry` stanza is configured. From 283c335e32da2c5e002600525af8138c5e4cb440 Mon Sep 17 00:00:00 2001 From: Josh Soref <2119212+jsoref@users.noreply.github.com> Date: Fri, 18 Oct 2024 03:45:58 -0400 Subject: [PATCH 26/59] spelling: httpproxy Signed-off-by: Josh Soref <2119212+jsoref@users.noreply.github.com> --- geps/gep-1282/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/geps/gep-1282/index.md b/geps/gep-1282/index.md index c8a54f74a1..dead0babfa 100644 --- a/geps/gep-1282/index.md +++ b/geps/gep-1282/index.md @@ -53,7 +53,7 @@ We've got the following feature requests and discussions in the Gateway API repo - [#1285](https://github.com/kubernetes-sigs/gateway-api/discussions/1285) has a more specific discussion about how different ingress implementations allow this to be configured today, whether that's with the Ingress resource or their own custom one. The great roundup that Candace did is reproduced in the next few bullet points. * Istio uses a [DestinationRule resource with ClientTLSSettings](https://istio.io/latest/docs/reference/config/networking/destination-rule/#ClientTLSSettings) to capture TLS details, and the DestinationRule resource also holds traffic policy information like load balancing algorithm, connection pool size, and so on. * Openshift’s Route resource allows the [configuration of reencryption](https://docs.openshift.com/container-platform/4.10/networking/routes/secured-routes.html#nw-ingress-creating-a-reencrypt-route-with-a-custom-certificate_secured-routes) specifically, along with custom certificate details. - * Contour’s HTTPProxy captures TLS details using an Envoy client certificate, destination CA certificate, and optional SubjectName which sets what Envoy should expect to see from the backend service, all inside the HTTPProxy resource. It also requires either a Protocol field inside the HTTProxy, or an annotation on the Service that tells Contour that the service expects TLS. This is [all documented](https://projectcontour.io/docs/v1.21.1/config/upstream-tls/), but I should note that Contour’s docs use the Envoy convention where a backend in Gateway parlance is called an Upstream (which may be confusing if you’re not used to it). + * Contour’s HTTPProxy captures TLS details using an Envoy client certificate, destination CA certificate, and optional SubjectName which sets what Envoy should expect to see from the backend service, all inside the HTTPProxy resource. It also requires either a Protocol field inside the HTTPProxy, or an annotation on the Service that tells Contour that the service expects TLS. This is [all documented](https://projectcontour.io/docs/v1.21.1/config/upstream-tls/), but I should note that Contour’s docs use the Envoy convention where a backend in Gateway parlance is called an Upstream (which may be confusing if you’re not used to it). * Linkerd uses a [Server resource](https://linkerd.io/2.11/reference/authorization-policy/#server) (which is functionally pretty similar to Service in that it associates a name with a Pod selector, but also has other details like if the service supports Proxy protocol), along with a ServerAuthorization resource that specifies some constructs that sit more at the service mesh level, including identity and access control. In terms of other implementations existing use cases for features like this: From 5cf1e0dca68b9698cc1a3d49883b80ac11043922 Mon Sep 17 00:00:00 2001 From: Josh Soref <2119212+jsoref@users.noreply.github.com> Date: Mon, 21 Oct 2024 11:37:48 -0400 Subject: [PATCH 27/59] spelling: httpredirect Signed-off-by: Josh Soref <2119212+jsoref@users.noreply.github.com> --- ...tredirect-hostname.yaml => invalid-httpredirect-hostname.yaml} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename hack/invalid-examples/standard/httproute/{invalid-httredirect-hostname.yaml => invalid-httpredirect-hostname.yaml} (100%) diff --git a/hack/invalid-examples/standard/httproute/invalid-httredirect-hostname.yaml b/hack/invalid-examples/standard/httproute/invalid-httpredirect-hostname.yaml similarity index 100% rename from hack/invalid-examples/standard/httproute/invalid-httredirect-hostname.yaml rename to hack/invalid-examples/standard/httproute/invalid-httpredirect-hostname.yaml From d62a78f1a1763e2ad2cabab92294cdcc13eec60a Mon Sep 17 00:00:00 2001 From: Josh Soref <2119212+jsoref@users.noreply.github.com> Date: Fri, 18 Oct 2024 03:07:39 -0400 Subject: [PATCH 28/59] spelling: https Signed-off-by: Josh Soref <2119212+jsoref@users.noreply.github.com> --- conformance/echo-basic/grpc/grpc.go | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/conformance/echo-basic/grpc/grpc.go b/conformance/echo-basic/grpc/grpc.go index ffb55189b9..e2f1b88ab8 100644 --- a/conformance/echo-basic/grpc/grpc.go +++ b/conformance/echo-basic/grpc/grpc.go @@ -55,7 +55,7 @@ type serverConfig struct { // Controlled by TLS_SERVER_PRIVKEY env var TLSServerPrivKey string - // Controlled by HTPPS_PORT env var + // Controlled by HTTPS_PORT env var HTTPSPort int } From c72d09fdddeebcd92a646cdab36fc521213cd352 Mon Sep 17 00:00:00 2001 From: Josh Soref <2119212+jsoref@users.noreply.github.com> Date: Fri, 18 Oct 2024 03:47:14 -0400 Subject: [PATCH 29/59] spelling: implementation Signed-off-by: Josh Soref <2119212+jsoref@users.noreply.github.com> --- RELEASE.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/RELEASE.md b/RELEASE.md index 307f33f519..d72758367e 100644 --- a/RELEASE.md +++ b/RELEASE.md @@ -70,7 +70,7 @@ The following steps must be done by one of the [Gateway API maintainers][gateway - Run the `make build-install-yaml` command which will generate install files in the `release/` directory. Attach these files to the GitHub release. - Update the `README.md` and `site-src/guides/index.md` files to point links and examples to the new release. -- Update the implementation table path (`nav.Implementations.Comparison`) in the nav of `mkdocs.yml` to point to the latest release file (for example Implementation Comparison points to `implmenetation-table-v1.2.0.md`). Add the now past version under `Past Version Comparisons`, and edit the text blurb in `mkdocs-generate-conformance.py` to also reflect the added past version. +- Update the implementation table path (`nav.Implementations.Comparison`) in the nav of `mkdocs.yml` to point to the latest release file (for example Implementation Comparison points to `implementation-table-v1.2.0.md`). Add the now past version under `Past Version Comparisons`, and edit the text blurb in `mkdocs-generate-conformance.py` to also reflect the added past version. #### For an **RC** release: - Update `pkg/consts/consts.go` with the new semver tag (like `v1.2.0-rc1`) and any updates to the API review URL. From 64cb0172d371f14b56be2342437b70e7a6bf13d3 Mon Sep 17 00:00:00 2001 From: Josh Soref <2119212+jsoref@users.noreply.github.com> Date: Fri, 18 Oct 2024 03:47:19 -0400 Subject: [PATCH 30/59] spelling: improvements Signed-off-by: Josh Soref <2119212+jsoref@users.noreply.github.com> --- CHANGELOG/1.2-TEAM.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CHANGELOG/1.2-TEAM.md b/CHANGELOG/1.2-TEAM.md index f52ba70025..ebd6283ded 100644 --- a/CHANGELOG/1.2-TEAM.md +++ b/CHANGELOG/1.2-TEAM.md @@ -7,7 +7,7 @@ | BackendProtocol Support | @dprotaso | | HTTPRoute Retries | @mikemorris | | Percentage-based request mirroring | @jakebennert | -| Backend TLS Config improvments | @mkosieradzki, @LiorLieberman | +| Backend TLS Config improvements | @mkosieradzki, @LiorLieberman | | Named Route Rules | @guicassolato, @howardjohn | | Conformance Profiles and Reports | @mlavacca, @shaneutt, @xtineskim | | Gateway API Maintainers | @mlavacca, @robscott, @shaneutt, @youngnick | From a8487f4de6cb44989b2a77b3660ca1a1fc7ebf94 Mon Sep 17 00:00:00 2001 From: Josh Soref <2119212+jsoref@users.noreply.github.com> Date: Wed, 16 Oct 2024 14:28:47 -0400 Subject: [PATCH 31/59] spelling: in Signed-off-by: Josh Soref <2119212+jsoref@users.noreply.github.com> --- geps/gep-724/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/geps/gep-724/index.md b/geps/gep-724/index.md index bb1e9854f9..5fdd108f8b 100644 --- a/geps/gep-724/index.md +++ b/geps/gep-724/index.md @@ -618,7 +618,7 @@ bar namespace. Unfortunately that would be very difficult to recreate with ReferenceGrant. ReferenceGrant is fundamentally about trusting references from resource of kind -Foo in to resources of kind Bar. Names and section names are intentionally +Foo in resources of kind Bar. Names and section names are intentionally excluded. If we added both of those concepts to ReferenceGrant, this would be possible, but quite complex and verbose. This is what the example from above would look like with this approach: From 15301d213edd069675b95338834e11d419441d49 Mon Sep 17 00:00:00 2001 From: Josh Soref <2119212+jsoref@users.noreply.github.com> Date: Mon, 21 Oct 2024 11:26:08 -0400 Subject: [PATCH 32/59] spelling: infrastructure Signed-off-by: Josh Soref <2119212+jsoref@users.noreply.github.com> --- pkg/features/gateway.go | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/pkg/features/gateway.go b/pkg/features/gateway.go index a90a32a4b3..7fc1a20db0 100644 --- a/pkg/features/gateway.go +++ b/pkg/features/gateway.go @@ -58,7 +58,7 @@ const ( SupportGatewayHTTPListenerIsolation FeatureName = "GatewayHTTPListenerIsolation" // SupportGatewayInfrastructureAnnotations option indicates support for - // spec.infrastructure.annotations and spec.infrastrucutre.labels + // spec.infrastructure.annotations and spec.infrastructure.labels SupportGatewayInfrastructurePropagation FeatureName = "GatewayInfrastructurePropagation" ) From 9323ae824b9fcf4804b2fff372e171d0f86c6025 Mon Sep 17 00:00:00 2001 From: Josh Soref <2119212+jsoref@users.noreply.github.com> Date: Wed, 16 Oct 2024 14:16:46 -0400 Subject: [PATCH 33/59] spelling: into Signed-off-by: Josh Soref <2119212+jsoref@users.noreply.github.com> --- geps/gep-1364/index.md | 2 +- geps/gep-1619/index.md | 2 +- geps/gep-713/index.md | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/geps/gep-1364/index.md b/geps/gep-1364/index.md index 5afa356347..0ff89c5007 100644 --- a/geps/gep-1364/index.md +++ b/geps/gep-1364/index.md @@ -418,7 +418,7 @@ For many implementations (certainly for Envoy-based ones), getting this informat correctly and avoiding races on applying it is surprisingly difficult. For this reason, this GEP proposes that we exclude the `Ready` condition from Core -conformance, and make it a feature that implementations may opt in to - making it +conformance, and make it a feature that implementations may opt into - making it an Extended condition. It will have the following behavior: diff --git a/geps/gep-1619/index.md b/geps/gep-1619/index.md index 12316812e7..a1e41138f2 100644 --- a/geps/gep-1619/index.md +++ b/geps/gep-1619/index.md @@ -1069,7 +1069,7 @@ TODO ### Open Questions - What happens when session persistence causes traffic splitting scenarios to overload a backend? -- Should we add status somewhere when a user gets in to a "risky" configuration with session persistence? +- Should we add status somewhere when a user gets into a "risky" configuration with session persistence? - Should there be an API configuration field that specifies how already established sessions are handled? - How do implementations drain established sessions during backend upgrades without disruption? - Do we need a "session draining timeout" as documented by [A55: xDS-Based Stateful Session Affinity for Proxyless gRPC](https://github.com/grpc/proposal/blob/master/A55-xds-stateful-session-affinity.md#background) diff --git a/geps/gep-713/index.md b/geps/gep-713/index.md index ed0575b3ff..768cfc50fc 100644 --- a/geps/gep-713/index.md +++ b/geps/gep-713/index.md @@ -789,7 +789,7 @@ This solution: - is low cost in terms of apiserver updates (because it's only on the GatewayClass, and only on implementation startup) - provides a standard place for all users to look for relevant objects -- ties in to the Conformance Profiles design and other efforts about GatewayClass +- ties into the Conformance Profiles design and other efforts about GatewayClass status #### Standard status stanza From cb67f66ae3040554d0aa41c303639f697bcbbb97 Mon Sep 17 00:00:00 2001 From: Josh Soref <2119212+jsoref@users.noreply.github.com> Date: Fri, 18 Oct 2024 03:47:24 -0400 Subject: [PATCH 34/59] spelling: intuitive Signed-off-by: Josh Soref <2119212+jsoref@users.noreply.github.com> --- geps/gep-957/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/geps/gep-957/index.md b/geps/gep-957/index.md index f4de43e304..577076a16d 100644 --- a/geps/gep-957/index.md +++ b/geps/gep-957/index.md @@ -120,7 +120,7 @@ spec: Port matching can be supported if SectionName accepts port numbers in addition to listener names. This approach results in a less explicit API when a ParentRef points to a resource that is not `Gateway`. For example, an implementation may -attach a route to an `Mesh` CRD. In this case, it's less inituitive to set +attach a route to an `Mesh` CRD. In this case, it's less intuitive to set `ParentRef.SectionName` to `443` to express `route all traffic whose destination port is 443 to ...`. It also complicates the validation on SectionName in order to differentiate between a listener name and a port number. From f16f6d2b93053bb3615909cdac7d186d10420953 Mon Sep 17 00:00:00 2001 From: Josh Soref <2119212+jsoref@users.noreply.github.com> Date: Wed, 16 Oct 2024 14:10:56 -0400 Subject: [PATCH 35/59] spelling: its Signed-off-by: Josh Soref <2119212+jsoref@users.noreply.github.com> --- geps/gep-1709/index.md | 2 +- geps/gep-1911/index.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/geps/gep-1709/index.md b/geps/gep-1709/index.md index 9914da2549..c145975277 100644 --- a/geps/gep-1709/index.md +++ b/geps/gep-1709/index.md @@ -358,7 +358,7 @@ profiles: > **WARNING**: It is an important clarification that this is NOT a full > Kubernetes API. It uses `TypeMeta` for some fields that made sense to re-use -> and were familiar, but otherwise has it's own structure. It is not a [Custom +> and were familiar, but otherwise has its own structure. It is not a [Custom > Resource Definition (CRD)][crd] nor will it be made available along with our > CRDs. It will be used only by conformance test tooling. diff --git a/geps/gep-1911/index.md b/geps/gep-1911/index.md index cdcd8a2803..d0db118a75 100644 --- a/geps/gep-1911/index.md +++ b/geps/gep-1911/index.md @@ -48,7 +48,7 @@ At the moment there exists three defined constants: ### New Protocols & Reserved Prefix -To add support for a new protocol it should first become a Kubernetes Standard Application Protocol by updating the [KEP-3726][kep-3726]. [KEP-3726][kep-3726] also states the `appProtocol` field accepts a domain-prefixed implementation specific value. Thus, if the suggested protocol is not suited to have a `kubernetes.io/*` prefix, then the Gateway API MAY support the new protocol using it's own prefix `gateway.networking.k8s.io/*`. Please make a PR to this GEP. +To add support for a new protocol it should first become a Kubernetes Standard Application Protocol by updating the [KEP-3726][kep-3726]. [KEP-3726][kep-3726] also states the `appProtocol` field accepts a domain-prefixed implementation specific value. Thus, if the suggested protocol is not suited to have a `kubernetes.io/*` prefix, then the Gateway API MAY support the new protocol using its own prefix `gateway.networking.k8s.io/*`. Please make a PR to this GEP. For example we may want to add a sentinel `appProtocol` value that prevents Gateway implementations from discovering the protocol of the application. Instead they should just refer to the Service's `protocol` field. Such a constant was rejected upstream (https://github.com/kubernetes/enhancements/pull/4106) but as an example it could be defined in a future addition to this GEP as `gateway.networking.k8s.io/no-sniff`. From c8a640c4fe575a9a34df8fc40f1b2102e6dbd35f Mon Sep 17 00:00:00 2001 From: Josh Soref <2119212+jsoref@users.noreply.github.com> Date: Fri, 18 Oct 2024 03:47:51 -0400 Subject: [PATCH 36/59] spelling: linked Signed-off-by: Josh Soref <2119212+jsoref@users.noreply.github.com> --- geps/gep-1731/metadata.yaml | 2 +- geps/gep-2659/index.md | 2 +- geps/gep-696/metadata.yaml | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/geps/gep-1731/metadata.yaml b/geps/gep-1731/metadata.yaml index d0650085b0..c85ccbcb0c 100644 --- a/geps/gep-1731/metadata.yaml +++ b/geps/gep-1731/metadata.yaml @@ -13,7 +13,7 @@ relationships: # set back to this GEP, and MUST be moved to Declined. obsoletes: {} obsoletedBy: {} - # extends indicates that a GEP extends the linkned GEP, adding more detail + # extends indicates that a GEP extends the linked GEP, adding more detail # or additional implementation. The extended GEP MUST have its extendedBy # field set back to this GEP. extends: {} diff --git a/geps/gep-2659/index.md b/geps/gep-2659/index.md index 57fbd19890..1ea2d7b9a0 100644 --- a/geps/gep-2659/index.md +++ b/geps/gep-2659/index.md @@ -118,7 +118,7 @@ relationships: # set back to this GEP, and MUST be moved to Declined. obsoletes: {} obsoletedBy: {} - # extends indicates that a GEP extends the linkned GEP, adding more detail + # extends indicates that a GEP extends the linked GEP, adding more detail # or additional implementation. The extended GEP MUST have its extendedBy # field set back to this GEP. extends: {} diff --git a/geps/gep-696/metadata.yaml b/geps/gep-696/metadata.yaml index 6bc1cfeb5a..cd15a89cd4 100644 --- a/geps/gep-696/metadata.yaml +++ b/geps/gep-696/metadata.yaml @@ -16,7 +16,7 @@ relationships: # set back to this GEP, and MUST be moved to Declined. obsoletes: {} obsoletedBy: {} - # extends indicates that a GEP extends the linkned GEP, adding more detail + # extends indicates that a GEP extends the linked GEP, adding more detail # or additional implementation. The extended GEP MUST have its extendedBy # field set back to this GEP. extends: {} From 9b17331bea294ba911a086f5f8e233f28a515ddf Mon Sep 17 00:00:00 2001 From: Josh Soref <2119212+jsoref@users.noreply.github.com> Date: Fri, 18 Oct 2024 03:48:03 -0400 Subject: [PATCH 37/59] spelling: maintainers Signed-off-by: Josh Soref <2119212+jsoref@users.noreply.github.com> --- geps/gep-2659/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/geps/gep-2659/index.md b/geps/gep-2659/index.md index 1ea2d7b9a0..3e11ff071a 100644 --- a/geps/gep-2659/index.md +++ b/geps/gep-2659/index.md @@ -87,7 +87,7 @@ Memorandum GEPs after this GEP is merged. ### Addition of YAML metadata file -The core Gateway API mainatainers were hoping not to need metadata YAMLs for a +The core Gateway API maintainers were hoping not to need metadata YAMLs for a while, but the addition of relationships has turbocharged the need for machine parseable GEP metadata. From a28f0b9c8b2dd12bdeeb07297aa2d3dc5fc061e0 Mon Sep 17 00:00:00 2001 From: Josh Soref <2119212+jsoref@users.noreply.github.com> Date: Fri, 18 Oct 2024 03:48:07 -0400 Subject: [PATCH 38/59] spelling: maintenance Signed-off-by: Josh Soref <2119212+jsoref@users.noreply.github.com> --- geps/gep-1686/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/geps/gep-1686/index.md b/geps/gep-1686/index.md index d80bdfa042..bc903efc94 100644 --- a/geps/gep-1686/index.md +++ b/geps/gep-1686/index.md @@ -25,7 +25,7 @@ GAMMA intends to introduce a "Mesh" [conformance profile](https://gateway-api.si This approach will enable service meshes to certify that an implementation follows the GAMMA spec without requiring a North/South implementation, and importantly avoid any expectation that North/South Gateway API implementations expand their scope to understand GAMMA and E/W traffic flows. -Leveraging existing tests for common functionality between N/S and E/W implementations will both ensure consistency across Gateway API implementations and help limit the maintence burden for the conformance testing suite. +Leveraging existing tests for common functionality between N/S and E/W implementations will both ensure consistency across Gateway API implementations and help limit the maintenance burden for the conformance testing suite. ### Support Levels From c93b2c1c566dee60c627523c61e9dba1e30e8786 Mon Sep 17 00:00:00 2001 From: Josh Soref <2119212+jsoref@users.noreply.github.com> Date: Fri, 18 Oct 2024 03:48:17 -0400 Subject: [PATCH 39/59] spelling: maximum Signed-off-by: Josh Soref <2119212+jsoref@users.noreply.github.com> --- geps/gep-1731/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/geps/gep-1731/index.md b/geps/gep-1731/index.md index 91231cdc35..cb479ed126 100644 --- a/geps/gep-1731/index.md +++ b/geps/gep-1731/index.md @@ -272,7 +272,7 @@ type HTTPRouteRetry struct { // Codes []HTTPRouteRetryStatusCode `json:"codes,omitempty"` - // Attempts specifies the maxmimum number of times an individual request + // Attempts specifies the maximum number of times an individual request // from the gateway to a backend should be retried. // // If the maximum number of retries has been attempted without a successful From a02ce99cafedaa152af2c3d502e1ca8efc0f6ea5 Mon Sep 17 00:00:00 2001 From: Josh Soref <2119212+jsoref@users.noreply.github.com> Date: Mon, 21 Oct 2024 11:30:17 -0400 Subject: [PATCH 40/59] spelling: negotiated Signed-off-by: Josh Soref <2119212+jsoref@users.noreply.github.com> --- conformance/echo-basic/grpcecho.proto | 4 ++-- conformance/echo-basic/grpcechoserver/grpcecho.pb.go | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/conformance/echo-basic/grpcecho.proto b/conformance/echo-basic/grpcecho.proto index 86c3fe6aed..df744e5b12 100644 --- a/conformance/echo-basic/grpcecho.proto +++ b/conformance/echo-basic/grpcecho.proto @@ -46,13 +46,13 @@ message TLSAssertions { // The TLS version used by the connection, e.g. "TLSv1.3" string version = 1; - // The negotatiated protocol. + // The negotiated protocol. string negotiated_protocol = 2; // The server name indication extension sent by the client. string server_name = 3; - // The cipher suite negotatiated for the connection, e.g. "TLS_EDCHE_ECDSA_WITH_AES_128_GCM_SHA256" + // The cipher suite negotiated for the connection, e.g. "TLS_EDCHE_ECDSA_WITH_AES_128_GCM_SHA256" string cipher_suite = 4; // The parsed certificates sent by the peer, in the order in which they were sent. diff --git a/conformance/echo-basic/grpcechoserver/grpcecho.pb.go b/conformance/echo-basic/grpcechoserver/grpcecho.pb.go index 9585b7760b..88207f3fe4 100644 --- a/conformance/echo-basic/grpcechoserver/grpcecho.pb.go +++ b/conformance/echo-basic/grpcechoserver/grpcecho.pb.go @@ -177,11 +177,11 @@ type TLSAssertions struct { // The TLS version used by the connection, e.g. "TLSv1.3" Version string `protobuf:"bytes,1,opt,name=version,proto3" json:"version,omitempty"` - // The negotatiated protocol. + // The negotiated protocol. NegotiatedProtocol string `protobuf:"bytes,2,opt,name=negotiated_protocol,json=negotiatedProtocol,proto3" json:"negotiated_protocol,omitempty"` // The server name indication extension sent by the client. ServerName string `protobuf:"bytes,3,opt,name=server_name,json=serverName,proto3" json:"server_name,omitempty"` - // The cipher suite negotatiated for the connection, e.g. "TLS_EDCHE_ECDSA_WITH_AES_128_GCM_SHA256" + // The cipher suite negotiated for the connection, e.g. "TLS_EDCHE_ECDSA_WITH_AES_128_GCM_SHA256" CipherSuite string `protobuf:"bytes,4,opt,name=cipher_suite,json=cipherSuite,proto3" json:"cipher_suite,omitempty"` // The parsed certificates sent by the peer, in the order in which they were sent. PeerCertificates []string `protobuf:"bytes,5,rep,name=peer_certificates,json=peerCertificates,proto3" json:"peer_certificates,omitempty"` From 491e36bf1592b7542dadd6b0ab69a0671fad2b47 Mon Sep 17 00:00:00 2001 From: Josh Soref <2119212+jsoref@users.noreply.github.com> Date: Mon, 21 Oct 2024 11:30:37 -0400 Subject: [PATCH 41/59] spelling: networking Signed-off-by: Josh Soref <2119212+jsoref@users.noreply.github.com> --- geps/gep-713/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/geps/gep-713/index.md b/geps/gep-713/index.md index 768cfc50fc..2bc1d28c76 100644 --- a/geps/gep-713/index.md +++ b/geps/gep-713/index.md @@ -871,7 +871,7 @@ contains `status` information. ```yaml kind: EffectivePolicy -apiVersion: gateway.networkking.k8s.io/v1alpha2 +apiVersion: gateway.networking.k8s.io/v1alpha2 metadata: name: targeted-object namespace: targeted-object-namespace From 7e3982d178673fb93cf669624f6abc733add8ba0 Mon Sep 17 00:00:00 2001 From: Josh Soref <2119212+jsoref@users.noreply.github.com> Date: Wed, 16 Oct 2024 14:10:38 -0400 Subject: [PATCH 42/59] spelling: nonexistent Signed-off-by: Josh Soref <2119212+jsoref@users.noreply.github.com> --- apis/v1/shared_types.go | 2 +- apis/v1alpha2/tcproute_types.go | 2 +- apis/v1alpha2/tlsroute_types.go | 2 +- apis/v1alpha2/udproute_types.go | 2 +- .../gateway.networking.k8s.io_grpcroutes.yaml | 2 +- .../gateway.networking.k8s.io_httproutes.yaml | 4 ++-- .../gateway.networking.k8s.io_tcproutes.yaml | 4 ++-- .../gateway.networking.k8s.io_tlsroutes.yaml | 4 ++-- .../gateway.networking.k8s.io_udproutes.yaml | 4 ++-- .../gateway.networking.k8s.io_grpcroutes.yaml | 2 +- .../gateway.networking.k8s.io_httproutes.yaml | 4 ++-- geps/gep-1016/index.md | 2 +- geps/gep-1364/index.md | 12 ++++++------ pkg/generated/openapi/zz_generated.openapi.go | 8 ++++---- 14 files changed, 27 insertions(+), 27 deletions(-) diff --git a/apis/v1/shared_types.go b/apis/v1/shared_types.go index dcaa1b4b4a..226c776372 100644 --- a/apis/v1/shared_types.go +++ b/apis/v1/shared_types.go @@ -469,7 +469,7 @@ type RouteParentStatus struct { // There are a number of cases where the "Accepted" condition may not be set // due to lack of controller visibility, that includes when: // - // * The Route refers to a non-existent parent. + // * The Route refers to a nonexistent parent. // * The Route is of a type that the controller does not support. // * The Route is in a namespace the controller does not have access to. // diff --git a/apis/v1alpha2/tcproute_types.go b/apis/v1alpha2/tcproute_types.go index b79253dd33..e383af495d 100644 --- a/apis/v1alpha2/tcproute_types.go +++ b/apis/v1alpha2/tcproute_types.go @@ -67,7 +67,7 @@ type TCPRouteRule struct { Name *SectionName `json:"name,omitempty"` // BackendRefs defines the backend(s) where matching requests should be - // sent. If unspecified or invalid (refers to a non-existent resource or a + // sent. If unspecified or invalid (refers to a nonexistent resource or a // Service with no endpoints), the underlying implementation MUST actively // reject connection attempts to this backend. Connection rejections must // respect weight; if an invalid backend is requested to have 80% of diff --git a/apis/v1alpha2/tlsroute_types.go b/apis/v1alpha2/tlsroute_types.go index 26dfde77c7..f21fe3fc50 100644 --- a/apis/v1alpha2/tlsroute_types.go +++ b/apis/v1alpha2/tlsroute_types.go @@ -108,7 +108,7 @@ type TLSRouteRule struct { Name *SectionName `json:"name,omitempty"` // BackendRefs defines the backend(s) where matching requests should be - // sent. If unspecified or invalid (refers to a non-existent resource or + // sent. If unspecified or invalid (refers to a nonexistent resource or // a Service with no endpoints), the rule performs no forwarding; if no // filters are specified that would result in a response being sent, the // underlying implementation must actively reject request attempts to this diff --git a/apis/v1alpha2/udproute_types.go b/apis/v1alpha2/udproute_types.go index 9e7fe3ff80..c7e92b92b4 100644 --- a/apis/v1alpha2/udproute_types.go +++ b/apis/v1alpha2/udproute_types.go @@ -67,7 +67,7 @@ type UDPRouteRule struct { Name *SectionName `json:"name,omitempty"` // BackendRefs defines the backend(s) where matching requests should be - // sent. If unspecified or invalid (refers to a non-existent resource or a + // sent. If unspecified or invalid (refers to a nonexistent resource or a // Service with no endpoints), the underlying implementation MUST actively // reject connection attempts to this backend. Packet drops must // respect weight; if an invalid backend is requested to have 80% of diff --git a/config/crd/experimental/gateway.networking.k8s.io_grpcroutes.yaml b/config/crd/experimental/gateway.networking.k8s.io_grpcroutes.yaml index 778993eb2a..38a433a38b 100644 --- a/config/crd/experimental/gateway.networking.k8s.io_grpcroutes.yaml +++ b/config/crd/experimental/gateway.networking.k8s.io_grpcroutes.yaml @@ -1975,7 +1975,7 @@ spec: There are a number of cases where the "Accepted" condition may not be set due to lack of controller visibility, that includes when: - * The Route refers to a non-existent parent. + * The Route refers to a nonexistent parent. * The Route is of a type that the controller does not support. * The Route is in a namespace the controller does not have access to. items: diff --git a/config/crd/experimental/gateway.networking.k8s.io_httproutes.yaml b/config/crd/experimental/gateway.networking.k8s.io_httproutes.yaml index 4d16463b4d..e9d59f53ff 100644 --- a/config/crd/experimental/gateway.networking.k8s.io_httproutes.yaml +++ b/config/crd/experimental/gateway.networking.k8s.io_httproutes.yaml @@ -2830,7 +2830,7 @@ spec: There are a number of cases where the "Accepted" condition may not be set due to lack of controller visibility, that includes when: - * The Route refers to a non-existent parent. + * The Route refers to a nonexistent parent. * The Route is of a type that the controller does not support. * The Route is in a namespace the controller does not have access to. items: @@ -5878,7 +5878,7 @@ spec: There are a number of cases where the "Accepted" condition may not be set due to lack of controller visibility, that includes when: - * The Route refers to a non-existent parent. + * The Route refers to a nonexistent parent. * The Route is of a type that the controller does not support. * The Route is in a namespace the controller does not have access to. items: diff --git a/config/crd/experimental/gateway.networking.k8s.io_tcproutes.yaml b/config/crd/experimental/gateway.networking.k8s.io_tcproutes.yaml index cdbeeb8c08..5d71119425 100644 --- a/config/crd/experimental/gateway.networking.k8s.io_tcproutes.yaml +++ b/config/crd/experimental/gateway.networking.k8s.io_tcproutes.yaml @@ -293,7 +293,7 @@ spec: backendRefs: description: |- BackendRefs defines the backend(s) where matching requests should be - sent. If unspecified or invalid (refers to a non-existent resource or a + sent. If unspecified or invalid (refers to a nonexistent resource or a Service with no endpoints), the underlying implementation MUST actively reject connection attempts to this backend. Connection rejections must respect weight; if an invalid backend is requested to have 80% of @@ -488,7 +488,7 @@ spec: There are a number of cases where the "Accepted" condition may not be set due to lack of controller visibility, that includes when: - * The Route refers to a non-existent parent. + * The Route refers to a nonexistent parent. * The Route is of a type that the controller does not support. * The Route is in a namespace the controller does not have access to. items: diff --git a/config/crd/experimental/gateway.networking.k8s.io_tlsroutes.yaml b/config/crd/experimental/gateway.networking.k8s.io_tlsroutes.yaml index 3c5413f96e..f3e63f56dd 100644 --- a/config/crd/experimental/gateway.networking.k8s.io_tlsroutes.yaml +++ b/config/crd/experimental/gateway.networking.k8s.io_tlsroutes.yaml @@ -353,7 +353,7 @@ spec: backendRefs: description: |- BackendRefs defines the backend(s) where matching requests should be - sent. If unspecified or invalid (refers to a non-existent resource or + sent. If unspecified or invalid (refers to a nonexistent resource or a Service with no endpoints), the rule performs no forwarding; if no filters are specified that would result in a response being sent, the underlying implementation must actively reject request attempts to this @@ -551,7 +551,7 @@ spec: There are a number of cases where the "Accepted" condition may not be set due to lack of controller visibility, that includes when: - * The Route refers to a non-existent parent. + * The Route refers to a nonexistent parent. * The Route is of a type that the controller does not support. * The Route is in a namespace the controller does not have access to. items: diff --git a/config/crd/experimental/gateway.networking.k8s.io_udproutes.yaml b/config/crd/experimental/gateway.networking.k8s.io_udproutes.yaml index 5aec6abf64..2bfcb7aab9 100644 --- a/config/crd/experimental/gateway.networking.k8s.io_udproutes.yaml +++ b/config/crd/experimental/gateway.networking.k8s.io_udproutes.yaml @@ -293,7 +293,7 @@ spec: backendRefs: description: |- BackendRefs defines the backend(s) where matching requests should be - sent. If unspecified or invalid (refers to a non-existent resource or a + sent. If unspecified or invalid (refers to a nonexistent resource or a Service with no endpoints), the underlying implementation MUST actively reject connection attempts to this backend. Packet drops must respect weight; if an invalid backend is requested to have 80% of @@ -488,7 +488,7 @@ spec: There are a number of cases where the "Accepted" condition may not be set due to lack of controller visibility, that includes when: - * The Route refers to a non-existent parent. + * The Route refers to a nonexistent parent. * The Route is of a type that the controller does not support. * The Route is in a namespace the controller does not have access to. items: diff --git a/config/crd/standard/gateway.networking.k8s.io_grpcroutes.yaml b/config/crd/standard/gateway.networking.k8s.io_grpcroutes.yaml index 273ab5bcdd..2950958e76 100644 --- a/config/crd/standard/gateway.networking.k8s.io_grpcroutes.yaml +++ b/config/crd/standard/gateway.networking.k8s.io_grpcroutes.yaml @@ -1747,7 +1747,7 @@ spec: There are a number of cases where the "Accepted" condition may not be set due to lack of controller visibility, that includes when: - * The Route refers to a non-existent parent. + * The Route refers to a nonexistent parent. * The Route is of a type that the controller does not support. * The Route is in a namespace the controller does not have access to. items: diff --git a/config/crd/standard/gateway.networking.k8s.io_httproutes.yaml b/config/crd/standard/gateway.networking.k8s.io_httproutes.yaml index 84f72350f5..0959fb2321 100644 --- a/config/crd/standard/gateway.networking.k8s.io_httproutes.yaml +++ b/config/crd/standard/gateway.networking.k8s.io_httproutes.yaml @@ -2515,7 +2515,7 @@ spec: There are a number of cases where the "Accepted" condition may not be set due to lack of controller visibility, that includes when: - * The Route refers to a non-existent parent. + * The Route refers to a nonexistent parent. * The Route is of a type that the controller does not support. * The Route is in a namespace the controller does not have access to. items: @@ -5230,7 +5230,7 @@ spec: There are a number of cases where the "Accepted" condition may not be set due to lack of controller visibility, that includes when: - * The Route refers to a non-existent parent. + * The Route refers to a nonexistent parent. * The Route is of a type that the controller does not support. * The Route is in a namespace the controller does not have access to. items: diff --git a/geps/gep-1016/index.md b/geps/gep-1016/index.md index 8ce35205c0..08576730ca 100644 --- a/geps/gep-1016/index.md +++ b/geps/gep-1016/index.md @@ -424,7 +424,7 @@ type GRPCRouteRule struct { // BackendRefs defines the backend(s) where matching requests should be // sent. - // If unspecified or invalid (refers to a non-existent resource or a Service + // If unspecified or invalid (refers to a nonexistent resource or a Service // with no endpoints), the rule performs no forwarding. If there are also no // filters specified that would result in a response being sent, a gRPC `UNAVAILABLE` // status is returned. `UNAVAILABLE` responses must be sent so that the overall diff --git a/geps/gep-1364/index.md b/geps/gep-1364/index.md index 0ff89c5007..25c879f907 100644 --- a/geps/gep-1364/index.md +++ b/geps/gep-1364/index.md @@ -323,13 +323,13 @@ Note that some classes of inter-resource reference failure do _not_ cause a reso to become unattached and stop being accepted (that is, to have the `Accepted` condition set to `status: false`). -* Non-existent Service backends - if the backend does not exist on a HTTPRoute that +* Nonexistent Service backends - if the backend does not exist on a HTTPRoute that is otherwise okay, then the data plane must generate 500s for traffic that matches that HTTPRoute. In this case, the `Accepted` Condition must be true, and the `ResolvedRefs` Condition must be false, with reasons and messages indicating that the backend services do not exist. * HTTPRoutes with *all* backends in other namespaces, but not permitted by ReferenceGrants. -In this case, the "non-existent service backends" rules apply, and 500s must be +In this case, the "nonexistent service backends" rules apply, and 500s must be generated. In this case, again, the `Accepted` condition is true, and the `ResolvedRefs` Condition is false, with reasons and messages indicating that the backend services are not reachable. @@ -359,21 +359,21 @@ Examples of Conditions: * HTTPRoute with one match with one backend that is valid. `Accepted` is true, `ResolvedRefs` is true. -* HTTPRoute with one match with one backend that is a non-existent Service backend. +* HTTPRoute with one match with one backend that is a nonexistent Service backend. The `Accepted` Condition is true, the `ResolvedRefs` condition is false, with a reason of `BackendNotFound`. `Accepted` is true in this case because the data path must respond to requests that would be sent to that backend with a 500 response. -* HTTPRoute with one match with two backends, one of which is a non-existent Service +* HTTPRoute with one match with two backends, one of which is a nonexistent Service backend. The `Accepted` Condition is true, the `ResolvedRefs` condition is false. `Accepted` is true in this case because the data path must respond to a percentage -of the requests matching the rule corresponding to the weighting of the non-existent +of the requests matching the rule corresponding to the weighting of the nonexistent backend (which would be fifty percent unless weights are applied). * HTTPRoute with one match with one backend that is in a different namespace, and does _not_ have a ReferenceGrant permitting that access. The `Accepted` condition is true, and the `ResolvedRefs` Condition is false, with a reason of `RefNotPermitted`. As before, `Accepted` is true because in this case, the data path must be programmed with 500s for the match. -* TCPRoute with one match with a backend that is a non-existent Service. `Accepted` +* TCPRoute with one match with a backend that is a nonexistent Service. `Accepted` is false, and `ResolvedRefs` is false. `Accepted` is false in this case because there is not enough information to program any rules to handle the traffic in the underlying data plane - TCP doesn't have a way to say "this is a valid destination diff --git a/pkg/generated/openapi/zz_generated.openapi.go b/pkg/generated/openapi/zz_generated.openapi.go index 5171a458c9..811e47ee48 100644 --- a/pkg/generated/openapi/zz_generated.openapi.go +++ b/pkg/generated/openapi/zz_generated.openapi.go @@ -5487,7 +5487,7 @@ func schema_sigsk8sio_gateway_api_apis_v1_RouteParentStatus(ref common.Reference }, }, SchemaProps: spec.SchemaProps{ - Description: "Conditions describes the status of the route with respect to the Gateway. Note that the route's availability is also subject to the Gateway's own status conditions and listener status.\n\nIf the Route's ParentRef specifies an existing Gateway that supports Routes of this kind AND that Gateway's controller has sufficient access, then that Gateway's controller MUST set the \"Accepted\" condition on the Route, to indicate whether the route has been accepted or rejected by the Gateway, and why.\n\nA Route MUST be considered \"Accepted\" if at least one of the Route's rules is implemented by the Gateway.\n\nThere are a number of cases where the \"Accepted\" condition may not be set due to lack of controller visibility, that includes when:\n\n* The Route refers to a non-existent parent. * The Route is of a type that the controller does not support. * The Route is in a namespace the controller does not have access to.", + Description: "Conditions describes the status of the route with respect to the Gateway. Note that the route's availability is also subject to the Gateway's own status conditions and listener status.\n\nIf the Route's ParentRef specifies an existing Gateway that supports Routes of this kind AND that Gateway's controller has sufficient access, then that Gateway's controller MUST set the \"Accepted\" condition on the Route, to indicate whether the route has been accepted or rejected by the Gateway, and why.\n\nA Route MUST be considered \"Accepted\" if at least one of the Route's rules is implemented by the Gateway.\n\nThere are a number of cases where the \"Accepted\" condition may not be set due to lack of controller visibility, that includes when:\n\n* The Route refers to a nonexistent parent. * The Route is of a type that the controller does not support. * The Route is in a namespace the controller does not have access to.", Type: []string{"array"}, Items: &spec.SchemaOrArray{ Schema: &spec.Schema{ @@ -6329,7 +6329,7 @@ func schema_sigsk8sio_gateway_api_apis_v1alpha2_TCPRouteRule(ref common.Referenc }, "backendRefs": { SchemaProps: spec.SchemaProps{ - Description: "BackendRefs defines the backend(s) where matching requests should be sent. If unspecified or invalid (refers to a non-existent resource or a Service with no endpoints), the underlying implementation MUST actively reject connection attempts to this backend. Connection rejections must respect weight; if an invalid backend is requested to have 80% of connections, then 80% of connections must be rejected instead.\n\nSupport: Core for Kubernetes Service\n\nSupport: Extended for Kubernetes ServiceImport\n\nSupport: Implementation-specific for any other resource\n\nSupport for weight: Extended", + Description: "BackendRefs defines the backend(s) where matching requests should be sent. If unspecified or invalid (refers to a nonexistent resource or a Service with no endpoints), the underlying implementation MUST actively reject connection attempts to this backend. Connection rejections must respect weight; if an invalid backend is requested to have 80% of connections, then 80% of connections must be rejected instead.\n\nSupport: Core for Kubernetes Service\n\nSupport: Extended for Kubernetes ServiceImport\n\nSupport: Implementation-specific for any other resource\n\nSupport for weight: Extended", Type: []string{"array"}, Items: &spec.SchemaOrArray{ Schema: &spec.Schema{ @@ -6538,7 +6538,7 @@ func schema_sigsk8sio_gateway_api_apis_v1alpha2_TLSRouteRule(ref common.Referenc }, "backendRefs": { SchemaProps: spec.SchemaProps{ - Description: "BackendRefs defines the backend(s) where matching requests should be sent. If unspecified or invalid (refers to a non-existent resource or a Service with no endpoints), the rule performs no forwarding; if no filters are specified that would result in a response being sent, the underlying implementation must actively reject request attempts to this backend, by rejecting the connection or returning a 500 status code. Request rejections must respect weight; if an invalid backend is requested to have 80% of requests, then 80% of requests must be rejected instead.\n\nSupport: Core for Kubernetes Service\n\nSupport: Extended for Kubernetes ServiceImport\n\nSupport: Implementation-specific for any other resource\n\nSupport for weight: Extended", + Description: "BackendRefs defines the backend(s) where matching requests should be sent. If unspecified or invalid (refers to a nonexistent resource or a Service with no endpoints), the rule performs no forwarding; if no filters are specified that would result in a response being sent, the underlying implementation must actively reject request attempts to this backend, by rejecting the connection or returning a 500 status code. Request rejections must respect weight; if an invalid backend is requested to have 80% of requests, then 80% of requests must be rejected instead.\n\nSupport: Core for Kubernetes Service\n\nSupport: Extended for Kubernetes ServiceImport\n\nSupport: Implementation-specific for any other resource\n\nSupport for weight: Extended", Type: []string{"array"}, Items: &spec.SchemaOrArray{ Schema: &spec.Schema{ @@ -6762,7 +6762,7 @@ func schema_sigsk8sio_gateway_api_apis_v1alpha2_UDPRouteRule(ref common.Referenc }, "backendRefs": { SchemaProps: spec.SchemaProps{ - Description: "BackendRefs defines the backend(s) where matching requests should be sent. If unspecified or invalid (refers to a non-existent resource or a Service with no endpoints), the underlying implementation MUST actively reject connection attempts to this backend. Packet drops must respect weight; if an invalid backend is requested to have 80% of the packets, then 80% of packets must be dropped instead.\n\nSupport: Core for Kubernetes Service\n\nSupport: Extended for Kubernetes ServiceImport\n\nSupport: Implementation-specific for any other resource\n\nSupport for weight: Extended", + Description: "BackendRefs defines the backend(s) where matching requests should be sent. If unspecified or invalid (refers to a nonexistent resource or a Service with no endpoints), the underlying implementation MUST actively reject connection attempts to this backend. Packet drops must respect weight; if an invalid backend is requested to have 80% of the packets, then 80% of packets must be dropped instead.\n\nSupport: Core for Kubernetes Service\n\nSupport: Extended for Kubernetes ServiceImport\n\nSupport: Implementation-specific for any other resource\n\nSupport for weight: Extended", Type: []string{"array"}, Items: &spec.SchemaOrArray{ Schema: &spec.Schema{ From f57b8822fb2e9b3809fbffe155634fe4841d32f9 Mon Sep 17 00:00:00 2001 From: Josh Soref <2119212+jsoref@users.noreply.github.com> Date: Wed, 16 Oct 2024 14:11:19 -0400 Subject: [PATCH 43/59] spelling: or Signed-off-by: Josh Soref <2119212+jsoref@users.noreply.github.com> --- conformance/apis/v1/result.go | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/conformance/apis/v1/result.go b/conformance/apis/v1/result.go index f3a826c4a2..0fbaec6570 100644 --- a/conformance/apis/v1/result.go +++ b/conformance/apis/v1/result.go @@ -29,7 +29,7 @@ var ( // tests passing without any failures, but some were skipped. Partial Result = "partial" - // Failure indicates that the test run concluded in one ore more tests + // Failure indicates that the test run concluded in one or more tests // failing to complete successfully. Failure Result = "failure" ) From 16faa64c228ed58339889f1fdd36e9169358ca12 Mon Sep 17 00:00:00 2001 From: Josh Soref <2119212+jsoref@users.noreply.github.com> Date: Fri, 18 Oct 2024 03:49:59 -0400 Subject: [PATCH 44/59] spelling: overridden Signed-off-by: Josh Soref <2119212+jsoref@users.noreply.github.com> --- geps/gep-1742/index.md | 2 +- geps/gep-3155/index.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/geps/gep-1742/index.md b/geps/gep-1742/index.md index 39ab142b86..2019b5e505 100644 --- a/geps/gep-1742/index.md +++ b/geps/gep-1742/index.md @@ -476,7 +476,7 @@ Timeouts could be configured using policy attachments or in objects other than ` Instead of configuring timeouts directly on an API object, they could be configured using policy attachments. The advantage to this approach would be that timeout policies can be not only -configured for an `HTTPRouteRule`, but can also be added/overriden at a more fine +configured for an `HTTPRouteRule`, but can also be added/overridden at a more fine (e.g., `HTTPBackendRef`) or coarse (e.g. `HTTPRoute`) level of granularity. The downside, however, is complexity introduced for the most common use case, adding a simple diff --git a/geps/gep-3155/index.md b/geps/gep-3155/index.md index 8652b3b13b..2fb1089295 100644 --- a/geps/gep-3155/index.md +++ b/geps/gep-3155/index.md @@ -64,7 +64,7 @@ type GatewayBackendTLS struct { // ClientCertificateRef can reference to standard Kubernetes resources, i.e. // Secret, or implementation-specific custom resources. // - // This setting can be overriden on the service level by use of BackendTLSPolicy. + // This setting can be overridden on the service level by use of BackendTLSPolicy. ClientCertificateRef SecretObjectReference `json:"clientCertificateRef,omitempty"` } ``` From e34f45b4b54842deccc302624f91e2804481a9d0 Mon Sep 17 00:00:00 2001 From: Josh Soref <2119212+jsoref@users.noreply.github.com> Date: Fri, 18 Oct 2024 03:50:11 -0400 Subject: [PATCH 45/59] spelling: possible Signed-off-by: Josh Soref <2119212+jsoref@users.noreply.github.com> --- geps/gep-2648/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/geps/gep-2648/index.md b/geps/gep-2648/index.md index ae3ebf389c..05a0a44667 100644 --- a/geps/gep-2648/index.md +++ b/geps/gep-2648/index.md @@ -300,7 +300,7 @@ const ( Implementations that use Direct Policy objects SHOULD put a Condition into `status.Conditions` of any objects affected by a Direct Policy, if that field is present. Ideally, there should be a set of Conditions that can be namespaced -by the implementing controller, but if that is not posisble, use the guidance below. +by the implementing controller, but if that is not possible, use the guidance below. If they do, that Condition MUST have a `type` ending in `PolicyAffected` (like `gateway.networking.k8s.io/PolicyAffected`), From d10efd830ed62985c8f1af9e27f53b83d1de57cf Mon Sep 17 00:00:00 2001 From: Josh Soref <2119212+jsoref@users.noreply.github.com> Date: Wed, 16 Oct 2024 14:11:27 -0400 Subject: [PATCH 46/59] spelling: preexisting Signed-off-by: Josh Soref <2119212+jsoref@users.noreply.github.com> --- Makefile | 6 +++--- geps/gep-3171/index.md | 2 +- site-src/contributing/devguide.md | 2 +- 3 files changed, 5 insertions(+), 5 deletions(-) diff --git a/Makefile b/Makefile index 7ef6a2a4a7..4bde1cc5e5 100644 --- a/Makefile +++ b/Makefile @@ -92,16 +92,16 @@ test.crds-validation: conformance: go test ${GO_TEST_FLAGS} -v ./conformance -run TestConformance -args ${CONFORMANCE_FLAGS} -# Install CRD's and example resources to a pre-existing cluster. +# Install CRD's and example resources to a preexisting cluster. .PHONY: install install: crd example -# Install the CRD's to a pre-existing cluster. +# Install the CRD's to a preexisting cluster. .PHONY: crd crd: kubectl kustomize config/crd | kubectl apply -f - -# Install the example resources to a pre-existing cluster. +# Install the example resources to a preexisting cluster. .PHONY: example example: hack/install-examples.sh diff --git a/geps/gep-3171/index.md b/geps/gep-3171/index.md index fbf21c4c3c..25ffd5d26d 100644 --- a/geps/gep-3171/index.md +++ b/geps/gep-3171/index.md @@ -22,7 +22,7 @@ The scope of this GEP is to add support for this feature in both HTTPRoute and G [Request Mirroring](https://gateway-api.sigs.k8s.io/guides/http-request-mirroring/) is a feature that allows a user to mirror requests going to some backend A along to some other specified backend B. Right now Request Mirroring is an all or nothing feature – either 100% of request are mirrored, or 0% are. Percentage-based Request Mirroring will allow users to specify a percentage of requests they'd like mirrored as opposed to every single request. -This feature is already [supported by Envoy](https://www.envoyproxy.io/docs/envoy/latest/api-v3/config/route/v3/route_components.proto#envoy-v3-api-msg-config-route-v3-routeaction-requestmirrorpolicy), so adding it for the Gateway API would enable better integration between the two products. There's also an existing user desire for this feature on the [HAProxy side](https://www.haproxy.com/blog/haproxy-traffic-mirroring-for-real-world-testing) and [NGINX side](https://alex.dzyoba.com/blog/nginx-mirror/). Since Request Mirroring is already supported by the Gateway API, Percentage-based Request Mirroring would a clear improvement on this pre-existing feature. +This feature is already [supported by Envoy](https://www.envoyproxy.io/docs/envoy/latest/api-v3/config/route/v3/route_components.proto#envoy-v3-api-msg-config-route-v3-routeaction-requestmirrorpolicy), so adding it for the Gateway API would enable better integration between the two products. There's also an existing user desire for this feature on the [HAProxy side](https://www.haproxy.com/blog/haproxy-traffic-mirroring-for-real-world-testing) and [NGINX side](https://alex.dzyoba.com/blog/nginx-mirror/). Since Request Mirroring is already supported by the Gateway API, Percentage-based Request Mirroring would a clear improvement on this preexisting feature. ## Existing Support in Implementations diff --git a/site-src/contributing/devguide.md b/site-src/contributing/devguide.md index 3f7e92a9ac..5ee98407d3 100644 --- a/site-src/contributing/devguide.md +++ b/site-src/contributing/devguide.md @@ -82,7 +82,7 @@ ensuring the field name will not be reused. ### Deploy the Code -Use the following command to deploy CRDs to the pre-existing `Kind` cluster. +Use the following command to deploy CRDs to the preexisting `Kind` cluster. ```shell make crd From 5798db7f89bd9cfaddbac8a22bbe20b65d03889e Mon Sep 17 00:00:00 2001 From: Josh Soref <2119212+jsoref@users.noreply.github.com> Date: Fri, 18 Oct 2024 03:50:21 -0400 Subject: [PATCH 47/59] spelling: prominence Signed-off-by: Josh Soref <2119212+jsoref@users.noreply.github.com> --- geps/gep-713/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/geps/gep-713/index.md b/geps/gep-713/index.md index 2bc1d28c76..8122fbea68 100644 --- a/geps/gep-713/index.md +++ b/geps/gep-713/index.md @@ -588,7 +588,7 @@ plugin. ##### Design considerations -This is already part of the API pattern, but is being lifted to more prominience +This is already part of the API pattern, but is being lifted to more prominence here. #### Standard status struct From e0a37a3508ff992f42919e4a3b5b14856fda6c2d Mon Sep 17 00:00:00 2001 From: Josh Soref <2119212+jsoref@users.noreply.github.com> Date: Fri, 18 Oct 2024 03:50:27 -0400 Subject: [PATCH 48/59] spelling: protocol Signed-off-by: Josh Soref <2119212+jsoref@users.noreply.github.com> --- pkg/features/httproute.go | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/pkg/features/httproute.go b/pkg/features/httproute.go index cd7d90ec5b..8264098493 100644 --- a/pkg/features/httproute.go +++ b/pkg/features/httproute.go @@ -95,7 +95,7 @@ const ( // This option indicates support for HTTPRoute with a backendref with an appProtocol 'kubernetes.io/h2c' (extended conformance) SupportHTTPRouteBackendProtocolH2C FeatureName = "HTTPRouteBackendProtocolH2C" - // This option indicates support for HTTPRoute with a backendref with an appProtoocol 'kubernetes.io/ws' (extended conformance) + // This option indicates support for HTTPRoute with a backendref with an appProtocol 'kubernetes.io/ws' (extended conformance) SupportHTTPRouteBackendProtocolWebSocket FeatureName = "HTTPRouteBackendProtocolWebSocket" ) From aea9af3a3fcfaf7724949cee07c91aca1c448678 Mon Sep 17 00:00:00 2001 From: Josh Soref <2119212+jsoref@users.noreply.github.com> Date: Fri, 18 Oct 2024 03:50:38 -0400 Subject: [PATCH 49/59] spelling: recommend Signed-off-by: Josh Soref <2119212+jsoref@users.noreply.github.com> --- geps/gep-995/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/geps/gep-995/index.md b/geps/gep-995/index.md index e74c9ae07e..de95280c6a 100644 --- a/geps/gep-995/index.md +++ b/geps/gep-995/index.md @@ -50,7 +50,7 @@ If specified, the name of a route rule MUST comply with the [`SectionName`](http To preserve backward compatibility with previous version of the affected APIs, the `name` field for route rules should be introduced in the API as optional – i.e., end-user are not forced to add it to their existing or new route objects. -Implementations MAY recomend the usage of the `name` field for enabling specific features, such as for supporting policy attachment targetting individual route rules, and more assertive log messages and/or status reporting that include on the name of the rule. However, because as by API design the presence of the field is optional, implementations MUST take into account that a value may sometimes not be available. For such cases, implementations are free to decide whether to provide the feature depending the `name` field, if the feature is not required for Core compliance, or to enable the feature relying on another method of referencing of choice. +Implementations MAY recommend the usage of the `name` field for enabling specific features, such as for supporting policy attachment targetting individual route rules, and more assertive log messages and/or status reporting that include on the name of the rule. However, because as by API design the presence of the field is optional, implementations MUST take into account that a value may sometimes not be available. For such cases, implementations are free to decide whether to provide the feature depending the `name` field, if the feature is not required for Core compliance, or to enable the feature relying on another method of referencing of choice. ### Default value From d074fdc556e4b2b25535a68c236fe226f48ec39d Mon Sep 17 00:00:00 2001 From: Josh Soref <2119212+jsoref@users.noreply.github.com> Date: Fri, 18 Oct 2024 03:50:46 -0400 Subject: [PATCH 50/59] spelling: referent Signed-off-by: Josh Soref <2119212+jsoref@users.noreply.github.com> --- geps/gep-709/index.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/geps/gep-709/index.md b/geps/gep-709/index.md index a4a8d21379..1a2ea88f5f 100644 --- a/geps/gep-709/index.md +++ b/geps/gep-709/index.md @@ -132,7 +132,7 @@ type ReferenceGrantSpec struct { // ReferenceGrantFrom describes trusted namespaces and kinds. type ReferenceGrantFrom struct { - // Group is the group of the referrent. + // Group is the group of the referent. // // Support: Core // @@ -140,7 +140,7 @@ type ReferenceGrantFrom struct { // +kubebuilder:validation:MaxLength=253 Group string `json:"group"` - // Kind is the kind of the referrent. Although implementations may support + // Kind is the kind of the referent. Although implementations may support // additional resources, the following Route types are part of the "Core" // support level for this field: // @@ -153,7 +153,7 @@ type ReferenceGrantFrom struct { // +kubebuilder:validation:MaxLength=253 Kind string `json:"kind"` - // Namespace is the namespace of the referrent. + // Namespace is the namespace of the referent. // // Support: Core // @@ -165,7 +165,7 @@ type ReferenceGrantFrom struct { // ReferenceGrantTo describes what Kinds are allowed as targets of the // references. type ReferenceGrantTo struct { - // Group is the group of the referrent. + // Group is the group of the referent. // // Support: Core // @@ -173,7 +173,7 @@ type ReferenceGrantTo struct { // +kubebuilder:validation:MaxLength=253 Group string `json:"group"` - // Kind is the kind of the referrent. Although implementations may support + // Kind is the kind of the referent. Although implementations may support // additional resources, the following types are part of the "Core" // support level for this field: // From 0fb0ec1419903248e8763e480767cc0e052be1d4 Mon Sep 17 00:00:00 2001 From: Josh Soref <2119212+jsoref@users.noreply.github.com> Date: Fri, 18 Oct 2024 03:50:57 -0400 Subject: [PATCH 51/59] spelling: release Signed-off-by: Josh Soref <2119212+jsoref@users.noreply.github.com> --- .openvex/templates/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.openvex/templates/README.md b/.openvex/templates/README.md index d724e1d0e7..3961ecf784 100644 --- a/.openvex/templates/README.md +++ b/.openvex/templates/README.md @@ -14,7 +14,7 @@ vexctl add --in-place main.openvex.json pkg:oci/test CVE-2014-1234567 fixed That will add a new VEX statement expressing that the impact of CVE-2014-1234567 is under investigation in the test image. When cutting a new release, for `pkg:oci/test` the new file will be -incorporated to the relase's VEX data. +incorporated to the release's VEX data. ## Read more about OpenVEX From fbc1c939d0fa244c6adb60bc7bcc439f0ee0342e Mon Sep 17 00:00:00 2001 From: Josh Soref <2119212+jsoref@users.noreply.github.com> Date: Fri, 18 Oct 2024 03:49:50 -0400 Subject: [PATCH 52/59] spelling: route-override Signed-off-by: Josh Soref <2119212+jsoref@users.noreply.github.com> --- geps/gep-746/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/geps/gep-746/index.md b/geps/gep-746/index.md index 475a0ae8f3..4c0f33be9a 100644 --- a/geps/gep-746/index.md +++ b/geps/gep-746/index.md @@ -176,7 +176,7 @@ type TLSRouteOverrideType string const ( // Allows the parameter to be configured from all routes. - TLSROuteOVerrideAllow TLSRouteOverrideType = "Allow" + TLSRouteOverrideAllow TLSRouteOverrideType = "Allow" // Prohibits the parameter from being configured from any route. TLSRouteOverrideDeny TLSRouteOverrideType = "Deny" From 95f58b6f0fa1f699ccc958b6ab6f84a0cc308829 Mon Sep 17 00:00:00 2001 From: Josh Soref <2119212+jsoref@users.noreply.github.com> Date: Fri, 18 Oct 2024 12:53:36 -0400 Subject: [PATCH 53/59] spelling: stabilizing Signed-off-by: Josh Soref <2119212+jsoref@users.noreply.github.com> --- geps/gep-713/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/geps/gep-713/index.md b/geps/gep-713/index.md index 8122fbea68..3fa9fba4ad 100644 --- a/geps/gep-713/index.md +++ b/geps/gep-713/index.md @@ -54,7 +54,7 @@ more resources, and are consequently harder to understand and require a more complex status design. Splitting these two design patterns apart into separate GEPs is intended to -allow proceeding with stablizing the simpler (Direct) case while we work on +allow proceeding with stabilizing the simpler (Direct) case while we work on solving the status problem for the more complex (Inherited) case. Direct Attached Policies are further specified in the addendum GEP GEP-2648, From 390f5d00b15ff20f52906713aa43bc30a8644c0d Mon Sep 17 00:00:00 2001 From: Josh Soref <2119212+jsoref@users.noreply.github.com> Date: Fri, 18 Oct 2024 03:51:48 -0400 Subject: [PATCH 54/59] spelling: substituted Signed-off-by: Josh Soref <2119212+jsoref@users.noreply.github.com> --- site-src/guides/simple-gateway.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/site-src/guides/simple-gateway.md b/site-src/guides/simple-gateway.md index a49bce55c0..0697dfc928 100644 --- a/site-src/guides/simple-gateway.md +++ b/site-src/guides/simple-gateway.md @@ -15,7 +15,7 @@ match all HTTP traffic and directs it to a single Service named `foo-svc`. The Gateway represents the instantiation of a logical load balancer and the GatewayClass defines the load balancer template when users create a Gateway. The example Gateway is templated from a hypothetical `example` -GatewayClass, which is meant to be a placeholder and substitued by users. Here +GatewayClass, which is meant to be a placeholder and substituted by users. Here is a list of available [Gateway Implementation](https://gateway-api.sigs.k8s.io/implementations/) that can be used to determine the correct GatewayClass based on the specific From 1b3c687d8b75f6fc49582793fd174d640dc7cc25 Mon Sep 17 00:00:00 2001 From: Josh Soref <2119212+jsoref@users.noreply.github.com> Date: Mon, 21 Oct 2024 11:58:08 -0400 Subject: [PATCH 55/59] spelling: targeting Signed-off-by: Josh Soref <2119212+jsoref@users.noreply.github.com> --- geps/gep-995/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/geps/gep-995/index.md b/geps/gep-995/index.md index de95280c6a..162cc4d676 100644 --- a/geps/gep-995/index.md +++ b/geps/gep-995/index.md @@ -50,7 +50,7 @@ If specified, the name of a route rule MUST comply with the [`SectionName`](http To preserve backward compatibility with previous version of the affected APIs, the `name` field for route rules should be introduced in the API as optional – i.e., end-user are not forced to add it to their existing or new route objects. -Implementations MAY recommend the usage of the `name` field for enabling specific features, such as for supporting policy attachment targetting individual route rules, and more assertive log messages and/or status reporting that include on the name of the rule. However, because as by API design the presence of the field is optional, implementations MUST take into account that a value may sometimes not be available. For such cases, implementations are free to decide whether to provide the feature depending the `name` field, if the feature is not required for Core compliance, or to enable the feature relying on another method of referencing of choice. +Implementations MAY recommend the usage of the `name` field for enabling specific features, such as for supporting policy attachment targeting individual route rules, and more assertive log messages and/or status reporting that include on the name of the rule. However, because as by API design the presence of the field is optional, implementations MUST take into account that a value may sometimes not be available. For such cases, implementations are free to decide whether to provide the feature depending the `name` field, if the feature is not required for Core compliance, or to enable the feature relying on another method of referencing of choice. ### Default value From 63799af601c43763274a05d57866d61884540050 Mon Sep 17 00:00:00 2001 From: Josh Soref <2119212+jsoref@users.noreply.github.com> Date: Wed, 16 Oct 2024 14:08:55 -0400 Subject: [PATCH 56/59] spelling: the Signed-off-by: Josh Soref <2119212+jsoref@users.noreply.github.com> --- geps/gep-1686/index.md | 2 +- geps/gep-2162/index.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/geps/gep-1686/index.md b/geps/gep-1686/index.md index bc903efc94..22ecb477ef 100644 --- a/geps/gep-1686/index.md +++ b/geps/gep-1686/index.md @@ -80,7 +80,7 @@ producer). - Assert that traffic from a client in a different `Namespace` is routed by the `HTTPRoute` -A consumer `HTTPRoute` is in the same `Namespace` as the the request sender (the +A consumer `HTTPRoute` is in the same `Namespace` as the request sender (the consumer), a different `Namespace` as the `parentRef` `Service`. - Given a consumer `HTTPRoute` diff --git a/geps/gep-2162/index.md b/geps/gep-2162/index.md index 43f5d052d1..7a106e200e 100644 --- a/geps/gep-2162/index.md +++ b/geps/gep-2162/index.md @@ -123,7 +123,7 @@ Every feature should: #### Conformance test names -Conformance tests file names should try to follow the the `pascal-case-name.go` format. +Conformance tests file names should try to follow the `pascal-case-name.go` format. For example for `HTTPRoutePortRedirect` - the test file would be `httproute-port-redirect.go`. We should treat this guidance as "best effort" because we might have test files that check the combination of several features and can't follow the same format. From 02c19d4611f85f1950320b898580b956ab52c850 Mon Sep 17 00:00:00 2001 From: Josh Soref <2119212+jsoref@users.noreply.github.com> Date: Fri, 18 Oct 2024 03:56:17 -0400 Subject: [PATCH 57/59] spelling: validationutil Signed-off-by: Josh Soref <2119212+jsoref@users.noreply.github.com> --- apis/v1/util/validation/gatewayclass_test.go | 4 ++-- apis/v1beta1/util/validation/gatewayclass_test.go | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/apis/v1/util/validation/gatewayclass_test.go b/apis/v1/util/validation/gatewayclass_test.go index d211b1fcd7..f5cdb1d0d6 100644 --- a/apis/v1/util/validation/gatewayclass_test.go +++ b/apis/v1/util/validation/gatewayclass_test.go @@ -20,7 +20,7 @@ import ( "testing" gatewayv1 "sigs.k8s.io/gateway-api/apis/v1" - validationtutils "sigs.k8s.io/gateway-api/apis/v1beta1/util/validation" + validationutil "sigs.k8s.io/gateway-api/apis/v1beta1/util/validation" ) func TestIsControllerNameValid(t *testing.T) { @@ -58,7 +58,7 @@ func TestIsControllerNameValid(t *testing.T) { for _, tc := range testCases { t.Run(tc.name, func(t *testing.T) { - isValid := validationtutils.IsControllerNameValid(tc.controllerName) + isValid := validationutil.IsControllerNameValid(tc.controllerName) if isValid != tc.isvalid { t.Errorf("Expected validity %t, got %t", tc.isvalid, isValid) } diff --git a/apis/v1beta1/util/validation/gatewayclass_test.go b/apis/v1beta1/util/validation/gatewayclass_test.go index 175d4f9a30..128de4947e 100644 --- a/apis/v1beta1/util/validation/gatewayclass_test.go +++ b/apis/v1beta1/util/validation/gatewayclass_test.go @@ -20,7 +20,7 @@ import ( "testing" gatewayv1b1 "sigs.k8s.io/gateway-api/apis/v1beta1" - validationtutils "sigs.k8s.io/gateway-api/apis/v1beta1/util/validation" + validationutil "sigs.k8s.io/gateway-api/apis/v1beta1/util/validation" ) func TestIsControllerNameValid(t *testing.T) { @@ -58,7 +58,7 @@ func TestIsControllerNameValid(t *testing.T) { for _, tc := range testCases { t.Run(tc.name, func(t *testing.T) { - isValid := validationtutils.IsControllerNameValid(tc.controllerName) + isValid := validationutil.IsControllerNameValid(tc.controllerName) if isValid != tc.isvalid { t.Errorf("Expected validity %t, got %t", tc.isvalid, isValid) } From 4e79ea61d4d9e5bfc01e2472abdcdd7680ddd7f4 Mon Sep 17 00:00:00 2001 From: Josh Soref <2119212+jsoref@users.noreply.github.com> Date: Wed, 16 Oct 2024 14:09:28 -0400 Subject: [PATCH 58/59] spelling: which Signed-off-by: Josh Soref <2119212+jsoref@users.noreply.github.com> --- geps/gep-2162/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/geps/gep-2162/index.md b/geps/gep-2162/index.md index 7a106e200e..1000e3eea1 100644 --- a/geps/gep-2162/index.md +++ b/geps/gep-2162/index.md @@ -179,7 +179,7 @@ Once the GatewayClass features support are is published into the status we could ### Add Gateway API Version field to the GatewayClass Status -We got some feedback that it will be useful to indicate what what Gateway API version the implementation supports. So when we have supported features published in the GatewayClass Status, users will also be able to understand that those are the supported features for a specific Gateway API version. +We got some feedback that it will be useful to indicate which Gateway API version the implementation supports. So when we have supported features published in the GatewayClass Status, users will also be able to understand that those are the supported features for a specific Gateway API version. This work is likely to require its own small GEP but ideally what this field would mean is that an implementation supports Max(vX.X). From 8e1a8e55076568ccf1fb4c6041779c23871a0e06 Mon Sep 17 00:00:00 2001 From: Josh Soref <2119212+jsoref@users.noreply.github.com> Date: Fri, 18 Oct 2024 04:02:40 -0400 Subject: [PATCH 59/59] Reword simplify prototyping description Signed-off-by: Josh Soref <2119212+jsoref@users.noreply.github.com> --- geps/overview.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/geps/overview.md b/geps/overview.md index 74fed4288c..cf331cd94d 100644 --- a/geps/overview.md +++ b/geps/overview.md @@ -59,7 +59,7 @@ of stability of the change described in the GEP: * **Provisional:** The goals described by this GEP have consensus but implementation details have not been agreed to yet. - * **Prototyping:** An extension of `Provisional` which can be opted in to in + * **Prototyping:** An optional extension of `Provisional` in order to indicate to the community that there are some active practical tests and experiments going on which are intended to be a part of the development of this GEP. This may include APIs or code, but that content _must_ not be