----- Original Message -----
> From: "Lars Ellenberg" <lars.ellenb...@linbit.com>
> To: linux-ha@lists.linux-ha.org
> 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" <lars.ellenb...@linbit.com>
> > > To: "Brassow Jonathan" <jbras...@redhat.com>
> > > Cc: "General Linux-HA mailing list" <linux-ha@lists.linux-ha.org>, "Lars
> > > Marowsky-Bree" <l...@suse.com>, "Fabio M. Di
> > > Nitto" <fdini...@redhat.com>
> > > 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.
I've had a good talk with Jonathan about the --config "tags { pacemaker {} }"
approach. This was originally complicated for us because we were using the
--config option for a device filter during activation in certain situations...
using the --config option twice caused problems which made adding the tag in
the config difficult.
We've worked through those situations and it looks like it is actually safe to
strip out the conflicting --config usage required for the resilient device
filtering on activation.
The path forward is this.
1. Now that I know certain things are safe to remove, I'm going to re-evaluate
my current patches and attempt to greatly simplify the number of changes to the
original LVM agent. All the looking at the cluster membership and resilient
activation checking can be thrown out.
2. Next I'm going to introduce the proposed --config tags feature as a separate
patch that enables exclusive activation functionality without clvmd.
The final result here is going to be a much less scary looking set of changes
than what I currently have up for review. Hopefully we'll all be happy with the
new result.
Thanks for all the feedback, this has been very helpful
-- Vossel
>
> (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
> Linux-HA@lists.linux-ha.org
> http://lists.linux-ha.org/mailman/listinfo/linux-ha
> See also: http://linux-ha.org/ReportingProblems
>
_______________________________________________
Linux-HA mailing list
Linux-HA@lists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha
See also: http://linux-ha.org/ReportingProblems
