[ClusterLabs Developers] New LVM resource agent name (currently LVM-activate)
jpokorny at redhat.com
Thu Nov 23 16:17:14 EST 2017
[this follow-up is mostly to re-CC some people that were gradually
omitted as the thread progressed, I am not sure who's subscribed
and who not with them]
On 23/11/17 20:27 +0100, Jan Pokorný wrote:
> On 23/11/17 16:54 +0800, Eric Ren wrote:
>>> What about VolumeGroup (in the tradition of Filesystem, for instance)?
>> In the LVM-activate, we will support both all VG activation and only
>> one specified LV activation depending on the parameters.
> This non-educated suggestion was driven solely by the fact that VG
> needs to always be specified.
>>> Or why not shoot for an LVM merge (plus proper versioning to tell
>>> the difference)?
>> You mean merging LVM-activate with the existing LVM?
> Yep, see below.
>> Here was a long discussion about that:
> Honestly, was only vaguely aware of some previous complaints from
> Dejan in a different thread, but otherwise unlightened on what's
> And I must admit, I am quite sympathetic to the non-articulated wish
> of knowing there's a plan to give a new spin to enclustered LVM
> beforehand -- afterall, adoption depends also on whether the situation
> is/will be clear to the userbase. Some feedback could have been
> gathered earlier -- perhaps something to learn some lessons from
> for the future.
> Putting the "community logistics" issue aside...
> Bear with me, I am only very slightly familiar with the storage field.
> I suspect there are some framed pictures of "LVM-activate" use that
> are yet to be recognized. At least it looks to me like one of them
> is to couple+serialize lvmlockd agent instance followed with
> "LVM-activate". In that case, the latter seems to be spot-on naming
> and I'd rather speculate about the former to make this dependency
> clearer, renaming it to something like LVM-prep-lvmlockd :-)
> [At this point, I can't refrain myself from reminding how handy the
> "composability with parameter reuse" provision in RGManager was,
> and how naturally it would wrap such a pairing situation (unless
> the original assumption doesn't hold). I don't really see how
> that could be emulated in pacemaker, it would definitely be
> everything but a self-contained cut.]
Wanted to add a comment on IPaddr vs. IPaddr2 (which, as mentioned,
boils down to ifconfig vs. iproute2) situation being used for
comparison -- this is substantially a different story, as iproute2
(and in turn, IPaddr2) is Linux-only, while the whole stack is more
or less deployable on various *nixes so having two agents in parallel,
one portable but with some deficiences + one targeted and more capable
makes a damn good sense. Cannot claim the same here.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 819 bytes
Desc: not available
More information about the Developers