v1 CRDs are coming #550
Comments
|
Do you think it would be possible to convert the ConstraintTemplate CRD to structural schemas? Right now it's blocking some API client generation. |
|
OpenAPIV3Schemas are themselves not structural because they are recursive and Constraint Templates wrap around an open api v3 schema so that users can provide arbitrary structure to We can make them qualify as structural by adding in |
|
Yes I think that should help. We only need to preserve unknown fields on the |
|
I think @julianKatz was looking at upgrading our version of controller-gen, which will go some way toward making the v1beta1 constraint templates structural. |
|
@maxsmythe are we talking the |
|
|
|
This was discussed in today's community call and I think we said we'll drop support for 1.15 and older versions of k8s when we move to CRD v1. Does it make sense to align this with #818? Then we can say GK v3.x is compatible with k8s v1.16+ cc @maxsmythe |
|
+1 I think that's a very good idea |
julianKatz
added a commit
to julianKatz/gatekeeper
that referenced
this issue
Apr 14, 2021
Kubernetes v1 CRDs require structural schemas. This means that, where possible, JSONSchemas should identify the type of a field. Fields without this type information will require the key: value pair of x-kubernetes-unknown-fields: true to be set. This signals the API server to save the content found in that field to etcd without validation. This PR adds the remaining type information to the MatchSchema() function, rendering its output structural. This func's output is what populates the `match` section of the CRD for a Constraint kind. Fixes open-policy-agent#550 Signed-off-by: juliankatz <juliankatz@google.com>
julianKatz
added a commit
to julianKatz/gatekeeper
that referenced
this issue
Apr 14, 2021
Kubernetes v1 CRDs require structural schemas. This means that, where possible, JSONSchemas should identify the type of a field. Fields without this type information will require the key: value pair of x-kubernetes-unknown-fields: true to be set. This signals the API server to save the content found in that field to etcd without validation. This PR adds the remaining type information to the MatchSchema() function, rendering its output structural. This func's output is what populates the `match` section of the CRD for a Constraint kind. Fixes open-policy-agent#550 Signed-off-by: juliankatz <juliankatz@google.com>
julianKatz
added a commit
to julianKatz/gatekeeper
that referenced
this issue
Apr 15, 2021
Kubernetes v1 CRDs require structural schemas. This means that, where possible, JSONSchemas should identify the type of a field. Fields without this type information will require the key: value pair of x-kubernetes-unknown-fields: true to be set. This signals the API server to save the content found in that field to etcd without validation. This PR adds the remaining type information to the MatchSchema() function, rendering its output structural. This func's output is what populates the `match` section of the CRD for a Constraint kind. Fixes open-policy-agent#550 Signed-off-by: juliankatz <juliankatz@google.com>
julianKatz
added a commit
to julianKatz/gatekeeper
that referenced
this issue
Apr 16, 2021
Kubernetes v1 CRDs require structural schemas. This means that, where possible, JSONSchemas should identify the type of a field. Fields without this type information will require the key: value pair of x-kubernetes-unknown-fields: true to be set. This signals the API server to save the content found in that field to etcd without validation. This PR adds the remaining type information to the MatchSchema() function, rendering its output structural. This func's output is what populates the `match` section of the CRD for a Constraint kind. Fixes open-policy-agent#550 Signed-off-by: juliankatz <juliankatz@google.com>
julianKatz
added a commit
to julianKatz/gatekeeper
that referenced
this issue
Apr 16, 2021
Kubernetes v1 CRDs require structural schemas. This means that, where possible, JSONSchemas should identify the type of a field. Fields without this type information will require the key: value pair of x-kubernetes-unknown-fields: true to be set. This signals the API server to save the content found in that field to etcd without validation. This PR adds the remaining type information to the MatchSchema() function, rendering its output structural. This func's output is what populates the `match` section of the CRD for a Constraint kind. Fixes open-policy-agent#550 Signed-off-by: juliankatz <juliankatz@google.com>
julianKatz
added a commit
to julianKatz/gatekeeper
that referenced
this issue
Apr 16, 2021
Kubernetes v1 CRDs require structural schemas. This means that, where possible, JSONSchemas should identify the type of a field. Fields without this type information will require the key: value pair of x-kubernetes-unknown-fields: true to be set. This signals the API server to save the content found in that field to etcd without validation. This PR adds the remaining type information to the MatchSchema() function, rendering its output structural. This func's output is what populates the `match` section of the CRD for a Constraint kind. Fixes open-policy-agent#550 Signed-off-by: juliankatz <juliankatz@google.com>
julianKatz
added a commit
to julianKatz/gatekeeper
that referenced
this issue
Apr 19, 2021
Kubernetes v1 CRDs require structural schemas. This means that, where possible, JSONSchemas should identify the type of a field. Fields without this type information will require the key: value pair of x-kubernetes-unknown-fields: true to be set. This signals the API server to save the content found in that field to etcd without validation. This PR adds the remaining type information to the MatchSchema() function, rendering its output structural. This func's output is what populates the `match` section of the CRD for a Constraint kind. Fixes open-policy-agent#550 Signed-off-by: juliankatz <juliankatz@google.com>
julianKatz
added a commit
to julianKatz/gatekeeper
that referenced
this issue
Apr 19, 2021
Kubernetes v1 CRDs require structural schemas. This means that, where possible, JSONSchemas should identify the type of a field. Fields without this type information will require the key: value pair of x-kubernetes-unknown-fields: true to be set. This signals the API server to save the content found in that field to etcd without validation. This PR adds the remaining type information to the MatchSchema() function, rendering its output structural. This func's output is what populates the `match` section of the CRD for a Constraint kind. Fixes open-policy-agent#550 Signed-off-by: juliankatz <juliankatz@google.com>
julianKatz
added a commit
to julianKatz/gatekeeper
that referenced
this issue
Apr 19, 2021
Kubernetes v1 CRDs require structural schemas. This means that, where possible, JSONSchemas should identify the type of a field. Fields without this type information will require the key: value pair of x-kubernetes-unknown-fields: true to be set. This signals the API server to save the content found in that field to etcd without validation. This PR adds the remaining type information to the MatchSchema() function, rendering its output structural. This func's output is what populates the `match` section of the CRD for a Constraint kind. Fixes open-policy-agent#550 Signed-off-by: juliankatz <juliankatz@google.com>
julianKatz
added a commit
to julianKatz/gatekeeper
that referenced
this issue
Apr 19, 2021
Kubernetes v1 CRDs require structural schemas. This means that, where possible, JSONSchemas should identify the type of a field. Fields without this type information will require the key: value pair of x-kubernetes-unknown-fields: true to be set. This signals the API server to save the content found in that field to etcd without validation. This PR adds the remaining type information to the MatchSchema() function, rendering its output structural. This func's output is what populates the `match` section of the CRD for a Constraint kind. Fixes open-policy-agent#550 Signed-off-by: juliankatz <juliankatz@google.com>
julianKatz
added a commit
to julianKatz/frameworks
that referenced
this issue
May 5, 2021
v1 CRDs require that any JSONSchema information within them be "structural", as defined in https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#specifying-a-structural-schema Gatekeeper Constraint Templates (current supported versions v1alpha1, v1beta1) contain information that is inserted into a CRD. That information must be structural to be inserted into a v1 CRD. As CTs are written by users, their `validation` section will contain JSONSchema information that we as developers cannot control. Further, users already have v1alpha1 and v1beta1 CTs running on production clusters that are expected to work as they upgrade gatekeeper and their k8s cluster. As v1beta1 CRDs did _not_ have the requirement of structural schemas, v1beta1 CTs also do not. Thus, our users could be passing in non-structural information that we will have to fit into a v1 CRD. To bridge this gap, this PR includes custom conversion functions for v1alpha1 and v1beta1 CT `valiation` sections into the internal, versionless CT representation. These conversion functions transform the input information, adding the `x-kubernetes-preserve-unknown-fields: true` key/value pair where necessary. This prevents the API server from pruning fields that do not have the necessary type information, as it would do were we to avoid this change. This satisfies the definition of a structural schema as defined in the aforementioned docs page. Fixes open-policy-agent/gatekeeper#550 Signed-off-by: juliankatz <juliankatz@google.com>
julianKatz
added a commit
to julianKatz/frameworks
that referenced
this issue
May 5, 2021
v1 CRDs require that any JSONSchema information within them be "structural", as defined in https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#specifying-a-structural-schema Gatekeeper Constraint Templates (current supported versions v1alpha1, v1beta1) contain information that is inserted into a CRD. That information must be structural to be inserted into a v1 CRD. As CTs are written by users, their `validation` section will contain JSONSchema information that we as developers cannot control. Further, users already have v1alpha1 and v1beta1 CTs running on production clusters that are expected to work as they upgrade gatekeeper and their k8s cluster. As v1beta1 CRDs did _not_ have the requirement of structural schemas, v1beta1 CTs also do not. Thus, our users could be passing in non-structural information that we will have to fit into a v1 CRD. To bridge this gap, this PR includes custom conversion functions for v1alpha1 and v1beta1 CT `valiation` sections into the internal, versionless CT representation. These conversion functions transform the input information, adding the `x-kubernetes-preserve-unknown-fields: true` key/value pair where necessary. This prevents the API server from pruning fields that do not have the necessary type information, as it would do were we to avoid this change. This satisfies the definition of a structural schema as defined in the aforementioned docs page. Fixes open-policy-agent/gatekeeper#550 Signed-off-by: juliankatz <juliankatz@google.com>
julianKatz
added a commit
to julianKatz/frameworks
that referenced
this issue
May 5, 2021
v1beta1 CRDs will not be supported in upcoming k8s versions, so all our CRDs will have to be v1. This makes our toolchain output a v1 CRD for the Constraint Template kind. Fixes open-policy-agent/gatekeeper#550 Signed-off-by: juliankatz <juliankatz@google.com>
julianKatz
added a commit
to julianKatz/frameworks
that referenced
this issue
May 5, 2021
v1beta1 CRDs will not be supported in upcoming k8s versions, so all our CRDs will have to be v1. This makes our toolchain output a v1 CRD for the Constraint Template kind. Contributes to open-policy-agent/gatekeeper#550 Signed-off-by: juliankatz <juliankatz@google.com>
julianKatz
added a commit
to julianKatz/frameworks
that referenced
this issue
May 5, 2021
v1 CRDs require that any JSONSchema information within them be "structural", as defined in https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#specifying-a-structural-schema Gatekeeper Constraint Templates (current supported versions v1alpha1, v1beta1) contain information that is inserted into a CRD. That information must be structural to be inserted into a v1 CRD. As CTs are written by users, their `validation` section will contain JSONSchema information that we as developers cannot control. Further, users already have v1alpha1 and v1beta1 CTs running on production clusters that are expected to work as they upgrade gatekeeper and their k8s cluster. As v1beta1 CRDs did _not_ have the requirement of structural schemas, v1beta1 CTs also do not. Thus, our users could be passing in non-structural information that we will have to fit into a v1 CRD. To bridge this gap, this PR includes custom conversion functions for v1alpha1 and v1beta1 CT `valiation` sections into the internal, versionless CT representation. These conversion functions transform the input information, adding the `x-kubernetes-preserve-unknown-fields: true` key/value pair where necessary. This prevents the API server from pruning fields that do not have the necessary type information, as it would do were we to avoid this change. This satisfies the definition of a structural schema as defined in the aforementioned docs page. Contributes to open-policy-agent/gatekeeper#550 Signed-off-by: juliankatz <juliankatz@google.com>
julianKatz
added a commit
to julianKatz/frameworks
that referenced
this issue
May 5, 2021
v1beta1 CRDs will not be supported in upcoming k8s versions, so all our CRDs will have to be v1. This makes our toolchain output a v1 CRD for the Constraint Template kind. Contributes to open-policy-agent/gatekeeper#550 Signed-off-by: juliankatz <juliankatz@google.com>
julianKatz
added a commit
to julianKatz/gatekeeper
that referenced
this issue
May 25, 2021
Gatekeeper pods were failing to start on a k8s 1.22 cluster due to a couple extra v1beta.CRD calls. This PR updates them. Contributes to open-policy-agent#550 Signed-off-by: juliankatz <juliankatz@google.com>
julianKatz
added a commit
that referenced
this issue
May 25, 2021
Upgrade two more apiextensionsv1beta1 references Gatekeeper pods were failing to start on a k8s 1.22 cluster due to a couple extra v1beta.CRD calls. This PR updates them. This also cleans up the remaining apiextensionsv1beta1 references, which were in test code. Contributes to #550 Signed-off-by: juliankatz juliankatz@google.com
Closed
julianKatz
added a commit
to julianKatz/frameworks
that referenced
this issue
Jun 1, 2021
We recently upgraded Constraint Framework to produce v1 CRDs when creating Constraint kind CRDs. This was in preparation for the release of k8s 1.22, which removes the `v1beta1` CRD version. See open-policy-agent/gatekeeper#550 for more info. As v1beta1 ConstraintTemplate did _not_ required any user-entered schema information to be structural, transformation logic was implemented to "structuralize" the user-inputted schema information as needed. The new v1 ConstraintTemplate version purposefully does _no_ transformation, as it is meant to put the ConstraintTemplate creation experience in line with that of a v1 CRDs. Any schema information added by the user is expected to be structural. If non-structural schema info is added, an error should be returned. Signed-off-by: juliankatz <juliankatz@google.com>
julianKatz
added a commit
to julianKatz/frameworks
that referenced
this issue
Jun 2, 2021
We recently upgraded Constraint Framework to produce v1 CRDs when creating Constraint kind CRDs. This was in preparation for the release of k8s 1.22, which removes the `v1beta1` CRD version. See open-policy-agent/gatekeeper#550 for more info. As v1beta1 ConstraintTemplate did _not_ required any user-entered schema information to be structural, transformation logic was implemented to "structuralize" the user-inputted schema information as needed. The new v1 ConstraintTemplate version purposefully does _no_ transformation, as it is meant to put the ConstraintTemplate creation experience in line with that of a v1 CRDs. Any schema information added by the user is expected to be structural. If non-structural schema info is added, an error should be returned. Signed-off-by: juliankatz <juliankatz@google.com>
julianKatz
added a commit
to julianKatz/frameworks
that referenced
this issue
Jun 9, 2021
Previously, I left ConstraintTemplate (CT) versions v1alpha1 and v1beta1 using apiextensionsv1beta1.JSONSchemaProps. I thought this appropriate, given that was what they were previously implemented as. v1 CT, on the other hand, would use v1beta1 JSONSchemaProps. This turns out to be a bad idea. Any logic we write that interacts with OpenAPIV3Schema in a CT's Validation section is forced to interact with OpenAPIV3Schema's type. Before this PR, that type is apiextensionsv1beta1.JSONSchemaProps. This makes our life difficult, as v1 CT's version of this variable will have a different type. This would then require us to re-implement any logic for this section to implement a second type, or to do some gross conversions. Further, apiextensionsv1beta1 will be removed from k8s.io/apiextensions-apiserver, preventing us from upgrading that library without doing this work. Basically, this change is unavoidable and appropriate. This blocks open-policy-agent#121 Contributes to open-policy-agent/gatekeeper#550 Signed-off-by: juliankatz <juliankatz@google.com>
julianKatz
added a commit
to julianKatz/frameworks
that referenced
this issue
Jun 9, 2021
Previously, I left ConstraintTemplate (CT) versions v1alpha1 and v1beta1 using apiextensionsv1beta1.JSONSchemaProps. I thought this appropriate, given that was what they were previously implemented as. v1 CT, on the other hand, would use v1beta1 JSONSchemaProps. This turns out to be a bad idea. Any logic we write that interacts with OpenAPIV3Schema in a CT's Validation section is forced to interact with OpenAPIV3Schema's type. Before this PR, that type is apiextensionsv1beta1.JSONSchemaProps. This makes our life difficult, as v1 CT's version of this variable will have a different type. This would then require us to re-implement any logic for this section to implement a second type, or to do some gross conversions. Further, apiextensionsv1beta1 will be removed from k8s.io/apiextensions-apiserver, preventing us from upgrading that library without doing this work. Basically, this change is unavoidable and appropriate. This blocks open-policy-agent#121 Contributes to open-policy-agent/gatekeeper#550 Signed-off-by: juliankatz <juliankatz@google.com>
|
@julianKatz is this okay to close now? |
julianKatz
added a commit
to julianKatz/frameworks
that referenced
this issue
Jun 9, 2021
We recently upgraded Constraint Framework to produce v1 CRDs when creating Constraint kind CRDs. This was in preparation for the release of k8s 1.22, which removes the `v1beta1` CRD version. See open-policy-agent/gatekeeper#550 for more info. As v1beta1 ConstraintTemplate did _not_ required any user-entered schema information to be structural, transformation logic was implemented to "structuralize" the user-inputted schema information as needed. The new v1 ConstraintTemplate version purposefully does _no_ transformation, as it is meant to put the ConstraintTemplate creation experience in line with that of a v1 CRDs. Any schema information added by the user is expected to be structural. If non-structural schema info is added, an error should be returned. Signed-off-by: juliankatz <juliankatz@google.com>
julianKatz
added a commit
to julianKatz/frameworks
that referenced
this issue
Jun 10, 2021
Our CRDs were previously of version v1beta1. In v1beta1, spec.PreserveUnknownFields defaulted to `true`. As we did not set this value explicitly, the value was set to `true`. We've now updated our CRDs to v1. In v1, spec.PreserveUnknownFields defaults to false. In fact, it is being deprecated in favor of the more targeted x-kubernetes-preserve-unknown-fields field. Despite this new default, spec.PreserveUnknownFields remains `true` for our CRDs, even after applying the new v1 versions. This does not cause any bad behavior, but is incorrect. To fix this, we must set spec.PreserveUnknownFields to false in our CRDs. `controller-gen` v0.5.0 doesn't include an annotation for that, presumably because it's not longer the supported path for disabling pruning. So, I've achieved the desired effect with a simple kustomize patch. Contributes to open-policy-agent/gatekeeper#550 Signed-off-by: juliankatz <juliankatz@google.com>
julianKatz
added a commit
to julianKatz/frameworks
that referenced
this issue
Jun 10, 2021
Our CRDs were previously of version v1beta1. In v1beta1, spec.PreserveUnknownFields defaulted to `true`. As we did not set this value explicitly, the value was set to `true`. We've now updated our CRDs to v1. In v1, spec.PreserveUnknownFields defaults to false. In fact, it is being deprecated in favor of the more targeted x-kubernetes-preserve-unknown-fields field. Despite this new default, spec.PreserveUnknownFields remains `true` for our CRDs, even after applying the new v1 versions. This does not cause any bad behavior, but is incorrect. To fix this, we must set spec.PreserveUnknownFields to false in our CRDs. `controller-gen` v0.5.0 doesn't include an annotation for that, presumably because it's not longer the supported path for disabling pruning. So, I've achieved the desired effect with a simple kustomize patch. Contributes to open-policy-agent/gatekeeper#550 Signed-off-by: juliankatz <juliankatz@google.com>
I'm going to include v1 ConstraintTemplate in here, since it's like an "addendum" |
julianKatz
added a commit
to julianKatz/frameworks
that referenced
this issue
Jun 22, 2021
We recently upgraded Constraint Framework to produce v1 CRDs when creating Constraint kind CRDs. This was in preparation for the release of k8s 1.22, which removes the `v1beta1` CRD version. See open-policy-agent/gatekeeper#550 for more info. As v1beta1 ConstraintTemplate did _not_ required any user-entered schema information to be structural, transformation logic was implemented to "structuralize" the user-inputted schema information as needed. The new v1 ConstraintTemplate version purposefully does _no_ transformation, as it is meant to put the ConstraintTemplate creation experience in line with that of a v1 CRDs. Any schema information added by the user is expected to be structural. If non-structural schema info is added, an error should be returned. Signed-off-by: juliankatz <juliankatz@google.com>
julianKatz
added a commit
to open-policy-agent/frameworks
that referenced
this issue
Jul 1, 2021
We recently upgraded Constraint Framework to produce v1 CRDs when creating Constraint kind CRDs. This was in preparation for the release of k8s 1.22, which removes the `v1beta1` CRD version. See open-policy-agent/gatekeeper#550 for more info. As v1beta1 ConstraintTemplate did _not_ required any user-entered schema information to be structural, transformation logic was implemented to "structuralize" the user-inputted schema information as needed. The new v1 ConstraintTemplate version purposefully does _no_ transformation, as it is meant to put the ConstraintTemplate creation experience in line with that of a v1 CRDs. Any schema information added by the user is expected to be structural. If non-structural schema info is added, an error should be returned. Signed-off-by: juliankatz <juliankatz@google.com>
julianKatz
added a commit
to julianKatz/gatekeeper
that referenced
this issue
Jul 2, 2021
This PR incorporates frameworks commit 1dbe2618668df5f48b6a256bdcd724eeb2b1c130 Add ConstraintTemplate v1 (#121) Contributes to open-policy-agent#550 Signed-off-by: juliankatz <juliankatz@google.com>
julianKatz
added a commit
to julianKatz/gatekeeper
that referenced
this issue
Jul 2, 2021
This PR incorporates frameworks commit 1dbe2618668df5f48b6a256bdcd724eeb2b1c130 Add ConstraintTemplate v1 (#121) Contributes to open-policy-agent#550 Signed-off-by: juliankatz <juliankatz@google.com>
julianKatz
added a commit
to julianKatz/gatekeeper
that referenced
this issue
Jul 8, 2021
This PR incorporates frameworks commit 1dbe2618668df5f48b6a256bdcd724eeb2b1c130 Add ConstraintTemplate v1 (#121) An imperative install CRD install step was added to the Helm Upgrade GH Workflow, as Helm does not update CRDs. Contributes to open-policy-agent#550 Signed-off-by: juliankatz juliankatz@google.com Signed-off-by: juliankatz <juliankatz@google.com>
|
As v1 CTs are now merged into Gatekeeper, I'm calling this done! |
julianKatz
added a commit
to julianKatz/gatekeeper
that referenced
this issue
Jul 27, 2021
This PR incorporates frameworks commit 1dbe2618668df5f48b6a256bdcd724eeb2b1c130 Add ConstraintTemplate v1 (#121) An imperative install CRD install step was added to the Helm Upgrade GH Workflow, as Helm does not update CRDs. Contributes to open-policy-agent#550 Signed-off-by: juliankatz juliankatz@google.com Signed-off-by: juliankatz <juliankatz@google.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
v1 CRDs are available as of K8s v1.16. We should begin supporting them in anticipation that v1beta1 get deprecated in the future.
The difficulty is that v1 has more stringent schema validation, so there may be some updating of templates needed to support the new version. I propose we copy what K8s is doing:
The text was updated successfully, but these errors were encountered: