[Pacemaker] Release model

[Andrew Beekhof]

On 28/06/2013, at 5:30 PM, Lars Marowsky-Bree <lmb at suse.com> wrote:

> On 2013-06-28T11:11:00, Andrew Beekhof <andrew at beekhof.net> wrote:
> 
>>>> Maybe you're right, maybe I should stop fighting it and go with the
>>>> firefox approach.
>>>> That certainly seemed to piss a lot of people off though...
>>> If there's one message I've learned in 13 years of work on Linux HA,
>>> then it is that people are *always* going to be pissed off. ;-)
>> Ok, so are you actually proposing we switch upstream to Pacemaker-{integer} releases, forsake any notion of stable versions and leave that to the enterprise distros?
> 
> I'm with you on this,

I wasn't exactly saying I was for it, I was checking if you we're proposing it seriously.

> except for "forsake any notion of stable
> versions".

Except I don't think it's avoidable. 

> 
> My grumbling about 1.1.8 was mostly because it was an *exception* (from
> where I stand); for the most part, all pacemaker versions have been
> continuously progressing and regressions were "rare enough", partly due
> to the diligence of the developer(s), but also due to the rather
> extensive regression test suites, and keeping backwards compatibility
> (which is, anyway, a strong requirement due to the need of supporting
> rolling upgrades).

I'd agree with that.

> 
> So it was always easy enough to just upgrade, effectively following a
> "firefox model". (Or a Linux kernel 3.x model, more like.) As far as I
> can see, 1.1.x already did that.

Yep

> 
> There's an exception: dropping commonly used external interfaces (say,
> "ptest") needs to be announced a few releases in advance before enacted
> upstream. (And if Enterprise distributions want to keep something, they
> have time to prepare for that.) And of course, if major components get
> rewritten, they either need more testing or should be in place in
> parallel for 1 or 2 releases.

Now we start to diverge...

Keeping two lrmd's around? Two stonithd's?
Or two copies of the PE after I rewrite ordering constraints? Urgh :-(
If that sort of thing wasn't such a PITA you'd have done it with 1.1.8.

Some changes can be broadcast in advance, ptest to use your example, but sometimes a clean break is the only sane path.

Which is the problem with the Firefox model - either there is no "good" time to make them, or users hate us because we can make them at any time.

Even broadcasting changes can have limited value.
To use a recent example, crmsh was left in place for well over a year (iirc) before it was dropped.
That didn't seem to help anything...

> Even though an Enterprise model pays my bills, I'm a big fan of
> continuous delivery. I believe that everything else is mostly madness.
> (Perpetuated by customers willing to pay for it, and because admittedly
> not all components have good test suites.)

Me too, but how do we do this where all the downside doesn't fall on me?