stackabletech / stackabletech/nifi-operator
NiFi 1.25.0 UI access unstable with more than one replica
Nobody has claimed this yet.
- Dominant language
- Rust
- Stars
- 48
- Forks
- 12
- Avg merge
- 11h 26m
- Merged PRs (30d)
- 10
Description
In NiFi 1.25.0 the access JWT changed its issuer/sub to a specific pod. Due to the round robin of the service / nodeport (it should be fine with load balancers and sticky sessions), it happens that you are connecting with a JWT from pod X to pod Y which is rejected and basically logs you out or results in strange behavior... This makes the UI more or less not usable for proper production.
We should create a single pod service (or adapt the create-reporting-task service that talks to only one pod) to avoid this behavior. It probably makes sense to deploy one (single-pod) service per pod (listener??).
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by tracing the Kubernetes service and NodePort routing, then inspect the create-reporting-task service mentioned in the issue and how requests are distributed across NiFi replicas. Compare JWT issuer/sub values across pods and verify the chosen routing approach keeps the UI usable with more than one replica.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- kubernetes, rust
- Domain
- authentication, infrastructure, networking
- Issue type
- Bug
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100