Skip to content
This repository has been archived by the owner on Jul 30, 2021. It is now read-only.

Add Eclipse Che operator #280

Closed
wants to merge 8 commits into from
Closed

Add Eclipse Che operator #280

wants to merge 8 commits into from

Conversation

ghost
Copy link

@ghost ghost commented Apr 13, 2019

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

image

image

@openshift-ci-robot openshift-ci-robot added size/XL Denotes a PR that changes 500-999 lines, ignoring generated files. needs-ok-to-test Indicates a PR that requires an org member to verify it is safe to test. labels Apr 13, 2019
@openshift-ci-robot
Copy link
Collaborator

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 /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

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.

@ghost
Copy link
Author

ghost commented Apr 13, 2019

Can someone help with the failing build please?

ERROR:operatorcourier.validate:category Developer Tools is not a valid category

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.

@gallettilance
Copy link
Member

@ghost
Copy link
Author

ghost commented Apr 15, 2019

@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?

@gallettilance
Copy link
Member

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).

@ghost
Copy link
Author

ghost commented Apr 15, 2019

@galletti94 got it. By the way, it looks like this is a new requirement since when I issued #193 build was a success.

Will this new requirement affect #193 too?

@gallettilance
Copy link
Member

gallettilance commented Apr 15, 2019

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.

@gallettilance
Copy link
Member

@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).

@ghost ghost mentioned this pull request Apr 18, 2019
verbs:
- "*"
- apiGroups:
- route.openshift.io
Copy link
Contributor

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?

Copy link
Author

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

Copy link
Contributor

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.

Copy link
Author

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.

Copy link
Contributor

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"

Copy link
Author

@ghost ghost Apr 30, 2019

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)

Copy link
Author

@ghost ghost Apr 30, 2019

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

@gallettilance
Copy link
Member

@eivantsov @SamiSousa FYI I just added a PR to operator-courier to add this category.

@bmicklea
Copy link

Now that the developer tools category exists is this in a merge-able state?

@ghost
Copy link
Author

ghost commented Apr 29, 2019

@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:
Copy link
Contributor

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

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ssimk0 thank you. Fixed

@dmesser
Copy link
Collaborator

dmesser commented May 2, 2019

@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?
Otherwise /lgtm

@ghost
Copy link
Author

ghost commented May 2, 2019

@dmesser no, there are no pre reqs for Kubernetes, default role+ role binding is sufficient on k8s.

@dmesser
Copy link
Collaborator

dmesser commented May 2, 2019

Ok cool. Since you submit copies of your CSV to both community (OpenShift) and upstream-community (Kubernetes), you could omit the OpenShift specific stuff in the Kubernetes-focussed version of your CSV.

@ghost
Copy link
Author

ghost commented May 2, 2019

@dmesser thanks. Fixed

@dmesser
Copy link
Collaborator

dmesser commented May 2, 2019

@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

@ghost
Copy link
Author

ghost commented May 2, 2019

@dmesser thanks for your review. Fixed.

@SamiSousa
Copy link
Contributor

SamiSousa commented May 3, 2019

@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
Copy link
Contributor

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?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@SamiSousa

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 ?

Copy link
Contributor

@davidfestal davidfestal May 22, 2019

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 ?

@dmesser
Copy link
Collaborator

dmesser commented May 16, 2019

Can you separate the submission to community-operators and upstream-community-operators into a separate PR? This way we can validaty faster and accordingly to the target platform (OCP vs. vanilla k8s)

@bmicklea
Copy link

@davidfestal can you help out with this?

@davidfestal
Copy link
Contributor

@bmicklea Sure, I'll look into it next week

@davidfestal
Copy link
Contributor

Can you separate the submission to community-operators and upstream-community-operators into a separate PR? This way we can validaty faster and accordingly to the target platform (OCP vs. vanilla k8s)

@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 7.0.0-beta-5.0
Che release.

@dmesser dmesser closed this May 24, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
needs-ok-to-test Indicates a PR that requires an org member to verify it is safe to test. size/XL Denotes a PR that changes 500-999 lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants