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

[Jan Pokorný]

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.]

-- 
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/157ecc6c/attachment-0004.sig>