On Thu, Feb 24, 2011 at 4:06 PM, Eric Day <e...@oddments.org> wrote: > On Thu, Feb 24, 2011 at 03:48:25PM -0500, Jay Pipes wrote: >> 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. > > Completely agree. :)
Cool. Was starting to lose my mind thinking people *really* wanted to duplicate the eucatools mess... >> 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. > > Yup, agree. Also keep in mind that some operations may be duplicates > across services, just with a different context. For example, > in a deployment where you use glance backed by swift for nova, > os-compute describe image <id> may be the same as os-image describe > <id> or os-object describe <id> (swift), but the os-compute is in > the context of instances so it could have more metadata. This will > mirror the dependency tree we see between services (especially as > they are split out). ++ > We want to make sure there are tools so services can stand alone as > needed (for example, os-image if you run glance standalone). Services > that combine other services (like nova) should aggregate these into > context-specific commands so you don't *need* to use the underlying > service tools for most things. This allows you to control nova use > one tool. :) No disagreement from me. -jay p.s. thx for not sending me to /dev/null ;) _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp