<div dir="ltr"><br><br>On Tue, Dec 20, 2016 at 2:11 PM, Dean Troyer <<a href="mailto:dtroyer@gmail.com">dtroyer@gmail.com</a>> wrote:<br>><br>> This is exactly how it should work.  I do want to make an additional<br>> important but subtle point:  while it looks like those are namespaced<br>> commands, we used 'server' not 'compute' because it is not a<br>> compute-namespaced, but a server-specific resource.<div><br></div><div>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" ;)</div><div><br></div><div>>'object store container' would be consistent, 'object store object' is awful.</div><div><br></div><div>Fully agree, would suggest:</div><div><br></div><div>"object <action>"</div><div>"object container <action>"</div><div>"object account <action>"</div><div><br></div><div>I think this follows closely where the other resource commands are going?</div><div><br></div><div>><br>> Notice that in the command list lined above the 'backup' resource has<br>> been deprecated and renamed as 'volume backup'.  We could possibly<br>> also do this with 'object' and 'container' from Swift, we will be<br>> doing this with other resources (flavor -> server flavor comes to<br>> mind).</div><div><br></div><div>I had not noticed the backup command, or flavor, thank you for pointing those out.  This is excellent news!</div><div><br>><br>> Backward compatibility is very important to us though, so renaming<br>> these resources takes a long time to complete.  Freeing up the<br>> top-level bare container resource would be three cycles out at best.<br>></div><div><br></div><div>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.</div><div><br></div><div>-Clay</div></div>