-
Notifications
You must be signed in to change notification settings - Fork 562
Conversation
Hi @eivantsov. Thanks for your PR. I'm waiting for a operator-framework or openshift member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
Can someone help with the failing build please?
It looks like it was allowed to provide own categories. It looks like it's not the case now. Is there a list of valid categories I can choose from? Btw, I have upgraded operator-courier to the latest version, and verify does not report anything illegal. |
Here is a list of the current allowed categories https://github.com/operator-framework/community-operators/blob/master/docs/required-fields.md#categories |
@galletti94 thanks. What would be the right way to proceed if none of those fits Eclipse Che operator? Is it possible to contribute a new category? |
Good question. I will escalate this concern and get back to you on that. Short term - removing that field, will categorize your operator as "other" - if this is acceptable for you in the short term it will help accelerate getting your operator into operatorhub.io. We can always add the category in a later PR (once this category becomes available). |
The UI validation done in this PR is one currently only done for operatorhub.io PRs so #193 will not be affected. However we do plan on using that same validation for both OCP and operatorhub.io in the near future - possibly as early as next week. |
@eivantsov To add a category to the list of accepted categories, please open a PR in this repo to add that category to the docs. In the PR, please briefly describe why this additional category is needed. Once it is merged I will add that category to operator-courier. Note that this change will only be visible when a new release of courier is cut (which may take a few days). |
verbs: | ||
- "*" | ||
- apiGroups: | ||
- route.openshift.io |
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.
If this operator has a dependency on this openshift API, would this still work on vanilla kubernetes?
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.
@SamiSousa Yes, when on k8s infra, the operator will create ingresses rather than routes. In csv, I request permissions to manage both
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.
When running this operator on minikube, the operator logs repeatedly print this message:
E0426 17:39:16.986396 1 reflector.go:134] sigs.k8s.io/controller-runtime/pkg/cache/internal/informers_map.go:126: Failed to list *v1beta1.Ingress: ingresses.extensions is forbidden: User "system:serviceaccount:eclipse-che:che-operator" cannot list resource "ingresses" in API group "extensions" in the namespace "eclipse-che"
After deploying the example CR, it's clear to me that the operator is unable to resolve it.
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.
@SamiSousa thanks for checking that. Is it possible that the APIGroup is wrong? For example, in Jaeger operator it's extensions, while it's extensions/v1beta1 for Eclipse Che. Weird thing though is that I cannot reproduce it on minikube myself, though I haven't ever tested with OLM/Marketplace on kube (only OCP/OKD).
Anyways, I have fixed API group for ingresses. I'd appreciate if you share instructions on how you test on minikube. Thanks.
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've tested this again and still have this error:
ce "eclipse-che"
E0430 16:48:42.334461 1 reflector.go:134] sigs.k8s.io/controller-runtime/pkg/cache/internal/informers_map.go:126: Failed to list *v1beta1.Ingress: ingresses.extensions is forbidden: User "system:serviceaccount:eclipse-che:che-operator" cannot list resource "ingresses" in API group "extensions" in the namespace "eclipse-che"
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.
@SamiSousa are ingresses in the role that is bound to che-operator SA?
Also, can you please share steps you take to test it? On MiniKube I am applying yamls with role, rolebinding and service account manually (I never tried OLM and Marketplace on k8s)
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.
Checked it again on MiniKube. This is the role https://github.com/eclipse/che-operator/blob/master/deploy/role.yaml, and it worked, service account can manage ingresses.
@SamiSousa what is your MiniKube version? It is related to RBAC but I cannot figure out why it fails on your side.
minikube version: v0.33.1
@eivantsov @SamiSousa FYI I just added a PR to operator-courier to add this category. |
Now that the developer tools category exists is this in a merge-able state? |
@bmicklea there are still some unresolved comments. I have pushed a fix, waiting for @SamiSousa to confirm. |
To instruct the operator to skip deploying PostgreSQL and Keycloak and connect to an existing DB and Keycloak instead: | ||
|
||
* set respective fields to `true` in a custom resource spec | ||
* provide the operator with connection and authentication details: |
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.
Hi,
here you probably miss the empty line, because it's not render as second item but as:
- set respective fields to
true
in a custom resource spec * provide the operator with connection and authentication details:
you can test it here and also it will be look probably little better when you should tab little the code section above them
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.
@ssimk0 thank you. Fixed
@eivantsov - the description talks about pre-requisites for OpenShift. Given that you also submit to OperatorHub.io you also target the wider Kubernetes community. Are there any pre-requisites there too? |
@dmesser no, there are no pre reqs for Kubernetes, default role+ role binding is sufficient on k8s. |
Ok cool. Since you submit copies of your CSV to both |
@dmesser thanks. Fixed |
@eivantsov great, thanks! Last nit: the one-liner description still mentions OpenShift - this could confuse users. Also, can you make the code example in the description in triple backticks wrapping a block instead of single backticks per individual line? Otherwise /lgtm |
@dmesser thanks for your review. Fixed. |
@eivantsov Looks good! Could you squash your commits please? 🙂 |
|
||
oc create clusterrole che-operator --resource=oauthclients --verb=get,create,delete,update,list,watch | ||
|
||
oc create clusterrolebinding che-operator --clusterrole=che-operator --serviceaccount=${NAMESPACE}:che-operator |
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.
Why can't this additional clusterrole be specified in the CSV's clusterPermissions
section?
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.
If I understand correctly, this might be to avoid adding unnecessary permissions, since these permissions would only be required when auth.openShiftoAuth
is enabled, which is not by default.
Do you think these permissions should be added systematically ?
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.
and wouldn't it represent some unnecessary security risk ?
Can you separate the submission to |
@davidfestal can you help out with this? |
@bmicklea Sure, I'll look into it next week |
@dmesser The 2 new split new PRs are #383 and #384 However I flagged them as WIP because I still want to update them with the last |
This PR adds Eclipse Che operator to community operators and upstream community operators. Eclipse Che operator auto detects infra, so can run on vanilla k8s and OpenShift.
Please let me know if I have chosen the wrong categories.
Tested on 4.0.0-0.9