FYI - we were able to move forward on getting Kerberos working without
requiring a Curator upgrade. We probably want to consider some architecture
changes around how we manage this queue in MaaS at some point, however
right now we will be continuing with the current version of Curator. The
Zookeepe
Discussed this a bit further with Nick and Ryan offline. The original issue
with Curator appears to have come up during Kerberos testing. Storm brings
in a whole host of extra libs when Kerberos is enabled (some preliminary
testing was started in parallel to the HBase and Hadoop upgrades). I'm told
+1
On September 17, 2019 at 14:53:13, Michael Miklavcic (
michael.miklav...@gmail.com) wrote:
Also, caught this come through the HBase dev list -
https://issues.apache.org/jira/browse/HBASE-23032. Might be worth a look at
4.2.0 while we're at it and possibly also avoid this issue that I was
ru
Also, caught this come through the HBase dev list -
https://issues.apache.org/jira/browse/HBASE-23032. Might be worth a look at
4.2.0 while we're at it and possibly also avoid this issue that I was
running into before when trying to use curator-tests 4.x
https://issues.apache.org/jira/browse/CURATO
+1 to making the change on the feature branch.
We don't really know how this might affect master which is still building
against HDP 2.6, nor is it strictly needed there. Going to Curator 4.0.0
is only needed due to the HDP 3.1 upgrade. This is also likely to get
more focused testing cycles in
Hey all,
While working through the feature branch upgrade for HDP 3.1, we came
across some classpath related issues conflicting with Storm and Guava while
testing out Kerberos. Initially, this seemed reasonable to roll into the
Kerberos fix PR, but the scope has expanded a bit because we found
add
