-
Notifications
You must be signed in to change notification settings - Fork 49
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.
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
Add ConstraintTemplate v1 #121
Add ConstraintTemplate v1 #121
Conversation
Codecov Report
@@ Coverage Diff @@
## master #121 +/- ##
==========================================
- Coverage 44.31% 42.19% -2.13%
==========================================
Files 30 35 +5
Lines 2419 2766 +347
==========================================
+ Hits 1072 1167 +95
- Misses 1022 1234 +212
- Partials 325 365 +40
Flags with carried forward coverage won't be shown. Click here to find out more.
Continue to review full report at Codecov.
|
8597947
to
0b05084
Compare
@maxsmythe and I have been trying to decide if Gatekeeper needs a Version Conversion Webhook to handle the conversion between To deal with reverse-compatibility, we've added the To validate that this acted as expected, I did the following manual test:
This test showed that the CT (originally applied as a Now, I'm going to dig into the details of how this process happens in the API server. We want to insure that this is the supported path, and not just a happy accident. |
Further investigation in the docs has confirmed this behavior: "Defaulting happens on the object... when reading from etcd using the storage version defaults". As the previous comment showed, the defaults from the version that a given CR was stored as are applied when retrieving that CR. This appears to be the case even when that CR is retrieved another version. In my test case, that meant that a |
What's here LGTM, but should we also add the honoring of legacySchema to this PR so that we don't recognize v1 without also recognizing its behavioral changes? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Forgot to mark my comment as a change request on the PR
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>
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>
e63d671
to
2d7d8e6
Compare
Does the newer version of the code do what you had in mind? Basically, for all three CT versions, the transformation is only done if |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
constraint/pkg/apis/templates/v1/constrainttemplate_types_test.go
Outdated
Show resolved
Hide resolved
Signed-off-by: juliankatz <juliankatz@google.com>
Signed-off-by: juliankatz <juliankatz@google.com>
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>
Signed-off-by: juliankatz <juliankatz@google.com>
Signed-off-by: juliankatz <juliankatz@google.com>
Signed-off-by: juliankatz <juliankatz@google.com>
Signed-off-by: juliankatz <juliankatz@google.com>
Signed-off-by: juliankatz <juliankatz@google.com>
6fc5688
to
0e3672b
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
This PR incorporates frameworks commit 1dbe261 Add ConstraintTemplate v1 (open-policy-agent#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
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. Seeopen-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.
Contributes to open-policy-agent/gatekeeper#550
Signed-off-by: juliankatz juliankatz@google.com