Closed emk closed 7 years ago
I like the third option the best. I think it covers the 80% usage case.
Well, my proposal is that we really need to support all three: pod only, service only, or either a pod or a service. We have examples of all three commands, and if we try to force everything into one scheme, we'll need to think through issues in the implementation very carefully, because not all commands naturally have the ability to work on both
Our current argument convention looks like this:
Nobody likes typing
<pod> <service>
, especially when service names are often globally unique. Additionally, therun
command needs some way to specify a pod normally, but to also allow the specification of a service. Andlogs
(#7) raises some design issues of its own.After some discussion with @dkastner, we'd like to propose three argument types:
<pod>
, for commands which can only accept a pod.<service>
, for commands which can accept a service. This can be specified as either$POD/$SERVICE
, or if the service name is unique, just$SERVICE
.<pod_or_service>
looks for$POD
,$POD/$SERVICE
and a unique$SERVICE
, in that order.With this design, our subcommands would look like:
Comments and feedback are welcome!