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.
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.
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.
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.
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.
Apache, Apache Lucene, Apache Hadoop, Hadoop, HDFS and the yellow elephant
logo are trademarks of the
Apache Software Foundation
in the United States and/or other countries.