-
Notifications
You must be signed in to change notification settings - Fork 84
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
Migrate to XP ManagementPolicies #163
Conversation
For now the combo that translates from ObserveDelete - > ["Observe", "Delete"] is not supported by default by controller-runtime. Ill add a PR which adds it to the list |
Still needs something to keep the objject webhook config in the yaml. WIP |
added a PR for above |
The |
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.
Looking pretty good, great work @lsviben 🙌
I like the way how you solved injecting conversion config to CRDs, even though it introduced another layer, I agree that there is no better way.
Two concerns that I have in general :
- This would require a Crossplane version with the recent fix, so:
- We should test what happens if someone with an old XP version, bumps provider-kubernetes to latest with this change.
- Make it explicit as much as we can that this requires a specific XP version.
- Could you also test how this behaves when Objects are part of compositions and may be compositions being part of Configurations. So, basically, what would be the migration path we suggest? Nothing to do by users? can we validate that?
During my testing I noticed that in some cases the provider-kubernetes logs:
Not sure yet why. Other then this in the logs, the conversion works fine, and nothing else looks amiss. But I would like to check more before merging this. cc: @turkenh |
For those who want to test this PR with the latest state (i.e. dea49e1), I just built/pushed an image which could be installed/upgraded to:
|
Signed-off-by: Hasan Turken <turkenh@gmail.com>
Signed-off-by: Hasan Turken <turkenh@gmail.com>
Signed-off-by: Hasan Turken <turkenh@gmail.com>
Signed-off-by: Hasan Turken <turkenh@gmail.com>
Signed-off-by: Hasan Turken <turkenh@gmail.com>
Looks like we need to have at least v1beta1 for conversion, otherwise getting: invalid: spec.conversion.conversionReviewVersions: Invalid value: []string{"v1alpha2"}: must include at least one of v1, v1beta1 Signed-off-by: Hasan Turken <turkenh@gmail.com>
Signed-off-by: lsviben <sviben.lovro@gmail.com>
Signed-off-by: lsviben <sviben.lovro@gmail.com>
Signed-off-by: lsviben <sviben.lovro@gmail.com>
Signed-off-by: lsviben <sviben.lovro@gmail.com>
Signed-off-by: lsviben <sviben.lovro@gmail.com>
Signed-off-by: lsviben <sviben.lovro@gmail.com>
Signed-off-by: lsviben <sviben.lovro@gmail.com>
Signed-off-by: lsviben <sviben.lovro@gmail.com>
Signed-off-by: lsviben <sviben.lovro@gmail.com>
Signed-off-by: lsviben <sviben.lovro@gmail.com>
Signed-off-by: lsviben <sviben.lovro@gmail.com>
Signed-off-by: lsviben <sviben.lovro@gmail.com>
Signed-off-by: lsviben <sviben.lovro@gmail.com>
Signed-off-by: lsviben <sviben.lovro@gmail.com>
Signed-off-by: lsviben <sviben.lovro@gmail.com>
Signed-off-by: lsviben <sviben.lovro@gmail.com>
Signed-off-by: lsviben <sviben.lovro@gmail.com>
Signed-off-by: lsviben <sviben.lovro@gmail.com>
I noticed TLS errors in the logs:
Everything seems to be working fine with the conversion, and nothing came out of my investigation. Found that it seems like a known issue from Go which appears on Kubernetes . So dropping further investigation of this for now, the PR should be good to go |
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.
Thank you @lsviben 🙌
I've successfully validated that conversion works well and observed no functional issues. Regarding the TLS error logs, I would suggest not blocking this PR and create a separate ticket to track it further.
@@ -184,7 +184,7 @@ spec: | |||
string: | |||
fmt: "%s-argocd" | |||
- base: | |||
apiVersion: kubernetes.crossplane.io/v1alpha1 | |||
apiVersion: kubernetes.crossplane.io/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.
think this needs to be fixed in master branch
kubernetes.crossplane.io/v1alpha2
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 one is actually the ProviderConfig, we didnt touch versioning of that. But the below one for the Object is wrong, ill fix it. Thanks for noticing!
@@ -206,7 +206,7 @@ spec: | |||
readinessChecks: | |||
- type: None | |||
- base: | |||
apiVersion: kubernetes.crossplane.io/v1alpha1 | |||
apiVersion: kubernetes.crossplane.io/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.
think this needs to be fixed in master branch
kubernetes.crossplane.io/v1alpha2
Description of your changes
Provider-kubernetes started using its own version of ManagementPoliciey before the core Crossplane. In the meantime, Crossplane developed its own native ManagementPolicies. This PR tries to smoothly migrate to the Crossplane ones.
v1alpha1
tov1alpha2
. There should not be any manual steps needed, as we are using conversion webhook to convert fromv1alpha1
tov1alpha2
.Fixes #162
I have:
make reviewable test
to ensure this PR is ready for review.How has this code been tested
make e2e
make e2e
local on kind with examples
and
there is a difference between
kubectl delete/get -f examples/object/object.yaml
and
kubectl delete/get -f objects.kubernetes.crossplane.io sample-namespace
the first one will convert the result back to
v1alpha1
if the object.yaml is in that version, the second one will just usev1beta1
without conversion (stored version).This is important for DELETE for example because if the conversion FROM
v1beta1
tov1alpha1
is not implemented correctly, the DELETED object will be saved as the "translated" objectv1alpha2
->v1alpha1
->v1alpha2
. If the translation back tov1alpha1
is not made correctly it could lose some important fields.(learned that the hard way :) )Tested with a configuration.