-
Notifications
You must be signed in to change notification settings - Fork 150
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
MCO-483: generate machineconfiguration (MCO) clients as part of MCO API migration #243
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -55,25 +55,46 @@ function generateApplyConfiguration(){ | |
done | ||
done | ||
|
||
echo "Generating applyconfigurations" | ||
if [ "$OUTPUT_PKG" == "github.com/openshift/client-go/machineconfiguration" ] | ||
then | ||
# TODO(jkyros): this is a temporary hack to ensure proper generation until the MCO can sort | ||
# out their embedded corev1.ObjectReference in MachineConfigPoolStatusConfiguration, which needs | ||
# to be resolved by the end of release-4.15 so this hack can be removed | ||
echo "Generating applyconfigurations specifically for MCO" | ||
applyconfigurationgen_external_apis_csv="$(codegen::join , "${FQ_APIS[@]}")" | ||
applyconfigurations_package="${OUTPUT_PKG}/${CLIENTSET_PKG_NAME:-applyconfigurations}" | ||
${APPLYCONFIGURATION_GEN} \ | ||
--output-package "${applyconfigurations_package}" \ | ||
--input-dirs "${applyconfigurationgen_external_apis_csv}" \ | ||
--external-applyconfigurations k8s.io/api/core/v1.ObjectReference:k8s.io/client-go/applyconfigurations/core/v1 \ | ||
Comment on lines
+63
to
+69
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. So the MCO embeds a
It looks like
If I add
Everything generates right for the MCO, but it changes a bunch of the other packages that were originally generated without the presence of So...I only added it when we're generating for the MCO and left it out for everyone else? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This is the "additional damage" in other packages if I let them generate with corev1 as external: 3367954 There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It's curious that the MCO blows up but others haven't, is there any difference in how the object reference is being used in the other APIs? Pointer vs reference per chance? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. There are examples in the API of both pointer/non-pointer usages, but ours is the only one that is embedded:
vs
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Ahh, right, in general for APIs we try to avoid embedding structs like that, but, it's done now. In theory you could change the go type without causing serialization errors, copying the fields from the object reference into the parent struct, that would mean you don't have this hack any more. Also, we should remove the protobuf tags, they aren't used for CRDs There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Something like this? https://gist.github.com/jkyros/db4d27fb28b38fa2ea170164ebfabae9#file-hypothetical_atrocity-go That feels like it should be a crime 😛 I think it would work, but there is stuff in the MCO that cares that it's an ObjectReference (mostly tests) and we'd need to defuse all of that. Would you entertain letting us keep this PR's MCO-only applyconfig hack for now (or something similar -- I don't want to make your update script ugly) until we can do some rearrangement? The applyconfigurations generated by this hack do seem to be proper and work, e.g. https://gist.github.com/jkyros/db4d27fb28b38fa2ea170164ebfabae9#file-main-go There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yeah the gist looks like what I meant. Since the serialization is the same, it's fine for a CRD to make a change like that to the go type, I got second opinions on that and a few of us are in agreement 😅 I'm happy to let you carry on like this, but, can we stick a pin in this to fix it before the end of 4.15? I'd like a TODO to remove this hack |
||
--external-applyconfigurations github.com/openshift/api/operator/v1.OperatorSpec:github.com/openshift/client-go/operator/applyconfigurations/operator/v1 \ | ||
--external-applyconfigurations github.com/openshift/api/operator/v1.OperatorStatus:github.com/openshift/client-go/operator/applyconfigurations/operator/v1 \ | ||
--external-applyconfigurations github.com/openshift/api/operator/v1.OperatorCondition:github.com/openshift/client-go/operator/applyconfigurations/operator/v1 \ | ||
--external-applyconfigurations github.com/openshift/api/operator/v1.GenerationStatus:github.com/openshift/client-go/operator/applyconfigurations/operator/v1 \ | ||
"$@" | ||
else | ||
echo "Generating applyconfigurations for $OUTPUT_PKG" | ||
applyconfigurationgen_external_apis_csv="$(codegen::join , "${FQ_APIS[@]}")" | ||
applyconfigurations_package="${OUTPUT_PKG}/${CLIENTSET_PKG_NAME:-applyconfigurations}" | ||
${APPLYCONFIGURATION_GEN} \ | ||
--output-package "${applyconfigurations_package}" \ | ||
--input-dirs "${applyconfigurationgen_external_apis_csv}" \ | ||
--external-applyconfigurations github.com/openshift/api/operator/v1.OperatorSpec:github.com/openshift/client-go/operator/applyconfigurations/operator/v1 \ | ||
--external-applyconfigurations github.com/openshift/api/operator/v1.OperatorStatus:github.com/openshift/client-go/operator/applyconfigurations/operator/v1 \ | ||
--external-applyconfigurations github.com/openshift/api/operator/v1.OperatorCondition:github.com/openshift/client-go/operator/applyconfigurations/operator/v1 \ | ||
--external-applyconfigurations github.com/openshift/api/operator/v1.GenerationStatus:github.com/openshift/client-go/operator/applyconfigurations/operator/v1 \ | ||
"$@" | ||
fi | ||
|
||
|
||
} | ||
|
||
# Until we get https://github.com/kubernetes/kubernetes/pull/120877 merged we need to | ||
# explicitly set these two variables which are not defaulted properly in generate-internal-groups.sh | ||
export CLIENTSET_PKG=clientset | ||
export CLIENTSET_NAME=versioned | ||
|
||
for group in apiserver apps authorization build cloudnetwork image imageregistry network oauth project quota route samples security securityinternal template user; do | ||
for group in apiserver apps authorization build cloudnetwork image imageregistry machineconfiguration network oauth project quota route samples security securityinternal template user; do | ||
bash ${CODEGEN_PKG}/generate-groups.sh "lister,informer" \ | ||
github.com/openshift/client-go/${group} \ | ||
github.com/openshift/api \ | ||
|
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
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.
Is this being tracked?
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.
Yes, I created MCO-726 for this purpose. Since we're in 4.15 now I moved it into our API migration epic, so it will be required to be completed in order for MCO to close the epic 😄