Selection of Kubernetes components to apply during odo push/deploy

[feloy]

/kind bug

In this page (point 4.) , it is specified that the Kubernetes components that are not associated to an Apply command will be applied at startup.

On odo implementation, that means that these non-associated Kubernetes components will be applied when running odo push.

On the other hand, during odo deploy, the Kubernetes components applied will be the ones explicitely associated with the deploy command.

This difference of selection of Kubernetes components for the commands odo push (indirect/implicit selection) and odo deploy (direct/explicit selection) can be confusing for user and difficult to reason about.

Which area this bug is related to?

/area api
/area library

[scottkurz]

I agree and in #517 suggested a new property like 'autoBuild' or 'autoDeploy' that could be added to image and kubernetes components rather than having the devfile tool reason based on the commands present. (There's quite a bit of extra noise in that issue though, sorry).

Looking ahead a bit... I guess the existing proposal more aligns with 'autoBuild' / 'autoDeploy' defaulting to "true", so 'odo' still has a bit of a challenge if it would prefer the default to be false.

Still I think this is less verbose, and it's less to conceptually understand. If the command is nothing more than "go look at the component definition" then why do we even have to bother having a command? This type of apply command just seems so different than the build/run/debug/test commands where they happen within the component container. Maybe I just don't get 'apply' commands?

[yangcao77]

@feloy Can you explain what is causing the confusion?
The behavior is not only for Kubernetes components, for containers/openshift components, it should behaves the same. It has been stated in the api reference doc for apply commands:
https://devfile.io/docs/devfile/2.1.0/user-guide/api-reference.html

When no apply command exist for a given component, it is assumed the component will be applied at devworkspace start by default.

(It mentions devworkspace, but should be the behavior for all tools)

And odo deploy is for outer-loop scanerio, and it is expected to be a composite command. Usually a command to build the image, and an apply command for kubernetes component. In this case, there is an apply command associates with the kubernetes component, and it won't be applied until deploy command has been triggered.

[feloy]

@yangcao77 I agree that the rule is simple and documented, but can be difficult to apply for a (human) user.

As an example:
When looking at a devfile to know which Kubernetes components will be deployed during an odo push, the user first needs to check, for each Kubernetes component, if it is referenced from a command. If you get a devfile with lots of Kubernetes components dedicated to odo deploy, that will be a lot of components to check, and error prone.

Moreover, odo push is one of the first commands used with odo, before odo deploy. For a new comer, it will be necessary to know and understand odo deploy before to understand correctly how works odo push.

[yangcao77]

@feloy If we take out odo deploy from consideration for a second.
Any container components that user defines in devfile generally, for example those in registry: https://github.com/devfile/registry/blob/04f6f78eaf101fdf72efa6fc71ff7531a2c552aa/stacks/nodejs/devfile.yaml#L17-L25, is the container users want tools to bring up during startup, odo push in Odo's case. I will only create a separate apply command for it, if I want to manually start it.
Currently when Odo calls generator from library to get all containers that needs to bring up during odo push, the generator filter out preStart and postStop containers, because they have an apply command associated with it.

Similarly, as a user, I define a Kubernetes component which I want all resources defined within that will be brought up during startup. and I won't define any additional apply/deploy command unless I want to manually kick off the deployment.

If I understands currently, what you are suggesting is that for any Kubernetes components, user should use odo deploy to apply it to the cluster. And this will force user to do extra actions (define apply & deploy commands, manually kick off the deployment) if their initial purpose and exception is just to deploy on startup. And this also brings inconsistent behavior against other components, like container components; which I can see brings more confusion.

[feloy]

If I understands currently, what you are suggesting is that for any Kubernetes components, user should use odo deploy to apply it to the cluster. And this will force user to do extra actions (define apply & deploy commands, manually kick off the deployment) if their initial purpose and exception is just to deploy on startup. And this also brings inconsistent behavior against other components, like container components; which I can see brings more confusion.

@yangcao77 no, that is not what I'm suggesting. My main concern is that when you have this devfile (https://gist.github.com/feloy/3260e57f38d2eaa5519da669ea4d34d2) it is not trivial to see for a user that none of the two Kubernetes components will be deployed during odo push, because it is not trivial to understand and see they are related to Apply components. With some experience, users will understand, but that can be very frustrating for a new user of odo who starts looking at the devfile content.

[kadel]

If I understands currently, what you are suggesting is that for any Kubernetes components, user should use odo deploy to apply it to the cluster. And this will force user to do extra actions (define apply & deploy commands, manually kick off the deployment) if their initial purpose and exception is just to deploy on startup. And this also brings inconsistent behavior against other components, like container components; which I can see brings more confusion.

@yangcao77 no, that is not what I'm suggesting. My main concern is that when you have this devfile (https://gist.github.com/feloy/3260e57f38d2eaa5519da669ea4d34d2) it is not trivial to see for a user that none of the two Kubernetes components will be deployed during odo push, because it is not trivial to understand and see they are related to Apply components. With some experience, users will understand, but that can be very frustrating for a new user of odo who starts looking at the devfile content.

I would like to add that this is not related to just odo. You can replace odo push with Che Workspace startup in @feloy's sentence.
This is not issue about tooling but about Devfile getting to the point where it can't be easily understand by humans. :-/

[elsony]

Introduce deployByDefault (default is false) on kubernetes component and autoBuild (default is false) on image component. Need to figure out if we need the same auto start behaviour for container and volume components.