Proposal for odo deploy

[neeraj-laad]

What type of PR is this?
/kind design
[skip ci]

What does does this PR do / why we need it:
This is a design proposal for adding limited outer-loop capabilities to odo. Additional information non this is captured here: #3300

Which issue(s) this PR fixes:
Relates to: #3300

How to test changes / Special notes to the reviewer:
This is a design proposal, once the design is agreed upon we can submit a PR for the implementation. We might start making some progress on a prototype based on this proposal and then adjust as the design evolves.

[openshift-ci-robot]

Hi @neeraj-laad. Thanks for your PR.

I'm waiting for a openshift member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[codecov]

Codecov Report

Merging #3368 into master will increase coverage by 0.11%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master    #3368      +/-   ##
==========================================
+ Coverage   45.95%   46.07%   +0.11%     
==========================================
  Files         111      111              
  Lines       11034    11072      +38     
==========================================
+ Hits         5071     5101      +30     
- Misses       5473     5479       +6     
- Partials      490      492       +2     

Impacted Files	Coverage Δ
pkg/util/util.go	55.26% <0.00%> (ø)
pkg/url/url.go	64.14% <0.00%> (+0.83%)	⬆️
pkg/sync/sync.go	47.52% <0.00%> (+0.99%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update c7dbe2c...07adf2d. Read the comment docs.

[girishramnani]

Some questions -

• Would the odo log work with the deployed slim container?
• Would the odo exec command be allowed to run commands on the deployed prod container?
• What kind of kubernetes resource would the Image be deployed as? Like a low level Pod resource or a replicated Deployment or something else?
• Would we allow configure health checks (liveness probes)?

[adisky]

/ok-to-test

[kadel]

• Would the odo log work with the deployed slim container?

yes, but we can address this later.

• Would the odo exec command be allowed to run commands on the deployed prod container?

yes, but we can address this later.

• What kind of kubernetes resource would the Image be deployed as? Like a low level Pod resource or a replicated Deployment or something else?

That will be complete under the devfile creator control. deployment-manifest: could point to anything. It can be Pod, Deployment, Knative Service, or CR, or even multiple resources-

• Would we allow configure health checks (liveness probes)?

Same as above, it will depend on what will be defined in deployment-manifest should be able to add there almost anything they want.

[dharmit]

Mostly questions based solely on what I read on this PR. Please feel free to point me to docs that you feel one must read to understand this better. I'm trying to grok the google doc I found for "Devfile 2.1.0 proposal".

[neeraj-laad]

@girishramnani

• Would the odo log work with the deployed slim container?

Based on current thinking No. It would be good to not intermingle the commands for inner-loop/outer-loop to start with. But we can put this as a future piece if we think it might be useful.

• Would the odo exec command be allowed to run commands on the deployed prod container?

I would think No - purely because I do not understand what use case will need this. Can you think of a reason why this would be useful?

• What kind of kubernetes resource would the Image be deployed as? Like a low level Pod resource or a replicated Deployment or something else?

We would like to support any Kubernetes resource. So devfile creator can decide what makes most sense. standard k8s deployment, knative service, operator custom resource etc.

• Would we allow configure health checks (liveness probes)?

My current thought is that we will not do anything over and above what the devfile creator specifies. If they want specific health/liveness probes they need to provide those in the deployment manifest. or maybe consider this as a future piece.

[sbose78]

@neeraj-laad Could you please address in your proposal why we aren't going to use the BuildConfig Dockerfile strategy in OpenShift ?

@girishramnani @kadel @dharmit

Would it be messy if we had a couple of if-else blocks where

• if openshift, use buildconfig and push to imagestream
• if non-openshift, use plain pods, and push to quay.io-ish registry with credentials.

[kadel]

Would it be messy if we had a couple of if-else blocks where

• if openshift, use buildconfig and push to imagestream
• if non-openshift, use plain pods, and push to quay.io-ish registry with credentials.

This would be ok. We already doing something similar for URLs where odo creates Routes when working with OpenShift and Ingress when working with Kubernetes

[neeraj-laad]

@sbose78 @kadel I have updated to proposal to use BuildConfig if present on cluster or use kaniko if not.

This will mean the first PR could provide OpenShift support using BuildConfig. and a follow on PR could add support for generic Kubernetes with Kaniko.

[kadel]

Just one small comment.
Overall this looks good
/approve

[openshift-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: kadel

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• docs/OWNERS [kadel]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[kadel]

/lgtm

overriding CI, we don't need tests for this PR
/override ci/prow/v4.5-integration-e2e
/override ci/prow/v4.4-integration-e2e
/override ci/prow/v4.3-integration-e2e
/override ci/prow/v4.2-integration-e2e

[openshift-ci-robot]

@kadel: Overrode contexts on behalf of kadel: ci/prow/v4.2-integration-e2e, ci/prow/v4.3-integration-e2e, ci/prow/v4.4-integration-e2e, ci/prow/v4.5-integration-e2e

In response to this:

/lgtm

overriding CI, we don't need tests for this PR
/override ci/prow/v4.5-integration-e2e
/override ci/prow/v4.4-integration-e2e
/override ci/prow/v4.3-integration-e2e
/override ci/prow/v4.2-integration-e2e

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[jaideepr97]

Hi folks, based on my understanding of this proposal, I had a few questions (apologies for any trivial/previously answered questions) :-

1. odo deploy flags mentions multiple ways to handle flag inputs (registry credentials etc) depending on the type of target ( k8s/OS) - is the target specified in the devfile or supplied in some other way?

2. I understand that as of now odo deploy is intended to only be used for deployments in the dev environment. However, I was wondering, given enough time to mature through successive improvements, if there was any likelihood of configuring existing pipelines to leverage odo deploy internally to deploy applications to prod and other environments at some point down the line

A couple peripheral questions that also seemed relevant to me :

3. Is the intention of having a devfile that the user would not have to worry about any of the deployment details at all? Because as per my understanding the devfile points to variable resources like the deployment manifest and source URL which would probably be specific to an application and can't just be picked up by odo deploy from a stock devfile for a particular language/framework

4. Has the structure of the devfile 2.0 been fixed or is it still being debated? The link for the documentation (https://devfile.github.io/website/) provided on the kubernetes-api github page seems to be broken (https://github.com/devfile/kubernetes-api)

Appreciate any inputs!

[neeraj-laad]

@jaideepr97 Sorry missed this message as the PR got merged.

1. odo deploy flags mentions multiple ways to handle flag inputs (registry credentials etc) depending on the type of target ( k8s/OS) - is the target specified in the devfile or supplied in some other way?

The intent was to sue a fully qualified image name (registry, repo, name, version etc.) to be supplied as the --tag argument and corresponding credentials to be supplied as credentials. That said the first implementation will be using Openshift BuildConfig so we will not need tag and credentials. for that case.

2. I understand that as of now odo deploy is intended to only be used for deployments in the dev environment. However, I was wondering, given enough time to mature through successive improvements, if there was any likelihood of configuring existing pipelines to leverage odo deploy internally to deploy applications to prod and other environments at some point down the line

It can be though, using a developer CLI tool in a pipeline was a bit odd. Instead the odo pipelines init/bootstrap will use the same code to provide appropriate build/deploy artifacts that the pipelines can use. This will allow the pipelines to be generic and not have to rely on odo.

3. Is the intention of having a devfile that the user would not have to worry about any of the deployment details at all? Because as per my understanding the devfile points to variable resources like the deployment manifest and source URL which would probably be specific to an application and can't just be picked up by odo deploy from a stock devfile for a particular language/framework

The intent is that the devfile can provide default dockerfile/deployment manifests that will work with standard apps for that technology/framework. If the developer wants to override this, they do have the capability to do so by utilising standard inheritance and override capabilities that will be available to devfiles.

2. Has the structure of the devfile 2.0 been fixed or is it still being debated? The link for the documentation (https://devfile.github.io/website/) provided on the kubernetes-api github page seems to be broken (https://github.com/devfile/kubernetes-api)

I would think this would be temporary. It is close to getting finalised but this feature was suggesting no changes to devfile spec. As a proper syntax and first class support will be added as part of Devfile 2.1.0

[sbose78]

@EnriqueL8 Is odo push needed to get to odo deploy, I guess No ? :)