-
Notifications
You must be signed in to change notification settings - Fork 20
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
Change scope of test-operator to namespace #264
Change scope of test-operator to namespace #264
Conversation
Skipping CI for Draft Pull Request. |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: lpiwowar The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
7fd0f3a
to
ad48997
Compare
The test-operator got changed from cluster scoped operator to namespace scoped operator in this PR [1]. It is now recommended that the test-operator gets installed in a separate namespace other than the one where the test pods are spawned. This patch ensures that: - the test-operator gets installed in the openstack-test-operator namespace - the test-operator spawns test pods in the openstack namespace [1] openstack-k8s-operators/test-operator#264
ad48997
to
2f211b0
Compare
The test-operator got changed from cluster scoped operator to namespace scoped operator in this PR [1]. It is now recommended that the test-operator gets installed in a separate namespace other than the one where the test pods are spawned. This patch ensures that: - the test-operator gets installed in the openstack-test-operator namespace - the test-operator spawns test pods in the openstack namespace [1] openstack-k8s-operators/test-operator#264
The test-operator got changed from cluster scoped operator to namespace scoped operator in this PR [1]. It is now recommended that the test-operator gets installed in a separate namespace other than the one where the test pods are spawned. This patch ensures that: - the test-operator gets installed in the openstack-test-operator namespace - the test-operator spawns test pods in the openstack namespace [1] openstack-k8s-operators/test-operator#264
2f211b0
to
883001d
Compare
The test-operator got changed from cluster scoped operator to namespace scoped operator in this PR [1]. It is now recommended that the test-operator gets installed in a separate namespace other than the one where the test pods are spawned. This patch ensures that: - the test-operator gets installed in the openstack-test-operator namespace - the test-operator spawns test pods in the openstack namespace [1] openstack-k8s-operators/test-operator#264
/test all |
Test-operator is currently designed to be a cluster scoped operator. This means it can watch and modify resources across all OCP cluster. This patch changes the operator to namespace scoped operator. By default it is going to watch only: - openstack-test-operator namespace: This is a namespace where we recommend to install the test-operator. Prior to the installation we recommend to create an OperatorGroup with targetNamespaces value set to openstack-test-operator and openstack. - openstack: This is a namespace where the openstack controll plane is deployed. Test-operator requires an access to this namespace in order to read openstack specific CMs and Secrets (e.g., clouds.yaml). Depends-On: openstack-k8s-operators/ci-framework#2600
883001d
to
81c09bd
Compare
/test all |
The test-operator got changed from cluster scoped operator to namespace scoped operator in this PR [1]. It is now recommended that the test-operator gets installed in a separate namespace other than the one where the test pods are spawned. This patch ensures that: - the test-operator gets installed in the openstack-test-operator namespace - the test-operator spawns test pods in the openstack namespace [1] openstack-k8s-operators/test-operator#264
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have tested this patch and it seems to be running well. The only changes I requested are in the documentation for this because some steps have small mistakes.
I also didn't find the installplans to delete according to documentation 🤔 Maybe it's just a mistake in my testing, but I wanted to mention it here at least.
/lgtm |
why you want to change the scope? we can not do it. this needs further discussion |
/hold At the moment it looks like that we can not switch the test-operator to project scoped because:
|
when there will be a new api version, conversion webhooks can do the migration of existing objects to the new version. |
What this PR does is that it allows exactly this. It allows the installation of the test-operator in a separate namespace ( If you install the test-operator in the
But there is the option of installing it in a separate namespace let's say
@stuggi any thoughts, please? I'm 100 % ok with not merging this :) I just want to be sure that there is a justification for it. So do we agree to keep the test-operator ClusterScoped because of?
|
how would the clusterroles be managed in this case? you'd have to manually create them?
the functionality of the conversion webhooks is crucial, especially for the other service operators. for the test-operator it might be ok to say that you'd have to delete old CRs to unblock installation of a new operator version which brings a new api version, and afterwards you can use the new api, but we can not do it for the other services and from my pov we must be consistent across all operators. |
No, you would not have to create them manually. OLM would create them. |
but you are changing the type here from ClusterRole -> Role |
Yes, I know. I find this confusing as well. I have test-operator index build here which contains test-operator with this PR. If you install test-operator like this:
Then the OLM will create ClusterRole.
https://olm.operatorframework.io/docs/concepts/crds/operatorgroup/ In contrast if you install test-operator (with this change) like this:
then only |
As per the previous comments, I'm closing this PR. We won't be switching the test-operator to a namespace-scoped one. |
Test-operator is currently designed to be a cluster scoped operator. This means it can watch and modify resources across all OCP cluster.
This patch changes the operator to namespace scoped operator. By default it is going to watch only:
openstack-test-operator namespace: This is a namespace where we recommend to install the test-operator. Prior to the installation we recommend to create an OperatorGroup with targetNamespaces value set to openstack-test-operator and openstack.
openstack: This is a namespace where the openstack controll plane is deployed. Test-operator requires an access to this namespace in order to read openstack specific CMs and Secrets (e.g., clouds.yaml).