On 2010-04-19T23:04:42, Lars Ellenberg <[email protected]> wrote:
> > If it works and is auto-migrated, the warning shouldn't be "noisy" - the
> > logs already are ;-)
>
> That's the vicious circle:
> if the noise level is too high, everyone starts shouting.
> > If we can do it mostly under the lid, lets keep it there.
> But then we never get rid of it.
No, we "never" get rid of the symlink, for example (in cases where the
move is as trivial as that). Users have this weird expectation that they
can install updates _without_ messing with their configuration. Cluster
customers even more so.
(For comparison, drbd has compatibility handling for systems with 0.7 on
it still, right? If not 0.6?)
One can get rid of backwards-compatibility at major upgrades and
significant jumps. Not so much within 1.0.x to 1.0.x+1.
I'm sorry: we shipped it, we are responsible to our users.
> > Switching the ra type is, after all, another of those changes that
> > require a full restart of the resource (and thus service down-time).
> maintenance-mode=on
> s/ocf:heartbeat:drbd/ocf:linbit:drbd/g
> # some other things that may be necessary
> maintenance-mode=off
>
> should do it, without downtime.
No, the PE will complain about the changed hash, I'm pretty sure?
> > Instead, if the depreciated flag is somehow available to the UIs, I
> > think they should warn/reject definitions of new instances and suggest
> > the new one (trivial).
> >
> > And, possibly, in "I want a pony!"-land, notice when the resource in
> > question is stopped anyway and ask whether the user would like to switch
> > it to the new RA ;-)
>
> See above. Maintenance mode.
You can't change instance parameters in maintenance mode without causing
a restart once the cluster reengages.
Besides (even if I'm wrong and the ra-type isn't encoded and verified by
the PE, which would be surprising), even then this is a special case -
it doesn't help with dropping RAs entirely.
And if it _indeed_ was such a trivial change, _why_ require any user
interaction at all?!
Regards,
Lars
--
Architect Storage/HA, OPS Engineering, Novell, Inc.
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)
"Experience is the name everyone gives to their mistakes." -- Oscar Wilde
_______________________________________________________
Linux-HA-Dev: [email protected]
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/
