On Tue, Dec 20, 2016 at 2:11 PM, Dean Troyer <dtro...@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
__________________________________________________________________________ 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
