Few comments on the devfile spec

[dharmit]

/area api

The problem, as I see it

I'm a developer working on a team that's creating a tooling on top of devfile. I don't consider myself to be an expert at devfile, rather far from it. But I find a few things unusual in the devfile, which I felt like bringing up:

1. A command has id attribute, but a component has a name attribute. Wouldn't naming these consistently make more sense from a user's perspective?
2. AFAIU, deployByDefault should be used to start the component when the tooling is spinning up resources for inner loop mode. To start the same component in outer loop mode, we rely on it being a part of the composite command with group-kind deploy. Isn't that separate ways to segregate the same item between inner and outer loops?
3. Also, why are we using a boolean with "deploy" in its name when it's meant to indicate that such a component should be start in the inner loop? I know it's not a crime to do so, but it's unintuitive, IMO.
4. For autoBuild, my understanding is that a command with that boolean set to true will trigger docker build and then the resulting image is used to start the Deployment in inner loop mode. But to use it in outer loop mode, one must add the same command to composite commands for the command group-kind deploy. So, essentially, we require only one boolean for inner loop mode, and explicitly putting it in composite commands for outer loop mode. I feel there could be more consistent way of doing things for the two modes.
5. For outer loop mode, we only consider things which are marked with group-kind deploy. And everything that's not marked as group-kind deploy is implicitly a part of inner loop. As a result, reusing things in both modes requires additional flags like autoBuild, deployByDefault, etc., right? Is that by design?
6. This one's probably stretching things too far, but why does devfile have separate ways to do things for the two modes it supports, instead of having a straightforward way to do it in both modes? What if there was a need to add support for a third mode in devfile at some point?

Describe the solution you'd like

Simpler and consistent devfile spec. Explicit rather than implicit approach.

[elsony]

Based on community call discussion:

1. No immediate need to change yet. We can wait until the next major version update to change component name to id. And we may also want to introduce a display name.

Other changes:

1. Update metadata description to explain the onboarding usage in a registry

[dharmit]

I didn't completely understand the solution/scenario that we discussed to make spec more declarative and the possible gains/losses from user perspective.

IMO (and as @feloy explained on the call), deploy (outer loop) related things are explicit (does that also mean declarative?) in the devfile, whereas inner loop is more implicit and assumed in nature. Did we propose to make inner loop more declarative or something else?

@gorkem I'm asking because I found your question about possible gains/loss very relevant.

[elsony]

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.

[l0rd]

I have mentioned the proposals above in the dedicated issue. And I would prefer if we could continue the discussion on this new field (deployStrategy) there rather than here.

[Jdubrick]

Closing issue. As stated in the comment above a dedicated issue for these proposals was opened.