On 2013-05-14T15:59:05, Dejan Muhamedagic <deja...@fastmail.fm> wrote:
> > Appart from a larger restructuring of the code,
>
> For which I'd still like to hear a good explanation. Mind, this
> is not to say that this or that version is better, but that such
> a huge change calls for a serious effort on part of the
> developers and users.
As far as I understand it (and Fabio has confirmed that), this is
intended to merge the heartbeat LVM and the rgmanager LVM agent, with
the goal to ultimately reduce code duplication.
So that means moving shared code to a library/include, and turning both
existing front-ends into wrappers. I'd agree from the way the code was
structured before the merge that the rgmanager agent was better suited
to be the primary source of the library functions. But the discussion
also showed that there were some design decisions made in the heartbeat
version that were important - hence, the merged code drops the lvs calls
in monitor/status. An important dialogue to have.
And such merges of existing code bases are typically less easily broken
up into small incremental patches (as any observer of LKML can attest).
As far as I can see, it does also provide a few new use cases and
improvements.
While I agree this invites slightly more audit/review effort, it seems
we are in fact getting that here. And as everyone knows, I'm a
convergence fanboy, and willing to help out and test this further.
> area more than once. Finally, LVM is not without its own set of
> oddities which of course vary from version to version. If we're
> to go that way, then it should be for a good reason.
The reason why we merged the resource agent projects in the first place
was convergence, and reducing duplicated code. Exactly because resource
agents only seem straightforward, but are actually just as subtle and
core to delivering a working cluster as other parts, I think that is a
good reason to go this way.
Clearly, we want to be careful, do proper inspection, testing, etc.
But I'm also not sure how any attempt at merging agent code could happen
*without* gutting the existing RAs and turning them into front-ends, and
making sure the shared code covers both scenarios.
For me, preserving both frontends - and not making one go away - is
important, because it allows the configurations that reference either
one to continue working. That strikes me as good.
In summary, we had a merge that was slightly too broad, but
well-intentioned; that got good and important review from Dejan and lge,
whose points were addressed; and we're going in a good direction. Lets
make sure the remaining points (if any) are hashed out and merged. ;-)
(I admit that I'm a bit worried that if this is the amount of effort we
go through for something 'as simple as the lvm agent', how much pain
will something complex be! But, alas, I can see that it is a
constructive and necessary discussion.)
> > Maybe this has been originally implemented on request of some customer,
> > which was happy once he was able to say "exclusive=1", without thinking
> > about technical details?
> That'd be my best guess too. Been there myself a few times.
Yeah, well, me never of course. *cough*
In any case, that might actually be a reason to merge a feature that
turns out to not be perfectly well designed (I'm not saying this is
one): the merge needs to cover the use cases from before.
Since I've been among those beating David up over a certain LRM feature
that got dropped during a reimplementation and then was argued back in
with exactly that rationale (despite a better design proposal then),
even if this was true, I will NOT throw the first stone ;-) Preserving
existing deployed features is paramount.
(And, of course, that also means the new RA should be as stable as
before, too, preferably more so.)
Best,
Lars
--
Architect Storage/HA
SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB
21284 (AG Nürnberg)
"Experience is the name everyone gives to their mistakes." -- Oscar Wilde
_______________________________________________
Linux-HA mailing list
Linux-HA@lists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha
See also: http://linux-ha.org/ReportingProblems
