openstack team mailing list archive

[Jay Pipes <jaypipes@xxxxxxxxx>]

OK, now I understand you a bit better about the URI naming scheme.
Thanks for your explanation/clearing it up.

Cheers!
jay

On Thu, Feb 10, 2011 at 12:05 PM, Eric Day <eday@xxxxxxxxxxxx> wrote:
> 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
>