From 4dc56ba6b3df4d0bfeadee1db3ae308d438db398 Mon Sep 17 00:00:00 2001 From: "dependabot[bot]" <49699333+dependabot[bot]@users.noreply.github.com> Date: Thu, 15 Aug 2024 21:14:59 +0000 Subject: [PATCH] Bump sigs.k8s.io/controller-tools from 0.15.0 to 0.16.1 (#2402) * Bump sigs.k8s.io/controller-tools from 0.15.0 to 0.16.1 Bumps [sigs.k8s.io/controller-tools](https://github.com/kubernetes-sigs/controller-tools) from 0.15.0 to 0.16.1. - [Release notes](https://github.com/kubernetes-sigs/controller-tools/releases) - [Changelog](https://github.com/kubernetes-sigs/controller-tools/blob/master/envtest-releases.yaml) - [Commits](https://github.com/kubernetes-sigs/controller-tools/compare/v0.15.0...v0.16.1) --- updated-dependencies: - dependency-name: sigs.k8s.io/controller-tools dependency-type: direct:production update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] * Update code generation --------- Signed-off-by: dependabot[bot] Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: Saylor Berman --- ...eway.nginx.org_clientsettingspolicies.yaml | 55 +------- .../gateway.nginx.org_nginxgateways.yaml | 21 +-- .../bases/gateway.nginx.org_nginxproxies.yaml | 2 +- ...teway.nginx.org_observabilitypolicies.yaml | 55 +------- deploy/crds.yaml | 133 ++---------------- go.mod | 4 +- go.sum | 8 +- 7 files changed, 32 insertions(+), 246 deletions(-) diff --git a/config/crd/bases/gateway.nginx.org_clientsettingspolicies.yaml b/config/crd/bases/gateway.nginx.org_clientsettingspolicies.yaml index 13b5cf910..956cd1239 100644 --- a/config/crd/bases/gateway.nginx.org_clientsettingspolicies.yaml +++ b/config/crd/bases/gateway.nginx.org_clientsettingspolicies.yaml @@ -3,7 +3,7 @@ apiVersion: apiextensions.k8s.io/v1 kind: CustomResourceDefinition metadata: annotations: - controller-gen.kubebuilder.io/version: v0.15.0 + controller-gen.kubebuilder.io/version: v0.16.1 labels: gateway.networking.k8s.io/policy: inherited name: clientsettingspolicies.gateway.nginx.org @@ -160,27 +160,22 @@ spec: the controller first sees the policy and SHOULD update the entry as appropriate when the relevant ancestor is modified. - Note that choosing the relevant ancestor is left to the Policy designers; an important part of Policy design is designing the right object level at which to namespace this status. - Note also that implementations MUST ONLY populate ancestor status for the Ancestor resources they are responsible for. Implementations MUST use the ControllerName field to uniquely identify the entries in this list that they are responsible for. - Note that to achieve this, the list of PolicyAncestorStatus structs MUST be treated as a map with a composite key, made up of the AncestorRef and ControllerName fields combined. - A maximum of 16 ancestors will be represented in this list. An empty list means the Policy is not relevant for any ancestors. - If this slice is full, implementations MUST NOT add further entries. Instead they MUST consider the policy unimplementable and signal that on any related resources such as the ancestor that would be referenced @@ -192,7 +187,6 @@ spec: PolicyAncestorStatus describes the status of a route with respect to an associated Ancestor. - Ancestors refer to objects that are either the Target of a policy or above it in terms of object hierarchy. For example, if a policy targets a Service, the Policy's Ancestors are, in order, the Service, the HTTPRoute, the Gateway, and @@ -201,28 +195,23 @@ spec: SHOULD use Gateway as the PolicyAncestorStatus object unless the designers have a _very_ good reason otherwise. - In the context of policy attachment, the Ancestor is used to distinguish which resource results in a distinct application of this policy. For example, if a policy targets a Service, it may have a distinct result per attached Gateway. - Policies targeting the same resource may have different effects depending on the ancestors of those resources. For example, different Gateways targeting the same Service may have different capabilities, especially if they have different underlying implementations. - For example, in BackendTLSPolicy, the Policy attaches to a Service that is used as a backend in a HTTPRoute that is itself attached to a Gateway. In this case, the relevant object for status is the Gateway, and that is the ancestor object referred to in this status. - Note that a parent is also an ancestor, so for objects where the parent is the relevant object for status, this struct SHOULD still be used. - This struct is intended to be used in a slice that's effectively a map, with a composite key made up of the AncestorRef and the ControllerName. properties: @@ -239,7 +228,6 @@ spec: To set the core API group (such as for a "Service" kind referent), Group must be explicitly set to "" (empty string). - Support: Core maxLength: 253 pattern: ^$|^[a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*$ @@ -249,14 +237,11 @@ spec: description: |- Kind is kind of the referent. - There are two kinds of parent resources with "Core" support: - * Gateway (Gateway conformance profile) * Service (Mesh conformance profile, ClusterIP Services only) - Support for other resources is Implementation-Specific. maxLength: 63 minLength: 1 @@ -266,7 +251,6 @@ spec: description: |- Name is the name of the referent. - Support: Core maxLength: 253 minLength: 1 @@ -276,20 +260,17 @@ spec: Namespace is the namespace of the referent. When unspecified, this refers to the local namespace of the Route. - Note that there are specific rules for ParentRefs which cross namespace boundaries. 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. - 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 originating from the same namespace as the Route, for which @@ -297,7 +278,6 @@ spec: ParentRef of the Route. - Support: Core maxLength: 63 minLength: 1 @@ -308,7 +288,6 @@ spec: Port is the network port this Route targets. It can be interpreted differently based on the type of parent resource. - When the parent resource is a Gateway, this targets all listeners listening on the specified port that also support this kind of Route(and select this Route). It's not recommended to set `Port` unless the @@ -317,19 +296,16 @@ spec: 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. - 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, @@ -338,7 +314,6 @@ spec: attached. If no Gateway listeners accept attachment from this Route, the Route MUST be considered detached from the Gateway. - Support: Extended format: int32 maximum: 65535 @@ -349,7 +324,6 @@ spec: SectionName is the name of a section within the target resource. In the following resources, SectionName is interpreted as the following: - * Gateway: Listener name. When both Port (experimental) and SectionName are specified, the name and port of the selected listener must match both specified values. @@ -357,12 +331,10 @@ spec: are specified, the name and port of the selected listener 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. - 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 @@ -372,7 +344,6 @@ spec: attached. If no Gateway listeners accept attachment from this Route, the Route MUST be considered detached from the Gateway. - Support: Core maxLength: 253 minLength: 1 @@ -385,18 +356,8 @@ spec: description: Conditions describes the status of the Policy with respect to the given Ancestor. items: - description: "Condition contains details for one aspect of - the current state of this API Resource.\n---\nThis struct - is intended for direct use as an array at the field path - .status.conditions. For example,\n\n\n\ttype FooStatus - struct{\n\t // Represents the observations of a foo's - current state.\n\t // Known .status.conditions.type are: - \"Available\", \"Progressing\", and \"Degraded\"\n\t // - +patchMergeKey=type\n\t // +patchStrategy=merge\n\t // - +listType=map\n\t // +listMapKey=type\n\t Conditions - []metav1.Condition `json:\"conditions,omitempty\" patchStrategy:\"merge\" - patchMergeKey:\"type\" protobuf:\"bytes,1,rep,name=conditions\"`\n\n\n\t - \ // other fields\n\t}" + description: Condition contains details for one aspect of + the current state of this API Resource. properties: lastTransitionTime: description: |- @@ -438,12 +399,7 @@ spec: - Unknown type: string type: - description: |- - type of condition in CamelCase or in foo.example.com/CamelCase. - --- - Many .condition.type values are consistent across resources like Available, but because arbitrary conditions can be - useful (see .node.status.conditions), the ability to deconflict is important. - The regex it matches is (dns1123SubdomainFmt/)?(qualifiedNameFmt) + description: type of condition in CamelCase or in foo.example.com/CamelCase. maxLength: 316 pattern: ^([a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*/)?(([A-Za-z0-9][-A-Za-z0-9_.]*)?[A-Za-z0-9])$ type: string @@ -466,15 +422,12 @@ spec: controller that wrote this status. This corresponds with the controllerName field on GatewayClass. - Example: "example.net/gateway-controller". - The format of this field is DOMAIN "/" PATH, where DOMAIN and PATH are valid Kubernetes names (https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names). - Controllers MUST populate this field when writing status. Controllers should ensure that entries to status populated with their ControllerName are cleaned up when they are no longer necessary. diff --git a/config/crd/bases/gateway.nginx.org_nginxgateways.yaml b/config/crd/bases/gateway.nginx.org_nginxgateways.yaml index 375f742f8..74acab5da 100644 --- a/config/crd/bases/gateway.nginx.org_nginxgateways.yaml +++ b/config/crd/bases/gateway.nginx.org_nginxgateways.yaml @@ -3,7 +3,7 @@ apiVersion: apiextensions.k8s.io/v1 kind: CustomResourceDefinition metadata: annotations: - controller-gen.kubebuilder.io/version: v0.15.0 + controller-gen.kubebuilder.io/version: v0.16.1 name: nginxgateways.gateway.nginx.org spec: group: gateway.nginx.org @@ -65,16 +65,8 @@ spec: properties: conditions: items: - description: "Condition contains details for one aspect of the current - state of this API Resource.\n---\nThis struct is intended for - direct use as an array at the field path .status.conditions. For - example,\n\n\n\ttype FooStatus struct{\n\t // Represents the - observations of a foo's current state.\n\t // Known .status.conditions.type - are: \"Available\", \"Progressing\", and \"Degraded\"\n\t // - +patchMergeKey=type\n\t // +patchStrategy=merge\n\t // +listType=map\n\t - \ // +listMapKey=type\n\t Conditions []metav1.Condition `json:\"conditions,omitempty\" - patchStrategy:\"merge\" patchMergeKey:\"type\" protobuf:\"bytes,1,rep,name=conditions\"`\n\n\n\t - \ // other fields\n\t}" + description: Condition contains details for one aspect of the current + state of this API Resource. properties: lastTransitionTime: description: |- @@ -115,12 +107,7 @@ spec: - Unknown type: string type: - description: |- - type of condition in CamelCase or in foo.example.com/CamelCase. - --- - Many .condition.type values are consistent across resources like Available, but because arbitrary conditions can be - useful (see .node.status.conditions), the ability to deconflict is important. - The regex it matches is (dns1123SubdomainFmt/)?(qualifiedNameFmt) + description: type of condition in CamelCase or in foo.example.com/CamelCase. maxLength: 316 pattern: ^([a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*/)?(([A-Za-z0-9][-A-Za-z0-9_.]*)?[A-Za-z0-9])$ type: string diff --git a/config/crd/bases/gateway.nginx.org_nginxproxies.yaml b/config/crd/bases/gateway.nginx.org_nginxproxies.yaml index 73acae5e8..e77fb194a 100644 --- a/config/crd/bases/gateway.nginx.org_nginxproxies.yaml +++ b/config/crd/bases/gateway.nginx.org_nginxproxies.yaml @@ -3,7 +3,7 @@ apiVersion: apiextensions.k8s.io/v1 kind: CustomResourceDefinition metadata: annotations: - controller-gen.kubebuilder.io/version: v0.15.0 + controller-gen.kubebuilder.io/version: v0.16.1 name: nginxproxies.gateway.nginx.org spec: group: gateway.nginx.org diff --git a/config/crd/bases/gateway.nginx.org_observabilitypolicies.yaml b/config/crd/bases/gateway.nginx.org_observabilitypolicies.yaml index 74de2c640..3647b1145 100644 --- a/config/crd/bases/gateway.nginx.org_observabilitypolicies.yaml +++ b/config/crd/bases/gateway.nginx.org_observabilitypolicies.yaml @@ -3,7 +3,7 @@ apiVersion: apiextensions.k8s.io/v1 kind: CustomResourceDefinition metadata: annotations: - controller-gen.kubebuilder.io/version: v0.15.0 + controller-gen.kubebuilder.io/version: v0.16.1 labels: gateway.networking.k8s.io/policy: direct name: observabilitypolicies.gateway.nginx.org @@ -182,27 +182,22 @@ spec: the controller first sees the policy and SHOULD update the entry as appropriate when the relevant ancestor is modified. - Note that choosing the relevant ancestor is left to the Policy designers; an important part of Policy design is designing the right object level at which to namespace this status. - Note also that implementations MUST ONLY populate ancestor status for the Ancestor resources they are responsible for. Implementations MUST use the ControllerName field to uniquely identify the entries in this list that they are responsible for. - Note that to achieve this, the list of PolicyAncestorStatus structs MUST be treated as a map with a composite key, made up of the AncestorRef and ControllerName fields combined. - A maximum of 16 ancestors will be represented in this list. An empty list means the Policy is not relevant for any ancestors. - If this slice is full, implementations MUST NOT add further entries. Instead they MUST consider the policy unimplementable and signal that on any related resources such as the ancestor that would be referenced @@ -214,7 +209,6 @@ spec: PolicyAncestorStatus describes the status of a route with respect to an associated Ancestor. - Ancestors refer to objects that are either the Target of a policy or above it in terms of object hierarchy. For example, if a policy targets a Service, the Policy's Ancestors are, in order, the Service, the HTTPRoute, the Gateway, and @@ -223,28 +217,23 @@ spec: SHOULD use Gateway as the PolicyAncestorStatus object unless the designers have a _very_ good reason otherwise. - In the context of policy attachment, the Ancestor is used to distinguish which resource results in a distinct application of this policy. For example, if a policy targets a Service, it may have a distinct result per attached Gateway. - Policies targeting the same resource may have different effects depending on the ancestors of those resources. For example, different Gateways targeting the same Service may have different capabilities, especially if they have different underlying implementations. - For example, in BackendTLSPolicy, the Policy attaches to a Service that is used as a backend in a HTTPRoute that is itself attached to a Gateway. In this case, the relevant object for status is the Gateway, and that is the ancestor object referred to in this status. - Note that a parent is also an ancestor, so for objects where the parent is the relevant object for status, this struct SHOULD still be used. - This struct is intended to be used in a slice that's effectively a map, with a composite key made up of the AncestorRef and the ControllerName. properties: @@ -261,7 +250,6 @@ spec: To set the core API group (such as for a "Service" kind referent), Group must be explicitly set to "" (empty string). - Support: Core maxLength: 253 pattern: ^$|^[a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*$ @@ -271,14 +259,11 @@ spec: description: |- Kind is kind of the referent. - There are two kinds of parent resources with "Core" support: - * Gateway (Gateway conformance profile) * Service (Mesh conformance profile, ClusterIP Services only) - Support for other resources is Implementation-Specific. maxLength: 63 minLength: 1 @@ -288,7 +273,6 @@ spec: description: |- Name is the name of the referent. - Support: Core maxLength: 253 minLength: 1 @@ -298,20 +282,17 @@ spec: Namespace is the namespace of the referent. When unspecified, this refers to the local namespace of the Route. - Note that there are specific rules for ParentRefs which cross namespace boundaries. 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. - 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 originating from the same namespace as the Route, for which @@ -319,7 +300,6 @@ spec: ParentRef of the Route. - Support: Core maxLength: 63 minLength: 1 @@ -330,7 +310,6 @@ spec: Port is the network port this Route targets. It can be interpreted differently based on the type of parent resource. - When the parent resource is a Gateway, this targets all listeners listening on the specified port that also support this kind of Route(and select this Route). It's not recommended to set `Port` unless the @@ -339,19 +318,16 @@ spec: 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. - 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, @@ -360,7 +336,6 @@ spec: attached. If no Gateway listeners accept attachment from this Route, the Route MUST be considered detached from the Gateway. - Support: Extended format: int32 maximum: 65535 @@ -371,7 +346,6 @@ spec: SectionName is the name of a section within the target resource. In the following resources, SectionName is interpreted as the following: - * Gateway: Listener name. When both Port (experimental) and SectionName are specified, the name and port of the selected listener must match both specified values. @@ -379,12 +353,10 @@ spec: are specified, the name and port of the selected listener 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. - 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 @@ -394,7 +366,6 @@ spec: attached. If no Gateway listeners accept attachment from this Route, the Route MUST be considered detached from the Gateway. - Support: Core maxLength: 253 minLength: 1 @@ -407,18 +378,8 @@ spec: description: Conditions describes the status of the Policy with respect to the given Ancestor. items: - description: "Condition contains details for one aspect of - the current state of this API Resource.\n---\nThis struct - is intended for direct use as an array at the field path - .status.conditions. For example,\n\n\n\ttype FooStatus - struct{\n\t // Represents the observations of a foo's - current state.\n\t // Known .status.conditions.type are: - \"Available\", \"Progressing\", and \"Degraded\"\n\t // - +patchMergeKey=type\n\t // +patchStrategy=merge\n\t // - +listType=map\n\t // +listMapKey=type\n\t Conditions - []metav1.Condition `json:\"conditions,omitempty\" patchStrategy:\"merge\" - patchMergeKey:\"type\" protobuf:\"bytes,1,rep,name=conditions\"`\n\n\n\t - \ // other fields\n\t}" + description: Condition contains details for one aspect of + the current state of this API Resource. properties: lastTransitionTime: description: |- @@ -460,12 +421,7 @@ spec: - Unknown type: string type: - description: |- - type of condition in CamelCase or in foo.example.com/CamelCase. - --- - Many .condition.type values are consistent across resources like Available, but because arbitrary conditions can be - useful (see .node.status.conditions), the ability to deconflict is important. - The regex it matches is (dns1123SubdomainFmt/)?(qualifiedNameFmt) + description: type of condition in CamelCase or in foo.example.com/CamelCase. maxLength: 316 pattern: ^([a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*/)?(([A-Za-z0-9][-A-Za-z0-9_.]*)?[A-Za-z0-9])$ type: string @@ -488,15 +444,12 @@ spec: controller that wrote this status. This corresponds with the controllerName field on GatewayClass. - Example: "example.net/gateway-controller". - The format of this field is DOMAIN "/" PATH, where DOMAIN and PATH are valid Kubernetes names (https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names). - Controllers MUST populate this field when writing status. Controllers should ensure that entries to status populated with their ControllerName are cleaned up when they are no longer necessary. diff --git a/deploy/crds.yaml b/deploy/crds.yaml index 547c91274..435e53ef0 100644 --- a/deploy/crds.yaml +++ b/deploy/crds.yaml @@ -2,7 +2,7 @@ apiVersion: apiextensions.k8s.io/v1 kind: CustomResourceDefinition metadata: annotations: - controller-gen.kubebuilder.io/version: v0.15.0 + controller-gen.kubebuilder.io/version: v0.16.1 labels: gateway.networking.k8s.io/policy: inherited name: clientsettingspolicies.gateway.nginx.org @@ -159,27 +159,22 @@ spec: the controller first sees the policy and SHOULD update the entry as appropriate when the relevant ancestor is modified. - Note that choosing the relevant ancestor is left to the Policy designers; an important part of Policy design is designing the right object level at which to namespace this status. - Note also that implementations MUST ONLY populate ancestor status for the Ancestor resources they are responsible for. Implementations MUST use the ControllerName field to uniquely identify the entries in this list that they are responsible for. - Note that to achieve this, the list of PolicyAncestorStatus structs MUST be treated as a map with a composite key, made up of the AncestorRef and ControllerName fields combined. - A maximum of 16 ancestors will be represented in this list. An empty list means the Policy is not relevant for any ancestors. - If this slice is full, implementations MUST NOT add further entries. Instead they MUST consider the policy unimplementable and signal that on any related resources such as the ancestor that would be referenced @@ -191,7 +186,6 @@ spec: PolicyAncestorStatus describes the status of a route with respect to an associated Ancestor. - Ancestors refer to objects that are either the Target of a policy or above it in terms of object hierarchy. For example, if a policy targets a Service, the Policy's Ancestors are, in order, the Service, the HTTPRoute, the Gateway, and @@ -200,28 +194,23 @@ spec: SHOULD use Gateway as the PolicyAncestorStatus object unless the designers have a _very_ good reason otherwise. - In the context of policy attachment, the Ancestor is used to distinguish which resource results in a distinct application of this policy. For example, if a policy targets a Service, it may have a distinct result per attached Gateway. - Policies targeting the same resource may have different effects depending on the ancestors of those resources. For example, different Gateways targeting the same Service may have different capabilities, especially if they have different underlying implementations. - For example, in BackendTLSPolicy, the Policy attaches to a Service that is used as a backend in a HTTPRoute that is itself attached to a Gateway. In this case, the relevant object for status is the Gateway, and that is the ancestor object referred to in this status. - Note that a parent is also an ancestor, so for objects where the parent is the relevant object for status, this struct SHOULD still be used. - This struct is intended to be used in a slice that's effectively a map, with a composite key made up of the AncestorRef and the ControllerName. properties: @@ -238,7 +227,6 @@ spec: To set the core API group (such as for a "Service" kind referent), Group must be explicitly set to "" (empty string). - Support: Core maxLength: 253 pattern: ^$|^[a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*$ @@ -248,14 +236,11 @@ spec: description: |- Kind is kind of the referent. - There are two kinds of parent resources with "Core" support: - * Gateway (Gateway conformance profile) * Service (Mesh conformance profile, ClusterIP Services only) - Support for other resources is Implementation-Specific. maxLength: 63 minLength: 1 @@ -265,7 +250,6 @@ spec: description: |- Name is the name of the referent. - Support: Core maxLength: 253 minLength: 1 @@ -275,20 +259,17 @@ spec: Namespace is the namespace of the referent. When unspecified, this refers to the local namespace of the Route. - Note that there are specific rules for ParentRefs which cross namespace boundaries. 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. - 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 originating from the same namespace as the Route, for which @@ -296,7 +277,6 @@ spec: ParentRef of the Route. - Support: Core maxLength: 63 minLength: 1 @@ -307,7 +287,6 @@ spec: Port is the network port this Route targets. It can be interpreted differently based on the type of parent resource. - When the parent resource is a Gateway, this targets all listeners listening on the specified port that also support this kind of Route(and select this Route). It's not recommended to set `Port` unless the @@ -316,19 +295,16 @@ spec: 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. - 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, @@ -337,7 +313,6 @@ spec: attached. If no Gateway listeners accept attachment from this Route, the Route MUST be considered detached from the Gateway. - Support: Extended format: int32 maximum: 65535 @@ -348,7 +323,6 @@ spec: SectionName is the name of a section within the target resource. In the following resources, SectionName is interpreted as the following: - * Gateway: Listener name. When both Port (experimental) and SectionName are specified, the name and port of the selected listener must match both specified values. @@ -356,12 +330,10 @@ spec: are specified, the name and port of the selected listener 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. - 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 @@ -371,7 +343,6 @@ spec: attached. If no Gateway listeners accept attachment from this Route, the Route MUST be considered detached from the Gateway. - Support: Core maxLength: 253 minLength: 1 @@ -384,18 +355,8 @@ spec: description: Conditions describes the status of the Policy with respect to the given Ancestor. items: - description: "Condition contains details for one aspect of - the current state of this API Resource.\n---\nThis struct - is intended for direct use as an array at the field path - .status.conditions. For example,\n\n\n\ttype FooStatus - struct{\n\t // Represents the observations of a foo's - current state.\n\t // Known .status.conditions.type are: - \"Available\", \"Progressing\", and \"Degraded\"\n\t // - +patchMergeKey=type\n\t // +patchStrategy=merge\n\t // - +listType=map\n\t // +listMapKey=type\n\t Conditions - []metav1.Condition `json:\"conditions,omitempty\" patchStrategy:\"merge\" - patchMergeKey:\"type\" protobuf:\"bytes,1,rep,name=conditions\"`\n\n\n\t - \ // other fields\n\t}" + description: Condition contains details for one aspect of + the current state of this API Resource. properties: lastTransitionTime: description: |- @@ -437,12 +398,7 @@ spec: - Unknown type: string type: - description: |- - type of condition in CamelCase or in foo.example.com/CamelCase. - --- - Many .condition.type values are consistent across resources like Available, but because arbitrary conditions can be - useful (see .node.status.conditions), the ability to deconflict is important. - The regex it matches is (dns1123SubdomainFmt/)?(qualifiedNameFmt) + description: type of condition in CamelCase or in foo.example.com/CamelCase. maxLength: 316 pattern: ^([a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*/)?(([A-Za-z0-9][-A-Za-z0-9_.]*)?[A-Za-z0-9])$ type: string @@ -465,15 +421,12 @@ spec: controller that wrote this status. This corresponds with the controllerName field on GatewayClass. - Example: "example.net/gateway-controller". - The format of this field is DOMAIN "/" PATH, where DOMAIN and PATH are valid Kubernetes names (https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names). - Controllers MUST populate this field when writing status. Controllers should ensure that entries to status populated with their ControllerName are cleaned up when they are no longer necessary. @@ -502,7 +455,7 @@ apiVersion: apiextensions.k8s.io/v1 kind: CustomResourceDefinition metadata: annotations: - controller-gen.kubebuilder.io/version: v0.15.0 + controller-gen.kubebuilder.io/version: v0.16.1 name: nginxgateways.gateway.nginx.org spec: group: gateway.nginx.org @@ -564,16 +517,8 @@ spec: properties: conditions: items: - description: "Condition contains details for one aspect of the current - state of this API Resource.\n---\nThis struct is intended for - direct use as an array at the field path .status.conditions. For - example,\n\n\n\ttype FooStatus struct{\n\t // Represents the - observations of a foo's current state.\n\t // Known .status.conditions.type - are: \"Available\", \"Progressing\", and \"Degraded\"\n\t // - +patchMergeKey=type\n\t // +patchStrategy=merge\n\t // +listType=map\n\t - \ // +listMapKey=type\n\t Conditions []metav1.Condition `json:\"conditions,omitempty\" - patchStrategy:\"merge\" patchMergeKey:\"type\" protobuf:\"bytes,1,rep,name=conditions\"`\n\n\n\t - \ // other fields\n\t}" + description: Condition contains details for one aspect of the current + state of this API Resource. properties: lastTransitionTime: description: |- @@ -614,12 +559,7 @@ spec: - Unknown type: string type: - description: |- - type of condition in CamelCase or in foo.example.com/CamelCase. - --- - Many .condition.type values are consistent across resources like Available, but because arbitrary conditions can be - useful (see .node.status.conditions), the ability to deconflict is important. - The regex it matches is (dns1123SubdomainFmt/)?(qualifiedNameFmt) + description: type of condition in CamelCase or in foo.example.com/CamelCase. maxLength: 316 pattern: ^([a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*/)?(([A-Za-z0-9][-A-Za-z0-9_.]*)?[A-Za-z0-9])$ type: string @@ -648,7 +588,7 @@ apiVersion: apiextensions.k8s.io/v1 kind: CustomResourceDefinition metadata: annotations: - controller-gen.kubebuilder.io/version: v0.15.0 + controller-gen.kubebuilder.io/version: v0.16.1 name: nginxproxies.gateway.nginx.org spec: group: gateway.nginx.org @@ -795,7 +735,7 @@ apiVersion: apiextensions.k8s.io/v1 kind: CustomResourceDefinition metadata: annotations: - controller-gen.kubebuilder.io/version: v0.15.0 + controller-gen.kubebuilder.io/version: v0.16.1 labels: gateway.networking.k8s.io/policy: direct name: observabilitypolicies.gateway.nginx.org @@ -974,27 +914,22 @@ spec: the controller first sees the policy and SHOULD update the entry as appropriate when the relevant ancestor is modified. - Note that choosing the relevant ancestor is left to the Policy designers; an important part of Policy design is designing the right object level at which to namespace this status. - Note also that implementations MUST ONLY populate ancestor status for the Ancestor resources they are responsible for. Implementations MUST use the ControllerName field to uniquely identify the entries in this list that they are responsible for. - Note that to achieve this, the list of PolicyAncestorStatus structs MUST be treated as a map with a composite key, made up of the AncestorRef and ControllerName fields combined. - A maximum of 16 ancestors will be represented in this list. An empty list means the Policy is not relevant for any ancestors. - If this slice is full, implementations MUST NOT add further entries. Instead they MUST consider the policy unimplementable and signal that on any related resources such as the ancestor that would be referenced @@ -1006,7 +941,6 @@ spec: PolicyAncestorStatus describes the status of a route with respect to an associated Ancestor. - Ancestors refer to objects that are either the Target of a policy or above it in terms of object hierarchy. For example, if a policy targets a Service, the Policy's Ancestors are, in order, the Service, the HTTPRoute, the Gateway, and @@ -1015,28 +949,23 @@ spec: SHOULD use Gateway as the PolicyAncestorStatus object unless the designers have a _very_ good reason otherwise. - In the context of policy attachment, the Ancestor is used to distinguish which resource results in a distinct application of this policy. For example, if a policy targets a Service, it may have a distinct result per attached Gateway. - Policies targeting the same resource may have different effects depending on the ancestors of those resources. For example, different Gateways targeting the same Service may have different capabilities, especially if they have different underlying implementations. - For example, in BackendTLSPolicy, the Policy attaches to a Service that is used as a backend in a HTTPRoute that is itself attached to a Gateway. In this case, the relevant object for status is the Gateway, and that is the ancestor object referred to in this status. - Note that a parent is also an ancestor, so for objects where the parent is the relevant object for status, this struct SHOULD still be used. - This struct is intended to be used in a slice that's effectively a map, with a composite key made up of the AncestorRef and the ControllerName. properties: @@ -1053,7 +982,6 @@ spec: To set the core API group (such as for a "Service" kind referent), Group must be explicitly set to "" (empty string). - Support: Core maxLength: 253 pattern: ^$|^[a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*$ @@ -1063,14 +991,11 @@ spec: description: |- Kind is kind of the referent. - There are two kinds of parent resources with "Core" support: - * Gateway (Gateway conformance profile) * Service (Mesh conformance profile, ClusterIP Services only) - Support for other resources is Implementation-Specific. maxLength: 63 minLength: 1 @@ -1080,7 +1005,6 @@ spec: description: |- Name is the name of the referent. - Support: Core maxLength: 253 minLength: 1 @@ -1090,20 +1014,17 @@ spec: Namespace is the namespace of the referent. When unspecified, this refers to the local namespace of the Route. - Note that there are specific rules for ParentRefs which cross namespace boundaries. 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. - 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 originating from the same namespace as the Route, for which @@ -1111,7 +1032,6 @@ spec: ParentRef of the Route. - Support: Core maxLength: 63 minLength: 1 @@ -1122,7 +1042,6 @@ spec: Port is the network port this Route targets. It can be interpreted differently based on the type of parent resource. - When the parent resource is a Gateway, this targets all listeners listening on the specified port that also support this kind of Route(and select this Route). It's not recommended to set `Port` unless the @@ -1131,19 +1050,16 @@ spec: 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. - 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, @@ -1152,7 +1068,6 @@ spec: attached. If no Gateway listeners accept attachment from this Route, the Route MUST be considered detached from the Gateway. - Support: Extended format: int32 maximum: 65535 @@ -1163,7 +1078,6 @@ spec: SectionName is the name of a section within the target resource. In the following resources, SectionName is interpreted as the following: - * Gateway: Listener name. When both Port (experimental) and SectionName are specified, the name and port of the selected listener must match both specified values. @@ -1171,12 +1085,10 @@ spec: are specified, the name and port of the selected listener 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. - 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 @@ -1186,7 +1098,6 @@ spec: attached. If no Gateway listeners accept attachment from this Route, the Route MUST be considered detached from the Gateway. - Support: Core maxLength: 253 minLength: 1 @@ -1199,18 +1110,8 @@ spec: description: Conditions describes the status of the Policy with respect to the given Ancestor. items: - description: "Condition contains details for one aspect of - the current state of this API Resource.\n---\nThis struct - is intended for direct use as an array at the field path - .status.conditions. For example,\n\n\n\ttype FooStatus - struct{\n\t // Represents the observations of a foo's - current state.\n\t // Known .status.conditions.type are: - \"Available\", \"Progressing\", and \"Degraded\"\n\t // - +patchMergeKey=type\n\t // +patchStrategy=merge\n\t // - +listType=map\n\t // +listMapKey=type\n\t Conditions - []metav1.Condition `json:\"conditions,omitempty\" patchStrategy:\"merge\" - patchMergeKey:\"type\" protobuf:\"bytes,1,rep,name=conditions\"`\n\n\n\t - \ // other fields\n\t}" + description: Condition contains details for one aspect of + the current state of this API Resource. properties: lastTransitionTime: description: |- @@ -1252,12 +1153,7 @@ spec: - Unknown type: string type: - description: |- - type of condition in CamelCase or in foo.example.com/CamelCase. - --- - Many .condition.type values are consistent across resources like Available, but because arbitrary conditions can be - useful (see .node.status.conditions), the ability to deconflict is important. - The regex it matches is (dns1123SubdomainFmt/)?(qualifiedNameFmt) + description: type of condition in CamelCase or in foo.example.com/CamelCase. maxLength: 316 pattern: ^([a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*/)?(([A-Za-z0-9][-A-Za-z0-9_.]*)?[A-Za-z0-9])$ type: string @@ -1280,15 +1176,12 @@ spec: controller that wrote this status. This corresponds with the controllerName field on GatewayClass. - Example: "example.net/gateway-controller". - The format of this field is DOMAIN "/" PATH, where DOMAIN and PATH are valid Kubernetes names (https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names). - Controllers MUST populate this field when writing status. Controllers should ensure that entries to status populated with their ControllerName are cleaned up when they are no longer necessary. diff --git a/go.mod b/go.mod index 278b21053..852a55b6a 100644 --- a/go.mod +++ b/go.mod @@ -25,7 +25,7 @@ require ( k8s.io/apimachinery v0.31.0 k8s.io/client-go v0.31.0 sigs.k8s.io/controller-runtime v0.19.0 - sigs.k8s.io/controller-tools v0.15.0 + sigs.k8s.io/controller-tools v0.16.1 sigs.k8s.io/gateway-api v1.1.0 ) @@ -36,7 +36,7 @@ require ( github.com/davecgh/go-spew v1.1.2-0.20180830191138-d8f796af33cc // indirect github.com/emicklei/go-restful/v3 v3.12.0 // indirect github.com/evanphx/json-patch/v5 v5.9.0 // indirect - github.com/fatih/color v1.16.0 // indirect + github.com/fatih/color v1.17.0 // indirect github.com/fsnotify/fsnotify v1.7.0 // indirect github.com/fxamacker/cbor/v2 v2.7.0 // indirect github.com/go-logfmt/logfmt v0.5.1 // indirect diff --git a/go.sum b/go.sum index 300a5e78a..ef358200e 100644 --- a/go.sum +++ b/go.sum @@ -17,8 +17,8 @@ github.com/evanphx/json-patch v5.7.0+incompatible h1:vgGkfT/9f8zE6tvSCe74nfpAVDQ github.com/evanphx/json-patch v5.7.0+incompatible/go.mod h1:50XU6AFN0ol/bzJsmQLiYLvXMP4fmwYFNcr97nuDLSk= github.com/evanphx/json-patch/v5 v5.9.0 h1:kcBlZQbplgElYIlo/n1hJbls2z/1awpXxpRi0/FOJfg= github.com/evanphx/json-patch/v5 v5.9.0/go.mod h1:VNkHZ/282BpEyt/tObQO8s5CMPmYYq14uClGH4abBuQ= -github.com/fatih/color v1.16.0 h1:zmkK9Ngbjj+K0yRhTVONQh1p/HknKYSlNT+vZCzyokM= -github.com/fatih/color v1.16.0/go.mod h1:fL2Sau1YI5c0pdGEVCbKQbLXB6edEj1ZgiY4NijnWvE= +github.com/fatih/color v1.17.0 h1:GlRw1BRJxkpqUCBKzKOw098ed57fEsKeNjpTe3cSjK4= +github.com/fatih/color v1.17.0/go.mod h1:YZ7TlrGPkiz6ku9fK3TLD/pl3CpsiFyu8N92HLgmosI= github.com/fsnotify/fsnotify v1.7.0 h1:8JEhPFa5W2WU7YfeZzPNqzMP6Lwt7L2715Ggo0nosvA= github.com/fsnotify/fsnotify v1.7.0/go.mod h1:40Bi/Hjc2AVfZrqy+aj+yEI+/bRxZnMJyTJwOpGvigM= github.com/fxamacker/cbor/v2 v2.7.0 h1:iM5WgngdRBanHcxugY4JySA0nk1wZorNOpTgCMedv5E= @@ -273,8 +273,8 @@ k8s.io/utils v0.0.0-20240711033017-18e509b52bc8 h1:pUdcCO1Lk/tbT5ztQWOBi5HBgbBP1 k8s.io/utils v0.0.0-20240711033017-18e509b52bc8/go.mod h1:OLgZIPagt7ERELqWJFomSt595RzquPNLL48iOWgYOg0= sigs.k8s.io/controller-runtime v0.19.0 h1:nWVM7aq+Il2ABxwiCizrVDSlmDcshi9llbaFbC0ji/Q= sigs.k8s.io/controller-runtime v0.19.0/go.mod h1:iRmWllt8IlaLjvTTDLhRBXIEtkCK6hwVBJJsYS9Ajf4= -sigs.k8s.io/controller-tools v0.15.0 h1:4dxdABXGDhIa68Fiwaif0vcu32xfwmgQ+w8p+5CxoAI= -sigs.k8s.io/controller-tools v0.15.0/go.mod h1:8zUSS2T8Hx0APCNRhJWbS3CAQEbIxLa07khzh7pZmXM= +sigs.k8s.io/controller-tools v0.16.1 h1:gvIsZm+2aimFDIBiDKumR7EBkc+oLxljoUVfRbDI6RI= +sigs.k8s.io/controller-tools v0.16.1/go.mod h1:0I0xqjR65YTfoO12iR+mZR6s6UAVcUARgXRlsu0ljB0= sigs.k8s.io/gateway-api v1.1.0 h1:DsLDXCi6jR+Xz8/xd0Z1PYl2Pn0TyaFMOPPZIj4inDM= sigs.k8s.io/gateway-api v1.1.0/go.mod h1:ZH4lHrL2sDi0FHZ9jjneb8kKnGzFWyrTya35sWUTrRs= sigs.k8s.io/json v0.0.0-20221116044647-bc3834ca7abd h1:EDPBXCAspyGV4jQlpZSudPeMmr1bNJefnuqLsRAsHZo=