On Tue, Dec 20, 2016 at 1:00 PM, Hongbin Lu <hongbin...@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
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev