Breaking Java API changes in release notes?


(ppearcy) #1

Hey,
The release notes do a great job of calling out any breaking changes
in terms of gateway format or config files:

However, it'd be great if any updates that impact the compatibility of
Java API protocols were called out, as well.

For example, I am on master from last week and am moving up to the
current master and the only way to know if the Java APIs are still
compatible is to just give it a shot. My preference is to perform a
rolling update, but if I knew there was an incompatibility would have
to bring down the whole cluster and upgrade it all at the same time.

Along these same lines and probably a better approach, it'd be best if
the APIs detected you were attempting to talk to an incompatible
version and log out the failure and refuse to join.

Thanks,
Paul


(ppearcy) #2

Looks like the same incompatibility can exist with the cluster
metadata and config.

Guess the correct approach is to always update the entire cluster and
any Java node based clients at the same time?

On Nov 15, 11:19 am, Paul ppea...@gmail.com wrote:

Hey,
The release notes do a great job of calling out any breaking changes
in terms of gateway format or config files:https://github.com/elasticsearch/elasticsearch/wiki/Release-notes

However, it'd be great if any updates that impact the compatibility of
Java API protocols were called out, as well.

For example, I am on master from last week and am moving up to the
current master and the only way to know if the Java APIs are still
compatible is to just give it a shot. My preference is to perform a
rolling update, but if I knew there was an incompatibility would have
to bring down the whole cluster and upgrade it all at the same time.

Along these same lines and probably a better approach, it'd be best if
the APIs detected you were attempting to talk to an incompatible
version and log out the failure and refuse to join.

Thanks,
Paul


(Shay Banon) #3

Yes, at least currently, this is the case.

On Mon, Nov 15, 2010 at 10:08 PM, Paul ppearcy@gmail.com wrote:

Looks like the same incompatibility can exist with the cluster
metadata and config.

Guess the correct approach is to always update the entire cluster and
any Java node based clients at the same time?

On Nov 15, 11:19 am, Paul ppea...@gmail.com wrote:

Hey,
The release notes do a great job of calling out any breaking changes
in terms of gateway format or config files:
https://github.com/elasticsearch/elasticsearch/wiki/Release-notes

However, it'd be great if any updates that impact the compatibility of
Java API protocols were called out, as well.

For example, I am on master from last week and am moving up to the
current master and the only way to know if the Java APIs are still
compatible is to just give it a shot. My preference is to perform a
rolling update, but if I knew there was an incompatibility would have
to bring down the whole cluster and upgrade it all at the same time.

Along these same lines and probably a better approach, it'd be best if
the APIs detected you were attempting to talk to an incompatible
version and log out the failure and refuse to join.

Thanks,
Paul


(Clinton Gormley) #4

On Tue, 2010-11-16 at 10:55 +0200, Shay Banon wrote:

Yes, at least currently, this is the case.

    Guess the correct approach is to always update the entire
    cluster and
    any Java node based clients at the same time?

Would it not be a good idea to introduce an API version check at the
moment that a node tries to join a cluster. If the cluster it connects
to is using a different version of API, then it could throw an error
explaining the issue.

We've seen a few emails from people who have inadvertently mixed
versions, with cryptic results, and this error would make it clearer
what the problem is.

Later, the versioning could make it possible to handle different
versions gracefully, but this seems to me to be a reasonable half way
point, no?

clint

--
Web Announcements Limited is a company registered in England and Wales,
with company number 05608868, with registered address at 10 Arvon Road,
London, N5 1PR.


(Shay Banon) #5

Yes, agreed. Requires some careful thinking, but certainly possible.

On Tue, Nov 16, 2010 at 12:24 PM, Clinton Gormley
clinton@iannounce.co.ukwrote:

On Tue, 2010-11-16 at 10:55 +0200, Shay Banon wrote:

Yes, at least currently, this is the case.

    Guess the correct approach is to always update the entire
    cluster and
    any Java node based clients at the same time?

Would it not be a good idea to introduce an API version check at the
moment that a node tries to join a cluster. If the cluster it connects
to is using a different version of API, then it could throw an error
explaining the issue.

We've seen a few emails from people who have inadvertently mixed
versions, with cryptic results, and this error would make it clearer
what the problem is.

Later, the versioning could make it possible to handle different
versions gracefully, but this seems to me to be a reasonable half way
point, no?

clint

--
Web Announcements Limited is a company registered in England and Wales,
with company number 05608868, with registered address at 10 Arvon Road,
London, N5 1PR.


(system) #6