Add odo deploy command for initial transition from inner to outer loop

[bbrowning]

/kind feature

Which functionality do you think we should add?

Today odo helps a developer with their inner loop workflow. Once the developer is ready to deploy that application, they need to go outside of odo to make that happen. I propose odo have an odo deploy command to allow an initial transition from inner loop to outer loop.

The result of an odo deploy command should be the component gets deployed to the cluster in a configuration suitable to receive production traffic.

Why is this needed?

This is meant primarily for new user experience, demos, and such as a developer learns how to deploy applications to the cluster. Best practice for real production usage would still be integration with pipelines (#1238) or integration with gitops workflows (#2617). There's a gap between odo push for in-cluster inner loop and pipelines or gitops workflows that this intends to fill.

How should it be added?

As a strawman proposal, I'd suggest bringing this in following the recent devfile support by having a convention for metadata in the devfile that odo can understand to deploy an application. This would allow devfile-aware pipelines to reuse that same devfile metadata to do the actual deployment at the output of those pipelines.

What the exact metadata in the devfile should look like needs to be decided. I believe the existing devfile 2.0 spec covers the need here, but we'll need to verify that.

User stories

• Support image component and deploy devfile command / initial odo deploy implementation #5109
• use of existing Dockerfile #5110

[sspeiche]

This is the "same" related to this discussion #1229

[girishramnani]

We are planning a proposal issue which would break this epic down #2703

[lance]

In addition to pipelines, I would like to see another devfile command supported by odo. Currently, if I understand correctly, odo supports two commands in the devfile: devBuild and devRun. Could there be a supported command that will deploy your image without the supervisor and possibly using a different image component?

[kadel]

Could there be a supported command that will deploy your image without the supervisor and possibly using a different image component?

Yes, this is what the deploy command should do.
"deployed to the cluster in a configuration suitable to receive production traffic." means that the supervisor won't be present and different image can be optionally used (for example this image should be completely stripped form any development tools, and should be as small as possible).

Not sure how we exactly we will achieve this but defining another command like prodRun or prodBuild could be one way of doing this.

[lance]

@kadel that sounds good - but it does raise another question...

If I want to deploy a stripped down image for production, there needs to be a command to build that image - e.g. prodBuild. I wonder if there's a better way, so that commands aren't quite as explicit, but rather are codified as a "build" command or a "run" command more generically with some metadata that specifies the environment. Kind of spitballing here, but it seems like just adding another special command name could lead down a path that's perhaps not ideal. What happens when a customer has 3 environments they want to build for/deploy to - dev, stage, prod? Do we then add stageBuild and stageRun as well?

[arthurdm]

+1 for having a build command that takes in a flag or metadata that maps to a different Dockerfile (or artifact to build the image).

[openshift-bot]

Issues go stale after 90d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle stale

[openshift-bot]

Stale issues rot after 30d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle rotten
/remove-lifecycle stale

[kadel]

/remove-lifecycle rotten /lifecycle frozen

…

On Sun, 15 Nov 2020 at 21:31, OpenShift Bot ***@***.***> wrote: Stale issues rot after 30d of inactivity. Mark the issue as fresh by commenting /remove-lifecycle rotten. Rotten issues close after an additional 30d of inactivity. Exclude this issue from closing by commenting /lifecycle frozen. If this issue is safe to close now please do so with /close. /lifecycle rotten /remove-lifecycle stale — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2756 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAN65SYLRANAHHULFTCUATSQA3BLANCNFSM4LTR6LYQ> .

[serenamarie125]

Moved out to 2.2 milestone due to dependencies on devfile 2.2

[dharmit]

The devfile library doesn't have outer loop support yet. Ideally, this should be sorted at devfile library end first and then implemented in odo.

[kadel]

The devfile library doesn't have outer loop support yet. Ideally, this should be sorted at devfile library end first and then implemented in odo.

It does now (https://github.com/devfile/library/releases/tag/v1.2.0). We can start working on this

Created user story to cover initial odo deploy work #5109