Support CustomResourceDefinition for Kubernetes component in Devfiles

[apupier]

Is your enhancement related to a problem? Please describe.

I would like to provide a Camel K instance in the workspace through the devfile. Unfortunately, it requires CustomResourceDefinition which is not supported.

If for instance you add this component in the devfile:

 - type: kubernetes
    alias: camel-k
    reference: >-
      https://raw.githubusercontent.com/apache/camel-k/master/deploy/crd-integration-platform.yaml

there is this error:
Error: Failed to start the workspace: "Found unknown object type in recipe -- name: 'integrationplatforms.camel.apache.org', kind: 'CustomResourceDefinition'

Based on this code, the CustomResourceDefinition is not handled:

https://github.com/eclipse/che/blob/1907b041c137dd45f8b9ae20a4a4ba3231438054/infrastructures/kubernetes/src/main/java/org/eclipse/che/workspace/infrastructure/kubernetes/environment/KubernetesEnvironmentFactory.java#L107-L127

Describe the solution you'd like

Be able to reference CustomResourceDefinition yaml file and have it deployed.

Describe alternatives you've considered

alternative is to ask user to deploy by hand.

Additional context

required to go to last iteration of Camel K stack in Che #14831

[tsmaeder]

Not sure about the prio, but handling crd's sounds important.

[sleshchenko]

I'm not sure but I assume that only cluster admin is able to register CRD on the cluster, if it's true - then we are not able to allow CRD in Devfile (CR yes, but not CRDs) since typically Che User may have admin rights for some k8s namespaces but not cluster-admin rights.

@davidfestal Could you share your knowledge in this area, can we somehow create CRD with namespace admin rights (not cluster rights)?

[davidfestal]

I think we should precise the real use-case for this need.
A CRD is a clusterwide resource as @sleshchenko said. And typically it would be installed either with cluster admin rights, or through OLM that would install it from the CSV + OLM package.

I don't think it is expected to be installed by a runtime component such as a workspace.

@apupier Can you precise a bit your use-case ?

[davidfestal]

OTOH if you would like to add a Camel custom resource of kind IntegrationPlatform, that's another story, and could probably be allowed in the Che server. But that would still require that the IntegrationPlatform is known in the cluster. So using such a worspace would make sense only if previously you installed the CamelK operator from the OperatorHub.

[apupier]

@apupier Can you precise a bit your use-case ?

my use case:

• create a workspace from a devfile
• have a Camel K runtime available from this workspace for development purpose.

I created a brief for the higher level use case: https://docs.google.com/document/d/1EUefd78aJLD8FlQlyvv3cszRzr5AR-ymJ6JfsCOjd1s/edit?usp=sharing

[davidfestal]

So I assume it's more about creating a Custom Resource than creating a Custom Resource Definition.

[apupier]

So I assume it's more about creating a Custom Resource than creating a Custom Resource Definition.

I don't think so.
From what I understand, on th setup of Camel K instance, you need to install several Custom Resource Definition.
The custom resource are created when we are deploying a Camel K integration, which means when I'm in my workspace and developing an integration.

In the devfile, what we want is to provide the Camel K instance so that users can deploy a Camel K integration during development inside the workspace.

[davidfestal]

From what I understand, on th setup of Camel K instance, you need to install several Custom Resource Definition.

Could you provide a concrete example ?

[apupier]

From what I understand, on th setup of Camel K instance, you need to install several Custom Resource Definition.

Could you provide a concrete example ?

not sure which example you are looking for, but let's try :-)

to install Camel K, you need to call the Kamel cli "kamel install". https://github.com/apache/camel-k#installation
it ends up with several custom resource definitions created:

• builds
• camelcatalogs
• integrationkits
• integrationplatforms
• integrations
  

[che-bot]

Issues go stale after 180 days of inactivity. lifecycle/stale issues rot after an additional 7 days of inactivity and eventually close.

Mark the issue as fresh with /remove-lifecycle stale in a new comment.

If this issue is safe to close now please do so.

Moderators: Add lifecycle/frozen label to avoid stale mode.