Move the devfile feature set out of the experimental mode

[girishramnani]

/kind user-story

User Story

As a user I should be able to use the devfile features without having experimental mode enabled. The decision between devfile and s2i will be made based on which config file is present locally.

Acceptance Criteria

• It should use devfile by default
• It should allow user to use devfile without experimental mode
• resolve broken tests

Links

• Feature Request:
• Related issue:

/kind user-story

[elsony]

Note:

1. This item is restricted to the Kube inner loop scenario only.
2. Local docker support should continue to require experimental set to true
3. odo deploy function should continue to require experimental set to true

[elsony]

/area devfile

[cdrage]

I'm implementing Devfile by default in time for the August 4th Alpha release without the experimental mode enabled. There are commands that are not implemented such as:

• storage
• link
• unlink
• update
• describe

How do you think we should hide this in the UX / UI when Devfile is by default? What if a user wants to deploy / edit an S2I deployment? Should I just update the help usage to say (FOR S2I ONLY) beside the command or something?

[kadel]

• storag

odo storage is WIP in #3398

• link

component->service was implemented in #3557
component->component link is planned in #3423 (This probably won't be implemented in time for 2.0)

ping @dharmit

• unlink

planned for this sprint #3563

• update

this command should be deprecated in favor of using odo config
I thought that I opened an issue about this, but I can't find it :-/

• describe

Looks like we forgot about this one :-( We need to implement this before 2.0 release

[dharmit]

component->component link is planned in #3423 (This probably won't be implemented in time for 2.0)
ping @dharmit

Indeed, this is not a priority for 2.0.

• unlink

planned for this sprint #3563

Intend to open a PR soon now that #3557 is in.

• update

this command should be deprecated in favor of using odo config
I thought that I opened an issue about this, but I can't find it :-/

#2688?

[kadel]

• update

this command should be deprecated in favor of using odo config
I thought that I opened an issue about this, but I can't find it :-/

#2688?

That is one part of that. But I was convinced that I explicitly wrote a user story about deprecating odo update. But It looks like I did not :-/

Found it #3396

For devfile component, it shows the following message

▶ odo update
Experimental mode is enabled, use at your own risk

 ✗  'odo update' command is not available for Devfile based components

for s2i component, there is a deprecation warning

  WARNING: odo update is not available for Devfile based components and will be removed in the future odo versions.

[kadel]

opened #3644 to cover odo describe

[cdrage]

I have a proposal. Implementing #3634 has been very difficult with rebasing as well as #3545 being added.

One major UX / UI concern is with regards to the --help output.

With Devfile being the default and --s2i being added as an extra paramter to odo create it's creating an issue where --help is overwhelming to the user with a ton of parameters that only work with certain features (Devfile vs S2I parameters).

What I propose is that instead of adding a parameter (--s2i) we add an preference config similar to how we use odo preference set experimental true

For example:

odo preference set deployment s2i

odo preference set deployment devfile

If we don't do this, --help will have to still show all the parameters / examples and options of both Devfile and S2I which is quite frankly, way too overwhelming. See below:

Examples:
  # Create new Node.js component with the source in current directory.
  
  Note: When you use odo with experimental mode enabled and create devfile component, if you want to use existing devfile the first argument will be the component name
  # Create new Node.js component with existing devfile
  odo create mynodejs (devfile exists in current working directory)
  odo create mynodejs --devfile ./devfile.yaml (devfile exists in any other directory)
  odo create mynodejs --devfile https://raw.githubusercontent.com/elsony/devfile-registry/master/devfiles/nodejs/devfile.yaml (devfile exists in network)
  
  # Create new Node.js component
  odo create nodejs
  
  # Create new Node.js component named 'frontend' with the source in './frontend' directory
  odo create nodejs frontend --context ./frontend
  
  # Create new Java component with binary named sample.jar in './target' directory
  odo create java:8  --binary target/sample.jar
  
  # Create new Node.js component with source from remote git repository
  odo create nodejs --git https://github.com/openshift/nodejs-ex.git
  
  # Create new Node.js component with custom ports, additional environment variables and memory and cpu limits
  odo create nodejs --port 8080,8100/tcp,9100/udp --env key=value,key1=value1 --memory 4Gi --cpu 2
  
  # Create new Node.js component and download the sample project named nodejs-starter
  odo create nodejs --starter=nodejs-starter

Flags:
      --app string                                Application, defaults to active application
  -b, --binary string                             Create a binary file component component using given artifact. Works only with Java components. File needs to be in the context directory.
      --context string                            Use given context directory as a source for component settings
      --cpu string                                Amount of cpu to be allocated to the component. ex. 100m or 0.1 (sets min-cpu and max-cpu to this value)
      --devfile string                            Path to the user specify devfile
      --env strings                               Environmental variables for the component. For example --env VariableName=Value
  -g, --git string                                Create a git component using this repository.
  -h, --help                                      Help for create
      --max-cpu string                            Limit maximum amount of cpu to be allocated to the component. ex. 1
      --max-memory string                         Limit maximum amount of memory to be allocated to the component. ex. 100Mi
      --memory string                             Amount of memory to be allocated to the component. ex. 100Mi (sets min-memory and max-memory to this value)
      --min-cpu string                            Limit minimum amount of cpu to be allocated to the component. ex. 100m
      --min-memory string                         Limit minimum amount of memory to be allocated to the component. ex. 100Mi
      --now                                       Push changes to the cluster immediately
  -p, --port strings                              Ports to be used when the component is created (ex. 8080,8100/tcp,9100/udp)
      --project string                            Project, defaults to active project
  -r, --ref string                                Use a specific ref e.g. commit, branch or tag of the git repository (only valid for --git components)
      --registry string                           Create devfile component from specific registry
      --s2i                                       Path to the user specify devfile
      --starter string[="devfile-project-name"]   Download a project specified in the devfile
      --token string                              Token to be used when downloading devfile from the devfile path that is specified via --devfile

I suggest we add this preference and document this in the --help usage at the very top as well as in our documentation.

This makes it much easier to differentiate between s2i and devfile.

Ping @dharmit @girishramnani @kadel

[cdrage]

Problem 1, IsExperimentalModeEnabled is embedded in our code heavily

Another thing to note too. Our "IsExperimentalModeEnabled" code is heavily embedded in our code. If I were to make Devfile default (taking it out of experimental mode) it would cause a lot of refactoring. You can already see this in my current code here: #3634 where I've had to refactor url.go code.

Have a quick search here: https://github.com/openshift/odo/search?q=IsExperimentalModeEnabled&unscoped_q=IsExperimentalModeEnabled and you'll see that if the IsExperimentalModeEnabled is located anywhere outside pkg/odo/cli it'll have to be refactored and an alternative way to determine if Devfile should be detected on it.

For example, code such as here: https://github.com/openshift/odo/blob/d8a529fce4efd46f4719aca81abaceb2f456b730/pkg/occlient/occlient.go#L755 in the occlient.go file would have to be refactored and a parameter added to https://github.com/openshift/odo/blob/d8a529fce4efd46f4719aca81abaceb2f456b730/pkg/occlient/occlient.go#L714 most likely a bool parameter determining isS2i or not. We are able to detect if a Devifle exists, but only in the /cli package where we have access to the devfilePath variables https://github.com/openshift/odo/blob/32ef163aa6e7605aadd2f5888c2db381c870a643/pkg/odo/cli/component/update.go#L81 Thus we would have to find an alternative way to pass in a way to safely determine if we should use devfile or s2i.

All of this could be solved by simply adding a preference configuration instead of having to continue to determine if a devfile exists in the directory or not.

Problem 2. We cannot safely rely on determining if a Devfile is in the directory or not.

Another problem is the following. Say we were to use odo catalog list components in our home directory, in a non-odo directory. How do we determine to list s2i components or Devfile? We can't. We've taken devfile out of experimental and now we cannot determine whether to list s2i or not.

The way to solve that too would be a preference configuration. Otherwise, the only way to determine if Devfile is enabled or not is by checking the current directory for devfile.yaml. But if you're outside of your development directory, what would we list?

[elsony]

The only problem case is if the user is developing multiple components at the same time with a mixed components of s2i and devfiles. Having said that, I think most user will be using one or another instead of a mix of s2i and devfile components at the same time. Therefore, I think it is fine with adding the preference on setting the deployment flag to determine if the user wants s2i or devfile support.

FWIW...For "Problem 2", I don't think it is a problem even if we don't introduce the preference flag. During catalog list, the user hasn't indicate which mode to add yet so we can just show both type of components (maybe provide a flag to filter to specific type if we need to)

[adisky]

@cdrage
The first reference in oc client was added there #3265, we can solve this at cli layer with --s2i flag, so it could be removed.
Not sure about other places, i agree it is a cumbersome task.

If we are going with preference option then we do not need --s2i flag either.