[Pacemaker] Reminder: Pacemaker-1.1.10-rc5 is out there

Thu Jun 27 10:50:34 UTC 2013

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

> On 2013-06-27T14:28:19, Andrew Beekhof <andrew at beekhof.net> wrote:
> 
>> I wouldn't say the 6 months between 1.1.7 and 1.1.8 was a particularly aggressive release cycle.
> 
> For the amount of changes in there, I think yes. And the intrusive ones
> didn't show up all at the beginning of that cycle, either. That just
> made integration difficult - basically, we ended up skipping 1.1.8/1.1.9
> and went mostly with 1.1.10-rcx.
> 
>> Generally though, it has always been hard/dangerous to backport
>> specific fixes because of the complexity of the interactions -
>> particularly in the PE.
> 
> Yes, that's why we try to avoid backports ;-)
> 
>>> Yeah, that one. If it fixes a bug, it was probably unavoidable
>>> (though the specific commit
>>> (953bedf8f7f54f91a76672aeee5f44dc465741e9) didn't mention a bugzilla
>>> id).
>> It has always been the case that I find and fix far more bugs than
>> people report.
>> I don't plan to start filing bugs for myself.
> 
> True, I didn't mean that was necessary. A one liner about the fix would
> have been helpful, though.

There was one :-)
I merged the best bits of three parallel CPG code paths.
The things that prompted the extra bits in one also applied to the others.

> 
>> In this case though, I made an exception because the plan is to NOT have another 1.1.x and "it is still my intention not to have API changes in 2.0.x, so better before than after".
> 
> True. I admit I would probably have taken that as a reason for inserting
> one more 1.1.x release, but I understand you have your own scheduling
> requirements.

I'm also quite over doing releases.
I've been wanting to close the door on 1.1 since 2010, every extra release just leaves more time for new features (and cleanups) to be dreamt up.

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...

> 
>> Granted I had completely forgotten about the plugin editions of ocfs2/dlm, but I was told you'd already deep frozen what you were planning to ship, so I don't understand the specific concern.
> 
> We're already working towards the first maintenance update ;-)
> 
> And it's not a specific concern (we'll delay that one until it's all
> settled again), but we were discussing changes and how to schedule
> releases for them; and from the point of view as a consumer/user,
> introducing such a change in what was supposed to be the "last" release
> candidate was a huge surprise.
> 
>> There is never a good point to make these changes, even if I make them just after a release people will just grumble when it comes time to look at the next one - just like you did above for 1.1.8.
> 
> No, that's not quite it. 1.1.8 *was* special. Also look at the impact it
> had on our users; LRM rewrite (which implies huge logging changes),
> crmsh split, changes to m/s ... 1.1.8 was an exception in what otherwise
> is a rather impressive track record of releases. Normally, integrating
> new releases has always been rather straightforward. But I don't want to
> dwell on that.
> 
>>> I don't really mind the API changes much, for me it's mostly a
>>> question of timing and how big the pile is at every single
>>> release.
>> I thought you wanted longer release cycles... wouldn't that make the
>> pile bigger?  
> 
> No, I generally tend to want shorter release cycles, with a more
> moderate flow of changes. (As far as that is concerned.)

If only life were so predictable.
Of course there is often a wishlist, but what _actually_ goes into a release is very much a product of how many and what types of bugs are getting reported (what code needs the most attention and how much "free" time I have).

The amount of help I get is a big factor too.
Without NTT looking after 1.0.x or David making short work of various features, I definitely wouldn't have gotten to half of these cleanups.

So no master plan to make anyone's life hell, just "Oh look, somehow I have a chunk of time to do something useful in" or "If I don't fix it now I'll have to look at it for the next decade".

> 
>> And is it not better to batch them up and have one point of
>> incompatibility rather than a continuous stream of them?
> 
> Well, that means we end up backporting the changes that can't wait. And
> the cliff to jump from to the next release just becomes larger and more
> deterring.
> 
>>> If you consider the API from a customer point of view, the things like
>>> build or runtime dependencies on shared libraries aren't so much of an
>>> issue - hopefully, the distribution provider hides that before they
>>> release updates. Hence my "Oh well, I don't care" stance.
>> Except if it affects ocf2/dlm/sbd?
> 
> I don't care for the fact that the changes were made, much. The new
> interface looks like a win and code reduction. My comment was, as stated
> above, specifically about doing such a change in a late release
> candidate.
> 
>>> What's more troublesome are changes to existing commands (even
>>> something minimal like "crm_resource -M" now generating a short
>>> location constraint,
>> I find it confusing how an contained 10 line change to a CLI tool is
>> troublesome
> 
> Because it shows through to users.

I got that part, it was the comparative difficulty of maintaining compatibility I was going for.

> And it's then when I start having to
> worry about users complaining when their scripts break (that expected
> the tools to do something specific; though I hope that in this case it
> doesn't - we'll document it as an optimization).
> 
>> but you're prepared to wear the overhead of holding back
>> API changes - which usually impact all sorts of code paths, sometimes
>> across multiple projects.
> 
> We don't hold them back.

Then I guess I'm confused by what you meant by:

>>> Distributions can take care of them when they integrate them; basically
>>> they'll trickle through until the whole stack the distributions ship
>>> builds again.

Didn't that relate to essentially holding back not-critical-to-you changes?

> We'll fix the dependencies before the release.
> It's my intention to keep being as close to a (tested) upstream version
> as possible, because everything else ends up being very costly.
> 
> The difference is that the latter is a cost that is internal to us as
> developers, and not something that users/customers would possibly care
> about. (Unless they've written their own add-on code, which is truly
> rare.)
> 
>> CLI output I can usually be convinced of, but log messages are most definitely not something I will consider as a valid programming interface.
> 
> Agreed. It's not an API, that's for sure. Yet it's one of the interfaces
> to *customers* and their system monitoring tools. Yes, one must be
> allowed to change them, but they need to be documented (by someone, not
> necessarily you).

The day you suggest every message include a unique and immutable ID... lets just say you'd better start polishing that katana.

> 
> It's my hope that regression test suite for the crm shell history
> explorer will help catch them and thus help with documentation.
> 
> 
> Regards,
>    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
> 
> 
> _______________________________________________
> Pacemaker mailing list: Pacemaker at oss.clusterlabs.org
> http://oss.clusterlabs.org/mailman/listinfo/pacemaker
> 
> Project Home: http://www.clusterlabs.org
> Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
> Bugs: http://bugs.clusterlabs.org