expose component status

[benoitf]

Currently with dev-workspace I can create a workspace and I've access to:

• devworkspace object that has spec.template with devfile content listing components/commands that I want
• workspaceRoutings object saying which endpoint are exposed.

But where to grab component status ?
(with che server it was within workspace.runtime object)

It seems for now I've to look at pod object and compare some container name with component/name but it looks very fragile.

[benoitf]

For example on pods we have
status.containerStatuses

so it would be a good fit to have status.componentStatuses

[amisevsk]

It's worth discussing what we actually mean by "component status" -- if they deployment is up, the components are all green. If one component fails (e.g. is OOMKIlled), the whole deployment fails and all components are red.

Is there ever a possibility to have only one component not working, in a way that the DevWorkspace Operator will be aware of?

[amisevsk]

Related to this issue: one of the options in devfile/api#370 would make this easier (but I'm still not sure how useful this information is).

[sleshchenko]

Closing assuming that #318 provides endpoints URL and all commands, components as flattened devfile.
@benoitf please create another issue if it's not enough, or you have strong need to have that info under DevWorkspace CR status

[benoitf]

well status should still expose stuff (not a separate or mounted file)

[davidfestal]

you have strong need to have that info under DevWorkspace CR status

Seems to me that having this info in the Status would allow other components, that do not run inside Workspace POD containers, to have access to the result of the flattening (== the complete and annotated structure of the resulting workspace). Just think of the Dashboard trying to graphically represent the various components of a Workspace.
Storing it in the status would also allow keeping it even when the workspace is stopped (the fact that the workspace is stopped doesn't really impacts the result of the flattening).

TBH it seems to me that not putting it in the status is just doing more work for a less useful result.

Are there real problems raised by adding the annotated flattened devworkspace in the status, apart from having a CR that is longer ?
It is already the case because of the last-applied metadata added by kubectl for example.

[amisevsk]

I would say putting a flattened devworkspace in the status is a real problem. I already had to figure out a bash alias to strip out managedFields when I'm looking at resources.

The flattened workspace can (and will be if theia is involved) 3-4 times longer than the spec. That's too much info for a status IMO. To add here, if you apply a flattened DevWorkspace, the status will reproduce the original workspace in its entirety, with no changes except for a few annotations.

[sleshchenko]

I believe we agreed we are not going to expand devworkspace status with much details. Instead we may add link to flattened devfile from devworkspace status. But we agreed we won't add it until we see the necessity.