Open Stack

On 03/20/2017 08:16 PM, Dean Troyer wrote:
> On Mon, Mar 20, 2017 at 5:52 PM, Monty Taylor <mordred at 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!