K8SPS-781: Add custom names for orchestrator RBAC resources - #1427
Open
Miracle05 wants to merge 1 commit into
Open
K8SPS-781: Add custom names for orchestrator RBAC resources#1427Miracle05 wants to merge 1 commit into
Miracle05 wants to merge 1 commit into
Conversation
Miracle05
requested review from
egegunes,
gkech,
hors,
mayankshah1607,
nmarukovich,
oksana-grishchenko and
pooknull
as code owners
June 24, 2026 18:31
|
|
egegunes
reviewed
Jun 25, 2026
| meta := metav1.ObjectMeta{ | ||
| Namespace: cr.Namespace, | ||
| Name: "percona-server-mysql-operator-orchestrator", | ||
| Name: cr.Spec.Orchestrator.ServiceAccountName, |
Contributor
There was a problem hiding this comment.
maybe the default orchestrator service account name should be changed as well to include cr.Name, so you don't need to set a custom name for the 2nd cluster
this should be done with a version check and should only apply >=1.3.0
Author
There was a problem hiding this comment.
Good point, thanks. Updated the PR:
- Added DefaultOrchestratorServiceAccountName() with a version gate:
- for crVersion >= 1.3.0 the default is now {cr.Name}-orchestrator (aligned with {cr.Name}-clusterset and other per-cluster resources; happy to use percona-{cr.Name}-orchestrator if you prefer a vendor prefix)
- for crVersion < 1.3.0 the legacy default percona-server-mysql-operator-orchestrator is preserved
- orchestrator.RBAC() continues to use spec.orchestrator.serviceAccountName, so ServiceAccount, Role, and RoleBinding stay in sync
Upgrade path:
Operator upgrade to 1.3.0 alone does not change behavior for clusters with crVersion < 1.3.0
After bumping spec.crVersion to 1.3.0, the operator creates new per-cluster RBAC resources
The legacy shared SA/Role/RoleBinding can be removed manually if no longer used
Miracle05
force-pushed
the
fix-orc-rbac-hardcode
branch
from
June 25, 2026 08:22
a206065 to
33f44cd
Compare
Miracle05
force-pushed
the
fix-orc-rbac-hardcode
branch
from
June 25, 2026 08:44
33f44cd to
0d12164
Compare
egegunes
changed the title
egegunes
previously approved these changes
Jun 26, 2026
gkech
previously approved these changes
Jun 29, 2026
Collaborator
|
@Miracle05, could you please fix the conflicts? |
Author
Certainly, i will fix it tomorrow morning |
Miracle05
force-pushed
the
fix-orc-rbac-hardcode
branch
from
July 8, 2026 19:31
529d3c6 to
af168d1
Compare
Miracle05
force-pushed
the
fix-orc-rbac-hardcode
branch
from
July 8, 2026 20:00
af168d1 to
fcf8148
Compare
egegunes
approved these changes
Jul 9, 2026
Collaborator
commit: fcf8148 |
hors
requested changes
Jul 29, 2026
hors
left a comment
hors
left a comment
Collaborator
There was a problem hiding this comment.
@egegunes @Miracle05 could you please check limits test?
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
6 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
CHANGE DESCRIPTION
Problem:
When multiple PerconaServerMySQL clusters with Orchestrator enabled are deployed in the same namespace, they conflict over a single set of RBAC resources (ServiceAccount, Role, RoleBinding) named percona-server-mysql-operator-orchestrator. This can cause reconcile errors (controller owner reference conflicts) and prevents running multiple Orchestrator instances in one namespace.
Cause:
spec.orchestrator.serviceAccountName was already supported for Orchestrator pods, but orchestrator.RBAC() always created RBAC objects with a hardcoded name (percona-server-mysql-operator-orchestrator), ignoring the CR value. As a result, all clusters in a namespace shared the same RBAC objects regardless of the configured service account name.
Solution:
Use cr.Spec.Orchestrator.ServiceAccountName (after defaults are applied) as the name for all Orchestrator RBAC resources: ServiceAccount, Role, and RoleBinding. Each cluster can now get an isolated RBAC set by setting a unique spec.orchestrator.serviceAccountName. If the field is not set, the default percona-server-mysql-operator-orchestrator is preserved — existing single-cluster deployments are unaffected.
CHECKLIST
Tests
No E2E test — behavior fix for an existing field; covered by unit tests. Can add a multi-orchestrator E2E if the team wants it.
Config/Logging/Testability
Are all needed new/changed options added to default YAML files?
no new option — spec.orchestrator.serviceAccountName already exists and is documented in deploy/cr.yaml
Are all needed new/changed options added to the Helm Chart?
no Helm changes required — field already exposed
Did we add proper logging messages for operator actions?
not applicable — behavior fix, no new operator actions
Did we ensure compatibility with the previous version or cluster upgrade process?
Backward compatible via
crVersiongate:crVersion < 1.3.0(or empty): legacy default SA namepercona-server-mysql-operator-orchestratoris preservedcrVersion >= 1.3.0: new per-cluster default{cr.Name}-orchestratorspec.orchestrator.serviceAccountNamealways overrides defaultsUpgrade path:
spec.crVersionto1.3.0, the operator creates new per-cluster RBAC resourcesDoes the change support oldest and newest supported PS version?
Does the change support oldest and newest supported Kubernetes version?