odo
odo copied to clipboard
odo should show a list and state of resources created by `odo deploy`
/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:
- What resource odo created
- 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): #2756
/kind user-story
Notes
- Originally discussed in https://github.com/openshift/odo/issues/5109#issuecomment-976217398.
- What resource odo created
- 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?
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.
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
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.
You aren't wrong, but
odo deploy
isn't a shorthand forodo 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 (https://github.com/openshift/odo/issues/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.
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 https://github.com/openshift/odo/issues/5253 to capture this and added more info why I think that the component
subcommand is just harming UX
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
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,
-
odo list
will list devfile components, the way it does at the moment. -
odo list --deploy
will list deployed components-
odo list --deploy --project myproject
should print all the k8s component in the myproject. -
odo list --deploy
should print all the k8s components deployed, and not-deployed if in the context directory. -
odo list --deploy --app
; do we need to label the k8s components with anapp
key?
-
- ~
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.
There are other questions related to output as well:
-
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
-
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 labelcomponent
. -
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
},
}
Scope of the issue:
-
- [ ] Implement
odo list --deploy
-
- [ ] Human readable output
-
- [ ] Machine output;
-o json
- [ ] Machine output;
- [ ] Implement
-
- [ ] Integration tests
-
- [ ] Documentation
-
- [ ] Demo Recording
@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
.
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
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.
Considering the output mentioned in https://github.com/redhat-developer/odo/issues/5248#issuecomment-1004138330, if the context is accessible, get the Deploy State
of the component, else mark it as unknown.
Scope:
-
- [ ] Add Deploy state to the json output.
-
- [ ] Add to docs
-
- [ ] Add tests
[ ] 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?
[ ] 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.
It might be a bit premature.
- we need more feedback from the user on
odo deploy
- deploy feature is not yet GA