Hi, On Thu, Aug 09, 2012 at 08:51:48AM +0200, Ulrich Windl wrote: > Just because of curiosity I did a quick grep for potential problems, and I > found this (SLES11 SP1): > > heartbeat/VIPArip:RIPDCONF=$HA_RSCTMP/VIPArip-ripd.conf > heartbeat/VIPArip: sed "s/redistribute connected metric .*/redistribute > con > nected metric $1/g" $RIPDCONF > $RIPDCONF.tmp > heartbeat/VIPArip: cp $RIPDCONF.tmp $RIPDCONF
Ugly. Now, the problem is that if we fix this, on the next upgrade the resource needs to be restarted. Actually, it should be done like this: # resource stop # upgrade resource-agents # resource start Currently, there's no mechanism to enforce such an upgrade. As we all know, nobody's reading release notes or changelogs. > Others seem OK. Thanks for taking a look. Dejan > > >>> Dejan Muhamedagic <[email protected]> schrieb am 08.08.2012 um 16:48 in > Nachricht <20120808144841.GD3580@squib>: > > Hi, > > > > On Fri, Jul 27, 2012 at 11:47:19AM +0200, Ulrich Windl wrote: > > > Hi! > > > > > > While your idea sounds good, I doubt whether parallel mounts being tried > > are actually being performed in parallel, just as the exportfs operations. > > They all access some common data structures in the kernel, I guess. In that > > case, the timeout values may need adjustments. > > > > > > Despite of that some RAs may show amazing behavior if executed in > > > parallel > > (I guess) ;-) > > > > That should never be the case. If it does, then it's a bug. > > > > Thanks, > > > > Dejan > > > > > Regards, > > > Ulrich > > > > > > >>> <[email protected]> schrieb am 27.07.2012 um 09:15 in Nachricht > > > <of7cf1dd89.6edcc5c6-onc1257a48.0025bf70-c1257a48.0027c...@bull.net>: > > > > Hi > > > > > > > > For now I had a group with several Filesystem resources followed by the > > > > exportfs like this : > > > > group g-FS-EXPORTED fs-A fs-B fs-C fs-D fs-E > > > > exportfs-fs-A > > > > exportfs-fs-B exportfs-fs-C exportfs-fs-D exportfs-fs-E \ > > > > > > > > Now, I would like to have all the FS mounted before all the exportfs > > > > BUT > > > > with sequential=false for all Filesystem primitives and > > > > sequential=false > > > > also for all exportfs primitives. > > > > > > > > I saw in the Pacemaker Configuration Explained documentation the > > > > Example 6.11. Ordered sets of unordered resources > > > > with two ressources A & B starting in parallel and before two > > > > ressources C > > > > & D starting also starting in parallel. I think this > > > > is exactly what I need. > > > > > > > > But : > > > > > > > > 1/ I have to remove the group configuration g-FS-EXPORTED , right ? > > > > or could I have such constraints "inside" the group itself ? > > > > (based on documentation, I don't think so) > > > > > > > > 2/ How can I enter the ordered set of unordered resources in the > > > > configuration ? > > > > (in documentation, the examples are given in xml, whereas we can't > > > > edit > > > > > > the xml cib file, > > > > and in crm configure order, I can't see the way to do it : > > > > usage: order <id> score-type: <first-rsc>[:<action>] > > > > <then-rsc>[:<action>] [symmetrical=<bool>] > > > > > > > > 3/ After this configuration, that means that I can't manage the start > > > > or > > > > stop of all these resources with only one command > > > > as it was the case with the group ? meaning that I have to launch > > > > a > > > > start command on the 10 primitives ? instead of > > > > the start command on the group ? > > > > > > > > Thanks for your help on this. > > > > Alain > > > > > > > > _______________________________________________ > > > > Linux-HA mailing list > > > > [email protected] > > > > http://lists.linux-ha.org/mailman/listinfo/linux-ha > > > > See also: http://linux-ha.org/ReportingProblems > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > Linux-HA mailing list > > > [email protected] > > > http://lists.linux-ha.org/mailman/listinfo/linux-ha > > > See also: http://linux-ha.org/ReportingProblems > > _______________________________________________ > > Linux-HA mailing list > > [email protected] > > http://lists.linux-ha.org/mailman/listinfo/linux-ha > > See also: http://linux-ha.org/ReportingProblems > > > > > > > _______________________________________________ > Linux-HA mailing list > [email protected] > http://lists.linux-ha.org/mailman/listinfo/linux-ha > See also: http://linux-ha.org/ReportingProblems _______________________________________________ Linux-HA mailing list [email protected] http://lists.linux-ha.org/mailman/listinfo/linux-ha See also: http://linux-ha.org/ReportingProblems
