Canvas installation on alternative namespace

[getdineshkumarg]

Team,

  Canvas installation on alternative namespace runs into issue. 

Please find below the issue description.

Objective: In our Ericsson environment, we have Canvas and Component installed with version "v1beta2" on the K8 cluster, and on the same cluster we are trying to install the Canvas and Component with version "v1beta3.

Steps Followed: 1) helm repo add oda-canvas https://tmforum-oda.github.io/oda-canvas 2)helm repo update 3)helm template canvas-beta3 oda-canvas/canvas-oda -n canvas-beta3 --create-namespace --set canvas-namespaces.componentNamespace=components-beta3 --set controller.deployment.monitoredNamespaces=components-beta3 Note: Trying to update the namespace of the canvas as "canvas-beta3" and namespace of the component as "components-beta3" 4)helm install canvas-beta3 oda-canvas/canvas-oda -n canvas-beta3 --create-namespace --set canvas-namespaces.componentNamespace=components-beta3 --set controller.deployment.monitoredNamespaces=components-beta3 5) For the step4, we got into an issue Error: INSTALLATION FAILED: rendered manifests contain a resource that already exists. Unable to continue with install: CustomResourceDefinition "clusterissuers.cert-man ager.io" in namespace "" exists and cannot be imported into the current release: invalid ownership metadata; annotation validation error: key "meta.helm.sh/release-name" must equal "canvas-beta3": current value is "canvas"; annotation validation error: key "meta.helm.sh/release-namespace" must equal "canvas-beta3": current value is "can vas" 6) It was failing because of the canvas namespace hardcoded on this file. Path: oda-canvas\charts\cert-manager-init\Values.yaml

[brian-burton]

Thanks @getdineshkumarg ,

I've had a look through the code and in addition to your description above there are some more considerations:

1. I've raised support for multiple canvas and component namespaces on a single cluster as an issue to create a formal design decision. We've tried not to prevent use of multiple namespaces, but we've also not actually designed it in properly so it looks like it's about 95% there.
2. There are two places where controllers don't support multiple canvas namespaces, here and here, so we'll also add those to this issue to fix.
3. We also need a BDD and TDD test to confirm that having multiple canvas and components namespaces work. We'll add those tests as part of fixing this issue.

[getdineshkumarg]

Hello @brian-burton /@LesterThomas, Please do let us know if you have a further update on this ticket.

[ferenc-hechler]

In our Ericsson environment, we have Canvas and Component installed with version "v1beta2" on the K8 cluster, and on the same cluster we are trying to install the Canvas and Component with version "v1beta3.

I see some problems, especially to have CustomResources with two different default versions. I am not sure, if it really is possible to do this, because the CompCRDWebHook will always bring all Custom Resources into the same version.

[brian-burton]

Perhaps this needs us to look at the CRD schema again - it might be that we can associate resources against an instance of a canvas installation in the CRD.

You are correct that different default versions could cause challenges if the versions are wildly different, but I would suggest that if someone is having to run a "legacy" canvas, then we can reasonably recommend not hosting them on the same Kubernetes cluster because they've probably got other dependencies outside the canvas itself that we can't resolve.

[ferenc-hechler]

Making the Component Namespace configurable or more flexible is a valid request.

But supporting to run two canvases in parallel inside one Kubernetes Cluster in different namespaces will not be possible. Mostly the restriction is based on cluster scope resources which are claimed from the canvas.

Running two identical canvases might be somehow possible but useless, because there is no difference to having one canvas. Running two different versions will not be possible.

If the issue is, to run multiple canvases in one Kubernetes cluster, we could work on making the Canvas runnable inside a vCluster.

https://github.com/loft-sh/vcluster

At DT we tried this and it mostly worked, with one exception. The Istio deployment. Istio is not so easy to run inside a vCluster, because it uses Daemonsets, which are not supported. It is possible to run Istio inside a vCluster but special version of Istio is needed and the Host-System needs to support this.

We could try to get the reference implementatio running inside a vCluster. Then multiple Clusters can be deployed into one Kubernetes Cluster and are additionally more isolated.