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