[ClusterLabs Developers] New LVM resource agent name (currently LVM-activate)

[Jan Pokorný]

[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:
>> 
>> https://github.com/ClusterLabs/resource-agents/pull/1040
> 
> Honestly, was only vaguely aware of some previous complaints from
> Dejan in a different thread, but otherwise unlightened on what's
> happening.
> 
> 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.

-- 
Jan (Poki)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <https://lists.clusterlabs.org/pipermail/developers/attachments/20171123/023f3623/attachment-0004.sig>