[jira] [Commented] (DRILL-4596) Drill should do version check among drillbits

[Arina Ielchiieva (JIRA)]

[ 
https://issues.apache.org/jira/browse/DRILL-4596?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15625714#comment-15625714
 ] 

Arina Ielchiieva commented on DRILL-4596:
-

Copying Paul and Jacques comments from PR:
*Paul*
Great issue! Getting version compatibility working will be a huge benefit to 
users.

But, as it turns out, 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? (DRILL-4543)

Dremio proposes a new 2.0 release that breaks compatibility. Will Drill 1.9 
(say) be compatible with the (proposed) incompatile Drill 2.0? Should it be? 
How should we make that work?

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).

If I may suggest, this is a complex topic. This is much more than a code change 
to compare version numbers. Perhaps we should work out the goals and issues in 
a design document.

Some other design issues. The idea of a rollling upgrade presupposes that we 
can shut down a Drillbit, bring up a new one, and the cluster keeps running. 
But, today, bringing down a Drillbit causes all in-flight queries on that node 
to fail. There is no way to mark a node as "quiescent" (up, but not accepting 
new work.) So, a rolling upgrade today would entail a long series of query 
failures as we replace each of, say, 20 or 50 nodes. So, in fact, it is less 
disruptive to take the cluster down, push an upgrade, and bring it back up. 
(See DRILL-4286.)

Back on testing: testing is essential. A feature that allow +/-1 feature 
compatibility is not helpful unless someone (other than the user) can certify 
that it works. If the user gets to do the checking, then it is not very 
helpful: safer just to do a full upgrade.

To emphasize an earlier point: there are two distinct issues. One is a managed 
cluster upgrade (the admin can do it with the help of a management tool.) The 
other are the many Drill clients spread across desktops: that is a classic 
desktop software upgrade. Some might be on planes, others locked in desks while 
someone is on vacation. Let's think about how to upgrade JDBC drivers and the 
like given this reality.

Is the compatiblity policy number or time based? As an admin, can I expect to 
have a three-month window for upgrades? Or, will it sometimes be one month, 
others four months, depending on who changes what? Should we have a time-based 
policy?

*Jacques*
In general, I'm against version number checking. We did that in the code early 
on but we should be moving towards a capabilities flag approach.

Also agree with Paul in his mention of DRILL-4286, don't think worrying about 
rolling upgrade makes sense until we resolve the issues around decommissioning.

> Drill should do version check among drillbits
> -
>
> Key: DRILL-4596
> URL: https://issues.apache.org/jira/browse/DRILL-4596
> Project: Apache Drill
>  Issue Type: New Feature
>Affects Versions: 1.6.0
>Reporter: Arina Ielchiieva
> Fix For: Future
>
>
> Before registering new drillbit in zookeeper, we should do version check, and 
> make sure all the running drillbits are in the same version.
> Using drillbits of different version can lead to unexpected results.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (DRILL-4596) Drill should do version check among drillbits

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/DRILL-4596?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15625698#comment-15625698
 ] 

ASF GitHub Bot commented on DRILL-4596:
---

Github user arina-ielchiieva closed the pull request at:

https://github.com/apache/drill/pull/474


> Drill should do version check among drillbits
> -
>
> Key: DRILL-4596
> URL: https://issues.apache.org/jira/browse/DRILL-4596
> Project: Apache Drill
>  Issue Type: New Feature
>Affects Versions: 1.6.0
>Reporter: Arina Ielchiieva
>Assignee: Arina Ielchiieva
> Fix For: Future
>
>
> Before registering new drillbit in zookeeper, we should do version check, and 
> make sure all the running drillbits are in the same version.
> Using drillbits of different version can lead to unexpected results.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (DRILL-4596) Drill should do version check among drillbits

[Arina Ielchiieva (JIRA)]

[ 
https://issues.apache.org/jira/browse/DRILL-4596?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15240021#comment-15240021
 ] 

Arina Ielchiieva commented on DRILL-4596:
-

John, I think it's a good idea at least for now until compatibility design is 
not ready to generate alert if current drillbit version doesn't match with 
other drillbits on WebUI. At least the customer will know that drillbits 
versions are out of sync. I will create Jira to introduce this change.

> Drill should do version check among drillbits
> -
>
> Key: DRILL-4596
> URL: https://issues.apache.org/jira/browse/DRILL-4596
> Project: Apache Drill
>  Issue Type: New Feature
>Affects Versions: 1.6.0
>Reporter: Arina Ielchiieva
>Assignee: Arina Ielchiieva
> Fix For: Future
>
>
> Before registering new drillbit in zookeeper, we should do version check, and 
> make sure all the running drillbits are in the same version.
> Using drillbits of different version can lead to unexpected results.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (DRILL-4596) Drill should do version check among drillbits

[John Omernik (JIRA)]

[ 
https://issues.apache.org/jira/browse/DRILL-4596?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15239202#comment-15239202
 ] 

John Omernik commented on DRILL-4596:
-

I've been following this thread closely, and it's a very complex issue. 
Jacques, great work on the initial compatibility statements and Paul great 
enumeration of potential issues with locking in users to versions and potential 
future challenges. Also, thanks to Arina for bringing this up and all who have 
contributed.  This is a great topic for discussion. 

Without dictating a path here, I'd like to share a store as an administrator 
that my offer yet another option.  I think enforcing the versions could pose 
challenges in general.  There are lots of edge cases, and for us to enumerate 
them all, even with Paul's work, would likely end up missing a few.  So as part 
of the compatibility statements, as those get finalized, I think it's fair to 
say "We in the Drill community recommend you use drill bits of the same 
version, that's the only way to ensure consistency across a cluster, however, 
we will strive to make moving from version to version easy, with the 
understanding that certain features will only work as intended when all drill 
bits meet a certain minimum"   I.e. If we put a feature in 1.8, and you have a 
1.7 and 1.8 mixed cluster, and try to use that feature in 1.8, there should be 
no expectation that it will work as intended.  That is a quagmire of support 
paths that I am sure scares many devs. (Supporting new features in a backwards 
way) (I like the word quagmire, and never get to really use it)

So, as the public commitment on compatibility gets finalized, instead of 
"forcing" certain conditions to be met, (i.e. make sure all bits are the same). 
 We could potentially take a play from MapR's playbook.  MapR folks, keep me 
honest here on how MapR approaches things, this is my perception as a user.

Basically, MapR has a "cluster version" that is set on install. So if no 
version is set, the first install sets it.  When nodes of different versions 
are installed, (lesser or greater, doesn't matter) There is an "alert" 
generated that flags the admin in the MapR Control System. MapR still works, it 
just makes noise about inconsistency. 

So , we don't have a Drill Control System, but we do have a Web UI that shows 
all the drill bits, and that we default to upon logging on. We could add the 
Drill version to each listed drill bit, we could also display the "Master 
Cluster Version".  If any of the drill bits are "out of sync" we can highlight 
it in red or list them in a separate list (out of sync drill bits) Etc.  Make 
it plainly obvious that we have drill bits not in sync with the master version. 
 This will allow administrators to go figure out what's wrong and address the 
problem. If a cluster upgrade is happening, this is not an issue, if a cluster 
upgrade is NOT happening, an admin will want to resolve this ASAP. 

Let's say we do an upgrade and the master version is 1.6 but all bits are 
running 1.7.  Now the drill page shows everything as out of sync. Like in MapR, 
we just provide a documentation item that allows an administrator to run ALTER 
SYSTEM SET `drill.cluster.master.version` = 1.7 and boom, all bits are now in 
sync.  We have the one master version, but we don't enforce what can connect.  

Basically, we are saying, we have X for public compatibility, and we allow 
users/admins to do what ever they want, and understand that certain things 
won't work, we say that in our public statement and potentially enumerate know 
items in release notes.  We give admins a clear way to manage their systems and 
cluster version, but enforce nothing. 

Now, there may be breaking changes, there may be things that we need to deal 
with.  I think one thing MapR does that's handy is for new features, the 
feature is dependent on  on a system setting.   So let's pick a feature, say 
Arrow support.  (I don't know if any of this is true, I am using it as an 
example of a concrete feature, not as accurate description of what may break 
with Arrow support in particular). If say Arrow Support lands in 1.8, the 
feature itself, optionally, can use the cluster master version as a guard. I.e. 
it won't be enabled until the cluster master version is set to 1.8 but on an 
existing cluster,  even with the master version running at 1.8, it still has to 
be "manually" turned on by an administrator.

Arrow support would on drill.cluster.features.arrowsupport and for existing 
clusters it's set to false be default.  For a new cluster of version 1.8, it 
could be defaulted to true (this up to the dev writing the feature).  For an 
existing cluster, the setting is added as false.  If you try to enable it with 
the master version set to 1.7, a helpful error is returned "Arrow support 
requires your cluster to be running master.version 1.8" If the master version 
is 

[jira] [Commented] (DRILL-4596) Drill should do version check among drillbits

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/DRILL-4596?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15237875#comment-15237875
 ] 

ASF GitHub Bot commented on DRILL-4596:
---

Github user jacques-n commented on the pull request:

https://github.com/apache/drill/pull/474#issuecomment-209081311
  
In general, I'm against version number checking. We did that in the code 
early on but we should be moving towards a capabilities flag approach.

Also agree with Paul in his mention of DRILL-4286, don't think worrying 
about rolling upgrade makes sense until we resolve the issues around 
decommissioning.


> Drill should do version check among drillbits
> -
>
> Key: DRILL-4596
> URL: https://issues.apache.org/jira/browse/DRILL-4596
> Project: Apache Drill
>  Issue Type: New Feature
>Affects Versions: 1.6.0
>Reporter: Arina Ielchiieva
>Assignee: Arina Ielchiieva
> Fix For: Future
>
>
> Before registering new drillbit in zookeeper, we should do version check, and 
> make sure all the running drillbits are in the same version.
> Using drillbits of different version can lead to unexpected results.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (DRILL-4596) Drill should do version check among drillbits

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/DRILL-4596?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15237365#comment-15237365
 ] 

ASF GitHub Bot commented on DRILL-4596:
---

Github user paul-rogers commented on the pull request:

https://github.com/apache/drill/pull/474#issuecomment-208959253
  
Some other design issues. The idea of a rollling upgrade presupposes that 
we can shut down a Drillbit, bring up a new one, and the cluster keeps running. 
But, today, bringing down a Drillbit causes all in-flight queries on that node 
to fail. There is no way to mark a node as "quiescent" (up, but not accepting 
new work.) So, a rolling upgrade today would entail a long series of query 
failures as we replace each of, say, 20 or 50 nodes. So, in fact, it is less 
disruptive to take the cluster down, push an upgrade, and bring it back up. 
(See DRILL-4286.)

Back on testing: testing is essential. A feature that allow +/-1 feature 
compatibility is not helpful unless someone (other than the user) can certify 
that it works. If the user gets to do the checking, then it is not very 
helpful: safer just to do a full upgrade.

To emphasize an earlier point: there are two distinct issues. One is a 
managed cluster upgrade (the admin can do it with the help of a management 
tool.) The other are the many Drill clients spread across desktops: that is a 
classic desktop software upgrade. Some might be on planes, others locked in 
desks while someone is on vacation. Let's think about how to upgrade JDBC 
drivers and the like given this reality.

Is the compatiblity policy number or time based? As an admin, can I expect 
to have a three-month window for upgrades? Or, will it sometimes be one month, 
others four months, depending on who changes what? Should we have a time-based 
policy?


> Drill should do version check among drillbits
> -
>
> Key: DRILL-4596
> URL: https://issues.apache.org/jira/browse/DRILL-4596
> Project: Apache Drill
>  Issue Type: New Feature
>Affects Versions: 1.6.0
>Reporter: Arina Ielchiieva
>Assignee: Arina Ielchiieva
> Fix For: Future
>
>
> Before registering new drillbit in zookeeper, we should do version check, and 
> make sure all the running drillbits are in the same version.
> Using drillbits of different version can lead to unexpected results.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (DRILL-4596) Drill should do version check among drillbits

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/DRILL-4596?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15237312#comment-15237312
 ] 

ASF GitHub Bot commented on DRILL-4596:
---

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.


> Drill should do version check among drillbits
> -
>
> Key: DRILL-4596
> URL: https://issues.apache.org/jira/browse/DRILL-4596
> Project: Apache Drill
>  Issue Type: New Feature
>Affects Versions: 1.6.0
>Reporter: Arina Ielchiieva
>Assignee: Arina Ielchiieva
> Fix For: Future
>
>
> Before registering new drillbit in zookeeper, we should do version check, and 
> make sure all the running drillbits are in the same version.
> Using drillbits of different version can lead to unexpected results.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (DRILL-4596) Drill should do version check among drillbits

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/DRILL-4596?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15236773#comment-15236773
 ] 

ASF GitHub Bot commented on DRILL-4596:
---

Github user arina-ielchiieva commented on a diff in the pull request:

https://github.com/apache/drill/pull/474#discussion_r59332891
  
--- Diff: 
common/src/main/java/org/apache/drill/common/util/DrillVersionInfo.java ---
@@ -49,10 +53,52 @@ public static String getVersion() {
 }
   }
 } catch (IOException except) {
-  appVersion = "Unknown";
+  appVersion = UNKNOWN_VERSION;
 }
 return appVersion;
   }
 
+  /**
+   * Compare two Drill versions disregarding build number and comparing 
only major and minor versions.
+   * Versions are considered to be compatible:
+   * 1. if current version is the same as version to compare.
+   * 2. if current version minor version + 1 is the same as version to 
compare.
+   */
+  public static boolean isVersionsCompatible(String currentVersion, String 
versionToCompare) {
+if (currentVersion != null && currentVersion.equals(versionToCompare)) 
{
+  return true;
+}
+
+BigDecimal currentVersionDecimal = getVersionAsDecimal(currentVersion);
+BigDecimal versionToCompareDecimal = 
getVersionAsDecimal(versionToCompare);
+
+if (currentVersionDecimal != null && versionToCompareDecimal != null) {
--- End diff --

I guess, yes. Ideally all drillbits in cluster will be with the same 
version, only during rolling upgrades this situation may occur.


> Drill should do version check among drillbits
> -
>
> Key: DRILL-4596
> URL: https://issues.apache.org/jira/browse/DRILL-4596
> Project: Apache Drill
>  Issue Type: New Feature
>Affects Versions: 1.6.0
>Reporter: Arina Ielchiieva
>Assignee: Arina Ielchiieva
> Fix For: Future
>
>
> Before registering new drillbit in zookeeper, we should do version check, and 
> make sure all the running drillbits are in the same version.
> Using drillbits of different version can lead to unexpected results.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (DRILL-4596) Drill should do version check among drillbits

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/DRILL-4596?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15236170#comment-15236170
 ] 

ASF GitHub Bot commented on DRILL-4596:
---

Github user yufeldman commented on a diff in the pull request:

https://github.com/apache/drill/pull/474#discussion_r59297387
  
--- Diff: 
common/src/main/java/org/apache/drill/common/util/DrillVersionInfo.java ---
@@ -49,10 +53,52 @@ public static String getVersion() {
 }
   }
 } catch (IOException except) {
-  appVersion = "Unknown";
+  appVersion = UNKNOWN_VERSION;
 }
 return appVersion;
   }
 
+  /**
+   * Compare two Drill versions disregarding build number and comparing 
only major and minor versions.
+   * Versions are considered to be compatible:
+   * 1. if current version is the same as version to compare.
+   * 2. if current version minor version + 1 is the same as version to 
compare.
+   */
+  public static boolean isVersionsCompatible(String currentVersion, String 
versionToCompare) {
+if (currentVersion != null && currentVersion.equals(versionToCompare)) 
{
+  return true;
+}
+
+BigDecimal currentVersionDecimal = getVersionAsDecimal(currentVersion);
+BigDecimal versionToCompareDecimal = 
getVersionAsDecimal(versionToCompare);
+
+if (currentVersionDecimal != null && versionToCompareDecimal != null) {
--- End diff --

So for Drillbit with version 1.6 Drillbit with version 1.7 will be 
included, while for a Drillbit with version 1.7 Drillbit with version 1.6 will 
not be included?  Does it mean that at any particular time a particular 
Drillbit will have different view on the cluster from some other Drillbit?


> Drill should do version check among drillbits
> -
>
> Key: DRILL-4596
> URL: https://issues.apache.org/jira/browse/DRILL-4596
> Project: Apache Drill
>  Issue Type: New Feature
>Affects Versions: 1.6.0
>Reporter: Arina Ielchiieva
>Assignee: Arina Ielchiieva
> Fix For: Future
>
>
> Before registering new drillbit in zookeeper, we should do version check, and 
> make sure all the running drillbits are in the same version.
> Using drillbits of different version can lead to unexpected results.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (DRILL-4596) Drill should do version check among drillbits

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/DRILL-4596?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15235965#comment-15235965
 ] 

ASF GitHub Bot commented on DRILL-4596:
---

Github user arina-ielchiieva commented on the pull request:

https://github.com/apache/drill/pull/474#issuecomment-208557847
  
If we add new type to version 1.7, it can't work with  version 1.6 where 
this type is absent, that's why I am adding support only for +1 version. At 
this point in my implementation, 1.6 can work with 1.6 and 1.7. 1.7 can work 
with 1.7 and 1.8.


> Drill should do version check among drillbits
> -
>
> Key: DRILL-4596
> URL: https://issues.apache.org/jira/browse/DRILL-4596
> Project: Apache Drill
>  Issue Type: New Feature
>Affects Versions: 1.6.0
>Reporter: Arina Ielchiieva
>Assignee: Arina Ielchiieva
> Fix For: Future
>
>
> Before registering new drillbit in zookeeper, we should do version check, and 
> make sure all the running drillbits are in the same version.
> Using drillbits of different version can lead to unexpected results.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (DRILL-4596) Drill should do version check among drillbits

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/DRILL-4596?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15235952#comment-15235952
 ] 

ASF GitHub Bot commented on DRILL-4596:
---

Github user yufeldman commented on the pull request:

https://github.com/apache/drill/pull/474#issuecomment-208554692
  
Not sure how that comment contradicts with what I said. Adding new feature 
in the next version should not break previous version. 

> On Apr 11, 2016, at 12:41 PM, arina-ielchiieva  
wrote:
> 
> I thought it's hard to maintain backward compatibility. Quoting Parth 
comment from Jira:
> "Drill needs to be able to run queries that depend only on features that 
are in the oldest version of Drill in the cluster. Say for example, most 
drillbits are at version N and some are at version N+1. You added support for a 
new type foo in version N+1. Any queries not using or depending on type foo 
should run successfully. Queries depending on foo can only run successfully 
after all the drillbits are upgraded to N+1."
> 
> —
> You are receiving this because you commented.
> Reply to this email directly or view it on GitHub
> 



> Drill should do version check among drillbits
> -
>
> Key: DRILL-4596
> URL: https://issues.apache.org/jira/browse/DRILL-4596
> Project: Apache Drill
>  Issue Type: New Feature
>Affects Versions: 1.6.0
>Reporter: Arina Ielchiieva
>Assignee: Arina Ielchiieva
> Fix For: Future
>
>
> Before registering new drillbit in zookeeper, we should do version check, and 
> make sure all the running drillbits are in the same version.
> Using drillbits of different version can lead to unexpected results.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (DRILL-4596) Drill should do version check among drillbits

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/DRILL-4596?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15235409#comment-15235409
 ] 

ASF GitHub Bot commented on DRILL-4596:
---

Github user yufeldman commented on the pull request:

https://github.com/apache/drill/pull/474#issuecomment-208434359
  
Should it be +-1, not just +1 ? Otherwise in your scheme 1.9 can work with
2.0, but can not with 1.8, while 1.8 can work with 1.9.

On Mon, Apr 11, 2016 at 9:08 AM, arina-ielchiieva 
wrote:

> Updated PR.
> New implementation approach:
> 1. we allow to register any drillbit (disregarding the version).
> 2. instead of getting available endpoints from coordinator, we'll be
> receiving compatible endpoints. Version compatibility will be defined 
using
> main application version (major.minor (+ 1). For example, drillbit with
> version 1.8 can work with 1.8 and 1.9. Drillbit with version 1.9 can work
> with 1.9 and 2.0 and so on. Even during rolling upgrades, compatible
> endpoints will be able to work together.
>
> —
> You are receiving this because you commented.
> Reply to this email directly or view it on GitHub
> 
>



> Drill should do version check among drillbits
> -
>
> Key: DRILL-4596
> URL: https://issues.apache.org/jira/browse/DRILL-4596
> Project: Apache Drill
>  Issue Type: New Feature
>Affects Versions: 1.6.0
>Reporter: Arina Ielchiieva
>Assignee: Arina Ielchiieva
> Fix For: Future
>
>
> Before registering new drillbit in zookeeper, we should do version check, and 
> make sure all the running drillbits are in the same version.
> Using drillbits of different version can lead to unexpected results.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (DRILL-4596) Drill should do version check among drillbits

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/DRILL-4596?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15235374#comment-15235374
 ] 

ASF GitHub Bot commented on DRILL-4596:
---

Github user arina-ielchiieva commented on the pull request:

https://github.com/apache/drill/pull/474#issuecomment-208428822
  
Updated PR.
New implementation approach:
1. we allow to register any drillbit (disregarding the version).
2. instead of getting available endpoints from coordinator, we'll be 
receiving compatible endpoints. Version compatibility will be defined using 
main application version (major.minor (+ 1). For example, drillbit with version 
1.8 can work with 1.8 and 1.9. Drillbit with version 1.9 can work with 1.9 and 
2.0 and so on. Even during rolling upgrades, compatible endpoints will be able 
to work together.


> Drill should do version check among drillbits
> -
>
> Key: DRILL-4596
> URL: https://issues.apache.org/jira/browse/DRILL-4596
> Project: Apache Drill
>  Issue Type: New Feature
>Affects Versions: 1.6.0
>Reporter: Arina Ielchiieva
>Assignee: Arina Ielchiieva
> Fix For: Future
>
>
> Before registering new drillbit in zookeeper, we should do version check, and 
> make sure all the running drillbits are in the same version.
> Using drillbits of different version can lead to unexpected results.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (DRILL-4596) Drill should do version check among drillbits

[Arina Ielchiieva (JIRA)]

[ 
https://issues.apache.org/jira/browse/DRILL-4596?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15233563#comment-15233563
 ] 

Arina Ielchiieva commented on DRILL-4596:
-

[Parth|https://issues.apache.org/jira/secure/ViewProfile.jspa?name=parthc], 
thanks for use case.
So implementation approach can be the following:
1. we allow to register any drillbit (disregarding the version) in zookeeper.
2. version compatibility will be guaranteed during release, changes in modules 
(protobuf, rpc, etc) will influence main version number.
3. when issuing fragment, query to different drillbit, we will check if it's 
main version is compatible with our drillibit (N + 1). For example, drillbit 
with version 1.5 can work with 1.5 and 1.6.  Drillbit with version 1.6 can work 
with 1.6 and 1.7 and so on.

> Drill should do version check among drillbits
> -
>
> Key: DRILL-4596
> URL: https://issues.apache.org/jira/browse/DRILL-4596
> Project: Apache Drill
>  Issue Type: New Feature
>Affects Versions: 1.6.0
>Reporter: Arina Ielchiieva
>Assignee: Arina Ielchiieva
> Fix For: Future
>
>
> Before registering new drillbit in zookeeper, we should do version check, and 
> make sure all the running drillbits are in the same version.
> Using drillbits of different version can lead to unexpected results.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (DRILL-4596) Drill should do version check among drillbits

[Parth Chandra (JIRA)]

[ 
https://issues.apache.org/jira/browse/DRILL-4596?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15233145#comment-15233145
 ] 

Parth Chandra commented on DRILL-4596:
--

The common use case for having drillbits of different versions is for 
performing rolling upgrades, especially in a production environment. You never 
upgrade all the nodes in a cluster. You take a set of nodes offline, upgrade 
them, bring them online, repeat until all nodes are upgraded. During the 
upgrade, processes that require the older version of (any) software running 
continue to run as before.



> Drill should do version check among drillbits
> -
>
> Key: DRILL-4596
> URL: https://issues.apache.org/jira/browse/DRILL-4596
> Project: Apache Drill
>  Issue Type: New Feature
>Affects Versions: 1.6.0
>Reporter: Arina Ielchiieva
>Assignee: Arina Ielchiieva
> Fix For: Future
>
>
> Before registering new drillbit in zookeeper, we should do version check, and 
> make sure all the running drillbits are in the same version.
> Using drillbits of different version can lead to unexpected results.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (DRILL-4596) Drill should do version check among drillbits

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/DRILL-4596?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15232776#comment-15232776
 ] 

ASF GitHub Bot commented on DRILL-4596:
---

Github user arina-ielchiieva commented on a diff in the pull request:

https://github.com/apache/drill/pull/474#discussion_r59077998
  
--- Diff: 
exec/java-exec/src/main/java/org/apache/drill/exec/server/Drillbit.java ---
@@ -207,6 +209,28 @@ private void javaPropertiesToSystemOptions() {
   }
 
   /**
+   * Disallow registering drillbit when:
+   * 1. version is unknown;
+   * 2. drillbit with different version has been already registered.
+   */
+  private void checkVersion(DrillbitEndpoint endpoint) throws 
DrillbitStartupException {
+String currentVersion = endpoint.getVersion();
+if (DrillVersionInfo.UNKNOWN_VERSION.equals(currentVersion)) {
+  throw new DrillbitStartupException("Drillbit version is unknown.");
+}
+
+for (DrillbitEndpoint registeredEnpoint : 
coord.getAvailableEndpoints()) {
+  if (!currentVersion.equals(registeredEnpoint.getVersion())) {
--- End diff --

Agree. Probably it's better to compare each module major versions.


> Drill should do version check among drillbits
> -
>
> Key: DRILL-4596
> URL: https://issues.apache.org/jira/browse/DRILL-4596
> Project: Apache Drill
>  Issue Type: New Feature
>Affects Versions: 1.6.0
>Reporter: Arina Ielchiieva
>Assignee: Arina Ielchiieva
> Fix For: Future
>
>
> Before registering new drillbit in zookeeper, we should do version check, and 
> make sure all the running drillbits are in the same version.
> Using drillbits of different version can lead to unexpected results.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (DRILL-4596) Drill should do version check among drillbits

[Arina Ielchiieva (JIRA)]

[ 
https://issues.apache.org/jira/browse/DRILL-4596?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15232774#comment-15232774
 ] 

Arina Ielchiieva commented on DRILL-4596:
-

[Parth|https://issues.apache.org/jira/secure/ViewProfile.jspa?name=parthc],
I can't think of use case when customer would like to have drillbits with 
different versions. 
If we want to test out new drillibit version, we can just simply set different 
cluster-id.
Though, I agree that it makes sense to check each module for version 
compatibility. Let's say, compare each module major version only.
Does it sound reasonable?

> Drill should do version check among drillbits
> -
>
> Key: DRILL-4596
> URL: https://issues.apache.org/jira/browse/DRILL-4596
> Project: Apache Drill
>  Issue Type: New Feature
>Affects Versions: 1.6.0
>Reporter: Arina Ielchiieva
>Assignee: Arina Ielchiieva
> Fix For: Future
>
>
> Before registering new drillbit in zookeeper, we should do version check, and 
> make sure all the running drillbits are in the same version.
> Using drillbits of different version can lead to unexpected results.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (DRILL-4596) Drill should do version check among drillbits

[Parth Chandra (JIRA)]

[ 
https://issues.apache.org/jira/browse/DRILL-4596?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15232694#comment-15232694
 ] 

Parth Chandra commented on DRILL-4596:
--

I think it is too strict to require all drillbits to have the same version.
In general, we need to allow drillbits of different 'compatible' versions to 
allow to exist in a cluster. Compatibility itself is defined at multiple levels 
-
  Protobuf - Protobuf guarantees compatibility if fields are declared as 
OPTIONAL. So any changes to protobuf messages should really only add new fields 
and they should be optional.
  RPC - The RPC layer checks for an RPC version for any 
{user|control|data}client connecting to a {user|control|data}server. It would 
be nice to have a major and minor version of the RPC version where we guarantee 
that minor versions are compatible. Note that RPC version can change if there 
is a change to the Protobuf object or to the protocol itself.
  Application - Drill needs to be able to run queries that depend only on 
features that are in the oldest version of Drill in the cluster.  Say for 
example, most drillbits are at version N and some are at version N+1. You added 
support for a new type foo in  version N+1. Any queries not using or depending 
on type foo should run successfully. Queries depending on foo can only run 
successfully after all the drillbits are upgraded to N+1. 

> Drill should do version check among drillbits
> -
>
> Key: DRILL-4596
> URL: https://issues.apache.org/jira/browse/DRILL-4596
> Project: Apache Drill
>  Issue Type: New Feature
>Affects Versions: 1.6.0
>Reporter: Arina Ielchiieva
>Assignee: Arina Ielchiieva
> Fix For: Future
>
>
> Before registering new drillbit in zookeeper, we should do version check, and 
> make sure all the running drillbits are in the same version.
> Using drillbits of different version can lead to unexpected results.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (DRILL-4596) Drill should do version check among drillbits

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/DRILL-4596?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15232605#comment-15232605
 ] 

ASF GitHub Bot commented on DRILL-4596:
---

Github user sudheeshkatkam commented on a diff in the pull request:

https://github.com/apache/drill/pull/474#discussion_r59065316
  
--- Diff: 
exec/java-exec/src/main/java/org/apache/drill/exec/server/Drillbit.java ---
@@ -207,6 +209,28 @@ private void javaPropertiesToSystemOptions() {
   }
 
   /**
+   * Disallow registering drillbit when:
+   * 1. version is unknown;
+   * 2. drillbit with different version has been already registered.
+   */
+  private void checkVersion(DrillbitEndpoint endpoint) throws 
DrillbitStartupException {
+String currentVersion = endpoint.getVersion();
+if (DrillVersionInfo.UNKNOWN_VERSION.equals(currentVersion)) {
+  throw new DrillbitStartupException("Drillbit version is unknown.");
+}
+
+for (DrillbitEndpoint registeredEnpoint : 
coord.getAvailableEndpoints()) {
+  if (!currentVersion.equals(registeredEnpoint.getVersion())) {
--- End diff --

How does this check work with regards to [protobuf backwards 
compatibility](https://developers.google.com/protocol-buffers/docs/javatutorial#extending-a-protocol-buffer)?
 Endpoints currently do not have a version. So if two bits (A and B), one with 
and one without this change, are started, the two start order cases (A after B, 
and B after A) should pass.


> Drill should do version check among drillbits
> -
>
> Key: DRILL-4596
> URL: https://issues.apache.org/jira/browse/DRILL-4596
> Project: Apache Drill
>  Issue Type: New Feature
>Affects Versions: 1.6.0
>Reporter: Arina Ielchiieva
>Assignee: Arina Ielchiieva
> Fix For: Future
>
>
> Before registering new drillbit in zookeeper, we should do version check, and 
> make sure all the running drillbits are in the same version.
> Using drillbits of different version can lead to unexpected results.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (DRILL-4596) Drill should do version check among drillbits

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/DRILL-4596?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15232602#comment-15232602
 ] 

ASF GitHub Bot commented on DRILL-4596:
---

Github user JohnOmernik commented on a diff in the pull request:

https://github.com/apache/drill/pull/474#discussion_r59064857
  
--- Diff: 
exec/java-exec/src/main/java/org/apache/drill/exec/server/Drillbit.java ---
@@ -207,6 +209,28 @@ private void javaPropertiesToSystemOptions() {
   }
 
   /**
+   * Disallow registering drillbit when:
+   * 1. version is unknown;
+   * 2. drillbit with different version has been already registered.
--- End diff --

Agreed.  In addition to potential soft enforcement, I think we should 
consider the differences of a version defined in a pom.xml, the version of the 
running drillbit, and the version of a drill cluster.  By using a setting in 
drill-override to specify what the drill cluster version is, we don't get 
accident "first bit to register is the wrong version" situations.  Are there 
situations where we might want to allow a specific Drill version + all minor 
versions at that level, or Drill version + 1 Major version for rolling upgrades?


> Drill should do version check among drillbits
> -
>
> Key: DRILL-4596
> URL: https://issues.apache.org/jira/browse/DRILL-4596
> Project: Apache Drill
>  Issue Type: New Feature
>Affects Versions: 1.6.0
>Reporter: Arina Ielchiieva
>Assignee: Arina Ielchiieva
> Fix For: Future
>
>
> Before registering new drillbit in zookeeper, we should do version check, and 
> make sure all the running drillbits are in the same version.
> Using drillbits of different version can lead to unexpected results.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (DRILL-4596) Drill should do version check among drillbits

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/DRILL-4596?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15232577#comment-15232577
 ] 

ASF GitHub Bot commented on DRILL-4596:
---

Github user yufeldman commented on a diff in the pull request:

https://github.com/apache/drill/pull/474#discussion_r59063793
  
--- Diff: 
exec/java-exec/src/main/java/org/apache/drill/exec/server/Drillbit.java ---
@@ -207,6 +209,28 @@ private void javaPropertiesToSystemOptions() {
   }
 
   /**
+   * Disallow registering drillbit when:
+   * 1. version is unknown;
+   * 2. drillbit with different version has been already registered.
--- End diff --

What if you first DrillBit registered had "bad" version? Somebody would 
have to bring it down, so others can start?
Should it be (at least) option to have soft enforcement, rather than just 
hard enforcement.


> Drill should do version check among drillbits
> -
>
> Key: DRILL-4596
> URL: https://issues.apache.org/jira/browse/DRILL-4596
> Project: Apache Drill
>  Issue Type: New Feature
>Affects Versions: 1.6.0
>Reporter: Arina Ielchiieva
>Assignee: Arina Ielchiieva
> Fix For: Future
>
>
> Before registering new drillbit in zookeeper, we should do version check, and 
> make sure all the running drillbits are in the same version.
> Using drillbits of different version can lead to unexpected results.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (DRILL-4596) Drill should do version check among drillbits

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/DRILL-4596?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15232536#comment-15232536
 ] 

ASF GitHub Bot commented on DRILL-4596:
---

Github user arina-ielchiieva commented on the pull request:

https://github.com/apache/drill/pull/474#issuecomment-207529907
  
Drill version is defined from build manifest file [1].
There is no config setting to override it. Though if you want to change 
version in "master", you'll have to update version property in pom.xml files. 
(1.7.0-SNAPSHOT)

[1] 
https://github.com/apache/drill/blob/master/common/src/main/java/org/apache/drill/common/util/DrillVersionInfo.java



> Drill should do version check among drillbits
> -
>
> Key: DRILL-4596
> URL: https://issues.apache.org/jira/browse/DRILL-4596
> Project: Apache Drill
>  Issue Type: New Feature
>Affects Versions: 1.6.0
>Reporter: Arina Ielchiieva
>Assignee: Arina Ielchiieva
> Fix For: Future
>
>
> Before registering new drillbit in zookeeper, we should do version check, and 
> make sure all the running drillbits are in the same version.
> Using drillbits of different version can lead to unexpected results.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (DRILL-4596) Drill should do version check among drillbits

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/DRILL-4596?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15232497#comment-15232497
 ] 

ASF GitHub Bot commented on DRILL-4596:
---

Github user JohnOmernik commented on the pull request:

https://github.com/apache/drill/pull/474#issuecomment-207520784
  
So how is the version actually set? Is it just the bit to register with 
Drill? Is there a config setting that we can set in drill-override that sets 
the cluster version?  Where is the "master" version stored, and how do we move 
away from that? 

Thanks


> Drill should do version check among drillbits
> -
>
> Key: DRILL-4596
> URL: https://issues.apache.org/jira/browse/DRILL-4596
> Project: Apache Drill
>  Issue Type: New Feature
>Affects Versions: 1.6.0
>Reporter: Arina Ielchiieva
>Assignee: Arina Ielchiieva
> Fix For: Future
>
>
> Before registering new drillbit in zookeeper, we should do version check, and 
> make sure all the running drillbits are in the same version.
> Using drillbits of different version can lead to unexpected results.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (DRILL-4596) Drill should do version check among drillbits

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/DRILL-4596?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15232487#comment-15232487
 ] 

ASF GitHub Bot commented on DRILL-4596:
---

GitHub user arina-ielchiieva opened a pull request:

https://github.com/apache/drill/pull/474

DRILL-4596: Drill should do version check among drillbits



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/arina-ielchiieva/drill DRILL-4596

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/drill/pull/474.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #474


commit 76e857c29becee22daf116dd58a36fe34a920595
Author: Arina Ielchiieva 
Date:   2016-04-08T14:22:47Z

DRILL-4596: Drill should do version check among drillbits




> Drill should do version check among drillbits
> -
>
> Key: DRILL-4596
> URL: https://issues.apache.org/jira/browse/DRILL-4596
> Project: Apache Drill
>  Issue Type: New Feature
>Affects Versions: 1.6.0
>Reporter: Arina Ielchiieva
>Assignee: Arina Ielchiieva
> Fix For: Future
>
>
> Before registering new drillbit in zookeeper, we should do version check, and 
> make sure all the running drillbits are in the same version.
> Using drillbits of different version can lead to unexpected results.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)