You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@etch.apache.org by scott comer <sc...@cisco.com> on 2009/02/02 15:52:02 UTC
naming service again...
it was pointed out to me by james that the name service was a bit
confused in its roll by mixing up the idea of
name translation with the ideas of failover, replication, clustering,
and grouping of services. while those ideas
are important in a distributed system, they deserve their own specific
treatment and should not be part of the
name service itself. (replication of name servers itself is needed, but
subject to a different discussion.)
manoj and i reviewed the proposal for name service and struck the
requirements that were specifically not
related to implementing a basic name service. while replication of a
name service is still important, and
ought to be present, we feel we could make a good first cut without the
specific requirement and then see
where we can go.
so we adjusted the proposal and fiddled the wording a bit to account for
the shift in focus:
http://cwiki.apache.org/ETCH/etch-name-service.html
here are the important design principles as we see them:
1) a service or application should not have be overtly aware of the name
service. it should be possible to
deploy a service or application with or without the name service, with
no conditional code or changes
to code. thus use of a name service is purely a deployment consideration
and is not required.
2) the name service should be supportable in a variety of styles or
modes without changing the
fundamental functional interface. indeed, the basic contract should be
very simple.
we've not updated the ns.etch file to match yet. probably today.
thoughts? ideas? over the next few days manoj and i will publish some
call flows and code snips to
illustrate these ideas.
scott out
Re: naming service again...
Posted by James Dixson <di...@gmail.com>.
I think in my mind I was thinking in terms of a very simple
policy/default-preference role in NameService, vs. a specific syntax.
The idea being that the minimum request of the NS should be for 'api'
and then everything else is essentially a query for a specific
instance of that api.
The URI
etch:api - any instance or scheme is acceptable
would defer to the nameserver the responsibility to selecting in
instance and scheme for the api. Whereas as URIs like
Exactly 'foo' instance of 'api' using 'tcp' scheme
etch:api/foo/tcp
Exactly 'foo' instance of 'api', prefer 'tls' but will accept 'tcp'
etch:api/foo/tls,tcp
etch:api/foo/tls?altname=api/foo/tcp
etch:api/foo?scheme=tls,tcp
Any instance of 'api', but only accept 'tls' scheme
etch:api?scheme=tls
constrains the nameserver response based on the preferences of the client.
I am not advocating policy enforcement etc, just trying to draw the
demarcation between the minimum request to the ns and then a
convention for a standard set of query params.
--
james
On Mon, Feb 2, 2009 at 11:42 AM, scott comer (sccomer)
<sc...@cisco.com> wrote:
> agreed, there is a distinction between the format of a name and it's
> significance to the
> name server and how the api might use it. in fact, the name is just a
> string, it can have
> whatever significance we want. but when you specify a certain name, it has
> significance
> only to the target name service and none other.
>
> still, for compatibility between name services and to avoid confusion
> between users
> it seems like we ought to narrow it down slightly.
>
> i was thinking about the significance of scheme on the way in. i might
> reasonably have
> two schemes based on tls, one with different filters, for example. i think
> the scheme
> perhaps doesn't need to be one to one with an actual scheme, but perhaps
> just a
> qualifier on instance name.
>
> so let's suppose this format (though you could use any format that your ns
> supports):
>
> api[/inst[/qual]]
>
> where inst count be inst1[,inst2...]
>
> and qual could be qual1[,qual2...]
>
> in either case, what we are suggesting here is again the notion of search.
> shouldn't this
> be better specified some other way?
>
> consider this:
>
> api/foo,bar/tls,tcp
>
> it is a nice compact way to express this:
>
> api/foo/tls
> api/foo/tcp
> api/bar/tls
> api/bar/tcp
>
> though that is somewhat ambiguous. you might prefer this order:
>
> api/foo/tls
> api/bar/tls
> api/foo/tcp
> api/bar/tcp
>
> what might work better would be this:
>
> etch:api/foo/tls?altname=api/bar/tls,api/foo/tcp,api/bar/tcp
>
> this eliminates the idea that a name might have wildcarding, while still
> allowing for the
> idea of an alternate address. this already mirrors something i'd like to see
> with tcp
> scheme:
>
> tcp://foo:8090?alt=bar:8090
>
> how do you interpret this:
>
> etch://ns1:8090/api/foo/tls?altname=api/bar/tls,api/foo/tcp,api/bar/tcp?alt=ns2:8090
>
> contact ns1 to translate the names, if ns1 offline use ns2. hmmm. what
> scheme should
> we use for contacting the ns?
>
> how about this:
>
> etch:api/foo/tls?altname=api/bar/tls,api/foo/tcp,api/bar/tcp?ns=tcp://ns1:8090,tcp://ns2:8090
>
> scott out
>
> James Dixson wrote:
>>
>> What if I do not know/care about the instance name or connection
>> scheme at runtime. The URI:
>>
>> etch://<name_service_ip:port>/<api>/<instance>/<scheme>
>>
>> Both the <instance> and <scheme> path elements seem as if they should
>> be both optional and, as suggested by 'tcp,tls", tuples. So a service
>> URI could be as simple as:
>>
>> etch:<api> (or maybe also etch:///<api> ) --
>> etch:///etch.examples.perf.Perf
>> etch:etch.examples.perf.Perf
>>
>> etch:<api>/<instance> --
>> etch:etch.examples.perf.Perf/foo
>> etch.etch.examples.perf.Perf/foo,bar
>>
>> etch:<api>/<instance>/<scheme> --
>> etch:etch.examples.perf.Perf/foo/tcp
>> etch:etch.examples.perf.Perf/foo,bar/tcp
>> etch:etch.examples.perf.Perf/foo/tcp,tls
>> etch:etch.examples.perf.Perf/foo,bar/tcp,tls
>>
>>
>>
>> --
>> james
>>
>>
>>
>> On Mon, Feb 2, 2009 at 8:52 AM, scott comer <sc...@cisco.com> wrote:
>>
>>>
>>> it was pointed out to me by james that the name service was a bit
>>> confused
>>> in its roll by mixing up the idea of
>>> name translation with the ideas of failover, replication, clustering, and
>>> grouping of services. while those ideas
>>> are important in a distributed system, they deserve their own specific
>>> treatment and should not be part of the
>>> name service itself. (replication of name servers itself is needed, but
>>> subject to a different discussion.)
>>>
>>> manoj and i reviewed the proposal for name service and struck the
>>> requirements that were specifically not
>>> related to implementing a basic name service. while replication of a name
>>> service is still important, and
>>> ought to be present, we feel we could make a good first cut without the
>>> specific requirement and then see
>>> where we can go.
>>>
>>> so we adjusted the proposal and fiddled the wording a bit to account for
>>> the
>>> shift in focus:
>>>
>>> http://cwiki.apache.org/ETCH/etch-name-service.html
>>>
>>> here are the important design principles as we see them:
>>>
>>> 1) a service or application should not have be overtly aware of the name
>>> service. it should be possible to
>>> deploy a service or application with or without the name service, with no
>>> conditional code or changes
>>> to code. thus use of a name service is purely a deployment consideration
>>> and
>>> is not required.
>>>
>>> 2) the name service should be supportable in a variety of styles or modes
>>> without changing the
>>> fundamental functional interface. indeed, the basic contract should be
>>> very
>>> simple.
>>>
>>> we've not updated the ns.etch file to match yet. probably today.
>>>
>>> thoughts? ideas? over the next few days manoj and i will publish some
>>> call
>>> flows and code snips to
>>> illustrate these ideas.
>>>
>>> scott out
>>>
>>>
>>>
>>>
>
Re: naming service again...
Posted by "scott comer (sccomer)" <sc...@cisco.com>.
agreed, there is a distinction between the format of a name and it's
significance to the
name server and how the api might use it. in fact, the name is just a
string, it can have
whatever significance we want. but when you specify a certain name, it
has significance
only to the target name service and none other.
still, for compatibility between name services and to avoid confusion
between users
it seems like we ought to narrow it down slightly.
i was thinking about the significance of scheme on the way in. i might
reasonably have
two schemes based on tls, one with different filters, for example. i
think the scheme
perhaps doesn't need to be one to one with an actual scheme, but perhaps
just a
qualifier on instance name.
so let's suppose this format (though you could use any format that your
ns supports):
api[/inst[/qual]]
where inst count be inst1[,inst2...]
and qual could be qual1[,qual2...]
in either case, what we are suggesting here is again the notion of
search. shouldn't this
be better specified some other way?
consider this:
api/foo,bar/tls,tcp
it is a nice compact way to express this:
api/foo/tls
api/foo/tcp
api/bar/tls
api/bar/tcp
though that is somewhat ambiguous. you might prefer this order:
api/foo/tls
api/bar/tls
api/foo/tcp
api/bar/tcp
what might work better would be this:
etch:api/foo/tls?altname=api/bar/tls,api/foo/tcp,api/bar/tcp
this eliminates the idea that a name might have wildcarding, while still
allowing for the
idea of an alternate address. this already mirrors something i'd like to
see with tcp
scheme:
tcp://foo:8090?alt=bar:8090
how do you interpret this:
etch://ns1:8090/api/foo/tls?altname=api/bar/tls,api/foo/tcp,api/bar/tcp?alt=ns2:8090
contact ns1 to translate the names, if ns1 offline use ns2. hmmm. what
scheme should
we use for contacting the ns?
how about this:
etch:api/foo/tls?altname=api/bar/tls,api/foo/tcp,api/bar/tcp?ns=tcp://ns1:8090,tcp://ns2:8090
scott out
James Dixson wrote:
> What if I do not know/care about the instance name or connection
> scheme at runtime. The URI:
>
> etch://<name_service_ip:port>/<api>/<instance>/<scheme>
>
> Both the <instance> and <scheme> path elements seem as if they should
> be both optional and, as suggested by 'tcp,tls", tuples. So a service
> URI could be as simple as:
>
> etch:<api> (or maybe also etch:///<api> ) --
> etch:///etch.examples.perf.Perf
> etch:etch.examples.perf.Perf
>
> etch:<api>/<instance> --
> etch:etch.examples.perf.Perf/foo
> etch.etch.examples.perf.Perf/foo,bar
>
> etch:<api>/<instance>/<scheme> --
> etch:etch.examples.perf.Perf/foo/tcp
> etch:etch.examples.perf.Perf/foo,bar/tcp
> etch:etch.examples.perf.Perf/foo/tcp,tls
> etch:etch.examples.perf.Perf/foo,bar/tcp,tls
>
>
>
> --
> james
>
>
>
> On Mon, Feb 2, 2009 at 8:52 AM, scott comer <sc...@cisco.com> wrote:
>
>> it was pointed out to me by james that the name service was a bit confused
>> in its roll by mixing up the idea of
>> name translation with the ideas of failover, replication, clustering, and
>> grouping of services. while those ideas
>> are important in a distributed system, they deserve their own specific
>> treatment and should not be part of the
>> name service itself. (replication of name servers itself is needed, but
>> subject to a different discussion.)
>>
>> manoj and i reviewed the proposal for name service and struck the
>> requirements that were specifically not
>> related to implementing a basic name service. while replication of a name
>> service is still important, and
>> ought to be present, we feel we could make a good first cut without the
>> specific requirement and then see
>> where we can go.
>>
>> so we adjusted the proposal and fiddled the wording a bit to account for the
>> shift in focus:
>>
>> http://cwiki.apache.org/ETCH/etch-name-service.html
>>
>> here are the important design principles as we see them:
>>
>> 1) a service or application should not have be overtly aware of the name
>> service. it should be possible to
>> deploy a service or application with or without the name service, with no
>> conditional code or changes
>> to code. thus use of a name service is purely a deployment consideration and
>> is not required.
>>
>> 2) the name service should be supportable in a variety of styles or modes
>> without changing the
>> fundamental functional interface. indeed, the basic contract should be very
>> simple.
>>
>> we've not updated the ns.etch file to match yet. probably today.
>>
>> thoughts? ideas? over the next few days manoj and i will publish some call
>> flows and code snips to
>> illustrate these ideas.
>>
>> scott out
>>
>>
>>
>>
Re: naming service again...
Posted by James Dixson <di...@gmail.com>.
What if I do not know/care about the instance name or connection
scheme at runtime. The URI:
etch://<name_service_ip:port>/<api>/<instance>/<scheme>
Both the <instance> and <scheme> path elements seem as if they should
be both optional and, as suggested by 'tcp,tls", tuples. So a service
URI could be as simple as:
etch:<api> (or maybe also etch:///<api> ) --
etch:///etch.examples.perf.Perf
etch:etch.examples.perf.Perf
etch:<api>/<instance> --
etch:etch.examples.perf.Perf/foo
etch.etch.examples.perf.Perf/foo,bar
etch:<api>/<instance>/<scheme> --
etch:etch.examples.perf.Perf/foo/tcp
etch:etch.examples.perf.Perf/foo,bar/tcp
etch:etch.examples.perf.Perf/foo/tcp,tls
etch:etch.examples.perf.Perf/foo,bar/tcp,tls
--
james
On Mon, Feb 2, 2009 at 8:52 AM, scott comer <sc...@cisco.com> wrote:
> it was pointed out to me by james that the name service was a bit confused
> in its roll by mixing up the idea of
> name translation with the ideas of failover, replication, clustering, and
> grouping of services. while those ideas
> are important in a distributed system, they deserve their own specific
> treatment and should not be part of the
> name service itself. (replication of name servers itself is needed, but
> subject to a different discussion.)
>
> manoj and i reviewed the proposal for name service and struck the
> requirements that were specifically not
> related to implementing a basic name service. while replication of a name
> service is still important, and
> ought to be present, we feel we could make a good first cut without the
> specific requirement and then see
> where we can go.
>
> so we adjusted the proposal and fiddled the wording a bit to account for the
> shift in focus:
>
> http://cwiki.apache.org/ETCH/etch-name-service.html
>
> here are the important design principles as we see them:
>
> 1) a service or application should not have be overtly aware of the name
> service. it should be possible to
> deploy a service or application with or without the name service, with no
> conditional code or changes
> to code. thus use of a name service is purely a deployment consideration and
> is not required.
>
> 2) the name service should be supportable in a variety of styles or modes
> without changing the
> fundamental functional interface. indeed, the basic contract should be very
> simple.
>
> we've not updated the ns.etch file to match yet. probably today.
>
> thoughts? ideas? over the next few days manoj and i will publish some call
> flows and code snips to
> illustrate these ideas.
>
> scott out
>
>
>