On Wed, 2010-03-03 at 18:01 +0100, Gianluca Cecchi wrote:
> The new desired mount point is to be put under /oradata/TEST/newtemp
>
>
> Current extract of cluster.conf is
> <service domain="MAIN" autostart="1" name="TESTSRV">
> <ip ref="10.4.5.157"/>
> <lvm ref="TEST_APPL"/>
> <fs ref="TEST_APPL"/>
> <lvm ref="TEST_DATA"/>
> <fs ref="TEST_DATA"/>
> <script ref="clusterssh"/>
> </service>
>
>
> Based on my assumption about precedences/child resources and so on, I
> presumed one correct new conf would be:
> <service domain="MAIN" autostart="1" name="TESTSRV">
> <ip ref="10.4.5.157"/>
> <lvm ref="TEST_APPL"/>
> <fs ref="TEST_APPL"/>
> <lvm ref="TEST_DATA"/>
> <fs ref="TEST_DATA">
> <lvm ref="TEST_TEMP"/>
> <fs ref="TEST_TEMP"/>
> </fs>
> <script ref="clusterssh"/>
> </service>
So, here's the problem:
Starting TESTSRV...
[start] service:TESTSRV
[start] lvm:TEST_APPL
[start] lvm:TEST_DATA
[start] fs:TEST_APPL
[start] fs:TEST_DATA
[start] fs:TEST_TEMP
[start] lvm:TEST_TEMP
[start] ip:10.4.5.157
[start] script:clusterssh
Start of TESTSRV complete
This is because[1]:
===
With all the type-specified children, it's also important to note that
all untyped children - children of a given resource node which do not
have a <child> definition in the resource agent metadata - are all
started according to their order in cluster.conf and stopped in reverse
order. They are started after all type-specified children and stopped
before any typed children.
===
As it happens, the 'fs' file system type looks for child 'fs' resources:
<child type="fs" start="1" stop="3"/>
... but it does not have an entry for 'lvm', which would be required to
make it work in the order you specified.
The following would work:
<service domain="MAIN" autostart="1" name="TESTSRV">
<ip ref="10.4.5.157"/>
<lvm ref="TEST_APPL"/>
<fs ref="TEST_APPL"/>
<lvm ref="TEST_DATA"/>
<fs ref="TEST_DATA"/>
<lvm ref="TEST_TEMP"/>
<fs ref="TEST_TEMP"/>
<script ref="clusterssh"/>
</service>
rg_test ordering:
Starting TESTSRV...
[start] service:TESTSRV
[start] lvm:TEST_APPL
[start] lvm:TEST_DATA
[start] lvm:TEST_TEMP
[start] fs:TEST_APPL
[start] fs:TEST_DATA
[start] fs:TEST_TEMP
[start] ip:10.4.5.157
[start] script:clusterssh
Start of TESTSRV complete
So would this (if you needed to be absolutely sure that TEST_TEMP
mounted as a subdirectory of the TEST_APPL mountpoint):
<service domain="MAIN" autostart="1" name="TESTSRV">
<ip ref="10.4.5.157"/>
<lvm ref="TEST_APPL"/>
<fs ref="TEST_APPL"/>
<lvm ref="TEST_DATA"/>
<lvm ref="TEST_TEMP"/>
<fs ref="TEST_DATA">
<fs ref="TEST_TEMP"/>
</fs>
<script ref="clusterssh"/>
</service>
There apparently a bug in "rg_test delta" output. This is because it
simply runs through the resource list, looking for newly added/changed
resources. Because it doesn't run down the tree, the output of the
"Operations" section is wrong.
However, the tree outputs (old/new) are correct and consistent with
expected operation given the default fs.sh/lvm.sh/service.sh metadata.
-- Lon
[1] http://sources.redhat.com/cluster/wiki/ResourceTrees
--
Linux-cluster mailing list
Linux-cluster@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/linux-cluster
