openstack team mailing list archive

[Eric Day <eday@xxxxxxxxxxxx>]

On Wed, Feb 09, 2011 at 08:00:02PM -0500, Jay Pipes wrote:
> > There is other common functionality we should consider for OpenStack
> > services. We don't need anything too formal, just a "best practices"
> > document that can change with time. This will hopefully also drive
> > openstack-common projects for chosen languages so we can encourage
> > code sharing between projects (although not required).
> 
> Heh, good luck on this one. It's like:
> 
> * herding cats
> * pulling teeth
> * getting developers to agree on something
> 
> All of which are similar to each other.

We don't need to do much here, I think community requirements will
drive much of this naturally (ie, I want swift and nova to use
the same auth system). As we've seen already projects won't always
share similar code, and there are legitimate cases for not sharing,
so there is no reason trying to enforce anything like that. All we
can do is encourage where it makes sense. :)

> >  The URI does imply a dotted hierarchy in order to perform suffix
> >  matching (for example, zone cage1.dc1.north.service.com would
> >  match for *.north.service.com requests). We could keep this field
> >  completely free-form and make the location generation/matching
> >  pluggable, but URIs seem to be pretty ubiquitous. DNS entries for
> >  these URIs are possible but not required.
> 
> The main thing I feel is problematic with the above: a zone does not
> imply any sort of location at all. No geographic location or
> inter-datacenter location is implied for a zone. A zone can just as
> easily be a set of hosts or a set of geographically-associated zones
> that have a specific service-level agreement defined for them.
> 
> In other words, a Zone is merely a container of hosts or other zones.
> Nothing more :)

I agree. I was using location-based names as an example, but I should
have stated a URI does not need to imply geographic location. You
could still have zones named 'erics_cloud.foo', 'jays_cloud.foo',
and 'bar' and I can ask for new instances in '*' (put it anywhere),
'*.foo' (put it somewhere under 'foo'), or 'jays_cloud.foo'. Just
think of all the various schemes folks have modeled on top of DNS.

So I am only proposing enforcing a hierarchy for zone and object naming
modeled after DNS since that is a well known and proven standard,
nothing more. Folks who are concerned about geographic location (and
I suspect many will be) can leverage this to solve those locality
problems easily, but there is no reason your hierarchy names need to
imply location.

As we build up large, complex zone configurations, a hierarchy will
really help organize things and allow us to create/leverage efficient
routing algorithms (not keep one giant lookup table for all things).

> > * Firehouse - So far we've not discussed this too much, but I
> 
> Firehose I assume? :)

Hehe, yeah :)

-Eric