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 <e...@oddments.org> 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 > _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
