Skip to content

Conversation

@wornjs
Copy link

@wornjs wornjs commented Oct 19, 2025

Description

This PR fixes an issue where the StarRocks Operator’s Role and RoleBinding resources were always created in the operator’s own namespace, even when a different watchNamespace was specified.
As a result, the operator had insufficient RBAC permissions to manage resources in the target namespace.

# Related Issue(s)

Please list any related issues and link them here.

Checklist

For operator, please complete the following checklist:

  • run make generate to generate the code.
  • run golangci-lint run to check the code style.
  • run make test to run UT.
  • run make manifests to update the yaml files of CRD.

For helm chart, please complete the following checklist:

  • make sure you have updated the values.yaml
    file of starrocks chart.
  • In scripts directory, run bash create-parent-chart-values.sh to update the values.yaml file of the parent
    chart( kube-starrocks chart).

@CLAassistant
Copy link

CLA assistant check
Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
You have signed the CLA already but the status is still pending? Let us recheck it.

@yandongxiao
Copy link
Collaborator

Thank you for your contribution, please sign the CLA.

@yandongxiao
Copy link
Collaborator

If the Role and Rolebinding are both in another namespace, but the serviceAccount is deployed in the same namespace with operator, how can you make it together to work?

Another suggestion is you can deploy the operator both in namespace-a and namespace-b, and also remove the clusterrole and clusterrolebinding deployment.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants