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

[Jiho Hahm]

This is related to my earlier post where I asked about
start/stop ordering.

I have a setup where my application code is installed on a
SAN volume.  Furthermore, the data directory appears as a
subdirectory of install root but is actually on another SAN
volume.  Taking Apache as an example, let's say it's
installed under /opt/apache and web pages are under
/opt/apache/htdocs.

The directories correspond to devices like this:

/dev/sda1 - /opt/apache
/dev/sdb1 - /opt/apache/htdocs

To start Apache I need to first mount /dev/sda1, then mount
/dev/sdb1, and finally invoke /opt/apache/bin/apachectl
start.  To stop I would do things in reverse. 
Particularly, I can't unmount /opt/apache before unmounting
/opt/apache/htdocs.  (rgmanager doesn't deal with failed
umounts well.)

In cluster.conf, this dependency can be expressed like
this:

    <resources>
        <fs name="/opt/apache" device="/dev/sda1" ... />
        <fs name="/opt/apache/htdocs" device="dev/sdb1" ...
/>
        <script name="apachectl"
                file="/opt/apache/bin/apachectl"/>
    </resources>
    <resourcegroup name="rg1">
        <fs ref="/opt/apache">
            <fs ref="/opt/apache/htdocs">
                <script ref="apachectl"/>
            </fs>
        </fs>
    </resourcegroup>

This is currently not possible because the only child
resource type allowed inside <fs> is <nfsexport>.  But the
rule can be easily changed by adding:

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

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

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

-Jiho


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com