[Linux-cluster] <script> and <fs> as child resource of <fs> resource

[Lon Hohberger]

Hi,

First of all: Sorry for the delay!

On Fri, 2005-02-25 at 16:44 -0800, Jiho Hahm wrote:

>     <child type="fs"/>
>     <child type="script"/>

That's fine, and shouldn't cause any problems.  You can also, of course,
use symlinks, if you're worried about it:

mount fs1 on /opt/apache
mount fs2 on /opt/htdocs
symlink /opt/apache/htdocs -> /opt/htdocs

> to /usr/share/cluster/fs.sh file.  After the change things
> work as expected.  But is that a safe change?  What are the
> ramifications?

It's a safe change.  I wouldn't make dependency loops, though ;) (Though
in the fs case, maxinstances will prevent this).

> It seems we can allow any root resource to contain children
> of any other root type.  Not every case will have a
> practical use case but many will.  For example, <ip> can be
> configured as a child of <script>, to bring up the IP
> address only when the application is ready, and to remove
> the IP address and therefore stop any more incoming clients
> before shutting down the application.

Typically user scripts which are part of cluster services should be
bound to the service IP address(es) in order to allow reuse of IP ports.
Doing this requires that the service IP be up before the application.
An application can't explicitly bind to 192.168.1.2:80 if 192.168.1.2
isn't on the system.

Starting the IP after an application will more or less prevent multiple
applications from binding to the same IP port.

Furthermore, if the application isn't binding explicitly to the
specified IPs, then clients may be able to access the application via
non-clustered IP addresses.  If the service is relocated or the node
fails, the application will appear down/dead to those clients - and it
won't recover.

Anyway, that's my $0.02 on this piece.  You are welcome to do what suits
your application.  

> What do folks think?  Are there reasons we shouldn't do
> this?

Actually, rgmanager should (soon) be able to use any non-
excluded/restricted child-types.  However, they will get started after
all specified child types to preserve ordering.

This isn't a difficult change, and it would obviate the need to alter
the resource agents to specify every possible/common use case.

This functionality is needed to support third-party "resource agents",
(which might be plugged in at any level of the tree).

-- Lon