You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@curator.apache.org by "Phong X. Nguyen" <p....@yahooinc.com> on 2021/12/14 00:48:03 UTC
Curator, Zookeeper and Guava woes (again)
I posted about this earlier this year but I'm not sure if this was fully
resolved.
We're currently on Guava 14, Zookeeper 3.5.7 and Curator 2.4.2.
We'd like to upgrade to a reasonably recent version of Guava. That requires
an upgrade to Curator 4, but that brings in the problem reported in
CURATOR-526 and ZOOKEEPER-3577. Our Zookeeper configuration uses the old
securedClientPort setting, which is currently unavailable in the new
Dynamic Reconfiguration file format and thus is rejected by Zookeeper's new
EnsembleTracker.
As far as I can tell, CURATOR-526 just silences the log message, but upon
trying to read through the code, it doesn't look like the internal
EnsembleTracker will be properly populated as it won't read the old
securedClientPort configuration. If that can't be resolved, for newer
versions of Zookeeper, is there an alternative to securedClientPort?
Is there a way out of this situation without deploying our own
custom-patched Curator 2 or Curator 3 in which we remove Guava
dependencies? Merely upgrading to Guava 17 isn't much of a win for us (and
meanwhile our automated security scanners keep yelling at us for using
outdated libraries)
Sorry to bug everyone again, but the old version of Guava that we're stuck
with is starting to cause serious problems as certain libraries are
requiring newer versions of Guava, and we cannot upgrade (even to fix
CVEs).
Thanks,
- Phong X. Nguyen
Re: [E] Curator, Zookeeper and Guava woes (again)
Posted by "Phong X. Nguyen" <p....@yahooinc.com>.
On Tue, Dec 14, 2021 at 1:54 PM Jordan Zimmerman <jo...@jordanzimmerman.com>
wrote:
> It looks like someone attempted to shade Curator 2.13.0 and Curator 3.3.0,
> but it was only done for curator-client.
>
>
> No - all of Curator is shaded except for 3 classes (that part was fixed in
> Curator 5). We have a Tech Note on this:
> https://cwiki.apache.org/confluence/display/CURATOR/TN13
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__cwiki.apache.org_confluence_display_CURATOR_TN13&d=DwMFAg&c=sWW_bEwW_mLyN3Kx2v57Q8e-CRbmiT9yOhqES_g_wVY&r=O70g06ptcR0kFf_F97KEE28PSob_XuRM9pHP9am9rP0&m=EceFBtmaNvNSlif9tbBeXA1qk-rV70CALIMo_syINHgWtCqCFuZmMP1xMsYU2x0j&s=x-OIzYHZADz0jHnjeD79blQ7sP6qD3KWr2oaAqhcbD0&e=> -
> you can merely exclude Guava when adding a dependency to it (In Maven use
> the <excludes> tag). So, if you're able to upgrade to Curator 2.12.x you
> should have no problems.
>
> -Jordan
>
>
My IDE's disassembler was playing tricks with the fully qualified class
names and misleading me. I disassembled the classes in javap instead and I
see the disassembly pointing to the 'right' place.
Thank you very much!
Re: [E] Curator, Zookeeper and Guava woes (again)
Posted by Jordan Zimmerman <jo...@jordanzimmerman.com>.
> It looks like someone attempted to shade Curator 2.13.0 and Curator 3.3.0, but it was only done for curator-client.
No - all of Curator is shaded except for 3 classes (that part was fixed in Curator 5). We have a Tech Note on this: https://cwiki.apache.org/confluence/display/CURATOR/TN13 <https://cwiki.apache.org/confluence/display/CURATOR/TN13> - you can merely exclude Guava when adding a dependency to it (In Maven use the <excludes> tag). So, if you're able to upgrade to Curator 2.12.x you should have no problems.
-Jordan
> On Dec 14, 2021, at 7:56 PM, Phong X. Nguyen <p....@yahooinc.com> wrote:
>
> It looks like someone attempted to shade Curator 2.13.0 and Curator 3.3.0, but it was only done for curator-client.
>
> I know they're very old releases, but is it possible that we could get a Curator-2.13.1 and Curator-3.3.1 that also shades curator-framework, curator-x-discovery, etc.? An official fork would be better than an internal fork.
>
> On Tue, Dec 14, 2021 at 2:51 AM Jordan Zimmerman <jordan@jordanzimmerman.com <ma...@jordanzimmerman.com>> wrote:
>> Is there a way out of this situation without deploying our own custom-patched Curator 2 or Curator 3 in which we remove Guava dependencies? Merely upgrading to Guava 17 isn't much of a win for us (and meanwhile our automated security scanners keep yelling at us for using outdated libraries)
>
> If you're unable to upgrade you could create a shaded version of Curator maybe with the Maven Shade plugin. This would require an internal fork for you though.
>
> I'm not familiar with CURATOR-526 and ZOOKEEPER-3577 to comment on those.
>
> -JZ
>
>> On Dec 14, 2021, at 12:48 AM, Phong X. Nguyen <p.nguyen@yahooinc.com <ma...@yahooinc.com>> wrote:
>>
>> I posted about this earlier this year but I'm not sure if this was fully resolved.
>>
>> We're currently on Guava 14, Zookeeper 3.5.7 and Curator 2.4.2.
>>
>> We'd like to upgrade to a reasonably recent version of Guava. That requires an upgrade to Curator 4, but that brings in the problem reported in CURATOR-526 and ZOOKEEPER-3577. Our Zookeeper configuration uses the old securedClientPort setting, which is currently unavailable in the new Dynamic Reconfiguration file format and thus is rejected by Zookeeper's new EnsembleTracker.
>>
>> As far as I can tell, CURATOR-526 just silences the log message, but upon trying to read through the code, it doesn't look like the internal EnsembleTracker will be properly populated as it won't read the old securedClientPort configuration. If that can't be resolved, for newer versions of Zookeeper, is there an alternative to securedClientPort?
>>
>> Is there a way out of this situation without deploying our own custom-patched Curator 2 or Curator 3 in which we remove Guava dependencies? Merely upgrading to Guava 17 isn't much of a win for us (and meanwhile our automated security scanners keep yelling at us for using outdated libraries)
>>
>> Sorry to bug everyone again, but the old version of Guava that we're stuck with is starting to cause serious problems as certain libraries are requiring newer versions of Guava, and we cannot upgrade (even to fix CVEs).
>>
>> Thanks,
>> - Phong X. Nguyen
>>
>
Re: [E] Re: Curator, Zookeeper and Guava woes (again)
Posted by "Phong X. Nguyen" <p....@yahooinc.com>.
It looks like someone attempted to shade Curator 2.13.0 and Curator 3.3.0,
but it was only done for curator-client.
I know they're very old releases, but is it possible that we could get a
Curator-2.13.1 and Curator-3.3.1 that also shades curator-framework,
curator-x-discovery, etc.? An official fork would be better than an
internal fork.
On Tue, Dec 14, 2021 at 2:51 AM Jordan Zimmerman <jo...@jordanzimmerman.com>
wrote:
> Is there a way out of this situation without deploying our own
> custom-patched Curator 2 or Curator 3 in which we remove Guava
> dependencies? Merely upgrading to Guava 17 isn't much of a win for us (and
> meanwhile our automated security scanners keep yelling at us for using
> outdated libraries)
>
>
> If you're unable to upgrade you could create a shaded version of Curator
> maybe with the Maven Shade plugin. This would require an internal fork for
> you though.
>
> I'm not familiar with CURATOR-526 and ZOOKEEPER-3577 to comment on those.
>
> -JZ
>
> On Dec 14, 2021, at 12:48 AM, Phong X. Nguyen <p....@yahooinc.com>
> wrote:
>
> I posted about this earlier this year but I'm not sure if this was fully
> resolved.
>
> We're currently on Guava 14, Zookeeper 3.5.7 and Curator 2.4.2.
>
> We'd like to upgrade to a reasonably recent version of Guava. That
> requires an upgrade to Curator 4, but that brings in the problem reported
> in CURATOR-526 and ZOOKEEPER-3577. Our Zookeeper configuration uses the old
> securedClientPort setting, which is currently unavailable in the new
> Dynamic Reconfiguration file format and thus is rejected by Zookeeper's new
> EnsembleTracker.
>
> As far as I can tell, CURATOR-526 just silences the log message, but upon
> trying to read through the code, it doesn't look like the internal
> EnsembleTracker will be properly populated as it won't read the old
> securedClientPort configuration. If that can't be resolved, for newer
> versions of Zookeeper, is there an alternative to securedClientPort?
>
> Is there a way out of this situation without deploying our own
> custom-patched Curator 2 or Curator 3 in which we remove Guava
> dependencies? Merely upgrading to Guava 17 isn't much of a win for us (and
> meanwhile our automated security scanners keep yelling at us for using
> outdated libraries)
>
> Sorry to bug everyone again, but the old version of Guava that we're stuck
> with is starting to cause serious problems as certain libraries are
> requiring newer versions of Guava, and we cannot upgrade (even to fix
> CVEs).
>
> Thanks,
> - Phong X. Nguyen
>
>
>
Re: Curator, Zookeeper and Guava woes (again)
Posted by Jordan Zimmerman <jo...@jordanzimmerman.com>.
> Is there a way out of this situation without deploying our own custom-patched Curator 2 or Curator 3 in which we remove Guava dependencies? Merely upgrading to Guava 17 isn't much of a win for us (and meanwhile our automated security scanners keep yelling at us for using outdated libraries)
If you're unable to upgrade you could create a shaded version of Curator maybe with the Maven Shade plugin. This would require an internal fork for you though.
I'm not familiar with CURATOR-526 and ZOOKEEPER-3577 to comment on those.
-JZ
> On Dec 14, 2021, at 12:48 AM, Phong X. Nguyen <p....@yahooinc.com> wrote:
>
> I posted about this earlier this year but I'm not sure if this was fully resolved.
>
> We're currently on Guava 14, Zookeeper 3.5.7 and Curator 2.4.2.
>
> We'd like to upgrade to a reasonably recent version of Guava. That requires an upgrade to Curator 4, but that brings in the problem reported in CURATOR-526 and ZOOKEEPER-3577. Our Zookeeper configuration uses the old securedClientPort setting, which is currently unavailable in the new Dynamic Reconfiguration file format and thus is rejected by Zookeeper's new EnsembleTracker.
>
> As far as I can tell, CURATOR-526 just silences the log message, but upon trying to read through the code, it doesn't look like the internal EnsembleTracker will be properly populated as it won't read the old securedClientPort configuration. If that can't be resolved, for newer versions of Zookeeper, is there an alternative to securedClientPort?
>
> Is there a way out of this situation without deploying our own custom-patched Curator 2 or Curator 3 in which we remove Guava dependencies? Merely upgrading to Guava 17 isn't much of a win for us (and meanwhile our automated security scanners keep yelling at us for using outdated libraries)
>
> Sorry to bug everyone again, but the old version of Guava that we're stuck with is starting to cause serious problems as certain libraries are requiring newer versions of Guava, and we cannot upgrade (even to fix CVEs).
>
> Thanks,
> - Phong X. Nguyen
>