On Mon, Mar 20, 2017 at 5:52 PM, Monty Taylor <mord...@inaugust.com> wrote: >> [Hongbin Lu] >> I think the style would be more consistent if all the resources are >> qualified or un-qualified, not the mix of both.
> So - swift got here first, it wins, it gets container. The fine folks in > barbican, rather than calling a thing a container and then needing to > call it a secret-container - maybe could call their thing a vault or a > locker or a safe or a lockbox or an oubliette. (for instance) Right, there _were_ only 5 projects when we started this and we re-used most of the original project-specific names. Swift is a particularly fun one because both 'container' and 'object' are extrement useful in that context, but both are also extremely generic, and 'object container', well, what is that? > I do not have any suggestions for things that actually return a resource > that are a single "linux container" - since swift called their thing a > container before docker was written and popularized the word to mean > something different. We might just get to be fun and different - sort of > like how Emacs calls cut/paste "kill" and "yank" (if you're not an Emacs > user, you "kill" text into the kill ring and then you "yank" from the > ring into the current document. Monty, grab your Tardis and follow me around the Austin summit and listen to the opinions I get for doing things like this :) > OTOH, I think Dean has talked about more verbose terms and then aliases > for backwards compat. So maybe a swift container is always an > "object_container" - but because of history it gets to also be > unqualified "container" - but then we could have "object container" and > "secret container" and "linux container" ... similarly we could have > "server flavor" and "volume flavor" ... etc. Yes, we do have plans to go back and qualify some of these resource names to be consistent, but the current names will probably never change, we'll just have the qualified names for those who prefer to use them. Flavor is my favorite example of this as we add network flavor, and others. It also illustrates the 'it isn't a namespace' as it will become 'server flavor' rather than 'compute flavor'. dt -- Dean Troyer dtro...@gmail.com __________________________________________________________________________ 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
