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

Improve behavior of kubectl options #1638

Closed
Parkofadown opened this issue Aug 7, 2024 · 11 comments
Closed

Improve behavior of kubectl options #1638

Parkofadown opened this issue Aug 7, 2024 · 11 comments
Labels
kind/feature Categorizes issue or PR as related to a new feature. needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one. sig/docs Categorizes an issue or PR as relevant to SIG Docs.

Comments

@Parkofadown
Copy link

Page is automatically generated
As of 2:24 PM 8/7/24
Synopsis states: Print the list of flags inherited by all commands

This synopsis is very vague and if you are intending to display all the flag options for all the kubectl commands inside of one terminal window, you are going to have to constantly scroll through the terminal to look for what you were looking for.
I recommend options being converted into an Argument for each individual command for example. kubectl get options and it will list all the flag options for the get command.

Thanks,
PARKOFADOWN

@k8s-ci-robot
Copy link
Contributor

This issue is currently awaiting triage.

SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the triage/accepted label.

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-sigs/prow repository.

@k8s-ci-robot k8s-ci-robot added the needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one. label Aug 7, 2024
@Adarsh-verma-14
Copy link

/language en
/sig docs

Page reported in issue:https://kubernetes.io/docs/reference/kubectl/generated/kubectl_options/

@k8s-ci-robot k8s-ci-robot added the sig/docs Categorizes an issue or PR as relevant to SIG Docs. label Aug 7, 2024
@sftim
Copy link
Contributor

sftim commented Aug 8, 2024

/transfer kubectl

@k8s-ci-robot k8s-ci-robot transferred this issue from kubernetes/website Aug 8, 2024
@sftim
Copy link
Contributor

sftim commented Aug 8, 2024

/kind feature

/retitle Improve behavior of kubectl options

@k8s-ci-robot k8s-ci-robot changed the title Improvement for k8s.io/docs/reference/kubectl/generated/kubectl_options/ Improve behavior of kubectl options Aug 8, 2024
@k8s-ci-robot k8s-ci-robot added the kind/feature Categorizes issue or PR as related to a new feature. label Aug 8, 2024
@Ritikaa96
Copy link
Contributor

Page is automatically generated As of 2:24 PM 8/7/24 Synopsis states: Print the list of flags inherited by all commands

This synopsis is very vague and if you are intending to display all the flag options for all the kubectl commands inside of one terminal window, you are going to have to constantly scroll through the terminal to look for what you were looking for. I recommend options being converted into an Argument for each individual command for example. kubectl get options and it will list all the flag options for the get command.

Thanks, PARKOFADOWN

If we look at the commands output, most of the options will be repeated (Not all). How do you propose this change ? If you clarify with example. It might make the proposition more legit.

@Parkofadown
Copy link
Author

Page is automatically generated As of 2:24 PM 8/7/24 Synopsis states: Print the list of flags inherited by all commands
This synopsis is very vague and if you are intending to display all the flag options for all the kubectl commands inside of one terminal window, you are going to have to constantly scroll through the terminal to look for what you were looking for. I recommend options being converted into an Argument for each individual command for example. kubectl get options and it will list all the flag options for the get command.
Thanks, PARKOFADOWN

If we look at the commands output, most of the options will be repeated (Not all). How do you propose this change ? If you clarify with example. It might make the proposition more legit.

@Ritikaa96 I will have to do some research and get back to you Monday August 12th in the afternoon EST

@Ritikaa96
Copy link
Contributor

No worries. Will look forward for this one.

@ardaguclu
Copy link
Member

Closing this in favor of #1632
/close

@k8s-ci-robot
Copy link
Contributor

@ardaguclu: Closing this issue.

In response to this:

Closing this in favor of #1632
/close

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-sigs/prow repository.

@Parkofadown
Copy link
Author

@Ritikaa96 For this issue my thoughts were that I use Linux through a virtual machine which has limited computer screen space and a limited sized terminal box the options would need to be an argument to describe the options for each individual command instead of a command displaying all options for all commands. Hope this clarifies, still have not had the opportunity to use the Kubectl options command at work to verify.

@Parkofadown
Copy link
Author

@Ritikaa96 @sftim @ardaguclu
Just ran the options command it is okay but still can be improved to an argument because if an individual runs multiple kubectl commands the options tab would be scrolled all the way to the top of the terminal. Then the individual would not remember all of the command options available without having to scroll. Example kubectl create options, kubectl run options and then it would display directly below the command just entered in the terminal and the user would not have to scroll very hard to see the options and then re-run the command.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/feature Categorizes issue or PR as related to a new feature. needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one. sig/docs Categorizes an issue or PR as relevant to SIG Docs.
Projects
None yet
Development

No branches or pull requests

6 participants