redhat-developer / odo Goto Github PK

We need to build a wrapper around the oc commands that we will frequently use instead of always execing to oc.
Ideal case would be to use https://github.com/openshift/client-go, but AFAIK it does have support for all the oc commands, so till happens, we will need a wrapper which we can easily replace later on.

This could very well be a different package or even a project outside which we simply import.

release first version

• Use github.com/golang/dep as our dependency management tool (assigned to @surajnarwade)
• Set up Travis (assigned to @kadel)
• Set up coverage, travis, godoc badges (assigned to @kadel)
• Set up bintray for building binaries (assigned to @kadel)

ping @ashetty1 @kadel

We could use something like -

commands:
  - ocdev application create
  - ocdev component create nodejs --git=<url>
  
assert:
- url:  <route_url>
  output: "successfully created"
  exitCode: 0

component create <component_type> [component_name] [--app app_name] [--binary binary_path] [--git git_url] [--dir directory]

component_type is a type of the application such as php, nodejs, python etc…., or it can be mongodb, mariadb etc…
component_name - is an optional parameter, its value defaults to the component_type value,
Component is created in context of current application by default
--app is set than component is created in context of application set by this parameter

Documentation
We should be providing documentation for installing ocdev to cover:

• Pre-requisities
• Download and Installing: MacOS, Windows, Linux
• Verify your installation
• Getting started - @containscafeine
• Update ocdevcli
• Troubleshooting
• Uninstallation

parent issue: #70

Looking at the output and source code, it looks like an application is mapped to a project.

$ oc get project
NAME                  DISPLAY NAME   STATUS
devconfcz18                          Active
labs                                 Active
samplelabs                           Active
the-lounge-jmorales                  Active

$ ocdev application list
devconfcz18
labs
samplelabs
the-lounge-jmorales

As can be inferred from "Use case 14: As a developer, I want to list all applications in my project" an OpenShift project can have multiple applications.

we should automate this somehow, low priority though

ocdev application <name> - change active aplication to <name> application

ocdev component <name> - change active component to <name>

something like:

A newer version of ocdev is available. Either update with your package manager, or run curl <...> | sh to update manually.

We can use queries like oc new-app --search --image-stream=httpd to implement ocdev component search <component name>

Because there is nothing that can represent the application in openshift we need to create something.

First we should figure out where we will keep application metadata and also context of active application.

It can be either client side (in config files in directory like ~/.ocdev/<application_name>).

Or it could be in cluster using CRD. We could take inspiration form Kubernetes Application API proposal, and use something like this:

apiVersion: ocdev.apps.openshift.com/v1beta1
Kind: Application
metadata:
  name: wordpress
spec:
  components:
    - wordpress-mysql-hsvc:
        version: v1
        kind: Service
    - wordpress-mysql:
        group: apps
        version: v1
        kind: StatefulSet
    - wordpress-webserver-hsvc:
        version: v1
        kind: Service
    - wordpress-webserver-svc:
        version: v1
        kind: Service
    - wordpress-mysql:
        group: apps
        version: v1
        kind: StatefulSet
    - wordpress-webserver:
        group: apps
        version: v1
        kind: StatefulSet

Goal

The goal of this epic is to provide a simple installation flow for ocdev as well as update and uninstallation.
While the installation might not be difficult, we should make it really simple so the users could (ideally) install ocdev with a single instruction line.

Description

Getting Started

We need to think about the getting started experience of the end-user with ocdev and try to provide the best first experience. This implies a certain requirements on how the user can install ocdev as well as a flow in the documentation to help the user to quickly ramp up.

The installation of ocdev is requiring some pre-requisites that we need to document.

Once those pre-requisites are installed, we should be looking at how we can simplify the installation of ocdev. For example, on MacOS, we could be using homebrew packages, on Linux we could install from a single command line wget -qO- https://github.com/redhat-developer/ocdev/master/blob/install-ocdev.sh | sh . This should be properly documented too.

After having proceed of the installation, we should guide the user to verify that ocdev has been properly installed.

Now that ocdev is ready, we should provide a default basic set of first commands, something like:

• oc login
• ocdev application create first-app
• ocdev component create nodejs
• ocdev ocdev component create --git https://github.com/openshift/nodejs-ex
• ocdev component push

Staying up to date

How do we handle the updates of ocdev ? Could we be looking at different solutions so that ocdev keep itself automatically up to date?
To start, we can just put a warning to notify the user that there is a new version of ocdev available, and point to the installation/upgrade documentation.

Troubleshooting

What happens when the developer is hitting some issues? Can we provide different DEBUG information when interacting with the OpenShift API?

Uninstallation

We need to provide a way for the developer to properly uninstall ocdev.
If ocdev was installed with homebrew, we can have an uninstall command.
We should provide proper set of instructions to delete on Linux and Windows too.

Documentation

We should be providing documentation for installing ocdev to cover:

• Pre-requisities
• Download and Installing: MacOS, Windows, Linux
• Verify your installation
• Getting started
• Update ocdevcli
• Troubleshooting
• Uninstallation

Sub Tasks

• Create Homebrew package - #69
• show warning when user is running older ocdev version -  #71
• Create installation bash script #74
• add proper documentation #75
• [ ]
• [ ]
• [ ]

When creating applications on OpenShift/K8S, there's currently one label that is standard "app" and that the OpenSHift UI uses to group components that belong to the same application. OpenShift/K8S are trying to standardize on other labels, (e.g. component), and this should be used, so that the application is properly visualized, and in the future, managed with other tools.

I have created an application called devconfcz18 and then a component called httpd.

This are the labels set on the deployment:

And this is what can be seen in the Overview.

As can be seen in the second image, OpenShift identifies the application as "httpd" and not as "devconfcz18"

As the tool relies on "oc" command, it can happen that a developer uses "ocdev" with a context selected in .kube/config of a cluster not accesible. A check should be made, or this error should be properly captured and reported.

$ ocdev application list
unable to list applications: unable to get projects: command: [/usr/local/bin/oc get project -o custom-columns=NAME:.metadata.name] failed to run:
Unable to connect to the server: dial tcp 192.168.64.40:8443: i/o timeout
: exit status 1

https://docs.openshift.com/container-platform/3.7/cli_reference/extend_cli.html

We should have bash script that takes care of installing ocdev in your $PATH. It also determines if oc binary is present or not, and installs it if absent.

ocdev project create <project_name>
ocdev project set <project_name>
ocdev project

project maps to normal openshift project

ocdev component create nodejs --dir=... or any other component with --dir will return a build that fails and another one that passes. This is how the code has been implemented because we first need to run oc new-app nodejs~temp-dir and that directory has no code. This means that the first build will fail. And then we run the second build using oc start-build --from-dir.
This is done because there is no way in oc new-app cannot take local source code as input but instead detected the origin remote from the given repo as input and then pulls it and deploys it.

The output looks like -

$ oc get pods
NAME             READY     STATUS      RESTARTS   AGE
nodejs-1-build   0/1       Error       0          1m
nodejs-1-vst86   1/1       Running     0          1m
nodejs-2-build   0/1       Completed   0          1m

This is not a good user experience.
We need to either remove the extra build in ocdev, or we need a better way of implementing this.

If there's no project selected, which can happen if the entry in .kube/config for the context defined by the current_context is empty, there's an error:

$ ocdev application get
unable to get the active application: unable to get current project name: command: [/Users/jmorales/repositories/jorgemoralespou/openshift-evangelists/oc-login.git/oc-origin project -q] failed to run:
error: no project has been set
: exit status 1

app get [--short]

app get
Display message: "You are currently working on the XYZ application"

app get --short
display just application name nothing else

(use-case 7)

This is needed quite a lot right now, since demoing the tool to someone should not require running any oc commands but right now we need to do an ocdev expose service <service name>

When we run ocdev version, it should also get the version of OpenShift client and server.
Will help in troubleshooting and determining if it's being used with the compatible versions or not.

Goals

Interactive mode for ocdev would be particularly interesting. When a developer is new to the CLI, he does not necessarily know what are the different commands and options.
The interactive mode would help and guide the user to provide the right commands and options.

Enable/Disable options

The interactive mode for ocdev should be unactivable.
We should enable the interactive mode by default, but have options to disable it so that the

Sub-tasks

• Study how to provide interactive mode in ocdev
• #1272

So, right now we have ocdev application create which creates a new application and binds it to the current project.
We should have the following behavior as well -
ocdev application ___

• <name> - sets the given application as the current application #128
• list - lists all the applications
• get - gets the currently active application #23
• delete - deletes the given application

"Use case 24: As a developer, I want to be able to push local directory contents or a binary artifact." defines that:

"As a developer, I want to be able to push local directory contents or an artifact, if I have built a binary artifact that can be directly pushed. The push commands will default to push contents of the local directory, but with a flag the behaviour changes to push a binary artifact."

The push command should push whatever is set, based on the create command mode/flags. By default local directory content, but if the component has been created from a binary, it should try to push the binary.

Description

When using the commands pointing to a particular component or application, like ocdev application delete <application_name>, it would be handy to provide autocompletion.
This way the developer can:

• get the list of all applications / components, in case he does not have them in mind
• fasten the interaction with the commands

for instance
https://github.com/redhat-developer/ocdev/blob/00a364e44c12868f0fc27568f8e4b63b6a76a347/cmd/application.go#L1
https://github.com/redhat-developer/ocdev/blob/00a364e44c12868f0fc27568f8e4b63b6a76a347/cmd/completion.go#L1

As the tool is relying under the hood on "oc" it should be possible to set "--timeout".

We can use ~/.kube/ocdevconfig to store the data that we want like current component, current application info there

looks like it needs to handle the error properly and check required flags argument in place before calling oc binary under the hood. The current error message is not intuitive for any new users.

$ ./ocdev component create hello
command: [/home/prkumar/.minishift/cache/oc/v3.7.1/linux/oc new-app hello~/tmp/fakeSource753103845 --name hello --labels app.ocdev.developers.redhat.com=myproject,component.ocdev.developers.redhat.com=hello] failed to run:
error: Errors occurred while determining argument types:

hello~/tmp/fakeSource753103845 as a local directory pointing to a Git repository:  stat hello~/tmp/fakeSource753103845: no such file or directory

Errors occurred during resource creation:
error: no match for "hello"

The 'oc new-app' command will match arguments to the following types:

  1. Images tagged into image streams in the current project or the 'openshift' project
     - if you don't specify a tag, we'll add ':latest'
  2. Images in the Docker Hub, on remote registries, or on the local Docker engine
  3. Templates in the current project or the 'openshift' project
  4. Git repository URLs or local paths that point to Git repositories

--allow-missing-images can be used to point to an image that does not exist yet.

See 'oc new-app -h' for examples.
: exit status 1

Since ocdev is a very CLI centric tool, it'd be great if we could somehow generate entire CLI documentation and push it on every merge. This takes away the task of manually writing docs, all we will need to do is to put in good descriptions and usages in every command we have with cobra, and we can generate the docs using that.

Cobra lets us generate markdown, man pages, etc, so we could leverage that.
https://github.com/spf13/cobra#generating-documentation-for-your-command

push [component_name] [--app app_name] [--dir directory]

Push content to component
If compoenent_name is not set it uses current component
If app_name is not specified uses current application
use dir as --from-dir for oc start-build

if --dir is not set use current directory (.)

When oc cluster isn't running, we should display a proper error message that the cluster isn't up and running;

# ocdev application create
Creating application: app
unable to create application: app: unable to create new project: command: [/usr/bin/oc new-project app] failed to run:
error: Missing or incomplete configuration info.  Please login or point to an existing, complete config file:

  1. Via the command-line flag --config
  2. Via the KUBECONFIG environment variable
  3. In your home directory as ~/.kube/config

To view or setup config directly use the 'config' command.
: exit status 1