Che: CHE_INFRA_OPENSHIFT_ROUTE_LABELS is not accepted

Created on 3 Nov 2020  ·  20Comments  ·  Source: eclipse/che

When passing the parameter CHE_INFRA_OPENSHIFT_ROUTE_LABELS in the cluster deploy it is not working correctly

aredoc areinstall kinquestion

Most helpful comment

@cronaldo
CHE_INFRA_OPENSHIFT_ROUTE_LABELS is mainly for routes created for workspaces.
For che-server, registries, keycloak routes it is needed to use the following fields in the CR:

  • spec.auth.identityProviderRoute.labels
  • spec.server.cheServerRoute.labels
  • spec.server.pluginRegistryRoute.labels
  • spec.server.devfileRegistryRoute.labels

And it is available since 7.20.0 version of che-operator
https://www.eclipse.org/che/docs/che-7/installation-guide/configuring-labels-for-routes/

All 20 comments

Hello @cronaldo
Could you please provide more details on this issue, according to the default template
https://github.com/eclipse/che/issues/new?assignees=&labels=kind%2Fbug&template=bug_report.md&title=

Thanks!

Sorry Artem,

I'm sending the details:

Describe the bug

When adding values ​​in CHE_INFRA_OPENSHIFT_ROUTE_LABELS they are not passed on to the routes created

Che version

  • [7.19.2]

    Steps to reproduce

From the "customCheProperties:" section of the Eclipse Che cluster creation file, the supported option CHE_INFRA_OPENSHIFT_ROUTE_LABELS is added to it, step labels of routes so that Eclipse Che pods use routes by environment, example: type = routeprod, type = routerdev in this way pods can leave via different routers. When passing values ​​in CHE_INFRA_OPENSHIFT_ROUTE_LABELS they are not being used at the time of the creation of the routes, thus leaving the routes with pedestrian status and the cluster deployment error, since the route is not exposed.

Expected behavior

When adding values ​​in CHE_INFRA_OPENSHIFT_ROUTE_LABELS they should be passed on to the routes to be created, when checking the yaml the values ​​are in the file, but in the routes the values ​​are not set.

Runtime

  • [ ] kubernetes (include output of kubectl version)
  • [X] Openshift (include output of oc version)
  • [ ] minikube (include output of minikube version and kubectl version)
  • [ ] minishift (include output of minishift version and oc version)
  • [ ] docker-desktop + K8S (include output of docker version and kubectl version)
  • [ ] other: (please specify)

Installation method

  • [ ] chectl

    • provide a full command that was used to deploy Eclipse Che (including the output)

    • provide an output of chectl version command

  • [X] OperatorHub
  • [ ] I don't know

Thank you @cronaldo for providing the details! :+1:
I'm setting P2, but feel free to reprioritize it if needed.
cc @tolusha

@cronaldo
CHE_INFRA_OPENSHIFT_ROUTE_LABELS is mainly for routes created for workspaces.
For che-server, registries, keycloak routes it is needed to use the following fields in the CR:

  • spec.auth.identityProviderRoute.labels
  • spec.server.cheServerRoute.labels
  • spec.server.pluginRegistryRoute.labels
  • spec.server.devfileRegistryRoute.labels

And it is available since 7.20.0 version of che-operator
https://www.eclipse.org/che/docs/che-7/installation-guide/configuring-labels-for-routes/

@tolusha

When installing the operator I do not need to pass labels on the routes, only when creating the workspaces, did version 7.20.0 correct the problem of 7.19.2?

Regarding the workspace routes, this feature exists in 7.19.2
/cc @mshaposhnik @skabashnyuk

@tolusha

When performing tests in version 7.19.2 and passing a value in the CHE_INFRA_OPENSHIFT_ROUTE_LABELS option, it is not propagated for routes that are elevated to workspaces

Did you start workspace after updating spec.server.customCheProperties.CHE_INFRA_OPENSHIFT_ROUTE_LABELS field in the CR?

I add directly to the creation of the workspace, follow example below:

apiVersion: org.eclipse.che/v1
kind: CheCluster
metadata:
  name: eclipse-che
  namespace: <che>
spec:
  server:
    cheImageTag: ''
    devfileRegistryImage: ''
    pluginRegistryImage: ''
    tlsSupport: true
    selfSignedCert: false
    customCheProperties:
      CHE_INFRA_OPENSHIFT_ROUTE_LABELS: "foo=bar"
  auth:

So, I have re-checked again. Here is my che-server version:

image

Che-cluster config:

image

Workspace route has the custom lable:

image

Another route:
image

@cronaldo Either we're looking into different routes (Che server vs Workspace) or some other misunderstanding...

@mshaposhnik
Could you confirm the version of your Openshift (Kubernetes)? Another question, are you passing the parameter on the Che or Workspace server?

Openshift 4.4. Parameter should be added to the Che server (and it will apply it for all workspaces)

@mshaposhnik
Thanks for the answers, I will perform new tests to validate again

@mshaposhnik

I tried to reproduce the same steps in the environment I'm using. I tried on a newer version to highlight some problem of version 7.19.2, but the label is not set on the route. Would you help me?

Openshift version:

version_ocp

Operator version:
operator_version

custom config cluster:

yaml_cluster

cluster details:

cluster_details

route details:

route_pending

no value in route:

route_details

@cronaldo You're looking into the che-server route. It will have no labels (because they're managed by operator, not che-server itself). This property affects only routes which are originated by user workspaces. If you want labels on che-server route, you need to add them into operator somehow.

@mshaposhnik but can I put route labels on the che server cluster? Or is there no such possibility? Is CHE_INFRA_OPENSHIFT_ROUTE_LABELS configured directly on Che Cluster, and does it propagate this configuration to the correct workspaces?

@cronaldo I think your case is a good example that we are not good enough in our documentation.
There is a didicated page that explaining https://www.eclipse.org/che/docs/che-7/installation-guide/configuring-labels-for-routes/
route labels configuration. However it's not good enaugh to explain that there are 5 different type of routes that
you can adjust. They are :

  • Che server route - configured over /spec/server/cheServerRoute/labels
  • Keycloak route - configured over /spec/server/cheServerRoute/labels
  • Plugion registry route- configured over /spec/server/cheServerRoute/labels
  • Devfile registry route- configured over /spec/server/cheServerRoute/labels
  • Workspaces routes - configured over /spec/server/customCheProperties/CHE_INFRA_OPENSHIFT_ROUTE_LABELS

As I understand you are looking for Che server route? I would really appreciate your contribution to Che docs
to avoid such misunderstandings in the future.

Hello @skabashnyuk , thanks for the reply, this part of the documentation I had already read, and I noticed that we can pass on these values.

I'm running the installation of Eclipse Che using the operator for this, so I pass the value of the label I need so that all the routes that are created already come with the label set in CHE_INFRA_OPENSHIFT_ROUTE_LABELS.

I did some more research and noticed that this functionality was only included as of version 7.19.2 am I right? (https://github.com/eclipse/che-operator/commit/37e6a9d18f03d9f79a59a60ac4f389b36b2e8502)

Because I'm using the operator for this, does he use the functions to perform these actions or does he perform it in another way?

@tolusha can you assist here https://github.com/eclipse/che/issues/18277#issuecomment-725377318 ?

Hello everyone, I managed to make the necessary settings to configure the label on the route, but it was in a way that I did not find in the operator's documentation, below is an example of how I managed to configure the labels:

spec:
  server:
    cheImageTag: ''
    cheFlavor: codeready
    devfileRegistryImage: ''
    pluginRegistryImage: ''
    tlsSupport: false
    selfSignedCert: false
    cheServerRoute: {labels: "foo=bar"}
    pluginRegistryRoute: {labels: "foo=bar"}
    devfileRegistryRoute: {labels: "foo=bar"}
    customCheProperties:  
      CHE_INFRA_OPENSHIFT_ROUTE_LABELS: foo=bar
...
auth:
    openShiftoAuth: true
    identityProviderImage: ''
    externalIdentityProvider: true
    identityProviderURL: ''
    identityProviderRealm: ''
    identityProviderClientId: ''
    identityProviderRoute: {labels: "foo=bar"}

the parameters:

    cheServerRoute: {labels: "foo=bar"}
    pluginRegistryRoute: {labels: "foo=bar"}
    devfileRegistryRoute: {labels: "foo=bar"}
    identityProviderRoute: {labels: "foo=bar"}

must be configured individually, as they cannot get the route label otherwise in my tests.

in addition to these parameters, we must also pass the

customCheProperties:
  CHE_INFRA_OPENSHIFT_ROUTE_LABELS: foo=bar

this is only used by the workspaces and I was unable to pass the label to the workspaces of another form.

With that I see that we can end the issue only with the opening of an update in the documentation. Thank you for your time and support.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

JamesDrummond picture JamesDrummond  ·  3Comments

sudheerherle picture sudheerherle  ·  3Comments

skabashnyuk picture skabashnyuk  ·  3Comments

l0rd picture l0rd  ·  3Comments

amisevsk picture amisevsk  ·  3Comments