On Tue, Dec 20, 2016 at 3:39 PM, Clay Gerrard <[email protected]> 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 [email protected] __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
