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