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

kn service update should print an error message when invalid or no option is passed #286

Closed
toVersus opened this issue Jul 23, 2019 · 8 comments · Fixed by #318
Closed
Assignees
Labels
good first issue Denotes an issue ready for a new contributor. kind/feature New feature or request
Milestone

Comments

@toVersus
Copy link
Contributor

In what area(s)?

/kind good-first-issue
/kind feature

Describe the feature:

When users run kn service update command with invalid options, nothing is changed. But in current implementation, kn prints the following output:

$ ./kn service update hello --max-scale -100
Waiting for service 'hello' to become ready ... OK
Service 'hello' updated in namespace 'default'.

IMO, this is a little confusing behavior. Kn should print unchanged when it changed nothing as kubectl does. I think we can implement this feature by comparing the generation before and after updating the service resource and returning changed/unchanged state (boolean).

$ ./kn service update hello --max-scale -100
Service 'hello' unchanged in namespace 'default'.

Can I take this, if you can accept this proposal?

@toVersus toVersus added the kind/feature New feature or request label Jul 23, 2019
@knative-prow-robot knative-prow-robot added the good first issue Denotes an issue ready for a new contributor. label Jul 23, 2019
@rhuss
Copy link
Contributor

rhuss commented Jul 23, 2019

Shouldn't we just print an error in this case ? like "-100 is an invalid value for max-scale".

Anything else would be surprising.

@rhuss
Copy link
Contributor

rhuss commented Jul 23, 2019

And then the "unchanged" message is unnecessary (you perfectly can assume that the service is not changed if an error occurs)

@toVersus
Copy link
Contributor Author

Shouldn't we just print an error in this case ?

Ah, maybe I mixed up things, so aren't there any strong opinions in current behavior, which silently keeps "unchanged" state if users input invalid values. Can we require to pass at least one option at anytime for avoiding the following case ?

$ ./kn service update hello
Waiting for service 'hello' to become ready ... OK
Service 'hello' updated in namespace 'default'.

@rhuss
Copy link
Contributor

rhuss commented Jul 23, 2019

Good point. We should catch that and return an error for such a no-op.

Of course, when we update with a new value == old value, we should not worry about (and should also print the success message)

@zhanggbj
Copy link

zhanggbj commented Jul 24, 2019

Hi @toVersus @rhuss ,

If nobody's working on this, I would like to take it. Thanks!
From the above comments, I think two items need to fix. Please let me know if anything is unclear.

  • Add input validation for kn service update flags, for e.g., if --max-scale -100 is specified, we should return an error.

  • If no input for kn service update, we should return an error.

@rhuss
Copy link
Contributor

rhuss commented Jul 24, 2019

@zhanggbj agreed on the action items.

/assign zhanggbj

@toVersus
Copy link
Contributor Author

@zhanggbj Thanks for picking it up! I worked on the first item in #279. I would appreciate if you look into the PR before implementing the second action item.

@toVersus toVersus changed the title kn service update prints unchanged when nothing is changed kn service update should print an error message when invalid or no option is passed Jul 24, 2019
@zhanggbj
Copy link

@toVersus Sure, no problem! I just noticed your PR, maybe you can refer this issue item in your PR comment so people can know you are working on it :)

zhanggbj pushed a commit to zhanggbj/client that referenced this issue Jul 30, 2019
For now if no flag(s) set, service update will still try to
do an update, it should return an error instead.

[issue 286](knative#286)
zhanggbj pushed a commit to zhanggbj/client that referenced this issue Jul 30, 2019
For now if no flag(s) set, service update will still try to
do an update, it should return an error instead.

[issue 286](knative#286)
zhanggbj pushed a commit to zhanggbj/client that referenced this issue Jul 30, 2019
For now if no flag(s) set, service update will still try to
do an update, it should return an error instead.

[issue 286](knative#286)
zhanggbj pushed a commit to zhanggbj/client that referenced this issue Jul 31, 2019
For now if no flag(s) set, service update will still try to
do an update, it should return an error instead.

[issue 286](knative#286)
zhanggbj pushed a commit to zhanggbj/client that referenced this issue Jul 31, 2019
For now if no flag(s) set, service update will still try to
do an update, it should return an error instead.

[issue 286](knative#286)
knative-prow-robot pushed a commit that referenced this issue Jul 31, 2019
For now if no flag(s) set, service update will still try to
do an update, it should return an error instead.

[issue 286](#286)
@navidshaikh navidshaikh added this to the v0.8.0 milestone Aug 27, 2019
coryrc pushed a commit to coryrc/client that referenced this issue May 14, 2020
…tive#286)

* complete source code for code coverage project for Knative repos

* fix build failure

* moved coverage from root dir to /tools/

* fix unit test failure

The failure was due to change of directory

also added the printing of stderr of failed cmds
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. kind/feature New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants