----- Original Message ----- > From: "Lars Ellenberg" <[email protected]> > To: [email protected] > Sent: Tuesday, May 21, 2013 5:58:05 PM > Subject: Re: [Linux-HA] LVM Resource agent, "exclusive" activation > > On Tue, May 21, 2013 at 05:52:39PM -0400, David Vossel wrote: > > ----- Original Message ----- > > > From: "Lars Ellenberg" <[email protected]> > > > To: "Brassow Jonathan" <[email protected]> > > > Cc: "General Linux-HA mailing list" <[email protected]>, "Lars > > > Marowsky-Bree" <[email protected]>, "Fabio M. Di > > > Nitto" <[email protected]> > > > Sent: Monday, May 20, 2013 3:50:49 PM > > > Subject: Re: [Linux-HA] LVM Resource agent, "exclusive" activation > > > > > > On Fri, May 17, 2013 at 02:00:48PM -0500, Brassow Jonathan wrote: > > > > > > > > On May 17, 2013, at 10:14 AM, Lars Ellenberg wrote: > > > > > > > > > On Thu, May 16, 2013 at 10:42:30AM -0400, David Vossel wrote: > > > > > > > > > >>>>>>> The use of 'auto_activation_volume_list' depends on updates to > > > > >>>>>>> the > > > > >>>>>>> LVM > > > > >>>>>>> initscripts - ensuring that they use '-aay' in order to > > > > >>>>>>> activate > > > > >>>>>>> logical > > > > >>>>>>> volumes. That has been checked in upstream. I'm sure it will > > > > >>>>>>> go > > > > >>>>>>> into > > > > >>>>>>> RHEL7 and I think (but would need to check on) RHEL6. > > > > > > > > > > Only that this is upstream here, so it better work with > > > > > debian oldstale, gentoo or archlinux as well ;-) > > > > > > > > > > > > > > > Would this be good enough: > > > > > > > > > > vgchange --addtag pacemaker $VG > > > > > and NOT mention the "pacemaker" tag anywhere in lvm.conf ... > > > > > then, in the agent start action, > > > > > vgchange -ay --config "tags { pacemaker {} }" $VG > > > > > > > > > > (or have the to be used tag as an additional parameter) > > > > > > > > > > No retagging necessary. > > > > > > > > > > How far back do the lvm tools understand the "--config ..." option? > > > > > > > > --config option goes back years and years - not sure of the exact date, > > > > but > > > > could probably tell with 'git bisect' if you wanted me to. > > > > > > > > The above would not quite be sufficient. > > > > You would still have to change the 'volume_list' field in lvm.conf (and > > > > update the initrd). > > > > > > You have to do that anyways if you want to make use of tags in this way? > > > > > > > What you are proposing would simplify things in that you would not > > > > need different 'volume_list's on each machine - you could copy configs > > > > between machines. > > > > > > I thought volume_list = [ ... , "@*" ] in lvm.conf, > > > assuming that works on all "relevant" distributions as well, > > > and a command line "--config" tag would also propagate into that @*. > > > It did so for me. > > > > > > But yes, vlumen_list = [ ... , "pacemaker" ] would be fine as well. > > > > wait, did we just go around in a circle. If we add "pacemaker" to the > > volume list, and use that in every cluster node's config, then we've > > by-passed the exclusive activation part have we not?! > > No. I suggested to NOT set that "pacemaker" tag in the config (lvm.conf), > but only ever explicitly set that tag from the command line as used from > the resource agent ( --config "tags { pacemaker {} }" ) > > That would also mean to either override volume_list with the same > command line, or to have the tag mentioned in the volume_list in > lvm.conf (but not set it in the tags {} section). > > > Also, we're not happy with the auto_activate list because it won't > > work with old distros?! It's a new feature, why do we have to work > > with old distros that don't support it? > > You are right, we only have to make sure we don't break existing setup > by rolling out a new version of the RA. So if the resource agent > won't "accidentally" use a code path where support of a new feature > (of LVM) would be required, that's "good enough" compatibility. > > Still it won't hurt to pick the most "compatible" implementation > of several possible "equivalent" ones (RA-feature wise). > > I think the proposed --config "tags { pacemaker {} }" > is simpler (no retagging, no re-writing of lvm meta data), > and will work for any setup that knows about tags. > > (and I still think the RA should not try to second guess pacemaker and > double check the membership... which in the case of this "cluster wide > tag" would not make sense anymore, anyways) > > Of course this cluster wide tag "pacemaker" could be made configurable > itself, so not all clusters in the world using this feature would use > the same tag. > > primitive ... params exclusive=1 > (implicitly "does the right thing", > and internally guesses whatever that may be, > several times scanning and parsing LVM meta data just for that) > > becomes > > primitive ... params tag=weather-forecast-scratch-01 > (explicitly knows to use the _tag variants of start/monitor/stop, > no parsing and guessing, not try and retry, but just do-it-or-fail) > > Does that make sense at all?
yes, we are on the same page now. I am in favor of this approach. I am still confused about Jonathan's comment though when you proposed this solution... "The above would not quite be sufficient. You would still have to change the 'volume_list' field in lvm.conf (and update the initrd)." Why would this be necessary? I think I'm missing something here. -- Vossel > > Cheers, > Lars > > -- > : Lars Ellenberg > : LINBIT | Your Way to High Availability > : DRBD/HA support and consulting http://www.linbit.com > > DRBD® and LINBIT® are registered trademarks of LINBIT, Austria. > _______________________________________________ > 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
