FrankChen021 commented on PR #19963:
URL: https://github.com/apache/druid/pull/19963#issuecomment-5248619900
`WONT_FIX_LARGE_CHANGE` — closing after exact-head verification of
`e90f9c5754b61b3471a3ffafee7ff706e27be448` against current upstream `master`
`b3f08c83aa0492a8ed0e16b1b715f5abc0fa3d3a`.
The PR is a one-line `google-api-client` 2.2.0 → 2.9.0 bump, but all five
red jobs are deterministic PR-caused Maven Enforcer failures, not flaky or
infrastructure failures:
- packaging (job 93635261386), strict-compilation (93635261322),
static-checks (93635261298), and openrewrite (93635261311) fail
`RequireUpperBoundDeps` in `druid-iceberg-extensions`:
`google-auth-library-{credentials,oauth2-http}` resolves to 1.20.0 through
`google-cloud-storage:2.29.1`, while `google-api-client:2.9.0` requires 1.30.0.
- Those jobs, and validate-dist (93635261711), also expose `druid-server`
selecting `auto-value-annotations:1.8.1` through test Truth while the upgraded
auth client requires 1.11.0.
- A focused local validate additionally reproduces the auth conflict in
`google-extensions`.
Adding only the two obvious version pins would make the current checks
quieter without making the dependency graph supported. The authoritative 2.9.0
POM upgrades the Google HTTP client family to 2.0.0, and the published 2.9.0
JAR manifest imports its HTTP/JSON/util packages in `[2.0,3)`. Druid still
centrally forces `google-http-client` core/Jackson to 1.42.3, while
`google-cloud-storage:2.29.1` contributes other HTTP modules at 1.43.3 and auth
at 1.20.0. The resulting effective graph mixes 1.42.3, 1.43.3, and 2.0.0 HTTP
modules plus auth 1.20.0/1.30.0. That is not compatibility-safe.
Compatibility review:
- The affected surface is broader than the root POM: `cloud/gcp-common`,
`server`, Google, GCE, Iceberg, Kubernetes-overlord, and embedded-test modules.
`GcpModule` also exposes Google HTTP types through bindings, so
extension/plugin classloader compatibility is part of the change.
- Google API Client 2.9 changes trust-store selection and deprecates
`GoogleNetHttpTransport`; Druid directly uses
`GoogleNetHttpTransport.newTrustedTransport()` in GCP/GCE code. This can alter
outbound TLS/private-CA/proxy behavior and needs deployment-level GCS/GCE/ADC
testing.
- Google HTTP Client 2.0 documents a breaking Guava-family update. Java
runtime level itself is acceptable for Druid, but coordinated HTTP 2,
storage/gax/auth/grpc dependency management and live integration verification
are required.
- `japicmp` (with missing optional classes ignored) found no general public
binary/source break in API Client 2.2→2.9 or auth 1.20→1.30. It did flag a
Java-serialization UID change for HTTP Client's public
`DateTime.SecondsAndNanos`; Druid has no direct use, so no Druid stored-data
format change was identified. Druid REST/SQL/config and persistence formats are
otherwise untouched, but the network/TLS and extension-SPI risks remain
unresolved.
- Licenses remain compatible (Apache-2.0/BSD-3-Clause), but the coordinated
version alignment would require updating `licenses.yaml`, which still records
the old API/auth/HTTP/AutoValue versions.
- GitHub's reviewed advisory database returned no exact-version advisory for
API Client 2.2.0 that would justify rushing an unsafe partial migration.
There is concrete scope precedent: #16483 attempted only Google HTTP Client
1.42.3 → 1.44.2 and accumulated four follow-up alignment commits spanning
Google, Iceberg, gRPC, OpenTelemetry, and license metadata before it was
closed. Moving this PR to HTTP 2 safely is a larger migration.
A compatibility-safe repair therefore requires widespread dependency
alignment and integration work outside a surgical dependency-PR fix. No patch,
push, approval, or merge was performed.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
