qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alan Conway <acon...@redhat.com>
Subject Re: Review Request 14361: QPID-5197: Remove obsolete --cluster-durable/persistLastNode options
Date Mon, 07 Oct 2013 13:30:41 GMT
Hi Fraser,

It's always a bit of a juggling act isn't it?

My thinking was that since the feature is now gone on the broker, it is 
confusing to keep it in the tools. However you have a point about new tools 
against old brokers.

Do you think we should keep the old features in the tools and put a deprecation 
in the release notes, then take them out next cycle? That would mean that we 
have to test that new tools do actually work with old brokers, which is 
something we haven't done so far (but probably should)


On 10/05/2013 06:37 AM, Fraser Adams wrote:
> Hey Alan,
> I finally got round to playing with this - I noticed it was part of the mammoth
> svn update I did this morning. It all looks fine to me. As I say thanks for
> being so thorough about tidying up everything that refers to this.
> 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.
> 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?
> I've got no real issues myself, but thought it was worth mentioning it as a bit
> of food for thought in case someone has any bright ideas how to manage this sort
> of scenario (it's bound to crop up again).
> Cheers,
> Frase
> On 01/10/13 22:43, Alan Conway wrote:
>     On October 1st, 2013, 6:47 p.m. UTC, *Fraser Adams* wrote:
>         Ship It!
>     On October 1st, 2013, 6:55 p.m. UTC, *Fraser Adams* wrote:
>         Hi Alan, I've been tied up for ages on a bunch of other things so I
> probably won't get a change to "fire it up" until the weekend to actually kick
> it, however I have had a look through the diffs and it all looks fine to me.
>         I have to say that I'm impressed by how thorough you've been. I did a
> double take when I saw the GetOpt helper mentioned cause I couldn't recall it
> having any such dependencies - but you've even tidied up references that were
> just mentioned as comments - nice one!
>         As long as you've fired up the GUI and checked the other bits of
> "durable" still behave (and from the diff I can't see any reason why they
> wouldn't) then I'm cool, but it'd definitely be good to double check - that
> expansion animation was a little fiddly :-) Visually though it looks fine to me.
> Great. I will try to figure out how to fire up the GUI myself, if you don't get
> to it first.

To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org

View raw message