stackabletech / stackabletech/hdfs-operator
ClusterRoleBinding applied asynchronously leading to topology provider failures
Nobody has claimed this yet.
- Dominant language
- Rust
- Stars
- 53
- Forks
- 9
- Avg merge
- 1d 13h
- Merged PRs (30d)
- 10
Description
Affected Stackable version
All up until and including SDP 26.3.0
Affected Apache HDFS version
N/A
Current and expected behavior
When the Topology Provider runs, it is assumed that the necessary permissions are there for the Kubernetes API.
There is a small window for a new HdfsCluster's where the ClusterRoleBinding hasn't been applied by the time the Topology Provider starts.
Possible solution
Instead of concurrently applying ClusterRoleBindings and StatefulSets, do them in sequence.
The overhead should be negligible.
Additional context
No response
Environment
No response
Would you like to work on fixing this bug?
yes
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 locating the HdfsCluster reconciliation entry point that applies ClusterRoleBindings and StatefulSets, then trace how the Topology Provider starts. Verify the current concurrent ordering and change the flow so the ClusterRoleBinding is applied first; done means a new HdfsCluster cannot start the provider before its Kubernetes API permissions exist.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- kubernetes, rust
- Domain
- infrastructure
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 58/100