odo should show a list and state of resources created by odo deploy

[dharmit]

/kind user-story

User Story

As a user, I want to get a list of resources created by odo deploy so that I can know:

1. What resource odo created
2. What is the state of these resources

This could be done via odo deploy list.

Acceptance Criteria

• It should show a list of resources created and their state (running/error/something else)
• Display resources defined in the devfile as "Non Deployed"
• Display resources defined in the devfile AND deployed in the cluster as "Deployed"

Links

• Related Epic (mandatory): Add odo deploy command for initial transition from inner to outer loop #2756

/kind user-story

Notes

• Originally discussed in Support image component and deploy devfile command / initial odo deploy implementation #5109 (comment).

[kadel]

1. What resource odo created
2. What is the state of these resources

This could be done via odo deploy list.

Would it make sense to use already existing command odo list to show both "innerloop" and "outerloop" resources?

[dharmit]

Would it make sense to use already existing command odo list to show both "innerloop" and "outerloop" resources?

Doable. But odo list is a shorthand for odo component list. Listing resources created by odo deploy there won't be technically correct, IMO.

[kadel]

Listing resources created by odo deploy there won't be technically correct, IMO.

I don't see it that way. Even the outer loop resources are still part of the devfile component, they are part of the same devfile

[dharmit]

I don't see it that way. Even the outer loop resources are still part of the devfile component, they are part of the same devfile

You aren't wrong, but odo deploy isn't a shorthand for odo component deploy. deploy is a separate command of its own like service, url, storage etc. which all perform operations on a devfile component and hence are also a part of the devfile component.

[kadel]

You aren't wrong, but odo deploy isn't a shorthand for odo component deploy.

It is not but it should be, odo deploy means execute what is in devfile under deploy command.

deploy is a separate command of its own like service, url, storage etc. which all perform operations on a devfile component and hence are also a part of the devfile component.

yes, service url storage all are separate commands but they perform actions on component, so why they are not under odo component but have a separate commands? The hiearchy where url, storage and service was separate made sense with s2i/localConfig implementation. With devfile it is different, and we need to start cleaning this up.

As I see it devfile = odo component. So every command that odo does is action on top of the component. It doesn't make sense to have component subcommand anymore.

Component is confusing term and even among odo developers there is confusion what component actually represents.
We know that we want to limit or ideally stop using term component (#4884).

If we would to keep using components odo deploy should be shorthand odo component deploy the only reason why it is not implemented like this is that we don't want to keep adding stuff on top of the components.

[kadel]

As I see it devfile = odo component. So every command that odo does is action on top of the component. It doesn't make sense to have component subcommand anymore.

created #5253 to capture this and added more info why I think that the component subcommand is just harming UX

[deboer-tim]

Just stating a +1 to Tomas' comments above - I agree users would expect to see the deployed app (inner or outer) via 'odo list' (i.e. don't have separate commands), and most users wouldn't even know about 'odo component ' equivalents.

[valaparthvi]

While I think odo deploy list is intuitive, we could extend odo list to display deployed devfile-K8s-components, similar to what we did for odo delete. So,

1. odo list will list devfile components, the way it does at the moment.
2. odo list --deploy will list deployed components
   1. odo list --deploy --project myproject should print all the k8s component in the myproject.
   2. odo list --deploy should print all the k8s components deployed, and not-deployed if in the context directory.
   3. odo list --deploy --app; do we need to label the k8s components with an app key?
3. odo list --all will deploy both the type of components : This is not feasible considering both the component types have a different structure, making it an inconsistent JSON output.

[valaparthvi]

There are other questions related to output as well:

1. odo list --deploy can look like the following:

   ➜  odo list --deploy
   K8s Devfile Components:
   NAME            TYPE        STATE
   my-component    Deployment  Not Deployed
   my-service      Service     Deployed

2. odo list --deploy -o json is a toughie. But this is how I think it can be structured, considering that the important things that we need is the manifest itself, name, and state of the component. Also, to identify the devfile that a K8s component belongs to, we add an extra label component. -

type K8sComponent struct {
   metav1.TypeMeta   `json:",inline"`
   metav1.ObjectMeta `json:"metadata,omitempty"`
   Manifest          unstructured.Unstructured   `json:"spec,omitempty"`
   Status            ComponentStatus `json:"status,omitempty"`
}

// ComponentStatus is Status of components
type ComponentStatus struct {                       <----------- Existing struct
   Context        string        `json:"context,omitempty"`
   State          State         `json:"state"`
   LinkedServices []SecretMount `json:"linkedServices,omitempty"`
}


k8scomp := K8sComponent{
   TypeMeta: metav1.TypeMeta{
   	Kind:       "Component",
   	APIVersion: "odo.dev/v1alpha1",
   },
   ObjectMeta: metav1.ObjectMeta{
   	Name:      compName,     <------ Name of the K8s resource
   	Namespace: namespace,    <------- Namespace where it has been deployed, if deployed
   	Labels: map[string]string{     <-------- Labels used by the K8s component, this includes the labels from the actual manifest
   		applabels.ManagedBy: "odo",     <------- to determine that the component is managed by odo
   		component:   "devfile-name"       <------- determine the devfile that the deployed component belongs to
   		"{{extralabels}}"
   	},
   },
   Manifest: {      <----- if the K8s component in devfile is URI, read the data and add it here, else add the in-lined manifest as is.
   	"{{K8s Manifest}}"
   },
   Status: ComponentStatus{           <------- if the component is deployed or not
   	State: state,     <------- Possible values: Deployed, Not Deployed
   },
}

[valaparthvi]

Scope of the issue:

1. • Implement odo list --deploy
   1. • Human readable output
   2. • Machine output; -o json
2. • Integration tests
3. • Documentation
4. • Demo Recording

[dharmit]

@serenamarie125 @kadel are we sure to pop issues into a milestone when we are in the middle of it? I'm inclined to put this on 2.5+ instead since we never figured that we would need something like this when we first thought of odo deploy.

[kadel]

Let's NOT do odo list --deploy.
odo list should list both "inner loop" and "outer loop" by default. User should be able to know status of it's components in one command

[kadel]

To show the state we could simply modify the component state.
Let's rename STATE to PUSH STATE and add new DEPLOY STATE

Deploy state will have similar states as Push state: Deployed, Not Deployed, Uknown.

The output could look like this:

$ odo list
APP     NAME                      PROJECT     TYPE       PUSH STATE    DEPLOY STATE      MANAGED BY ODO
app     devfile-nodejs-deploy     test        nodejs     Pushed        Not Deployed      Yes

For json output we will just add deployState and keep state field as it is to keep it backward compatible.

example of `odo list -o json` output with `deployState` field

{
    "kind": "List",
    "apiVersion": "odo.dev/v1alpha1",
    "metadata": {},
    "devfileComponents": [
        {
            "kind": "Component",
            "apiVersion": "odo.dev/v1alpha1",
            "metadata": {
                "name": "devfile-nodejs-deploy",
                "namespace": "test",
                "creationTimestamp": null,
                "labels": {
                    "app": "app",
                    "app.kubernetes.io/instance": "devfile-nodejs-deploy",
                    "app.kubernetes.io/managed-by": "odo",
                    "app.kubernetes.io/managed-by-version": "v2.4.3",
                    "app.kubernetes.io/name": "",
                    "app.kubernetes.io/part-of": "app",
                    "component": "devfile-nodejs-deploy"
                },
                "annotations": {
                    "app.openshift.io/vcs-uri": "https://github.com/kadel/devfile-nodejs-deploy",
                    "deployment.kubernetes.io/revision": "1",
                    "odo.dev/project-type": "nodejs"
                }
            },
            "spec": {
                "app": "app",
                "type": "nodejs",
                "env": [
                    {
                        "name": "PROJECTS_ROOT",
                        "value": "/projects"
                    },
                    {
                        "name": "PROJECT_SOURCE",
                        "value": "/projects"
                    }
                ]
            },
            "status": {
                "state": "Pushed",
                "deployState": "Deployed"
            }
        }
    ],
    "otherComponents": []
}

Note that this needs to work even without a context folder. So if I'm not in a component folder I should still be able to run odo list --app app --project test or odo list --all-apps --project test to see all components in test project in app application (or in all applications). odo list needs to still correctly show both "push state" and "deploy state".

This will help users understand that is the current state of their components.

Details about all resources should not be in odo list output. For that, we will need to update odo describe to show all outer-loop resources.

[valaparthvi]

Considering the output mentioned in #5248 (comment), if the context is accessible, get the Deploy State of the component, else mark it as unknown.

Scope:

1. • Add Deploy state to the json output.
2. • Add to docs
3. • Add tests

[dharmit]

[ ] Add Deploy state to the json output.

Could we elaborate the difference in behaviour for the time when odo list will be executed from within a context directory and outside it?

[valaparthvi]

[ ] Add Deploy state to the json output.

Could we elaborate the difference in behaviour for the time when odo list will be executed from within a context directory and outside it?

Considering the output mentioned in #5248 (comment), if the context is accessible, get the Deploy State of the component, else mark it as unknown.

[valaparthvi]

It might be a bit premature.

• we need more feedback from the user on odo deploy
• deploy feature is not yet GA

[github-actions]

A friendly reminder that this issue had no activity for 90 days. Stale issues will be closed after an additional 30 days of inactivity.

[github-actions]

This issue was closed because it has been inactive for 30 days since being marked as stale.