[Spread-users] Spread as a real daemon

[Ed Holyat]

I have had success with just adding another daemon to a conf file. 
The new machine(s) you add to the conf file will not work until the
spmonitor reload.  You can sync up all conf files or just use a shared
conf file.
Just start the additional daemon(s) with the new conf file and then
reload with spmonitor.  All is well if all daemons have the new conf
file before the reload.  

I cannot think of a good reason to join a singleton segment before
joining the final segment.


-----Original Message-----
From: spread-users-bounces at lists.spread.org
[mailto:spread-users-bounces at lists.spread.org] On Behalf Of John
Robinson
Sent: Friday, February 16, 2007 12:05 PM
To: Yair Amir
Cc: spread-users at lists.spread.org
Subject: Re: [Spread-users] Spread as a real daemon

Well, that is what I think I was trying.  Here is my experience:

OS is Linux 2.6.9-22.ELsmp x86_64.  Spread is Version 4.00.00.

1.  Start two spread daemons, each in a singleton segment:

machine A:

Spread_Segment  192.168.1.255:4803 {
      A 192.168.1.66
   }

machine B:

Spread_Segment  192.168.1.255:4803 {
      B 192.168.1.67
   }

2.  Combine them into one segment; each has equivalent definition now:

machine A and B both:

Spread_Segment  192.168.1.255:4803 {
      A 192.168.1.66
      B 192.168.1.67
   }

3.  With spmonitor, reload the config on each daemon.  Observe that
     the output from the daemons shows them reloading their configs,
     and listing two members.

4.  On each machine, display the segments with spmonitor, and observe
     that they match.

5.  Connect two spuser sessions, one to each daemon.  Have them each
     join the same group and send a message.

Problem: the two spusers do not see each other.  Despite all
indications, they are not communicating completely.  The daemon did
not exit, as pronmised, but the segment did not seem to be fully
working.

6.  Stop and restart one of the spread daemons using the combined
config.

7.  Now retry the testing with spuser, and observe that it works as 
expected.

Can you see a flaw in this procedure?  We want to avoid bouncing the
daemon so that we can avoid ceding root priveleges.

thanks,
/jr
---
Yair Amir wrote:
> John,
> 
> If you give the singleton machine its IP address and multicast address
> that you will later use, it will work. This machine will not talk with
> the others (using Spread 4 only) until you put it in the same
configuration
> file and the others' configuration file is also updated to the same.
> If you follow this approach, the daemon on the singleton machine will
> not exit. I think this should solve your problem - and that is the
> way we envisioned it to happen.
> 
> In general, if you replace the IP address / multicast address of
> a daemon, it has to exit because it does not have the same identity
> anymore. Spread is a strong-semantics messaging system and the
> semantic guarantees have to be kept even during these configuration
> changes.
> 
> Cheers,
> 
>     :) Yair.
> 
> John Robinson wrote:
> 
>> Hi all,
>>
>> We are looking to install the spread daemon as a real Linux daemon - 
>> you know, starts on reboot, can be cycled while the system is
running, 
>> detaches itself from stdin/out/err.  We can do all this with a 
>> /etc/rc.d shell script riding above it [can share this if anyone is 
>> interested]. Target platforms are RHEL4, Fedora, and SuSe, if that 
>> matters.
>>
>> Here's the issue:
>>
>> We are happily using the cluster-reconfiguration feature of Spread 
>> 4.0.  This is one problem we have bumped into:
>>
>> We would like to configure a new machine to add to the cluster by 
>> installing spread on it and starting its daemon, say with just a 
>> private Spread segment, then adding it to the existing segment with 
>> spmonitor. However, if we do this, it won't join the pre-existing 
>> segment without cycling its daemon, which requires root access, which

>> we would prefer to avoid.  In other words, if there are two separate 
>> spread segments (one the singleton new machine), and we try to get 
>> them to combine into one segment with a matched config file, it 
>> doesn't succeed.  We have thought of a way to make this work by 
>> watching for the spread.conf file to appear, and then firing up the 
>> daemon at the right time (this would be a separete daemon-watching 
>> daemon, if you will).  Doesn't seem elegant.
>>
>> What would help out here, and we have been tempted to put this into 
>> the spread daemon, is if the daemon can start with a non-existant 
>> config file (perhaps with an extra switch to say "keep running if the

>> config file isn't there yet"), and then have it just wake up 
>> periodically to wait for the config file to appear and then go
through 
>> all the rest of its initialization to join the (newly-expanded)
segment.
>>
>> Have we missed something obvious?  Has someone wrestled with this
issue?
>>
>> Many thanks; the product has been working great for us (thankfully,
we 
>> have necesary flow control =:).
>>
>> /jr
>>
>>
>> _______________________________________________
>> Spread-users mailing list
>> Spread-users at lists.spread.org
>> http://lists.spread.org/mailman/listinfo/spread-users
>>
>>
> 

_______________________________________________
Spread-users mailing list
Spread-users at lists.spread.org
http://lists.spread.org/mailman/listinfo/spread-users