Re: Scalability & daughterships

>>	% export CRMOTHER=host:port  	# where is my mother?
>>	% export CRMOTHERSHIP=host:port	# what "mothership" should I look like?
>>	% python .../cr/mothership/server/daughtership.py 
> 
> 
> I'm not clear on the purpose of adding the CRMOTHER environment variable.  In 
> the daughtership's environment CRMOTHERSHIP should presumably be the 
> daughter's mother.  The only remaining question is what port number the 
> daughership should open for incoming requests.  In the current implementation, 
> I think the mothership picks the port based on the parameter to CR.Go(), 
> doesn't it?

The "interesting" syntax is provided to match the current use of CRMOTHERSHIP, 
which is not only used by the servers, but also by the mothership herself (to 
configure her listening port).

The daughtership will contact a mothership, read a configuration, and then 
execute just as a mothership would - including reading the CRMOTHERSHIP variable 
in order to determine which port to set herself up on.  Clearly, we can't have 
both mothership and daughtership setting themselves up on the same port; so 
either we add a variable to configure the "extra" values that the daughtership 
needs that the mothership does not (i.e., the address of the mothership to 
contact), or the daughtership changes the value of CRMOTHERSHIP in the 
environment before executing.

Three options:
- Maintain the utility of CRMOTHERSHIP for configuring daughterships, and add a 
new variable for identifying the true mothership (current implementation)
- Maintain the utility of CRMOTHERSHIP for identifying a mothership to contact, 
and add a new variable for configuring the daughtership
- Deprecate the use of CRMOTHERSHIP for configuring daughterships (all other 
current utility remains); use CRMOTHERSHIP to identify the parent, and otherwise 
require the daughtership to be fully configured (perhaps via command line options).

I'm open for any.

> Here is another question to consider: how does a node pick which mothership to 
> talk to?  Is there any interest in being able to say something like:
> 
> setenv CRMOTHERSHIP "node1:1234,node2:5678,node3:1324"
> 
> to specify that the Node has a variety of choices?  I could live without it, 
> but some piece of software somewhere has to get smart enough to choose.  That 
> could be the Node code itself, or it could be whatever I write that spawns the 
> Node process.

The clients would have to define a policy for which mothership is preferred, 
which in some cases would be pretty clear, but in other cases rather murky.  I'd 
rather leave this to config files.

Bob Ellison
Tungsten Graphics, Inc.



-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click