Extend deployByDefault to other components, drop the implicit apply command rule

[l0rd]

Which area this feature is related to?

/area api
/area library
/area devworkspace

Which functionality do you think we should add?

Why is this needed? Is your feature request related to a problem?

Devfile adopters struggle to understand what components will be started when a workspace is provisioned.

Detailed description:

Understanding which components are started automatically (or builded in the case of an image) and which are not is currently complicated.

There is an implicit rule to start only components that are NOT referenced by a command of type apply. That's a hidden rule that is hard to understand and remember.

The new deployByDefault and autoBuild fields have improved the situation but only apply to kubernetes/openshift and image components respectively.

Describe the solution you'd like

Add a runOnDemand boolean field for components of type containers (false by default).

Do not rely on the apply rule anymore, but forbid the following configurations (document in the spec, raise an error in the library):

• a container with runOnDemand: false is referenced by an apply a command
• a kubernetes/openshift with deployByDefault: true is referenced by an apply command
• a image with autobuild: true is referenced by an apply command

Describe alternatives you've considered

We should add a new command of type delete that would be the complement of apply.

Related issues

#204
#693

[rajibmitra]

I would love to work on this issue. @l0rd

[viveksahu26]

Hey @l0rd , Ohh, I am bit late to know about this project. Hey, Myself vivek !! Currently a student, looking for new project to contribute. And it seems to me an interesting project. I have bit of experience of past one year in open source world. Contributed to Kyverno project. Looking forward to know more about this project. Any useful resources ??

[faze-geek]

Hi @l0rd , this is Anurag Bhat , a student looking to contribute to this project under the LFX mentorship program . I feel this project is a great entry point for me into cloud native development, after contributing to couple of GSoC orgs in the past year. I had submitted my application 3-4 days ago and believe the admission process is in progress now !
Thanks .

[kadel]

I'm not a big fan of the "apply rule" so it would be great to have something more explicit.

I'm a bit afraid of creating too many rules like "If this is enabled then you can't enable something else" it might make writing devfiles too complex as it createss too many invalid scenarios. I would avoid adding validation like this unless it creates situation that are ambiguous or completely invalid.

• a container with runOnDemand: false is referenced by an apply a command

Doing this might look weird, but essentially it is not creating an invalid scenario. You will be applying something that already exists, so it will only result in "noop".

• a kubernetes/openshift with deployByDefault: true is referenced by an apply command

Similar in as above scenario

• a image with autobuild: true is referenced by an apply command

I can actually see a valid scenario where I would want to build image with autobuild: true again. I would set autobuild: true to have it build for the first time on startup, and later I might want to apply that image component again to re-build image, when I did some changes.

name runOnDemand looks a bit weird to me, It might not be obvious what it does.

Could we maybe name this field autoStart and have the logic reversed.
By default it would be false so it would be applied only if it is referenced by command.
autoStart: true would mean that is is automatically applied on workspace start, but it could be still referenced by commands.

I will try to create a few examples to verify how it would work.

[l0rd]

@kadel setting autoStart: false by default would add some syntax sugar AND change the semantic of existing Devfile that do not have an autoStart field. Although this is an interesting topic (are devfile containers started more often at startup or after running a command?) I would like to keep this issue about a new more explicit syntax without hanging the behavior of existing Devfiles.

I am ok to call it autoStart and it's a good idea to allow a component to haveautoStart: true and to be referenced by an apply command for now. We can decide later, based on feedback, if we need to avoid it or not.

[l0rd]

@rajibmitra is going to work on this issue as part of the LXF mentorship program.

[kadel]

@kadel setting autoStart: false by default would add some syntax sugar AND change the semantic of existing Devfile that do not have an autoStart field. Although this is an interesting topic (are devfile containers started more often at startup or after running a command?) I would like to keep this issue about a new more explicit syntax without hanging the behavior of existing Devfiles.

I got a little bit carried away 😇 . You are right this might not be a good idea right now as it would be incompatible with current Devfile behaviors, but it would simplify a lot of things :-)

I am ok to call it autoStart and it's a good idea to allow a component to haveautoStart: true and to be referenced by an apply command for now. We can decide later, based on feedback, if we need to avoid it or not.

I'm afraid that if we want to keep default behaviors as autoStart: true we will need a different name for this field :-/
Some time back we agreed that we should try to keep default values for boolean fields false, as it makes it much easier to deal with them.
This means that we won't be able to use autoStart. We will need a different name that will have inverted logic (like the originally proposed runOnDemand).
runOnDemand sounds a little bit weird to me, but currently, I can't think of a better name for this.

[l0rd]

During the Devfile Cabal of the 20th of June we have discussed a couple of proposal as mentioned in another issue to use the field deployStrategy instead of runOnDemand:

Proposal 1:
DeployStrategy: AtStartupInMainPod, AtStartupInSeparatePod, StartWithCommandInMainPod, StartWithCommandInSeparatePod

Proposal 2:
DeployStrategy: AtStartup, StartWithCommand
DedicatedPod: true/false

@kadel Action: Come up with a proposal and examples on how these fields will behave.