ciao-cli: implement subcommands

[albertomurillo]

ciao-cli help prints all the available options without any clue of which are dependant of others.

With support for more openstack components being added like glance,cinder and swift, the list will grow even bigger without any structure.

'ciao-cli' without arguments should show the available commands. and global options

'ciao-cli command' should show the available subcommands related to 'command'

and so on until you get a clear idea of how to run the cli.

[mcastelino]

maybe something along the lines of

ciao-cli --command=launch-instances --workload=... --instances=....

[sameo]

I agree ciao-cli is going to get messy soon, and its set of options and commands needs reorganizing. I'd like to do ciao-cli [item] [command] [options], where an item is a cluster object and could be one of:

• event
• instance
• image
• node
• tenant
• workload

For each of these items we'd have a list of supported commands:

• event
  • list
  • delete
• instance
  • add
  • list
  • delete
  • restart
  • stop
• image
  • add
  • download
  • list
  • upload
• node
  • list
• tenant
  • list
• workload
  • add
  • list

And then we'd support a set of options for any (item, command) pair, e.g.

ciao-cli workload list -tenant-id 1234567890 ciao-cli instance add -workload-id 12345 -instances 200 -label foobar

[sameo]

Also, we need to keep the current behaviour working as is, i.e. we should have a legacy mode where all current calls should be supported. We want to switch to the new ciao-cli [item] [command] mode asap and thus we won't accept any new options our commands outside of that pattern.

[sameo]

@mcastelino convinced me offline that it's probably not worth it to keep the backward compatibility requirement. Let's drop it then and see how many people complain about it.

[sameo]

I'd like to see both items and commands being implemented as command interfaces:

type Command interface {
        Run(args []string) error
        Help() string
}

We'd have one file per item where the item and all commands for the item would be implemented as such interface. And then we'd have a slice mapping command strings to interface implementations

items := []struct {
        name string
        item   Command
}{
       {
              name: "instance",
              item:   instanceItem,
       },
       {
              name: "event",
              item:    eventItem,
       },
}