Github user paul-rogers commented on the pull request:
https://github.com/apache/drill/pull/474#issuecomment-208943460
Hi All. Version compatibility is a complex issue. Do we have a design
document that explains our goals and policy? Is the goal to allow rolling
updates of clients? (Drill server at, say 1.8, rolling upgrade of client from
1.7 to 1.8, old clients work)? Or, is it to allow rolling upgrades of servers?
Both?
MapR customers receive even releases: 1.4, 1.6, 1.8. Would the +/-1 policy
benefit them?
As I understand it, each Drill bit is to work with another of +/-1 version.
But, what I bring up Drill 1.6, Drill 1.5 and Drill 1.4. The 1.5 is happy to
work with both 1.6 and 1.4. But, the 1.6 and 1.4 versions will fail only when
they communicate with one another. When will this communication occur? At
startup? Or, only later when, say, 1.6 tries to send a query to 1.4?
Does this mean that Drillbits should advertise their version in ZooKeeper
so that we fail fast and can provide a clear error message?
Dremio proposes a new 2.0 release that breaks compatibility. Will Drill 1.9
(say) be compatible with the incompatile Drill 2.0? Should it be?
As others have said, we need to consider wire protocol and semantics. The
usual solution is protocol negotiation. If a 1.6 client connects to a 1.7
server, they agree to "speak" 1.6. If a 1.7 client connects to a 1.6 server,
they also agree to "speak" 1.6. Such as solution has impact on our messaging
layer. It increases testing requirements.
Drill-on-YARN will provide another way to do server upgrades (ramp up a new
cluster while ramping down an old one.) Otherwise, YARN will need some way to
run the same cluster, replacing version X drillbits with version X+1 (while
still running the version X Application Master).
Are all these issues spelled out in a design doc?
IMHO: let's not try to bug fix our way to success here; let's step back and
work out a complete design.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---
