Navigation Menu

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

Unwanted console output in the versiongetter API #1853

Closed
bart0sh opened this issue Oct 23, 2019 · 10 comments · Fixed by kubernetes/kubernetes#85032
Closed

Unwanted console output in the versiongetter API #1853

bart0sh opened this issue Oct 23, 2019 · 10 comments · Fixed by kubernetes/kubernetes#85032
Assignees
Labels
good first issue Denotes an issue ready for a new contributor, according to the "help wanted" guidelines. help wanted Denotes an issue that needs help from a contributor. Must meet "help wanted" guidelines. lifecycle/active Indicates that an issue or PR is actively being worked on by a contributor. priority/backlog Higher priority than priority/awaiting-more-evidence.
Milestone

Comments

@bart0sh
Copy link

bart0sh commented Oct 23, 2019

API to get version information(ClusterVersion, KubeadmVersion and VersionFromCILabel) contain unwanted calls of fmt.Print functions:

https://github.com/kubernetes/kubernetes/blob/master/cmd/kubeadm/app/phases/upgrade/versiongetter.go#L66
https://github.com/kubernetes/kubernetes/blob/master/cmd/kubeadm/app/phases/upgrade/versiongetter.go#L78
https://github.com/kubernetes/kubernetes/blob/master/cmd/kubeadm/app/phases/upgrade/versiongetter.go#L95

They should be moved outside of the API. It should be done carefully in order to not degrade user experience, i.e. kubeadm console output should stay the same.

@bart0sh
Copy link
Author

bart0sh commented Oct 23, 2019

/good-first-issue

@k8s-ci-robot
Copy link
Contributor

@bart0sh:
This request has been marked as suitable for new contributors.

Please ensure the request meets the requirements listed here.

If this request no longer meets these requirements, the label can be removed
by commenting with the /remove-good-first-issue command.

In response to this:

/good-first-issue

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 good first issue Denotes an issue ready for a new contributor, according to the "help wanted" guidelines. help wanted Denotes an issue that needs help from a contributor. Must meet "help wanted" guidelines. labels Oct 23, 2019
@neolit123
Copy link
Member

neolit123 commented Oct 23, 2019

@bart0sh please link to code examples for such fmt.Print* calls in the first post.

@neolit123 neolit123 added the priority/awaiting-more-evidence Lowest priority. Possibly useful, but not yet enough support to actually get it done. label Oct 23, 2019
@neolit123 neolit123 added this to the v1.17 milestone Oct 23, 2019
@SataQiu
Copy link
Member

SataQiu commented Oct 24, 2019

/cc

@bart0sh
Copy link
Author

bart0sh commented Oct 24, 2019

@neolit123

please link to code examples for such fmt.Print* calls in the first post.

done

@neolit123 neolit123 added priority/backlog Higher priority than priority/awaiting-more-evidence. and removed priority/awaiting-more-evidence Lowest priority. Possibly useful, but not yet enough support to actually get it done. labels Oct 24, 2019
@jfbai
Copy link

jfbai commented Oct 28, 2019

I can help fix this.

@bart0sh @neolit123 Move them to caller side?

/assign

@bart0sh
Copy link
Author

bart0sh commented Oct 28, 2019

@jfbai Yes, that's pretty much what needs to be done. However, it should be done carefully to make sure user visible output doesn't change.

@jfbai
Copy link

jfbai commented Oct 31, 2019

@jfbai Yes, that's pretty much what needs to be done. However, it should be done carefully to make sure user visible output doesn't change.

I have an idea about move them to caller side, something like this:

// ClusterVersion gets API server version
func (g *KubeVersionGetter) ClusterVersion() (string, *versionutil.Version, error) {
	clusterVersionInfo, err := g.client.Discovery().ServerVersion()
	if err != nil {
		return "", nil, errors.Wrap(err, "Couldn't fetch cluster version from the API Server")
	}
	fmt.Fprintf(g.w, "[upgrade/versions] Cluster version: %s\n", clusterVersionInfo.String())

	clusterVersion, err := versionutil.ParseSemantic(clusterVersionInfo.String())
	if err != nil {
-               return "", nil, errors.Wrap(err, "Couldn't parse cluster version")
+		return clusterVersionInfo.String(), nil, errors.Wrap(err, "Couldn't parse cluster version")
	}
	return clusterVersionInfo.String(), clusterVersion, nil
}

// caller side
	kubeadmVersionStr, kubeadmVersion, err := versionGetterImpl.KubeadmVersion()
	if err != nil {
+		if len(kubeadmVersionStr) > 0 {
+			fmt.Printf("[upgrade/versions] kubeadm version: %s\n", kubeadmVersionStr)
+		}
		return upgrades, err
	}

Could this be fine?

@bart0sh
Copy link
Author

bart0sh commented Oct 31, 2019

@jfbai Not sure why do you use ClusterVersion() API and KubeadmVersion() on the caller side in your example, but I think I've got your idea. It's a bit implicit to my taste, but could work. You can also consider splitting ClusterVersion API to 2 APIs: ClusterVersionInfo() and ClusterVersion() It'd result in a bit more code duplication on the caller side, but it's more readable in my opinion.

@jfbai
Copy link

jfbai commented Nov 1, 2019

@jfbai Not sure why do you use ClusterVersion() API and KubeadmVersion() on the caller side in your example, but I think I've got your idea. It's a bit implicit to my taste, but could work.

@bart0sh My mistake.

You can also consider splitting ClusterVersion API to 2 APIs: ClusterVersionInfo() and ClusterVersion() It'd result in a bit more code duplication on the caller side, but it's more readable in my opinion.

IMO, your idea makes sense and I will implement in this way.

@neolit123 neolit123 added the lifecycle/active Indicates that an issue or PR is actively being worked on by a contributor. label Nov 9, 2019
@neolit123 neolit123 modified the milestones: v1.17, v1.18 Nov 19, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
good first issue Denotes an issue ready for a new contributor, according to the "help wanted" guidelines. help wanted Denotes an issue that needs help from a contributor. Must meet "help wanted" guidelines. lifecycle/active Indicates that an issue or PR is actively being worked on by a contributor. priority/backlog Higher priority than priority/awaiting-more-evidence.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants