[fix](docker)(regression) Stabilize external test environment

[suxiaogang223]

What problem does this PR solve?

Issue Number: None

Related PR: #66254

Problem Summary:

The branch-4.0 fix in #66254 also applies to master in four places:

• The lightweight Kerberos environment creates principals with random keys on every container start, so keytabs provisioned to Doris hosts no longer match after the KDC is rebuilt.
• A successful Hive baseline restore skips init-hive-baseline.sh, while the incremental Hive module list does not include the Paimon HMS table definitions. The restored environment therefore misses the Paimon databases.
• test_file_cache_query_limit sends BE brpc and HTTP requests to externalEnvIp, which identifies the third-party Docker host rather than the backend host in a multi-host deployment.
• test_file_cache_statistics treats each queue's max_size as a hard limit even though queues may borrow unused capacity from one another. The actual hard bound is the total file-cache capacity.

This PR uses deterministic Kerberos keys, registers Paimon HMS as an incremental Hive module, resolves the single live backend before accessing BE endpoints, and validates normal-queue usage against the sum of all queue capacities.

The ES database-name fix from #66254 is intentionally not included because master has already migrated this suite to external ES catalogs and no longer switches to the old internal P0 database.

Release note

None

Check List (For Author)

• Test
  • Regression test
  • Unit Test
  • Manual test
    • bash -n for all changed shell scripts
    • docker/thirdparties/test/run-thirdparties-docker-hive-bootstrap-groups-test.sh
    • Paimon HMS module selection and refresh harness
    • Groovy CONVERSION-phase parse for both changed regression suites
    • Full external regression was not run because it requires a multi-host Doris cluster and the third-party Docker stack
• Behavior changed:
  • No
  • Yes
• Does this need documentation?
  • No
  • Yes

[hello-stephen]

Thank you for your contribution to Apache Doris.
Don't know what should be done next? See How to process your PR.

Please clearly describe your PR:

1. What problem was fixed (it's best to include specific error reporting information). How it was fixed.
2. Which behaviors were modified. What was the previous behavior, what is it now, why was it modified, and what possible impacts might there be.
3. What features were added. Why was this function added?
4. Which code was refactored and why was this part of the code refactored?
5. Which functions were optimized and what is the difference before and after the optimization?

[suxiaogang223]

run buildall

[github-actions]

PR approved by at least one committer and no changes requested.

[github-actions]

PR approved by anyone and no changes requested.

[shuke987]

/review

[github-actions]

Automated review completed for 1efe2108e6ffa47ad40bf645a859a2caf741468e after three convergence rounds.

Overall, the implementation is focused and its runtime/test behavior is internally consistent in the checked-in pipelines. One P2 documentation-contract mismatch remains and is called out inline; I found no critical production-runtime blocker.

Critical checkpoints:

• Goal and correctness: Paimon HMS automatic/explicit selection, Hive2/Hive3 refresh behavior, module SHA commit/retry, deterministic Kerberos rebuilds, BE endpoint discovery, and file-cache queue borrowing were traced end to end. The code paths are sound apart from the documented selection contract.
• Scope and maintainability: The seven changed files are focused on the stated Docker/Hive/Kerberos and regression-test fixes, and they reuse the existing module and cache-statistics mechanisms.
• Concurrency and lifecycle: Baseline restore/full-init paths invalidate the module marker before HQL and mark it only after success. The two KDC realms recreate disjoint keytab files and are health-checked before use; no new production lock or shared-state ordering is introduced.
• Configuration and compatibility: The fixed principal/password/single-enctype inputs plus ktadd -norandkey make post-migration rebuilds deterministic. No production protocol, persistence format, storage format, or FE-BE variable propagation change applies.
• Tests and observability: The single-BE external pipeline is IPv4-pinned, and its cache capacity is unchanged by any scheduled reset suite. Changed shell scripts passed bash -n; the module selector was exercised directly. Current compile, style, unit, P0, external, nonConcurrent, cloud, and coverage checks pass. No build or repository test suite was run by this static review.
• Performance and security: No material production performance or observability regression was found. The Kerberos change is under Docker/regression infrastructure, outside the production threat model, but its correctness and key lifecycle were still reviewed.
• Transactions and data correctness: No production transaction, persistence, or data-write path is changed.
• User focus: No additional user-provided review focus was present; the whole PR was reviewed.

Requested change: clarify both Hive README rows that enablePaimonHms controls inclusion in the default/all expansion, while an explicit --hive-modules paimon_hms selector intentionally overrides it.

[hello-stephen]

/review

[github-actions]

Request changes: one P2 compatibility issue remains in the new Paimon module selection. The Kerberos rebuild fix and both file-cache regression-test fixes look sound in their supported paths.

Critical checkpoint conclusions

1. Goal and proof: The PR addresses four independent environment/test failures. Three fixes achieve their stated goal. Paimon refresh state is recorded only after successful HQL, but the new explicit selector is not Hive-generation-aware. The reported Hive3 harness does not prove the Hive2 or combined-generation path identified inline.
2. Scope and clarity: The changes are small and generally focused. The remaining issue is localized to how module availability is normalized before the common Hive2/Hive3 launcher consumes it.
3. Concurrency: There is no new shared-memory concurrency. Hive2 and Hive3 can be launched concurrently, and both receive the same HIVE_MODULES; one Hive2 failure is propagated by the aggregate wait and aborts the launch, which is the concrete effect of the inline issue.
4. Lifecycle: Full initialization, baseline restoration, incremental refresh, SHA invalidation, and successful-commit ordering were traced. Hive3 avoids duplicate HQL execution and failed refreshes remain retryable. Kerberos startup cleans both realm databases/keytabs before deterministic recreation.
5. Configuration: No Doris runtime configuration is added. Existing enablePaimonHms correctly controls default/all inclusion, but it is not a Hive-generation capability signal for explicit selection.
6. Compatibility: The explicit Paimon module is newly reachable from Hive 2.3.2 even though this stack installs/configures the Hive 3.1 handler path. Official Paimon documentation likewise distinguishes Hive 2.3 and Hive 3.1 connector artifacts: https://paimon.apache.org/docs/master/ecosystem/hive/ . This is the requested change.
7. Parallel paths: Hive2/Hive3, refresh/rebuild/fast, restored/missing baseline, default/all/explicit module, and both Kerberos realms were checked. The Hive2 explicit-module path is the only unsupported parallel path found.
8. Conditional checks: The single-live-BE skip is load-bearing and documented; live-BE host/config ports correlate in the enabled external pipeline. The Paimon default flag condition is correct, but explicit validation needs a separate Hive3 capability check.
9. Test coverage: The existing/manual evidence covers script syntax, Hive3 bootstrap behavior, and Groovy parsing. Add a harness case for explicit paimon_hms with Hive2 and with a combined Hive2/Hive3 launch. No full runtime/regression build was run in this static-review environment.
10. Test results: No golden .out files change. The adjusted queue-size assertion matches clean-start production semantics, and removing the element upper bound matches the lack of element-count enforcement.
11. Observability: Existing stage/error output, refresh detail, and test skip logs are sufficient for these paths; no new production metrics are needed.
12. Persistence/transactions: No Doris EditLog or transaction path changes. Hive module SHA state is persisted only after successful HQL. Kerberos ktadd -norandkey preserves key/version as intended: https://web.mit.edu/kerberos/krb5-latest/doc/admin/admin_commands/kadmin_local.html .
13. Data writes/crash behavior: Changes are limited to test-environment Hive DDL/state and regression assertions. Full rebuild owns destructive bootstrap DDL; failed module execution does not mark the SHA current.
14. FE/BE propagation: No new FE/BE variables, RPCs, symbols, or storage formats are introduced.
15. Performance: No hot production path changes or material CPU/memory regressions were found. Added shell iteration and test metric aggregation are negligible.
16. Other/security: The fixed Kerberos credential is confined to unsupported Docker/regression infrastructure under the repository threat model, not a Doris runtime vulnerability. The live README wording issue is already covered by discussion r3694601306 and was not duplicated.

User focus

No additional review focus was supplied, so the complete seven-file PR was reviewed.

Static validation: bash -n passed for the three changed shell scripts. Builds and runtime regression tests were intentionally not run under the review-runner constraints.

dismiss