diff --git a/apis/v1/backendtlspolicy_types.go b/apis/v1/backendtlspolicy_types.go index 5a755eb1ba..674dca7bd8 100644 --- a/apis/v1/backendtlspolicy_types.go +++ b/apis/v1/backendtlspolicy_types.go @@ -88,6 +88,12 @@ type BackendTLSPolicySpec struct { // implementation MUST ensure the `Accepted` Condition is set to // `status: False`, with Reason `Conflicted`. // + // Implementations SHOULD NOT support more than one targetRef at this + // time. Although the API technically allows for this, the current guidance + // for conflict resolution and status handling is lacking. Until that can be + // clarified in a future release, the safest approach is to support a single + // targetRef. + // // Support: Extended for Kubernetes Service // // Support: Implementation-specific for any other resource diff --git a/apisx/v1alpha1/xbackendtrafficpolicy_types.go b/apisx/v1alpha1/xbackendtrafficpolicy_types.go index 55359c9148..3ac5163693 100644 --- a/apisx/v1alpha1/xbackendtrafficpolicy_types.go +++ b/apisx/v1alpha1/xbackendtrafficpolicy_types.go @@ -69,10 +69,6 @@ type BackendTrafficPolicySpec struct { // Currently, a TargetRef can not be scoped to a specific port on a // Service. // - // Because of concerns over recording status correctly in some edge cases, - // currently, Core support is only given to one (1) TargetRef. More than - // one TargetRef is Implementation Specific. - // // +listType=map // +listMapKey=group // +listMapKey=kind diff --git a/config/crd/experimental/gateway.networking.k8s.io_backendtlspolicies.yaml b/config/crd/experimental/gateway.networking.k8s.io_backendtlspolicies.yaml index d97be36c40..7f59226386 100644 --- a/config/crd/experimental/gateway.networking.k8s.io_backendtlspolicies.yaml +++ b/config/crd/experimental/gateway.networking.k8s.io_backendtlspolicies.yaml @@ -108,6 +108,12 @@ spec: implementation MUST ensure the `Accepted` Condition is set to `status: False`, with Reason `Conflicted`. + Implementations SHOULD NOT support more than one targetRef at this + time. Although the API technically allows for this, the current guidance + for conflict resolution and status handling is lacking. Until that can be + clarified in a future release, the safest approach is to support a single + targetRef. + Support: Extended for Kubernetes Service Support: Implementation-specific for any other resource @@ -771,6 +777,12 @@ spec: implementation MUST ensure the `Accepted` Condition is set to `status: False`, with Reason `Conflicted`. + Implementations SHOULD NOT support more than one targetRef at this + time. Although the API technically allows for this, the current guidance + for conflict resolution and status handling is lacking. Until that can be + clarified in a future release, the safest approach is to support a single + targetRef. + Support: Extended for Kubernetes Service Support: Implementation-specific for any other resource diff --git a/config/crd/experimental/gateway.networking.x-k8s.io_xbackendtrafficpolicies.yaml b/config/crd/experimental/gateway.networking.x-k8s.io_xbackendtrafficpolicies.yaml index 367f8d7a55..49f0474d38 100644 --- a/config/crd/experimental/gateway.networking.x-k8s.io_xbackendtrafficpolicies.yaml +++ b/config/crd/experimental/gateway.networking.x-k8s.io_xbackendtrafficpolicies.yaml @@ -253,10 +253,6 @@ spec: Currently, a TargetRef can not be scoped to a specific port on a Service. - - Because of concerns over recording status correctly in some edge cases, - currently, Core support is only given to one (1) TargetRef. More than - one TargetRef is Implementation Specific. items: description: |- LocalPolicyTargetReference identifies an API object to apply a direct or diff --git a/config/crd/standard/gateway.networking.k8s.io_backendtlspolicies.yaml b/config/crd/standard/gateway.networking.k8s.io_backendtlspolicies.yaml index aacbd1c030..8e70d695c4 100644 --- a/config/crd/standard/gateway.networking.k8s.io_backendtlspolicies.yaml +++ b/config/crd/standard/gateway.networking.k8s.io_backendtlspolicies.yaml @@ -108,6 +108,12 @@ spec: implementation MUST ensure the `Accepted` Condition is set to `status: False`, with Reason `Conflicted`. + Implementations SHOULD NOT support more than one targetRef at this + time. Although the API technically allows for this, the current guidance + for conflict resolution and status handling is lacking. Until that can be + clarified in a future release, the safest approach is to support a single + targetRef. + Support: Extended for Kubernetes Service Support: Implementation-specific for any other resource @@ -753,6 +759,12 @@ spec: implementation MUST ensure the `Accepted` Condition is set to `status: False`, with Reason `Conflicted`. + Implementations SHOULD NOT support more than one targetRef at this + time. Although the API technically allows for this, the current guidance + for conflict resolution and status handling is lacking. Until that can be + clarified in a future release, the safest approach is to support a single + targetRef. + Support: Extended for Kubernetes Service Support: Implementation-specific for any other resource diff --git a/pkg/generated/openapi/zz_generated.openapi.go b/pkg/generated/openapi/zz_generated.openapi.go index 127f76b1c2..79b179a616 100644 --- a/pkg/generated/openapi/zz_generated.openapi.go +++ b/pkg/generated/openapi/zz_generated.openapi.go @@ -3139,7 +3139,7 @@ func schema_sigsk8sio_gateway_api_apis_v1_BackendTLSPolicySpec(ref common.Refere }, }, SchemaProps: spec.SchemaProps{ - Description: "TargetRefs identifies an API object to apply the policy to. Only Services have Extended support. Implementations MAY support additional objects, with Implementation Specific support. Note that this config applies to the entire referenced resource by default, but this default may change in the future to provide a more granular application of the policy.\n\nTargetRefs must be _distinct_. This means either that:\n\n* They select different targets. If this is the case, then targetRef\n entries are distinct. In terms of fields, this means that the\n multi-part key defined by `group`, `kind`, and `name` must\n be unique across all targetRef entries in the BackendTLSPolicy.\n* They select different sectionNames in the same target.\n\nWhen more than one BackendTLSPolicy selects the same target and sectionName, implementations MUST determine precedence using the following criteria, continuing on ties:\n\n* The older policy by creation timestamp takes precedence. For\n example, a policy with a creation timestamp of \"2021-07-15\n 01:02:03\" MUST be given precedence over a policy with a\n creation timestamp of \"2021-07-15 01:02:04\".\n* The policy appearing first in alphabetical order by {name}.\n For example, a policy named `bar` is given precedence over a\n policy named `baz`.\n\nFor any BackendTLSPolicy that does not take precedence, the implementation MUST ensure the `Accepted` Condition is set to `status: False`, with Reason `Conflicted`.\n\nSupport: Extended for Kubernetes Service\n\nSupport: Implementation-specific for any other resource", + Description: "TargetRefs identifies an API object to apply the policy to. Only Services have Extended support. Implementations MAY support additional objects, with Implementation Specific support. Note that this config applies to the entire referenced resource by default, but this default may change in the future to provide a more granular application of the policy.\n\nTargetRefs must be _distinct_. This means either that:\n\n* They select different targets. If this is the case, then targetRef\n entries are distinct. In terms of fields, this means that the\n multi-part key defined by `group`, `kind`, and `name` must\n be unique across all targetRef entries in the BackendTLSPolicy.\n* They select different sectionNames in the same target.\n\nWhen more than one BackendTLSPolicy selects the same target and sectionName, implementations MUST determine precedence using the following criteria, continuing on ties:\n\n* The older policy by creation timestamp takes precedence. For\n example, a policy with a creation timestamp of \"2021-07-15\n 01:02:03\" MUST be given precedence over a policy with a\n creation timestamp of \"2021-07-15 01:02:04\".\n* The policy appearing first in alphabetical order by {name}.\n For example, a policy named `bar` is given precedence over a\n policy named `baz`.\n\nFor any BackendTLSPolicy that does not take precedence, the implementation MUST ensure the `Accepted` Condition is set to `status: False`, with Reason `Conflicted`.\n\nImplementations SHOULD NOT support more than one targetRef at this time. Although the API technically allows for this, the current guidance for conflict resolution and status handling is lacking. Until that can be clarified in a future release, the safest approach is to support a single targetRef.\n\nSupport: Extended for Kubernetes Service\n\nSupport: Implementation-specific for any other resource", Type: []string{"array"}, Items: &spec.SchemaOrArray{ Schema: &spec.Schema{ @@ -8786,7 +8786,7 @@ func schema_sigsk8sio_gateway_api_apisx_v1alpha1_BackendTrafficPolicySpec(ref co }, }, SchemaProps: spec.SchemaProps{ - Description: "TargetRefs identifies API object(s) to apply this policy to. Currently, Backends (A grouping of like endpoints such as Service, ServiceImport, or any implementation-specific backendRef) are the only valid API target references.\n\nCurrently, a TargetRef can not be scoped to a specific port on a Service.\n\nBecause of concerns over recording status correctly in some edge cases, currently, Core support is only given to one (1) TargetRef. More than one TargetRef is Implementation Specific.", + Description: "TargetRefs identifies API object(s) to apply this policy to. Currently, Backends (A grouping of like endpoints such as Service, ServiceImport, or any implementation-specific backendRef) are the only valid API target references.\n\nCurrently, a TargetRef can not be scoped to a specific port on a Service.", Type: []string{"array"}, Items: &spec.SchemaOrArray{ Schema: &spec.Schema{