-
Notifications
You must be signed in to change notification settings - Fork 52
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
Upgrade: controller-gen v0.5.0, conversion-gen v0.20.2 #111
Upgrade: controller-gen v0.5.0, conversion-gen v0.20.2 #111
Conversation
40c7936
to
97d09fe
Compare
constraint/config/crd_patch.yaml
Outdated
served: true | ||
storage: false | ||
|
||
version: v1beta1 |
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.
Would love to get rid of this completely, but I'm not sure how.
@maxsmythe you know the kubebuilder annotations pretty well... do you know how to change it?
That said, all the v1beta1 CRD examples in this kubernetes documentation don't even include the version:
field, so maybe we can just remove it.
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.
Yeah, the version field just needs to equal the first item in the versions
list, if present.
From the looks of it, this can be removed.
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.
It looks like leaving it in is actually breaking the unit tests
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.
Removed it using kustomize
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.
Basically LGTM with two nits.
@sozercan Can you see if this alone is enough to unblock your upgrading controller-runtime in GK? I'm skeptical because I'm not seeing new methods in the autogenned code.
If not, maybe controller-gen takes its cues from the version of controller-runtime used. And we'll need to upgrade that dependency and regen.
constraint/config/crd_patch.yaml
Outdated
served: true | ||
storage: false | ||
|
||
version: v1beta1 |
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.
Yeah, the version field just needs to equal the first item in the versions
list, if present.
From the looks of it, this can be removed.
@maxsmythe I think we will need to regenerate the conversions for it to work with new apimachinery. Sounds like when we regenerate with new version, it should remove s.Convert() or have it accept 2 args.
|
@sozercan WDYT of committing this as-is (as this change at least gets us to a workable version of controller-gen), then we can play around with figuring out whatever kind of poking we need to do to update the conversion function signatures? |
@sozercan @julianKatz It looks like controller-gen doesn't integrate conversion-gen, which is what is used to generate the conversion functions. We'll need to keep building/applying that one manually (if possible): https://pkg.go.dev/k8s.io/code-generator/cmd/conversion-gen Luckily conversion-gen appears to be versioned in lockstep with K8s, so we should be able to upgrade it along with controller-runtime. |
Also, because we can just move dependencies in lockstep now, we wont need to run conversion-gen as it's own, self-contained gomodule/docker container. |
can we re-add the conversion-gen parts back to makefile (and whatever else is missing)? So we can only focus on upgrading controller-gen in this PR and follow up on conversion-gen later. |
4c29f6c
to
56ce6ad
Compare
Codecov Report
@@ Coverage Diff @@
## master #111 +/- ##
==========================================
- Coverage 44.15% 43.89% -0.27%
==========================================
Files 27 27
Lines 2405 2383 -22
==========================================
- Hits 1062 1046 -16
+ Misses 1023 1017 -6
Partials 320 320
Flags with carried forward coverage won't be shown. Click here to find out more.
Continue to review full report at Codecov.
|
6f0e4bb
to
b7f544a
Compare
return err | ||
} | ||
// FIXME: Provide conversion function to convert apiextensionsv1beta1.JSONSchemaProps to apiextensions.JSONSchemaProps | ||
compileErrorOnMissingConversion() |
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.
this is an issue generating these conversions (and why lint is failing). not sure why this happens since these conversions exists.
example:
func autoConvert_v1beta1_Validation_To_templates_Validation(in *Validation, out *templates.Validation, s conversion.Scope) error {
if in.OpenAPIV3Schema != nil {
in, out := &in.OpenAPIV3Schema, &out.OpenAPIV3Schema
*out = new(apiextensions.JSONSchemaProps)
if err := v1.Convert_v1_JSONSchemaProps_To_apiextensions_JSONSchemaProps(*in, *out, s); err != nil {
return err
}
} else {
out.OpenAPIV3Schema = nil
}
return nil
}
func autoConvert_templates_Validation_To_v1beta1_Validation(in *templates.Validation, out *Validation, s conversion.Scope) error {
if in.OpenAPIV3Schema != nil {
in, out := &in.OpenAPIV3Schema, &out.OpenAPIV3Schema
*out = new(v1.JSONSchemaProps)
if err := v1.Convert_apiextensions_JSONSchemaProps_To_v1_JSONSchemaProps(*in, *out, s); err != nil {
return err
}
} else {
out.OpenAPIV3Schema = nil
}
return nil
}
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.
Looks like this is a bug (kubernetes/kubernetes#98380)
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.
False alarm! I just needed to make that package available to conversion-gen
. Thanks for posting that example @sozercan, that was the clue I needed.
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.
Issue says it's for types containing an array of pointers to custom objects.
Does this apply to our types?
Is this a blocker? What are our options here?
glad it's resolved!
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.
Sorry, it isn't completely resolved. I've included notes in Makefile
.
But, I've got us frankensteined together enough to move forward.
constraint/Makefile
Outdated
# Install the generation dependencies on the location machine | ||
gen-dependencies: | ||
GO111MODULE=on go get sigs.k8s.io/controller-tools/cmd/controller-gen@v0.5.0 | ||
GO111MODULE=on go get k8s.io/code-generator/cmd/conversion-gen@v0.21.0 |
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.
should we align this with controller-gen dependency version (v0.20.2)?
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.
We probably want to align this with the cert-controller dependency version (but that is also v0.20.2):
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.
Will update
b7f544a
to
eedf931
Compare
Checks are failing. Can we exclude For the unit tests, it looks like we need to change the controller-gen invocation to |
@maxsmythe linter is failing because of undefined function getting generated (which is meant to cause build failure) #111 (review) |
eedf931
to
0c5e494
Compare
With the default call to
and
The first is fixed by including the
But, the second remains unfixed. Why? It turns out that the conversion function we'd expect is actually a human written one, found at AFAICT, this is a bug (albeit a different one than the one I mentioned earlier). In the meantime, I can change the line of code manually and we can move on. I'll file a bug in EDIT: This isn't quite right actually. It turns out that the necessary function is already generated. See it defined in the generated file. I'm lost as to why this is happening. |
0c5e494
to
f37e4f8
Compare
@julianKatz there are more investigations at kubernetes/kubernetes#101567 |
a4911cf
to
197a4b3
Compare
Update: I've gotten around the In the meantime, I believe this PR can move forward. |
Unit tests are passing now. PTAL: @maxsmythe @sozercan @shomron |
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.
Still LGTM with 1 nit, @sozercan LGTY?
constraint/Makefile
Outdated
docker build . -t constraint-test && docker run -t constraint-test | ||
|
||
# Install CRDs into a cluster | ||
install: manifests | ||
kubectl apply -f config/crds | ||
|
||
# Install the generation dependencies on the location machine |
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.
nit: location => local?
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.
oops, will change
Not a huge fan of the manual code update, but I don't see any other way forward :( Can we document what to manually update in conversion? (perhaps add in #112) |
frameworks/constraint had previously been reliant on an outdated version of the controller-gen library for generating CRDs with embedded JSONSchemas. The older version of the library wasn't built to detect a nested JSONSchema, and thus would not refuse it. With the requirement of v1 CRDs around the corner in k8s 1.22, framework/constraint requires the newer controller-gen v0.5.0. This library version can output v1 CRD. The conversion logic was also in need of a library upgrade, with conversion-gen v0.21.0 now generating the necessary files. This PR _does not_ output a v1 CRD for Constraint Template. That will be left for a future PR. This PR brings the two binaries up-to-date. Note: I attempted to dockerize these two binaries. Controller-gen worked fine, but for some reason conversion-gen couldn't write to the filesystem. The output looked fine, but no dice. Rather than figure out why, I decided to punt on the dockeriziation effort. Signed-off-by: juliankatz <juliankatz@google.com>
197a4b3
to
0e7217e
Compare
@julianKatz ready to merge? |
frameworks/constraint had previously been reliant on an outdated version
of the controller-gen library for generating CRDs with embedded
JSONSchemas. The older version of the library wasn't built to detect
a nested JSONSchema, and thus would not refuse it.
With the requirement of v1 CRDs around the corner in k8s 1.22,
framework/constraint requires the newer controller-gen v0.5.0. This
library version can output v1 CRD.
The conversion logic was also in need of a library upgrade, with
conversion-gen v0.21.0 now generating the necessary files.
This PR does not output a v1 CRD for Constraint Template. That will
be left for a future PR. This PR brings the two binaries up-to-date.
Note: I attempted to dockerize these two binaries. Controller-gen
worked fine, but for some reason conversion-gen couldn't write to the
filesystem. The output looked fine, but no dice. Rather than figure
out why, I decided to punt on the dockeriziation effort.