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

[Lars Marowsky-Bree]

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.

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

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

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

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