yuqi1129 opened a new pull request, #11213: URL: https://github.com/apache/gravitino/pull/11213
### What changes were proposed in this pull request? Adds a new GitHub Actions workflow at `.github/workflows/multi-instance-consistency-test.yml` that brings up two Gravitino instances backed by a shared MySQL service container and runs the existing shell-based consistency suite against them. Also lands the suite at `dev/ci/test_multi_instance_consistency.sh` — a 14-phase / 94-assertion script that exercises the `JcasbinAuthorizer` caches (`ownerRelCache`, `metadataIdCache`, `userRoleCache`, `loadedRoles`, `groupRoleCache`) and the `JcasbinChangePoller` invalidation paths across two instances: | Phase | What it covers | |---|---| | A / B' | Owner read-back + warm-cache invalidation (eventual, poll-driven) | | C / D | Role grant / revoke immediately effective on the peer | | E | Role-privilege add/remove immediately effective on the peer | | F | Role hard-delete clears peer's `loadedRoles` cache | | G / H | User delete + same-name re-create has no stale role inheritance | | I | Role re-create with same name has no stale privilege leak | | J | Cross-metalake isolation (role/owner does not leak) | | K | DENY condition overrides ALLOW on a different role | | L | Group lifecycle: create / grant / revoke / delete visible on peer | | N | `setOwner` propagation works for non-METALAKE entities (TAG) | | O | Multi-role partial revoke only affects the revoked role | | P | Owner change on TAG with warm cache on the peer | | Q | Burst of `setOwner` calls within one poll window converges | | R | Re-granting an already-held role is idempotent | Both Gravitino instances run with: ``` gravitino.cache.enabled = false # isolates from entity-store cache gravitino.authorization.enable = true gravitino.authorization.serviceAdmins = admin gravitino.entity.store.relational.jdbcUrl = <shared MySQL> ``` A `paths-filter` job keeps the workflow from running for unrelated changes. ### Why are the changes needed? The script exercises the `JcasbinAuthorizer` cache layer end-to-end across instances; without a CI gate, regressions in these paths only surface when someone runs the script by hand. The recent `versionCheckAndLoadRoles` fix for the role-delete propagation gap (follow-up to #10996) in particular has no automated coverage. Fix: #11212 ### Does this PR introduce _any_ user-facing change? No. ### How was this patch tested? The script itself is the test. It passes 94/94 locally against two instances: ``` == Summary == Passed: 94 Failed: 0 ``` The workflow file is structured per the existing access-control / integration test workflows in this repo; a full CI run will happen once this PR is open. -- 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]
