Open Stack

On Tue, Dec 20, 2016 at 2:11 PM, Dean Troyer <dtroyer at gmail.com> wrote:
>
> 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.

I *think* I understood this - the server command is representative of a
server resource, not a service.  It's somewhat circumstantial that often
times when you think about the top level base primitive resources OpenStack
provides cloud users - that they occasionally align with a single service
API endpoint.  But a big design goal for a unified client seems like it
might hopefully help abstract the services away so the user can focus on
their "stuff" ;)

>'object store container' would be consistent, 'object store object' is
awful.

Fully agree, would suggest:

"object <action>"
"object container <action>"
"object account <action>"

I think this follows closely where the other resource commands are going?

>
> 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).

I had not noticed the backup command, or flavor, thank you for pointing
those out.  This is excellent news!

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

Seems reasonable to me!  AIUI the top level "object" resource would stay,
it would grow "container" & "account" sub resources, and the "object store
account" and "container" top-level commands would be deprecated.  Then
during the development of the release after a release which includes those
changes you could start to remove the deprecated interfaces.

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