Use new devworkspace-controller templates and add cert-manager v1 apiVersion

[flacatus]

Signed-off-by: Flavius Lacatusu [email protected]

What does this PR do?

This PR replace old templates of devworkspace-controller with new one after migration to operatorsdk1. Also in this PR change cert-manager api version from v1alpha2 to v1(stable)

Reff issue: eclipse-che/che#18962
Reff issue: eclipse-che/che#18842

Screenshot/screencast of this PR

What issues does this PR fix or reference?

How to test this PR?

PR Checklist

As the author of this Pull Request I made sure that:

• The Eclipse Contributor Agreement is valid
• Code produced is complete
• Code builds without errors
• Tests are covering the bugfix
• The repository devfile is up to date and works
• Sections What issues does this PR fix or reference and How to test this PR completed
• Relevant user documentation updated
• Relevant contributing documentation updated
• CI/CD changes implemented, documented and communicated

Reviewers

Reviewers, please comment how you tested the PR when approving it.

[flacatus]

Helm tests will fail. Need to change api version of cert-manager here: https://github.com/eclipse/che/blob/master/deploy/cert-manager/che-cluster-issuer.yml

[flacatus]

I was able to deploy devworkspace-controller in Ocp 4.X and also in minikube. I've create workspaces in both platform using samples: https://github.com/devfile/devworkspace-operator/tree/master/samples

[metlos]

Does this mean that we will need to change chectl whenever devworkspace-operator decides to add or remove a file from the deployment? Wouldn't it be better to just generically apply all the files in the deploy/deployment/${PLATFORM}/objects ?

[flacatus]

Does this mean that we will need to change chectl whenever devworkspace-operator decides to add or remove a file from the deployment? Wouldn't it be better to just generically apply all the files in the deploy/deployment/${PLATFORM}/objects ?

@metlos Honestly I preffer to add one by one the objects because for example if one of the objects exist in cluster whole installation will fail.

Anyway if you remove/add objects in devworkspace you need to change chect server:delete.

[metlos]

I was trying to override the namespace by running:

bin/run server:deploy -p minikube --workspace-engine=dev-workspace --dev-workspace-controller-namespace=dw-ctrl

and got this error:

Create ServiceAccount devworkspace-controller-serviceaccount in namespace dw-ctrl
      → the namespace of the provided object does not match the namespace sent on the request

[AndrienkoAleksandr]

devworkspaceConfigMap -> devWorkspaceConfigMap

[sleshchenko]

at milestone 1 we must guarantee that DevWorkspace Engine it not enabled on the cluster where Web Terminal is enabled.

So, apart from checking if mutating webhooks cfg exist, it would be cool to check the configured namespace inside. It's the example of Mutating Webhooks created by Web Terminal

apiVersion: admissionregistration.k8s.io/v1
kind: MutatingWebhookConfiguration
metadata:
  labels:
    app.kubernetes.io/name: devworkspace-webhook-server
    app.kubernetes.io/part-of: devworkspace-operator
  name: controller.devfile.io
webhooks:
- admissionReviewVersions:
  - v1beta1
  clientConfig:
    ...
    service:
      name: devworkspace-webhookserver
      namespace: openshift-operators
      path: /mutate
      port: 443
  ...
  name: mutate.devworkspace-controller.svc
  namespaceSelector: {}
  objectSelector: {}
  reinvocationPolicy: Never
  rules:
  ...
- admissionReviewVersions:
  - v1beta1
  clientConfig:
    service:
      name: devworkspace-webhookserver
      namespace: openshift-operators
      path: /mutate
      port: 443
  ...

Pay attention on namespace: openshift-operators.

Also, about Web Terminal presence can tell Subscription:

apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  labels:
    operators.coreos.com/web-terminal.openshift-operators: ""
  name: web-terminal
  namespace: openshift-operators
spec:
  channel: alpha
  installPlanApproval: Automatic
  name: web-terminal
  source: redhat-operators
  sourceNamespace: openshift-marketplace
  startingCSV: web-terminal.v1.1.0

But in general it's going to break DevWorkspaces, if there is another devworkspace controller deployed.

So, the smart logic on Chectl side could be (at least in my opinion ;) ):

1. There is no need to provide an ability to override devworkspace operator namespace, so let's just remove it.
2. Then chectl checks and fails if Web Terminal installed (Subscription exists).
3. Then chectl checks if mutatingwebhooks exists, and their namespace is different than devworkspace-operator - checlt fails and tells that WebTerminal is not uninstalled properly (if namespace if openshift-operators) or another devworkspace controller is already deployed in namespace X (it can be evaluated on chectl with webhooks object).

[mmorhun]

What if a resource with v1alpha1 or v1alpha2 appear? What if it then turned into v1beta2?
According to the current strategy, we'll have to add several methods per version.
To me it is better to have version as second parameter (maybe default to v1)

[tolusha]

Agree. But let's keep as is for now.

[mmorhun]

ok

[openshift-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: flacatus, mmorhun, tolusha
To complete the pull request process, please assign after the PR has been reviewed.
You can assign the PR to them by writing /assign in a comment when ready.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[tolusha]

/test v7-chectl-e2e-operator-installer

[tolusha]

/test v6-chectl-e2e-olm-installer