-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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鈥檒l occasionally send you account related emails.
Already on GitHub? Sign in to your account
馃尡 Detect certificate expiry from kube-apiserver serving cert #7355
馃尡 Detect certificate expiry from kube-apiserver serving cert #7355
Conversation
/assign @fabriziopandini @vincepri @ykakarap Please take a look. Quick feedback would be really appreciated! |
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 think this approach is ok
/test pull-cluster-api-e2e-full-main clusterctl upgrade test should be able to prove that existing machines get the expiry annotation after the upgrade EDIT: kind: KubeadmConfig
metadata:
annotations:
machine.cluster.x-k8s.io/certificates-expiry: "2023-10-06T06:11:17Z"
creationTimestamp: "2022-10-06T06:11:04Z" clusterctl upgrade using ClusterClass (v1.2=>current) [ClusterClass]: apiVersion: bootstrap.cluster.x-k8s.io/v1beta1
kind: KubeadmConfig
metadata:
annotations:
machine.cluster.x-k8s.io/certificates-expiry: "2023-10-06T07:19:20Z"
creationTimestamp: "2022-10-06T07:19:02Z" |
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.
The approach looks good to me
We should fix also documentation (see #7268)
5e6695a
to
2b04c4e
Compare
@fabriziopandini All findings should be adressed /test pull-cluster-api-e2e-full-main |
2b04c4e
to
f768132
Compare
/test pull-cluster-api-e2e-full-main |
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
/hold Waiting for feedback from Vince and then I want to add some test coverage before merge. |
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.
/approve
Ready to unhold/unwip? |
I would add a few unit tests tomorrow and Fabrizio can lgtm afterwards Primarily wanted the non-test code finalized/reviewed |
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.
The overall approach looks good 馃憤馃徏
This will be a nice improvements for the users.
/lgtm
Signed-off-by: Stefan B眉ringer buringerst@vmware.com
f768132
to
a7a4740
Compare
Added unit test, now ready for merge |
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.
Great work!
/lgtm
/approve
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: fabriziopandini, vincepri 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 |
/hold cancel |
Signed-off-by: Stefan B眉ringer buringerst@vmware.com
What this PR does / why we need it:
WIP: waiting for feedback before implementing unit tests
This PR changes the detection of the certificate expiry. Instead of setting it only for new machines
in CABPK now we detect it in KCP from the serving certificate of the kube-apiserver.
This has the big advantage that it allows detecting certificate expiry of pre-existing machines!
For more details see: #7342 (comment)
Which issue(s) this PR fixes (optional, in
fixes #<issue number>(, fixes #<issue_number>, ...)
format, will close the issue(s) when PR gets merged):Fixes #7342