Support Kubernetes Devfile component

[girishramnani]

/kind feature

service operations should occur on odo push. we need to store the service information in the Component as a CR in the devfile.

[kadel]

In order for this to work, we first need to add support for kubernetes components.

Devfile can specify kubernetes component like this:

components:
  - name: my-mongo
    kubernetes:
      inlined: >
        apiVersion: v1
        kind: Pod
        metadata:
          name: nginx
          labels:
            name: nginx
        spec:
          containers:
          - name: nginx
            image: nginx
            ports:
            - containerPort: 80

or

components:
  - name: my-mongo
    kubernetes:
      inlined: >
        apiVersion: mongodb.com/v1
        kind: MongoDB
        metadata:
          name: my-replica-set
          namespace: tkral-test
        spec:
          credentials: my-credentials
          members: 3
          opsManager:
            configMapRef:
              name: my-project
          type: ReplicaSet
          version: 4.4.0-ent
          persistent: true
        status:
          phase: Running
          type: ReplicaSet

The idea is that the content of a kubernetes component can be any Kubernetes resource (core one, or custom resource).

odo push needs to recognize kubernetes components and apply them to the cluster.

[dharmit]

In order for this to work, we first need to add support for kubernetes components.
odo push needs to recognize kubernetes components and apply them to the cluster.

I think we can take a small step first by adding the definition of the resource to the devfile. In the next step, we can ensure that odo push does something of it. I think there will be a lot of discussion for that. For example, I have asked some questions in #4160 (comment). I also remember we were playing with the idea of breaking down odo push so that individual pieces are pushed: a component, the URLs, service, etc.

Devfile can specify kubernetes component like this:
The idea is that the content of a kubernetes component can be any Kubernetes resource (core one, or custom resource).

+1 to the examples. Makes sense.

[kadel]

I think we can take a small step first by adding the definition of the resource to the devfile. In the next step, we can ensure that odo push does something of it.

I'm actually proposing doing it the other way around. The first step needs to be to ensure that odo push can correctly interpret kubernetes component.

I think there will be a lot of discussion for that. For example, I have asked some questions in #4160 (comment).

This issue is about odo push the #4160 is about odo create

[dharmit]

I'm actually proposing doing it the other way around. The first step needs to be to ensure that odo push can correctly interpret kubernetes component.

My concern on doing that first is that we're just getting started with refactoring and a lot of things are expected to change. I don't intend to wait till refactoring is over but, at the moment, there's almost no clarity on how odo push code is going to change.

[kadel]

My concern on doing that first is that we're just getting started with refactoring and a lot of things are expected to change. I don't intend to wait till refactoring is over but, at the moment, there's almost no clarity on how odo push code is going to change.

We will first need to address changes in devfile/parser or in parser in odo as there is no support for kubernetes component.
Before we get into writing the actual odo push logic the refactoring will probably be done, or at least it will be clear how much changes will be needed there.

[dharmit]

We're waiting on some movement on devfile/api#216 for this to be able to move further. The code for this needs to go into library and not in odo.

[openshift-bot]

Issues go stale after 90d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
Exclude this issue from closing by commenting /lifecycle frozen.

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

/lifecycle stale

[dharmit]

/lifecycle frozen

[scottkurz]

@kadel @dharmit - I'm noticing the recent updates like #4656 to support kubernetes-typed components focus on support operator-backed services.

I'm curious if a use case like Tomas's naked Mongo Pod described here: #4159 (comment)
is still considered a valid use case.

On the one-hand, I can see how using an operator would be more powerful for something like a database.

But I'm interested in where we're headed with this case. Is the inlined kubernetes component going to allow a devfile author to insert any yaml that will be kubectl apply(d)? Or is odo always going to carefully parse and validate it against the resources in the cluster?

That is, even if this isn't the most useful way to create a Mongo DB I'm curious if the vision is to allow any yaml to be applied via an inline component?

[dharmit]

@scottkurz I'll try to answer that but will rely on @kadel to validate my response.

At a high level, odo is currently not focussing on the users who would modify devfile by hands. That is, if someone's editing it manually and not interacting with it via odo, there's no guarantee that things would work.

Having said that, we do understand that for architects or Devfile authors like you, Andy and others, modifying Devfile by hands could be a "norm".

What odo does in the code is use the dynamic client to create the Kubernetes inlined component: https://github.com/openshift/odo/blob/c0be940e1df15ca1ebf410de962932b327d9d5a7/pkg/service/service.go#L856-L867

Theoretically, you could very well create a Pod or any other Kubernetes resources of your choice using this. We haven't tested it, however, because such use cases are currently not a priority for odo.

@kadel correct me if I am wrong.

[kadel]

At a high level, odo is currently not focussing on the users who would modify devfile by hands. That is, if someone's editing it manually and not interacting with it via odo, there's no guarantee that things would work.

Not really. Odo uses Devfile v2. And as such, it needs to be able to correctly interpret any valid devfile.
It is perfectly valid odo use-case to write devfiles "by-hand" and use just odo push.
The thing that we are not focusing on and it will always be out of the scope for odo is providing a command to modify every aspect and field in devfile. Odo devfile editing capabilities will be always limited to just the most common use cases. Fot the rest usrs will have to edit devices directly.

Theoretically, you could very well create a Pod or any other Kubernetes resources of your choice using this. We haven't tested it, however, because such use cases are currently not a priority for odo.

@kadel correct me if I am wrong.

If that Devfile has Pod or any other k8s resource as a Kubernetes component odo needs to be able to interpret it.

[scottkurz]

OK.. I opened #4685 to follow-up on this use case.

Let me just note again I'm not saying this is particularly important to the set of top Open Liberty use cases. I just view it as a test case understanding the full devfile vision.

[dharmit]

Original request in the issue description is implemented.

/close

[openshift-ci]

@dharmit: Closing this issue.

In response to this:

Original request in the issue description is implemented.

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.