[Devfile] odo needs to be storing namespace in local env.yaml file

[johnmcollier]

/kind bug

What versions of software are you using?

Operating System:
macOS
Output of odo version:
odo from master

Actual behavior

I've been looking at writing integration tests for odo's devfile support and was hitting a bizarre issue: tests would intermittently fail because it was trying to retrieve Kube resources or do an odo push in a different namespace than what was expected, thus causing a number of errors

What was happening is that the integration tests would be running in parallel, and standing up their own namespace/project for each test. Since odo push --devfile always just uses the current active namespace (rather than one specified by the user with a --namespace flag or the namespace where the component was pushed to), this would mean a number of issues could occur:
- odo push fails because the namespace is being terminated
- odo push pushes to the wrong namespace
- Unable to retrieve pods because the namespace we did the odo push in, is no longer the active namespace

We should modify odo push for devfiles to do the following:

• Add a --namespace flag to the command, allowing the user to specify the namespace to be used
  • Store the namespace in env.yaml
• If no value was passed in with the flag, check If a namespace exists in env.yaml and if so, use it
• Use the current active namespace if no namespace is set in either --namespace or in the env.yaml

Expected behavior

odo push doesn't always use the current active namespace

[johnmcollier]

/area devfile

[kadel]

We should modify odo push for devfiles to do the following:

• Add a --namespace flag to the command, allowing the user to specify the namespace to be used

  • Store the namespace in env.yaml

• If no value was passed in with the flag, check If a namespace exists in env.yaml and if so, use it

• Use the current active namespace if no namespace is set in either --namespace or in the env.yaml

+1

A little bit of context:
We haven't had this problem before, as for "LocalConfig" components (based on s2i) odo is storing namespace in LocalConfg in .odo/config.yaml with other values. But this is not a good solution as it mixes application definitions and environment-specific config in one file.
What you are proposing makes sense.

But for your testing problem, there is a solution even with the current implementation. It should be possible to just copy the current $KUBECONFIG file into a new location and set KUBECONFIG to this copy in BeforeSuite function https://onsi.github.io/ginkgo/#parallel-specs.
Putting it here just for a record. Not saying that we need to do this. We will need --namespace flag anyway

[GeekArthur]

@elsony Per your request, In this issue we can

Implement
Store namespace info into env.yaml if user specify namespace when running odo create

For

If no value was passed in with the flag, check If a namespace exists in env.yaml and if so, use it

[kadel]

Let me turn this into user story

User Story

• as odo user I want to use my own namespace and not the namespace. (If I git clone repository with devfile.yaml I should not be forced to use namespace that is defined in devfile.yaml)
• as odo user that works on two separate components in different projects, I don't want to be forced to always switch namespaces using kubectl or oc. Odo should remember the correct namespace.
  This is an example of a bad experience:

  cd mycomponent1
  kubectl config set-context --current --namespace=project1
  odo push
  
  cd mycomponent2
  kubectl config set-context --current --namespace=project2
  odo push
  

Acceptance criteria

• if the project is not set in env.yaml or --project flag is not used odo push should work against the current namespace as defined in KUBECONFIG
• if --project flag for odo push is set, use the project specified by the flag
• if odo push is executed and there is a project set in env.yaml the project from env.yaml should be used
• if both --project flag and project in env.yaml are set the flag has priority

[elsony]

Based on the design discussion, we are using --project instead of --namespace for the command to make it consistent with the odo s2i scenario. The value that we store in the env.yaml will continue to use namespace since the eventual goal is to turn the command later to use --namespace in the future.