Merge branch 'master' of github.com:openshift/odo into updatedevfiledoc

[skip ci]
Signed-off-by: John Collier <John.J.Collier@ibm.com>

.gitignore

@@ -75,3 +75,10 @@ tags
 
 # VSCode specific
 .vscode
+
+#
+# MAC OS SPECIFIC
+#
+
+# Finder Desktop Service
+.DS_Store

.travis.yml

@@ -130,7 +130,7 @@ jobs:
       # scenario of docker devfile url testing needs only Kube config file. So the test has been
       # added here just to make sure docker devfile url command test gets a proper kube config file.
       # without creating a separate OpenShift cluster.
-      name: "devfile catalog, create, push, delete and docker devfile url command integration tests"
+      name: "devfile catalog, create, push, delete, registry and docker devfile url command integration tests"
       script:
         - ./scripts/oc-cluster.sh
         - make bin
@@ -143,6 +143,7 @@ jobs:
         - travis_wait make test-cmd-devfile-push
         - travis_wait make test-cmd-devfile-watch
         - travis_wait make test-cmd-devfile-delete
+        - travis_wait make test-cmd-devfile-registry
         - odo logout
 
     - <<: *base-test
@@ -161,7 +162,7 @@ jobs:
 
     - <<: *base-test
       stage: test
-      name: "docker devfile push and delete command integration tests"
+      name: "docker devfile push, url, catalog, delete command integration tests"
       script:
         - make bin
         - sudo cp odo /usr/bin

Makefile

@@ -217,6 +217,11 @@ test-cmd-devfile-watch:
 .PHONY: test-cmd-devfile-delete
 test-cmd-devfile-delete:
 	ginkgo $(GINKGO_FLAGS) -focus="odo devfile delete command tests" tests/integration/devfile/
+
+# Run odo devfile registry command tests
+.PHONY: test-cmd-devfile-registry
+test-cmd-devfile-registry:
+	ginkgo $(GINKGO_FLAGS) -focus="odo devfile registry command tests" tests/integration/devfile/
 
 # Run odo storage command tests
 .PHONY: test-cmd-storage

README.adoc

@@ -2,7 +2,7 @@
 <img align="right" role="right" width="180" src="/docs/img/openshift.png?raw=true"/>
 +++
 [id="readme"]
-= `odo` - Developer-focused CLI for OpenShift
+= `odo` - Developer-focused CLI for OpenShift and Kubernetes
 :toc: macro
 :toc-title:
 :toclevels: 1
@@ -15,7 +15,7 @@ image:https://img.shields.io/github/license/openshift/odo?style=for-the-badge[Li
 [[overview]]
 == Overview
 
-`odo` is a fast, iterative, and straightforward CLI tool for developers who write, build, and deploy applications on OpenShift.
+`odo` is a fast, iterative, and straightforward CLI tool for developers who write, build, and deploy applications on OpenShift and Kubernetes.
 
 Existing tools such as `oc` are more operations-focused and require a deep-understanding of Kubernetes and OpenShift concepts. `odo` abstracts away complex Kubernetes and OpenShift concepts for the developer.
 
@@ -25,11 +25,11 @@ Existing tools such as `oc` are more operations-focused and require a deep-under
 `odo` is designed to be simple and concise with the following key features:
 
 * Simple syntax and design centered around concepts familiar to developers, such as projects, applications, and components.
-* Completely client based. No server is required within the OpenShift cluster for deployment.
+* Completely client based. No server is required within the cluster for deployment.
 * Official support for Node.js and Java components.
 * Partial compatibility with languages and frameworks such as Ruby, Perl, PHP, and Python. 
 * Detects changes to local code and deploys it to the cluster automatically, giving instant feedback to validate changes in real time.
-* Lists all the available components and services from the {product-title} cluster.
+* Lists all the available components and services from the cluster.
 
 [id="odo-supported-languages-and-images"]
 === Officially supported languages and corresponding container images
@@ -80,13 +80,13 @@ The list of available container images is sourced from the cluster's internal co
 
 To list the available components and associated container images for your cluster:
 
-. Log in to the {product-title} cluster with {odo-title}:
+. Access your cluster. Authentication with `odo login` for Kubernetes clusters is currently not supported. For OpenShift cluster, you can authenticate with `odo login`: 
 +
 ----
 $ odo login -u developer -p developer
 ----
 
-. List the available {odo-title} supported and unsupported components and corresponding container images:
+. List the available `odo` supported and unsupported components and corresponding container images:
 +
 ----------------------------------------------------
 $ odo catalog list components
@@ -184,8 +184,7 @@ Want to try out the odo experimental mode? Please read the link:https://github.c
 
 *Application:* An application consists of multiple microservices or components that work individually to build the entire application.
 
-*Component:* A component is similar to a microservice. Multiple
-components make up an application. A component has different attributes like storage. `odo` supports multiple component types like nodejs, perl, php, python, and ruby.
+*Component:* A component is similar to a microservice. Multiple components make up an application. A component has different attributes like storage. `odo` supports multiple component types like nodejs, perl, php, python, and ruby.
 
 *Service:* Typically a service is a database or a service that a
 component links to or depends on. For example: MariaDB, Jenkins, MySQL.

cmd/odo/odo.go

@@ -3,7 +3,6 @@ package main
 import (
 	"flag"
 	"os"
-	"strings"
 
 	"github.com/openshift/odo/pkg/log"
 	"github.com/openshift/odo/pkg/odo/cli"
@@ -46,15 +45,6 @@ func main() {
 		}
 	}
 
-	// Override the logging level by the value (if set) by the ODO_LOG_LEVEL env
-	// The "-v" flag set on command line will take precedence over ODO_LOG_LEVEL env
-	v := flag.CommandLine.Lookup("v").Value.String()
-	// if the json flag is passed and is valid, we don't turn on ODO_LOG_LEVEL
-	jsonFlagValue := flag.CommandLine.Lookup("o").Value.String()
-	if level, ok := os.LookupEnv("ODO_LOG_LEVEL"); ok && v == "0" && strings.ToLower(jsonFlagValue) != "json" {
-		_ = flag.CommandLine.Set("v", level)
-	}
-
 	// run the completion, in case that the completion was invoked
 	// and ran as a completion script or handled a flag that passed
 	// as argument, the Run method will return true,

docs/dev/development.adoc

@@ -513,7 +513,7 @@ Below is working example of how we would implement a "HelloWorld" struct.
     machineOutput := GenericSuccess{
       TypeMeta: metav1.TypeMeta{
         Kind:       "HelloWorldExample",
-        APIVersion: "odo.openshift.io/v1alpha1",
+        APIVersion: "odo.dev/v1alpha1",
       }, 
       ObjectMeta: metav1.ObjectMeta{
         Name: "MyProject",

docs/dev/machine-output.adoc

@@ -170,7 +170,7 @@ See the below table for a list of all possible machine readable output commands:
 ----
 {
   "kind": "Application",
-  "apiVersion": "odo.openshift.io/v1alpha1",
+  "apiVersion": "odo.dev/v1alpha1",
   "metadata": {
     "name": "app",
     "namespace": "myproject",
@@ -189,12 +189,12 @@ See the below table for a list of all possible machine readable output commands:
 ----
 {
   "kind": "List",
-  "apiVersion": "odo.openshift.io/v1alpha1",
+  "apiVersion": "odo.dev/v1alpha1",
   "metadata": {},
   "items": [
     {
       "kind": "Application",
-      "apiVersion": "odo.openshift.io/v1alpha1",
+      "apiVersion": "odo.dev/v1alpha1",
       "metadata": {
         "name": "app",
         "namespace": "myproject",
@@ -219,7 +219,7 @@ See the below table for a list of all possible machine readable output commands:
 ----
 {
     "kind": "Component",
-    "apiVersion": "odo.openshift.io/v1alpha1",
+    "apiVersion": "odo.dev/v1alpha1",
     "metadata": {
         "name": "nodejs-nodejs-ex-xvgz",
         "namespace": "foobarz",
@@ -232,12 +232,12 @@ See the below table for a list of all possible machine readable output commands:
         "sourceType": "local",
         "urls": {
             "kind": "List",
-            "apiVersion": "odo.openshift.io/v1alpha1",
+            "apiVersion": "odo.dev/v1alpha1",
             "metadata": {},
             "items": [
                 {
                     "kind": "url",
-                    "apiVersion": "odo.openshift.io/v1alpha1",
+                    "apiVersion": "odo.dev/v1alpha1",
                     "metadata": {
                         "name": "myurl",
                         "creationTimestamp": null
@@ -254,7 +254,7 @@ See the below table for a list of all possible machine readable output commands:
                 },
                 {
                     "kind": "url",
-                    "apiVersion": "odo.openshift.io/v1alpha1",
+                    "apiVersion": "odo.dev/v1alpha1",
                     "metadata": {
                         "name": "json",
                         "creationTimestamp": null
@@ -271,12 +271,12 @@ See the below table for a list of all possible machine readable output commands:
         },
         "storages": {
             "kind": "List",
-            "apiVersion": "odo.openshift.io/v1alpha1",
+            "apiVersion": "odo.dev/v1alpha1",
             "metadata": {},
             "items": [
                 {
                     "kind": "storage",
-                    "apiVersion": "odo.openshift.io/v1alpha1",
+                    "apiVersion": "odo.dev/v1alpha1",
                     "metadata": {
                         "name": "mystorage",
                         "creationTimestamp": null
@@ -288,7 +288,7 @@ See the below table for a list of all possible machine readable output commands:
                 },
                 {
                     "kind": "storage",
-                    "apiVersion": "odo.openshift.io/v1alpha1",
+                    "apiVersion": "odo.dev/v1alpha1",
                     "metadata": {
                         "name": "mystorage2",
                         "creationTimestamp": null
@@ -323,12 +323,12 @@ See the below table for a list of all possible machine readable output commands:
 ----
 {
   "kind": "List",
-  "apiVersion": "odo.openshift.io/v1alpha1",
+  "apiVersion": "odo.dev/v1alpha1",
   "metadata": {},
   "items": [
     {
       "kind": "Component",
-      "apiVersion": "odo.openshift.io/v1alpha1",
+      "apiVersion": "odo.dev/v1alpha1",
       "metadata": {
         "name": "nodejs-nvnh",
         "creationTimestamp": null
@@ -358,12 +358,12 @@ See the below table for a list of all possible machine readable output commands:
 ----
 {
   "kind": "List",
-  "apiVersion": "odo.openshift.io/v1alpha1",
+  "apiVersion": "odo.dev/v1alpha1",
   "metadata": {},
   "items": [
     {
       "kind": "Project",
-      "apiVersion": "odo.openshift.io/v1alpha1",
+      "apiVersion": "odo.dev/v1alpha1",
       "metadata": {
         "name": "myproject",
         "creationTimestamp": null
@@ -387,7 +387,7 @@ See the below table for a list of all possible machine readable output commands:
 ----
 {
   "kind": "storage",
-  "apiVersion": "odo.openshift.io/v1alpha1",
+  "apiVersion": "odo.dev/v1alpha1",
   "metadata": {
     "name": "mystorage",
     "creationTimestamp": null
@@ -405,12 +405,12 @@ See the below table for a list of all possible machine readable output commands:
 ----
 {
   "kind": "List",
-  "apiVersion": "odo.openshift.io/v1aplha1",
+  "apiVersion": "odo.dev/v1aplha1",
   "metadata": {},
   "items": [
     {
       "kind": "Storage",
-      "apiVersion": "odo.openshift.io/v1alpha1",
+      "apiVersion": "odo.dev/v1alpha1",
       "metadata": {
         "name": "mystorage",
         "creationTimestamp": null
@@ -430,7 +430,7 @@ See the below table for a list of all possible machine readable output commands:
 ----
 {
   "kind": "url",
-  "apiVersion": "odo.openshift.io/v1alpha1",
+  "apiVersion": "odo.dev/v1alpha1",
   "metadata": {
     "name": "foobar-8080",
     "creationTimestamp": null
@@ -449,12 +449,12 @@ See the below table for a list of all possible machine readable output commands:
 ----
 {
   "kind": "List",
-  "apiVersion": "odo.openshift.io/v1alpha1",
+  "apiVersion": "odo.dev/v1alpha1",
   "metadata": {},
   "items": [
     {
       "kind": "url",
-      "apiVersion": "odo.openshift.io/v1alpha1",
+      "apiVersion": "odo.dev/v1alpha1",
       "metadata": {
         "name": "foobar-8080",
         "creationTimestamp": null

docs/proposals/odo-debug.md

@@ -32,7 +32,7 @@ Odo sets up port-forwarding to allow a debugger to connect to the running proces
 
 ```yaml
 kind: LocalConfig
-apiversion: odo.openshift.io/v1alpha1
+apiversion: odo.dev
 ComponentSettings:
   Type: nodejs
   SourceLocation: ./
@@ -72,7 +72,7 @@ Optional flag, that controls the number of the local port. The value is not stor
 ##### The `DebugPort` is set in the LocalConfig:
 ```yaml
 kind: LocalConfig
-apiversion: odo.openshift.io/v1alpha1
+apiversion: odo.dev
 ComponentSettings:
   Type: nodejs
   SourceLocation: ./
@@ -89,7 +89,7 @@ ComponentSettings:
 ##### If the `DebugPort` is NOT set in the LocalConfig:
 ```yaml
 kind: LocalConfig
-apiversion: odo.openshift.io/v1alpha1
+apiversion: odo.dev
 ComponentSettings:
   Type: nodejs
   SourceLocation: ./

docs/public/deploying-a-devfile-using-odo.adoc

@@ -8,21 +8,21 @@ With a devfile you can describe:
 
 * The source code being used
 * Development components such as IDE tools (VSCode) and application runtimes (Yarn / NPM)
-* A list of pre-defined commands that can be ran
+* A list of pre-defined commands that can be run
 * Projects to initially clone
 
 Odo takes this devfile and transforms it into a workspace of multiple containers running on OpenShift, Kubernetes or Docker.
 
-Devfile's are YAML files with a defined structure, take a look at the general https://github.com/redhat-developer/devfile/blob/master/docs/devfile.md[schema] of devfile.
+Devfiles are YAML files with a defined https://github.com/redhat-developer/devfile/blob/master/docs/devfile.md[schema].
 
 == Odo and devfile
 
-When deploying a devfile using odo, odo will automatically look at the default https://github.com/elsony/devfile-registry[devfile] https://github.com/eclipse/che-devfile-registry/[registries]. Interacting with the devfile registries allows a user to pull a standard `devfile.yaml` and begin development immediately.
+Odo can now create components from devfiles as recorded in registries. Odo automatically consults the default https://github.com/elsony/devfile-registry[devfile] https://github.com/eclipse/che-devfile-registry/[registries] but users can also add their own registries. Devfiles contribute new component types that users can pull to begin development immediately.
 
 An example deployment scenario:
 
-. `odo create` will look at devfile registry and pull down the `devfile.yaml` file
-. odo push  parses and then deploys the component in the following order:
+. `odo create` will consult the recorded devfile registries to offer the user a selection of available component types and pull down the associated `devfile.yaml` file
+. `odo push` parses and then deploys the component in the following order:
  .. Parses and validates the YAML file
  .. Deploys the development environment to your OpenShift cluster
  .. Synchronizes your source code to the containers
@@ -209,15 +209,15 @@ In this example we will be deploying an https://github.com/odo-devfiles/nodejs-e
  $ cd <directory-name>
 ----
 
-. List the contents of the directory to see that the front end is a Node.js application:
+. List the contents of the directory to confirm that the application is indeed a Node.js® application:
 +
 [source,sh]
 ----
  $ ls
  app  LICENSE  package.json  package-lock.json  README.md
 ----
 
-. Create a component configuration of Node.js component-type named mynodejs:
+. Create a component configuration using the `nodejs` component-type named `mynodejs`:
 +
 [source,sh]
 ----
@@ -304,17 +304,16 @@ In this example, we will be deploying the same Java Spring Boot® component we d
 
 *Prerequisites:* Docker `17.05` or higher installed
 
-. Enabling the separate pushtarget preference:
+. Enabling a separate push target, using the `pushtarget` preference:
 +
 [source,sh]
 ----
  $ odo preference set pushtarget docker
  Global preference was successfully updated
 ----
 +
-You can configure a separate push target by making use of the `pushtarget` preference.
 
-. Create a component configuration of Spring Boot component-type named mydockerspringboot and download its sample project:
+. Create a component configuration using the `java-spring-boot` component-type named `mydockerspringboot` and download its sample project:
 +
 [source,sh]
 ----
@@ -341,7 +340,7 @@ You can configure a separate push target by making use of the `pushtarget` prefe
 +
 In order to access the docker application, exposed ports are required and automatically generated by odo.
 
-. Deploy the Spring Boot devfile component to Docker:
+. Deploy the Spring Boot® devfile component to Docker:
 +
 [source,sh]
 ----