On 10/05/2013 11:37 AM, Fraser Adams wrote:
One very minor thing struck me the other evening after I'd thought about
this change - it's not all that uncommon for people to be running
systems that may contain a "mixed economy" of broker versions. It's
clearly not a huge deal as the versions of the tools deployed with the
earlier instances with work with those and 0.25+ but the opposite isn't
true for the case of cluster-durable and that might cause some confusion.
I only note this as I've got entertaining memories of the time when I
has a mixture of 0.8 and 0.18 in a very large federated topology.
Between those versions things had been updated to use pure QMF method
invocation for adding/deleting things so the 0.18 tools failed miserably
on the 0.8 brokers but the 0.8 tools still worked with the 0.18 brokers
- thank goodness :-D . Fortunately I'm pretty familiar with QMF ;-) so I
clocked the issue pretty much much immediately (when I found out about
it!) but the poor sod who's job was actually to manage the system was
tearing his hair out for ages until he thought to mention his pain to me.
The bigger problem is usually when the schema or management protocol
itself changes (particularly when things are removed). In this case it
would just be an option on a tool that is no longer available. So
hopefully its caught a little earlier and more obviously.
I guess It's a challenge trying to keep things abreast (and tidy) with
improvements whilst also keeping older/mixed systems running and I don't
have any good answers myself (just saying "upgrade" doesn't cut it in an
Enterprise environment). Documenting the change *might* work, but in
this case where on earth would one put it where someone who may get
bitten by this change would find it?
The much bigger change here is the removal of the old cluster module.
That was discussed a fair bit and was I believe release noted in 0.20.
This is really just a tidying up of the code around that.
I guess you could change the tool to print an explicit error when a
'removed' option is requested. That's probably worth it in some cases.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
