Hi, On Tue, Apr 20, 2010 at 03:33:14PM +0200, Lars Marowsky-Bree wrote: > On 2010-04-20T08:20:57, Florian Haas <[email protected]> wrote: > > > > And the first two _are_ still used/maintained for the SLES10 > > > packages. > > Which means they'll _never_ even install a resource-agents package > > without risking to lose support. Why do we need to carry those RAs in > > future upstream releases of resource-agents then? > > Well, first, I'm entertaining the notion to upgrade SLES10 to a recent > package build. Second, I was just pointing out that they are still being > used by some, and I very much object to the notion to dropping RAs in > minor releases with 1-6 months lead time.
Agreed. That time is too short. More, the warnings we had so far were not sufficient. And there are certainly people who didn't upgrade for a long time and perhaps won't in a long time. If their clusters are running fine, I guess that people are reluctant to do the upgrades anyway, until really forced. > I find the policy per se inacceptable, sorry. This is _enterprise_ code, > not J. Random Project people install for fun. Anything that is > user-visible and has the potential to bring down configurations that > work today but wouldn't after the update is a no-go. Agreed again, though I'm not sure if we've always had the same attitude. > > > The LinuxSCSI RA is, to the best of my knowledge, not broken either, and > > > does something entirely different from either SCSI reservations or sfex. > > But is has BETA written all over it, and you were on the CC list of the > > bug where we agreed that these should be deprecated and removed from > > future releases. Why are you complaining now? > > > > See comment > > http://developerbugs.linux-foundation.org/show_bug.cgi?id=2244#c1 > > specifically. You could have corrected us _then_. > > I _miss_ things. People do. If even I missed it, what is your guess how > many users will not have noticed anything? > > > > drbd - conceded, but shouldn't there then be a symlink to the new > > > version (which will do work in 99% of all cases unless someone used my > > > ill-conceived floating peer support)? > > Fine with the idea of the distro doing that via RPM magic. > > This is _irresponsible_ to our users of the community packaging. I'm at > a loss for words. > > > Aw c'mon, now don't _you_ start _me_ on rolling upgrades! > > Yes, I do. Because I it is extremely painful if it is not possible. > Trust me; I'm on the receiving end of those scenarios. We got away with > it once from SLES10 to SLE11, because the jump is too massive > technically for anything else to work, but here we are talking "x.y.z vs > x.y.z+1". > > Even pacemaker 0.6 to 1.0 is mostly automatic, unless the XSLT transform > fails. (Which, except for one or two bugs, it hasn't.) Even then the > cluster configuration was auto-converted. > > > Besides like the other Lars said: welcome to maintenance mode. > > If it is that simple, it should be automatic. We should not piss of our > users. I think that we need a different approach to the matter. Cheers, Dejan > 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/ _______________________________________________________ Linux-HA-Dev: [email protected] http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev Home Page: http://linux-ha.org/
