Comments (14)
I think one thing I don't like about kubectl is the fact that get
works on two different cardnalities.
Operation | Cardnality | kubectl | current kn |
---|---|---|---|
Summary | One | get |
n/a |
Summary | Many | get |
list |
Detail | One | describe |
describe |
Detail | Many | n/a | n/a |
from client.
/milestone v0.1.0
from client.
@csantanapr: You must be a member of the knative/knative-milestone-maintainers github team to set the milestone.
In response to this:
/milestone v0.1.0
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.
from client.
@csantanapr : what information about <service_name>
should be printed in this command ?
How does this defer from kn service list
?
If we can list the data points to be provided by CLI for these two commands, it should help.
from client.
I would like to suggest to combine kn service list
and kn service get
to a single command kn service get
for the following reasons:
- It reduces the UX surface by having one subcommand less. This is IMO always a good thing.
kn service get
without argument can just list all services. - It mimics the behaviour of
kubectl get
wherekubectl get
without argument just list all resources. So having onlykn service get
also follows the Principle of least astonishment which is a good thing.
Wdyt ?
If there are no objections, I'd like to start working on kn service get
from client.
Another argument for having a single 'kn service get' for listing and showing is a typical ux flow:
- List all service available
- Then: Select a single service to get details.
So you can call 'kn service get', check the output, cursor up for one step back in shell history and then just add the service of interest to the end of the command.
from client.
@rhuss downside to combining list and get is that i imagine output format would be quite different. list i imagine is more compact whereas get would show more detailed information.
from client.
I like having different list and single-object describe commands. Get vs describe, no particluarly strong opinion about the single-object one, but I do like describe.
from client.
@sixolet +1, I think too that we should distinguish between get
and describe
a la kubectl.
I think we could just rename kn service list
to kn service get
and allow an argument for filtering on the list. That would be similar to kubectl get
(and hence less surprising).
kn service describe
would be reserved then for a detail view of a single service.
Wdyt ?
Of course it depends how close we want to follow a UX like for kubectl. I think it would be good to stay close to its UX (get
for list/summary like info, describe
for details) because people know this already. On the other hand when changing to something new, then I would do it for all verbs. I.e. change also describe
to something else, like show
or info
(so, list
for list/summary and show
for details, new
for create).
from client.
@rhuss downside to combining list and get is that i imagine output format would be quite different. list i imagine is more compact whereas get would show more detailed information.
@cppforlife I'm not sure whether the output format should be different, if we want to keep the semantics of get
in kubectl (which actually is a list command there).
Operation | kubectl style | kn style | alternate style |
---|---|---|---|
Summary info | get |
list |
list |
Details info | describe |
describe / (get now ?) |
show |
from client.
I suggest #75 for the start of implementation for this issue with kn service describe
is about presenting the detail information (instead of kn service get
).
from client.
(I'm ok with implementing a single-target summary information printing command, but it should be different from the many-target summary-information printing command)
from client.
(I'm ok with implementing a single-target summary information printing command, but it should be different from the many-target summary-information printing command)
For get
(or list
right now) we are supporting the printing option -o
from cli-runtime, which treats single entities and a list of entities the same as it e.g. for yaml/json exports either a single object or a list of objects, but with the same content. Same for -o name
.
In that sense and for staying consistent, I tend to lean to keep the one and many information the same also for 'human readable' output for kn get
(i.e. using a list with a single entry).
What would be a plus though would be to allow multiple and wildcard arguments for kn service get
to filter the list (see #71 )
from client.
Done by #90
from client.
Related Issues (20)
- Issues with go-licenses HOT 4
- Add support for different volume types HOT 6
- Can't create private service using --no-cluster-local HOT 3
- Add `url` option for `kn service list --output` HOT 2
- Add support for providing sink spec in GVR format
- Add config option to specify `readOnly` volumes HOT 2
- Add `--scale-activation` flag to match new Serving option HOT 5
- Option to specify Node Selector HOT 2
- support uninstallation of local cluster using kn HOT 6
- Compile errors with Go 1.20 HOT 2
- kn does not show new trigger filters HOT 2
- Service export should handle securityContext field HOT 12
- Missing example of fully qualified GVR in`--sink` flag HOT 3
- Eventing TLS: support Eventing TLS in kn-plugin-event HOT 5
- `kn trigger update --help` information is incorrect HOT 2
- CLI: Add support for EventType v1beta2 HOT 6
- CLI: add support for experimental new filters API in trigger HOT 4
- Ability to set toleration, affinity and node selector HOT 10
- 48h Knative - A Hackathon-Style Event
- Remove deprecated `--inject-broker` flag from `trigger` cmds HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from client.