odo create should not require cluster access to function

[metacosm]

/kind bug

What versions of software are you using?

Operating System: macOS 10.15.6

Output of odo version: odo v1.2.5 (927826e8d)

How did you run odo exactly?

odo create java-quarkus without being connected to a cluster

Actual behavior

✗  You don't have permission to create or set project 'default' or the project doesn't exist. Please create or set a different project
        odo project create|set <project_name>

Expected behavior

odo should create my component without issue. I should be able to work with odo without a cluster up to the moment I actually want to push to the cluster.

Any logs, error output, etc?

See above.

[metacosm]

cc @kadel @maxandersen

[kadel]

+1 odo should not require a cluster if it is not needed for a given action

There is no reason why odo create should not work without a cluster.

[johnmcollier]

Same for odo catalog list components https://github.com/openshift/odo/issues/3779

[prietyc123]

v2.0.0 has been released, so I am removing the required-for-v2

[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

[maxandersen]

Still an issue. Could.someone add frozen ?

[kadel]

Not sure what happened, but this is till a problem that needs to be fixed.

[kadel]

Currently odo create saves project/namespace name into env.yaml. We need to defer this to a later stage (odo push).

Acceptance criteria:

• [ ] odo create is not doing anything with the cluster it should not even read anything from KUBECONFIG. It needs to work even without Kubernetes client configuration.
• [ ] If the user runs just odo create without --project the project name should not be added to env.yaml
yaml # env.yaml ComponentSettings: Name: java AppName: app
• [ ] If the user runs odo create with --project. The Project will be recorded in env.yaml. There should be no check to verify if project/namespace exists or not.
  yaml # env.yaml ComponentSettings: Name: java Project: myproject AppName: app
• [ ] odo push can already handle a situation where there is no env.yaml. It will also need to handle a situation where env.yaml doesn't have specify Project. So for example with
  yaml # env.yaml ComponentSettings: Name: java AppName: app
odo push command will first have to populate Project field with the default value (current project/namespace name) and then perform push action.

[slemeur]

Thanks @kadel !

[dharmit]

/assign @mik-dass

[mik-dass]

If the user runs just odo create without specifying component name or flags like --project, --app .odo/env/env.yaml should not be created.

We should use the component type as the name and the default app name and record it in the env.yaml as they don't require any cluster access.

[kadel]

If the user runs just odo create without specifying component name or flags like --project, --app .odo/env/env.yaml should not be created.

We should use the component type as the name and the default app name and record it in the env.yaml as they don't require any cluster access.

The reason that included this is that I would like to make sure that if someone does just odo create java-maven --starter without any odo specific flags they get just devfile.yaml and the starter project source code without any odo specific stuff.
Users might not even use odo beyond odo create. They might be doing the whole interloop locally or use Che or another tool for the rest of their workflow. .odo directory would just pollute their project directory.

[mik-dass]

The reason that included this is that I would like to make sure that if someone does just odo create java-maven --starter without any odo specific flags they get just devfile.yaml and the starter project source code without any odo specific stuff.

But, in the current state, many commands like URL create, Storage create etc would stop working without the env.yaml along with the devfile.yaml.

[dharmit]

Probably thinking too much ahead of what we're discussing here. But here goes.

I'm assuming that the user decides to use odo for rest of the inner loop tasks instead of moving to use Che or something else.

I don't think odo has a check to prevent multiple components from being assigned the same name. This could be a problem if the user does odo create nodejs in two different dirs. This problem was reported in https://github.com/openshift/odo/issues/4112.

I think that if we can add some random string to the component name when the user doesn't provide a component name would fix both the problems (this issue and #4112).

[kadel]

The reason that included this is that I would like to make sure that if someone does just odo create java-maven --starter without any odo specific flags they get just devfile.yaml and the starter project source code without any odo specific stuff.

But, in the current state, many commands like URL create, Storage create etc would stop working without the env.yaml along with the devfile.yaml.

Good point. We will have to figure out how this should work. I will remove this from the acceptance criteria for now.
I will create another issue to address this problem.

[dharmit]

• If the user runs just odo create without --project the project name should not be added to env.yaml

   # env.yaml
   ComponentSettings:
     Name: java
     AppName: app
  

And why do we need the AppName in the env.yaml? Why can't we defer that to odo push as well?

[kadel]

And why do we need the AppName in the env.yaml? Why can't we defer that to odo push as well?

I tried to reduce it to the bare minimum to solve the odo create problem. And then do the rest in https://github.com/openshift/odo/issues/4424

I'm not sure if we can defer AppName to push. But I did some tests with Name and this one we can't defer to later, because odo url create would produce an invalid URL name. My thought process was that if we can't remove Name than we shouldn't even try to do it with AppName as it could create an even bigger mess.
I still want to do this, but it should be addressed together in a separate issue.