odo: unable to push devfile, if there is no .odo

@dharmit do you have other solution in mind?

I’d suggest we go ahead with what we’re discussing about odo push creating an env.yaml if it doesn’t find one. But adding similar capabilities to odo config set project and odo config set name can be kept for later time if we receive request from users. I’m saying this because it’s about adding functionality to sub commands unlike odo push. Also, someone using odo config commands first thing after cloning a repo containing devfile.yaml doesn’t sound like a frequent scenario to me.

Don’t get me wrong, I understand the intention. It’s just that I don’t think it’s required right now.

As for the below approach,

• odo project create <project> can create a project and set it in KUBECONFIG as well as env.yaml only if there is no project present because that’s the most conventional this command could become without being unpredictable i.e.

  • odo project create <project-name> sets env.yaml when there is not project/default project present in env.yaml

  • odo project create <project-name> will not set env.yaml if the project is already set.

I agree it makes sense. But it must be clearly laid out in docs so that there’s no room for confusion among users and/or developers.

So the final approach I would like to propose here would be -

• odo create in a directory with or without a devfile.yaml (with experimental mode= on) will always populates .odo/env/env.yaml with current namespace and other values. if there is no namespace that can be detected then
  • either fail or use default
• odo push will use env.yaml file if its available else it will use defaults . assuming if the env.yaml is not present the user didn’t go through the standard odo create process and actually cloned someone’s odo component and due to that the component would be freshly created which means its ok to have a fresh component name and project name.
• odo push in case if it doesn’t find the env.yaml, should create the env.yaml before it starts doing any cluster operations.
• odo config set project, odo config set name will set a namespace and component name in env.yaml even in a directory without .odo but with already existing devfile.yaml. This will essentially bootstrap the full odo component allowing anyone to start with existing devfile.yaml and add some odo specific configurations.
• odo project create <project> can create a project and set it in KUBECONFIG as well as env.yaml only if there is no project present because that’s the most conventional this command could become without being unpredictable i.e.
  • odo project create <project-name> sets env.yaml when there is not project/default project present in env.yaml
  • odo project create <project-name> will not set env.yaml if the project is already set.

Namespace is not a required parameter, but is expected to save in env.yaml file. If we always use the currently active namespace and do not have a static namespace for the component, it would cause errors.

odo push will work without .odo/env/env.yaml with defaults as described before.

Can we make odo push smart enough to check if .odo/env/env.yaml is present in the directory? If it’s not present but devfile.yaml is present, can odo push automagically create .odo/env/env.yaml with some well-informed defaults?

By well-informed defaults I mean:

• it should use project/namespace which is currently set in the KUBECONFIG.
• it should create a component name based on pwd (but I have a reservation against this and would suggest some random string getting appended to component name otherwise a user might have two different nodejs components for two different directories at /home/dshah/project1/nodejs and /home/dshah/project2/nodejs. We can do something similar to what metadata.generateName does for other use cases. This will create one component named nodejs-random-string-1 and nodejs-random-string-2. So user won’t accidentally push/modify something for one component from the directory for other component. This is not related to this discussion so I can open a new issue if there’s not one already.)

What odo push would then do is, just call the same code that odo create calls if it detects that .odo/env/env.yaml is not present in the pwd.

The following behavior seems more natural to me:

odo project create myproject
odo component create java mycomponent
odo push

# now I want to push this component to different project
odo project create myproject2
odo push
# OK: pushed to myproject2


# Now I have decided that I want to always use project1
odo config set project myproject1
odo push
# now push will always push to myproject1

TBH, this sounds quite confusing to me. Whatever we decide to go with, we must make sure to explicitly mention this in the documentation along with a scenario. 😉