From: Steve Martinelli [mailto:s.martine...@gmail.com] Sent: December-20-16 5:09 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [osc][openstackclient][zun] Collision on the keyword 'container'
On Tue, Dec 20, 2016 at 4:39 PM, Clay Gerrard <clay.gerr...@gmail.com<mailto:clay.gerr...@gmail.com>> wrote: On Tue, Dec 20, 2016 at 1:00 PM, Hongbin Lu <hongbin...@huawei.com<mailto:hongbin...@huawei.com>> wrote: $ openstack objectstore container <action> <args> $ openstack container container <action> <args> $ openstack secret container <action> <args> Thoughts? This is the closest thing I can see that's somewhat reasonable - with the obvious exception of "container container <action>" - which is pretty gross. Here's the best list I could find of what's going on now: 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". 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?! This was my initial thought when discussing the problem with Hongbin last night. We have three main "swift" resources in OSC -- "object store account", "container" and "object". I think renaming "container" to "object store container" is totally acceptable. The issue of deprecation comes into play, we'll need to deprecate it and give it at least one cycle. Luckily, the zun team isn't ready to publish a CLI just yet. Alternatively, I don't mind "appcontainer". [Hongbin Lu] I am going to propose ‘appcontainer’ to Zun team. It looks like a good alternative to me.
__________________________________________________________________________ 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
