Re: [DISCUSS] Curator client upgrade
+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 running into before when trying to use curator-tests 4.x https://issues.apache.org/jira/browse/CURATOR-446. Fixed in 4.0.1, which would naturally be included with 4.2.0 assuming we don't run into any other classpath or API compatibility issues. On Tue, Sep 17, 2019 at 11:20 AM Nick Allen wrote: > +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 the feature branch before it has a chance to > break anything in master. > > On Tue, Sep 17, 2019 at 1:13 PM Michael Miklavcic < > michael.miklav...@gmail.com> wrote: > > > 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 > > additional impacts while working through the Hadoop upgrade branch as > well. > > We're now looking at splitting this out into a separate PR in the feature > > branch. Curator 4.0.0 is backwards compatible and will work with > Zookeeper > > 3.4.6. Strictly speaking, this *could* be done against master first, but > > there may be some duplicate testing effort there, and I'm really not it's > > worth it as there is absolutely no issue currently with Curator 2.12.0 in > > master - I call this out purely for transparency/information share with > the > > community. I'm leaning towards us making this change against the feature > > branch directly as that is the only place we currently have compatibility > > issues. > > > > Best, > > Mike > > >
Re: [DISCUSS] Curator client upgrade
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/CURATOR-446. Fixed in 4.0.1, which would naturally be included with 4.2.0 assuming we don't run into any other classpath or API compatibility issues. On Tue, Sep 17, 2019 at 11:20 AM Nick Allen wrote: > +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 the feature branch before it has a chance to > break anything in master. > > On Tue, Sep 17, 2019 at 1:13 PM Michael Miklavcic < > michael.miklav...@gmail.com> wrote: > > > 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 > > additional impacts while working through the Hadoop upgrade branch as > well. > > We're now looking at splitting this out into a separate PR in the feature > > branch. Curator 4.0.0 is backwards compatible and will work with > Zookeeper > > 3.4.6. Strictly speaking, this *could* be done against master first, but > > there may be some duplicate testing effort there, and I'm really not it's > > worth it as there is absolutely no issue currently with Curator 2.12.0 in > > master - I call this out purely for transparency/information share with > the > > community. I'm leaning towards us making this change against the feature > > branch directly as that is the only place we currently have compatibility > > issues. > > > > Best, > > Mike > > >
Re: [DISCUSS] Curator client upgrade
+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 the feature branch before it has a chance to break anything in master. On Tue, Sep 17, 2019 at 1:13 PM Michael Miklavcic < michael.miklav...@gmail.com> wrote: > 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 > additional impacts while working through the Hadoop upgrade branch as well. > We're now looking at splitting this out into a separate PR in the feature > branch. Curator 4.0.0 is backwards compatible and will work with Zookeeper > 3.4.6. Strictly speaking, this *could* be done against master first, but > there may be some duplicate testing effort there, and I'm really not it's > worth it as there is absolutely no issue currently with Curator 2.12.0 in > master - I call this out purely for transparency/information share with the > community. I'm leaning towards us making this change against the feature > branch directly as that is the only place we currently have compatibility > issues. > > Best, > Mike >
[DISCUSS] Curator client upgrade
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 additional impacts while working through the Hadoop upgrade branch as well. We're now looking at splitting this out into a separate PR in the feature branch. Curator 4.0.0 is backwards compatible and will work with Zookeeper 3.4.6. Strictly speaking, this *could* be done against master first, but there may be some duplicate testing effort there, and I'm really not it's worth it as there is absolutely no issue currently with Curator 2.12.0 in master - I call this out purely for transparency/information share with the community. I'm leaning towards us making this change against the feature branch directly as that is the only place we currently have compatibility issues. Best, Mike
