Odo: Experimental destroys regular odo component create command

[amitkrout]

/kind bug

What versions of software are you using?

Operating System:
Supported
Output of odo version:
master

How did you run odo exactly?

$ ODO_EXPERIMENTAL=true odo create nodejs --project test321 --context ../tests/examples/source/nodejs/
 ✓  Checking if the specified component type is supported devfile component type [148319ns]
 ✓  Validating component [71622ns]

Please use `odo push` command to create the component with source deployed

$ ls -a ../tests/examples/source/nodejs/
.               ..              package.json    server.js

$ odo push --context ../tests/examples/source/nodejs/
 ✗  The current directory does not represent an odo component. Use 'odo create' to create component here or switch to directory with a component

Actual behavior

All the component configuration found the the same dir from where i launches the command

$ tree -a 
.
├── .odo
│   └── env
│       └── env.yaml
└── devfile.yaml

Why these configuration files are created for regular odo component create command ?

Expected behavior

Component should be created with proper local config

Any logs, error output, etc?

[amitkrout]

ping @girishramnani @kadel

It seems like we are exposing experimental feature putting original feature at risk. AFAIK experimental feature is some functionality/feature added to the original product to get more feedback from the user side and ofcoures there is a trade-off if it breaks but it should never have bad impact on the original product functionality/feature.

[dharmit]

It seems like we are exposing experimental feature putting original feature at risk.

I think there's some confusion here (I'm referring to the above quoted statement and the section How did you run odo exactly?). What you've done is:

1. Created a component using experimental mode
2. Tried to push it without experimental mode

But, it is expected that when you create a component with experimental mode enabled, you should be pushing it with experimental mode enabled as well. This is because experimental mode creates devfile (./devfile.yaml) and when you don't use experimental mode, odo works with ./.odo/config.yaml which didn't get created because you used experimental mode when creating a component.

The correct way to do this would be:

# create the component
$ ODO_EXPERIMENTAL=true odo create nodejs --project test321 --context ../tests/examples/source/nodejs/

# push the component
$ ODO_EXPERIMENTAL=true odo push

Correct me if i"m wrong @kadel @girishramnani or if I'm mistaken in understanding what you're doing @amitkrout.

[amitkrout]

push the component
$ ODO_EXPERIMENTAL=true odo push

@dharmit Don't you think you are missing --context flag here while pushing. Ideally it would be $ ODO_EXPERIMENTAL=true odo push --context ../tests/examples/source/nodejs/, isn't it ?

[dharmit]

Yes, that's right. But using --context correctly, without enabling experimental mode, in this particular case won't yield to successful push since the component was created using experimental mode.

[GeekArthur]

@amitkrout Regarding It seems like we are exposing experimental feature putting original feature at risk, I think it can be boiled down to the question "How does devfile component and s2i component live together properly?" and the question is not only about odo create, it's about all the corresponding commands such as odo create, odo push, odo url, etc.

Let me briefly explain the design, we would like to support both devfile component and s2i component together using the same command with experimental mode enabled but devfile component has higher priority, which means if nodejs component is supported by both devfile component and s2i component we create devfile nodejs component for user if user runs odo create nodejs. The concept applies to all the other commands such as odo push and odo url. FWIW, this is the design with details: https://github.com/openshift/odo/pull/2598#issuecomment-585680436

From your run in the issue description

$ ODO_EXPERIMENTAL=true odo create nodejs --project test321 --context ../tests/examples/source/nodejs/
 ✓  Checking if the specified component type is supported devfile component type [148319ns]
 ✓  Validating component [71622ns]

Please use `odo push` command to create the component with source deployed

$ ls -a ../tests/examples/source/nodejs/
.               ..              package.json    server.js

$ odo push --context ../tests/examples/source/nodejs/
 ✗  The current directory does not represent an odo component. Use 'odo create' to create component here or switch to directory with a component

You are still creating the devfile component instead of s2i component (regular component) since both devfile component and s2i component support nodejs (you can use odo catalog list components to check which component is supported by which), you find all the configuration files are in the local directory instead of the directory that specifies in --context is because currently the devfile component commands (eg. odo create, odo push) don't support --context flag, we already opened separate issue to track this, for example here is the issue for odo push --context https://github.com/openshift/odo/issues/2744

In short, the behavior you see from the output is expected for now, the issue will be resolved once we support the --context flag for all devfile component commands. It doesn't break the s2i component (regular component) creation since you don't create the 2i component (regular component). If you really want to create the create the 2i component (regular component), you can either create a component that's not supported by devfile component or turn off the experimental flag.

FYI @kadel @girishramnani @elsony

[GeekArthur]

/assign

[GeekArthur]

@amitkrout Probably you already test other scenarios, please let me know, if all tests are good for s2i components this issue should be a feature/user story instead of bug

[dharmit]

@amitkrout I'm removing the priority/critical label from this since the behaviour exhibited is expected.

[amitkrout]

@amitkrout Probably you already test other scenarios, please let me know, if all tests are good for s2i components this issue should be a feature/user story instead of bug

@GeekArthur Thanks for a lovely description https://github.com/openshift/odo/issues/2813#issuecomment-609901433. I have created an issue #2831 to document those vital piece of information.

I have tested only two scenarios and need to cover few more scenario. Then accordingly i will update the label for sure.

[GeekArthur]

@amitkrout I think this one should be fixed, let me know if you still can reproduce this on some scenarios that you test against.

[GeekArthur]

/triage needs-information

[GeekArthur]

Based on the explanation and discussion above, I think this issue is done. @amitkrout Can you use the latest master to verify? If there are no more issues related we can close this one.

[amitkrout]

Based on the explanation and discussion above, I think this issue is done. @amitkrout Can you use the latest master to verify? If there are no more issues related we can close this one.

@GeekArthur Yes, we are good to go. Thanks for your patience
/close

[openshift-ci-robot]

@amitkrout: Closing this issue.

In response to this:

Based on the explanation and discussion above, I think this issue is done. @amitkrout Can you use the latest master to verify? If there are no more issues related we can close this one.

@GeekArthur Yes, we are good to go. Thanks for your patience
/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.