Command-line parameters should be improved

[Yancey1989]

As the discussing in the meeting, maybe we should add some subcommands for the current command-line parameters according to different resource. Here is some ideas:

• Job

paddlecloud job list # list all job 
paddlecloud job logs <job name> # fetch all trainers' log
paddlecloud job get <job name> # describe a job 

• Quota

paddlecloud quota list

• File

paddlecloud file ls 
paddlecloud file get/put

• Trainer

paddlecloud trainer ls -job <job name> # list all trainers for the specify job
paddlecloud trainer get <trainer name>
paddlecloud trainer logs <trainer name>

[gongweibao]

参考kubernets的风格，动词在前可能会更好一点？

paddlecloud verb resource-type 

verb可以是create logs get delete describe等

例如：

• get resource

paddlecloud get jobs
paddlecloud get quotas 
# worker相当于kubernets的pod的概念。是一个执行体。
# trainer, pserver, master, infer server 都是worker
paddlecloud get workers

• describe a resource

paddlecloud describe job job-name 
paddlecloud describe worker worker-name 

• logs

paddlecloud logs worker worker-name
paddlecloud logs job job-name

虽然文件也是一种资源，但是他不只是在cloud端，动词属性和只在cloud端的resource有区别。
如ls mkdir rm可以分别变成describe create delete 和上边的对资源的管理保持一致，cp好像不行。文件的动词可以和上边的都不同，这样就可以不用指定resource type而直接使用。

paddlecloud  ls
paddlecloud  mkdir
paddlecloud  rm
paddlecloud  cp

另外一种选择是把pfs的操作客户端和paddlecloud命令分开为两个，如：

pfs ls

[typhoonzero]

的确，包含"sub-command"的程序总体看大部分的command line的设计都遵守：

$ [command] [verb] [target...] [options]

的规范，比如：git clone, git checkout, pip install, kubectl create, docker pull, yum list。

不实用"sub-command"的unix命令基本也都是一些动词，比如：ls, mkdir, kill。

另外一种选择是把pfs的操作客户端和paddlecloud命令分开为两个，如：

赞同这种方式。其实hadoop的命令的设计是比较奇葩的，个人觉得可以不必参考。

[helinwang]

赞大家的思考！

我比较倾向于subcommand的形式，subcommand是名词动词都可，如：

$ go help
Usage:

	go command [arguments]

The commands are:

	build       compile packages and dependencies
	clean       remove object files
	doc         show documentation for package or symbol
	env         print Go environment information
	bug         start a bug report
	fix         run go tool fix on packages
	fmt         run gofmt on package sources
	generate    generate Go files by processing source
	get         download and install packages and dependencies
	install     compile and install packages and dependencies
	list        list packages
	run         compile and run Go program
	test        test packages
	tool        run specified go tool
	version     print Go version
	vet         run go tool vet on packages

好处是有很明显的分类，go build就全都是build相关的，help也容易：go build help就全都是build相关的，pcloud trainer help就全都是trainer相关的。反过来讲，要是用pcloud get help，只能说get能够get些什么，而无法说清楚trainer相关的命令是啥。
我觉得k8s用kubectl get object的原因是他们有很多可变的但是有共性的object(pod, replication controller, deployment, service)，可以统一处理。我们的这个情况感觉其实object就几个，是不是可以考虑按subcommand的方式更容易理解。

[typhoonzero]

另外一种选择是把pfs的操作客户端和paddlecloud命令分开为两个，如：

补充：后来想了下，分成两个命令还是不合适，这样用户得下载两个二进制了。只下载一个二进制直接执行还是会简单很多。

[Yancey1989]

我比较倾向于subcommand的形式，subcommand是名词动词都可，如：

不限制subcommand为动词确实可以稍微灵活一些，PFS的命令也可以整合进来，例如：
pcloud pfs [ls|put|get|rm...] [path1|path2...]

[helinwang]

@Yancey1989 Thanks for leading the discussion! Could we have a summarization of what have we decided on? (is the design doc #291 up to date?)

[Yancey1989]

@helinwang , sorry for delay updating, I have some commands in #291 (comment), thanks for your reveiw!