[Spread-users] Spread as a real daemon

[John Robinson]

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
>>
>>
>