Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

v1 CRDs are coming #550

Closed
maxsmythe opened this issue Apr 15, 2020 · 11 comments
Closed

v1 CRDs are coming #550

maxsmythe opened this issue Apr 15, 2020 · 11 comments
Assignees
@julianKatz
Labels
enhancement New feature or request
Projects
Roadmap
Milestone
v3.6.0

Comments

@maxsmythe
Copy link
Contributor

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:

  • Allow both v1beta1 and v1 constraint templates
  • Apply v1 CRD validation to the CRD created by v1 Constraint Templates
  • Apply v1beta1 CRD validation the the CRD created by v1beta1 constraint templates
  • Also apply v1 validation to the CRD created by v1beta1 constraint templates, but failures are a warning that is surfaced to the user.
  • Only instantiate v1beta1 CRDs on clusters so we don't break compatibility with clusters < v1.16
@morgante
Copy link

Do you think it would be possible to convert the ConstraintTemplate CRD to structural schemas? Right now it's blocking some API client generation.

@maxsmythe
Copy link
Contributor Author

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 properties.

We can make them qualify as structural by adding in x-kubernetes-preserve-unknown-fields: true, does that fix things?

@morgante
Copy link

Yes I think that should help. We only need to preserve unknown fields on the validation part of the schema.

@ritazh ritazh added this to To do in Roadmap Oct 6, 2020
@sozercan sozercan added the enhancement New feature or request label Oct 8, 2020
@maxsmythe
Copy link
Contributor Author

I think @julianKatz was looking at upgrading our version of controller-gen, which will go some way toward making the v1beta1 constraint templates structural.

@julianKatz
Copy link
Contributor

@maxsmythe are we talking the controller-gen in open-policy-agent/gatekeeper or in open-policy-agent/frameworks?

@maxsmythe
Copy link
Contributor Author

frameworks

@sozercan sozercan mentioned this issue Feb 26, 2021
Closed
@sozercan
Copy link
Member

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

@maxsmythe
Copy link
Contributor Author

+1 I think that's a very good idea

julianKatz added a commit to julianKatz/gatekeeper that referenced this issue Apr 14, 2021
@julianKatz
Add type declarations to g8r MatchSchema()
61ee060 
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 julianKatz mentioned this issue Apr 14, 2021
Merged
julianKatz added a commit to julianKatz/gatekeeper that referenced this issue Apr 14, 2021
@julianKatz
Add type declarations to g8r MatchSchema()
f62587f 
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
@julianKatz
Add type declarations to g8r MatchSchema()
58947b0 
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
@julianKatz
Add type declarations to g8r MatchSchema()
3692e2f 
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
@julianKatz
Add type declarations to g8r MatchSchema()
ceed92a 
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
@julianKatz
Add type declarations to g8r MatchSchema()
c9e8dc8 
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
@julianKatz
Add type declarations to g8r MatchSchema()
e59c753 
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
@julianKatz
Add type declarations to g8r MatchSchema()
793ac20 
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
@julianKatz
Add type declarations to g8r MatchSchema()
74be181 
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
@julianKatz
Add type declarations to g8r MatchSchema()
375a6cf 
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
@julianKatz
Add x-kubernetes-preserve-unknown-fields during CT conversion
e07e7c0 
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 julianKatz mentioned this issue May 5, 2021
Merged
julianKatz added a commit to julianKatz/frameworks that referenced this issue May 5, 2021
@julianKatz
Add x-kubernetes-preserve-unknown-fields during CT conversion
02df31f 
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
@julianKatz
Change Constraint Template CRD to apiextensions.k8s.io/v1
dcddaff 
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 julianKatz mentioned this issue May 5, 2021
Merged
julianKatz added a commit to julianKatz/frameworks that referenced this issue May 5, 2021
@julianKatz
Change Constraint Template CRD to apiextensions.k8s.io/v1
d50a5ea 
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
@julianKatz
Add x-kubernetes-preserve-unknown-fields during CT conversion
1180030 
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
@julianKatz
Change Constraint Template CRD to apiextensions.k8s.io/v1
6370717 
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
@julianKatz
Upgrade two more apiextensionsv1beta1 references
0b2b012 
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 julianKatz mentioned this issue May 25, 2021
Merged
julianKatz added a commit that referenced this issue May 25, 2021
@julianKatz
Upgrade two more apiextensionsv1beta1 references (#1327)
f6c2fe8 
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
@sozercan sozercan mentioned this issue May 27, 2021
Closed
julianKatz added a commit to julianKatz/frameworks that referenced this issue Jun 1, 2021
@julianKatz
Add ConstraintTemplate v1
8597947 
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 julianKatz mentioned this issue Jun 1, 2021
Merged
julianKatz added a commit to julianKatz/frameworks that referenced this issue Jun 2, 2021
@julianKatz
Add ConstraintTemplate v1
0b05084 
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
@julianKatz
ConstraintTemplate versions use apiextensionsv1
88ba532 
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 julianKatz mentioned this issue Jun 9, 2021
Merged
julianKatz added a commit to julianKatz/frameworks that referenced this issue Jun 9, 2021
@julianKatz
ConstraintTemplate versions use apiextensionsv1
04f102c 
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>
@sozercan
Copy link
Member

sozercan commented Jun 9, 2021

@julianKatz is this okay to close now?

julianKatz added a commit to julianKatz/frameworks that referenced this issue Jun 9, 2021
@julianKatz
Add ConstraintTemplate v1
dc2a818 
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
@julianKatz
Set PreserveUnknownFields: false in ConstraintTemplate v1 CRD
d89d10d 
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 julianKatz mentioned this issue Jun 10, 2021
Merged
julianKatz added a commit to julianKatz/frameworks that referenced this issue Jun 10, 2021
@julianKatz
Set PreserveUnknownFields: false in ConstraintTemplate v1 CRD
2073faf 
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
Copy link
Contributor

@julianKatz is this okay to close now?

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
@julianKatz
Add ConstraintTemplate v1
1e43b95 
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
@julianKatz
Add ConstraintTemplate v1 (#121)
1dbe261 
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
@julianKatz
Include v1 ConstraintTemplate from frameworks
c86e78f 
This PR incorporates frameworks commit

1dbe2618668df5f48b6a256bdcd724eeb2b1c130
Add ConstraintTemplate v1 (#121)

Contributes to open-policy-agent#550

Signed-off-by: juliankatz <juliankatz@google.com>
@julianKatz julianKatz mentioned this issue Jul 2, 2021
Merged
julianKatz added a commit to julianKatz/gatekeeper that referenced this issue Jul 2, 2021
@julianKatz
Include v1 ConstraintTemplate from frameworks
c65d9ef 
This PR incorporates frameworks commit

1dbe2618668df5f48b6a256bdcd724eeb2b1c130
Add ConstraintTemplate v1 (#121)

Contributes to open-policy-agent#550

Signed-off-by: juliankatz <juliankatz@google.com>
@sozercan sozercan modified the milestones: v3.5.0, v3.6.0 Jul 2, 2021
julianKatz added a commit that referenced this issue Jul 8, 2021
@julianKatz
Include v1 ConstraintTemplate from frameworks (#1416)
d9495ad 
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 #550

Signed-off-by: juliankatz juliankatz@google.com
julianKatz added a commit to julianKatz/gatekeeper that referenced this issue Jul 8, 2021
@julianKatz
Include v1 ConstraintTemplate from frameworks (open-policy-agent#1416)
91e0d1c 
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>
@julianKatz
Copy link
Contributor

As v1 CTs are now merged into Gatekeeper, I'm calling this done!

Roadmap automation moved this from To do to Done Jul 8, 2021
julianKatz added a commit to julianKatz/gatekeeper that referenced this issue Jul 27, 2021
@julianKatz
Include v1 ConstraintTemplate from frameworks (open-policy-agent#1416)
509fa68 
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
Assignees

@julianKatz julianKatz

Labels
enhancement New feature or request
Projects
Roadmap
  
Done
Milestone
v3.6.0
Development

No branches or pull requests
5 participants
@sozercan @morgante @ritazh @julianKatz @maxsmythe