Selection of Kubernetes components to apply during odo push/deploy #693

Activity

1. openshift-ci

   added

   kind/bugSomething isn't workingSomething isn't working

   area/apiEnhancement or issue related to the api/devfile specificationEnhancement or issue related to the api/devfile specification

   area/libraryCommon devfile library for interacting with devfilesCommon devfile library for interacting with devfiles

   on Nov 24, 2021
2. scottkurz commented on Nov 24, 2021

   

   scottkurz

   on Nov 24, 2021

   Last edited by scottkurz

   Contributor

   More actions

   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?
3. yangcao77

   self-assigned this

   on Nov 30, 2021
4. yangcao77 commented on Nov 30, 2021

   

   yangcao77

   on Nov 30, 2021

   Last edited by yangcao77

   Contributor

   More actions

   @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.
5. feloy commented on Dec 1, 2021

   

   feloy

   on Dec 1, 2021

   Last edited by feloy

   ContributorAuthor

   More actions

   @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.
6. yangcao77 commented on Dec 1, 2021

   

   yangcao77

   on Dec 1, 2021

   Last edited by yangcao77

   Contributor

   More actions

   @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.
7. feloy commented on Dec 3, 2021

   

   feloy

   on Dec 3, 2021

   ContributorAuthor

   More actions

   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.
8. kadel commented on Dec 3, 2021

   

   kadel

   on Dec 3, 2021

   Member

   More actions

   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. :-/
9. elsony commented on Dec 7, 2021

   

   elsony

   on Dec 7, 2021

   Last edited by elsony

   Contributor

   More actions

   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.
10. yangcao77

    added

    kind/enhancementNew feature or requestNew feature or request

    and removed

    kind/bugSomething isn't workingSomething isn't working

    on Dec 7, 2021
11. yangcao77

    closed this as completedin library#127on Jan 5, 2022
12. elsony

    added this to the 2.2 milestone on Jan 31, 2022