-
Notifications
You must be signed in to change notification settings - Fork 243
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 Certificate Manager DNSAuthorization API #2561
Migrate Certificate Manager DNSAuthorization API #2561
Conversation
/assign @justinsb |
20a5df5
to
572ebe0
Compare
Hi Anh, I work Certificate Manager team and happened to see this pull request by accident. Just curious, could you provide me more context about this pull request? Is it part of the recent efforts to improve the config connector (https://github.com/GoogleCloudPlatform/k8s-config-connector?tab=readme-ov-file#-coming-soon-a-new-way-to-write-the-controller-) ? Also, is the defined schema for this resource based on the the latest version that the config connector had? or will it be up-to-date with the API ? Are we no longer based on the Terraform Provider Google beta version? I'm asking because the latest version we had in KCC didn't include the recently-added Enum field |
apis/certificatemanager/v1beta1/certificatemanagerdnsauthorization_types.go
Show resolved
Hide resolved
apis/certificatemanager/v1beta1/certificatemanagerdnsauthorization_types.go
Show resolved
Hide resolved
@Hamzawy63
|
7a80250
to
2af3156
Compare
dev/tasks/generate-crds
Outdated
excluded_resources=("computeforwardingrule") | ||
excluded_resources=("computeforwardingrule" "certificatemanagerdnsauthorization") | ||
|
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.
So for a beta resource, we suggest not excluding the CRD generation using excluded_resources
, because it gives the PR reviewing no clue on whether the outcome is correct or not (also it would be very error prone for the developers).
Instead, you can add the cnrm.cloud.google.com/dcl2crd: "true”
in the type go tag. (example), and comment out those new fields that do not exist in the TF-based resources according to the outcome from dev/task/generate-crds. Guide here
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 good! One comment about avoid using the excluded_resources
flag so that we can compare whether this PR is backward compatible since the resource is already in Beta.
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 with a few non-blocking nits.
apis/certificatemanager/v1beta1/certificatemanagerdnsauthorization_types.go
Outdated
Show resolved
Hide resolved
apis/certificatemanager/v1beta1/certificatemanagerdnsauthorization_types.go
Show resolved
Hide resolved
apis/certificatemanager/v1beta1/certificatemanagerdnsauthorization_types.go
Show resolved
Hide resolved
The current CRD also has v1alpha1 information. if I do not exclude this resource; the v1alpha1 part will be deleted which might cause issue for customer who is using v1alpha1. |
you can include the alpha resource in the direct types. here's the related section in the guide. |
685bb42
to
14aa100
Compare
done. added alpha resource and regen crds |
@@ -308,9 +341,3 @@ spec: | |||
storage: true |
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.
Could you try to:
- Install the old CRD and create a CertificateManagerDNSAuthorization resource.
- Upgrade to the new CRD.
- Verify whether the upgrade works and whether the existing CertificateManagerDNSAuthorization successfully reconciled based on the new schema?
The reason I asked here is that we've never switched the storage version from v1alpha1 to v1beta1 so we probably want to be extra careful.
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.
I tested by following these steps:
- Checkout to master
- Apply the existing crd
kubectl apply -f config/crds/resources/apiextensions.k8s.io_v1_customresourcedefinition_certificatemanagerdnsauthorizations.certificatemanager.cnrm.cloud.google.com.yaml; make deploy-controller && kubectl delete pods --namespace cnrm-system --all
- Apply sample DNS Authorization
kubectl apply -f config/samples/resources/certificatemanagerdnsauthorization/certificatamanager_v1beta1_certificatemanagerdnsauthorization.yaml
- Check into my branch with new change and run step 2 again with an extra log line to confirm that the new controller is deployed.
- Wait a bit and confirm that the resource is still good.
- Make a change in the resource and apply again to force reconciliation.
- The resource is updated and ready.
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.
Awesome, thank you!
14aa100
to
b7f1353
Compare
/lgtm though you'll probably want to figure out why the validation still fails. |
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
/approve
Awesome! Thanks!
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: yuwenma The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
apis/certificatemanager/v1alpha1/certificatemanagerdnsauthorization_types.go
Outdated
Show resolved
Hide resolved
b7f1353
to
d7a333c
Compare
/lgtm |
f437f9f
into
GoogleCloudPlatform:master
Change description
Fixes #
Tests you have done
make ready-pr
to ensure this PR is ready for review.