Odo: Add ability to switch context between local and kube (odo context)

[johnmcollier]

User Story

As a user, I want to be able to switch contexts between using odo for Kubernetes development with devfiles, and local development with devfiles (with Docker as the container runtime). An odo context <context> command can enable this, where <context> is either local or kube.

Acceptance Criteria

• [ ] It should allow users to easily switch between contexts when developing with devfile projects
• [ ] Users shouldn't have to re-run odo create ... after switching contexts
• [ ] It should be optional. If it isn't run, the default context will be Kube/OpenShift.
• [ ] It should add a field to the config.yaml to note the context: context: <context>

Links

• Parent epic: https://github.com/openshift/odo/issues/2576

/kind user-story

[johnmcollier]

/area Devfile

[gorkem]

What do we expect the context switch to do? Asking because I always imagined the local support would be a flag to certain commands such as push or watch

[johnmcollier]

Our line of thinking was that it would enable users to activate support for "local" development without having to add --local to all of their commands. The context switch would just add some metadata to the odo config.yaml. Alternatively, if we wanted to keep odo context as an optional command for local support, we could also add support for --local flags as well (if --local is used, it would override the current/default context)

Longer-term, we were also thinking odo context could be used as a way to quickly switch between Kubernetes contexts for multiple Kube clusters with odo (like https://github.com/ahmetb/kubectx).

[johnmcollier]

/assign

[elsony]

The other point regarding to adding odo context command is that when user starts to use the local scenario, most of the commands that they call will be all executing on the local. It will pretty rare that the user will call one command on Kube and another command on local and switching context frequently across commands. Having the odo context command will save the user from having to pass the --local flag to all the commands that they are calling.

[kadel]

/area local

[girishramnani]

• we already have context being used for component directory all through out odo commands. So I would suggest target parameter for this feature.
• we have sourceType that can be set to git, binary or local so please consider something else for local development. maybe consider --docker or --oci or --container?
• we can avoid implementing odo context by providing --target flag to odo create which would add Target: <<local or kube>> in the config.yaml. We wouldn't need to provide this flag to all commands as they can pick this information from the local config.
• we can augment odo update to allow switch target from docker to kube or kube to docker. This can essentially be a shortcut for odo config set target <<docker or kube>> then odo push.

[kadel]

Our line of thinking was that it would enable users to activate support for "local" development without having to add --local to all of their commands. The context switch would just add some metadata to the odo config.yaml.
Alternatively, if we wanted to keep odo context as an optional command for local support, we could also add support for --local flags as well (if --local is used, it would override the current/default context)

Longer-term, we were also thinking odo context could be used as a way to quickly switch between Kubernetes contexts for multiple Kube clusters with odo (like https://github.com/ahmetb/kubectx).

@johnmcollier
I'm afraid that adding another command will just make it really confusing.
We already have odo preference that handles global odo settings for the current machine. (stored in $HOME/.odo/
And odo config that is supposed to handle anything that is project-specific. (currently stored with source code in .odo/config.yaml, in future, I would like to completely replace this file with devfile)

I don't want to add another command that that handles settings/preferences/config. I think that odo preference would be a good fit for this.

---

It will pretty rare that the user will call one command on Kube and another command on local and switching context frequently across commands.

@elsony has a good point. People will usually won't run one command on local, and the other on kube, and the next one on local again. Why don't make a preference?

Someone who wants to work on local would just do something like this odo preference set PushTarget local and then work as usual.

The only command that this will be affected by this should be odo push and odo watch

---

• we can avoid implementing odo context by providing --target flag to odo create which would add Target: <<local or kube>> in the config.yaml. We wouldn't need to provide this flag to all commands as they can pick this information from the local config.
• we can augment odo update to allow switch target from docker to kube or kube to docker. This can essentially be a shortcut for odo config set target <<docker or kube>> then odo push.

@girishramnani
This information should not be stored in the local config. Local config is meant to be committed to VCS and shared between people. One person working on the same project might want to work local and others with kube.

[johnmcollier]

I don't want to add another command that that handles settings/preferences/config. I think that odo preference would be a good fit for this.

@kadel Yeah, that's a fair concern, and that's why I brought up using something like odo preference or odo config on slack, as I realized the implementation of odo context would just be a wrapper for those commands.

My concern though with storing the setting in the odo preferences is that it makes it a global change, and needs to be switched off for any projects users want to use on Kube.

[girishramnani]

Again remembering the conversation with jorge about config.local file 😂 @kadel

[girishramnani]

This information should not be stored in the local config. Local config is meant to be committed to VCS and shared between people. One person working on the same project might want to work local and others with kube.

I always forget this aspect 😅 . Yeah I guess the only possible approach is to go with preferences then. But the other points related to the naming still hold.

[jorgemoralespou]

Again remembering the conversation with jorge about config.local file 😂 @kadel

I guess this never got implemented :-D

[girishramnani]

Again remembering the conversation with jorge about config.local file 😂 @kadel

I guess this never got implemented :-D

Well at the time, there wasn’t a good enough usecase and the config file could have become too confusing a feature 😅

[girishramnani]

@johnmcollier I would suggest to have the PushTarget or Target ( I prefer the former as it gives more information ) as a preference in the preferences file

[kadel]

My concern though with storing the setting in the odo preferences is that it makes it a global change, and needs to be switched off for any projects users want to use on Kube.

There should be a flag for odo push that will allow one time overwrite of the default setting in a preference file.

Is there an expectation that the user will work on the multiple projects at the same time where for one he wants to push it to local, and for another project to Kube?
I would expect that if someone wants to work locally they will do it for all of the projects that they are working one. And if there is an exception the odo push flag should be enough.

[johnmcollier]

As discussed on the contributor's call today, we'll do the following:

• MVP: store PushTarget in the odo preferences files, using odo preferences set PushTarget, valid values are Docker and Kube
• Post-MVP: Consider storing the PushStarget setting as part of a future local config file that is gitignored (for environment specific settings).