On Thu, Feb 24, 2011 at 2:48 PM, Eric Day <[email protected]> wrote: > Perhaps I'm missing something, but I'm not sure what you mean by > "one API". Each project/service will be driving their own API, > no? For example do you expect one CLI tool for swift, nova, and a > queue service? > > I see John's points with allowing each service to drive their own > API/tools (hopefully following some cross-project guidelines so they > are consistent), and then possibly supplying a "super tool" that allows > complex orchestration using the other tools when needed. For example: > > os-super-tool create cluster <network> <nodes> <images> ... > > This would in turn use os-compute, os-network, etc. > > We could also do some tool reflection to allow: > > os-compute <args> > > To be the same as: > > os-super-tool compute <args> > > So you can only use os-super-tool if you don't want to remember all > the others.
I just don't want to end up with: os-describe-images os-describe-image-attribute os-describe-instances os-describe-groups os-describe-zones os-describe-keypairs os-describe-volumes os-describe-snapshots The above is asinine, IMO. If you want to have an os-compute and an os-network CLI tool, cool, but I think that: os-compute describe images os-compute describe image-attribute os-compute describe instances os-compute describe groups etc... is far more workable than 15 separate CLI tools that do essentially identical things. -jay _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : [email protected] Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
