-
Notifications
You must be signed in to change notification settings - Fork 212
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
multi-tenant env support (weblogic-kubernetes-operator:4.2.8) #5114
Comments
@Krishnamotive, with the 3.x version of the operator, it was only required that someone with sufficient cluster privileges install the CRD document and then the rest of the installation could be done in a single namespace using the dedicated mode, as you described. However, the 4.x operator added a schema conversion webhook to assist customers with upgrading from the v8 version of the domain resource schema to the v9 version and the new v1 cluster resource. Since we were only very rarely hearing requests for support of multitenant cluster environments, we elected to have the CRD always be installed by the endpoint serving the schema conversion webhook. You can achieve something like the 3.x dedicated mode by having someone with sufficient cluster privileges install the webhook endpoint using the webhookOnly option. Then, you could install one or more operator instances in dedicated namespaces using the selection strategy and the operatorOnly option. We are working on an enhancement that would allow you to skip installing the schema conversion webhook entirely. When this enhancement is available, we would have restored the 3.x behavior of just requiring the installation of the CRD documents (with a Looping in @mriccell, who is our product manager. |
Thanks @rjeberhard for your prompt response. |
The enhancement will be available in the next few weeks to about a month. I can't yet give you a better estimate because most of the WebLogic team is focused on completing the next version of the product (WebLogic 14.1.2) |
I would like to inquire if it's possible to create namespace-specific RBAC roles separately and then bind them to the service account (using admin privileges for this step). Once created, we could use the following options, for example: --set rbac.enabled=false --set serviceAccountName=weblogic-operator-sa. I looked through the charts/templates but couldn't find an option to disable RBAC. Could you please confirm if the above approach is feasible? |
I'm hoping that we don't need an additional option. We already have |
I am trying to deploy web-logic operator weblogic-kubernetes-operator:4.2.8 on OCP 4.16 multi-tenant env with dedicated domainNamespaceSelectionStrategy. However some roles like weblogic-operator-role , weblogic-operator-general fails RBAC permission issues.
Do we need to follow any specific guidelines for this multi-tenant type installation?
Also, do we need to add any namespace based custom roles to achieve this in multi-tenant env before proceeding installation?
The text was updated successfully, but these errors were encountered: