Open Stack

On Tue, Dec 20, 2016 at 3:39 PM, Clay Gerrard <clay.gerrard at gmail.com> wrote:
> 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".

This is exactly how it should work.  I do want to make an additional
important but subtle point:  while it looks like those are namespaced
commands, we used 'server' not 'compute' because it is not a
compute-namespaced, but a server-specific resource.

> 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?!

'object store account' is a hack that I still hate, but due to Swift's
unique ability to not use Keystone we had to do something.  'object
store container' would be consistent, 'object store object' is awful.

> 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?

Notice that in the command list lined above the 'backup' resource has
been deprecated and renamed as 'volume backup'.  We could possibly
also do this with 'object' and 'container' from Swift, we will be
doing this with other resources (flavor -> server flavor comes to
mind).

Backward compatibility is very important to us though, so renaming
these resources takes a long time to complete.  Freeing up the
top-level bare container resource would be three cycles out at best.

dt

-- 

Dean Troyer
dtroyer at gmail.com