[Feature] Watch CR in multiple namespaces with namespaced RBAC resources #1106

kevin85421 · 2023-05-23T18:14:15Z

Why are these changes needed?

Currently, KubeRay supports the following options:

Watching all custom resources in the Kubernetes cluster: This is the default setting, which installs cluster-scoped RBAC resources (i.e., ClusterRole and ClusterRoleBinding).
Watching only the namespace where the operator is deployed: This is achieved by setting singleNamespaceInstall to true, which installs namespaced RBAC resources (i.e., Role and RoleBinding).

However, for users who only have namespaced access, they would need to deploy one KubeRay operator for each namespace. This can increase the maintenance overhead, such as upgrading the version of KubeRay for each deployed instance.

This PR implements a feature that supports users to deploy a KubeRay operator to watch multiple namespaces without installing ClusterRole and ClusterRoleBinding as proposal in #1084.

There are two fields available to configure the KubeRay operator to achieve this:

singleNamespaceInstall:
- Case 1: If set to false, the KubeRay operator will create ClusterRole and ClusterRoleBinding.
- Case 2: If set to true and watchNamespace is set, it will create Role and RoleBinding for all namespaces listed in watchNamespace.
- Case 3: If set to true and watchNamespace is not set, it will create Role and RoleBinding for the namespace where the operator is deployed.
- Case 4: If singleNamespaceInstall is not set, the KubeRay operator will create ClusterRole and ClusterRoleBinding.
watchNamespace: A list of namespaces that the KubeRay operator will watch. In addition, it will be passed to KubeRay binary as the --watch-namespace flag.

Related issue number

Closes #1084
Closes #1083

#1094

Checks

I've made sure the tests are passing.
Testing Strategy
- Unit tests
- Manual tests
- This PR is not tested :(

Case 1: If `singleNamespaceInstall` is set to false, the KubeRay operator will create ClusterRole and ClusterRoleBinding.

kind create cluster --image=kindest/node:v1.23.0
kind load docker-image controller:latest

# Create namespaces
kubectl create ns n1
kubectl create ns n2

# Install a KubeRay operator (use gist1 to replace values.yaml)
# (path: helm-chart/kuberay-operator)
helm install kuberay-operator . --set image.repository=controller,image.tag=latest

# Check ClusterRole
kubectl get clusterrole | grep kuberay
# kuberay-operator                                                       2023-05-23T22:02:31Z

# Check Role 
kubectl get role
# NAME                               CREATED AT
# kuberay-operator-leader-election   2023-05-23T22:02:31Z


# Install RayCluster in `default`, `n1`, `n2`
helm install raycluster kuberay/ray-cluster --version 0.5.0
helm install raycluster kuberay/ray-cluster --version 0.5.0 -n n1
helm install raycluster kuberay/ray-cluster --version 0.5.0 -n n2

# RayCluster in these 3 namespaces should be created.

Case 2: If `singleNamespaceInstall` is set to true and watchNamespace is set, it will create Role and RoleBinding for all namespaces listed in watchNamespace.

watchNamespace: n1, n2

kind create cluster --image=kindest/node:v1.23.0
kind load docker-image controller:latest

# Create namespaces
kubectl create ns n1
kubectl create ns n2

# Install a KubeRay operator (use gist2 to replace values.yaml)
# (path: helm-chart/kuberay-operator)
helm install kuberay-operator . --set image.repository=controller,image.tag=latest

# Check ClusterRole
kubectl get clusterrole | grep kuberay
# (nothing found)

# Check Role 
kubectl get role --all-namespaces | grep kuberay
# default       kuberay-operator-leader-election                 2023-05-23T22:27:37Z
# n1            kuberay-operator                                 2023-05-23T22:27:37Z
# n2            kuberay-operator                                 2023-05-23T22:27:37Z


# Install RayCluster in `default`, `n1`, `n2`
helm install raycluster kuberay/ray-cluster --version 0.5.0
helm install raycluster kuberay/ray-cluster --version 0.5.0 -n n1
helm install raycluster kuberay/ray-cluster --version 0.5.0 -n n2

# Only RayCluster in n1 and n2 will be created.

Case 3: If `singleNamespaceInstall` is set to true and `watchNamespace` is not set, it will create Role and RoleBinding for the namespace where the operator is deployed.

kind create cluster --image=kindest/node:v1.23.0
kind load docker-image controller:latest

# Create namespaces
kubectl create ns n1
kubectl create ns n2

# Install a KubeRay operator (use gist3 to replace values.yaml)
# (path: helm-chart/kuberay-operator)
helm install kuberay-operator . --set image.repository=controller,image.tag=latest

# Check ClusterRole
kubectl get clusterrole | grep kuberay
# (nothing found)

# Check Role 
kubectl get role --all-namespaces | grep kuberay
# default       kuberay-operator                                 2023-05-23T22:35:15Z
# default       kuberay-operator-leader-election                 2023-05-23T22:35:15Z


# Install RayCluster in `default`, `n1`, `n2`
helm install raycluster kuberay/ray-cluster --version 0.5.0
helm install raycluster kuberay/ray-cluster --version 0.5.0 -n n1
helm install raycluster kuberay/ray-cluster --version 0.5.0 -n n2

# Only RayCluster in `default` will be created.

Case 4: If `singleNamespaceInstall` is not set, the KubeRay operator will create ClusterRole and ClusterRoleBinding.

kind create cluster --image=kindest/node:v1.23.0
kind load docker-image controller:latest

# Create namespaces
kubectl create ns n1
kubectl create ns n2

# Install a KubeRay operator (use gist3 to replace values.yaml)
# (path: helm-chart/kuberay-operator)
helm install kuberay-operator . --set image.repository=controller,image.tag=latest

# Check ClusterRole
kubectl get clusterrole | grep kuberay
# kuberay-operator                                                       2023-05-23T22:40:18Z

# Check Role 
kubectl get role --all-namespaces | grep kuberay
# default       kuberay-operator-leader-election                 2023-05-23T22:40:18Z


# Install RayCluster in `default`, `n1`, `n2`
helm install raycluster kuberay/ray-cluster --version 0.5.0
helm install raycluster kuberay/ray-cluster --version 0.5.0 -n n1
helm install raycluster kuberay/ray-cluster --version 0.5.0 -n n2

# RayCluster in `default`, `n1`, and `n2` will be created.

kevin85421 · 2023-05-23T20:59:08Z

ray-operator/main.go

-	})
+	}
+
+	if len(watchNamespaces) == 1 {


It is not possible for len(watchNamespaces) == 0 to be true. The length of strings.Split("", ",") is still 1. See this link for more details.

This seems worth including as a code comment.

Added f209400.

kevin85421 · 2023-05-23T21:01:23Z

ray-operator/main.go

+
+	if len(watchNamespaces) == 1 {
+		options.Namespace = watchNamespaces[0]
+		if watchNamespaces[0] == "" {


Based on this doc, if Namespace is specified, restricts the manager's cache to watch objects in the desired namespace. If the field is not specified, it defaults to all namespaces.

kevin85421 · 2023-05-23T21:01:59Z

ray-operator/main.go

+			setupLog.Info(fmt.Sprintf("Only watch custom resources in the namespace: %s", watchNamespaces[0]))
+		}
+	} else {
+		options.NewCache = cache.MultiNamespacedCacheBuilder(watchNamespaces)


To watch multiple namespaces, we can use MultiNamespacedCache. See this example and this doc for more details.

kevin85421 · 2023-05-23T21:03:56Z

ray-operator/config/rbac/leader_election_role.yaml

@@ -30,3 +30,12 @@ rules:
  - events
  verbs:
  - create
+- apiGroups:


This is necessary for Leader Election. We can refer to leader_election_role.yaml in the kubebuilder repo for further.

kevin85421 · 2023-05-23T21:04:41Z

helm-chart/kuberay-operator/templates/leader_election_role.yaml

@@ -32,4 +31,13 @@ rules:
  - events
  verbs:
  - create
+- apiGroups:


Necessary for leader election.

For my education, how did you notice that this was necessary? (Did some test fail?)

I attempted to skip the installation of role.yaml, but it resulted in the failure of the leader election due to permission issues. Then, I found leader_election_role.yaml.

kevin85421 · 2023-05-23T21:09:26Z

helm-chart/kuberay-operator/templates/deployment.yaml

@@ -42,10 +42,10 @@ spec:
            {{- $argList = append $argList "--enable-batch-scheduler" -}}
            {{- end -}}
            {{- $watchNamespace := "" -}}
-            {{- if .Values.singleNamespaceInstall -}}
+            {{- if and .Values.singleNamespaceInstall (not .Values.watchNamespace) -}}
            {{- $watchNamespace = .Release.Namespace -}}


Case 1: If singleNamespaceInstall is set to true and watchNamespace is not specified, the KubeRay operator will only watch the namespace where the operator is deployed.

Case 2: If watchNamespace is specified, the KubeRay operator will watch all namespaces listed in the variable. In this case, we concatenate all namespaces into a string separated by commas. Then, the string will be parsed by strings.Split(watchNamespace, ",") in main.go.

Based on this, it looks likesingleNamespaceInstall and watchNamespace are existing fields in KubeRay. The new behavior for both is clearly explained by Cases 1-4. The old behavior for singleNamespaceInstall is also described. But I think the old behavior of watchNamespace is missing from the PR description, do you mind adding it? (Maybe the only change is that it now supports multiple namespaces?)

Just to double check, are commas , forbidden characters in namespaces?

But I think the old behavior of watchNamespace is missing from the PR description, do you mind adding it?

The behavior is described by the comments in values.yaml. The comments are deleted by this PR.

# kuberay operator will only watch the resource events from the "watchNamespace" namespace. # this option has no effect if singleNamespaceInstall is true, because we assume there are no # permissions outside of the current namespace # watchNamespace: ray-user-namespace

Just to double check, are commas , forbidden characters in namespaces?

The flag --watch-namespace is a list of namespaces, separated by commas. It will be parsed by watchNamespaces := strings.Split(watchNamespace, ",") in main.go.

Right, but if a namespace is allowed to have a comma in it then breaking by commas won't work. Anyways I checked and it looks like namespaces can only have alphanumeric characters, so it's fine.

Right, but if a namespace is allowed to have a comma in it then breaking by commas won't work.

Oh, I understand now. I missed that part. Thank you for pointing it out!

kevin85421 · 2023-05-23T21:58:18Z

helm-chart/kuberay-operator/templates/multiple_namespaces_role.yaml

+kind: Role
+apiVersion: rbac.authorization.k8s.io/v1
+metadata:
+  labels: {{ include "kuberay-operator.labels" $ | nindent 4 }}


In a range block, . no longer refers to the top level scope, so use $ to access the top-level variables.

Using .Chart.name in range function helm/helm#3684

https://stackoverflow.com/questions/56671452/helm-chart-error-cant-evaluate-field-values-in-type-interface

kevin85421 · 2023-05-23T22:46:04Z

cc @msumitjain @anshulomar @Yicheng-Lu-llll would you mind reviewing this PR? Thanks!

kevin85421 · 2023-05-24T03:47:04Z

Follow up:

Add consistency check for multiple_namespaces_*.yaml
Revisit the RBAC YAML files and examine potential overlaps between role.yaml and ray_*_editor_role.yaml.

architkulkarni

Don't have prior experience with this area so I don't really have substantial critical feedback, just comments/questions.

As a general note, the PR comments are really helpful, and I think most of them could be included directly as code comments to improve readability with little or no downside.

architkulkarni · 2023-05-30T20:39:45Z

helm-chart/kuberay-operator/templates/deployment.yaml

@@ -42,10 +42,10 @@ spec:
            {{- $argList = append $argList "--enable-batch-scheduler" -}}
            {{- end -}}
            {{- $watchNamespace := "" -}}
-            {{- if .Values.singleNamespaceInstall -}}
+            {{- if and .Values.singleNamespaceInstall (not .Values.watchNamespace) -}}
            {{- $watchNamespace = .Release.Namespace -}}


Based on this, it looks likesingleNamespaceInstall and watchNamespace are existing fields in KubeRay. The new behavior for both is clearly explained by Cases 1-4. The old behavior for singleNamespaceInstall is also described. But I think the old behavior of watchNamespace is missing from the PR description, do you mind adding it? (Maybe the only change is that it now supports multiple namespaces?)

architkulkarni · 2023-05-30T20:43:59Z

helm-chart/kuberay-operator/templates/deployment.yaml

@@ -42,10 +42,10 @@ spec:
            {{- $argList = append $argList "--enable-batch-scheduler" -}}
            {{- end -}}
            {{- $watchNamespace := "" -}}
-            {{- if .Values.singleNamespaceInstall -}}
+            {{- if and .Values.singleNamespaceInstall (not .Values.watchNamespace) -}}
            {{- $watchNamespace = .Release.Namespace -}}


Just to double check, are commas , forbidden characters in namespaces?

architkulkarni · 2023-05-30T20:46:29Z

helm-chart/kuberay-operator/templates/leader_election_role.yaml

@@ -32,4 +31,13 @@ rules:
  - events
  verbs:
  - create
+- apiGroups:


For my education, how did you notice that this was necessary? (Did some test fail?)

architkulkarni · 2023-05-30T21:54:57Z

helm-chart/kuberay-operator/templates/ray_rayjob_editor_role.yaml


-{{- if .Values.singleNamespaceInstall }}
-kind: Role
-{{- else }}


What's the effect of this change? It looks like now we don't create these roles if singleNamespaceInstall is false, why don't we need them anymore in this case?

(Is it because we're replacing these roles with the new multiple_namespaces_role?)

What's the effect of this change? It looks like now we don't create these roles if singleNamespaceInstall is false, why don't we need them anymore in this case?

The permissions of this file are a subset of those in role.yaml. Therefore, KubeRay operator does not need it before/after this PR. In my understanding, there is no RoleBinding to link these Roles with any ServiceAccount. These RBAC YAML files are generated by kubebuilder. I guess they are used to define users' access.

architkulkarni · 2023-05-30T22:00:26Z

helm-chart/kuberay-operator/values.yaml

-# permissions outside of the current namespace
-# watchNamespace: ray-user-namespace
+# The KubeRay operator will watch the custom resources in the namespaces listed in the "watchNamespace" parameter.
+# watchNamespace:


Is this the source of truth for documentation, or is there a corresponding doc page that also needs to be updated?

Yes, it is the source of truth. There is no document related to it.

ray-operator/DEVELOPMENT.md

architkulkarni · 2023-05-30T22:05:20Z

ray-operator/main.go

-	})
+	}
+
+	if len(watchNamespaces) == 1 {


This seems worth including as a code comment.

architkulkarni · 2023-05-30T22:16:36Z

Also, is this a breaking change?

msumitjain

LGTM

kevin85421 · 2023-06-02T07:21:29Z

I think most of them could be included directly as code comments to improve readability with little or no downside.

Adding comments in Helm chart template YAML files may cause issues with the Helm parser.

Also, is this a breaking change?

Nope.

anshulomar

Thanks @kevin85421 for putting up this PR! It looks good to me but I have few comments:

(Functional) While the changes are fine for a manual deploy, for automated deploys there could be challenges. For example, an Argo CD project can deploy to only a single namespace. In such a case, the Argo CD won't be able to apply multiple_namespaces_role and multiple_namespaces_rolebinding to any namespace other than the one it is configured with - where it deploys the operator. So, Argo CD projects for respective namespaces (where RayServices run) will have to apply the role and rolebinding to allow the operator manage RayService in their namespaces. Hence, to facilitate such use-cases, we might want to introduce a new config attribute, say multipleNamespacesRbacEnabled. If its value is true, only then multiple_namespaces_role/rolebinding should be applied. What do you think?
(Config Readability) I think the field name singleNamespaceInstall becomes confusing after this change. This is because it could mean installing KubeRay and its roles/rolebindings either in a single namespace or in multiple namespaces (defined in watchNamespaces list). One way to resolve this confusion could be to replace this field with another field, say clusterScopedInstall. When clusterScopedInstall: true is set, then ClusterRole and ClusterRoleBinding should be created. When clusterScopedInstall: false is set, then roles and rolebindings should be created in the namespaces listed in watchNamespaces. That said, I do understand that singleNamespaceInstall field may be required for backward-compatibility. If that is the case, please ignore this point.

kevin85421 · 2023-06-02T18:39:59Z

Thank @anshulomar for the insight!

For example, an Argo CD project can deploy to only a single namespace. In such a case, the Argo CD won't be able to apply multiple_namespaces_role and multiple_namespaces_rolebinding to any namespace other than the one it is configured with - where it deploys the operator.

Wow, I wasn't aware that ArgoCD has this restriction.

Argo CD projects for respective namespaces (where RayServices run) will have to apply the role and rolebinding to allow the operator manage RayService in their namespaces. Hence, to facilitate such use-cases, we might want to introduce a new config attribute, say multipleNamespacesRbacEnabled. If its value is true, only then multiple_namespaces_role/rolebinding should be applied. What do you think?

This is a bit confusing for me. Could you please provide more details or an example to help clarify? Thanks!

Q: Which RBAC resources (Role / RoleBinding / ClusterRole / ClusterRoleBinding / ServiceAccount) should be created by the KubeRay operator Helm chart when multipleNamespacesRbacEnabled is set to false?

Current situation:

(1) Users can set rbacEnable: false and serviceAccount.create: false to prevent the creation of any RBAC resources.

(2) Users can use the singleNamespaceInstall option to determine whether to create namespaced RBAC resources (e.g., Role and RoleBinding) or cluster-scoped RBAC resources (e.g., ClusterRole and ClusterRoleBinding).

(3) If singleNamespaceInstall is set to true, users can use the watchNamespace option to determine in which namespaces the Role and RoleBinding should be installed. If watchNamespace is not set, the Role and RoleBinding will be installed in the same namespace as the KubeRay operator.

Based on (1)(2)(3), users seem to have enough power? I do not have any experience with ArgoCD. I may miss some points.

kevin85421 · 2023-06-02T18:44:18Z

@anshulomar

(Config Readability) I think the field name singleNamespaceInstall becomes confusing after this change.

I agree that this can be confusing. Breaking backward compatibility can be a challenging decision. For example, even if there is a typo like miniReplicas, we still need to make accommodations to maintain backward compatibility through the following hacks.

kuberay/helm-chart/ray-cluster/templates/raycluster-cluster.yaml

Line 105 in fe29409

    
           minReplicas: {{ $values.minReplicas | default (default 1 $values.miniReplicas) }}

Yicheng-Lu-llll · 2023-06-02T22:13:22Z

helm-chart/kuberay-operator/templates/multiple_namespaces_role.yaml

+{{- $watchNamespaces := default (list .Release.Namespace) .Values.watchNamespace }}
+{{- range $namespace := $watchNamespaces }}
+---
+kind: Role


I'm wondering if we could add thescenario: singleNamespaceInstall is set to false or not set here. So that there is no need to synchronize multiple_namespaces_role.yaml and role.yaml (same as rolebinding)

More specifically, when singleNamespaceInstall is false:

set $watchNamespaces to a placeholder value (so that only iterates once)

create a ClusterRole instead of a Role.

omit the metadata.namespace field

Originally, I intended to achieve this by updating role.yaml and rolebinding.yaml instead of creating new files (multi_namespaces_*.yaml). However, it can be extremely challenging or even impossible (?) to achieve that. The Helm parser is not smart enough.

anshulomar · 2023-06-06T10:48:30Z

Thanks @kevin85421 !

This is a bit confusing for me. Could you please provide more details or an example to help clarify? Thanks!

Sure. Given that an ArgoCD project can deploy only to one namespace, ArgoCD for kuberay operator won't be able to apply multiple_namespaces_role/rolebinding to other namespaces where RayServices will be deployed. Let us consider a Kubernetes cluster configured with Argo. And let us suppose that we need to deploy kuberay operator in namespace n1 and rayservice1 in n2 and rayservice2 in n3. In such a scenario, we will have three ArgoCD projects:

ArgoCD project1 for deploying kuberay operator in n1
ArgoCD project2 for deploying rayservice1 in n2
ArgoCD project3 for deploying rayservice2 in n3

By configuring multipleNamespacesRbacEnabled: false, ArgoCD project1 won't apply multiple_namespaces_role/rolebinding at all, thereby averting error scenario that could arise due to permission issue. So, we will have to additionally configure ArgoCD project2 and project3 to apply the required role/rolebinding in their respective namespaces. This additional configuration can be done by end clients themselves - it doesn't require any changes in this repository to manage it.

Q: Which RBAC resources (Role / RoleBinding / ClusterRole / ClusterRoleBinding / ServiceAccount) should be created by the KubeRay operator Helm chart when multipleNamespacesRbacEnabled is set to false?

When multipleNamespacesRbacEnabled: false is set, this Helm chart should not create any resources in a namespace different from the one it is installed in. This restriction is clearly applicable to only namespace-scoped resources such as roles, rolebindings, serviceaccount and so on. ClusterRole and ClusterRoleBinding are cluster-scoped resources so this Helm chart should create them if singleNamespaceInstall: false.

Based on (1)(2)(3), users seem to have enough power? I do not have any experience with ArgoCD. I may miss some points.

Yes, users have enough power but for automated deployment tools like Argo, there could be permission restrictions for applying manifests to multiple namespaces as explained in this comment above.

Does it help? Or is it still confusing?

kevin85421 · 2023-06-12T18:21:28Z

@anshulomar Thank you for your reply! I understand your point clearly, and I will proceed to draft a pull request.

…ces (ray-project#1106) Watch CR in multiple namespaces with namespaced RBAC resources

kevin85421 added 5 commits May 23, 2023 18:13

watch multiple namespaces

5fd1446

update

6e27ff4

update

853026b

rbac consistency

b04ce3d

update

41fedd0

kevin85421 commented May 23, 2023

View reviewed changes

kevin85421 added 2 commits May 23, 2023 21:34

update

28cb9b9

update

d4f183c

kevin85421 commented May 23, 2023

View reviewed changes

update

ecba427

kevin85421 mentioned this pull request May 23, 2023

[WIP] Multi-namespace cache #1094

Closed

4 tasks

kevin85421 changed the title ~~Watch multiple namespaces~~ [Feature] Watch CR in multiple namespaces with namespaced RBAC resources May 23, 2023

kevin85421 marked this pull request as ready for review May 23, 2023 22:43

kevin85421 requested review from architkulkarni, sihanwang41, gvspraveen and shrekris-anyscale May 23, 2023 22:44

architkulkarni self-assigned this May 30, 2023

architkulkarni approved these changes May 30, 2023

View reviewed changes

msumitjain approved these changes May 31, 2023

View reviewed changes

msumitjain mentioned this pull request May 31, 2023

[TEMP] [WIP] [DO_NOT_MERGE] Kuberay-operator deployment chart changes to support singleNamespaceInstall true #1097

Closed

4 tasks

add comment

f209400

anshulomar suggested changes Jun 2, 2023

View reviewed changes

Yicheng-Lu-llll reviewed Jun 2, 2023

View reviewed changes

kevin85421 merged commit 36b112e into ray-project:master Jun 5, 2023
17 checks passed

kevin85421 mentioned this pull request Jun 13, 2023

[Helm][RBAC] Introduce the option crNamespacedRbacEnable to enable or disable the creation of Role/RoleBinding for RayCluster preparation #1162

Merged

4 tasks

anshulomar mentioned this pull request Jun 24, 2023

[Bug] KubeRay tries to create ClusterRoleBinding when singleNamespaceInstall and rbacEnable are set to true #1186

Closed

2 tasks

lowang-bh pushed a commit to lowang-bh/kuberay that referenced this pull request Sep 24, 2023

[Feature] Watch CR in multiple namespaces with namespaced RBAC resour…

8fe3891

…ces (ray-project#1106) Watch CR in multiple namespaces with namespaced RBAC resources

This was referenced Oct 9, 2023

[Enhancement] Maintain code cleanliness #1472

Closed

Remove miniReplicas in raycluster-cluster.yaml #1473

Merged

evalaiyc98 mentioned this pull request Oct 16, 2023

[Doc][KubeRay] Doc for Helm chart RBAC ray-project/ray#40360

Merged

8 tasks

[Feature] Watch CR in multiple namespaces with namespaced RBAC resources #1106

[Feature] Watch CR in multiple namespaces with namespaced RBAC resources #1106

Conversation

kevin85421 commented May 23, 2023 • edited Loading

Why are these changes needed?

Related issue number

Checks

Case 1: If singleNamespaceInstall is set to false, the KubeRay operator will create ClusterRole and ClusterRoleBinding.

Case 2: If singleNamespaceInstall is set to true and watchNamespace is set, it will create Role and RoleBinding for all namespaces listed in watchNamespace.

Case 3: If singleNamespaceInstall is set to true and watchNamespace is not set, it will create Role and RoleBinding for the namespace where the operator is deployed.

Case 4: If singleNamespaceInstall is not set, the KubeRay operator will create ClusterRole and ClusterRoleBinding.

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

kevin85421 commented May 23, 2023

kevin85421 commented May 24, 2023

architkulkarni left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

architkulkarni commented May 30, 2023

msumitjain left a comment

Choose a reason for hiding this comment

kevin85421 commented Jun 2, 2023

anshulomar left a comment

Choose a reason for hiding this comment

kevin85421 commented Jun 2, 2023

kevin85421 commented Jun 2, 2023

Yicheng-Lu-llll Jun 2, 2023 • edited Loading

Choose a reason for hiding this comment

kevin85421 Jun 2, 2023 • edited Loading

Choose a reason for hiding this comment

anshulomar commented Jun 6, 2023 • edited Loading

kevin85421 commented Jun 12, 2023

kevin85421 commented May 23, 2023 •

edited

Loading

Case 1: If `singleNamespaceInstall` is set to false, the KubeRay operator will create ClusterRole and ClusterRoleBinding.

Case 2: If `singleNamespaceInstall` is set to true and watchNamespace is set, it will create Role and RoleBinding for all namespaces listed in watchNamespace.

Case 3: If `singleNamespaceInstall` is set to true and `watchNamespace` is not set, it will create Role and RoleBinding for the namespace where the operator is deployed.

Case 4: If `singleNamespaceInstall` is not set, the KubeRay operator will create ClusterRole and ClusterRoleBinding.

Yicheng-Lu-llll Jun 2, 2023 •

edited

Loading

kevin85421 Jun 2, 2023 •

edited

Loading

anshulomar commented Jun 6, 2023 •

edited

Loading