On 03/20/2017 08:16 PM, Dean Troyer wrote: > 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 :)
Which Austin summit - haven't we been at two together now?. ;) >> 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'. Yes - that's an excellent example. I think one of the most important thing to realize is that our project organization is much less interesting to our API consumers than it is to developers and operators. _especially_ when some things move their project home over time. (is it compute floating-ip? is it network floating-ip?) And that a single project could have more than one thing that is similar in different contexts (we have both a ComputeUsage and a ServerUsage - with ServerUsage being the usage for a specific server while ComputeUsage is the aggregate compute usage for a project) Yay naming! __________________________________________________________________________ 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