systemalchemy opened a new issue, #3495:
URL: https://github.com/apache/polaris/issues/3495
### Describe the bug
Hi Polaris team, can you help? Is there something basic I am missing or is
this a known bug with a work-around recommended. Thanks in advance!
# Polaris Catalog Issue Report
## 1. What version of Apache Polaris are you using?
- **Version:** polaris-bin-1.1.0-incubating (image assembled from release
archive) (but same issue occurred when using 1.2.0 and 1.3.0.
- **CLI binaries present:** `/opt/polaris/bin/admin` and
`/opt/polaris/bin/server` are present; `/opt/polaris/bin/polaris` CLI binary is
not present in the image.
## 2. What operating system and processor architecture are you using?
- **Environment:** Kubernetes (Rancher Desktop)
- **Namespace:** `flink-sandbox`
- **Operating System:** (Host OS not specified; running in containerized
environment)
- **Processor Architecture:** (Not specified; typical x86_64 for containers)
## 3. What did you do?
- Integrated Polaris with Flink and MinIO on Kubernetes.
- Set up authentication using INTERNAL/default mode, token broker
`rsa-key-pair`, and token refresh via CronJob.
- Attempted to create a catalog using the management API:
1. Obtained admin token via `/api/catalog/v1/oauth/tokens`
(`scope=PRINCIPAL_ROLE:admin`, `grant_type=client_credentials`).
2. Called `POST /api/management/v1/catalogs` on port 8181 with valid token
and (optionally) `X-Polaris-Realm: default-realm`.
3. Example request body:
```json
{
"catalog": {
"name": "warehouse",
"type": "INTERNAL",
"properties": {
"default-base-location": "s3a://warehouse/iceberg"
},
"storageConfigInfo": {
"storageType": "S3",
"allowedLocations": ["s3a://warehouse"]
}
}
}
```
## 4. What did you expect to see?
- Expected HTTP 201 response with catalog information.
- Expected successful end-to-end Flink ↔ Iceberg integration and passing
integration tests.
## 5. What did you see instead?
- Received HTTP 500 error with `ContextNotActiveException` (Quarkus CDI) in
server logs.
- Unable to create a catalog; integration tests blocked.
- Service exposes only port 8181; 8182 (health/management) is not exposed
externally.
- CLI fallback unavailable (`/opt/polaris/bin/polaris` missing; `admin` tool
lacks catalog commands).
---
## Additional Details
### Environment
- **Auth mode:** INTERNAL/default, token broker `rsa-key-pair`, max token
TTL 1h.
- **Secrets:** RSA keys from `polaris-token-broker-keys`; admin credentials
from `polaris-admin-credentials`.
- **Token refresh:** CronJob posts to `/api/catalog/v1/oauth/tokens` and
writes access token to `polaris-token` secret (not mounted into Polaris
container).
- **Storage/DB:** Postgres backend; MinIO as object store (s3a).
### Issue 1: Auth Behavior (resolved locally)
- Flink requests to Polaris REST catalog returned 401 even with
`quarkus.oidc.enabled=false` and `POLARIS_AUTHENTICATION_ENABLED=false`.
- Workaround: Added env-based bearer token support in catalog manager
([pyflink/catalog/polaris_manager.py#L121-L137](pyflink/catalog/polaris_manager.py#L121-L137)).
Token injected into Flink JM/TM as env `POLARIS_BEARER_TOKEN`.
- Result: Auth succeeded; subsequent failure was a 400 “Please specify a
warehouse,” confirming token acceptance.
### Issue 2: Management API Catalog Create Fails (blocking)
- Symptom: `POST /api/management/v1/catalogs` returns HTTP 500 with
`ContextNotActiveException` (Quarkus CDI).
- Impact: Cannot create a catalog; Flink ↔ Iceberg integration tests blocked.
### Hypothesis
- The error appears to be a server-side request context activation gap
(e.g., missing `@ActivateRequestContext` or scope on a producer used by
management/warehouse resources), based on the observed Quarkus CDI exception
and referenced documentation.
### Requests for Community Guidance
1. Known issues in 1.1.0/1.3.0 where management APIs throw
`ContextNotActiveException`? Any patches or backports?
2. Is there an official Polaris CLI binary for catalog operations that
should ship in the binary distro?
3. Should the management API be called on 8182 instead of 8181? Expected
port exposure and required headers?
4. Recommended workaround until a fix: is it safe to insert
`@ActivateRequestContext` around management endpoints, or should the producer
scope be adjusted elsewhere?
### Next-Step Options Considered
- Patch Polaris source (prefer 1.3.0) to wrap management/warehouse resources
with request context and rebuild image (if source access is available).
- Expose 8182 and retest (to confirm if the error persists or to aid
diagnosis).
### Artifacts and References
- Auth patch: `kubernetes/overlays/local/polaris-auth-patch.yaml`
- Token refresh CronJob:
`kubernetes/overlays/local/polaris-token-refresh-cronjob.yaml`
- Deployment: `kubernetes/base/polaris/deployment.yaml`
- Service: `kubernetes/base/polaris/service.yaml`
- CLI binary absence confirmed via `kubectl exec deploy/polaris -- ls
/opt/polaris/bin` (only `admin`, `server` present).
### Open Items
- Decode and share live token claims for validation (can provide if helpful).
- Confirm whether realm header is required beyond bearer token for
management calls.
### To Reproduce
_No response_
### Actual Behavior
_No response_
### Expected Behavior
_No response_
### Additional context
_No response_
### System information
_No response_
--
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]
