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)
pgps3hVzdU5Np.pgp
Description: PGP signature
_______________________________________________ Developers mailing list [email protected] http://lists.clusterlabs.org/mailman/listinfo/developers
