Skip to content
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

Fix rollout history bug #111093

Merged
merged 1 commit into from Aug 24, 2022
Merged

Fix rollout history bug #111093

merged 1 commit into from Aug 24, 2022

Conversation

brianpursley
Copy link
Member

What type of PR is this?

/kind bug
/kind cleanup

What this PR does / why we need it:

Fixes bug in kubectl rollout history where only the latest revision was displayed when a specific revision was requested and an output format was specified

Adds unit and integration tests for rollout history.

Which issue(s) this PR fixes:

Fixes #110097

Special notes for your reviewer:

Does this PR introduce a user-facing change?

Fixed bug in kubectl rollout history where only the latest revision was displayed when a specific revision was requested and an output format was specified

Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.:


@k8s-ci-robot k8s-ci-robot added release-note Denotes a PR that will be considered when it comes time to generate release notes. size/XL Denotes a PR that changes 500-999 lines, ignoring generated files. kind/bug Categorizes issue or PR as related to a bug. kind/cleanup Categorizes issue or PR as related to cleaning up code, process, or technical debt. cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. do-not-merge/needs-sig Indicates an issue or PR lacks a `sig/foo` label and requires one. labels Jul 12, 2022
@k8s-ci-robot
Copy link
Contributor

@brianpursley: This issue is currently awaiting triage.

If a SIG or subproject determines this is a relevant issue, they will accept it by applying the triage/accepted label and provide further guidance.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

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.

@k8s-ci-robot k8s-ci-robot added needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one. needs-priority Indicates a PR lacks a `priority/foo` label and requires one. labels Jul 12, 2022
@k8s-ci-robot
Copy link
Contributor

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: brianpursley

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 /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@k8s-ci-robot k8s-ci-robot added area/test approved Indicates a PR has been approved by an approver from all required OWNERS files. sig/cli Categorizes an issue or PR as relevant to SIG CLI. sig/testing Categorizes an issue or PR as relevant to SIG Testing. and removed do-not-merge/needs-sig Indicates an issue or PR lacks a `sig/foo` label and requires one. labels Jul 12, 2022
@brianpursley
Copy link
Member Author

Holding for review...
/hold

@k8s-ci-robot k8s-ci-robot added the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Jul 12, 2022
@brianpursley
Copy link
Member Author

/retest

for _, rs := range allRSs {
v, err := deploymentutil.Revision(rs)
if err != nil {
continue
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why we continue in here?. As far as I understand, error in here is not a fatal thing?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think I agree that it should return an error. I was following the way that ViewHistory did it (see line 114 above), but it does seem that it would be misleading if it did not actually fail if there was an error.

Let me see about changing this to return an error...

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think I'm going to leave this as continue for now, and have added warning messages if it skips a replicaset.

It looks like this was done intentionally in case it is unable to parse the revision from the replicaset's annotation, so that you never get into a situation where you can't see the rollout history because of a single corrupt replicaset's metadata.

I could be convinced that returning an error is the correct thing to do, it just gives me pause to change this since this is how it was already being done. I wish there was a comment here or something explaining why continue is being used. At least there will be a warning now.

if err != nil {
return nil, fmt.Errorf("failed to retrieve replica sets from deployment %s: %v", name, err)
}
allRSs := oldRSs
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why we introduce allRSs instead using oldRSs?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I just extracted the original code into a func, but didn't try to improve it. I think you're right. It is unnecessary to introduce this extra variable

test/cmd/apps.sh Show resolved Hide resolved
@@ -48,6 +48,7 @@ const (
// HistoryViewer provides an interface for resources have historical information.
type HistoryViewer interface {
ViewHistory(namespace, name string, revision int64) (string, error)
GetHistory(namespace, name string) (map[int64]runtime.Object, error)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I understand that we can not easily remove ViewHistory. But just curiosity; semantically, GetHistory also contains ViewHistory?.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I mean consumers can do the same behavior just using the GetHistory without needing ViewHistory

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

GetHistory is just to get the data associated with the history, while ViewHistory gets and prints the history.

You are correct, a consumer can use GetHistory alone if they want to control how the data is handled. Or they can use ViewHistory alone if they want to let it get and print the output in the predefined way.


I thought about trying to refactor ViewHistory, but decided it would be too big of a change for this PR. I do think it probably needs to be refactored though. Maybe as a follow-up task.

Ideally, I think it would be good for ViewHistory to only be concerned with printing the history, and that it should not need to know how to also retrieve the history data. Maybe even move it to a describer like some of the existing TODO comments suggest.

}

historyInfo := make(map[int64]*corev1.PodTemplateSpec)
for _, rs := range allRSs {
v, err := deploymentutil.Revision(rs)
if err != nil {
klog.Warningf("unable to get revision from replicaset %s for deployment %s in namespace %s", rs.Name, name, namespace)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: would it be better to lower log level(ie. klog.v(2)) and embed error string into the message?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks. I added the error to the message.

But I'm leaving it as a warning, for now at least.

I don't think there would be a normal situation where an error occurs while getting the replicaset revision, so my intention is that the caller be made aware of the problem by printing a warning message. If this happens, then either there is something corrupt about that replicaset, or perhaps a bug in the revision logic somewhere in k8s that causes that situation (should it even occur).

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think there would be a normal situation where an error occurs while getting the replicaset revision, so my intention is that the caller be made aware of the problem by printing a warning message. If this happens, then either there is something corrupt about that replicaset, or perhaps a bug in the revision logic somewhere in k8s that causes that situation (should it even occur).

Good point

@ardaguclu
Copy link
Member

This lgtm but I'll defer it other folks to review.

Fix rollout history bug where the latest revision was
always shown when requesting a specific revision and
specifying an output.

Add unit and integration tests for rollout history.
@brianpursley
Copy link
Member Author

/retest

@brianpursley
Copy link
Member Author

ping @KnVerey thoughts on this PR?

@ardaguclu
Copy link
Member

/lgtm

@k8s-ci-robot k8s-ci-robot added the lgtm "Looks good to me", indicates that a PR is ready to be merged. label Jul 21, 2022
@dims
Copy link
Member

dims commented Aug 23, 2022

@brianpursley need to remove hold for this to land

@brianpursley
Copy link
Member Author

/unhold

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
approved Indicates a PR has been approved by an approver from all required OWNERS files. area/kubectl area/test cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. kind/bug Categorizes issue or PR as related to a bug. kind/cleanup Categorizes issue or PR as related to cleaning up code, process, or technical debt. lgtm "Looks good to me", indicates that a PR is ready to be merged. needs-priority Indicates a PR lacks a `priority/foo` label and requires one. needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one. release-note Denotes a PR that will be considered when it comes time to generate release notes. sig/cli Categorizes an issue or PR as relevant to SIG CLI. sig/testing Categorizes an issue or PR as relevant to SIG Testing. size/XL Denotes a PR that changes 500-999 lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Rollout history doesn't show the revision when output format is used
4 participants