Open Stack

On Tue, Dec 20, 2016 at 1:00 PM, Hongbin Lu <hongbin.lu at huawei.com> wrote:

>
>
> $ openstack objectstore container <action> <args>
>
> $ openstack container container <action> <args>
>
> $ openstack secret container <action> <args>
>
>
>
> Thoughts?
>

This is the closest thing I can see that's somewhat reasonable - with the
obvious exception of "container container <action>" - which is pretty gross.

Here's the best list I could find of what's going on now:

http://docs.openstack.org/developer/python-openstackclient/command-list.html

The collision of top-level resource names is not new.  You see stuff like
"volume create" & "server create" - but also "volume backup create" &
"server backup create"- which is an obvious pattern to replicate for
disambiguating top level name conflicts with similarly named
(sub?)-resources between services - except apparently in an effort to keep
things flat no one saw it coming with a name like "container".

But IMHO an object-store "container" is not a top level OpenStack resource,
is it?  I would think users would be happy to dump stuff into the object
store using "object create" - and reasonably expect to use "object
container create" to create a container *for their objects*?  This isn't a
generic OpenStack "container" - you can't use this generic "container" for
anything except objects?  Oddly, this pattern is already in use with the
pre-existing "object store account" command?!

Is it really already too late to apply some sane organization to the object
store commands in the openstack-cli and make room in the command namespace
for a top level OpenStack resource to manage a linux-containers' service?
Because of backwards compatibility issues?

-Clay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20161220/3ff3fd69/attachment.html>