From 8173dfe209127a38b55ef9cdcb100a2652239adc Mon Sep 17 00:00:00 2001 From: Mike Morris Date: Mon, 26 Jun 2023 13:57:09 -0400 Subject: [PATCH 01/14] apis: document ParentRef functionality for GAMMA --- apis/v1beta1/shared_types.go | 45 +++++++++++++++++++++++++++++------- 1 file changed, 37 insertions(+), 8 deletions(-) diff --git a/apis/v1beta1/shared_types.go b/apis/v1beta1/shared_types.go index 7540cff627..643ee40e59 100644 --- a/apis/v1beta1/shared_types.go +++ b/apis/v1beta1/shared_types.go @@ -21,9 +21,10 @@ import ( ) // ParentReference identifies an API object (usually a Gateway) that can be considered -// a parent of this resource (usually a route). The only kind of parent resource -// with "Core" support is Gateway. This API may be extended in the future to -// support additional kinds of parent resources, such as HTTPRoute. +// a parent of this resource (usually a route). The only kinds of parent resources +// with "Core" support are Service (only for implementations supporting the Mesh +// conformance profile) and Gateway. This API may be extended in the future to +// support additional kinds of parent resources. // // The API object must be valid in the cluster; the Group and Kind must // be registered in the cluster for this reference to be valid. @@ -43,6 +44,8 @@ type ParentReference struct { // // Support: Core (Gateway) // + // Support: Core (Service - mesh conformance profile only) + // // Support: Implementation-specific (Other Resources) // // +kubebuilder:default=Gateway @@ -58,6 +61,13 @@ type ParentReference struct { // Gateway has the AllowedRoutes field, and ReferenceGrant provides a // generic way to enable any other kind of cross-namespace reference. // + // ParentRefs from a Route to a Service in the same namespace are "producer" + // routes, which apply default routing rules to inbound connections from + // any namespace to the Service. ParentRefs from a Route to a Service in a + // different namespace are "consumer" routes, and these routing rules are + // only applied to outbound connections to the Service from the same + // namespace as the Route. + // // Support: Core // // +optional @@ -75,6 +85,10 @@ type ParentReference struct { // are specified, the name and port of the selected listener must match // both specified values. // + // * Service: Named port. When both Port (experimental) and SectionName + // are specified, the name and port of the selected port must match + // both specified values. + // // Implementations MAY choose to support attaching Routes to other resources. // If that is the case, they MUST clearly document how SectionName is // interpreted. @@ -104,6 +118,10 @@ type ParentReference struct { // and SectionName are specified, the name and port of the selected listener // must match both specified values. // + // When the parent resource is a Service, this targets a specific port in the + // Service spec. When both Port (experimental) and SectionName are specified, + // the name and port of the selected port must match both specified values. + // // Implementations MAY choose to support other parent resources. // Implementations supporting other types of parent resources MUST clearly // document how/if Port is interpreted. @@ -130,15 +148,19 @@ type CommonRouteSpec struct { // to be attached to. Note that the referenced parent resource needs to // allow this for the attachment to be complete. For Gateways, that means // the Gateway needs to allow attachment from Routes of this kind and - // namespace. + // namespace. For Services, that means the Service must either be in the same + // namespace for a "producer" route, or the mesh implementation must support + // and allow "consumer" routes for the referenced Service. // - // The only kind of parent resource with "Core" support is Gateway. This API - // may be extended in the future to support additional kinds of parent + // The only kinds of parent resources with "Core" support are Service (only + // for implementations supporting the Mesh conformance profile) and Gateway. + // This API may be extended in the future to support additional kinds of parent // resources such as one of the route kinds. // // It is invalid to reference an identical parent more than once. It is // valid to reference multiple distinct sections within the same parent - // resource, such as 2 Listeners within a Gateway. + // resource, such as two separate Listeners on the same Gateway or two separate + // ports on the same Service. // // It is possible to separately reference multiple distinct objects that may // be collapsed by an implementation. For example, some implementations may @@ -150,7 +172,14 @@ type CommonRouteSpec struct { // rules. Cross-namespace references are only valid if they are explicitly // allowed by something in the namespace they are referring to. For example, // Gateway has the AllowedRoutes field, and ReferenceGrant provides a - // generic way to enable any other kind of cross-namespace reference. + // generic way to enable other kinds of cross-namespace reference. + // + // ParentRefs from a Route to a Service in the same namespace are "producer" + // routes, which apply default routing rules to inbound connections from + // any namespace to the Service. ParentRefs from a Route to a Service in a + // different namespace are "consumer" routes, and these routing rules are + // only applied to outbound connections to the Service from the same + // namespace as the Route. // // +optional // +kubebuilder:validation:MaxItems=32 From d2bf38676c9f885029b95a87ff3ae27f39f250a5 Mon Sep 17 00:00:00 2001 From: Mike Morris Date: Mon, 26 Jun 2023 14:18:30 -0400 Subject: [PATCH 02/14] crds: update-codegen --- .../gateway.networking.k8s.io_grpcroutes.yaml | 137 ++++++--- .../gateway.networking.k8s.io_httproutes.yaml | 274 ++++++++++++------ .../gateway.networking.k8s.io_tcproutes.yaml | 137 ++++++--- .../gateway.networking.k8s.io_tlsroutes.yaml | 137 ++++++--- .../gateway.networking.k8s.io_udproutes.yaml | 137 ++++++--- .../gateway.networking.k8s.io_httproutes.yaml | 202 ++++++++----- 6 files changed, 668 insertions(+), 356 deletions(-) diff --git a/config/crd/experimental/gateway.networking.k8s.io_grpcroutes.yaml b/config/crd/experimental/gateway.networking.k8s.io_grpcroutes.yaml index 99b59c19c1..c40dd20ce8 100644 --- a/config/crd/experimental/gateway.networking.k8s.io_grpcroutes.yaml +++ b/config/crd/experimental/gateway.networking.k8s.io_grpcroutes.yaml @@ -127,13 +127,18 @@ spec: that a Route wants to be attached to. Note that the referenced parent resource needs to allow this for the attachment to be complete. For Gateways, that means the Gateway needs to allow attachment from - Routes of this kind and namespace. \n The only kind of parent resource - with \"Core\" support is Gateway. This API may be extended in the - future to support additional kinds of parent resources such as one - of the route kinds. \n It is invalid to reference an identical parent - more than once. It is valid to reference multiple distinct sections - within the same parent resource, such as 2 Listeners within a Gateway. - \n It is possible to separately reference multiple distinct objects + Routes of this kind and namespace. For Services, that means the + Service must either be in the same namespace for a \"producer\" + route, or the mesh implementation must support and allow \"consumer\" + routes for the referenced Service. \n The only kinds of parent resources + with \"Core\" support are Service (only for implementations supporting + the Mesh conformance profile) and Gateway. This API may be extended + in the future to support additional kinds of parent resources such + as one of the route kinds. \n It is invalid to reference an identical + parent more than once. It is valid to reference multiple distinct + sections within the same parent resource, such as two separate Listeners + on the same Gateway or two separate ports on the same Service. \n + It is possible to separately reference multiple distinct objects that may be collapsed by an implementation. For example, some implementations may choose to merge compatible Gateway Listeners together. If that is the case, the list of routes attached to those resources should @@ -141,16 +146,23 @@ spec: boundaries, there are specific rules. Cross-namespace references are only valid if they are explicitly allowed by something in the namespace they are referring to. For example, Gateway has the AllowedRoutes - field, and ReferenceGrant provides a generic way to enable any other - kind of cross-namespace reference." + field, and ReferenceGrant provides a generic way to enable other + kinds of cross-namespace reference. \n ParentRefs from a Route to + a Service in the same namespace are \"producer\" routes, which apply + default routing rules to inbound connections from any namespace + to the Service. ParentRefs from a Route to a Service in a different + namespace are \"consumer\" routes, and these routing rules are only + applied to outbound connections to the Service from the same namespace + as the Route." items: description: "ParentReference identifies an API object (usually a Gateway) that can be considered a parent of this resource (usually - a route). The only kind of parent resource with \"Core\" support - is Gateway. This API may be extended in the future to support - additional kinds of parent resources, such as HTTPRoute. \n The - API object must be valid in the cluster; the Group and Kind must - be registered in the cluster for this reference to be valid." + a route). The only kinds of parent resources with \"Core\" support + are Service (only for implementations supporting the Mesh conformance + profile) and Gateway. This API may be extended in the future to + support additional kinds of parent resources. \n The API object + must be valid in the cluster; the Group and Kind must be registered + in the cluster for this reference to be valid." properties: group: default: gateway.networking.k8s.io @@ -165,7 +177,8 @@ spec: kind: default: Gateway description: "Kind is kind of the referent. \n Support: Core - (Gateway) \n Support: Implementation-specific (Other Resources)" + (Gateway) \n Support: Core (Service - mesh conformance profile + only) \n Support: Implementation-specific (Other Resources)" maxLength: 63 minLength: 1 pattern: ^[a-zA-Z]([-a-zA-Z0-9]*[a-zA-Z0-9])?$ @@ -185,7 +198,13 @@ spec: the namespace they are referring to. For example: Gateway has the AllowedRoutes field, and ReferenceGrant provides a generic way to enable any other kind of cross-namespace reference. - \n Support: Core" + \n ParentRefs from a Route to a Service in the same namespace + are \"producer\" routes, which apply default routing rules + to inbound connections from any namespace to the Service. + ParentRefs from a Route to a Service in a different namespace + are \"consumer\" routes, and these routing rules are only + applied to outbound connections to the Service from the same + namespace as the Route. \n Support: Core" maxLength: 63 minLength: 1 pattern: ^[a-z0-9]([-a-z0-9]*[a-z0-9])?$ @@ -200,18 +219,22 @@ spec: a Route must apply to a specific port as opposed to a listener(s) whose port(s) may be changed. When both Port and SectionName are specified, the name and port of the selected listener - must match both specified values. \n Implementations MAY choose - to support other parent resources. Implementations supporting - other types of parent resources MUST clearly document how/if - Port is interpreted. \n For the purpose of status, an attachment - is considered successful as long as the parent resource accepts - it partially. For example, Gateway listeners can restrict - which Routes can attach to them by Route kind, namespace, - or hostname. If 1 of 2 Gateway listeners accept attachment - from the referencing Route, the Route MUST be considered successfully - attached. If no Gateway listeners accept attachment from this - Route, the Route MUST be considered detached from the Gateway. - \n Support: Extended \n " + must match both specified values. \n When the parent resource + is a Service, this targets a specific port in the Service + spec. When both Port (experimental) and SectionName are specified, + the name and port of the selected port must match both specified + values. \n Implementations MAY choose to support other parent + resources. Implementations supporting other types of parent + resources MUST clearly document how/if Port is interpreted. + \n For the purpose of status, an attachment is considered + successful as long as the parent resource accepts it partially. + For example, Gateway listeners can restrict which Routes can + attach to them by Route kind, namespace, or hostname. If 1 + of 2 Gateway listeners accept attachment from the referencing + Route, the Route MUST be considered successfully attached. + If no Gateway listeners accept attachment from this Route, + the Route MUST be considered detached from the Gateway. \n + Support: Extended \n " format: int32 maximum: 65535 minimum: 1 @@ -222,19 +245,22 @@ spec: interpreted as the following: \n * Gateway: Listener Name. When both Port (experimental) and SectionName are specified, the name and port of the selected listener must match both - specified values. \n Implementations MAY choose to support - attaching Routes to other resources. If that is the case, - they MUST clearly document how SectionName is interpreted. - \n When unspecified (empty string), this will reference the - entire resource. For the purpose of status, an attachment - is considered successful if at least one section in the parent - resource accepts it. For example, Gateway listeners can restrict - which Routes can attach to them by Route kind, namespace, - or hostname. If 1 of 2 Gateway listeners accept attachment - from the referencing Route, the Route MUST be considered successfully - attached. If no Gateway listeners accept attachment from this - Route, the Route MUST be considered detached from the Gateway. - \n Support: Core" + specified values. \n * Service: Named port. When both Port + (experimental) and SectionName are specified, the name and + port of the selected port must match both specified values. + \n Implementations MAY choose to support attaching Routes + to other resources. If that is the case, they MUST clearly + document how SectionName is interpreted. \n When unspecified + (empty string), this will reference the entire resource. For + the purpose of status, an attachment is considered successful + if at least one section in the parent resource accepts it. + For example, Gateway listeners can restrict which Routes can + attach to them by Route kind, namespace, or hostname. If 1 + of 2 Gateway listeners accept attachment from the referencing + Route, the Route MUST be considered successfully attached. + If no Gateway listeners accept attachment from this Route, + the Route MUST be considered detached from the Gateway. \n + Support: Core" maxLength: 253 minLength: 1 pattern: ^[a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*$ @@ -1396,7 +1422,8 @@ spec: kind: default: Gateway description: "Kind is kind of the referent. \n Support: - Core (Gateway) \n Support: Implementation-specific (Other + Core (Gateway) \n Support: Core (Service - mesh conformance + profile only) \n Support: Implementation-specific (Other Resources)" maxLength: 63 minLength: 1 @@ -1417,7 +1444,14 @@ spec: in the namespace they are referring to. For example: Gateway has the AllowedRoutes field, and ReferenceGrant provides a generic way to enable any other kind of cross-namespace - reference. \n Support: Core" + reference. \n ParentRefs from a Route to a Service in + the same namespace are \"producer\" routes, which apply + default routing rules to inbound connections from any + namespace to the Service. ParentRefs from a Route to a + Service in a different namespace are \"consumer\" routes, + and these routing rules are only applied to outbound connections + to the Service from the same namespace as the Route. \n + Support: Core" maxLength: 63 minLength: 1 pattern: ^[a-z0-9]([-a-z0-9]*[a-z0-9])?$ @@ -1433,8 +1467,12 @@ spec: a specific port as opposed to a listener(s) whose port(s) may be changed. When both Port and SectionName are specified, the name and port of the selected listener must match - both specified values. \n Implementations MAY choose to - support other parent resources. Implementations supporting + both specified values. \n When the parent resource is + a Service, this targets a specific port in the Service + spec. When both Port (experimental) and SectionName are + specified, the name and port of the selected port must + match both specified values. \n Implementations MAY choose + to support other parent resources. Implementations supporting other types of parent resources MUST clearly document how/if Port is interpreted. \n For the purpose of status, an attachment is considered successful as long as the @@ -1456,9 +1494,12 @@ spec: is interpreted as the following: \n * Gateway: Listener Name. When both Port (experimental) and SectionName are specified, the name and port of the selected listener - must match both specified values. \n Implementations MAY - choose to support attaching Routes to other resources. - If that is the case, they MUST clearly document how SectionName + must match both specified values. \n * Service: Named + port. When both Port (experimental) and SectionName are + specified, the name and port of the selected port must + match both specified values. \n Implementations MAY choose + to support attaching Routes to other resources. If that + is the case, they MUST clearly document how SectionName is interpreted. \n When unspecified (empty string), this will reference the entire resource. For the purpose of status, an attachment is considered successful if at least diff --git a/config/crd/experimental/gateway.networking.k8s.io_httproutes.yaml b/config/crd/experimental/gateway.networking.k8s.io_httproutes.yaml index 855f3064b2..951340395a 100644 --- a/config/crd/experimental/gateway.networking.k8s.io_httproutes.yaml +++ b/config/crd/experimental/gateway.networking.k8s.io_httproutes.yaml @@ -114,13 +114,18 @@ spec: that a Route wants to be attached to. Note that the referenced parent resource needs to allow this for the attachment to be complete. For Gateways, that means the Gateway needs to allow attachment from - Routes of this kind and namespace. \n The only kind of parent resource - with \"Core\" support is Gateway. This API may be extended in the - future to support additional kinds of parent resources such as one - of the route kinds. \n It is invalid to reference an identical parent - more than once. It is valid to reference multiple distinct sections - within the same parent resource, such as 2 Listeners within a Gateway. - \n It is possible to separately reference multiple distinct objects + Routes of this kind and namespace. For Services, that means the + Service must either be in the same namespace for a \"producer\" + route, or the mesh implementation must support and allow \"consumer\" + routes for the referenced Service. \n The only kinds of parent resources + with \"Core\" support are Service (only for implementations supporting + the Mesh conformance profile) and Gateway. This API may be extended + in the future to support additional kinds of parent resources such + as one of the route kinds. \n It is invalid to reference an identical + parent more than once. It is valid to reference multiple distinct + sections within the same parent resource, such as two separate Listeners + on the same Gateway or two separate ports on the same Service. \n + It is possible to separately reference multiple distinct objects that may be collapsed by an implementation. For example, some implementations may choose to merge compatible Gateway Listeners together. If that is the case, the list of routes attached to those resources should @@ -128,16 +133,23 @@ spec: boundaries, there are specific rules. Cross-namespace references are only valid if they are explicitly allowed by something in the namespace they are referring to. For example, Gateway has the AllowedRoutes - field, and ReferenceGrant provides a generic way to enable any other - kind of cross-namespace reference." + field, and ReferenceGrant provides a generic way to enable other + kinds of cross-namespace reference. \n ParentRefs from a Route to + a Service in the same namespace are \"producer\" routes, which apply + default routing rules to inbound connections from any namespace + to the Service. ParentRefs from a Route to a Service in a different + namespace are \"consumer\" routes, and these routing rules are only + applied to outbound connections to the Service from the same namespace + as the Route." items: description: "ParentReference identifies an API object (usually a Gateway) that can be considered a parent of this resource (usually - a route). The only kind of parent resource with \"Core\" support - is Gateway. This API may be extended in the future to support - additional kinds of parent resources, such as HTTPRoute. \n The - API object must be valid in the cluster; the Group and Kind must - be registered in the cluster for this reference to be valid." + a route). The only kinds of parent resources with \"Core\" support + are Service (only for implementations supporting the Mesh conformance + profile) and Gateway. This API may be extended in the future to + support additional kinds of parent resources. \n The API object + must be valid in the cluster; the Group and Kind must be registered + in the cluster for this reference to be valid." properties: group: default: gateway.networking.k8s.io @@ -152,7 +164,8 @@ spec: kind: default: Gateway description: "Kind is kind of the referent. \n Support: Core - (Gateway) \n Support: Implementation-specific (Other Resources)" + (Gateway) \n Support: Core (Service - mesh conformance profile + only) \n Support: Implementation-specific (Other Resources)" maxLength: 63 minLength: 1 pattern: ^[a-zA-Z]([-a-zA-Z0-9]*[a-zA-Z0-9])?$ @@ -172,7 +185,13 @@ spec: the namespace they are referring to. For example: Gateway has the AllowedRoutes field, and ReferenceGrant provides a generic way to enable any other kind of cross-namespace reference. - \n Support: Core" + \n ParentRefs from a Route to a Service in the same namespace + are \"producer\" routes, which apply default routing rules + to inbound connections from any namespace to the Service. + ParentRefs from a Route to a Service in a different namespace + are \"consumer\" routes, and these routing rules are only + applied to outbound connections to the Service from the same + namespace as the Route. \n Support: Core" maxLength: 63 minLength: 1 pattern: ^[a-z0-9]([-a-z0-9]*[a-z0-9])?$ @@ -187,18 +206,22 @@ spec: a Route must apply to a specific port as opposed to a listener(s) whose port(s) may be changed. When both Port and SectionName are specified, the name and port of the selected listener - must match both specified values. \n Implementations MAY choose - to support other parent resources. Implementations supporting - other types of parent resources MUST clearly document how/if - Port is interpreted. \n For the purpose of status, an attachment - is considered successful as long as the parent resource accepts - it partially. For example, Gateway listeners can restrict - which Routes can attach to them by Route kind, namespace, - or hostname. If 1 of 2 Gateway listeners accept attachment - from the referencing Route, the Route MUST be considered successfully - attached. If no Gateway listeners accept attachment from this - Route, the Route MUST be considered detached from the Gateway. - \n Support: Extended \n " + must match both specified values. \n When the parent resource + is a Service, this targets a specific port in the Service + spec. When both Port (experimental) and SectionName are specified, + the name and port of the selected port must match both specified + values. \n Implementations MAY choose to support other parent + resources. Implementations supporting other types of parent + resources MUST clearly document how/if Port is interpreted. + \n For the purpose of status, an attachment is considered + successful as long as the parent resource accepts it partially. + For example, Gateway listeners can restrict which Routes can + attach to them by Route kind, namespace, or hostname. If 1 + of 2 Gateway listeners accept attachment from the referencing + Route, the Route MUST be considered successfully attached. + If no Gateway listeners accept attachment from this Route, + the Route MUST be considered detached from the Gateway. \n + Support: Extended \n " format: int32 maximum: 65535 minimum: 1 @@ -209,19 +232,22 @@ spec: interpreted as the following: \n * Gateway: Listener Name. When both Port (experimental) and SectionName are specified, the name and port of the selected listener must match both - specified values. \n Implementations MAY choose to support - attaching Routes to other resources. If that is the case, - they MUST clearly document how SectionName is interpreted. - \n When unspecified (empty string), this will reference the - entire resource. For the purpose of status, an attachment - is considered successful if at least one section in the parent - resource accepts it. For example, Gateway listeners can restrict - which Routes can attach to them by Route kind, namespace, - or hostname. If 1 of 2 Gateway listeners accept attachment - from the referencing Route, the Route MUST be considered successfully - attached. If no Gateway listeners accept attachment from this - Route, the Route MUST be considered detached from the Gateway. - \n Support: Core" + specified values. \n * Service: Named port. When both Port + (experimental) and SectionName are specified, the name and + port of the selected port must match both specified values. + \n Implementations MAY choose to support attaching Routes + to other resources. If that is the case, they MUST clearly + document how SectionName is interpreted. \n When unspecified + (empty string), this will reference the entire resource. For + the purpose of status, an attachment is considered successful + if at least one section in the parent resource accepts it. + For example, Gateway listeners can restrict which Routes can + attach to them by Route kind, namespace, or hostname. If 1 + of 2 Gateway listeners accept attachment from the referencing + Route, the Route MUST be considered successfully attached. + If no Gateway listeners accept attachment from this Route, + the Route MUST be considered detached from the Gateway. \n + Support: Core" maxLength: 253 minLength: 1 pattern: ^[a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*$ @@ -1912,7 +1938,8 @@ spec: kind: default: Gateway description: "Kind is kind of the referent. \n Support: - Core (Gateway) \n Support: Implementation-specific (Other + Core (Gateway) \n Support: Core (Service - mesh conformance + profile only) \n Support: Implementation-specific (Other Resources)" maxLength: 63 minLength: 1 @@ -1933,7 +1960,14 @@ spec: in the namespace they are referring to. For example: Gateway has the AllowedRoutes field, and ReferenceGrant provides a generic way to enable any other kind of cross-namespace - reference. \n Support: Core" + reference. \n ParentRefs from a Route to a Service in + the same namespace are \"producer\" routes, which apply + default routing rules to inbound connections from any + namespace to the Service. ParentRefs from a Route to a + Service in a different namespace are \"consumer\" routes, + and these routing rules are only applied to outbound connections + to the Service from the same namespace as the Route. \n + Support: Core" maxLength: 63 minLength: 1 pattern: ^[a-z0-9]([-a-z0-9]*[a-z0-9])?$ @@ -1949,8 +1983,12 @@ spec: a specific port as opposed to a listener(s) whose port(s) may be changed. When both Port and SectionName are specified, the name and port of the selected listener must match - both specified values. \n Implementations MAY choose to - support other parent resources. Implementations supporting + both specified values. \n When the parent resource is + a Service, this targets a specific port in the Service + spec. When both Port (experimental) and SectionName are + specified, the name and port of the selected port must + match both specified values. \n Implementations MAY choose + to support other parent resources. Implementations supporting other types of parent resources MUST clearly document how/if Port is interpreted. \n For the purpose of status, an attachment is considered successful as long as the @@ -1972,9 +2010,12 @@ spec: is interpreted as the following: \n * Gateway: Listener Name. When both Port (experimental) and SectionName are specified, the name and port of the selected listener - must match both specified values. \n Implementations MAY - choose to support attaching Routes to other resources. - If that is the case, they MUST clearly document how SectionName + must match both specified values. \n * Service: Named + port. When both Port (experimental) and SectionName are + specified, the name and port of the selected port must + match both specified values. \n Implementations MAY choose + to support attaching Routes to other resources. If that + is the case, they MUST clearly document how SectionName is interpreted. \n When unspecified (empty string), this will reference the entire resource. For the purpose of status, an attachment is considered successful if at least @@ -2102,13 +2143,18 @@ spec: that a Route wants to be attached to. Note that the referenced parent resource needs to allow this for the attachment to be complete. For Gateways, that means the Gateway needs to allow attachment from - Routes of this kind and namespace. \n The only kind of parent resource - with \"Core\" support is Gateway. This API may be extended in the - future to support additional kinds of parent resources such as one - of the route kinds. \n It is invalid to reference an identical parent - more than once. It is valid to reference multiple distinct sections - within the same parent resource, such as 2 Listeners within a Gateway. - \n It is possible to separately reference multiple distinct objects + Routes of this kind and namespace. For Services, that means the + Service must either be in the same namespace for a \"producer\" + route, or the mesh implementation must support and allow \"consumer\" + routes for the referenced Service. \n The only kinds of parent resources + with \"Core\" support are Service (only for implementations supporting + the Mesh conformance profile) and Gateway. This API may be extended + in the future to support additional kinds of parent resources such + as one of the route kinds. \n It is invalid to reference an identical + parent more than once. It is valid to reference multiple distinct + sections within the same parent resource, such as two separate Listeners + on the same Gateway or two separate ports on the same Service. \n + It is possible to separately reference multiple distinct objects that may be collapsed by an implementation. For example, some implementations may choose to merge compatible Gateway Listeners together. If that is the case, the list of routes attached to those resources should @@ -2116,16 +2162,23 @@ spec: boundaries, there are specific rules. Cross-namespace references are only valid if they are explicitly allowed by something in the namespace they are referring to. For example, Gateway has the AllowedRoutes - field, and ReferenceGrant provides a generic way to enable any other - kind of cross-namespace reference." + field, and ReferenceGrant provides a generic way to enable other + kinds of cross-namespace reference. \n ParentRefs from a Route to + a Service in the same namespace are \"producer\" routes, which apply + default routing rules to inbound connections from any namespace + to the Service. ParentRefs from a Route to a Service in a different + namespace are \"consumer\" routes, and these routing rules are only + applied to outbound connections to the Service from the same namespace + as the Route." items: description: "ParentReference identifies an API object (usually a Gateway) that can be considered a parent of this resource (usually - a route). The only kind of parent resource with \"Core\" support - is Gateway. This API may be extended in the future to support - additional kinds of parent resources, such as HTTPRoute. \n The - API object must be valid in the cluster; the Group and Kind must - be registered in the cluster for this reference to be valid." + a route). The only kinds of parent resources with \"Core\" support + are Service (only for implementations supporting the Mesh conformance + profile) and Gateway. This API may be extended in the future to + support additional kinds of parent resources. \n The API object + must be valid in the cluster; the Group and Kind must be registered + in the cluster for this reference to be valid." properties: group: default: gateway.networking.k8s.io @@ -2140,7 +2193,8 @@ spec: kind: default: Gateway description: "Kind is kind of the referent. \n Support: Core - (Gateway) \n Support: Implementation-specific (Other Resources)" + (Gateway) \n Support: Core (Service - mesh conformance profile + only) \n Support: Implementation-specific (Other Resources)" maxLength: 63 minLength: 1 pattern: ^[a-zA-Z]([-a-zA-Z0-9]*[a-zA-Z0-9])?$ @@ -2160,7 +2214,13 @@ spec: the namespace they are referring to. For example: Gateway has the AllowedRoutes field, and ReferenceGrant provides a generic way to enable any other kind of cross-namespace reference. - \n Support: Core" + \n ParentRefs from a Route to a Service in the same namespace + are \"producer\" routes, which apply default routing rules + to inbound connections from any namespace to the Service. + ParentRefs from a Route to a Service in a different namespace + are \"consumer\" routes, and these routing rules are only + applied to outbound connections to the Service from the same + namespace as the Route. \n Support: Core" maxLength: 63 minLength: 1 pattern: ^[a-z0-9]([-a-z0-9]*[a-z0-9])?$ @@ -2175,18 +2235,22 @@ spec: a Route must apply to a specific port as opposed to a listener(s) whose port(s) may be changed. When both Port and SectionName are specified, the name and port of the selected listener - must match both specified values. \n Implementations MAY choose - to support other parent resources. Implementations supporting - other types of parent resources MUST clearly document how/if - Port is interpreted. \n For the purpose of status, an attachment - is considered successful as long as the parent resource accepts - it partially. For example, Gateway listeners can restrict - which Routes can attach to them by Route kind, namespace, - or hostname. If 1 of 2 Gateway listeners accept attachment - from the referencing Route, the Route MUST be considered successfully - attached. If no Gateway listeners accept attachment from this - Route, the Route MUST be considered detached from the Gateway. - \n Support: Extended \n " + must match both specified values. \n When the parent resource + is a Service, this targets a specific port in the Service + spec. When both Port (experimental) and SectionName are specified, + the name and port of the selected port must match both specified + values. \n Implementations MAY choose to support other parent + resources. Implementations supporting other types of parent + resources MUST clearly document how/if Port is interpreted. + \n For the purpose of status, an attachment is considered + successful as long as the parent resource accepts it partially. + For example, Gateway listeners can restrict which Routes can + attach to them by Route kind, namespace, or hostname. If 1 + of 2 Gateway listeners accept attachment from the referencing + Route, the Route MUST be considered successfully attached. + If no Gateway listeners accept attachment from this Route, + the Route MUST be considered detached from the Gateway. \n + Support: Extended \n " format: int32 maximum: 65535 minimum: 1 @@ -2197,19 +2261,22 @@ spec: interpreted as the following: \n * Gateway: Listener Name. When both Port (experimental) and SectionName are specified, the name and port of the selected listener must match both - specified values. \n Implementations MAY choose to support - attaching Routes to other resources. If that is the case, - they MUST clearly document how SectionName is interpreted. - \n When unspecified (empty string), this will reference the - entire resource. For the purpose of status, an attachment - is considered successful if at least one section in the parent - resource accepts it. For example, Gateway listeners can restrict - which Routes can attach to them by Route kind, namespace, - or hostname. If 1 of 2 Gateway listeners accept attachment - from the referencing Route, the Route MUST be considered successfully - attached. If no Gateway listeners accept attachment from this - Route, the Route MUST be considered detached from the Gateway. - \n Support: Core" + specified values. \n * Service: Named port. When both Port + (experimental) and SectionName are specified, the name and + port of the selected port must match both specified values. + \n Implementations MAY choose to support attaching Routes + to other resources. If that is the case, they MUST clearly + document how SectionName is interpreted. \n When unspecified + (empty string), this will reference the entire resource. For + the purpose of status, an attachment is considered successful + if at least one section in the parent resource accepts it. + For example, Gateway listeners can restrict which Routes can + attach to them by Route kind, namespace, or hostname. If 1 + of 2 Gateway listeners accept attachment from the referencing + Route, the Route MUST be considered successfully attached. + If no Gateway listeners accept attachment from this Route, + the Route MUST be considered detached from the Gateway. \n + Support: Core" maxLength: 253 minLength: 1 pattern: ^[a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*$ @@ -3900,7 +3967,8 @@ spec: kind: default: Gateway description: "Kind is kind of the referent. \n Support: - Core (Gateway) \n Support: Implementation-specific (Other + Core (Gateway) \n Support: Core (Service - mesh conformance + profile only) \n Support: Implementation-specific (Other Resources)" maxLength: 63 minLength: 1 @@ -3921,7 +3989,14 @@ spec: in the namespace they are referring to. For example: Gateway has the AllowedRoutes field, and ReferenceGrant provides a generic way to enable any other kind of cross-namespace - reference. \n Support: Core" + reference. \n ParentRefs from a Route to a Service in + the same namespace are \"producer\" routes, which apply + default routing rules to inbound connections from any + namespace to the Service. ParentRefs from a Route to a + Service in a different namespace are \"consumer\" routes, + and these routing rules are only applied to outbound connections + to the Service from the same namespace as the Route. \n + Support: Core" maxLength: 63 minLength: 1 pattern: ^[a-z0-9]([-a-z0-9]*[a-z0-9])?$ @@ -3937,8 +4012,12 @@ spec: a specific port as opposed to a listener(s) whose port(s) may be changed. When both Port and SectionName are specified, the name and port of the selected listener must match - both specified values. \n Implementations MAY choose to - support other parent resources. Implementations supporting + both specified values. \n When the parent resource is + a Service, this targets a specific port in the Service + spec. When both Port (experimental) and SectionName are + specified, the name and port of the selected port must + match both specified values. \n Implementations MAY choose + to support other parent resources. Implementations supporting other types of parent resources MUST clearly document how/if Port is interpreted. \n For the purpose of status, an attachment is considered successful as long as the @@ -3960,9 +4039,12 @@ spec: is interpreted as the following: \n * Gateway: Listener Name. When both Port (experimental) and SectionName are specified, the name and port of the selected listener - must match both specified values. \n Implementations MAY - choose to support attaching Routes to other resources. - If that is the case, they MUST clearly document how SectionName + must match both specified values. \n * Service: Named + port. When both Port (experimental) and SectionName are + specified, the name and port of the selected port must + match both specified values. \n Implementations MAY choose + to support attaching Routes to other resources. If that + is the case, they MUST clearly document how SectionName is interpreted. \n When unspecified (empty string), this will reference the entire resource. For the purpose of status, an attachment is considered successful if at least diff --git a/config/crd/experimental/gateway.networking.k8s.io_tcproutes.yaml b/config/crd/experimental/gateway.networking.k8s.io_tcproutes.yaml index 3bd0956c7a..f9cb172a66 100644 --- a/config/crd/experimental/gateway.networking.k8s.io_tcproutes.yaml +++ b/config/crd/experimental/gateway.networking.k8s.io_tcproutes.yaml @@ -49,13 +49,18 @@ spec: that a Route wants to be attached to. Note that the referenced parent resource needs to allow this for the attachment to be complete. For Gateways, that means the Gateway needs to allow attachment from - Routes of this kind and namespace. \n The only kind of parent resource - with \"Core\" support is Gateway. This API may be extended in the - future to support additional kinds of parent resources such as one - of the route kinds. \n It is invalid to reference an identical parent - more than once. It is valid to reference multiple distinct sections - within the same parent resource, such as 2 Listeners within a Gateway. - \n It is possible to separately reference multiple distinct objects + Routes of this kind and namespace. For Services, that means the + Service must either be in the same namespace for a \"producer\" + route, or the mesh implementation must support and allow \"consumer\" + routes for the referenced Service. \n The only kinds of parent resources + with \"Core\" support are Service (only for implementations supporting + the Mesh conformance profile) and Gateway. This API may be extended + in the future to support additional kinds of parent resources such + as one of the route kinds. \n It is invalid to reference an identical + parent more than once. It is valid to reference multiple distinct + sections within the same parent resource, such as two separate Listeners + on the same Gateway or two separate ports on the same Service. \n + It is possible to separately reference multiple distinct objects that may be collapsed by an implementation. For example, some implementations may choose to merge compatible Gateway Listeners together. If that is the case, the list of routes attached to those resources should @@ -63,16 +68,23 @@ spec: boundaries, there are specific rules. Cross-namespace references are only valid if they are explicitly allowed by something in the namespace they are referring to. For example, Gateway has the AllowedRoutes - field, and ReferenceGrant provides a generic way to enable any other - kind of cross-namespace reference." + field, and ReferenceGrant provides a generic way to enable other + kinds of cross-namespace reference. \n ParentRefs from a Route to + a Service in the same namespace are \"producer\" routes, which apply + default routing rules to inbound connections from any namespace + to the Service. ParentRefs from a Route to a Service in a different + namespace are \"consumer\" routes, and these routing rules are only + applied to outbound connections to the Service from the same namespace + as the Route." items: description: "ParentReference identifies an API object (usually a Gateway) that can be considered a parent of this resource (usually - a route). The only kind of parent resource with \"Core\" support - is Gateway. This API may be extended in the future to support - additional kinds of parent resources, such as HTTPRoute. \n The - API object must be valid in the cluster; the Group and Kind must - be registered in the cluster for this reference to be valid." + a route). The only kinds of parent resources with \"Core\" support + are Service (only for implementations supporting the Mesh conformance + profile) and Gateway. This API may be extended in the future to + support additional kinds of parent resources. \n The API object + must be valid in the cluster; the Group and Kind must be registered + in the cluster for this reference to be valid." properties: group: default: gateway.networking.k8s.io @@ -87,7 +99,8 @@ spec: kind: default: Gateway description: "Kind is kind of the referent. \n Support: Core - (Gateway) \n Support: Implementation-specific (Other Resources)" + (Gateway) \n Support: Core (Service - mesh conformance profile + only) \n Support: Implementation-specific (Other Resources)" maxLength: 63 minLength: 1 pattern: ^[a-zA-Z]([-a-zA-Z0-9]*[a-zA-Z0-9])?$ @@ -107,7 +120,13 @@ spec: the namespace they are referring to. For example: Gateway has the AllowedRoutes field, and ReferenceGrant provides a generic way to enable any other kind of cross-namespace reference. - \n Support: Core" + \n ParentRefs from a Route to a Service in the same namespace + are \"producer\" routes, which apply default routing rules + to inbound connections from any namespace to the Service. + ParentRefs from a Route to a Service in a different namespace + are \"consumer\" routes, and these routing rules are only + applied to outbound connections to the Service from the same + namespace as the Route. \n Support: Core" maxLength: 63 minLength: 1 pattern: ^[a-z0-9]([-a-z0-9]*[a-z0-9])?$ @@ -122,18 +141,22 @@ spec: a Route must apply to a specific port as opposed to a listener(s) whose port(s) may be changed. When both Port and SectionName are specified, the name and port of the selected listener - must match both specified values. \n Implementations MAY choose - to support other parent resources. Implementations supporting - other types of parent resources MUST clearly document how/if - Port is interpreted. \n For the purpose of status, an attachment - is considered successful as long as the parent resource accepts - it partially. For example, Gateway listeners can restrict - which Routes can attach to them by Route kind, namespace, - or hostname. If 1 of 2 Gateway listeners accept attachment - from the referencing Route, the Route MUST be considered successfully - attached. If no Gateway listeners accept attachment from this - Route, the Route MUST be considered detached from the Gateway. - \n Support: Extended \n " + must match both specified values. \n When the parent resource + is a Service, this targets a specific port in the Service + spec. When both Port (experimental) and SectionName are specified, + the name and port of the selected port must match both specified + values. \n Implementations MAY choose to support other parent + resources. Implementations supporting other types of parent + resources MUST clearly document how/if Port is interpreted. + \n For the purpose of status, an attachment is considered + successful as long as the parent resource accepts it partially. + For example, Gateway listeners can restrict which Routes can + attach to them by Route kind, namespace, or hostname. If 1 + of 2 Gateway listeners accept attachment from the referencing + Route, the Route MUST be considered successfully attached. + If no Gateway listeners accept attachment from this Route, + the Route MUST be considered detached from the Gateway. \n + Support: Extended \n " format: int32 maximum: 65535 minimum: 1 @@ -144,19 +167,22 @@ spec: interpreted as the following: \n * Gateway: Listener Name. When both Port (experimental) and SectionName are specified, the name and port of the selected listener must match both - specified values. \n Implementations MAY choose to support - attaching Routes to other resources. If that is the case, - they MUST clearly document how SectionName is interpreted. - \n When unspecified (empty string), this will reference the - entire resource. For the purpose of status, an attachment - is considered successful if at least one section in the parent - resource accepts it. For example, Gateway listeners can restrict - which Routes can attach to them by Route kind, namespace, - or hostname. If 1 of 2 Gateway listeners accept attachment - from the referencing Route, the Route MUST be considered successfully - attached. If no Gateway listeners accept attachment from this - Route, the Route MUST be considered detached from the Gateway. - \n Support: Core" + specified values. \n * Service: Named port. When both Port + (experimental) and SectionName are specified, the name and + port of the selected port must match both specified values. + \n Implementations MAY choose to support attaching Routes + to other resources. If that is the case, they MUST clearly + document how SectionName is interpreted. \n When unspecified + (empty string), this will reference the entire resource. For + the purpose of status, an attachment is considered successful + if at least one section in the parent resource accepts it. + For example, Gateway listeners can restrict which Routes can + attach to them by Route kind, namespace, or hostname. If 1 + of 2 Gateway listeners accept attachment from the referencing + Route, the Route MUST be considered successfully attached. + If no Gateway listeners accept attachment from this Route, + the Route MUST be considered detached from the Gateway. \n + Support: Core" maxLength: 253 minLength: 1 pattern: ^[a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*$ @@ -421,7 +447,8 @@ spec: kind: default: Gateway description: "Kind is kind of the referent. \n Support: - Core (Gateway) \n Support: Implementation-specific (Other + Core (Gateway) \n Support: Core (Service - mesh conformance + profile only) \n Support: Implementation-specific (Other Resources)" maxLength: 63 minLength: 1 @@ -442,7 +469,14 @@ spec: in the namespace they are referring to. For example: Gateway has the AllowedRoutes field, and ReferenceGrant provides a generic way to enable any other kind of cross-namespace - reference. \n Support: Core" + reference. \n ParentRefs from a Route to a Service in + the same namespace are \"producer\" routes, which apply + default routing rules to inbound connections from any + namespace to the Service. ParentRefs from a Route to a + Service in a different namespace are \"consumer\" routes, + and these routing rules are only applied to outbound connections + to the Service from the same namespace as the Route. \n + Support: Core" maxLength: 63 minLength: 1 pattern: ^[a-z0-9]([-a-z0-9]*[a-z0-9])?$ @@ -458,8 +492,12 @@ spec: a specific port as opposed to a listener(s) whose port(s) may be changed. When both Port and SectionName are specified, the name and port of the selected listener must match - both specified values. \n Implementations MAY choose to - support other parent resources. Implementations supporting + both specified values. \n When the parent resource is + a Service, this targets a specific port in the Service + spec. When both Port (experimental) and SectionName are + specified, the name and port of the selected port must + match both specified values. \n Implementations MAY choose + to support other parent resources. Implementations supporting other types of parent resources MUST clearly document how/if Port is interpreted. \n For the purpose of status, an attachment is considered successful as long as the @@ -481,9 +519,12 @@ spec: is interpreted as the following: \n * Gateway: Listener Name. When both Port (experimental) and SectionName are specified, the name and port of the selected listener - must match both specified values. \n Implementations MAY - choose to support attaching Routes to other resources. - If that is the case, they MUST clearly document how SectionName + must match both specified values. \n * Service: Named + port. When both Port (experimental) and SectionName are + specified, the name and port of the selected port must + match both specified values. \n Implementations MAY choose + to support attaching Routes to other resources. If that + is the case, they MUST clearly document how SectionName is interpreted. \n When unspecified (empty string), this will reference the entire resource. For the purpose of status, an attachment is considered successful if at least diff --git a/config/crd/experimental/gateway.networking.k8s.io_tlsroutes.yaml b/config/crd/experimental/gateway.networking.k8s.io_tlsroutes.yaml index 7de0a12d7c..ef14aa8280 100644 --- a/config/crd/experimental/gateway.networking.k8s.io_tlsroutes.yaml +++ b/config/crd/experimental/gateway.networking.k8s.io_tlsroutes.yaml @@ -95,13 +95,18 @@ spec: that a Route wants to be attached to. Note that the referenced parent resource needs to allow this for the attachment to be complete. For Gateways, that means the Gateway needs to allow attachment from - Routes of this kind and namespace. \n The only kind of parent resource - with \"Core\" support is Gateway. This API may be extended in the - future to support additional kinds of parent resources such as one - of the route kinds. \n It is invalid to reference an identical parent - more than once. It is valid to reference multiple distinct sections - within the same parent resource, such as 2 Listeners within a Gateway. - \n It is possible to separately reference multiple distinct objects + Routes of this kind and namespace. For Services, that means the + Service must either be in the same namespace for a \"producer\" + route, or the mesh implementation must support and allow \"consumer\" + routes for the referenced Service. \n The only kinds of parent resources + with \"Core\" support are Service (only for implementations supporting + the Mesh conformance profile) and Gateway. This API may be extended + in the future to support additional kinds of parent resources such + as one of the route kinds. \n It is invalid to reference an identical + parent more than once. It is valid to reference multiple distinct + sections within the same parent resource, such as two separate Listeners + on the same Gateway or two separate ports on the same Service. \n + It is possible to separately reference multiple distinct objects that may be collapsed by an implementation. For example, some implementations may choose to merge compatible Gateway Listeners together. If that is the case, the list of routes attached to those resources should @@ -109,16 +114,23 @@ spec: boundaries, there are specific rules. Cross-namespace references are only valid if they are explicitly allowed by something in the namespace they are referring to. For example, Gateway has the AllowedRoutes - field, and ReferenceGrant provides a generic way to enable any other - kind of cross-namespace reference." + field, and ReferenceGrant provides a generic way to enable other + kinds of cross-namespace reference. \n ParentRefs from a Route to + a Service in the same namespace are \"producer\" routes, which apply + default routing rules to inbound connections from any namespace + to the Service. ParentRefs from a Route to a Service in a different + namespace are \"consumer\" routes, and these routing rules are only + applied to outbound connections to the Service from the same namespace + as the Route." items: description: "ParentReference identifies an API object (usually a Gateway) that can be considered a parent of this resource (usually - a route). The only kind of parent resource with \"Core\" support - is Gateway. This API may be extended in the future to support - additional kinds of parent resources, such as HTTPRoute. \n The - API object must be valid in the cluster; the Group and Kind must - be registered in the cluster for this reference to be valid." + a route). The only kinds of parent resources with \"Core\" support + are Service (only for implementations supporting the Mesh conformance + profile) and Gateway. This API may be extended in the future to + support additional kinds of parent resources. \n The API object + must be valid in the cluster; the Group and Kind must be registered + in the cluster for this reference to be valid." properties: group: default: gateway.networking.k8s.io @@ -133,7 +145,8 @@ spec: kind: default: Gateway description: "Kind is kind of the referent. \n Support: Core - (Gateway) \n Support: Implementation-specific (Other Resources)" + (Gateway) \n Support: Core (Service - mesh conformance profile + only) \n Support: Implementation-specific (Other Resources)" maxLength: 63 minLength: 1 pattern: ^[a-zA-Z]([-a-zA-Z0-9]*[a-zA-Z0-9])?$ @@ -153,7 +166,13 @@ spec: the namespace they are referring to. For example: Gateway has the AllowedRoutes field, and ReferenceGrant provides a generic way to enable any other kind of cross-namespace reference. - \n Support: Core" + \n ParentRefs from a Route to a Service in the same namespace + are \"producer\" routes, which apply default routing rules + to inbound connections from any namespace to the Service. + ParentRefs from a Route to a Service in a different namespace + are \"consumer\" routes, and these routing rules are only + applied to outbound connections to the Service from the same + namespace as the Route. \n Support: Core" maxLength: 63 minLength: 1 pattern: ^[a-z0-9]([-a-z0-9]*[a-z0-9])?$ @@ -168,18 +187,22 @@ spec: a Route must apply to a specific port as opposed to a listener(s) whose port(s) may be changed. When both Port and SectionName are specified, the name and port of the selected listener - must match both specified values. \n Implementations MAY choose - to support other parent resources. Implementations supporting - other types of parent resources MUST clearly document how/if - Port is interpreted. \n For the purpose of status, an attachment - is considered successful as long as the parent resource accepts - it partially. For example, Gateway listeners can restrict - which Routes can attach to them by Route kind, namespace, - or hostname. If 1 of 2 Gateway listeners accept attachment - from the referencing Route, the Route MUST be considered successfully - attached. If no Gateway listeners accept attachment from this - Route, the Route MUST be considered detached from the Gateway. - \n Support: Extended \n " + must match both specified values. \n When the parent resource + is a Service, this targets a specific port in the Service + spec. When both Port (experimental) and SectionName are specified, + the name and port of the selected port must match both specified + values. \n Implementations MAY choose to support other parent + resources. Implementations supporting other types of parent + resources MUST clearly document how/if Port is interpreted. + \n For the purpose of status, an attachment is considered + successful as long as the parent resource accepts it partially. + For example, Gateway listeners can restrict which Routes can + attach to them by Route kind, namespace, or hostname. If 1 + of 2 Gateway listeners accept attachment from the referencing + Route, the Route MUST be considered successfully attached. + If no Gateway listeners accept attachment from this Route, + the Route MUST be considered detached from the Gateway. \n + Support: Extended \n " format: int32 maximum: 65535 minimum: 1 @@ -190,19 +213,22 @@ spec: interpreted as the following: \n * Gateway: Listener Name. When both Port (experimental) and SectionName are specified, the name and port of the selected listener must match both - specified values. \n Implementations MAY choose to support - attaching Routes to other resources. If that is the case, - they MUST clearly document how SectionName is interpreted. - \n When unspecified (empty string), this will reference the - entire resource. For the purpose of status, an attachment - is considered successful if at least one section in the parent - resource accepts it. For example, Gateway listeners can restrict - which Routes can attach to them by Route kind, namespace, - or hostname. If 1 of 2 Gateway listeners accept attachment - from the referencing Route, the Route MUST be considered successfully - attached. If no Gateway listeners accept attachment from this - Route, the Route MUST be considered detached from the Gateway. - \n Support: Core" + specified values. \n * Service: Named port. When both Port + (experimental) and SectionName are specified, the name and + port of the selected port must match both specified values. + \n Implementations MAY choose to support attaching Routes + to other resources. If that is the case, they MUST clearly + document how SectionName is interpreted. \n When unspecified + (empty string), this will reference the entire resource. For + the purpose of status, an attachment is considered successful + if at least one section in the parent resource accepts it. + For example, Gateway listeners can restrict which Routes can + attach to them by Route kind, namespace, or hostname. If 1 + of 2 Gateway listeners accept attachment from the referencing + Route, the Route MUST be considered successfully attached. + If no Gateway listeners accept attachment from this Route, + the Route MUST be considered detached from the Gateway. \n + Support: Core" maxLength: 253 minLength: 1 pattern: ^[a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*$ @@ -470,7 +496,8 @@ spec: kind: default: Gateway description: "Kind is kind of the referent. \n Support: - Core (Gateway) \n Support: Implementation-specific (Other + Core (Gateway) \n Support: Core (Service - mesh conformance + profile only) \n Support: Implementation-specific (Other Resources)" maxLength: 63 minLength: 1 @@ -491,7 +518,14 @@ spec: in the namespace they are referring to. For example: Gateway has the AllowedRoutes field, and ReferenceGrant provides a generic way to enable any other kind of cross-namespace - reference. \n Support: Core" + reference. \n ParentRefs from a Route to a Service in + the same namespace are \"producer\" routes, which apply + default routing rules to inbound connections from any + namespace to the Service. ParentRefs from a Route to a + Service in a different namespace are \"consumer\" routes, + and these routing rules are only applied to outbound connections + to the Service from the same namespace as the Route. \n + Support: Core" maxLength: 63 minLength: 1 pattern: ^[a-z0-9]([-a-z0-9]*[a-z0-9])?$ @@ -507,8 +541,12 @@ spec: a specific port as opposed to a listener(s) whose port(s) may be changed. When both Port and SectionName are specified, the name and port of the selected listener must match - both specified values. \n Implementations MAY choose to - support other parent resources. Implementations supporting + both specified values. \n When the parent resource is + a Service, this targets a specific port in the Service + spec. When both Port (experimental) and SectionName are + specified, the name and port of the selected port must + match both specified values. \n Implementations MAY choose + to support other parent resources. Implementations supporting other types of parent resources MUST clearly document how/if Port is interpreted. \n For the purpose of status, an attachment is considered successful as long as the @@ -530,9 +568,12 @@ spec: is interpreted as the following: \n * Gateway: Listener Name. When both Port (experimental) and SectionName are specified, the name and port of the selected listener - must match both specified values. \n Implementations MAY - choose to support attaching Routes to other resources. - If that is the case, they MUST clearly document how SectionName + must match both specified values. \n * Service: Named + port. When both Port (experimental) and SectionName are + specified, the name and port of the selected port must + match both specified values. \n Implementations MAY choose + to support attaching Routes to other resources. If that + is the case, they MUST clearly document how SectionName is interpreted. \n When unspecified (empty string), this will reference the entire resource. For the purpose of status, an attachment is considered successful if at least diff --git a/config/crd/experimental/gateway.networking.k8s.io_udproutes.yaml b/config/crd/experimental/gateway.networking.k8s.io_udproutes.yaml index 517d7a5018..de243dfdcc 100644 --- a/config/crd/experimental/gateway.networking.k8s.io_udproutes.yaml +++ b/config/crd/experimental/gateway.networking.k8s.io_udproutes.yaml @@ -49,13 +49,18 @@ spec: that a Route wants to be attached to. Note that the referenced parent resource needs to allow this for the attachment to be complete. For Gateways, that means the Gateway needs to allow attachment from - Routes of this kind and namespace. \n The only kind of parent resource - with \"Core\" support is Gateway. This API may be extended in the - future to support additional kinds of parent resources such as one - of the route kinds. \n It is invalid to reference an identical parent - more than once. It is valid to reference multiple distinct sections - within the same parent resource, such as 2 Listeners within a Gateway. - \n It is possible to separately reference multiple distinct objects + Routes of this kind and namespace. For Services, that means the + Service must either be in the same namespace for a \"producer\" + route, or the mesh implementation must support and allow \"consumer\" + routes for the referenced Service. \n The only kinds of parent resources + with \"Core\" support are Service (only for implementations supporting + the Mesh conformance profile) and Gateway. This API may be extended + in the future to support additional kinds of parent resources such + as one of the route kinds. \n It is invalid to reference an identical + parent more than once. It is valid to reference multiple distinct + sections within the same parent resource, such as two separate Listeners + on the same Gateway or two separate ports on the same Service. \n + It is possible to separately reference multiple distinct objects that may be collapsed by an implementation. For example, some implementations may choose to merge compatible Gateway Listeners together. If that is the case, the list of routes attached to those resources should @@ -63,16 +68,23 @@ spec: boundaries, there are specific rules. Cross-namespace references are only valid if they are explicitly allowed by something in the namespace they are referring to. For example, Gateway has the AllowedRoutes - field, and ReferenceGrant provides a generic way to enable any other - kind of cross-namespace reference." + field, and ReferenceGrant provides a generic way to enable other + kinds of cross-namespace reference. \n ParentRefs from a Route to + a Service in the same namespace are \"producer\" routes, which apply + default routing rules to inbound connections from any namespace + to the Service. ParentRefs from a Route to a Service in a different + namespace are \"consumer\" routes, and these routing rules are only + applied to outbound connections to the Service from the same namespace + as the Route." items: description: "ParentReference identifies an API object (usually a Gateway) that can be considered a parent of this resource (usually - a route). The only kind of parent resource with \"Core\" support - is Gateway. This API may be extended in the future to support - additional kinds of parent resources, such as HTTPRoute. \n The - API object must be valid in the cluster; the Group and Kind must - be registered in the cluster for this reference to be valid." + a route). The only kinds of parent resources with \"Core\" support + are Service (only for implementations supporting the Mesh conformance + profile) and Gateway. This API may be extended in the future to + support additional kinds of parent resources. \n The API object + must be valid in the cluster; the Group and Kind must be registered + in the cluster for this reference to be valid." properties: group: default: gateway.networking.k8s.io @@ -87,7 +99,8 @@ spec: kind: default: Gateway description: "Kind is kind of the referent. \n Support: Core - (Gateway) \n Support: Implementation-specific (Other Resources)" + (Gateway) \n Support: Core (Service - mesh conformance profile + only) \n Support: Implementation-specific (Other Resources)" maxLength: 63 minLength: 1 pattern: ^[a-zA-Z]([-a-zA-Z0-9]*[a-zA-Z0-9])?$ @@ -107,7 +120,13 @@ spec: the namespace they are referring to. For example: Gateway has the AllowedRoutes field, and ReferenceGrant provides a generic way to enable any other kind of cross-namespace reference. - \n Support: Core" + \n ParentRefs from a Route to a Service in the same namespace + are \"producer\" routes, which apply default routing rules + to inbound connections from any namespace to the Service. + ParentRefs from a Route to a Service in a different namespace + are \"consumer\" routes, and these routing rules are only + applied to outbound connections to the Service from the same + namespace as the Route. \n Support: Core" maxLength: 63 minLength: 1 pattern: ^[a-z0-9]([-a-z0-9]*[a-z0-9])?$ @@ -122,18 +141,22 @@ spec: a Route must apply to a specific port as opposed to a listener(s) whose port(s) may be changed. When both Port and SectionName are specified, the name and port of the selected listener - must match both specified values. \n Implementations MAY choose - to support other parent resources. Implementations supporting - other types of parent resources MUST clearly document how/if - Port is interpreted. \n For the purpose of status, an attachment - is considered successful as long as the parent resource accepts - it partially. For example, Gateway listeners can restrict - which Routes can attach to them by Route kind, namespace, - or hostname. If 1 of 2 Gateway listeners accept attachment - from the referencing Route, the Route MUST be considered successfully - attached. If no Gateway listeners accept attachment from this - Route, the Route MUST be considered detached from the Gateway. - \n Support: Extended \n " + must match both specified values. \n When the parent resource + is a Service, this targets a specific port in the Service + spec. When both Port (experimental) and SectionName are specified, + the name and port of the selected port must match both specified + values. \n Implementations MAY choose to support other parent + resources. Implementations supporting other types of parent + resources MUST clearly document how/if Port is interpreted. + \n For the purpose of status, an attachment is considered + successful as long as the parent resource accepts it partially. + For example, Gateway listeners can restrict which Routes can + attach to them by Route kind, namespace, or hostname. If 1 + of 2 Gateway listeners accept attachment from the referencing + Route, the Route MUST be considered successfully attached. + If no Gateway listeners accept attachment from this Route, + the Route MUST be considered detached from the Gateway. \n + Support: Extended \n " format: int32 maximum: 65535 minimum: 1 @@ -144,19 +167,22 @@ spec: interpreted as the following: \n * Gateway: Listener Name. When both Port (experimental) and SectionName are specified, the name and port of the selected listener must match both - specified values. \n Implementations MAY choose to support - attaching Routes to other resources. If that is the case, - they MUST clearly document how SectionName is interpreted. - \n When unspecified (empty string), this will reference the - entire resource. For the purpose of status, an attachment - is considered successful if at least one section in the parent - resource accepts it. For example, Gateway listeners can restrict - which Routes can attach to them by Route kind, namespace, - or hostname. If 1 of 2 Gateway listeners accept attachment - from the referencing Route, the Route MUST be considered successfully - attached. If no Gateway listeners accept attachment from this - Route, the Route MUST be considered detached from the Gateway. - \n Support: Core" + specified values. \n * Service: Named port. When both Port + (experimental) and SectionName are specified, the name and + port of the selected port must match both specified values. + \n Implementations MAY choose to support attaching Routes + to other resources. If that is the case, they MUST clearly + document how SectionName is interpreted. \n When unspecified + (empty string), this will reference the entire resource. For + the purpose of status, an attachment is considered successful + if at least one section in the parent resource accepts it. + For example, Gateway listeners can restrict which Routes can + attach to them by Route kind, namespace, or hostname. If 1 + of 2 Gateway listeners accept attachment from the referencing + Route, the Route MUST be considered successfully attached. + If no Gateway listeners accept attachment from this Route, + the Route MUST be considered detached from the Gateway. \n + Support: Core" maxLength: 253 minLength: 1 pattern: ^[a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*$ @@ -421,7 +447,8 @@ spec: kind: default: Gateway description: "Kind is kind of the referent. \n Support: - Core (Gateway) \n Support: Implementation-specific (Other + Core (Gateway) \n Support: Core (Service - mesh conformance + profile only) \n Support: Implementation-specific (Other Resources)" maxLength: 63 minLength: 1 @@ -442,7 +469,14 @@ spec: in the namespace they are referring to. For example: Gateway has the AllowedRoutes field, and ReferenceGrant provides a generic way to enable any other kind of cross-namespace - reference. \n Support: Core" + reference. \n ParentRefs from a Route to a Service in + the same namespace are \"producer\" routes, which apply + default routing rules to inbound connections from any + namespace to the Service. ParentRefs from a Route to a + Service in a different namespace are \"consumer\" routes, + and these routing rules are only applied to outbound connections + to the Service from the same namespace as the Route. \n + Support: Core" maxLength: 63 minLength: 1 pattern: ^[a-z0-9]([-a-z0-9]*[a-z0-9])?$ @@ -458,8 +492,12 @@ spec: a specific port as opposed to a listener(s) whose port(s) may be changed. When both Port and SectionName are specified, the name and port of the selected listener must match - both specified values. \n Implementations MAY choose to - support other parent resources. Implementations supporting + both specified values. \n When the parent resource is + a Service, this targets a specific port in the Service + spec. When both Port (experimental) and SectionName are + specified, the name and port of the selected port must + match both specified values. \n Implementations MAY choose + to support other parent resources. Implementations supporting other types of parent resources MUST clearly document how/if Port is interpreted. \n For the purpose of status, an attachment is considered successful as long as the @@ -481,9 +519,12 @@ spec: is interpreted as the following: \n * Gateway: Listener Name. When both Port (experimental) and SectionName are specified, the name and port of the selected listener - must match both specified values. \n Implementations MAY - choose to support attaching Routes to other resources. - If that is the case, they MUST clearly document how SectionName + must match both specified values. \n * Service: Named + port. When both Port (experimental) and SectionName are + specified, the name and port of the selected port must + match both specified values. \n Implementations MAY choose + to support attaching Routes to other resources. If that + is the case, they MUST clearly document how SectionName is interpreted. \n When unspecified (empty string), this will reference the entire resource. For the purpose of status, an attachment is considered successful if at least diff --git a/config/crd/standard/gateway.networking.k8s.io_httproutes.yaml b/config/crd/standard/gateway.networking.k8s.io_httproutes.yaml index ede1c0d29f..5e42681fcf 100644 --- a/config/crd/standard/gateway.networking.k8s.io_httproutes.yaml +++ b/config/crd/standard/gateway.networking.k8s.io_httproutes.yaml @@ -114,13 +114,18 @@ spec: that a Route wants to be attached to. Note that the referenced parent resource needs to allow this for the attachment to be complete. For Gateways, that means the Gateway needs to allow attachment from - Routes of this kind and namespace. \n The only kind of parent resource - with \"Core\" support is Gateway. This API may be extended in the - future to support additional kinds of parent resources such as one - of the route kinds. \n It is invalid to reference an identical parent - more than once. It is valid to reference multiple distinct sections - within the same parent resource, such as 2 Listeners within a Gateway. - \n It is possible to separately reference multiple distinct objects + Routes of this kind and namespace. For Services, that means the + Service must either be in the same namespace for a \"producer\" + route, or the mesh implementation must support and allow \"consumer\" + routes for the referenced Service. \n The only kinds of parent resources + with \"Core\" support are Service (only for implementations supporting + the Mesh conformance profile) and Gateway. This API may be extended + in the future to support additional kinds of parent resources such + as one of the route kinds. \n It is invalid to reference an identical + parent more than once. It is valid to reference multiple distinct + sections within the same parent resource, such as two separate Listeners + on the same Gateway or two separate ports on the same Service. \n + It is possible to separately reference multiple distinct objects that may be collapsed by an implementation. For example, some implementations may choose to merge compatible Gateway Listeners together. If that is the case, the list of routes attached to those resources should @@ -128,16 +133,23 @@ spec: boundaries, there are specific rules. Cross-namespace references are only valid if they are explicitly allowed by something in the namespace they are referring to. For example, Gateway has the AllowedRoutes - field, and ReferenceGrant provides a generic way to enable any other - kind of cross-namespace reference." + field, and ReferenceGrant provides a generic way to enable other + kinds of cross-namespace reference. \n ParentRefs from a Route to + a Service in the same namespace are \"producer\" routes, which apply + default routing rules to inbound connections from any namespace + to the Service. ParentRefs from a Route to a Service in a different + namespace are \"consumer\" routes, and these routing rules are only + applied to outbound connections to the Service from the same namespace + as the Route." items: description: "ParentReference identifies an API object (usually a Gateway) that can be considered a parent of this resource (usually - a route). The only kind of parent resource with \"Core\" support - is Gateway. This API may be extended in the future to support - additional kinds of parent resources, such as HTTPRoute. \n The - API object must be valid in the cluster; the Group and Kind must - be registered in the cluster for this reference to be valid." + a route). The only kinds of parent resources with \"Core\" support + are Service (only for implementations supporting the Mesh conformance + profile) and Gateway. This API may be extended in the future to + support additional kinds of parent resources. \n The API object + must be valid in the cluster; the Group and Kind must be registered + in the cluster for this reference to be valid." properties: group: default: gateway.networking.k8s.io @@ -152,7 +164,8 @@ spec: kind: default: Gateway description: "Kind is kind of the referent. \n Support: Core - (Gateway) \n Support: Implementation-specific (Other Resources)" + (Gateway) \n Support: Core (Service - mesh conformance profile + only) \n Support: Implementation-specific (Other Resources)" maxLength: 63 minLength: 1 pattern: ^[a-zA-Z]([-a-zA-Z0-9]*[a-zA-Z0-9])?$ @@ -172,7 +185,13 @@ spec: the namespace they are referring to. For example: Gateway has the AllowedRoutes field, and ReferenceGrant provides a generic way to enable any other kind of cross-namespace reference. - \n Support: Core" + \n ParentRefs from a Route to a Service in the same namespace + are \"producer\" routes, which apply default routing rules + to inbound connections from any namespace to the Service. + ParentRefs from a Route to a Service in a different namespace + are \"consumer\" routes, and these routing rules are only + applied to outbound connections to the Service from the same + namespace as the Route. \n Support: Core" maxLength: 63 minLength: 1 pattern: ^[a-z0-9]([-a-z0-9]*[a-z0-9])?$ @@ -183,19 +202,22 @@ spec: interpreted as the following: \n * Gateway: Listener Name. When both Port (experimental) and SectionName are specified, the name and port of the selected listener must match both - specified values. \n Implementations MAY choose to support - attaching Routes to other resources. If that is the case, - they MUST clearly document how SectionName is interpreted. - \n When unspecified (empty string), this will reference the - entire resource. For the purpose of status, an attachment - is considered successful if at least one section in the parent - resource accepts it. For example, Gateway listeners can restrict - which Routes can attach to them by Route kind, namespace, - or hostname. If 1 of 2 Gateway listeners accept attachment - from the referencing Route, the Route MUST be considered successfully - attached. If no Gateway listeners accept attachment from this - Route, the Route MUST be considered detached from the Gateway. - \n Support: Core" + specified values. \n * Service: Named port. When both Port + (experimental) and SectionName are specified, the name and + port of the selected port must match both specified values. + \n Implementations MAY choose to support attaching Routes + to other resources. If that is the case, they MUST clearly + document how SectionName is interpreted. \n When unspecified + (empty string), this will reference the entire resource. For + the purpose of status, an attachment is considered successful + if at least one section in the parent resource accepts it. + For example, Gateway listeners can restrict which Routes can + attach to them by Route kind, namespace, or hostname. If 1 + of 2 Gateway listeners accept attachment from the referencing + Route, the Route MUST be considered successfully attached. + If no Gateway listeners accept attachment from this Route, + the Route MUST be considered detached from the Gateway. \n + Support: Core" maxLength: 253 minLength: 1 pattern: ^[a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*$ @@ -1886,7 +1908,8 @@ spec: kind: default: Gateway description: "Kind is kind of the referent. \n Support: - Core (Gateway) \n Support: Implementation-specific (Other + Core (Gateway) \n Support: Core (Service - mesh conformance + profile only) \n Support: Implementation-specific (Other Resources)" maxLength: 63 minLength: 1 @@ -1907,7 +1930,14 @@ spec: in the namespace they are referring to. For example: Gateway has the AllowedRoutes field, and ReferenceGrant provides a generic way to enable any other kind of cross-namespace - reference. \n Support: Core" + reference. \n ParentRefs from a Route to a Service in + the same namespace are \"producer\" routes, which apply + default routing rules to inbound connections from any + namespace to the Service. ParentRefs from a Route to a + Service in a different namespace are \"consumer\" routes, + and these routing rules are only applied to outbound connections + to the Service from the same namespace as the Route. \n + Support: Core" maxLength: 63 minLength: 1 pattern: ^[a-z0-9]([-a-z0-9]*[a-z0-9])?$ @@ -1918,9 +1948,12 @@ spec: is interpreted as the following: \n * Gateway: Listener Name. When both Port (experimental) and SectionName are specified, the name and port of the selected listener - must match both specified values. \n Implementations MAY - choose to support attaching Routes to other resources. - If that is the case, they MUST clearly document how SectionName + must match both specified values. \n * Service: Named + port. When both Port (experimental) and SectionName are + specified, the name and port of the selected port must + match both specified values. \n Implementations MAY choose + to support attaching Routes to other resources. If that + is the case, they MUST clearly document how SectionName is interpreted. \n When unspecified (empty string), this will reference the entire resource. For the purpose of status, an attachment is considered successful if at least @@ -2048,13 +2081,18 @@ spec: that a Route wants to be attached to. Note that the referenced parent resource needs to allow this for the attachment to be complete. For Gateways, that means the Gateway needs to allow attachment from - Routes of this kind and namespace. \n The only kind of parent resource - with \"Core\" support is Gateway. This API may be extended in the - future to support additional kinds of parent resources such as one - of the route kinds. \n It is invalid to reference an identical parent - more than once. It is valid to reference multiple distinct sections - within the same parent resource, such as 2 Listeners within a Gateway. - \n It is possible to separately reference multiple distinct objects + Routes of this kind and namespace. For Services, that means the + Service must either be in the same namespace for a \"producer\" + route, or the mesh implementation must support and allow \"consumer\" + routes for the referenced Service. \n The only kinds of parent resources + with \"Core\" support are Service (only for implementations supporting + the Mesh conformance profile) and Gateway. This API may be extended + in the future to support additional kinds of parent resources such + as one of the route kinds. \n It is invalid to reference an identical + parent more than once. It is valid to reference multiple distinct + sections within the same parent resource, such as two separate Listeners + on the same Gateway or two separate ports on the same Service. \n + It is possible to separately reference multiple distinct objects that may be collapsed by an implementation. For example, some implementations may choose to merge compatible Gateway Listeners together. If that is the case, the list of routes attached to those resources should @@ -2062,16 +2100,23 @@ spec: boundaries, there are specific rules. Cross-namespace references are only valid if they are explicitly allowed by something in the namespace they are referring to. For example, Gateway has the AllowedRoutes - field, and ReferenceGrant provides a generic way to enable any other - kind of cross-namespace reference." + field, and ReferenceGrant provides a generic way to enable other + kinds of cross-namespace reference. \n ParentRefs from a Route to + a Service in the same namespace are \"producer\" routes, which apply + default routing rules to inbound connections from any namespace + to the Service. ParentRefs from a Route to a Service in a different + namespace are \"consumer\" routes, and these routing rules are only + applied to outbound connections to the Service from the same namespace + as the Route." items: description: "ParentReference identifies an API object (usually a Gateway) that can be considered a parent of this resource (usually - a route). The only kind of parent resource with \"Core\" support - is Gateway. This API may be extended in the future to support - additional kinds of parent resources, such as HTTPRoute. \n The - API object must be valid in the cluster; the Group and Kind must - be registered in the cluster for this reference to be valid." + a route). The only kinds of parent resources with \"Core\" support + are Service (only for implementations supporting the Mesh conformance + profile) and Gateway. This API may be extended in the future to + support additional kinds of parent resources. \n The API object + must be valid in the cluster; the Group and Kind must be registered + in the cluster for this reference to be valid." properties: group: default: gateway.networking.k8s.io @@ -2086,7 +2131,8 @@ spec: kind: default: Gateway description: "Kind is kind of the referent. \n Support: Core - (Gateway) \n Support: Implementation-specific (Other Resources)" + (Gateway) \n Support: Core (Service - mesh conformance profile + only) \n Support: Implementation-specific (Other Resources)" maxLength: 63 minLength: 1 pattern: ^[a-zA-Z]([-a-zA-Z0-9]*[a-zA-Z0-9])?$ @@ -2106,7 +2152,13 @@ spec: the namespace they are referring to. For example: Gateway has the AllowedRoutes field, and ReferenceGrant provides a generic way to enable any other kind of cross-namespace reference. - \n Support: Core" + \n ParentRefs from a Route to a Service in the same namespace + are \"producer\" routes, which apply default routing rules + to inbound connections from any namespace to the Service. + ParentRefs from a Route to a Service in a different namespace + are \"consumer\" routes, and these routing rules are only + applied to outbound connections to the Service from the same + namespace as the Route. \n Support: Core" maxLength: 63 minLength: 1 pattern: ^[a-z0-9]([-a-z0-9]*[a-z0-9])?$ @@ -2117,19 +2169,22 @@ spec: interpreted as the following: \n * Gateway: Listener Name. When both Port (experimental) and SectionName are specified, the name and port of the selected listener must match both - specified values. \n Implementations MAY choose to support - attaching Routes to other resources. If that is the case, - they MUST clearly document how SectionName is interpreted. - \n When unspecified (empty string), this will reference the - entire resource. For the purpose of status, an attachment - is considered successful if at least one section in the parent - resource accepts it. For example, Gateway listeners can restrict - which Routes can attach to them by Route kind, namespace, - or hostname. If 1 of 2 Gateway listeners accept attachment - from the referencing Route, the Route MUST be considered successfully - attached. If no Gateway listeners accept attachment from this - Route, the Route MUST be considered detached from the Gateway. - \n Support: Core" + specified values. \n * Service: Named port. When both Port + (experimental) and SectionName are specified, the name and + port of the selected port must match both specified values. + \n Implementations MAY choose to support attaching Routes + to other resources. If that is the case, they MUST clearly + document how SectionName is interpreted. \n When unspecified + (empty string), this will reference the entire resource. For + the purpose of status, an attachment is considered successful + if at least one section in the parent resource accepts it. + For example, Gateway listeners can restrict which Routes can + attach to them by Route kind, namespace, or hostname. If 1 + of 2 Gateway listeners accept attachment from the referencing + Route, the Route MUST be considered successfully attached. + If no Gateway listeners accept attachment from this Route, + the Route MUST be considered detached from the Gateway. \n + Support: Core" maxLength: 253 minLength: 1 pattern: ^[a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*$ @@ -3820,7 +3875,8 @@ spec: kind: default: Gateway description: "Kind is kind of the referent. \n Support: - Core (Gateway) \n Support: Implementation-specific (Other + Core (Gateway) \n Support: Core (Service - mesh conformance + profile only) \n Support: Implementation-specific (Other Resources)" maxLength: 63 minLength: 1 @@ -3841,7 +3897,14 @@ spec: in the namespace they are referring to. For example: Gateway has the AllowedRoutes field, and ReferenceGrant provides a generic way to enable any other kind of cross-namespace - reference. \n Support: Core" + reference. \n ParentRefs from a Route to a Service in + the same namespace are \"producer\" routes, which apply + default routing rules to inbound connections from any + namespace to the Service. ParentRefs from a Route to a + Service in a different namespace are \"consumer\" routes, + and these routing rules are only applied to outbound connections + to the Service from the same namespace as the Route. \n + Support: Core" maxLength: 63 minLength: 1 pattern: ^[a-z0-9]([-a-z0-9]*[a-z0-9])?$ @@ -3852,9 +3915,12 @@ spec: is interpreted as the following: \n * Gateway: Listener Name. When both Port (experimental) and SectionName are specified, the name and port of the selected listener - must match both specified values. \n Implementations MAY - choose to support attaching Routes to other resources. - If that is the case, they MUST clearly document how SectionName + must match both specified values. \n * Service: Named + port. When both Port (experimental) and SectionName are + specified, the name and port of the selected port must + match both specified values. \n Implementations MAY choose + to support attaching Routes to other resources. If that + is the case, they MUST clearly document how SectionName is interpreted. \n When unspecified (empty string), this will reference the entire resource. For the purpose of status, an attachment is considered successful if at least From fb6e2e4c773aeaf6f555035cb59f6bf1bbdb6f39 Mon Sep 17 00:00:00 2001 From: Mike Morris Date: Wed, 28 Jun 2023 14:43:56 -0400 Subject: [PATCH 03/14] Update apis/v1beta1/shared_types.go Co-authored-by: Rob Scott --- apis/v1beta1/shared_types.go | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/apis/v1beta1/shared_types.go b/apis/v1beta1/shared_types.go index 643ee40e59..c01671e0e7 100644 --- a/apis/v1beta1/shared_types.go +++ b/apis/v1beta1/shared_types.go @@ -85,7 +85,7 @@ type ParentReference struct { // are specified, the name and port of the selected listener must match // both specified values. // - // * Service: Named port. When both Port (experimental) and SectionName + // * Service: Port Name. When both Port (experimental) and SectionName // are specified, the name and port of the selected port must match // both specified values. // From 5cab2e8f3a51ecab7716d6846a4421aefb3cdfe3 Mon Sep 17 00:00:00 2001 From: Mike Morris Date: Wed, 28 Jun 2023 14:54:42 -0400 Subject: [PATCH 04/14] remove SectionName for Service ParentRef port selection --- apis/v1beta1/shared_types.go | 4 ---- 1 file changed, 4 deletions(-) diff --git a/apis/v1beta1/shared_types.go b/apis/v1beta1/shared_types.go index c01671e0e7..d9430f2a4c 100644 --- a/apis/v1beta1/shared_types.go +++ b/apis/v1beta1/shared_types.go @@ -85,10 +85,6 @@ type ParentReference struct { // are specified, the name and port of the selected listener must match // both specified values. // - // * Service: Port Name. When both Port (experimental) and SectionName - // are specified, the name and port of the selected port must match - // both specified values. - // // Implementations MAY choose to support attaching Routes to other resources. // If that is the case, they MUST clearly document how SectionName is // interpreted. From b1d32f0111b891e03385ab4b528b1b5c289dfe60 Mon Sep 17 00:00:00 2001 From: Mike Morris Date: Wed, 28 Jun 2023 14:56:27 -0400 Subject: [PATCH 05/14] break consumer routes section into new paragraph --- apis/v1beta1/shared_types.go | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/apis/v1beta1/shared_types.go b/apis/v1beta1/shared_types.go index d9430f2a4c..ccc0033141 100644 --- a/apis/v1beta1/shared_types.go +++ b/apis/v1beta1/shared_types.go @@ -63,10 +63,11 @@ type ParentReference struct { // // ParentRefs from a Route to a Service in the same namespace are "producer" // routes, which apply default routing rules to inbound connections from - // any namespace to the Service. ParentRefs from a Route to a Service in a - // different namespace are "consumer" routes, and these routing rules are - // only applied to outbound connections to the Service from the same - // namespace as the Route. + // any namespace to the Service. + // + // ParentRefs from a Route to a Service in a different namespace are + // "consumer" routes, and these routing rules are only applied to outbound + // connections to the Service from the same namespace as the Route. // // Support: Core // From 581eb6d837811d356ab23fa7aa87ef34868acb47 Mon Sep 17 00:00:00 2001 From: Mike Morris Date: Wed, 28 Jun 2023 15:00:23 -0400 Subject: [PATCH 06/14] update CRDs --- .../gateway.networking.k8s.io_grpcroutes.yaml | 44 ++++------ .../gateway.networking.k8s.io_httproutes.yaml | 88 ++++++++----------- .../gateway.networking.k8s.io_tcproutes.yaml | 44 ++++------ .../gateway.networking.k8s.io_tlsroutes.yaml | 44 ++++------ .../gateway.networking.k8s.io_udproutes.yaml | 44 ++++------ .../gateway.networking.k8s.io_httproutes.yaml | 88 ++++++++----------- 6 files changed, 152 insertions(+), 200 deletions(-) diff --git a/config/crd/experimental/gateway.networking.k8s.io_grpcroutes.yaml b/config/crd/experimental/gateway.networking.k8s.io_grpcroutes.yaml index c40dd20ce8..8379c9cca7 100644 --- a/config/crd/experimental/gateway.networking.k8s.io_grpcroutes.yaml +++ b/config/crd/experimental/gateway.networking.k8s.io_grpcroutes.yaml @@ -201,7 +201,7 @@ spec: \n ParentRefs from a Route to a Service in the same namespace are \"producer\" routes, which apply default routing rules to inbound connections from any namespace to the Service. - ParentRefs from a Route to a Service in a different namespace + \n ParentRefs from a Route to a Service in a different namespace are \"consumer\" routes, and these routing rules are only applied to outbound connections to the Service from the same namespace as the Route. \n Support: Core" @@ -245,22 +245,19 @@ spec: interpreted as the following: \n * Gateway: Listener Name. When both Port (experimental) and SectionName are specified, the name and port of the selected listener must match both - specified values. \n * Service: Named port. When both Port - (experimental) and SectionName are specified, the name and - port of the selected port must match both specified values. - \n Implementations MAY choose to support attaching Routes - to other resources. If that is the case, they MUST clearly - document how SectionName is interpreted. \n When unspecified - (empty string), this will reference the entire resource. For - the purpose of status, an attachment is considered successful - if at least one section in the parent resource accepts it. - For example, Gateway listeners can restrict which Routes can - attach to them by Route kind, namespace, or hostname. If 1 - of 2 Gateway listeners accept attachment from the referencing - Route, the Route MUST be considered successfully attached. - If no Gateway listeners accept attachment from this Route, - the Route MUST be considered detached from the Gateway. \n - Support: Core" + specified values. \n Implementations MAY choose to support + attaching Routes to other resources. If that is the case, + they MUST clearly document how SectionName is interpreted. + \n When unspecified (empty string), this will reference the + entire resource. For the purpose of status, an attachment + is considered successful if at least one section in the parent + resource accepts it. For example, Gateway listeners can restrict + which Routes can attach to them by Route kind, namespace, + or hostname. If 1 of 2 Gateway listeners accept attachment + from the referencing Route, the Route MUST be considered successfully + attached. If no Gateway listeners accept attachment from this + Route, the Route MUST be considered detached from the Gateway. + \n Support: Core" maxLength: 253 minLength: 1 pattern: ^[a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*$ @@ -1447,8 +1444,8 @@ spec: reference. \n ParentRefs from a Route to a Service in the same namespace are \"producer\" routes, which apply default routing rules to inbound connections from any - namespace to the Service. ParentRefs from a Route to a - Service in a different namespace are \"consumer\" routes, + namespace to the Service. \n ParentRefs from a Route to + a Service in a different namespace are \"consumer\" routes, and these routing rules are only applied to outbound connections to the Service from the same namespace as the Route. \n Support: Core" @@ -1494,12 +1491,9 @@ spec: is interpreted as the following: \n * Gateway: Listener Name. When both Port (experimental) and SectionName are specified, the name and port of the selected listener - must match both specified values. \n * Service: Named - port. When both Port (experimental) and SectionName are - specified, the name and port of the selected port must - match both specified values. \n Implementations MAY choose - to support attaching Routes to other resources. If that - is the case, they MUST clearly document how SectionName + must match both specified values. \n Implementations MAY + choose to support attaching Routes to other resources. + If that is the case, they MUST clearly document how SectionName is interpreted. \n When unspecified (empty string), this will reference the entire resource. For the purpose of status, an attachment is considered successful if at least diff --git a/config/crd/experimental/gateway.networking.k8s.io_httproutes.yaml b/config/crd/experimental/gateway.networking.k8s.io_httproutes.yaml index 951340395a..76d61f4d1a 100644 --- a/config/crd/experimental/gateway.networking.k8s.io_httproutes.yaml +++ b/config/crd/experimental/gateway.networking.k8s.io_httproutes.yaml @@ -188,7 +188,7 @@ spec: \n ParentRefs from a Route to a Service in the same namespace are \"producer\" routes, which apply default routing rules to inbound connections from any namespace to the Service. - ParentRefs from a Route to a Service in a different namespace + \n ParentRefs from a Route to a Service in a different namespace are \"consumer\" routes, and these routing rules are only applied to outbound connections to the Service from the same namespace as the Route. \n Support: Core" @@ -232,22 +232,19 @@ spec: interpreted as the following: \n * Gateway: Listener Name. When both Port (experimental) and SectionName are specified, the name and port of the selected listener must match both - specified values. \n * Service: Named port. When both Port - (experimental) and SectionName are specified, the name and - port of the selected port must match both specified values. - \n Implementations MAY choose to support attaching Routes - to other resources. If that is the case, they MUST clearly - document how SectionName is interpreted. \n When unspecified - (empty string), this will reference the entire resource. For - the purpose of status, an attachment is considered successful - if at least one section in the parent resource accepts it. - For example, Gateway listeners can restrict which Routes can - attach to them by Route kind, namespace, or hostname. If 1 - of 2 Gateway listeners accept attachment from the referencing - Route, the Route MUST be considered successfully attached. - If no Gateway listeners accept attachment from this Route, - the Route MUST be considered detached from the Gateway. \n - Support: Core" + specified values. \n Implementations MAY choose to support + attaching Routes to other resources. If that is the case, + they MUST clearly document how SectionName is interpreted. + \n When unspecified (empty string), this will reference the + entire resource. For the purpose of status, an attachment + is considered successful if at least one section in the parent + resource accepts it. For example, Gateway listeners can restrict + which Routes can attach to them by Route kind, namespace, + or hostname. If 1 of 2 Gateway listeners accept attachment + from the referencing Route, the Route MUST be considered successfully + attached. If no Gateway listeners accept attachment from this + Route, the Route MUST be considered detached from the Gateway. + \n Support: Core" maxLength: 253 minLength: 1 pattern: ^[a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*$ @@ -1963,8 +1960,8 @@ spec: reference. \n ParentRefs from a Route to a Service in the same namespace are \"producer\" routes, which apply default routing rules to inbound connections from any - namespace to the Service. ParentRefs from a Route to a - Service in a different namespace are \"consumer\" routes, + namespace to the Service. \n ParentRefs from a Route to + a Service in a different namespace are \"consumer\" routes, and these routing rules are only applied to outbound connections to the Service from the same namespace as the Route. \n Support: Core" @@ -2010,12 +2007,9 @@ spec: is interpreted as the following: \n * Gateway: Listener Name. When both Port (experimental) and SectionName are specified, the name and port of the selected listener - must match both specified values. \n * Service: Named - port. When both Port (experimental) and SectionName are - specified, the name and port of the selected port must - match both specified values. \n Implementations MAY choose - to support attaching Routes to other resources. If that - is the case, they MUST clearly document how SectionName + must match both specified values. \n Implementations MAY + choose to support attaching Routes to other resources. + If that is the case, they MUST clearly document how SectionName is interpreted. \n When unspecified (empty string), this will reference the entire resource. For the purpose of status, an attachment is considered successful if at least @@ -2217,7 +2211,7 @@ spec: \n ParentRefs from a Route to a Service in the same namespace are \"producer\" routes, which apply default routing rules to inbound connections from any namespace to the Service. - ParentRefs from a Route to a Service in a different namespace + \n ParentRefs from a Route to a Service in a different namespace are \"consumer\" routes, and these routing rules are only applied to outbound connections to the Service from the same namespace as the Route. \n Support: Core" @@ -2261,22 +2255,19 @@ spec: interpreted as the following: \n * Gateway: Listener Name. When both Port (experimental) and SectionName are specified, the name and port of the selected listener must match both - specified values. \n * Service: Named port. When both Port - (experimental) and SectionName are specified, the name and - port of the selected port must match both specified values. - \n Implementations MAY choose to support attaching Routes - to other resources. If that is the case, they MUST clearly - document how SectionName is interpreted. \n When unspecified - (empty string), this will reference the entire resource. For - the purpose of status, an attachment is considered successful - if at least one section in the parent resource accepts it. - For example, Gateway listeners can restrict which Routes can - attach to them by Route kind, namespace, or hostname. If 1 - of 2 Gateway listeners accept attachment from the referencing - Route, the Route MUST be considered successfully attached. - If no Gateway listeners accept attachment from this Route, - the Route MUST be considered detached from the Gateway. \n - Support: Core" + specified values. \n Implementations MAY choose to support + attaching Routes to other resources. If that is the case, + they MUST clearly document how SectionName is interpreted. + \n When unspecified (empty string), this will reference the + entire resource. For the purpose of status, an attachment + is considered successful if at least one section in the parent + resource accepts it. For example, Gateway listeners can restrict + which Routes can attach to them by Route kind, namespace, + or hostname. If 1 of 2 Gateway listeners accept attachment + from the referencing Route, the Route MUST be considered successfully + attached. If no Gateway listeners accept attachment from this + Route, the Route MUST be considered detached from the Gateway. + \n Support: Core" maxLength: 253 minLength: 1 pattern: ^[a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*$ @@ -3992,8 +3983,8 @@ spec: reference. \n ParentRefs from a Route to a Service in the same namespace are \"producer\" routes, which apply default routing rules to inbound connections from any - namespace to the Service. ParentRefs from a Route to a - Service in a different namespace are \"consumer\" routes, + namespace to the Service. \n ParentRefs from a Route to + a Service in a different namespace are \"consumer\" routes, and these routing rules are only applied to outbound connections to the Service from the same namespace as the Route. \n Support: Core" @@ -4039,12 +4030,9 @@ spec: is interpreted as the following: \n * Gateway: Listener Name. When both Port (experimental) and SectionName are specified, the name and port of the selected listener - must match both specified values. \n * Service: Named - port. When both Port (experimental) and SectionName are - specified, the name and port of the selected port must - match both specified values. \n Implementations MAY choose - to support attaching Routes to other resources. If that - is the case, they MUST clearly document how SectionName + must match both specified values. \n Implementations MAY + choose to support attaching Routes to other resources. + If that is the case, they MUST clearly document how SectionName is interpreted. \n When unspecified (empty string), this will reference the entire resource. For the purpose of status, an attachment is considered successful if at least diff --git a/config/crd/experimental/gateway.networking.k8s.io_tcproutes.yaml b/config/crd/experimental/gateway.networking.k8s.io_tcproutes.yaml index f9cb172a66..6744d90b4c 100644 --- a/config/crd/experimental/gateway.networking.k8s.io_tcproutes.yaml +++ b/config/crd/experimental/gateway.networking.k8s.io_tcproutes.yaml @@ -123,7 +123,7 @@ spec: \n ParentRefs from a Route to a Service in the same namespace are \"producer\" routes, which apply default routing rules to inbound connections from any namespace to the Service. - ParentRefs from a Route to a Service in a different namespace + \n ParentRefs from a Route to a Service in a different namespace are \"consumer\" routes, and these routing rules are only applied to outbound connections to the Service from the same namespace as the Route. \n Support: Core" @@ -167,22 +167,19 @@ spec: interpreted as the following: \n * Gateway: Listener Name. When both Port (experimental) and SectionName are specified, the name and port of the selected listener must match both - specified values. \n * Service: Named port. When both Port - (experimental) and SectionName are specified, the name and - port of the selected port must match both specified values. - \n Implementations MAY choose to support attaching Routes - to other resources. If that is the case, they MUST clearly - document how SectionName is interpreted. \n When unspecified - (empty string), this will reference the entire resource. For - the purpose of status, an attachment is considered successful - if at least one section in the parent resource accepts it. - For example, Gateway listeners can restrict which Routes can - attach to them by Route kind, namespace, or hostname. If 1 - of 2 Gateway listeners accept attachment from the referencing - Route, the Route MUST be considered successfully attached. - If no Gateway listeners accept attachment from this Route, - the Route MUST be considered detached from the Gateway. \n - Support: Core" + specified values. \n Implementations MAY choose to support + attaching Routes to other resources. If that is the case, + they MUST clearly document how SectionName is interpreted. + \n When unspecified (empty string), this will reference the + entire resource. For the purpose of status, an attachment + is considered successful if at least one section in the parent + resource accepts it. For example, Gateway listeners can restrict + which Routes can attach to them by Route kind, namespace, + or hostname. If 1 of 2 Gateway listeners accept attachment + from the referencing Route, the Route MUST be considered successfully + attached. If no Gateway listeners accept attachment from this + Route, the Route MUST be considered detached from the Gateway. + \n Support: Core" maxLength: 253 minLength: 1 pattern: ^[a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*$ @@ -472,8 +469,8 @@ spec: reference. \n ParentRefs from a Route to a Service in the same namespace are \"producer\" routes, which apply default routing rules to inbound connections from any - namespace to the Service. ParentRefs from a Route to a - Service in a different namespace are \"consumer\" routes, + namespace to the Service. \n ParentRefs from a Route to + a Service in a different namespace are \"consumer\" routes, and these routing rules are only applied to outbound connections to the Service from the same namespace as the Route. \n Support: Core" @@ -519,12 +516,9 @@ spec: is interpreted as the following: \n * Gateway: Listener Name. When both Port (experimental) and SectionName are specified, the name and port of the selected listener - must match both specified values. \n * Service: Named - port. When both Port (experimental) and SectionName are - specified, the name and port of the selected port must - match both specified values. \n Implementations MAY choose - to support attaching Routes to other resources. If that - is the case, they MUST clearly document how SectionName + must match both specified values. \n Implementations MAY + choose to support attaching Routes to other resources. + If that is the case, they MUST clearly document how SectionName is interpreted. \n When unspecified (empty string), this will reference the entire resource. For the purpose of status, an attachment is considered successful if at least diff --git a/config/crd/experimental/gateway.networking.k8s.io_tlsroutes.yaml b/config/crd/experimental/gateway.networking.k8s.io_tlsroutes.yaml index ef14aa8280..1aed50cab2 100644 --- a/config/crd/experimental/gateway.networking.k8s.io_tlsroutes.yaml +++ b/config/crd/experimental/gateway.networking.k8s.io_tlsroutes.yaml @@ -169,7 +169,7 @@ spec: \n ParentRefs from a Route to a Service in the same namespace are \"producer\" routes, which apply default routing rules to inbound connections from any namespace to the Service. - ParentRefs from a Route to a Service in a different namespace + \n ParentRefs from a Route to a Service in a different namespace are \"consumer\" routes, and these routing rules are only applied to outbound connections to the Service from the same namespace as the Route. \n Support: Core" @@ -213,22 +213,19 @@ spec: interpreted as the following: \n * Gateway: Listener Name. When both Port (experimental) and SectionName are specified, the name and port of the selected listener must match both - specified values. \n * Service: Named port. When both Port - (experimental) and SectionName are specified, the name and - port of the selected port must match both specified values. - \n Implementations MAY choose to support attaching Routes - to other resources. If that is the case, they MUST clearly - document how SectionName is interpreted. \n When unspecified - (empty string), this will reference the entire resource. For - the purpose of status, an attachment is considered successful - if at least one section in the parent resource accepts it. - For example, Gateway listeners can restrict which Routes can - attach to them by Route kind, namespace, or hostname. If 1 - of 2 Gateway listeners accept attachment from the referencing - Route, the Route MUST be considered successfully attached. - If no Gateway listeners accept attachment from this Route, - the Route MUST be considered detached from the Gateway. \n - Support: Core" + specified values. \n Implementations MAY choose to support + attaching Routes to other resources. If that is the case, + they MUST clearly document how SectionName is interpreted. + \n When unspecified (empty string), this will reference the + entire resource. For the purpose of status, an attachment + is considered successful if at least one section in the parent + resource accepts it. For example, Gateway listeners can restrict + which Routes can attach to them by Route kind, namespace, + or hostname. If 1 of 2 Gateway listeners accept attachment + from the referencing Route, the Route MUST be considered successfully + attached. If no Gateway listeners accept attachment from this + Route, the Route MUST be considered detached from the Gateway. + \n Support: Core" maxLength: 253 minLength: 1 pattern: ^[a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*$ @@ -521,8 +518,8 @@ spec: reference. \n ParentRefs from a Route to a Service in the same namespace are \"producer\" routes, which apply default routing rules to inbound connections from any - namespace to the Service. ParentRefs from a Route to a - Service in a different namespace are \"consumer\" routes, + namespace to the Service. \n ParentRefs from a Route to + a Service in a different namespace are \"consumer\" routes, and these routing rules are only applied to outbound connections to the Service from the same namespace as the Route. \n Support: Core" @@ -568,12 +565,9 @@ spec: is interpreted as the following: \n * Gateway: Listener Name. When both Port (experimental) and SectionName are specified, the name and port of the selected listener - must match both specified values. \n * Service: Named - port. When both Port (experimental) and SectionName are - specified, the name and port of the selected port must - match both specified values. \n Implementations MAY choose - to support attaching Routes to other resources. If that - is the case, they MUST clearly document how SectionName + must match both specified values. \n Implementations MAY + choose to support attaching Routes to other resources. + If that is the case, they MUST clearly document how SectionName is interpreted. \n When unspecified (empty string), this will reference the entire resource. For the purpose of status, an attachment is considered successful if at least diff --git a/config/crd/experimental/gateway.networking.k8s.io_udproutes.yaml b/config/crd/experimental/gateway.networking.k8s.io_udproutes.yaml index de243dfdcc..db3f0f55e7 100644 --- a/config/crd/experimental/gateway.networking.k8s.io_udproutes.yaml +++ b/config/crd/experimental/gateway.networking.k8s.io_udproutes.yaml @@ -123,7 +123,7 @@ spec: \n ParentRefs from a Route to a Service in the same namespace are \"producer\" routes, which apply default routing rules to inbound connections from any namespace to the Service. - ParentRefs from a Route to a Service in a different namespace + \n ParentRefs from a Route to a Service in a different namespace are \"consumer\" routes, and these routing rules are only applied to outbound connections to the Service from the same namespace as the Route. \n Support: Core" @@ -167,22 +167,19 @@ spec: interpreted as the following: \n * Gateway: Listener Name. When both Port (experimental) and SectionName are specified, the name and port of the selected listener must match both - specified values. \n * Service: Named port. When both Port - (experimental) and SectionName are specified, the name and - port of the selected port must match both specified values. - \n Implementations MAY choose to support attaching Routes - to other resources. If that is the case, they MUST clearly - document how SectionName is interpreted. \n When unspecified - (empty string), this will reference the entire resource. For - the purpose of status, an attachment is considered successful - if at least one section in the parent resource accepts it. - For example, Gateway listeners can restrict which Routes can - attach to them by Route kind, namespace, or hostname. If 1 - of 2 Gateway listeners accept attachment from the referencing - Route, the Route MUST be considered successfully attached. - If no Gateway listeners accept attachment from this Route, - the Route MUST be considered detached from the Gateway. \n - Support: Core" + specified values. \n Implementations MAY choose to support + attaching Routes to other resources. If that is the case, + they MUST clearly document how SectionName is interpreted. + \n When unspecified (empty string), this will reference the + entire resource. For the purpose of status, an attachment + is considered successful if at least one section in the parent + resource accepts it. For example, Gateway listeners can restrict + which Routes can attach to them by Route kind, namespace, + or hostname. If 1 of 2 Gateway listeners accept attachment + from the referencing Route, the Route MUST be considered successfully + attached. If no Gateway listeners accept attachment from this + Route, the Route MUST be considered detached from the Gateway. + \n Support: Core" maxLength: 253 minLength: 1 pattern: ^[a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*$ @@ -472,8 +469,8 @@ spec: reference. \n ParentRefs from a Route to a Service in the same namespace are \"producer\" routes, which apply default routing rules to inbound connections from any - namespace to the Service. ParentRefs from a Route to a - Service in a different namespace are \"consumer\" routes, + namespace to the Service. \n ParentRefs from a Route to + a Service in a different namespace are \"consumer\" routes, and these routing rules are only applied to outbound connections to the Service from the same namespace as the Route. \n Support: Core" @@ -519,12 +516,9 @@ spec: is interpreted as the following: \n * Gateway: Listener Name. When both Port (experimental) and SectionName are specified, the name and port of the selected listener - must match both specified values. \n * Service: Named - port. When both Port (experimental) and SectionName are - specified, the name and port of the selected port must - match both specified values. \n Implementations MAY choose - to support attaching Routes to other resources. If that - is the case, they MUST clearly document how SectionName + must match both specified values. \n Implementations MAY + choose to support attaching Routes to other resources. + If that is the case, they MUST clearly document how SectionName is interpreted. \n When unspecified (empty string), this will reference the entire resource. For the purpose of status, an attachment is considered successful if at least diff --git a/config/crd/standard/gateway.networking.k8s.io_httproutes.yaml b/config/crd/standard/gateway.networking.k8s.io_httproutes.yaml index 5e42681fcf..2779318bce 100644 --- a/config/crd/standard/gateway.networking.k8s.io_httproutes.yaml +++ b/config/crd/standard/gateway.networking.k8s.io_httproutes.yaml @@ -188,7 +188,7 @@ spec: \n ParentRefs from a Route to a Service in the same namespace are \"producer\" routes, which apply default routing rules to inbound connections from any namespace to the Service. - ParentRefs from a Route to a Service in a different namespace + \n ParentRefs from a Route to a Service in a different namespace are \"consumer\" routes, and these routing rules are only applied to outbound connections to the Service from the same namespace as the Route. \n Support: Core" @@ -202,22 +202,19 @@ spec: interpreted as the following: \n * Gateway: Listener Name. When both Port (experimental) and SectionName are specified, the name and port of the selected listener must match both - specified values. \n * Service: Named port. When both Port - (experimental) and SectionName are specified, the name and - port of the selected port must match both specified values. - \n Implementations MAY choose to support attaching Routes - to other resources. If that is the case, they MUST clearly - document how SectionName is interpreted. \n When unspecified - (empty string), this will reference the entire resource. For - the purpose of status, an attachment is considered successful - if at least one section in the parent resource accepts it. - For example, Gateway listeners can restrict which Routes can - attach to them by Route kind, namespace, or hostname. If 1 - of 2 Gateway listeners accept attachment from the referencing - Route, the Route MUST be considered successfully attached. - If no Gateway listeners accept attachment from this Route, - the Route MUST be considered detached from the Gateway. \n - Support: Core" + specified values. \n Implementations MAY choose to support + attaching Routes to other resources. If that is the case, + they MUST clearly document how SectionName is interpreted. + \n When unspecified (empty string), this will reference the + entire resource. For the purpose of status, an attachment + is considered successful if at least one section in the parent + resource accepts it. For example, Gateway listeners can restrict + which Routes can attach to them by Route kind, namespace, + or hostname. If 1 of 2 Gateway listeners accept attachment + from the referencing Route, the Route MUST be considered successfully + attached. If no Gateway listeners accept attachment from this + Route, the Route MUST be considered detached from the Gateway. + \n Support: Core" maxLength: 253 minLength: 1 pattern: ^[a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*$ @@ -1933,8 +1930,8 @@ spec: reference. \n ParentRefs from a Route to a Service in the same namespace are \"producer\" routes, which apply default routing rules to inbound connections from any - namespace to the Service. ParentRefs from a Route to a - Service in a different namespace are \"consumer\" routes, + namespace to the Service. \n ParentRefs from a Route to + a Service in a different namespace are \"consumer\" routes, and these routing rules are only applied to outbound connections to the Service from the same namespace as the Route. \n Support: Core" @@ -1948,12 +1945,9 @@ spec: is interpreted as the following: \n * Gateway: Listener Name. When both Port (experimental) and SectionName are specified, the name and port of the selected listener - must match both specified values. \n * Service: Named - port. When both Port (experimental) and SectionName are - specified, the name and port of the selected port must - match both specified values. \n Implementations MAY choose - to support attaching Routes to other resources. If that - is the case, they MUST clearly document how SectionName + must match both specified values. \n Implementations MAY + choose to support attaching Routes to other resources. + If that is the case, they MUST clearly document how SectionName is interpreted. \n When unspecified (empty string), this will reference the entire resource. For the purpose of status, an attachment is considered successful if at least @@ -2155,7 +2149,7 @@ spec: \n ParentRefs from a Route to a Service in the same namespace are \"producer\" routes, which apply default routing rules to inbound connections from any namespace to the Service. - ParentRefs from a Route to a Service in a different namespace + \n ParentRefs from a Route to a Service in a different namespace are \"consumer\" routes, and these routing rules are only applied to outbound connections to the Service from the same namespace as the Route. \n Support: Core" @@ -2169,22 +2163,19 @@ spec: interpreted as the following: \n * Gateway: Listener Name. When both Port (experimental) and SectionName are specified, the name and port of the selected listener must match both - specified values. \n * Service: Named port. When both Port - (experimental) and SectionName are specified, the name and - port of the selected port must match both specified values. - \n Implementations MAY choose to support attaching Routes - to other resources. If that is the case, they MUST clearly - document how SectionName is interpreted. \n When unspecified - (empty string), this will reference the entire resource. For - the purpose of status, an attachment is considered successful - if at least one section in the parent resource accepts it. - For example, Gateway listeners can restrict which Routes can - attach to them by Route kind, namespace, or hostname. If 1 - of 2 Gateway listeners accept attachment from the referencing - Route, the Route MUST be considered successfully attached. - If no Gateway listeners accept attachment from this Route, - the Route MUST be considered detached from the Gateway. \n - Support: Core" + specified values. \n Implementations MAY choose to support + attaching Routes to other resources. If that is the case, + they MUST clearly document how SectionName is interpreted. + \n When unspecified (empty string), this will reference the + entire resource. For the purpose of status, an attachment + is considered successful if at least one section in the parent + resource accepts it. For example, Gateway listeners can restrict + which Routes can attach to them by Route kind, namespace, + or hostname. If 1 of 2 Gateway listeners accept attachment + from the referencing Route, the Route MUST be considered successfully + attached. If no Gateway listeners accept attachment from this + Route, the Route MUST be considered detached from the Gateway. + \n Support: Core" maxLength: 253 minLength: 1 pattern: ^[a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*$ @@ -3900,8 +3891,8 @@ spec: reference. \n ParentRefs from a Route to a Service in the same namespace are \"producer\" routes, which apply default routing rules to inbound connections from any - namespace to the Service. ParentRefs from a Route to a - Service in a different namespace are \"consumer\" routes, + namespace to the Service. \n ParentRefs from a Route to + a Service in a different namespace are \"consumer\" routes, and these routing rules are only applied to outbound connections to the Service from the same namespace as the Route. \n Support: Core" @@ -3915,12 +3906,9 @@ spec: is interpreted as the following: \n * Gateway: Listener Name. When both Port (experimental) and SectionName are specified, the name and port of the selected listener - must match both specified values. \n * Service: Named - port. When both Port (experimental) and SectionName are - specified, the name and port of the selected port must - match both specified values. \n Implementations MAY choose - to support attaching Routes to other resources. If that - is the case, they MUST clearly document how SectionName + must match both specified values. \n Implementations MAY + choose to support attaching Routes to other resources. + If that is the case, they MUST clearly document how SectionName is interpreted. \n When unspecified (empty string), this will reference the entire resource. For the purpose of status, an attachment is considered successful if at least From bb553179444f871a1e7a5983c4e58789aca1d9ea Mon Sep 17 00:00:00 2001 From: Mike Morris Date: Wed, 28 Jun 2023 16:03:52 -0400 Subject: [PATCH 07/14] actually fixup consumer route language, in both places --- apis/v1beta1/shared_types.go | 15 ++++++++++----- 1 file changed, 10 insertions(+), 5 deletions(-) diff --git a/apis/v1beta1/shared_types.go b/apis/v1beta1/shared_types.go index ccc0033141..06748ee79c 100644 --- a/apis/v1beta1/shared_types.go +++ b/apis/v1beta1/shared_types.go @@ -67,7 +67,9 @@ type ParentReference struct { // // ParentRefs from a Route to a Service in a different namespace are // "consumer" routes, and these routing rules are only applied to outbound - // connections to the Service from the same namespace as the Route. + // connections originating from the same namespace as the Route, for which + // the intended destination of the connections are a Service targeted as a + // ParentRef of the Route. // // Support: Core // @@ -173,10 +175,13 @@ type CommonRouteSpec struct { // // ParentRefs from a Route to a Service in the same namespace are "producer" // routes, which apply default routing rules to inbound connections from - // any namespace to the Service. ParentRefs from a Route to a Service in a - // different namespace are "consumer" routes, and these routing rules are - // only applied to outbound connections to the Service from the same - // namespace as the Route. + // any namespace to the Service. + // + // ParentRefs from a Route to a Service in a different namespace are + // "consumer" routes, and these routing rules are only applied to outbound + // connections originating from the same namespace as the Route, for which + // the intended destination of the connections are a Service targeted as a + // ParentRef of the Route. // // +optional // +kubebuilder:validation:MaxItems=32 From 02769122d8050f914f51bec1135c0a7ad51ca828 Mon Sep 17 00:00:00 2001 From: Mike Morris Date: Wed, 28 Jun 2023 16:04:08 -0400 Subject: [PATCH 08/14] update CRDs --- .../gateway.networking.k8s.io_grpcroutes.yaml | 19 ++++++---- .../gateway.networking.k8s.io_httproutes.yaml | 38 ++++++++++++------- .../gateway.networking.k8s.io_tcproutes.yaml | 19 ++++++---- .../gateway.networking.k8s.io_tlsroutes.yaml | 19 ++++++---- .../gateway.networking.k8s.io_udproutes.yaml | 19 ++++++---- .../gateway.networking.k8s.io_httproutes.yaml | 38 ++++++++++++------- 6 files changed, 96 insertions(+), 56 deletions(-) diff --git a/config/crd/experimental/gateway.networking.k8s.io_grpcroutes.yaml b/config/crd/experimental/gateway.networking.k8s.io_grpcroutes.yaml index 8379c9cca7..1000f8bf91 100644 --- a/config/crd/experimental/gateway.networking.k8s.io_grpcroutes.yaml +++ b/config/crd/experimental/gateway.networking.k8s.io_grpcroutes.yaml @@ -150,10 +150,11 @@ spec: kinds of cross-namespace reference. \n ParentRefs from a Route to a Service in the same namespace are \"producer\" routes, which apply default routing rules to inbound connections from any namespace - to the Service. ParentRefs from a Route to a Service in a different + to the Service. \n ParentRefs from a Route to a Service in a different namespace are \"consumer\" routes, and these routing rules are only - applied to outbound connections to the Service from the same namespace - as the Route." + applied to outbound connections originating from the same namespace + as the Route, for which the intended destination of the connections + are a Service targeted as a ParentRef of the Route." items: description: "ParentReference identifies an API object (usually a Gateway) that can be considered a parent of this resource (usually @@ -203,8 +204,10 @@ spec: to inbound connections from any namespace to the Service. \n ParentRefs from a Route to a Service in a different namespace are \"consumer\" routes, and these routing rules are only - applied to outbound connections to the Service from the same - namespace as the Route. \n Support: Core" + applied to outbound connections originating from the same + namespace as the Route, for which the intended destination + of the connections are a Service targeted as a ParentRef of + the Route. \n Support: Core" maxLength: 63 minLength: 1 pattern: ^[a-z0-9]([-a-z0-9]*[a-z0-9])?$ @@ -1447,8 +1450,10 @@ spec: namespace to the Service. \n ParentRefs from a Route to a Service in a different namespace are \"consumer\" routes, and these routing rules are only applied to outbound connections - to the Service from the same namespace as the Route. \n - Support: Core" + originating from the same namespace as the Route, for + which the intended destination of the connections are + a Service targeted as a ParentRef of the Route. \n Support: + Core" maxLength: 63 minLength: 1 pattern: ^[a-z0-9]([-a-z0-9]*[a-z0-9])?$ diff --git a/config/crd/experimental/gateway.networking.k8s.io_httproutes.yaml b/config/crd/experimental/gateway.networking.k8s.io_httproutes.yaml index 76d61f4d1a..9792623a26 100644 --- a/config/crd/experimental/gateway.networking.k8s.io_httproutes.yaml +++ b/config/crd/experimental/gateway.networking.k8s.io_httproutes.yaml @@ -137,10 +137,11 @@ spec: kinds of cross-namespace reference. \n ParentRefs from a Route to a Service in the same namespace are \"producer\" routes, which apply default routing rules to inbound connections from any namespace - to the Service. ParentRefs from a Route to a Service in a different + to the Service. \n ParentRefs from a Route to a Service in a different namespace are \"consumer\" routes, and these routing rules are only - applied to outbound connections to the Service from the same namespace - as the Route." + applied to outbound connections originating from the same namespace + as the Route, for which the intended destination of the connections + are a Service targeted as a ParentRef of the Route." items: description: "ParentReference identifies an API object (usually a Gateway) that can be considered a parent of this resource (usually @@ -190,8 +191,10 @@ spec: to inbound connections from any namespace to the Service. \n ParentRefs from a Route to a Service in a different namespace are \"consumer\" routes, and these routing rules are only - applied to outbound connections to the Service from the same - namespace as the Route. \n Support: Core" + applied to outbound connections originating from the same + namespace as the Route, for which the intended destination + of the connections are a Service targeted as a ParentRef of + the Route. \n Support: Core" maxLength: 63 minLength: 1 pattern: ^[a-z0-9]([-a-z0-9]*[a-z0-9])?$ @@ -1963,8 +1966,10 @@ spec: namespace to the Service. \n ParentRefs from a Route to a Service in a different namespace are \"consumer\" routes, and these routing rules are only applied to outbound connections - to the Service from the same namespace as the Route. \n - Support: Core" + originating from the same namespace as the Route, for + which the intended destination of the connections are + a Service targeted as a ParentRef of the Route. \n Support: + Core" maxLength: 63 minLength: 1 pattern: ^[a-z0-9]([-a-z0-9]*[a-z0-9])?$ @@ -2160,10 +2165,11 @@ spec: kinds of cross-namespace reference. \n ParentRefs from a Route to a Service in the same namespace are \"producer\" routes, which apply default routing rules to inbound connections from any namespace - to the Service. ParentRefs from a Route to a Service in a different + to the Service. \n ParentRefs from a Route to a Service in a different namespace are \"consumer\" routes, and these routing rules are only - applied to outbound connections to the Service from the same namespace - as the Route." + applied to outbound connections originating from the same namespace + as the Route, for which the intended destination of the connections + are a Service targeted as a ParentRef of the Route." items: description: "ParentReference identifies an API object (usually a Gateway) that can be considered a parent of this resource (usually @@ -2213,8 +2219,10 @@ spec: to inbound connections from any namespace to the Service. \n ParentRefs from a Route to a Service in a different namespace are \"consumer\" routes, and these routing rules are only - applied to outbound connections to the Service from the same - namespace as the Route. \n Support: Core" + applied to outbound connections originating from the same + namespace as the Route, for which the intended destination + of the connections are a Service targeted as a ParentRef of + the Route. \n Support: Core" maxLength: 63 minLength: 1 pattern: ^[a-z0-9]([-a-z0-9]*[a-z0-9])?$ @@ -3986,8 +3994,10 @@ spec: namespace to the Service. \n ParentRefs from a Route to a Service in a different namespace are \"consumer\" routes, and these routing rules are only applied to outbound connections - to the Service from the same namespace as the Route. \n - Support: Core" + originating from the same namespace as the Route, for + which the intended destination of the connections are + a Service targeted as a ParentRef of the Route. \n Support: + Core" maxLength: 63 minLength: 1 pattern: ^[a-z0-9]([-a-z0-9]*[a-z0-9])?$ diff --git a/config/crd/experimental/gateway.networking.k8s.io_tcproutes.yaml b/config/crd/experimental/gateway.networking.k8s.io_tcproutes.yaml index 6744d90b4c..57a20d8ab6 100644 --- a/config/crd/experimental/gateway.networking.k8s.io_tcproutes.yaml +++ b/config/crd/experimental/gateway.networking.k8s.io_tcproutes.yaml @@ -72,10 +72,11 @@ spec: kinds of cross-namespace reference. \n ParentRefs from a Route to a Service in the same namespace are \"producer\" routes, which apply default routing rules to inbound connections from any namespace - to the Service. ParentRefs from a Route to a Service in a different + to the Service. \n ParentRefs from a Route to a Service in a different namespace are \"consumer\" routes, and these routing rules are only - applied to outbound connections to the Service from the same namespace - as the Route." + applied to outbound connections originating from the same namespace + as the Route, for which the intended destination of the connections + are a Service targeted as a ParentRef of the Route." items: description: "ParentReference identifies an API object (usually a Gateway) that can be considered a parent of this resource (usually @@ -125,8 +126,10 @@ spec: to inbound connections from any namespace to the Service. \n ParentRefs from a Route to a Service in a different namespace are \"consumer\" routes, and these routing rules are only - applied to outbound connections to the Service from the same - namespace as the Route. \n Support: Core" + applied to outbound connections originating from the same + namespace as the Route, for which the intended destination + of the connections are a Service targeted as a ParentRef of + the Route. \n Support: Core" maxLength: 63 minLength: 1 pattern: ^[a-z0-9]([-a-z0-9]*[a-z0-9])?$ @@ -472,8 +475,10 @@ spec: namespace to the Service. \n ParentRefs from a Route to a Service in a different namespace are \"consumer\" routes, and these routing rules are only applied to outbound connections - to the Service from the same namespace as the Route. \n - Support: Core" + originating from the same namespace as the Route, for + which the intended destination of the connections are + a Service targeted as a ParentRef of the Route. \n Support: + Core" maxLength: 63 minLength: 1 pattern: ^[a-z0-9]([-a-z0-9]*[a-z0-9])?$ diff --git a/config/crd/experimental/gateway.networking.k8s.io_tlsroutes.yaml b/config/crd/experimental/gateway.networking.k8s.io_tlsroutes.yaml index 1aed50cab2..a4d47f9bdb 100644 --- a/config/crd/experimental/gateway.networking.k8s.io_tlsroutes.yaml +++ b/config/crd/experimental/gateway.networking.k8s.io_tlsroutes.yaml @@ -118,10 +118,11 @@ spec: kinds of cross-namespace reference. \n ParentRefs from a Route to a Service in the same namespace are \"producer\" routes, which apply default routing rules to inbound connections from any namespace - to the Service. ParentRefs from a Route to a Service in a different + to the Service. \n ParentRefs from a Route to a Service in a different namespace are \"consumer\" routes, and these routing rules are only - applied to outbound connections to the Service from the same namespace - as the Route." + applied to outbound connections originating from the same namespace + as the Route, for which the intended destination of the connections + are a Service targeted as a ParentRef of the Route." items: description: "ParentReference identifies an API object (usually a Gateway) that can be considered a parent of this resource (usually @@ -171,8 +172,10 @@ spec: to inbound connections from any namespace to the Service. \n ParentRefs from a Route to a Service in a different namespace are \"consumer\" routes, and these routing rules are only - applied to outbound connections to the Service from the same - namespace as the Route. \n Support: Core" + applied to outbound connections originating from the same + namespace as the Route, for which the intended destination + of the connections are a Service targeted as a ParentRef of + the Route. \n Support: Core" maxLength: 63 minLength: 1 pattern: ^[a-z0-9]([-a-z0-9]*[a-z0-9])?$ @@ -521,8 +524,10 @@ spec: namespace to the Service. \n ParentRefs from a Route to a Service in a different namespace are \"consumer\" routes, and these routing rules are only applied to outbound connections - to the Service from the same namespace as the Route. \n - Support: Core" + originating from the same namespace as the Route, for + which the intended destination of the connections are + a Service targeted as a ParentRef of the Route. \n Support: + Core" maxLength: 63 minLength: 1 pattern: ^[a-z0-9]([-a-z0-9]*[a-z0-9])?$ diff --git a/config/crd/experimental/gateway.networking.k8s.io_udproutes.yaml b/config/crd/experimental/gateway.networking.k8s.io_udproutes.yaml index db3f0f55e7..bcaf167cb5 100644 --- a/config/crd/experimental/gateway.networking.k8s.io_udproutes.yaml +++ b/config/crd/experimental/gateway.networking.k8s.io_udproutes.yaml @@ -72,10 +72,11 @@ spec: kinds of cross-namespace reference. \n ParentRefs from a Route to a Service in the same namespace are \"producer\" routes, which apply default routing rules to inbound connections from any namespace - to the Service. ParentRefs from a Route to a Service in a different + to the Service. \n ParentRefs from a Route to a Service in a different namespace are \"consumer\" routes, and these routing rules are only - applied to outbound connections to the Service from the same namespace - as the Route." + applied to outbound connections originating from the same namespace + as the Route, for which the intended destination of the connections + are a Service targeted as a ParentRef of the Route." items: description: "ParentReference identifies an API object (usually a Gateway) that can be considered a parent of this resource (usually @@ -125,8 +126,10 @@ spec: to inbound connections from any namespace to the Service. \n ParentRefs from a Route to a Service in a different namespace are \"consumer\" routes, and these routing rules are only - applied to outbound connections to the Service from the same - namespace as the Route. \n Support: Core" + applied to outbound connections originating from the same + namespace as the Route, for which the intended destination + of the connections are a Service targeted as a ParentRef of + the Route. \n Support: Core" maxLength: 63 minLength: 1 pattern: ^[a-z0-9]([-a-z0-9]*[a-z0-9])?$ @@ -472,8 +475,10 @@ spec: namespace to the Service. \n ParentRefs from a Route to a Service in a different namespace are \"consumer\" routes, and these routing rules are only applied to outbound connections - to the Service from the same namespace as the Route. \n - Support: Core" + originating from the same namespace as the Route, for + which the intended destination of the connections are + a Service targeted as a ParentRef of the Route. \n Support: + Core" maxLength: 63 minLength: 1 pattern: ^[a-z0-9]([-a-z0-9]*[a-z0-9])?$ diff --git a/config/crd/standard/gateway.networking.k8s.io_httproutes.yaml b/config/crd/standard/gateway.networking.k8s.io_httproutes.yaml index 2779318bce..1a4cdaa6d9 100644 --- a/config/crd/standard/gateway.networking.k8s.io_httproutes.yaml +++ b/config/crd/standard/gateway.networking.k8s.io_httproutes.yaml @@ -137,10 +137,11 @@ spec: kinds of cross-namespace reference. \n ParentRefs from a Route to a Service in the same namespace are \"producer\" routes, which apply default routing rules to inbound connections from any namespace - to the Service. ParentRefs from a Route to a Service in a different + to the Service. \n ParentRefs from a Route to a Service in a different namespace are \"consumer\" routes, and these routing rules are only - applied to outbound connections to the Service from the same namespace - as the Route." + applied to outbound connections originating from the same namespace + as the Route, for which the intended destination of the connections + are a Service targeted as a ParentRef of the Route." items: description: "ParentReference identifies an API object (usually a Gateway) that can be considered a parent of this resource (usually @@ -190,8 +191,10 @@ spec: to inbound connections from any namespace to the Service. \n ParentRefs from a Route to a Service in a different namespace are \"consumer\" routes, and these routing rules are only - applied to outbound connections to the Service from the same - namespace as the Route. \n Support: Core" + applied to outbound connections originating from the same + namespace as the Route, for which the intended destination + of the connections are a Service targeted as a ParentRef of + the Route. \n Support: Core" maxLength: 63 minLength: 1 pattern: ^[a-z0-9]([-a-z0-9]*[a-z0-9])?$ @@ -1933,8 +1936,10 @@ spec: namespace to the Service. \n ParentRefs from a Route to a Service in a different namespace are \"consumer\" routes, and these routing rules are only applied to outbound connections - to the Service from the same namespace as the Route. \n - Support: Core" + originating from the same namespace as the Route, for + which the intended destination of the connections are + a Service targeted as a ParentRef of the Route. \n Support: + Core" maxLength: 63 minLength: 1 pattern: ^[a-z0-9]([-a-z0-9]*[a-z0-9])?$ @@ -2098,10 +2103,11 @@ spec: kinds of cross-namespace reference. \n ParentRefs from a Route to a Service in the same namespace are \"producer\" routes, which apply default routing rules to inbound connections from any namespace - to the Service. ParentRefs from a Route to a Service in a different + to the Service. \n ParentRefs from a Route to a Service in a different namespace are \"consumer\" routes, and these routing rules are only - applied to outbound connections to the Service from the same namespace - as the Route." + applied to outbound connections originating from the same namespace + as the Route, for which the intended destination of the connections + are a Service targeted as a ParentRef of the Route." items: description: "ParentReference identifies an API object (usually a Gateway) that can be considered a parent of this resource (usually @@ -2151,8 +2157,10 @@ spec: to inbound connections from any namespace to the Service. \n ParentRefs from a Route to a Service in a different namespace are \"consumer\" routes, and these routing rules are only - applied to outbound connections to the Service from the same - namespace as the Route. \n Support: Core" + applied to outbound connections originating from the same + namespace as the Route, for which the intended destination + of the connections are a Service targeted as a ParentRef of + the Route. \n Support: Core" maxLength: 63 minLength: 1 pattern: ^[a-z0-9]([-a-z0-9]*[a-z0-9])?$ @@ -3894,8 +3902,10 @@ spec: namespace to the Service. \n ParentRefs from a Route to a Service in a different namespace are \"consumer\" routes, and these routing rules are only applied to outbound connections - to the Service from the same namespace as the Route. \n - Support: Core" + originating from the same namespace as the Route, for + which the intended destination of the connections are + a Service targeted as a ParentRef of the Route. \n Support: + Core" maxLength: 63 minLength: 1 pattern: ^[a-z0-9]([-a-z0-9]*[a-z0-9])?$ From 2caff821427829d7fce35667f762b1ad0beb4c10 Mon Sep 17 00:00:00 2001 From: Mike Morris Date: Mon, 3 Jul 2023 15:44:33 -0400 Subject: [PATCH 09/14] Update apis/v1beta1/shared_types.go Co-authored-by: Rob Scott --- apis/v1beta1/shared_types.go | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/apis/v1beta1/shared_types.go b/apis/v1beta1/shared_types.go index 06748ee79c..8acf6161b1 100644 --- a/apis/v1beta1/shared_types.go +++ b/apis/v1beta1/shared_types.go @@ -21,10 +21,14 @@ import ( ) // ParentReference identifies an API object (usually a Gateway) that can be considered -// a parent of this resource (usually a route). The only kinds of parent resources -// with "Core" support are Service (only for implementations supporting the Mesh -// conformance profile) and Gateway. This API may be extended in the future to -// support additional kinds of parent resources. +// a parent of this resource (usually a route). There are two kinds of parent resources +// with "Core" support: +// +// * Gateway (Gateway conformance profile) +// * Service (Mesh conformance profile) +// +// This API may be extended in the future to support additional kinds of parent +// resources. // // The API object must be valid in the cluster; the Group and Kind must // be registered in the cluster for this reference to be valid. From e7b3f364676ac4ed4057ca9f78eacb181a787649 Mon Sep 17 00:00:00 2001 From: Mike Morris Date: Mon, 3 Jul 2023 15:45:10 -0400 Subject: [PATCH 10/14] Update apis/v1beta1/shared_types.go Co-authored-by: Rob Scott --- apis/v1beta1/shared_types.go | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/apis/v1beta1/shared_types.go b/apis/v1beta1/shared_types.go index 8acf6161b1..cdf21241bd 100644 --- a/apis/v1beta1/shared_types.go +++ b/apis/v1beta1/shared_types.go @@ -46,11 +46,12 @@ type ParentReference struct { // Kind is kind of the referent. // - // Support: Core (Gateway) + // There are two kinds of parent resources with "Core" support: // - // Support: Core (Service - mesh conformance profile only) + // * Gateway (Gateway conformance profile) + // * Service (Mesh conformance profile) // - // Support: Implementation-specific (Other Resources) + // Support for other resources is Implementation-Specific. // // +kubebuilder:default=Gateway // +optional From 0df8ec5fffd9944c3cfe166900f232e475e58b0c Mon Sep 17 00:00:00 2001 From: Mike Morris Date: Mon, 3 Jul 2023 15:45:41 -0400 Subject: [PATCH 11/14] Update apis/v1beta1/shared_types.go Co-authored-by: Rob Scott --- apis/v1beta1/shared_types.go | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/apis/v1beta1/shared_types.go b/apis/v1beta1/shared_types.go index cdf21241bd..07a743064e 100644 --- a/apis/v1beta1/shared_types.go +++ b/apis/v1beta1/shared_types.go @@ -156,10 +156,13 @@ type CommonRouteSpec struct { // namespace for a "producer" route, or the mesh implementation must support // and allow "consumer" routes for the referenced Service. // - // The only kinds of parent resources with "Core" support are Service (only - // for implementations supporting the Mesh conformance profile) and Gateway. + // There are two kinds of parent resources with "Core" support: + // + // * Gateway (Gateway conformance profile) + // * Service (Mesh conformance profile) + // // This API may be extended in the future to support additional kinds of parent - // resources such as one of the route kinds. + // resources. // // It is invalid to reference an identical parent more than once. It is // valid to reference multiple distinct sections within the same parent From 0fef56af7148b9fceff0e764b1b5a1f0ec8ffe0e Mon Sep 17 00:00:00 2001 From: Mike Morris Date: Mon, 3 Jul 2023 15:49:23 -0400 Subject: [PATCH 12/14] update CRDs --- .../gateway.networking.k8s.io_grpcroutes.yaml | 78 ++++----- .../gateway.networking.k8s.io_httproutes.yaml | 156 +++++++++--------- .../gateway.networking.k8s.io_tcproutes.yaml | 78 ++++----- .../gateway.networking.k8s.io_tlsroutes.yaml | 78 ++++----- .../gateway.networking.k8s.io_udproutes.yaml | 78 ++++----- .../gateway.networking.k8s.io_httproutes.yaml | 156 +++++++++--------- 6 files changed, 320 insertions(+), 304 deletions(-) diff --git a/config/crd/experimental/gateway.networking.k8s.io_grpcroutes.yaml b/config/crd/experimental/gateway.networking.k8s.io_grpcroutes.yaml index 1000f8bf91..bfc256a308 100644 --- a/config/crd/experimental/gateway.networking.k8s.io_grpcroutes.yaml +++ b/config/crd/experimental/gateway.networking.k8s.io_grpcroutes.yaml @@ -130,40 +130,40 @@ spec: Routes of this kind and namespace. For Services, that means the Service must either be in the same namespace for a \"producer\" route, or the mesh implementation must support and allow \"consumer\" - routes for the referenced Service. \n The only kinds of parent resources - with \"Core\" support are Service (only for implementations supporting - the Mesh conformance profile) and Gateway. This API may be extended - in the future to support additional kinds of parent resources such - as one of the route kinds. \n It is invalid to reference an identical - parent more than once. It is valid to reference multiple distinct - sections within the same parent resource, such as two separate Listeners - on the same Gateway or two separate ports on the same Service. \n - It is possible to separately reference multiple distinct objects - that may be collapsed by an implementation. For example, some implementations - may choose to merge compatible Gateway Listeners together. If that - is the case, the list of routes attached to those resources should - also be merged. \n Note that for ParentRefs that cross namespace - boundaries, there are specific rules. Cross-namespace references - are only valid if they are explicitly allowed by something in the - namespace they are referring to. For example, Gateway has the AllowedRoutes - field, and ReferenceGrant provides a generic way to enable other - kinds of cross-namespace reference. \n ParentRefs from a Route to - a Service in the same namespace are \"producer\" routes, which apply - default routing rules to inbound connections from any namespace - to the Service. \n ParentRefs from a Route to a Service in a different - namespace are \"consumer\" routes, and these routing rules are only - applied to outbound connections originating from the same namespace - as the Route, for which the intended destination of the connections - are a Service targeted as a ParentRef of the Route." + routes for the referenced Service. \n There are two kinds of parent + resources with \"Core\" support: \n * Gateway (Gateway conformance + profile) * Service (Mesh conformance profile) \n This API may be + extended in the future to support additional kinds of parent resources. + \n It is invalid to reference an identical parent more than once. + It is valid to reference multiple distinct sections within the same + parent resource, such as two separate Listeners on the same Gateway + or two separate ports on the same Service. \n It is possible to + separately reference multiple distinct objects that may be collapsed + by an implementation. For example, some implementations may choose + to merge compatible Gateway Listeners together. If that is the case, + the list of routes attached to those resources should also be merged. + \n Note that for ParentRefs that cross namespace boundaries, there + are specific rules. Cross-namespace references are only valid if + they are explicitly allowed by something in the namespace they are + referring to. For example, Gateway has the AllowedRoutes field, + and ReferenceGrant provides a generic way to enable other kinds + of cross-namespace reference. \n ParentRefs from a Route to a Service + in the same namespace are \"producer\" routes, which apply default + routing rules to inbound connections from any namespace to the Service. + \n ParentRefs from a Route to a Service in a different namespace + are \"consumer\" routes, and these routing rules are only applied + to outbound connections originating from the same namespace as the + Route, for which the intended destination of the connections are + a Service targeted as a ParentRef of the Route." items: description: "ParentReference identifies an API object (usually a Gateway) that can be considered a parent of this resource (usually - a route). The only kinds of parent resources with \"Core\" support - are Service (only for implementations supporting the Mesh conformance - profile) and Gateway. This API may be extended in the future to - support additional kinds of parent resources. \n The API object - must be valid in the cluster; the Group and Kind must be registered - in the cluster for this reference to be valid." + a route). There are two kinds of parent resources with \"Core\" + support: \n * Gateway (Gateway conformance profile) * Service + (Mesh conformance profile) \n This API may be extended in the + future to support additional kinds of parent resources. \n The + API object must be valid in the cluster; the Group and Kind must + be registered in the cluster for this reference to be valid." properties: group: default: gateway.networking.k8s.io @@ -177,9 +177,10 @@ spec: type: string kind: default: Gateway - description: "Kind is kind of the referent. \n Support: Core - (Gateway) \n Support: Core (Service - mesh conformance profile - only) \n Support: Implementation-specific (Other Resources)" + description: "Kind is kind of the referent. \n There are two + kinds of parent resources with \"Core\" support: \n * Gateway + (Gateway conformance profile) * Service (Mesh conformance + profile) \n Support for other resources is Implementation-Specific." maxLength: 63 minLength: 1 pattern: ^[a-zA-Z]([-a-zA-Z0-9]*[a-zA-Z0-9])?$ @@ -1421,10 +1422,11 @@ spec: type: string kind: default: Gateway - description: "Kind is kind of the referent. \n Support: - Core (Gateway) \n Support: Core (Service - mesh conformance - profile only) \n Support: Implementation-specific (Other - Resources)" + description: "Kind is kind of the referent. \n There are + two kinds of parent resources with \"Core\" support: \n + * Gateway (Gateway conformance profile) * Service (Mesh + conformance profile) \n Support for other resources is + Implementation-Specific." maxLength: 63 minLength: 1 pattern: ^[a-zA-Z]([-a-zA-Z0-9]*[a-zA-Z0-9])?$ diff --git a/config/crd/experimental/gateway.networking.k8s.io_httproutes.yaml b/config/crd/experimental/gateway.networking.k8s.io_httproutes.yaml index 9792623a26..9838abe717 100644 --- a/config/crd/experimental/gateway.networking.k8s.io_httproutes.yaml +++ b/config/crd/experimental/gateway.networking.k8s.io_httproutes.yaml @@ -117,40 +117,40 @@ spec: Routes of this kind and namespace. For Services, that means the Service must either be in the same namespace for a \"producer\" route, or the mesh implementation must support and allow \"consumer\" - routes for the referenced Service. \n The only kinds of parent resources - with \"Core\" support are Service (only for implementations supporting - the Mesh conformance profile) and Gateway. This API may be extended - in the future to support additional kinds of parent resources such - as one of the route kinds. \n It is invalid to reference an identical - parent more than once. It is valid to reference multiple distinct - sections within the same parent resource, such as two separate Listeners - on the same Gateway or two separate ports on the same Service. \n - It is possible to separately reference multiple distinct objects - that may be collapsed by an implementation. For example, some implementations - may choose to merge compatible Gateway Listeners together. If that - is the case, the list of routes attached to those resources should - also be merged. \n Note that for ParentRefs that cross namespace - boundaries, there are specific rules. Cross-namespace references - are only valid if they are explicitly allowed by something in the - namespace they are referring to. For example, Gateway has the AllowedRoutes - field, and ReferenceGrant provides a generic way to enable other - kinds of cross-namespace reference. \n ParentRefs from a Route to - a Service in the same namespace are \"producer\" routes, which apply - default routing rules to inbound connections from any namespace - to the Service. \n ParentRefs from a Route to a Service in a different - namespace are \"consumer\" routes, and these routing rules are only - applied to outbound connections originating from the same namespace - as the Route, for which the intended destination of the connections - are a Service targeted as a ParentRef of the Route." + routes for the referenced Service. \n There are two kinds of parent + resources with \"Core\" support: \n * Gateway (Gateway conformance + profile) * Service (Mesh conformance profile) \n This API may be + extended in the future to support additional kinds of parent resources. + \n It is invalid to reference an identical parent more than once. + It is valid to reference multiple distinct sections within the same + parent resource, such as two separate Listeners on the same Gateway + or two separate ports on the same Service. \n It is possible to + separately reference multiple distinct objects that may be collapsed + by an implementation. For example, some implementations may choose + to merge compatible Gateway Listeners together. If that is the case, + the list of routes attached to those resources should also be merged. + \n Note that for ParentRefs that cross namespace boundaries, there + are specific rules. Cross-namespace references are only valid if + they are explicitly allowed by something in the namespace they are + referring to. For example, Gateway has the AllowedRoutes field, + and ReferenceGrant provides a generic way to enable other kinds + of cross-namespace reference. \n ParentRefs from a Route to a Service + in the same namespace are \"producer\" routes, which apply default + routing rules to inbound connections from any namespace to the Service. + \n ParentRefs from a Route to a Service in a different namespace + are \"consumer\" routes, and these routing rules are only applied + to outbound connections originating from the same namespace as the + Route, for which the intended destination of the connections are + a Service targeted as a ParentRef of the Route." items: description: "ParentReference identifies an API object (usually a Gateway) that can be considered a parent of this resource (usually - a route). The only kinds of parent resources with \"Core\" support - are Service (only for implementations supporting the Mesh conformance - profile) and Gateway. This API may be extended in the future to - support additional kinds of parent resources. \n The API object - must be valid in the cluster; the Group and Kind must be registered - in the cluster for this reference to be valid." + a route). There are two kinds of parent resources with \"Core\" + support: \n * Gateway (Gateway conformance profile) * Service + (Mesh conformance profile) \n This API may be extended in the + future to support additional kinds of parent resources. \n The + API object must be valid in the cluster; the Group and Kind must + be registered in the cluster for this reference to be valid." properties: group: default: gateway.networking.k8s.io @@ -164,9 +164,10 @@ spec: type: string kind: default: Gateway - description: "Kind is kind of the referent. \n Support: Core - (Gateway) \n Support: Core (Service - mesh conformance profile - only) \n Support: Implementation-specific (Other Resources)" + description: "Kind is kind of the referent. \n There are two + kinds of parent resources with \"Core\" support: \n * Gateway + (Gateway conformance profile) * Service (Mesh conformance + profile) \n Support for other resources is Implementation-Specific." maxLength: 63 minLength: 1 pattern: ^[a-zA-Z]([-a-zA-Z0-9]*[a-zA-Z0-9])?$ @@ -1937,10 +1938,11 @@ spec: type: string kind: default: Gateway - description: "Kind is kind of the referent. \n Support: - Core (Gateway) \n Support: Core (Service - mesh conformance - profile only) \n Support: Implementation-specific (Other - Resources)" + description: "Kind is kind of the referent. \n There are + two kinds of parent resources with \"Core\" support: \n + * Gateway (Gateway conformance profile) * Service (Mesh + conformance profile) \n Support for other resources is + Implementation-Specific." maxLength: 63 minLength: 1 pattern: ^[a-zA-Z]([-a-zA-Z0-9]*[a-zA-Z0-9])?$ @@ -2145,40 +2147,40 @@ spec: Routes of this kind and namespace. For Services, that means the Service must either be in the same namespace for a \"producer\" route, or the mesh implementation must support and allow \"consumer\" - routes for the referenced Service. \n The only kinds of parent resources - with \"Core\" support are Service (only for implementations supporting - the Mesh conformance profile) and Gateway. This API may be extended - in the future to support additional kinds of parent resources such - as one of the route kinds. \n It is invalid to reference an identical - parent more than once. It is valid to reference multiple distinct - sections within the same parent resource, such as two separate Listeners - on the same Gateway or two separate ports on the same Service. \n - It is possible to separately reference multiple distinct objects - that may be collapsed by an implementation. For example, some implementations - may choose to merge compatible Gateway Listeners together. If that - is the case, the list of routes attached to those resources should - also be merged. \n Note that for ParentRefs that cross namespace - boundaries, there are specific rules. Cross-namespace references - are only valid if they are explicitly allowed by something in the - namespace they are referring to. For example, Gateway has the AllowedRoutes - field, and ReferenceGrant provides a generic way to enable other - kinds of cross-namespace reference. \n ParentRefs from a Route to - a Service in the same namespace are \"producer\" routes, which apply - default routing rules to inbound connections from any namespace - to the Service. \n ParentRefs from a Route to a Service in a different - namespace are \"consumer\" routes, and these routing rules are only - applied to outbound connections originating from the same namespace - as the Route, for which the intended destination of the connections - are a Service targeted as a ParentRef of the Route." + routes for the referenced Service. \n There are two kinds of parent + resources with \"Core\" support: \n * Gateway (Gateway conformance + profile) * Service (Mesh conformance profile) \n This API may be + extended in the future to support additional kinds of parent resources. + \n It is invalid to reference an identical parent more than once. + It is valid to reference multiple distinct sections within the same + parent resource, such as two separate Listeners on the same Gateway + or two separate ports on the same Service. \n It is possible to + separately reference multiple distinct objects that may be collapsed + by an implementation. For example, some implementations may choose + to merge compatible Gateway Listeners together. If that is the case, + the list of routes attached to those resources should also be merged. + \n Note that for ParentRefs that cross namespace boundaries, there + are specific rules. Cross-namespace references are only valid if + they are explicitly allowed by something in the namespace they are + referring to. For example, Gateway has the AllowedRoutes field, + and ReferenceGrant provides a generic way to enable other kinds + of cross-namespace reference. \n ParentRefs from a Route to a Service + in the same namespace are \"producer\" routes, which apply default + routing rules to inbound connections from any namespace to the Service. + \n ParentRefs from a Route to a Service in a different namespace + are \"consumer\" routes, and these routing rules are only applied + to outbound connections originating from the same namespace as the + Route, for which the intended destination of the connections are + a Service targeted as a ParentRef of the Route." items: description: "ParentReference identifies an API object (usually a Gateway) that can be considered a parent of this resource (usually - a route). The only kinds of parent resources with \"Core\" support - are Service (only for implementations supporting the Mesh conformance - profile) and Gateway. This API may be extended in the future to - support additional kinds of parent resources. \n The API object - must be valid in the cluster; the Group and Kind must be registered - in the cluster for this reference to be valid." + a route). There are two kinds of parent resources with \"Core\" + support: \n * Gateway (Gateway conformance profile) * Service + (Mesh conformance profile) \n This API may be extended in the + future to support additional kinds of parent resources. \n The + API object must be valid in the cluster; the Group and Kind must + be registered in the cluster for this reference to be valid." properties: group: default: gateway.networking.k8s.io @@ -2192,9 +2194,10 @@ spec: type: string kind: default: Gateway - description: "Kind is kind of the referent. \n Support: Core - (Gateway) \n Support: Core (Service - mesh conformance profile - only) \n Support: Implementation-specific (Other Resources)" + description: "Kind is kind of the referent. \n There are two + kinds of parent resources with \"Core\" support: \n * Gateway + (Gateway conformance profile) * Service (Mesh conformance + profile) \n Support for other resources is Implementation-Specific." maxLength: 63 minLength: 1 pattern: ^[a-zA-Z]([-a-zA-Z0-9]*[a-zA-Z0-9])?$ @@ -3965,10 +3968,11 @@ spec: type: string kind: default: Gateway - description: "Kind is kind of the referent. \n Support: - Core (Gateway) \n Support: Core (Service - mesh conformance - profile only) \n Support: Implementation-specific (Other - Resources)" + description: "Kind is kind of the referent. \n There are + two kinds of parent resources with \"Core\" support: \n + * Gateway (Gateway conformance profile) * Service (Mesh + conformance profile) \n Support for other resources is + Implementation-Specific." maxLength: 63 minLength: 1 pattern: ^[a-zA-Z]([-a-zA-Z0-9]*[a-zA-Z0-9])?$ diff --git a/config/crd/experimental/gateway.networking.k8s.io_tcproutes.yaml b/config/crd/experimental/gateway.networking.k8s.io_tcproutes.yaml index 57a20d8ab6..b8e25a59ea 100644 --- a/config/crd/experimental/gateway.networking.k8s.io_tcproutes.yaml +++ b/config/crd/experimental/gateway.networking.k8s.io_tcproutes.yaml @@ -52,40 +52,40 @@ spec: Routes of this kind and namespace. For Services, that means the Service must either be in the same namespace for a \"producer\" route, or the mesh implementation must support and allow \"consumer\" - routes for the referenced Service. \n The only kinds of parent resources - with \"Core\" support are Service (only for implementations supporting - the Mesh conformance profile) and Gateway. This API may be extended - in the future to support additional kinds of parent resources such - as one of the route kinds. \n It is invalid to reference an identical - parent more than once. It is valid to reference multiple distinct - sections within the same parent resource, such as two separate Listeners - on the same Gateway or two separate ports on the same Service. \n - It is possible to separately reference multiple distinct objects - that may be collapsed by an implementation. For example, some implementations - may choose to merge compatible Gateway Listeners together. If that - is the case, the list of routes attached to those resources should - also be merged. \n Note that for ParentRefs that cross namespace - boundaries, there are specific rules. Cross-namespace references - are only valid if they are explicitly allowed by something in the - namespace they are referring to. For example, Gateway has the AllowedRoutes - field, and ReferenceGrant provides a generic way to enable other - kinds of cross-namespace reference. \n ParentRefs from a Route to - a Service in the same namespace are \"producer\" routes, which apply - default routing rules to inbound connections from any namespace - to the Service. \n ParentRefs from a Route to a Service in a different - namespace are \"consumer\" routes, and these routing rules are only - applied to outbound connections originating from the same namespace - as the Route, for which the intended destination of the connections - are a Service targeted as a ParentRef of the Route." + routes for the referenced Service. \n There are two kinds of parent + resources with \"Core\" support: \n * Gateway (Gateway conformance + profile) * Service (Mesh conformance profile) \n This API may be + extended in the future to support additional kinds of parent resources. + \n It is invalid to reference an identical parent more than once. + It is valid to reference multiple distinct sections within the same + parent resource, such as two separate Listeners on the same Gateway + or two separate ports on the same Service. \n It is possible to + separately reference multiple distinct objects that may be collapsed + by an implementation. For example, some implementations may choose + to merge compatible Gateway Listeners together. If that is the case, + the list of routes attached to those resources should also be merged. + \n Note that for ParentRefs that cross namespace boundaries, there + are specific rules. Cross-namespace references are only valid if + they are explicitly allowed by something in the namespace they are + referring to. For example, Gateway has the AllowedRoutes field, + and ReferenceGrant provides a generic way to enable other kinds + of cross-namespace reference. \n ParentRefs from a Route to a Service + in the same namespace are \"producer\" routes, which apply default + routing rules to inbound connections from any namespace to the Service. + \n ParentRefs from a Route to a Service in a different namespace + are \"consumer\" routes, and these routing rules are only applied + to outbound connections originating from the same namespace as the + Route, for which the intended destination of the connections are + a Service targeted as a ParentRef of the Route." items: description: "ParentReference identifies an API object (usually a Gateway) that can be considered a parent of this resource (usually - a route). The only kinds of parent resources with \"Core\" support - are Service (only for implementations supporting the Mesh conformance - profile) and Gateway. This API may be extended in the future to - support additional kinds of parent resources. \n The API object - must be valid in the cluster; the Group and Kind must be registered - in the cluster for this reference to be valid." + a route). There are two kinds of parent resources with \"Core\" + support: \n * Gateway (Gateway conformance profile) * Service + (Mesh conformance profile) \n This API may be extended in the + future to support additional kinds of parent resources. \n The + API object must be valid in the cluster; the Group and Kind must + be registered in the cluster for this reference to be valid." properties: group: default: gateway.networking.k8s.io @@ -99,9 +99,10 @@ spec: type: string kind: default: Gateway - description: "Kind is kind of the referent. \n Support: Core - (Gateway) \n Support: Core (Service - mesh conformance profile - only) \n Support: Implementation-specific (Other Resources)" + description: "Kind is kind of the referent. \n There are two + kinds of parent resources with \"Core\" support: \n * Gateway + (Gateway conformance profile) * Service (Mesh conformance + profile) \n Support for other resources is Implementation-Specific." maxLength: 63 minLength: 1 pattern: ^[a-zA-Z]([-a-zA-Z0-9]*[a-zA-Z0-9])?$ @@ -446,10 +447,11 @@ spec: type: string kind: default: Gateway - description: "Kind is kind of the referent. \n Support: - Core (Gateway) \n Support: Core (Service - mesh conformance - profile only) \n Support: Implementation-specific (Other - Resources)" + description: "Kind is kind of the referent. \n There are + two kinds of parent resources with \"Core\" support: \n + * Gateway (Gateway conformance profile) * Service (Mesh + conformance profile) \n Support for other resources is + Implementation-Specific." maxLength: 63 minLength: 1 pattern: ^[a-zA-Z]([-a-zA-Z0-9]*[a-zA-Z0-9])?$ diff --git a/config/crd/experimental/gateway.networking.k8s.io_tlsroutes.yaml b/config/crd/experimental/gateway.networking.k8s.io_tlsroutes.yaml index a4d47f9bdb..b13fcd0b58 100644 --- a/config/crd/experimental/gateway.networking.k8s.io_tlsroutes.yaml +++ b/config/crd/experimental/gateway.networking.k8s.io_tlsroutes.yaml @@ -98,40 +98,40 @@ spec: Routes of this kind and namespace. For Services, that means the Service must either be in the same namespace for a \"producer\" route, or the mesh implementation must support and allow \"consumer\" - routes for the referenced Service. \n The only kinds of parent resources - with \"Core\" support are Service (only for implementations supporting - the Mesh conformance profile) and Gateway. This API may be extended - in the future to support additional kinds of parent resources such - as one of the route kinds. \n It is invalid to reference an identical - parent more than once. It is valid to reference multiple distinct - sections within the same parent resource, such as two separate Listeners - on the same Gateway or two separate ports on the same Service. \n - It is possible to separately reference multiple distinct objects - that may be collapsed by an implementation. For example, some implementations - may choose to merge compatible Gateway Listeners together. If that - is the case, the list of routes attached to those resources should - also be merged. \n Note that for ParentRefs that cross namespace - boundaries, there are specific rules. Cross-namespace references - are only valid if they are explicitly allowed by something in the - namespace they are referring to. For example, Gateway has the AllowedRoutes - field, and ReferenceGrant provides a generic way to enable other - kinds of cross-namespace reference. \n ParentRefs from a Route to - a Service in the same namespace are \"producer\" routes, which apply - default routing rules to inbound connections from any namespace - to the Service. \n ParentRefs from a Route to a Service in a different - namespace are \"consumer\" routes, and these routing rules are only - applied to outbound connections originating from the same namespace - as the Route, for which the intended destination of the connections - are a Service targeted as a ParentRef of the Route." + routes for the referenced Service. \n There are two kinds of parent + resources with \"Core\" support: \n * Gateway (Gateway conformance + profile) * Service (Mesh conformance profile) \n This API may be + extended in the future to support additional kinds of parent resources. + \n It is invalid to reference an identical parent more than once. + It is valid to reference multiple distinct sections within the same + parent resource, such as two separate Listeners on the same Gateway + or two separate ports on the same Service. \n It is possible to + separately reference multiple distinct objects that may be collapsed + by an implementation. For example, some implementations may choose + to merge compatible Gateway Listeners together. If that is the case, + the list of routes attached to those resources should also be merged. + \n Note that for ParentRefs that cross namespace boundaries, there + are specific rules. Cross-namespace references are only valid if + they are explicitly allowed by something in the namespace they are + referring to. For example, Gateway has the AllowedRoutes field, + and ReferenceGrant provides a generic way to enable other kinds + of cross-namespace reference. \n ParentRefs from a Route to a Service + in the same namespace are \"producer\" routes, which apply default + routing rules to inbound connections from any namespace to the Service. + \n ParentRefs from a Route to a Service in a different namespace + are \"consumer\" routes, and these routing rules are only applied + to outbound connections originating from the same namespace as the + Route, for which the intended destination of the connections are + a Service targeted as a ParentRef of the Route." items: description: "ParentReference identifies an API object (usually a Gateway) that can be considered a parent of this resource (usually - a route). The only kinds of parent resources with \"Core\" support - are Service (only for implementations supporting the Mesh conformance - profile) and Gateway. This API may be extended in the future to - support additional kinds of parent resources. \n The API object - must be valid in the cluster; the Group and Kind must be registered - in the cluster for this reference to be valid." + a route). There are two kinds of parent resources with \"Core\" + support: \n * Gateway (Gateway conformance profile) * Service + (Mesh conformance profile) \n This API may be extended in the + future to support additional kinds of parent resources. \n The + API object must be valid in the cluster; the Group and Kind must + be registered in the cluster for this reference to be valid." properties: group: default: gateway.networking.k8s.io @@ -145,9 +145,10 @@ spec: type: string kind: default: Gateway - description: "Kind is kind of the referent. \n Support: Core - (Gateway) \n Support: Core (Service - mesh conformance profile - only) \n Support: Implementation-specific (Other Resources)" + description: "Kind is kind of the referent. \n There are two + kinds of parent resources with \"Core\" support: \n * Gateway + (Gateway conformance profile) * Service (Mesh conformance + profile) \n Support for other resources is Implementation-Specific." maxLength: 63 minLength: 1 pattern: ^[a-zA-Z]([-a-zA-Z0-9]*[a-zA-Z0-9])?$ @@ -495,10 +496,11 @@ spec: type: string kind: default: Gateway - description: "Kind is kind of the referent. \n Support: - Core (Gateway) \n Support: Core (Service - mesh conformance - profile only) \n Support: Implementation-specific (Other - Resources)" + description: "Kind is kind of the referent. \n There are + two kinds of parent resources with \"Core\" support: \n + * Gateway (Gateway conformance profile) * Service (Mesh + conformance profile) \n Support for other resources is + Implementation-Specific." maxLength: 63 minLength: 1 pattern: ^[a-zA-Z]([-a-zA-Z0-9]*[a-zA-Z0-9])?$ diff --git a/config/crd/experimental/gateway.networking.k8s.io_udproutes.yaml b/config/crd/experimental/gateway.networking.k8s.io_udproutes.yaml index bcaf167cb5..1fb0453d59 100644 --- a/config/crd/experimental/gateway.networking.k8s.io_udproutes.yaml +++ b/config/crd/experimental/gateway.networking.k8s.io_udproutes.yaml @@ -52,40 +52,40 @@ spec: Routes of this kind and namespace. For Services, that means the Service must either be in the same namespace for a \"producer\" route, or the mesh implementation must support and allow \"consumer\" - routes for the referenced Service. \n The only kinds of parent resources - with \"Core\" support are Service (only for implementations supporting - the Mesh conformance profile) and Gateway. This API may be extended - in the future to support additional kinds of parent resources such - as one of the route kinds. \n It is invalid to reference an identical - parent more than once. It is valid to reference multiple distinct - sections within the same parent resource, such as two separate Listeners - on the same Gateway or two separate ports on the same Service. \n - It is possible to separately reference multiple distinct objects - that may be collapsed by an implementation. For example, some implementations - may choose to merge compatible Gateway Listeners together. If that - is the case, the list of routes attached to those resources should - also be merged. \n Note that for ParentRefs that cross namespace - boundaries, there are specific rules. Cross-namespace references - are only valid if they are explicitly allowed by something in the - namespace they are referring to. For example, Gateway has the AllowedRoutes - field, and ReferenceGrant provides a generic way to enable other - kinds of cross-namespace reference. \n ParentRefs from a Route to - a Service in the same namespace are \"producer\" routes, which apply - default routing rules to inbound connections from any namespace - to the Service. \n ParentRefs from a Route to a Service in a different - namespace are \"consumer\" routes, and these routing rules are only - applied to outbound connections originating from the same namespace - as the Route, for which the intended destination of the connections - are a Service targeted as a ParentRef of the Route." + routes for the referenced Service. \n There are two kinds of parent + resources with \"Core\" support: \n * Gateway (Gateway conformance + profile) * Service (Mesh conformance profile) \n This API may be + extended in the future to support additional kinds of parent resources. + \n It is invalid to reference an identical parent more than once. + It is valid to reference multiple distinct sections within the same + parent resource, such as two separate Listeners on the same Gateway + or two separate ports on the same Service. \n It is possible to + separately reference multiple distinct objects that may be collapsed + by an implementation. For example, some implementations may choose + to merge compatible Gateway Listeners together. If that is the case, + the list of routes attached to those resources should also be merged. + \n Note that for ParentRefs that cross namespace boundaries, there + are specific rules. Cross-namespace references are only valid if + they are explicitly allowed by something in the namespace they are + referring to. For example, Gateway has the AllowedRoutes field, + and ReferenceGrant provides a generic way to enable other kinds + of cross-namespace reference. \n ParentRefs from a Route to a Service + in the same namespace are \"producer\" routes, which apply default + routing rules to inbound connections from any namespace to the Service. + \n ParentRefs from a Route to a Service in a different namespace + are \"consumer\" routes, and these routing rules are only applied + to outbound connections originating from the same namespace as the + Route, for which the intended destination of the connections are + a Service targeted as a ParentRef of the Route." items: description: "ParentReference identifies an API object (usually a Gateway) that can be considered a parent of this resource (usually - a route). The only kinds of parent resources with \"Core\" support - are Service (only for implementations supporting the Mesh conformance - profile) and Gateway. This API may be extended in the future to - support additional kinds of parent resources. \n The API object - must be valid in the cluster; the Group and Kind must be registered - in the cluster for this reference to be valid." + a route). There are two kinds of parent resources with \"Core\" + support: \n * Gateway (Gateway conformance profile) * Service + (Mesh conformance profile) \n This API may be extended in the + future to support additional kinds of parent resources. \n The + API object must be valid in the cluster; the Group and Kind must + be registered in the cluster for this reference to be valid." properties: group: default: gateway.networking.k8s.io @@ -99,9 +99,10 @@ spec: type: string kind: default: Gateway - description: "Kind is kind of the referent. \n Support: Core - (Gateway) \n Support: Core (Service - mesh conformance profile - only) \n Support: Implementation-specific (Other Resources)" + description: "Kind is kind of the referent. \n There are two + kinds of parent resources with \"Core\" support: \n * Gateway + (Gateway conformance profile) * Service (Mesh conformance + profile) \n Support for other resources is Implementation-Specific." maxLength: 63 minLength: 1 pattern: ^[a-zA-Z]([-a-zA-Z0-9]*[a-zA-Z0-9])?$ @@ -446,10 +447,11 @@ spec: type: string kind: default: Gateway - description: "Kind is kind of the referent. \n Support: - Core (Gateway) \n Support: Core (Service - mesh conformance - profile only) \n Support: Implementation-specific (Other - Resources)" + description: "Kind is kind of the referent. \n There are + two kinds of parent resources with \"Core\" support: \n + * Gateway (Gateway conformance profile) * Service (Mesh + conformance profile) \n Support for other resources is + Implementation-Specific." maxLength: 63 minLength: 1 pattern: ^[a-zA-Z]([-a-zA-Z0-9]*[a-zA-Z0-9])?$ diff --git a/config/crd/standard/gateway.networking.k8s.io_httproutes.yaml b/config/crd/standard/gateway.networking.k8s.io_httproutes.yaml index 1a4cdaa6d9..f6eb3841b2 100644 --- a/config/crd/standard/gateway.networking.k8s.io_httproutes.yaml +++ b/config/crd/standard/gateway.networking.k8s.io_httproutes.yaml @@ -117,40 +117,40 @@ spec: Routes of this kind and namespace. For Services, that means the Service must either be in the same namespace for a \"producer\" route, or the mesh implementation must support and allow \"consumer\" - routes for the referenced Service. \n The only kinds of parent resources - with \"Core\" support are Service (only for implementations supporting - the Mesh conformance profile) and Gateway. This API may be extended - in the future to support additional kinds of parent resources such - as one of the route kinds. \n It is invalid to reference an identical - parent more than once. It is valid to reference multiple distinct - sections within the same parent resource, such as two separate Listeners - on the same Gateway or two separate ports on the same Service. \n - It is possible to separately reference multiple distinct objects - that may be collapsed by an implementation. For example, some implementations - may choose to merge compatible Gateway Listeners together. If that - is the case, the list of routes attached to those resources should - also be merged. \n Note that for ParentRefs that cross namespace - boundaries, there are specific rules. Cross-namespace references - are only valid if they are explicitly allowed by something in the - namespace they are referring to. For example, Gateway has the AllowedRoutes - field, and ReferenceGrant provides a generic way to enable other - kinds of cross-namespace reference. \n ParentRefs from a Route to - a Service in the same namespace are \"producer\" routes, which apply - default routing rules to inbound connections from any namespace - to the Service. \n ParentRefs from a Route to a Service in a different - namespace are \"consumer\" routes, and these routing rules are only - applied to outbound connections originating from the same namespace - as the Route, for which the intended destination of the connections - are a Service targeted as a ParentRef of the Route." + routes for the referenced Service. \n There are two kinds of parent + resources with \"Core\" support: \n * Gateway (Gateway conformance + profile) * Service (Mesh conformance profile) \n This API may be + extended in the future to support additional kinds of parent resources. + \n It is invalid to reference an identical parent more than once. + It is valid to reference multiple distinct sections within the same + parent resource, such as two separate Listeners on the same Gateway + or two separate ports on the same Service. \n It is possible to + separately reference multiple distinct objects that may be collapsed + by an implementation. For example, some implementations may choose + to merge compatible Gateway Listeners together. If that is the case, + the list of routes attached to those resources should also be merged. + \n Note that for ParentRefs that cross namespace boundaries, there + are specific rules. Cross-namespace references are only valid if + they are explicitly allowed by something in the namespace they are + referring to. For example, Gateway has the AllowedRoutes field, + and ReferenceGrant provides a generic way to enable other kinds + of cross-namespace reference. \n ParentRefs from a Route to a Service + in the same namespace are \"producer\" routes, which apply default + routing rules to inbound connections from any namespace to the Service. + \n ParentRefs from a Route to a Service in a different namespace + are \"consumer\" routes, and these routing rules are only applied + to outbound connections originating from the same namespace as the + Route, for which the intended destination of the connections are + a Service targeted as a ParentRef of the Route." items: description: "ParentReference identifies an API object (usually a Gateway) that can be considered a parent of this resource (usually - a route). The only kinds of parent resources with \"Core\" support - are Service (only for implementations supporting the Mesh conformance - profile) and Gateway. This API may be extended in the future to - support additional kinds of parent resources. \n The API object - must be valid in the cluster; the Group and Kind must be registered - in the cluster for this reference to be valid." + a route). There are two kinds of parent resources with \"Core\" + support: \n * Gateway (Gateway conformance profile) * Service + (Mesh conformance profile) \n This API may be extended in the + future to support additional kinds of parent resources. \n The + API object must be valid in the cluster; the Group and Kind must + be registered in the cluster for this reference to be valid." properties: group: default: gateway.networking.k8s.io @@ -164,9 +164,10 @@ spec: type: string kind: default: Gateway - description: "Kind is kind of the referent. \n Support: Core - (Gateway) \n Support: Core (Service - mesh conformance profile - only) \n Support: Implementation-specific (Other Resources)" + description: "Kind is kind of the referent. \n There are two + kinds of parent resources with \"Core\" support: \n * Gateway + (Gateway conformance profile) * Service (Mesh conformance + profile) \n Support for other resources is Implementation-Specific." maxLength: 63 minLength: 1 pattern: ^[a-zA-Z]([-a-zA-Z0-9]*[a-zA-Z0-9])?$ @@ -1907,10 +1908,11 @@ spec: type: string kind: default: Gateway - description: "Kind is kind of the referent. \n Support: - Core (Gateway) \n Support: Core (Service - mesh conformance - profile only) \n Support: Implementation-specific (Other - Resources)" + description: "Kind is kind of the referent. \n There are + two kinds of parent resources with \"Core\" support: \n + * Gateway (Gateway conformance profile) * Service (Mesh + conformance profile) \n Support for other resources is + Implementation-Specific." maxLength: 63 minLength: 1 pattern: ^[a-zA-Z]([-a-zA-Z0-9]*[a-zA-Z0-9])?$ @@ -2083,40 +2085,40 @@ spec: Routes of this kind and namespace. For Services, that means the Service must either be in the same namespace for a \"producer\" route, or the mesh implementation must support and allow \"consumer\" - routes for the referenced Service. \n The only kinds of parent resources - with \"Core\" support are Service (only for implementations supporting - the Mesh conformance profile) and Gateway. This API may be extended - in the future to support additional kinds of parent resources such - as one of the route kinds. \n It is invalid to reference an identical - parent more than once. It is valid to reference multiple distinct - sections within the same parent resource, such as two separate Listeners - on the same Gateway or two separate ports on the same Service. \n - It is possible to separately reference multiple distinct objects - that may be collapsed by an implementation. For example, some implementations - may choose to merge compatible Gateway Listeners together. If that - is the case, the list of routes attached to those resources should - also be merged. \n Note that for ParentRefs that cross namespace - boundaries, there are specific rules. Cross-namespace references - are only valid if they are explicitly allowed by something in the - namespace they are referring to. For example, Gateway has the AllowedRoutes - field, and ReferenceGrant provides a generic way to enable other - kinds of cross-namespace reference. \n ParentRefs from a Route to - a Service in the same namespace are \"producer\" routes, which apply - default routing rules to inbound connections from any namespace - to the Service. \n ParentRefs from a Route to a Service in a different - namespace are \"consumer\" routes, and these routing rules are only - applied to outbound connections originating from the same namespace - as the Route, for which the intended destination of the connections - are a Service targeted as a ParentRef of the Route." + routes for the referenced Service. \n There are two kinds of parent + resources with \"Core\" support: \n * Gateway (Gateway conformance + profile) * Service (Mesh conformance profile) \n This API may be + extended in the future to support additional kinds of parent resources. + \n It is invalid to reference an identical parent more than once. + It is valid to reference multiple distinct sections within the same + parent resource, such as two separate Listeners on the same Gateway + or two separate ports on the same Service. \n It is possible to + separately reference multiple distinct objects that may be collapsed + by an implementation. For example, some implementations may choose + to merge compatible Gateway Listeners together. If that is the case, + the list of routes attached to those resources should also be merged. + \n Note that for ParentRefs that cross namespace boundaries, there + are specific rules. Cross-namespace references are only valid if + they are explicitly allowed by something in the namespace they are + referring to. For example, Gateway has the AllowedRoutes field, + and ReferenceGrant provides a generic way to enable other kinds + of cross-namespace reference. \n ParentRefs from a Route to a Service + in the same namespace are \"producer\" routes, which apply default + routing rules to inbound connections from any namespace to the Service. + \n ParentRefs from a Route to a Service in a different namespace + are \"consumer\" routes, and these routing rules are only applied + to outbound connections originating from the same namespace as the + Route, for which the intended destination of the connections are + a Service targeted as a ParentRef of the Route." items: description: "ParentReference identifies an API object (usually a Gateway) that can be considered a parent of this resource (usually - a route). The only kinds of parent resources with \"Core\" support - are Service (only for implementations supporting the Mesh conformance - profile) and Gateway. This API may be extended in the future to - support additional kinds of parent resources. \n The API object - must be valid in the cluster; the Group and Kind must be registered - in the cluster for this reference to be valid." + a route). There are two kinds of parent resources with \"Core\" + support: \n * Gateway (Gateway conformance profile) * Service + (Mesh conformance profile) \n This API may be extended in the + future to support additional kinds of parent resources. \n The + API object must be valid in the cluster; the Group and Kind must + be registered in the cluster for this reference to be valid." properties: group: default: gateway.networking.k8s.io @@ -2130,9 +2132,10 @@ spec: type: string kind: default: Gateway - description: "Kind is kind of the referent. \n Support: Core - (Gateway) \n Support: Core (Service - mesh conformance profile - only) \n Support: Implementation-specific (Other Resources)" + description: "Kind is kind of the referent. \n There are two + kinds of parent resources with \"Core\" support: \n * Gateway + (Gateway conformance profile) * Service (Mesh conformance + profile) \n Support for other resources is Implementation-Specific." maxLength: 63 minLength: 1 pattern: ^[a-zA-Z]([-a-zA-Z0-9]*[a-zA-Z0-9])?$ @@ -3873,10 +3876,11 @@ spec: type: string kind: default: Gateway - description: "Kind is kind of the referent. \n Support: - Core (Gateway) \n Support: Core (Service - mesh conformance - profile only) \n Support: Implementation-specific (Other - Resources)" + description: "Kind is kind of the referent. \n There are + two kinds of parent resources with \"Core\" support: \n + * Gateway (Gateway conformance profile) * Service (Mesh + conformance profile) \n Support for other resources is + Implementation-Specific." maxLength: 63 minLength: 1 pattern: ^[a-zA-Z]([-a-zA-Z0-9]*[a-zA-Z0-9])?$ From 97545b695db975f6bbacb7b81c2790004c796234 Mon Sep 17 00:00:00 2001 From: Mike Morris Date: Mon, 3 Jul 2023 16:09:00 -0400 Subject: [PATCH 13/14] clarify ReferenceGrant non-applicability for Service ParentRefs on consumer mesh routes --- apis/v1alpha2/referencegrant_types.go | 8 ++++++-- apis/v1beta1/shared_types.go | 5 ++++- 2 files changed, 10 insertions(+), 3 deletions(-) diff --git a/apis/v1alpha2/referencegrant_types.go b/apis/v1alpha2/referencegrant_types.go index 903b1f4f26..1cecc75fab 100644 --- a/apis/v1alpha2/referencegrant_types.go +++ b/apis/v1alpha2/referencegrant_types.go @@ -36,8 +36,12 @@ import ( // Additional Reference Grants can be used to add to the set of trusted // sources of inbound references for the namespace they are defined within. // -// All cross-namespace references in Gateway API (with the exception of cross-namespace -// Gateway-route attachment) require a ReferenceGrant. +// A ReferenceGrant is required for all cross-namespace references in Gateway API +// (with the exception of cross-namespace Route-Gateway attachment, which is +// governed by the AllowedRoutes configuration on the Gateway, and cross-namespace +// Service ParentRefs on a "consumer" mesh Route, which defines routing rules +// applicable only to workloads in the Route namespace). ReferenceGrants allowing +// a reference from a Route to a Service are only applicable to BackendRefs. // // ReferenceGrant is a form of runtime verification allowing users to assert // which cross-namespace object references are permitted. Implementations that diff --git a/apis/v1beta1/shared_types.go b/apis/v1beta1/shared_types.go index 07a743064e..830feac862 100644 --- a/apis/v1beta1/shared_types.go +++ b/apis/v1beta1/shared_types.go @@ -154,7 +154,10 @@ type CommonRouteSpec struct { // the Gateway needs to allow attachment from Routes of this kind and // namespace. For Services, that means the Service must either be in the same // namespace for a "producer" route, or the mesh implementation must support - // and allow "consumer" routes for the referenced Service. + // and allow "consumer" routes for the referenced Service. ReferenceGrant is + // not applicable for governing ParentRefs to Services - it is not possible to + // create a "producer" route for a Service in a different namespace from the + // Route. // // There are two kinds of parent resources with "Core" support: // From 4eba3e9bf7f5dadd29c90645c8501166d46a9db5 Mon Sep 17 00:00:00 2001 From: Mike Morris Date: Mon, 3 Jul 2023 16:09:48 -0400 Subject: [PATCH 14/14] update CRDs --- .../gateway.networking.k8s.io_grpcroutes.yaml | 53 ++++----- .../gateway.networking.k8s.io_httproutes.yaml | 106 +++++++++--------- ...way.networking.k8s.io_referencegrants.yaml | 18 +-- .../gateway.networking.k8s.io_tcproutes.yaml | 53 ++++----- .../gateway.networking.k8s.io_tlsroutes.yaml | 53 ++++----- .../gateway.networking.k8s.io_udproutes.yaml | 53 ++++----- .../gateway.networking.k8s.io_httproutes.yaml | 106 +++++++++--------- ...way.networking.k8s.io_referencegrants.yaml | 18 +-- 8 files changed, 246 insertions(+), 214 deletions(-) diff --git a/config/crd/experimental/gateway.networking.k8s.io_grpcroutes.yaml b/config/crd/experimental/gateway.networking.k8s.io_grpcroutes.yaml index bfc256a308..68f40c6b0d 100644 --- a/config/crd/experimental/gateway.networking.k8s.io_grpcroutes.yaml +++ b/config/crd/experimental/gateway.networking.k8s.io_grpcroutes.yaml @@ -130,31 +130,34 @@ spec: Routes of this kind and namespace. For Services, that means the Service must either be in the same namespace for a \"producer\" route, or the mesh implementation must support and allow \"consumer\" - routes for the referenced Service. \n There are two kinds of parent - resources with \"Core\" support: \n * Gateway (Gateway conformance - profile) * Service (Mesh conformance profile) \n This API may be - extended in the future to support additional kinds of parent resources. - \n It is invalid to reference an identical parent more than once. - It is valid to reference multiple distinct sections within the same - parent resource, such as two separate Listeners on the same Gateway - or two separate ports on the same Service. \n It is possible to - separately reference multiple distinct objects that may be collapsed - by an implementation. For example, some implementations may choose - to merge compatible Gateway Listeners together. If that is the case, - the list of routes attached to those resources should also be merged. - \n Note that for ParentRefs that cross namespace boundaries, there - are specific rules. Cross-namespace references are only valid if - they are explicitly allowed by something in the namespace they are - referring to. For example, Gateway has the AllowedRoutes field, - and ReferenceGrant provides a generic way to enable other kinds - of cross-namespace reference. \n ParentRefs from a Route to a Service - in the same namespace are \"producer\" routes, which apply default - routing rules to inbound connections from any namespace to the Service. - \n ParentRefs from a Route to a Service in a different namespace - are \"consumer\" routes, and these routing rules are only applied - to outbound connections originating from the same namespace as the - Route, for which the intended destination of the connections are - a Service targeted as a ParentRef of the Route." + routes for the referenced Service. ReferenceGrant is not applicable + for governing ParentRefs to Services - it is not possible to create + a \"producer\" route for a Service in a different namespace from + the Route. \n There are two kinds of parent resources with \"Core\" + support: \n * Gateway (Gateway conformance profile) * Service (Mesh + conformance profile) \n This API may be extended in the future to + support additional kinds of parent resources. \n It is invalid to + reference an identical parent more than once. It is valid to reference + multiple distinct sections within the same parent resource, such + as two separate Listeners on the same Gateway or two separate ports + on the same Service. \n It is possible to separately reference multiple + distinct objects that may be collapsed by an implementation. For + example, some implementations may choose to merge compatible Gateway + Listeners together. If that is the case, the list of routes attached + to those resources should also be merged. \n Note that for ParentRefs + that cross namespace boundaries, there are specific rules. Cross-namespace + references are only valid if they are explicitly allowed by something + in the namespace they are referring to. For example, Gateway has + the AllowedRoutes field, and ReferenceGrant provides a generic way + to enable other kinds of cross-namespace reference. \n ParentRefs + from a Route to a Service in the same namespace are \"producer\" + routes, which apply default routing rules to inbound connections + from any namespace to the Service. \n ParentRefs from a Route to + a Service in a different namespace are \"consumer\" routes, and + these routing rules are only applied to outbound connections originating + from the same namespace as the Route, for which the intended destination + of the connections are a Service targeted as a ParentRef of the + Route." items: description: "ParentReference identifies an API object (usually a Gateway) that can be considered a parent of this resource (usually diff --git a/config/crd/experimental/gateway.networking.k8s.io_httproutes.yaml b/config/crd/experimental/gateway.networking.k8s.io_httproutes.yaml index 9838abe717..5e3309758c 100644 --- a/config/crd/experimental/gateway.networking.k8s.io_httproutes.yaml +++ b/config/crd/experimental/gateway.networking.k8s.io_httproutes.yaml @@ -117,31 +117,34 @@ spec: Routes of this kind and namespace. For Services, that means the Service must either be in the same namespace for a \"producer\" route, or the mesh implementation must support and allow \"consumer\" - routes for the referenced Service. \n There are two kinds of parent - resources with \"Core\" support: \n * Gateway (Gateway conformance - profile) * Service (Mesh conformance profile) \n This API may be - extended in the future to support additional kinds of parent resources. - \n It is invalid to reference an identical parent more than once. - It is valid to reference multiple distinct sections within the same - parent resource, such as two separate Listeners on the same Gateway - or two separate ports on the same Service. \n It is possible to - separately reference multiple distinct objects that may be collapsed - by an implementation. For example, some implementations may choose - to merge compatible Gateway Listeners together. If that is the case, - the list of routes attached to those resources should also be merged. - \n Note that for ParentRefs that cross namespace boundaries, there - are specific rules. Cross-namespace references are only valid if - they are explicitly allowed by something in the namespace they are - referring to. For example, Gateway has the AllowedRoutes field, - and ReferenceGrant provides a generic way to enable other kinds - of cross-namespace reference. \n ParentRefs from a Route to a Service - in the same namespace are \"producer\" routes, which apply default - routing rules to inbound connections from any namespace to the Service. - \n ParentRefs from a Route to a Service in a different namespace - are \"consumer\" routes, and these routing rules are only applied - to outbound connections originating from the same namespace as the - Route, for which the intended destination of the connections are - a Service targeted as a ParentRef of the Route." + routes for the referenced Service. ReferenceGrant is not applicable + for governing ParentRefs to Services - it is not possible to create + a \"producer\" route for a Service in a different namespace from + the Route. \n There are two kinds of parent resources with \"Core\" + support: \n * Gateway (Gateway conformance profile) * Service (Mesh + conformance profile) \n This API may be extended in the future to + support additional kinds of parent resources. \n It is invalid to + reference an identical parent more than once. It is valid to reference + multiple distinct sections within the same parent resource, such + as two separate Listeners on the same Gateway or two separate ports + on the same Service. \n It is possible to separately reference multiple + distinct objects that may be collapsed by an implementation. For + example, some implementations may choose to merge compatible Gateway + Listeners together. If that is the case, the list of routes attached + to those resources should also be merged. \n Note that for ParentRefs + that cross namespace boundaries, there are specific rules. Cross-namespace + references are only valid if they are explicitly allowed by something + in the namespace they are referring to. For example, Gateway has + the AllowedRoutes field, and ReferenceGrant provides a generic way + to enable other kinds of cross-namespace reference. \n ParentRefs + from a Route to a Service in the same namespace are \"producer\" + routes, which apply default routing rules to inbound connections + from any namespace to the Service. \n ParentRefs from a Route to + a Service in a different namespace are \"consumer\" routes, and + these routing rules are only applied to outbound connections originating + from the same namespace as the Route, for which the intended destination + of the connections are a Service targeted as a ParentRef of the + Route." items: description: "ParentReference identifies an API object (usually a Gateway) that can be considered a parent of this resource (usually @@ -2147,31 +2150,34 @@ spec: Routes of this kind and namespace. For Services, that means the Service must either be in the same namespace for a \"producer\" route, or the mesh implementation must support and allow \"consumer\" - routes for the referenced Service. \n There are two kinds of parent - resources with \"Core\" support: \n * Gateway (Gateway conformance - profile) * Service (Mesh conformance profile) \n This API may be - extended in the future to support additional kinds of parent resources. - \n It is invalid to reference an identical parent more than once. - It is valid to reference multiple distinct sections within the same - parent resource, such as two separate Listeners on the same Gateway - or two separate ports on the same Service. \n It is possible to - separately reference multiple distinct objects that may be collapsed - by an implementation. For example, some implementations may choose - to merge compatible Gateway Listeners together. If that is the case, - the list of routes attached to those resources should also be merged. - \n Note that for ParentRefs that cross namespace boundaries, there - are specific rules. Cross-namespace references are only valid if - they are explicitly allowed by something in the namespace they are - referring to. For example, Gateway has the AllowedRoutes field, - and ReferenceGrant provides a generic way to enable other kinds - of cross-namespace reference. \n ParentRefs from a Route to a Service - in the same namespace are \"producer\" routes, which apply default - routing rules to inbound connections from any namespace to the Service. - \n ParentRefs from a Route to a Service in a different namespace - are \"consumer\" routes, and these routing rules are only applied - to outbound connections originating from the same namespace as the - Route, for which the intended destination of the connections are - a Service targeted as a ParentRef of the Route." + routes for the referenced Service. ReferenceGrant is not applicable + for governing ParentRefs to Services - it is not possible to create + a \"producer\" route for a Service in a different namespace from + the Route. \n There are two kinds of parent resources with \"Core\" + support: \n * Gateway (Gateway conformance profile) * Service (Mesh + conformance profile) \n This API may be extended in the future to + support additional kinds of parent resources. \n It is invalid to + reference an identical parent more than once. It is valid to reference + multiple distinct sections within the same parent resource, such + as two separate Listeners on the same Gateway or two separate ports + on the same Service. \n It is possible to separately reference multiple + distinct objects that may be collapsed by an implementation. For + example, some implementations may choose to merge compatible Gateway + Listeners together. If that is the case, the list of routes attached + to those resources should also be merged. \n Note that for ParentRefs + that cross namespace boundaries, there are specific rules. Cross-namespace + references are only valid if they are explicitly allowed by something + in the namespace they are referring to. For example, Gateway has + the AllowedRoutes field, and ReferenceGrant provides a generic way + to enable other kinds of cross-namespace reference. \n ParentRefs + from a Route to a Service in the same namespace are \"producer\" + routes, which apply default routing rules to inbound connections + from any namespace to the Service. \n ParentRefs from a Route to + a Service in a different namespace are \"consumer\" routes, and + these routing rules are only applied to outbound connections originating + from the same namespace as the Route, for which the intended destination + of the connections are a Service targeted as a ParentRef of the + Route." items: description: "ParentReference identifies an API object (usually a Gateway) that can be considered a parent of this resource (usually diff --git a/config/crd/experimental/gateway.networking.k8s.io_referencegrants.yaml b/config/crd/experimental/gateway.networking.k8s.io_referencegrants.yaml index 801ccff0c5..b52b79d69b 100644 --- a/config/crd/experimental/gateway.networking.k8s.io_referencegrants.yaml +++ b/config/crd/experimental/gateway.networking.k8s.io_referencegrants.yaml @@ -35,13 +35,17 @@ spec: namespace as the policy. \n Each ReferenceGrant can be used to represent a unique trust relationship. Additional Reference Grants can be used to add to the set of trusted sources of inbound references for the namespace - they are defined within. \n All cross-namespace references in Gateway API - (with the exception of cross-namespace Gateway-route attachment) require - a ReferenceGrant. \n ReferenceGrant is a form of runtime verification allowing - users to assert which cross-namespace object references are permitted. Implementations - that support ReferenceGrant MUST NOT permit cross-namespace references which - have no grant, and MUST respond to the removal of a grant by revoking the - access that the grant allowed. \n Support: Core" + they are defined within. \n A ReferenceGrant is required for all cross-namespace + references in Gateway API (with the exception of cross-namespace Route-Gateway + attachment, which is governed by the AllowedRoutes configuration on the + Gateway, and cross-namespace Service ParentRefs on a \"consumer\" mesh Route, + which defines routing rules applicable only to workloads in the Route namespace). + ReferenceGrants allowing a reference from a Route to a Service are only + applicable to BackendRefs. \n ReferenceGrant is a form of runtime verification + allowing users to assert which cross-namespace object references are permitted. + Implementations that support ReferenceGrant MUST NOT permit cross-namespace + references which have no grant, and MUST respond to the removal of a grant + by revoking the access that the grant allowed. \n Support: Core" properties: apiVersion: description: 'APIVersion defines the versioned schema of this representation diff --git a/config/crd/experimental/gateway.networking.k8s.io_tcproutes.yaml b/config/crd/experimental/gateway.networking.k8s.io_tcproutes.yaml index b8e25a59ea..c8f925e61d 100644 --- a/config/crd/experimental/gateway.networking.k8s.io_tcproutes.yaml +++ b/config/crd/experimental/gateway.networking.k8s.io_tcproutes.yaml @@ -52,31 +52,34 @@ spec: Routes of this kind and namespace. For Services, that means the Service must either be in the same namespace for a \"producer\" route, or the mesh implementation must support and allow \"consumer\" - routes for the referenced Service. \n There are two kinds of parent - resources with \"Core\" support: \n * Gateway (Gateway conformance - profile) * Service (Mesh conformance profile) \n This API may be - extended in the future to support additional kinds of parent resources. - \n It is invalid to reference an identical parent more than once. - It is valid to reference multiple distinct sections within the same - parent resource, such as two separate Listeners on the same Gateway - or two separate ports on the same Service. \n It is possible to - separately reference multiple distinct objects that may be collapsed - by an implementation. For example, some implementations may choose - to merge compatible Gateway Listeners together. If that is the case, - the list of routes attached to those resources should also be merged. - \n Note that for ParentRefs that cross namespace boundaries, there - are specific rules. Cross-namespace references are only valid if - they are explicitly allowed by something in the namespace they are - referring to. For example, Gateway has the AllowedRoutes field, - and ReferenceGrant provides a generic way to enable other kinds - of cross-namespace reference. \n ParentRefs from a Route to a Service - in the same namespace are \"producer\" routes, which apply default - routing rules to inbound connections from any namespace to the Service. - \n ParentRefs from a Route to a Service in a different namespace - are \"consumer\" routes, and these routing rules are only applied - to outbound connections originating from the same namespace as the - Route, for which the intended destination of the connections are - a Service targeted as a ParentRef of the Route." + routes for the referenced Service. ReferenceGrant is not applicable + for governing ParentRefs to Services - it is not possible to create + a \"producer\" route for a Service in a different namespace from + the Route. \n There are two kinds of parent resources with \"Core\" + support: \n * Gateway (Gateway conformance profile) * Service (Mesh + conformance profile) \n This API may be extended in the future to + support additional kinds of parent resources. \n It is invalid to + reference an identical parent more than once. It is valid to reference + multiple distinct sections within the same parent resource, such + as two separate Listeners on the same Gateway or two separate ports + on the same Service. \n It is possible to separately reference multiple + distinct objects that may be collapsed by an implementation. For + example, some implementations may choose to merge compatible Gateway + Listeners together. If that is the case, the list of routes attached + to those resources should also be merged. \n Note that for ParentRefs + that cross namespace boundaries, there are specific rules. Cross-namespace + references are only valid if they are explicitly allowed by something + in the namespace they are referring to. For example, Gateway has + the AllowedRoutes field, and ReferenceGrant provides a generic way + to enable other kinds of cross-namespace reference. \n ParentRefs + from a Route to a Service in the same namespace are \"producer\" + routes, which apply default routing rules to inbound connections + from any namespace to the Service. \n ParentRefs from a Route to + a Service in a different namespace are \"consumer\" routes, and + these routing rules are only applied to outbound connections originating + from the same namespace as the Route, for which the intended destination + of the connections are a Service targeted as a ParentRef of the + Route." items: description: "ParentReference identifies an API object (usually a Gateway) that can be considered a parent of this resource (usually diff --git a/config/crd/experimental/gateway.networking.k8s.io_tlsroutes.yaml b/config/crd/experimental/gateway.networking.k8s.io_tlsroutes.yaml index b13fcd0b58..e35b549dc2 100644 --- a/config/crd/experimental/gateway.networking.k8s.io_tlsroutes.yaml +++ b/config/crd/experimental/gateway.networking.k8s.io_tlsroutes.yaml @@ -98,31 +98,34 @@ spec: Routes of this kind and namespace. For Services, that means the Service must either be in the same namespace for a \"producer\" route, or the mesh implementation must support and allow \"consumer\" - routes for the referenced Service. \n There are two kinds of parent - resources with \"Core\" support: \n * Gateway (Gateway conformance - profile) * Service (Mesh conformance profile) \n This API may be - extended in the future to support additional kinds of parent resources. - \n It is invalid to reference an identical parent more than once. - It is valid to reference multiple distinct sections within the same - parent resource, such as two separate Listeners on the same Gateway - or two separate ports on the same Service. \n It is possible to - separately reference multiple distinct objects that may be collapsed - by an implementation. For example, some implementations may choose - to merge compatible Gateway Listeners together. If that is the case, - the list of routes attached to those resources should also be merged. - \n Note that for ParentRefs that cross namespace boundaries, there - are specific rules. Cross-namespace references are only valid if - they are explicitly allowed by something in the namespace they are - referring to. For example, Gateway has the AllowedRoutes field, - and ReferenceGrant provides a generic way to enable other kinds - of cross-namespace reference. \n ParentRefs from a Route to a Service - in the same namespace are \"producer\" routes, which apply default - routing rules to inbound connections from any namespace to the Service. - \n ParentRefs from a Route to a Service in a different namespace - are \"consumer\" routes, and these routing rules are only applied - to outbound connections originating from the same namespace as the - Route, for which the intended destination of the connections are - a Service targeted as a ParentRef of the Route." + routes for the referenced Service. ReferenceGrant is not applicable + for governing ParentRefs to Services - it is not possible to create + a \"producer\" route for a Service in a different namespace from + the Route. \n There are two kinds of parent resources with \"Core\" + support: \n * Gateway (Gateway conformance profile) * Service (Mesh + conformance profile) \n This API may be extended in the future to + support additional kinds of parent resources. \n It is invalid to + reference an identical parent more than once. It is valid to reference + multiple distinct sections within the same parent resource, such + as two separate Listeners on the same Gateway or two separate ports + on the same Service. \n It is possible to separately reference multiple + distinct objects that may be collapsed by an implementation. For + example, some implementations may choose to merge compatible Gateway + Listeners together. If that is the case, the list of routes attached + to those resources should also be merged. \n Note that for ParentRefs + that cross namespace boundaries, there are specific rules. Cross-namespace + references are only valid if they are explicitly allowed by something + in the namespace they are referring to. For example, Gateway has + the AllowedRoutes field, and ReferenceGrant provides a generic way + to enable other kinds of cross-namespace reference. \n ParentRefs + from a Route to a Service in the same namespace are \"producer\" + routes, which apply default routing rules to inbound connections + from any namespace to the Service. \n ParentRefs from a Route to + a Service in a different namespace are \"consumer\" routes, and + these routing rules are only applied to outbound connections originating + from the same namespace as the Route, for which the intended destination + of the connections are a Service targeted as a ParentRef of the + Route." items: description: "ParentReference identifies an API object (usually a Gateway) that can be considered a parent of this resource (usually diff --git a/config/crd/experimental/gateway.networking.k8s.io_udproutes.yaml b/config/crd/experimental/gateway.networking.k8s.io_udproutes.yaml index 1fb0453d59..3af15f3892 100644 --- a/config/crd/experimental/gateway.networking.k8s.io_udproutes.yaml +++ b/config/crd/experimental/gateway.networking.k8s.io_udproutes.yaml @@ -52,31 +52,34 @@ spec: Routes of this kind and namespace. For Services, that means the Service must either be in the same namespace for a \"producer\" route, or the mesh implementation must support and allow \"consumer\" - routes for the referenced Service. \n There are two kinds of parent - resources with \"Core\" support: \n * Gateway (Gateway conformance - profile) * Service (Mesh conformance profile) \n This API may be - extended in the future to support additional kinds of parent resources. - \n It is invalid to reference an identical parent more than once. - It is valid to reference multiple distinct sections within the same - parent resource, such as two separate Listeners on the same Gateway - or two separate ports on the same Service. \n It is possible to - separately reference multiple distinct objects that may be collapsed - by an implementation. For example, some implementations may choose - to merge compatible Gateway Listeners together. If that is the case, - the list of routes attached to those resources should also be merged. - \n Note that for ParentRefs that cross namespace boundaries, there - are specific rules. Cross-namespace references are only valid if - they are explicitly allowed by something in the namespace they are - referring to. For example, Gateway has the AllowedRoutes field, - and ReferenceGrant provides a generic way to enable other kinds - of cross-namespace reference. \n ParentRefs from a Route to a Service - in the same namespace are \"producer\" routes, which apply default - routing rules to inbound connections from any namespace to the Service. - \n ParentRefs from a Route to a Service in a different namespace - are \"consumer\" routes, and these routing rules are only applied - to outbound connections originating from the same namespace as the - Route, for which the intended destination of the connections are - a Service targeted as a ParentRef of the Route." + routes for the referenced Service. ReferenceGrant is not applicable + for governing ParentRefs to Services - it is not possible to create + a \"producer\" route for a Service in a different namespace from + the Route. \n There are two kinds of parent resources with \"Core\" + support: \n * Gateway (Gateway conformance profile) * Service (Mesh + conformance profile) \n This API may be extended in the future to + support additional kinds of parent resources. \n It is invalid to + reference an identical parent more than once. It is valid to reference + multiple distinct sections within the same parent resource, such + as two separate Listeners on the same Gateway or two separate ports + on the same Service. \n It is possible to separately reference multiple + distinct objects that may be collapsed by an implementation. For + example, some implementations may choose to merge compatible Gateway + Listeners together. If that is the case, the list of routes attached + to those resources should also be merged. \n Note that for ParentRefs + that cross namespace boundaries, there are specific rules. Cross-namespace + references are only valid if they are explicitly allowed by something + in the namespace they are referring to. For example, Gateway has + the AllowedRoutes field, and ReferenceGrant provides a generic way + to enable other kinds of cross-namespace reference. \n ParentRefs + from a Route to a Service in the same namespace are \"producer\" + routes, which apply default routing rules to inbound connections + from any namespace to the Service. \n ParentRefs from a Route to + a Service in a different namespace are \"consumer\" routes, and + these routing rules are only applied to outbound connections originating + from the same namespace as the Route, for which the intended destination + of the connections are a Service targeted as a ParentRef of the + Route." items: description: "ParentReference identifies an API object (usually a Gateway) that can be considered a parent of this resource (usually diff --git a/config/crd/standard/gateway.networking.k8s.io_httproutes.yaml b/config/crd/standard/gateway.networking.k8s.io_httproutes.yaml index f6eb3841b2..9ac7c12e7f 100644 --- a/config/crd/standard/gateway.networking.k8s.io_httproutes.yaml +++ b/config/crd/standard/gateway.networking.k8s.io_httproutes.yaml @@ -117,31 +117,34 @@ spec: Routes of this kind and namespace. For Services, that means the Service must either be in the same namespace for a \"producer\" route, or the mesh implementation must support and allow \"consumer\" - routes for the referenced Service. \n There are two kinds of parent - resources with \"Core\" support: \n * Gateway (Gateway conformance - profile) * Service (Mesh conformance profile) \n This API may be - extended in the future to support additional kinds of parent resources. - \n It is invalid to reference an identical parent more than once. - It is valid to reference multiple distinct sections within the same - parent resource, such as two separate Listeners on the same Gateway - or two separate ports on the same Service. \n It is possible to - separately reference multiple distinct objects that may be collapsed - by an implementation. For example, some implementations may choose - to merge compatible Gateway Listeners together. If that is the case, - the list of routes attached to those resources should also be merged. - \n Note that for ParentRefs that cross namespace boundaries, there - are specific rules. Cross-namespace references are only valid if - they are explicitly allowed by something in the namespace they are - referring to. For example, Gateway has the AllowedRoutes field, - and ReferenceGrant provides a generic way to enable other kinds - of cross-namespace reference. \n ParentRefs from a Route to a Service - in the same namespace are \"producer\" routes, which apply default - routing rules to inbound connections from any namespace to the Service. - \n ParentRefs from a Route to a Service in a different namespace - are \"consumer\" routes, and these routing rules are only applied - to outbound connections originating from the same namespace as the - Route, for which the intended destination of the connections are - a Service targeted as a ParentRef of the Route." + routes for the referenced Service. ReferenceGrant is not applicable + for governing ParentRefs to Services - it is not possible to create + a \"producer\" route for a Service in a different namespace from + the Route. \n There are two kinds of parent resources with \"Core\" + support: \n * Gateway (Gateway conformance profile) * Service (Mesh + conformance profile) \n This API may be extended in the future to + support additional kinds of parent resources. \n It is invalid to + reference an identical parent more than once. It is valid to reference + multiple distinct sections within the same parent resource, such + as two separate Listeners on the same Gateway or two separate ports + on the same Service. \n It is possible to separately reference multiple + distinct objects that may be collapsed by an implementation. For + example, some implementations may choose to merge compatible Gateway + Listeners together. If that is the case, the list of routes attached + to those resources should also be merged. \n Note that for ParentRefs + that cross namespace boundaries, there are specific rules. Cross-namespace + references are only valid if they are explicitly allowed by something + in the namespace they are referring to. For example, Gateway has + the AllowedRoutes field, and ReferenceGrant provides a generic way + to enable other kinds of cross-namespace reference. \n ParentRefs + from a Route to a Service in the same namespace are \"producer\" + routes, which apply default routing rules to inbound connections + from any namespace to the Service. \n ParentRefs from a Route to + a Service in a different namespace are \"consumer\" routes, and + these routing rules are only applied to outbound connections originating + from the same namespace as the Route, for which the intended destination + of the connections are a Service targeted as a ParentRef of the + Route." items: description: "ParentReference identifies an API object (usually a Gateway) that can be considered a parent of this resource (usually @@ -2085,31 +2088,34 @@ spec: Routes of this kind and namespace. For Services, that means the Service must either be in the same namespace for a \"producer\" route, or the mesh implementation must support and allow \"consumer\" - routes for the referenced Service. \n There are two kinds of parent - resources with \"Core\" support: \n * Gateway (Gateway conformance - profile) * Service (Mesh conformance profile) \n This API may be - extended in the future to support additional kinds of parent resources. - \n It is invalid to reference an identical parent more than once. - It is valid to reference multiple distinct sections within the same - parent resource, such as two separate Listeners on the same Gateway - or two separate ports on the same Service. \n It is possible to - separately reference multiple distinct objects that may be collapsed - by an implementation. For example, some implementations may choose - to merge compatible Gateway Listeners together. If that is the case, - the list of routes attached to those resources should also be merged. - \n Note that for ParentRefs that cross namespace boundaries, there - are specific rules. Cross-namespace references are only valid if - they are explicitly allowed by something in the namespace they are - referring to. For example, Gateway has the AllowedRoutes field, - and ReferenceGrant provides a generic way to enable other kinds - of cross-namespace reference. \n ParentRefs from a Route to a Service - in the same namespace are \"producer\" routes, which apply default - routing rules to inbound connections from any namespace to the Service. - \n ParentRefs from a Route to a Service in a different namespace - are \"consumer\" routes, and these routing rules are only applied - to outbound connections originating from the same namespace as the - Route, for which the intended destination of the connections are - a Service targeted as a ParentRef of the Route." + routes for the referenced Service. ReferenceGrant is not applicable + for governing ParentRefs to Services - it is not possible to create + a \"producer\" route for a Service in a different namespace from + the Route. \n There are two kinds of parent resources with \"Core\" + support: \n * Gateway (Gateway conformance profile) * Service (Mesh + conformance profile) \n This API may be extended in the future to + support additional kinds of parent resources. \n It is invalid to + reference an identical parent more than once. It is valid to reference + multiple distinct sections within the same parent resource, such + as two separate Listeners on the same Gateway or two separate ports + on the same Service. \n It is possible to separately reference multiple + distinct objects that may be collapsed by an implementation. For + example, some implementations may choose to merge compatible Gateway + Listeners together. If that is the case, the list of routes attached + to those resources should also be merged. \n Note that for ParentRefs + that cross namespace boundaries, there are specific rules. Cross-namespace + references are only valid if they are explicitly allowed by something + in the namespace they are referring to. For example, Gateway has + the AllowedRoutes field, and ReferenceGrant provides a generic way + to enable other kinds of cross-namespace reference. \n ParentRefs + from a Route to a Service in the same namespace are \"producer\" + routes, which apply default routing rules to inbound connections + from any namespace to the Service. \n ParentRefs from a Route to + a Service in a different namespace are \"consumer\" routes, and + these routing rules are only applied to outbound connections originating + from the same namespace as the Route, for which the intended destination + of the connections are a Service targeted as a ParentRef of the + Route." items: description: "ParentReference identifies an API object (usually a Gateway) that can be considered a parent of this resource (usually diff --git a/config/crd/standard/gateway.networking.k8s.io_referencegrants.yaml b/config/crd/standard/gateway.networking.k8s.io_referencegrants.yaml index 729f96b57e..91b75ecad4 100644 --- a/config/crd/standard/gateway.networking.k8s.io_referencegrants.yaml +++ b/config/crd/standard/gateway.networking.k8s.io_referencegrants.yaml @@ -35,13 +35,17 @@ spec: namespace as the policy. \n Each ReferenceGrant can be used to represent a unique trust relationship. Additional Reference Grants can be used to add to the set of trusted sources of inbound references for the namespace - they are defined within. \n All cross-namespace references in Gateway API - (with the exception of cross-namespace Gateway-route attachment) require - a ReferenceGrant. \n ReferenceGrant is a form of runtime verification allowing - users to assert which cross-namespace object references are permitted. Implementations - that support ReferenceGrant MUST NOT permit cross-namespace references which - have no grant, and MUST respond to the removal of a grant by revoking the - access that the grant allowed. \n Support: Core" + they are defined within. \n A ReferenceGrant is required for all cross-namespace + references in Gateway API (with the exception of cross-namespace Route-Gateway + attachment, which is governed by the AllowedRoutes configuration on the + Gateway, and cross-namespace Service ParentRefs on a \"consumer\" mesh Route, + which defines routing rules applicable only to workloads in the Route namespace). + ReferenceGrants allowing a reference from a Route to a Service are only + applicable to BackendRefs. \n ReferenceGrant is a form of runtime verification + allowing users to assert which cross-namespace object references are permitted. + Implementations that support ReferenceGrant MUST NOT permit cross-namespace + references which have no grant, and MUST respond to the removal of a grant + by revoking the access that the grant allowed. \n Support: Core" properties: apiVersion: description: 'APIVersion defines the versioned schema of this representation