On 2010-04-19T22:22:41, Lars Ellenberg <[email protected]> wrote:
> > - EvmsSCC and
> > - Evmsd (both apply to EVMS, which is no longer maintained);
> Fine with me, as newer distributions don't ship with EVMS anymore anyways.
> Older distros (read: sles10) can easily keep the latest copy of those.
Ah, damn ;-) I'd have preferred if it stayed, but yes, we can do that.
In fact, we drop them when building for SLE 11, anyway.
Maybe that's another option: --with-depreciated-ras=yes
> > - drbd (superseded by ocf:linbit:drbd);
> Could possibly be replaced with a wrapper and continue to complain noisily.
> We may also offload that to distributors, though.
> Then, maybe not. Rather do that ourselves ;-)
I'm pretty sure at least one distributor would be in a position to
off-load it right back to you ;-)
I agree with the wrapper approach or somehow redirecting it directly
(symlink) - cluster-glue could conflict with an older drbd release to
ensure that, if drbd is installed, the new version providing the update
is present -, but I'm not so happy about the "noisy" warnings.
If it works and is auto-migrated, the warning shouldn't be "noisy" - the
logs already are ;-) If we can do it mostly under the lid, lets keep it
there.
Switching the ra type is, after all, another of those changes that
require a full restart of the resource (and thus service down-time).
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 ;-)
> > Since nobody should be using these anymore,
> And how is the average nobody supposed to know that? ;-)
Lars, you know that all our users diligently read and understand all of
the documentation, package changelogs, and release notes. How could you
even suggest this question! ;-)
> 1.0.2 was Feb 1st. 1.0.3 was last week.
> If that implies 1.0.4 will be in June,
> I don't think that deprecation timeframe was sufficient.
Yes, the kernel has, I think, a ~2 year removal window.
> Dejan, Rasto, Tim, Yan:
> Our various user interfaces should probably warn about
> deprecated resource agents, too.
Agreed, see above. (In a not-to-annoying fashion, because otherwise,
usability will suffer.)
In general, I think the ability to depreciate functionality is needed,
but shouldn't be slip-streamed into a minor dot release, and we first
need to do some more home work to get our infrastructure right before we
should consider breaking customer configurations.
> What else can we do to get the deprecation actually noticed
> by existing installations, respectively "the guy responsible"?
crm configure already warns about many things, as could the GUIs. It
shouldn't warn when "unrelated" stuff changes, and not too frequently.
(Aid users, don't piss them off, basically.)
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/
