-
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’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
✨ Clusterctl alpha rollout status #8569
Conversation
Hi @hiromu-a5a. Thanks for your PR. I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
/ok-to-test |
6c282f4
to
c8a4707
Compare
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
@hiromu-a5a Hey, are you still working on this? It looks like it needs a rebase and I'm happy to give you a review once that's done. |
Yes. thank you for reminding me. I'll do and let you know. |
@hiromu-a5a Any updates on this PR? |
c8a4707
to
47fef46
Compare
@hiromu-a5a: The following test failed, say
Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed 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.
Overall seems pretty straightforward. I'm wondering if we can find a way to reuse some of the conditions + messages in the status to generate the rollout info.
// MachineDeploymentStatusWatcher implements the StatusViewer interface. | ||
type MachineDeploymentStatusWatcher struct{} | ||
|
||
// ObjectStatusWatcher will issue a view on the specified cluster-api resource. |
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.
// ObjectStatusWatcher will issue a view on the specified cluster-api resource. | |
// ObjectStatusWatcher will issue a view on the specified Cluster API resource. |
} | ||
|
||
oldStatus := "" | ||
timeout := 600 * time.Second |
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 there a shared timeout defined in a const somewhere?
return "", false, errors.Wrapf(err, "failed to get kubeadmcontrolplane/%v", name) | ||
} | ||
if newKcp.Spec.Replicas != nil && newKcp.Status.UpdatedReplicas < *newKcp.Spec.Replicas { | ||
return fmt.Sprintf("Waiting for kubeadmcontrolplane %q rollout to finish: %d out of %d new replicas have been updated...\n", newKcp.Name, newKcp.Status.UpdatedReplicas, *newKcp.Spec.Replicas), false, 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.
Q: Is there a way to reuse something like the ready condition in the status? That should already provide a summary of the resource as well as info on if it's an error, warning, or informational message.
The Kubernetes project currently lacks enough contributors to adequately respond to all PRs. This bot triages PRs according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale |
The Kubernetes project currently lacks enough active contributors to adequately respond to all PRs. This bot triages PRs according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle rotten |
@hiromu-a5a Are you still working on this? If not we might want to close this PR as it's been without activity for almost 6 months. |
At this point it's very very likely that we will deprecate and remove the revision management, see #10479 |
I am really sorry for the late reply. We are shifting to GitOps and lost motivation to clusterctl. |
What this PR does / why we need it:
In the current implementation, it's hard to track the status of rollout for a specific resource.
The basic behavior of this status command is similar to the
kubectl rollout status
which shows a message ever time rollout progress. A few differences are: i) only the machinedeployment/kubeadmcontrolplane are supported; ii)--revision=<revision>
option is omitted since when setting this option in kubectl, it just shows an error which is not informative; iii) As a business logic, codes in this PR directly GET resources whereas kubectl uses informer, because using the informer only for this command is too much; iv) timeout is hard coded whereas kubeclt use.spec.progressDeadlineSeconds
, because.spec.progressDeadlineSeconds
in MachineDeployment doesn't have any effect.In other words, this PR is the minimum implementation to satisfy most usecases of
rollout status
command.Which issue(s) this PR fixes (optional, in
fixes #<issue number>(, fixes #<issue_number>, ...)
format, will close the issue(s) when PR gets merged):Tracking Issue:
#3439