-
Notifications
You must be signed in to change notification settings - Fork 261
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
Adds more columns in service get command output #56
Conversation
/ok-to-test |
2b53f46
to
e22252a
Compare
/retest |
7534667
to
d2497f2
Compare
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.
Looks good to me, but I'm not sure whether tabwriter.Writer
is the proper approach as it assumes always equally sized columns (although with a minimum width). I don't think it is optimal for distributing screen real estate.
For example, typically the NAME column is much larger than a status column. E.g. for plain pods its not uncommon to have name of 20 chars, but the READY column will be only around 3-5 chars. Having this equally sized with 20 chars is waste of space and doesnt look good anyway.
I recommend a more customized format. Not sure what Go package is a good fit (maybe fromhttps://github.com/kubernetes/cli-runtime). If it would be Perl, I would use perl formats.
tl;dr - I think we already think about flexible, non equally sized column widths.
@rhuss : Thanks for your review, each column width is re-adjusted based on the cell's max width (of that column). Hard-coding the padding and column width wont scale IMO. |
Yeah right. My fault, I've misread the documentation here. I think you are right, we should stay with this approach. |
/hold I think we should not implement our own table-writing code. |
I agree, that we should reuse the formatting machinery provided by cli-runtime for creating various output formats when specific options are provided.
Sorry for my ignorance (just ramping up with the k8s codebase), but doesn't kubectl itself uses custom code for human readable output ? I.e. in https://github.com/kubernetes/kubernetes/blob/c082ace102e217846833baace01d80966369ecd8/pkg/kubectl/cmd/get/get.go#L513 if I think we should combine both, but I'm afraid we have to write our own formatting code for the default console output, not covered by CLI options. |
in kubectl, the tab-writer is used when this combination of options is true: // human readable printers have special conversion rules, so we determine if we're using one.
if (len(*o.PrintFlags.OutputFormat) == 0 && len(templateArg) == 0) || *o.PrintFlags.OutputFormat == "wide" {
o.IsHumanReadablePrinter = true
} |
I'm a bit confused: Both I'm pretty sure that the supported printers (JSON, YAML, Name, Template) are not suitable for direct console output. @sixolet Any suggestion how to proceed? We could either implement a HumanReadableWriter on our own or just use a tabbed writer for the beginning (if no other options have been selected). |
@rhuss : Thanks for the feedback on human readable output format and enabling the generic output format flags, I have updated the PR respectively. Now the command supports printing with generic output format flags. Excerpts
and the
and the service list with jsonpath
|
The following is the coverage report on pkg/.
|
@sixolet : The previous approach for getting printer from cli-runtime is now restored. If no output flags are specified, the tabwriter is used to print the human-readable output. |
796782f
to
f62bd08
Compare
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: navidshaikh If they are not already assigned, you can assign the PR to them by writing 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 |
Based on the recent discussions, renamed |
@sixolet @cppforlife What are other recommendations ? I was checking https://github.com/kubernetes/kubernetes/tree/master/pkg/printers to see if we can re-use it, however this would add dependency on kube-versioned packages. I think we don't want that ? |
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.
So, I still have some trouble with the approach here. I'd like to see something that enables us to reuse some of the resource printing capabilities of k8s.io genericclioptions, and not have to reimplmeent that from scratch. That means using some of their interfaces, like before. I've linked them below in other comments.
// See the License for the specific language governing permissions and | ||
// limitations under the License. | ||
|
||
package printers |
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.
pkg/util or pkg/util/printers?
@@ -0,0 +1,30 @@ | |||
// Copyright © 2018 The Knative Authors |
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.
I'm not in love with "util" as a name of things. it seems like the thing people name a bin where they stick things they don't know where else to put.
@@ -0,0 +1,34 @@ | |||
// Copyright © 2018 The Knative Authors |
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.
I'd love pkg/output or pkg/printing or something.
return nil | ||
} | ||
// if no output format flag is set, lets print the human readable output | ||
printer := printers.NewTabWriter(cmd.OutOrStdout()) |
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.
This needs to be a printer
, implementing the interface here: https://github.com/kubernetes/cli-runtime/blob/master/pkg/printers/interface.go#L34
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.
This is a solved problem for kubectl and the human-friendly printer implementation is in place already https://github.com/kubernetes/kubernetes/blob/master/pkg/printers/tableprinter.go#L49 ,
however its not importable (or we don't want k8s dep) as genericclioptions.
A bunch of utilities can be re-used though from pkg/printers
(re-use = borrow the code?), and we'll just need to add the column-definitions and their printing logic as done here
https://github.com/kubernetes/kubernetes/blob/master/pkg/printers/internalversion/printers.go#L79 for resources operable via kn.
WDYT?
Cc: @bbrowning @rhuss
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.
@navidshaikh If there are no efforts underway to port that part to cli-runtime anyway, I would try to move that tableprinter stuff to kn
in an isolated way and if this is successful, create a PR for cli-runtime so that we could use it from there eventually. It depends on the size of the code to move around and how easy it is to isolate it, but I think this could be a strategy from which everyone could benefit.
We could do it the other way round (first move it to cli-runtime), but this is (a) doesn't help for kn
in the short term and (b) if we fail at cli-runtime, the effort is wasted. That's not the case with the first approach where the only danger is, that we would have to maintain the ported code on our own.
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.
@rhuss : makes sense, lets move ahead with first approach as you mentioned.
This commit adds basic details about service in service list command output. text/tabwriter is used to print columns on stdout. Fixes #knative#40
This commit adds AGE column representing the resources' age in human readable format calculated from CreationTimestamp field of service.
Now if list is empty, we print "No resources found." string. This commit updates the respective unit test.
Doesn't check the argument length after `service get` to leave room for filtering based on argument.
Closing in favor of #90 |
The remote caching jobs are not configured, and anyway Knative is not using bazel to the point that remote caching is a benefit. Disable it to avoid spurious error messages in the test logs.
This changeset adds basic details about service in
service get command output.
text/tabwriter is used to print columns on stdout.
Fixes ##40