Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

EXPERIMENTAL feature flag #2536

Closed
kadel opened this issue Jan 27, 2020 · 2 comments · Fixed by #2560
Closed

EXPERIMENTAL feature flag #2536

kadel opened this issue Jan 27, 2020 · 2 comments · Fixed by #2560
Assignees
Labels
area/devfile-spec Issues or PRs related to the Devfile specification and how odo handles and interprets it. kind/user-story An issue of user-story kind priority/Medium Nice to have issue. Getting it done before priority changes would be great.

Comments

@kadel
Copy link
Member

kadel commented Jan 27, 2020

User story

  • As a user, I have an expectation that all features in odo are stable and well tested.
  • As an advanced user, I'm interested in new uncomplete features and I'm aware that that there might not be stable but I want to test them.

Acceptance Criteria

  • odo should not show any commands or flags that are marked as EXPERIMENTAL if experimental features are not enabled
  • odo should show additional flags or commands that are not complete or marked as EXPERIMENTAL if experimental features are enabled

Background

We do time-based releases every sprint, and we will need to merge something that is not yet fully implemented in order to allow early adopters to test it and give us feedback.

It would be nice to have the option to hide partially implemented stuff from users, but at the same time allow them to test it if they really want.

We could either use the environment variable ODO_EXPERIMENTAL=true environment variable or we could do something like odo preference set odo-experimental true and use odo preference file to enable or disable experimental features.

odo preference might be slightly better as it will be more platform-independent and easier to use for tools build on top of odo (like ide plugins).

We will use this with the Devfile implementation.

The idea is that all The Devfile related functionality will be hidden by default unless the user enables it by running odo preference set odo-experimental true (or export ODO_EXPERIMENTAL=true).
This will allow us to merge even partially functional Devfile implementation.

Once the Devfile implementation is more complete and functional we can enable it by default.

How this will be used in Devfile implementation

No experimental features enabled:

$ odo create -h
# --devfile  flag is not mentioned anywhere

$ odo create java --devfile
Uknown flag --devfile

$ ls
src
.odo 
devfile.yaml

$ odo push
# "old style (s2i) " component defined in .odo will be pushed

Experimental features enabled odo preference set odo-experimental true or export ODO_EXPERIMENTAL=true


$ odo create -h
# help output includes --devfile  flag and its description

$ odo create java --devfile
# will create new devfile.yaml file in the current directory (To Be Defined)

$ ls
src
.odo 
devfile.yaml

$ odo push
#  odo will use devfile.yaml definition to create and push component
# More details will be defined in https://github.com/openshift/odo/issues/2470

/kind user-story
/priority medium
/area devfile

@openshift-ci-robot openshift-ci-robot added kind/user-story An issue of user-story kind priority/Medium Nice to have issue. Getting it done before priority changes would be great. area/devfile-spec Issues or PRs related to the Devfile specification and how odo handles and interprets it. labels Jan 27, 2020
@maysunfaisal
Copy link
Contributor

@kanchwala-yusuf I just tried this out from master, but i dont see the devfile flag when enabled:

maysuns-mbp:odo maysun$ ./odo preference set experimental true
? experimental is already set. Do you want to override it in the config Yes
Global preference was successfully updated

maysuns-mbp:odo maysun$ ./odo preference view 
PARAMETER             CURRENT_VALUE
UpdateNotification    
NamePrefix            
Timeout               
PushTimeout           
Experimental          true

maysuns-mbp:odo maysun$ ./odo push -h
Push source code to a component.

Usage:
  odo push [component name] [flags]

Examples:
  # Push source code to the current component
  odo push
  
  # Push data to the current component from the original source.
  odo push
  
  # Push source code in ~/mycode to component called my-component
  odo push my-component --context ~/mycode

Flags:
      --config               Use config flag to only apply config on to cluster
      --context string       Use given context directory as a source for component settings
  -f, --force-build          Use force-build flag to force building the component
  -h, --help                 Help for push
      --ignore stringSlice   Files or folders to be ignored via glob expressions.
      --show-log             If enabled, logs will be shown when built
      --source               Use source flag to only push latest source on to cluster

Additional Flags:
  -v, --v Level              Log level for V logs. Level varies from 0 to 9 (default 0).
      --vmodule moduleSpec   Comma-separated list of pattern=N settings for file-filtered logging

@kanchwala-yusuf
Copy link
Contributor

@kanchwala-yusuf I just tried this out from master, but i dont see the devfile flag when enabled:

maysuns-mbp:odo maysun$ ./odo preference set experimental true
? experimental is already set. Do you want to override it in the config Yes
Global preference was successfully updated

maysuns-mbp:odo maysun$ ./odo preference view 
PARAMETER             CURRENT_VALUE
UpdateNotification    
NamePrefix            
Timeout               
PushTimeout           
Experimental          true

maysuns-mbp:odo maysun$ ./odo push -h
Push source code to a component.

Usage:
  odo push [component name] [flags]

Examples:
  # Push source code to the current component
  odo push
  
  # Push data to the current component from the original source.
  odo push
  
  # Push source code in ~/mycode to component called my-component
  odo push my-component --context ~/mycode

Flags:
      --config               Use config flag to only apply config on to cluster
      --context string       Use given context directory as a source for component settings
  -f, --force-build          Use force-build flag to force building the component
  -h, --help                 Help for push
      --ignore stringSlice   Files or folders to be ignored via glob expressions.
      --show-log             If enabled, logs will be shown when built
      --source               Use source flag to only push latest source on to cluster

Additional Flags:
  -v, --v Level              Log level for V logs. Level varies from 0 to 9 (default 0).
      --vmodule moduleSpec   Comma-separated list of pattern=N settings for file-filtered logging

@maysunfaisal ,
The --devfile example shared above by @kadel is just a toy example (at least I would like to consider it that way) and demonstrates how the experimental mode should behave.

In the current master, the odo push-devfile command has been placed in the experimental mode.

We are now working towards removing the push-devfile sub command and replacing it with --devfile flag. You can see #2538 issue and it's associated PR #2598. Once this PR is merged, you would be able see --devfile flag in odo push -h output, only when experimental mode is enabled.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/devfile-spec Issues or PRs related to the Devfile specification and how odo handles and interprets it. kind/user-story An issue of user-story kind priority/Medium Nice to have issue. Getting it done before priority changes would be great.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants