Odo: Support OpenShift build and deploy support in odo

[neeraj-laad]

/kind feature

Which functionality do you think we should add?

Add a new command (verb) to build a production-like/slim container image for their project and deploy the built image on the target platform.

• odo deploy could provide developers with a way to build a container image for their application and deploy it on a target Kubernetes deployment using the build/deploy guidance provided by the stack.
• This is not meant to replace GitOps / pipeline based deployments for your controlled environments (test, stage, production), but it will complement them and can be a good way to assure the developer that their application can be built and deployed successfully. Both the deployment routes must honour the build and deployment information provided by the application stack (devfile).

The design proposal for this feature is here: https://github.com/openshift/odo/pull/3368

Early design thoughts were captured here: https://docs.google.com/document/d/1uaFOmutO_bWMv78tPTrdCUuFEBMfz9GADyVInySDsOI
Note: This google doc is now obsolete as we have a forma design proposal.

Why is this needed?

odo provides a great way to develop containerized applications on Docker and Kubernetes platforms (including OpenShift) using applications stacks based on Devfiles. However, this is limited to development inner-loop for a project and there is no support for outer-loop - build a slim/production container image for your application and deploy the build container.

It would be very useful for application developers to be able to build a container image and perform a Kubernetes deployment for their project. This information could be provided by the devfile to avoid developers having to worry about these aspects.

[neeraj-laad]

@kadel @elsony @girishramnani @sbose78 Would be very useful to get your view on this proposal/design.

[sbose78]

I did plan to have both 'odo deploy' and 'odo pipelines' co-exist. So this is well-aligned!

"odo build" is for deploying the code as a 'real' workload.
"odo pipelines" is for multi-stage & multi-task activities which would eventually be "saved" in a Git repo and managed out of it.

An ideal solution to build the source into an image should look like this:

"odo deploy" should only build an image, push it to a registry and deploy it, with/without use of Tekton objects.

• On OpenShift, If the cluster has BuildConfig, use BuildConfig ( supports Dockerfile, s2i with detected language ). Doesn't need any devfile guidance.

• On Kubernetes/OpenShift, Use Build v2 / Tekton APIs if present ( supports Dockerfile, Buildpacks, s2i )

• Else, use plain pod/container steps in a Deployment as recommended in the doc.

Regarding guidance,

• If there's devfile guidance, use it!
• Else, detect language and do an s2i / buildpacks-v3 build if there's also no /Dockerfile present in the repo.

I went through your doc and left some comments.

What are your thoughts on the image registry creds? We would need to ensure the service account which is going to do the build has the right creds linked.

• In OpenShift/BuildConfig, we could push to an imagestream.
• In Kubernetes, we wouldn't have it and hence we should support odo deploy --output-image-repo-credentials=path/to/creds. This would automatically link it to the service account being used.

[neeraj-laad]

Thanks for your comments on the proposal document. I merged some and responded to some. Please let me know if you have further comments/questions.

I do understand we have a wider proposal on this area, that will cover a broader design and multiple strategies etc. However, it will not be available in devfile v2.0.0.

So, the main purpose of raising this issue was to see if we feel that providing a simple implementation as dev-preview/tech-preview would be feasible/practical, and start steering us towards where we want to be with the wider proposal. I do not think we want to support all the cases with devfile v2.0.0 and instead, give ourselves more time/space to come up with a well thought through design for v2.1.0.

[sbose78]

Absolutely. My long comment was to layout the broader idea behind what we must eventually support, after starting small.

Also, even if something is semi-baked and not ready to be "released" as a spec in devfile 2.1.0, I'll support getting "preview" features in odo and then finalize the spec - even while working on odo support for devfile 2.0.0

[mnuttall]

In today's meeting we raised the question of how odo deploy should handle a project with a (kubernetes deployment) manifest stored remotely in a stak parent. In this case,

Should odo deploy copy the manifest into the local repo? Should it then be checked in, added to .gitignore or even kept outside the local repo? If checked in, should it be used by odo pipelines service add in preference to the version in the stack?

The linked Google doc states,

No changes will be made on the user's workspace / project.

If this holds then odo pipelines service add [--stak] would have to obtain the manifest from the remote parent. If odo deploy failed, a developer would have to investigate without the benefit of a local copy of the deployment yaml.

For now we need to decide whether 'no local changes' is an absolute rule than extends to the 'remote manifest' case.

[kadel]

by default odo deploy should not store manifest (we could introduce the flag to optionally print out the k8s manifest, but it should not be its main purpose). As I see it this command is for quick transition from the outer loop to interloop and mainly for testing that everything works as expected.

This is how I see a simple e2e scenario with an inner-loop and outer-loop when using odo.

1. odo create java mycomponent
   _This initializes odo component in the current directory. Or in other words, it downloads the java devfile from the devfile registry into the current directory._
2. working on the source code
3. odo push to check changes
4. go back to step 2. if needed
5. odo deploy
   _This step would build a new clean image and deploy it to the cluster.
   I don't currently have details on how the image build should look like, we will need to figure that out. But main point for this command is that it just does things without showing any k8s manifests to the user. There could be an optional flag, something like odo deploy --show-manifest if someone really wants to see what is happening._
6. testing what was deployed in the previous step, go back to 2. if something needs to be updated
7. odo pipelines bootstrap
   _This would bootstrap the GitOps repository. Internally the image build process and used in pipelines and the logic for generating manifest like Deployment should be the same as in odo deploy_

[sbose78]

@kadel This looks good!

[neeraj-laad]

@kadel @sbose78 Thanks for articulating the flow well.

I also wanted to get some agreement on the main purpose/intent for this command as that might help us scope it properly.

In my view, odo deploy is a way for the developer to test/verify that the build and deploy guidance from the devfile works fine with the app source and is able to create a production-like container image and deploy it.

It is NOT the recommended way for deploying apps developed using odo. That part should be dealt by odo pipelines by following proper GitOps processes or other CI/CD processes after checking your code in a src repo.

If we agree with the above can also state that odo deploy will:

• not make any changes to user's workspace (no build/deploy artifacts will be added by default)
• use dev versions of external links/services (like we do with odo push)
• deploy the app in the same namespace as used during dev (like we do with odo push)
• create resources that will be cleaned up when the dev component is cleaned up?

[neeraj-laad]

@sbose78 @kadel what are your thoughts on tagging, pushing image built and using it in the deployment?

[sbose78]

Coming back from a long weekend, will review! :)

[kadel]

If we agree with the above can also state that odo deploy will:

• not make any changes to user's workspace (no build/deploy artifacts will be added by default)

+1

• use dev versions of external links/services (like we do with odo push)

Yes, but it would be great if this was somehow configurable. Currently, we don't have a standard way of how these links should be represented. We can delay this for later when we know more about how to properly deal with external links/services.

• deploy the app in the same namespace as used during dev (like we do with odo push)

Similar to above, if the user wants to push this into separate namespace it should be possible.

• create resources that will be cleaned up when the dev component is cleaned up?

+1

[sbose78]

@sbose78 @kadel what are your thoughts on tagging, pushing image built and using it in the deployment?

Are you building odo deploy to work both on OpenShift and Kubernetes? The key difference here would be that OpenShift comes with an internal registry / imagestreams, whereas Kubernetes doesn't.

Here are our options:

• Optionally take the fully qualified image URL and credentials as a flag. If provided, ensure, it is made available to the pod which does the buildah push.

• If the user doesn't provide the fully qualified image URL , could we attempt pushing to an imagestream/internal registry, and use the same in the Deployment? This makes a non-explicit assumption that non-specification of the image url means that the user is doing an odo deploy against OpenShift.

[neeraj-laad]

@sbose78 Thanks for your thoughts. We were thinking on the same lines of adding a tag and credentials as flags with defaults referring to OpenShift scenario.

Another options that is possible is to provide this for OpenShift only as a starting point and then add Kubernetes support later.

[sbose78]

Another options that is possible is to provide this for OpenShift only as a starting point

+100 !

Thoughts, @kadel ?

[girishramnani]

A quick question -
How would odo deploy behave when users are in local mode? i.e. docker mode.

[neeraj-laad]

A quick question -
How would odo deploy behave when users are in local mode? i.e. docker mode.

@girishramnani odo deploy will only make sense for Kubernetes cases. There is no point providing deployment capability for docker environment. So, as per current proposal it will just provide a message to the user stating they need to be on Kubernetes mode. (Thanks: I will update the proposal to explain this)

I can see it would be useful if the developer can develop/push on docker and test the deploy part on Kubernetes cluster. I'm not sure if we can do that without having to switch the push target today. Perhaps that support can be added as a second pass. Thoughts?

[neeraj-laad]

/assign @neeraj-laad @EnriqueL8

[openshift-ci-robot]

@neeraj-laad: GitHub didn't allow me to assign the following users: EnriqueL8.

Note that only openshift members, repo collaborators and people who have commented on this issue/PR can be assigned. Additionally, issues/PRs can only have 10 assignees at the same time.
For more information please see the contributor guide

In response to this:

/assign @neeraj-laad @EnriqueL8

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.

[EnriqueL8]

/assign

[EnriqueL8]

After moving to using BuildConfig, we are unsure if we should be creating a new devfile adapter for Openshift which uses the occlient or split the code within the Kuberenetes adapter into BuildConfig for OCP and Kaniko for Kube.

• The Openshift adapter would only implement the build path for odo deploy and would call to the Kubernetes Adapter for all the other paths (push, delete...).
• We realise that the kclient is generic and can accept any resources, but we wanted to leverage the BuildConfig functions already implemented in the occlient.

[dharmit]

It is NOT the recommended way for deploying apps developed using odo. That part should be dealt by odo pipelines by following proper GitOps processes or other CI/CD processes after checking your code in a src repo.

Sorry for being too late to the party and apologies in advance because my comment's going to likely irk a few.

Is it just me who finds it "ironical" that "odo deploy is NOT the recommended way for deploying apps developed using odo"?

We use the verb "deploy" but don't want it to do what the verb is actually meant in general lingo. I had this reservation when I reviewed #3368 but didn't bring it up there assuming I was late to point it out.

Sure I'm even late to point to it now but, as a user, I find it unsettling to use "odo deploy to not deploy my app".

WDYT @kadel @neeraj-laad @sbose78?

[kadel]

• We realise that the kclient is generic and can accept any resources, but we wanted to leverage the BuildConfig functions already implemented in the occlient.

@EnriqueL8
I'm not sure how much of this you will be able to use. The current functions in occlient around BuildConfig were all written to use just s2i build strategy. You might be able to salvage something from it, but I don't think that you will be able to use them as they are :-/

[neeraj-laad]

It is NOT the recommended way for deploying apps developed using odo. That part should be dealt by odo pipelines by following proper GitOps processes or other CI/CD processes after checking your code in a src repo.

Sorry for being too late to the party and apologies in advance because my comment's going to likely irk a few.

Is it just me who finds it "ironical" that _"odo deploy is NOT the recommended way for deploying apps developed using odo"_?

We use the verb "deploy" but don't want it to do what the verb is actually meant in general lingo. I had this reservation when I reviewed #3368 but didn't bring it up there assuming I was late to point it out.

Sure I'm even late to point to it now but, as a user, I find it unsettling to use "odo deploy to not deploy my app".

WDYT @kadel @neeraj-laad @sbose78?

@dharmit Thanks for raising this. Better to raise this now than never. :)

In my view odo deploy is meant for deploying to a single environment (typically a development environment), It is not the mechanism we expect users to use as for deploying to environments with multiple stages (dev, test, prod etc.). We would want to steer users to odo pipelines for these commands.

Happy to rephrase this as a PR if that makes the proposal clearer.

[kadel]

In my view odo deploy is meant for deploying to a single environment (typically a development environment),

If we are going to say odo deploy is meant for deploying to development environment that I see why @dharmit has ab issue with calling it deploy.
My assumption about odo deploy was that it will be the straight forward and the most simples way to deploy the application to production. It won't deal with multi-stage environments (dev,test,stage,prod) but it will be able to handle a situation where my production environment is just a different namespace from the development environment.

[neeraj-laad]

@kadel @dharmit The current proposal does NOT allow deploying to another namespace, purely to keep it simple.
Would you want to add that to the current proposal?

Few things to consider if we think of this as a production deployment:

• We will need to add namespace as an optional flag (default to dev namespace) - this should be simple to add.

• User will need to ensure that any service binding/linking info is accurate for the environment you are deploying to. I'm not very familiar with this are, but was hoping to use info created by odo link as basis for injecting link info into odo deployment. In my mind, allowing diff set of services makes it slightly awkward for the user. as they now need those services in the target deployment namespace, which might not be the dev env. Will the odo push and odo deploy interfere with each other in this instance?

[elsony]

Removing need-information label since the design proposal has been merged: https://github.com/openshift/odo/pull/3368

[girishramnani]

we need to finalise the spec before we merge this

[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

[openshift-bot]

Rotten issues close after 30d of inactivity.

Reopen the issue by commenting /reopen.
Mark the issue as fresh by commenting /remove-lifecycle rotten.
Exclude this issue from closing again by commenting /lifecycle frozen.

/close

[openshift-ci-robot]

@openshift-bot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.

Reopen the issue by commenting /reopen.
Mark the issue as fresh by commenting /remove-lifecycle rotten.
Exclude this issue from closing again by commenting /lifecycle frozen.

/close

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.