Hello All,
With the allocator changes merged and about a month since the last release
I think it would be good to start a vote soon. I would like to volunteer to
be release manager.
I know that there were some issues that were identified after the transfer
patch was merged. I think that these iss
https://issues.apache.org/jira/browse/DRILL-4190
https://issues.apache.org/jira/browse/DRILL-4196
I'm working on a fix for both of these.
On Mon, Jan 4, 2016 at 1:48 PM, Jason Altekruse
wrote:
> Hello All,
>
> With the allocator changes merged and about a month since the last release
> I think
We are seeing an IllegalStateException in one of functional tests
(flatten), I already reported it in DRILL-4246, I think this should be
fixed as part of 1.5 release [1]
[1] https://issues.apache.org/jira/browse/DRILL-4246
On Mon, Jan 4, 2016 at 1:52 PM, Amit Hadke wrote:
> https://issues.apach
I just noticed that we never fixed DRILL-4174 [1], it's a one line fix and
would like to get it in 1.5 release.
[1] https://issues.apache.org/jira/browse/DRILL-4174
On Mon, Jan 4, 2016 at 1:59 PM, Abdel Hakim Deneche
wrote:
> We are seeing an IllegalStateException in one of functional tests
> (
I am working on a fix for Drill-4203 that I would like to have included in
1.5. A user trying to read dates out of a Drill produced parquet file from
spark was getting back incorrect data. Unfortunately we have been writing a
non-standard format for dates that we have just been reading correctly in
https://issues.apache.org/jira/browse/DRILL-4239 (Drill reported not to
work on 32-bit Windows) has been opened as a doc bug, but maybe we're
actually talking about a product bug. If so, how about a fix in 1.5?
Kristine Hahn
Sr. Technical Writer
415-497-8107 @krishahn skype:krishahn
On Mon, Jan
What about https://issues.apache.org/jira/browse/DRILL-4247 and
https://issues.apache.org/jira/browse/DRILL-4256? 4256 appears to be a
regression. Not sure about 4247.
-- Zelaine
On Tue, Jan 5, 2016 at 12:20 PM, Kristine Hahn wrote:
> https://issues.apache.org/jira/browse/DRILL-4239 (Drill re
Kristine,
I think that this would be a good thing to get fixed for the release, but
it looks like we will need to mess with building or packaging different
windows binaries to fix this issue. As far as I know Parth has been
carrying the majority of this type of work in the past and had a bit of a
I think 4247 is definitely worth trying to get into the release as it has
performance implications for a typical use case, partitioning by date. I
will be looking at this today to try to figure out what is causing it, I
don't anticipate it being difficult to fix.
I also agree 4256 should be fixed
Bumping this thread...
Here are the issues that were mentioned in this thread along with a
proposed categorization:
Release Blockers
In-progress Amit https://issues.apache.org/jira/browse/DRILL-4190
In-progress Amit https://issues.apache.org/jira/browse/DRILL-4196
Ready to merge Jacques https://i
I still saw mvn full build failed on linux due to the following unit
test case sometime:
Tests in error:
TestTopNSchemaChanges.testMissingColumn:206 ยป at position 0 column
'`kl1`' mi...
Either we comment out that unit test, or we should fix the test case.
Otherwise, people may see maven build
Jinfeng, can you open a jira for the failing test if one isn't open?
--
Jacques Nadeau
CTO and Co-Founder, Dremio
On Wed, Jan 20, 2016 at 7:57 AM, Jinfeng Ni wrote:
> I still saw mvn full build failed on linux due to the following unit
> test case sometime:
>
> Tests in error:
> TestTopNSchem
I merged a patch yesterday that I believe addresses that issue. Can you see
if you still hit it?
On Thu, Jan 21, 2016 at 8:39 AM, Jacques Nadeau wrote:
> Jinfeng, can you open a jira for the failing test if one isn't open?
>
> --
> Jacques Nadeau
> CTO and Co-Founder, Dremio
>
> On Wed, Jan 20,
Looks like there was a patch merged in yesterday, and it modified the
testcase [1].
While looking at the previous test, seems the expected results are not
right. (order by "DESC" should use NULL FIRST policy). I'm surprised
how it would happen with such random failure behavior.
[1]
https://gith
Any updates on this? What's blocking us from taking this to a vote -- the
sort merge join issues?
-- Zelaine
On Tue, Jan 19, 2016 at 4:18 PM, Jacques Nadeau wrote:
> Bumping this thread...
>
> Here are the issues that were mentioned in this thread along with a
> proposed categorization:
>
> Re
I think the main things are 4196 and 4291 should be completed. I know Amit
was able to reproduce 4196 locally this weekend so I think we're close on
that.
--
Jacques Nadeau
CTO and Co-Founder, Dremio
On Mon, Jan 25, 2016 at 10:14 AM, Zelaine Fong wrote:
> Any updates on this? What's blocking u
4196 was merged today. I have an updated patch for 4291 that is ready.
Unfortunately, it seems that something isn't working with our extended
tests so I haven't been able to run an extended regression. Unit tests
pass. Is someone else possibly able to run a regression suite against this
branch [1]
Kicked off a functional run with your branch. Will let you know once it
finishes
- Rahul
On Wed, Jan 27, 2016 at 9:56 PM, Jacques Nadeau wrote:
> 4196 was merged today. I have an updated patch for 4291 that is ready.
> Unfortunately, it seems that something isn't working with our extended
> tes
Jacques, I've scheduled Functional and Advanced regression runs against the
specified branch. Will let you know the results, once completed.
Regards,
Abhishek
On Wed, Jan 27, 2016 at 9:56 PM, Jacques Nadeau wrote:
> 4196 was merged today. I have an updated patch for 4291 that is ready.
> Unfort
Had two clean Functional runs. TPC-H SF100 was also successful.
On Wed, Jan 27, 2016 at 10:07 PM, rahul challapalli <
challapallira...@gmail.com> wrote:
> Kicked off a functional run with your branch. Will let you know once it
> finishes
>
> - Rahul
>
> On Wed, Jan 27, 2016 at 9:56 PM, Jacques Na
I got clean regression runs as well. I've merged the patch.
Jason, you want to start the release process?
--
Jacques Nadeau
CTO and Co-Founder, Dremio
On Wed, Jan 27, 2016 at 10:42 PM, Abhishek Girish wrote:
> Had two clean Functional runs. TPC-H SF100 was also successful.
>
> On Wed, Jan 27,
Hmm... this merge caused the Apache build to fail. Investigating...
--
Jacques Nadeau
CTO and Co-Founder, Dremio
On Thu, Jan 28, 2016 at 6:31 AM, Jacques Nadeau wrote:
> I got clean regression runs as well. I've merged the patch.
>
> Jason, you want to start the release process?
>
> --
> Jacque
Build back to normal. It looks like the Apache server was using an old
version of Maven. Once I switched to something more recent, the build
passed.
--
Jacques Nadeau
CTO and Co-Founder, Dremio
On Thu, Jan 28, 2016 at 7:02 AM, Jacques Nadeau wrote:
> Hmm... this merge caused the Apache build to
Jacques, I am getting the following build failure on the latest master
branch...is this what you saw for the Apache build ? My mvn version output
is shown below. Should we all be upgrading to a newer mvn ?
[INFO] --- maven-enforcer-plugin:1.3.1:enforce
(enforce-jdbc-jar-compactness) @ drill-jdb
Hi Aman,
This is the failure that he was seeing. He figured out that the new
exclusions in jdbc-all were not being respected when the build was run with
an older Maven version, causing the jar size to increase significantly. He
added an enforcer to make sure the JAR didn't grow unexpectedly. Can y
I upgraded to mvn 3.3.9 (using brew install maven) on my mac. I ran into
some other issues .. running out of PermGen and when I bumped it up to
256M, ran into OutOfMemoryError during the build. I will have more time
later today to look into it.
On Thu, Jan 28, 2016 at 11:23 AM, Jason Altekruse
I just wanted to bring up an issue that I just now discovered, that has
caused me a fair amount of grief.
https://github.com/apache/drill/pull/300/commits
DRILL-4198 changes a user-facing API, and causes StoragePlugins that were
compiled against currently released versions of Drill to no longer
f
Sorry I didn't realize I was breaking the public interface API. Let me work
on a patch to make it backward compatible.
Thanks
Venki
On Thu, Jan 28, 2016 at 12:54 PM, Steven Phillips wrote:
> I just wanted to bring up an issue that I just now discovered, that has
> caused me a fair amount of gri
Just found an issue with hive native parquet reader (DRILL-4323). This is a
regression from 1.4 and in my opinion should be treated as a blocker.
- Rahul
On Thu, Jan 28, 2016 at 1:12 PM, Venki Korukanti
wrote:
> Sorry I didn't realize I was breaking the public interface API. Let me work
> on a
I think it makes sense to wait for Venki's fix of the API, as releasing a
version with the change would make reverting/refactoring the API breaking
change less useful.
Do you have any idea about the scope of fixing the hive native reader, or
which change since the 1.4 release broke it? Is someone
Jason,
As of now I haven't narrowed down the exact commit which caused DRILL-4323
and I do not know the scope of the fix.
- Rahul
On Thu, Jan 28, 2016 at 1:39 PM, Jason Altekruse
wrote:
> I think it makes sense to wait for Venki's fix of the API, as releasing a
> version with the change would
Aman, for reference on the Maven version issue. You can see the output of
the shade plugin between the two Apache Builds. If you search for
maven-shade-plugin you'll see that build 647 (maven 3.0.5) fails because it
includes a bunch of hadoop (and other libraries that are listed as being
excluded).
I was able to do the build with maven 3.3.9 (after doing 'brew install
maven'). Here are my env variables related to maven:
M2_HOME=/usr/local/Cellar/maven/3.3.9/libexec
M2=/usr/local/Cellar/maven/3.3.9/libexec/bin
MAVEN_OPTS=-Xmx2048m -XX:MaxPermSize=256m
On Thu, Jan 28, 2016 at 2:20 PM, Jacque
Here is the partial fix:
https://github.com/vkorukanti/drill/commit/6646b0d08df274a22dff870ad5e6f6914b10fa0b
If the existing StragePlugins are implementing AbstractStoragePlugin class
this fix should resolve the backward compat issue. If they are implementing
StoragePlugin interface directly then
We could revert the change to the StoragePlugin interface to add the
getLogicalOptimizerRules
and getPhysicalOptimizerRules, and only put those in AbstractStoragePlugin
with default implementations.
We could then update the docs to tell users to not implement the interface
directly, and instead ex
Venki and I did some investigation for DRILL-4323. The issue reported
in DRILL-4323 seems to happen on 1.4.0 release as well. Seems to us
this is not a regression from 1.4.0; it's a regression from 1.3.0
probably.
DRILL-4083 makes the planner to use DrillHiveNativeReader in stead of
HiveReader for
I am running drill-1.4 and is able to run count(*) successfully.
0: jdbc:drill:zk=10.10.100.113:5181,10.10.100> alter session set
`store.hive.optimize_scan_with_native_readers` = true;
+---++
| ok |summary
Krystal, by any chance, did you turn on assertion when you start drillbit?
I think the error in drill-4323 will be raised when assertion = on.
On Fri, Jan 29, 2016 at 8:31 AM, Krystal Nguyen wrote:
> I am running drill-1.4 and is able to run count(*) successfully.
>
> 0: jdbc:drill:zk=10.10.10
Removing updates from StoragePlugin seems like a good approach. Will update
the patch soon.
On Thu, Jan 28, 2016 at 3:42 PM, Jason Altekruse
wrote:
> We could revert the change to the StoragePlugin interface to add the
> getLogicalOptimizerRules
> and getPhysicalOptimizerRules, and only put thos
I do see the same error with assertion turned on.
On Fri, Jan 29, 2016 at 8:45 AM, Jinfeng Ni wrote:
> Krystal, by any chance, did you turn on assertion when you start drillbit?
>
> I think the error in drill-4323 will be raised when assertion = on.
>
>
>
> On Fri, Jan 29, 2016 at 8:31 AM, Kryst
Rahul,
Let us know if you can reproduce the issue with assertions turned OFF. If
you cannot, then I think this should not be a blocker for 1.5, and Hsuan
will continue to look into fixing this.
-- Zelaine
On Fri, Jan 29, 2016 at 12:11 PM, Krystal Nguyen
wrote:
> I do see the same error with a
DRILL-4323 only happens when assertions are turned on (my install script
automatically enables assertions).
- Rahul
On Fri, Jan 29, 2016 at 12:40 PM, Zelaine Fong wrote:
> Rahul,
>
> Let us know if you can reproduce the issue with assertions turned OFF. If
> you cannot, then I think this shoul
Sean probably is quite close to find a fix for this issue. Let's see
whether he can post a patch soon.
On Fri, Jan 29, 2016 at 1:29 PM, rahul challapalli
wrote:
> DRILL-4323 only happens when assertions are turned on (my install script
> automatically enables assertions).
>
> - Rahul
>
> On Fri,
Yes, just send a pull request.
https://github.com/apache/drill/pull/349
Can Jinfeng review it?
Thanks,
On Fri, Jan 29, 2016 at 1:53 PM, Jinfeng Ni wrote:
> Sean probably is quite close to find a fix for this issue. Let's see
> whether he can post a patch soon.
>
>
> On Fri, Jan 29, 2016 at 1:2
Hey Jason,
Can you start the release vote? We've let this drag on too long.
I suggest we start from 03197d0f2. It seems like the partition pruning
changes are pretty complicated and on a pretty main path to add right
before the vote. Since Hsuan's fix (pr 349) hasn't been reviewed, I think
we sho
That sounds reasonable to me. I'll start preparing a release candidate.
Jinfeng, are you okay waiting for the next release to include this change?
On Sun, Jan 31, 2016 at 4:49 PM, Jacques Nadeau wrote:
> Hey Jason,
>
> Can you start the release vote? We've let this drag on too long.
>
> I sugge
Hi Jason,
I'm fine that release 1.5.0 starts from 03197d0f2. One thing I need
point out is that the pre-commit test suite has some testcase's plan
output modified because of the partition pruning change. If we run
pre-commit against the candidate release for 1.5.0, we have to use a
prior version
Jinfeng, do you agree that the changes are risky? I was going mostly by
commit messages.
Also just realized that the backwards compatibility fix to the storage
plugin interface is after these. Could create release branch from 03197d...
and then cherry pick the Venki change. Or could keep them all.
Venki's backwards compatibility fix (commit id:
03197d0) is before the partition pruning commit. So, it seems to be
fine to create a release candidate from 03197d0; no need to
cherry-pick.
As for whether the partition pruning changes are risky, the pre-commit
run did not show any serious proble
Given how easy it is to create a branch off a random commit, I generally
don't see a point in closing the master branch. I figure the release
manager can propose where they'd like to fork if this type of thing comes
up.
Thanks for the feedback Jinfeng. Of course you're right about Venki's
commit.
I don't think there was any issue with the merge either Jinfeng, I don't
think we need to close master. I had to step out for a few hours, but I am
working on finishing up the candidate right now.
Having a weird RAT issue running the actual maven release command, it's
complaining about a dependenc
Good to hear this, Jacques & Jason. That makes feel relieved. :-)
On Sun, Jan 31, 2016 at 10:36 PM, Jason Altekruse
wrote:
> I don't think there was any issue with the merge either Jinfeng, I don't
> think we need to close master. I had to step out for a few hours, but I am
> working on finishi
The only solution to this issue I have found is disabling the new plugin to
automatically enforce the size of the jdbc-all plugin. I don't know why it
is behaving differently when performing a release than it did during a 'mvn
install', but I have verified the correct size of the JAR manually and a
A question for previous release managers. Jacques was thinking I may need
to have my GPG signed to get linked into the Apache Web of Trust. Is this
necessary for making a release?
On Mon, Feb 1, 2016 at 11:24 AM, Jason Altekruse
wrote:
> The only solution to this issue I have found is disabling
I have trouble understanding the meaning of "GPG signed" =P
On Mon, Feb 1, 2016 at 1:27 PM, Jason Altekruse
wrote:
> A question for previous release managers. Jacques was thinking I may need
> to have my GPG signed to get linked into the Apache Web of Trust. Is this
> necessary for making a rele
Fair enough. I meant having my public GPG key signed by someone already in
the Apache web of trust.
On Mon, Feb 1, 2016 at 1:39 PM, Abdel Hakim Deneche
wrote:
> I have trouble understanding the meaning of "GPG signed" =P
>
> On Mon, Feb 1, 2016 at 1:27 PM, Jason Altekruse
> wrote:
>
>> A questi
Oh, I see. I didn't have to do it.
On Mon, Feb 1, 2016 at 1:42 PM, Jason Altekruse
wrote:
> Fair enough. I meant having my public GPG key signed by someone already in
> the Apache web of trust.
>
> On Mon, Feb 1, 2016 at 1:39 PM, Abdel Hakim Deneche > wrote:
>
>> I have trouble understanding th
57 matches
Mail list logo
