Skip to content

[#12367] test(iceberg): add a MinIO container for credential vending ITs - #12410

Open
bharos wants to merge 6 commits into
apache:mainfrom
bharos:minio-credential-it-12367
Open

[#12367] test(iceberg): add a MinIO container for credential vending ITs#12410
bharos wants to merge 6 commits into
apache:mainfrom
bharos:minio-credential-it-12367

Conversation

@bharos

@bharos bharos commented Aug 10, 2026

Copy link
Copy Markdown
Contributor

What changes were proposed in this pull request?

Adds a MinIO-backed integration test so Iceberg credential vending is covered by CI.

  • MinIOContainer in integration-test-common, plus ContainerSuite.startMinIOContainer() / getMinIOContainer().
  • IcebergRESTMinIOTokenAuthorizationIT, a subclass of IcebergRESTCloudTokenAuthorizationBaseIT tagged gravitino-docker-test rather than gated on cloud credentials, so its three test methods run in CI.

Deploy mode needed two things from the base class:

  • setupCloudBundles() has to run before super.startIntegrationTest(), because the server resolves S3FileIO from its classpath while starting. The javadoc said the opposite and is corrected.
  • The bundle is installed into catalogs/lakehouse-iceberg/libs/ as well as iceberg-rest-server/libs/. The catalog is loaded through IsolatedClassLoader and ships iceberg-aws without the AWS SDK, so S3FileIO resolved and then failed with NoClassDefFoundError. This is the layout described in gravitino-server-config.md and credential-vending.md. gravitino-iceberg-aws-bundle is built locally and shades both the Iceberg AWS bundle and the Gravitino credential providers, so nothing is downloaded at test time.

Why are the changes needed?

Credential vending ITs are gated by @EnabledIfEnvironmentVariable(named = "GRAVITINO_TEST_CLOUD_IT", matches = "true"), which nothing sets, and no workflow supplies cloud credentials. Whether a caller receives a writable or a read-only storage credential therefore has no automated protection against regressions.

MinIO enforces the session policy attached to an AssumeRole request, so that behaviour is observable without a cloud account.

Fix: #12367

Does this PR introduce any user-facing change?

No. Test only.

How was this patch tested?

New test, run locally in both modes:

./gradlew :iceberg:iceberg-rest-server:test --tests "*IcebergRESTMinIOTokenAuthorizationIT*" \
  -PskipTests -PtestMode=embedded -PskipDockerTests=false

./gradlew :iceberg:iceberg-rest-server:test --tests "*IcebergRESTMinIOTokenAuthorizationIT*" \
  -PskipTests -PtestMode=deploy -PskipDockerTests=false

All three tests pass in each mode: a caller with MODIFY_TABLE can write with the vended credential, and a caller with only SELECT_TABLE is rejected at the storage layer when it attempts to write.

…nding ITs

The credential vending integration tests are gated behind
GRAVITINO_TEST_CLOUD_IT and require a real cloud account, so they do not
run in CI. MinIO enforces the session policy attached to an AssumeRole
request, so the privilege-to-credential mapping is observable without
one.

Add MinIOContainer, wire it into ContainerSuite, and add
IcebergRESTMinIOTokenAuthorizationIT, which implements the cloud hooks of
IcebergRESTCloudTokenAuthorizationBaseIT against MinIO. The three test
methods on that base class now run through this subclass; the existing
cloud-specific subclasses stay gated and unchanged.
@github-actions

github-actions Bot commented Aug 10, 2026

Copy link
Copy Markdown

Code Coverage Report

Overall Project 68.39% 🟢
Files changed No Java source files changed -

Module Coverage
aliyun 1.72% 🔴
api 49.31% 🟢
authorization-common 85.96% 🟢
aws 42.04% 🟢
azure 2.47% 🔴
catalog-common 9.92% 🔴
catalog-fileset 79.77% 🟢
catalog-glue 68.95% 🟢
catalog-hive 79.4% 🟢
catalog-jdbc-common 45.7% 🟢
catalog-jdbc-doris 81.8% 🟢
catalog-jdbc-mysql 79.33% 🟢
catalog-jdbc-postgresql 83.39% 🟢
catalog-jdbc-starrocks 79.16% 🟢
catalog-kafka 77.01% 🟢
catalog-lakehouse-generic 59.18% 🟢
catalog-lakehouse-hudi 79.1% 🟢
catalog-lakehouse-iceberg 85.86% 🟢
catalog-lakehouse-paimon 84.23% 🟢
catalog-model 77.72% 🟢
cli 44.48% 🟢
client-java 78.28% 🟢
common 52.77% 🟢
core 83.33% 🟢
filesystem-hadoop3 77.28% 🟢
flink 0.0% 🔴
flink-common 48.68% 🟢
flink-runtime 0.0% 🔴
gcp 14.12% 🔴
hadoop-auth 68.0% 🟢
hadoop-common 12.7% 🔴
hive-metastore-common 53.4% 🟢
iceberg-aliyun-bundle 0.0% 🔴
iceberg-common 64.75% 🟢
iceberg-rest-server 75.03% 🟢
idp-basic 86.02% 🟢
integration-test-common 0.0% 🔴
jobs 62.92% 🟢
lance-common 31.75% 🔴
lance-rest-server 63.47% 🟢
lineage 53.02% 🟢
optimizer 83.24% 🟢
optimizer-api 21.95% 🔴
server 85.76% 🟢
server-common 76.69% 🟢
spark 28.57% 🔴
spark-common 45.89% 🟢
tencent 69.84% 🟢
trino-connector 40.29% 🟢

bharos added 4 commits August 10, 2026 14:17
… unaffected

IcebergRESTCloudTokenAuthorizationBaseIT expects its subclass to create
SCHEMA_NAME but never drops it. That was harmless while no subclass ran
in CI, but the Iceberg JDBC backend outlives a test class, so the schema
leaked into IcebergTableAuthorizationIT, which creates the same name and
failed with SchemaAlreadyExistsException.

Create the schema only when absent, since the sibling does not clean up
either and may run first, and drop it on teardown. Iceberg rejects a
cascading drop, so the tables are cleared first.
…ver starts

In deploy mode the Gravitino server resolves S3FileIO from its own
classpath at startup, so calling setupCloudBundles() after
super.startIntegrationTest() was too late and /v1/config failed with a
500 while the admin Iceberg catalog was being initialised. Embedded mode
cannot catch this because setupCloudBundles() returns early there.

Also run the schema cleanup in a try/finally. When setup failed part way
through, teardown threw before super.stopIntegrationTest() and left
test_metalake behind, which then broke IcebergTableAuthorizationIT.
…lassloader too

The lakehouse-iceberg catalog is loaded through IsolatedClassLoader from
catalogs/lakehouse-iceberg/libs, which ships iceberg-aws but no AWS SDK,
so S3FileIO resolved and then failed with NoClassDefFoundError on
software/amazon/awssdk. Only iceberg-rest-server/libs was being
populated, so the catalog never saw the SDK.

Copy gravitino-iceberg-aws-bundle into both directories, as
gravitino-server-config.md and credential-vending.md prescribe. That
bundle already shades the Iceberg AWS bundle and the Gravitino
credential providers, so the Maven download is no longer needed and the
test stops depending on network access.

Also correct the setupCloudBundles() javadoc, which told subclasses to
call it after super.startIntegrationTest(); that ordering is what broke
deploy mode in the first place.
…subclass

IcebergRESTS3TokenAuthorizationIT called setupCloudBundles() after
super.startIntegrationTest(), the ordering that fails in deploy mode for
the same reason the MinIO subclass did. It is gated behind
GRAVITINO_TEST_CLOUD_IT so CI never caught it.

Keeps the subclass consistent with the corrected javadoc on
setupCloudBundles().
@bharos
bharos marked this pull request as ready for review August 11, 2026 18:18
@bharos
bharos requested a review from roryqi August 11, 2026 18:18
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[Improvement] Add a MinIO container for credential vending integration tests

1 participant