Che: ConsoleLink for Che on OpenShift

[gorkem]

When Che operator is installed into an OpenShift 4.2 and later, it should create a ConsoleLink CR so that there is a link on the _Application Menu_ of the console to Che installation. This URL information will further enable Console to work with the given Che instance.

[rohitkrai03]

Example ConsoleLink CR -

apiVersion: console.openshift.io/v1
kind: ConsoleLink
metadata:
  name: che
spec:
  applicationMenu:
    imageURL: >-
      https://console-openshift-console.apps.jhadvig-shared-5.devcluster.openshift.com/static/assets/openshift.svg
    section: Red Hat Applications
  href: 'https://che.openshift.io'
  location: ApplicationMenu
  text: Che Workspace

[skabashnyuk]

What is the role of Devconsole for generic upstream Eclipse Che?
I'm not sure that making such a specific kind of CR is make sense for upstream Che. What if we create CR that would be agnostic to DevConsole and have more information like:

• Che server url
• Che workspace api url
• Devfile registry url
• Plugin registry url
• Keycloak url
• etc
  After that DevfConsole can read it and do appropriate changes on it UI

wdyt @gorkem @rohitkrai03 @benoitf @l0rd @davidfestal ?

[rohitkrai03]

@skabashnyuk What do you mean by create CR that would be agnostic to DevConsole? Who will create this CR, devconsole or che operator?

[davidfestal]

I'm not sure that making such a specific kind of CR is make sense for upstream Che

@skabashnyuk

Well, upstream Che Operator doesn't mean operator for upstream Kubernetes.

Currently the upstream Che operator already manages both Openshift and Pure K8s as 2 supported use-cases, with specific actions related to each one (routes vs ingresses, Openshift OAuth, etc ...)

It now evens detects the difference between Openshift 3.11 and Openshift 4 in order to adapt the OAuth mechanism or external API URL retrieval.

So I don't see why the upstream Eclipse Che operator could not create such a CR (which seems to be part of the overall Openshift 4 infrastructure) when running under Openshift 4 and the corresponding API group is available in current cluster.

@gorkem Am I missing some point here ?

[skabashnyuk]

@skabashnyuk What do you mean by create CR that would be agnostic to DevConsole? Who will create this CR, devconsole or che operator?

Che operator

So I don't see why the upstream Eclipse Che operator could not create such a CR

It looks to me as a very downstream specific feature.

[gorkem]

There is only one operator (code) and operators are meant to handle configuration differences such as these. This could as well be a difference on storage such as Azure vs AWS.

I am not sure if supporting something that happens on a specific platform is a bad thing. Otherwise open source projects would never be able to adopt operating system specific key bindings for instance. It is just a better experience for Che users on OpenShift, we do not take anything away from other distros.

[skabashnyuk]

ok

[l0rd]

I am wondering what happens if 2 different Che instances are deployed on the same cluster. There should be only one Che ConsoleLink per OS cluster but there may be multiple Che servers right?

In other words: a Che Server can be deployed by any user but a Che ConsoleLink can only be created by a cluster-wide admin. Should we make the ConsoleLink creation optional? Or handled by a different operator (not che-operator but the console operator)?

[ibuziuk]

@skabashnyuk am I correct that Platform team is going to take care of this issue?

[skabashnyuk]

yes

[gorkem]

Why do we need to support multiple Che instances on a single cluster? It will be even harder to support when we move to Workspace CRDs. Ideally I do not even want to create CheCluster resource, it should be created for me when I install the operator and operator should just adjust if/when I make changes to it.

This is on che-operator's responsibility. Che operator creates the che resources on the cluster and one of those is ConsoleLink. I do not see why we need to complicate it.

[sparkoo]

I've been working on this and there is high chance I won't be able to finish this task before leaving to 2weeks paternity leave. Here's how to make Openshift 4 and ConsoleLink running locally. The tricky part is that CodeReady Containers has latest bundle with openshift 4.1.9 and console links are supported from 4.2.

• run CodeReady Containers by this guide https://code-ready.github.io/crc/ (crc repo https://github.com/code-ready/crc see releases there)
  
  
  
  • I was able to run it only with libvirt. I've tried also virtualbox but with no luck
  
  
  • bundles are here http://cdk-builds.usersys.redhat.com/builds/crc/ (available only inside Red Hat network) download the newest version 4.1.9/linux/crc_libvirt_4.1.9.crcbundle (http://cdk-builds.usersys.redhat.com/builds/crc/4.1.9/linux/crc_libvirt_4.1.9.crcbundle)
  
  
  • first run crc setupthat will tell you WARN CRC bundle is not embedded in the binary, see 'crc help' for more details. that is ok.
  
  
  • crc start will tell you something like ERRO Error occurred: File /home/mvala/.crc/crc_libvirt_4.1.9.crcbundle does not exist. put crcbundle there or start with crc start -b <path_to_crcbundle>
  
  
  • crc start will ask for pull secret. If you type ? it will tell you url where to get it (this is one Sergii asked if it's working for us). Just click Copy Pull Secret on the website and paste it into the terminal.
  
  
  • after this, crc should start after few minutes
  
  
  • export KUBECONFIG=~/.crc/cache/crc_libvirt_4.1.9/kubeconfig to get oc/kubectl working with crc
  
  
  • note that at least 10G of memory is needed to run Che (crc start --memory 10240)
  
  
  • crc start prints password for kubeadmin account, something like this INFO Login to the console with user: kubeadmin, password: bUbiK-gvJb3-MAnW5-8MnMs
  
  
• now you should have openshift 4.1.9 running, but consolelinks are supported from 4.2
• update openshift-console image with oc set image deployment/console -n openshift-console console=quay.io/openshift/origin-console:4.2 and wait for rolling update done
• now you still don't have console link custom resource -> oc apply -f https://raw.githubusercontent.com/openshift/console-operator/release-4.2/manifests/00-crd-extension-console-link.yaml
• then you can create ConsoleLink object like this:

cat << EOF | oc apply -f -
apiVersion: console.openshift.io/v1
kind: ConsoleLink
metadata:
  name: che
spec:
  applicationMenu:
    imageURL: >-
      https://raw.githubusercontent.com/eclipse/che-website/master/che/images/ico/96x96.png
    section: Red Hat Applications
  href: 'https://che.openshift.io'
  location: ApplicationMenu
  text: Che Workspace
EOF

[sparkoo]

to possible future assignee of this task. Here's few hints how I work with che-operator:

• create eclipse-che project in openshift -> oc new-project eclipse-che
• set WATCH_NAMESPACE env variable -> export WATCH_NAMESPACE=eclipse-che (I'm not exactly sure what it's doing though)
• run deploy.sh script and then immediately delete the operator. With that, you'll have openshift ready to run operator locally -> oc delete deployment che-operator -n eclipse-che
• now you should be able to run the operator directly and if you have KUBEFONFIG set properly, it will communicate with your crc instance -> go run cmd/manager/main.go

[sparkoo]

Status of 2019-08-21

Che-operator have vendored dependencies and there is some undefined version of openshift/api, which is definitely older than 4.2. Issue is that ConsoleLink object is from 4.2, so there is no ConsoleLink Go struct to create. i've been following 2 approaches:

• update openshift/api dependency
  
  
  
  • WIP branch is here https://github.com/sparkoo/che-operator/tree/updateVendorToOpenshift42
  
  
  • it seems working, but it would need to be polished
    
    
    
    
    
    • we don't need all files in vendor dependency
    
    
    
    • what about this commit that is in upstream master repo https://github.com/eclipse/che-operator/commit/7572b31fc294d5e502087cf4bfcfb1f76faed8ea ?
    
    
    
  
  
  • has to be properly tested as it's changing a lot of things and there is high chance of breaking something
  
  
  • I don't know whether there is an easy way how to update dependencies. I did it manually.
  
  
• grab ConsoleLink struct from openshift/api 4.2 and include it into che-operator
  
  
  
  • WIP branch here https://github.com/sparkoo/che-operator/tree/addConsoleLink
  
  
  • buildable, but fails in runtime with no kind is registered for the type v1.ConsoleLink in scheme "k8s.io/client-go/kubernetes/scheme/register.go:60 so aparently the type shold be registered
  
  
  • there is some code that should be generated (https://github.com/sparkoo/che-operator/blob/addConsoleLink/pkg/apis/org/v1/zz_generated.deepcopy.go), I've updated that manually.
  
  
• there's another approach, suggested by @davidfestal, to use http API
  
  
  
  • it's already used in code https://github.com/eclipse/che-operator/blob/master/pkg/util/util.go#L149
  
  
  • this would probably be safest option that should not break anything
  
  
  • have to know whether API is available (see https://github.com/eclipse/che-operator/blob/master/pkg/util/util.go#L63)
  
  

[sparkoo]

2019-08-22 Morning update

I was able to successfully register ConsoleLink go struct and create consolelink object with that. I've created draft PR with first rough implementation.

[l0rd]

@sleshchenko after discussions this morning we figured out that ConsoleLink do not work for non TLS links. As a consequence we should not create a ConsoleLink if TLS is disabled.