[GLOBAL] Migrate to helm v3
[oom.git] / docs / oom_quickstart_guide.rst
index c556dfa..79a3056 100644 (file)
@@ -1,7 +1,7 @@
 .. This work is licensed under a
 .. Creative Commons Attribution 4.0 International License.
 .. http://creativecommons.org/licenses/by/4.0
-.. Copyright 2019 Amdocs, Bell Canada
+.. Copyright 2019-2020 Amdocs, Bell Canada, Orange, Samsung
 .. _oom_quickstart_guide:
 .. _quick-start-label:
 
@@ -11,7 +11,7 @@ OOM Quick Start Guide
 .. figure:: oomLogoV2-medium.png
    :align: right
 
-Once a kubernetes environment is available (follow the instructions in
+Once a Kubernetes environment is available (follow the instructions in
 :ref:`cloud-setup-guide-label` if you don't have a cloud environment
 available), follow the following instructions to deploy ONAP.
 
@@ -20,41 +20,65 @@ available), follow the following instructions to deploy ONAP.
   > git clone -b <BRANCH> http://gerrit.onap.org/r/oom --recurse-submodules
   > cd oom/kubernetes
 
-where <BRANCH> can be an offical release tag, such as
-4.0.0-ONAP for Dublin
-5.0.1-ONAP for El Alto
-6.0.0-ONAP for Frankfurt
+where <BRANCH> can be an official release tag, such as
+
+* 4.0.0-ONAP for Dublin
+* 5.0.1-ONAP for El Alto
+* 6.0.0 for Frankfurt
+* 7.0.0 for Guilin
+* 8.0.0 for Honolulu
+* 9.0.0 for Istanbul
+* 10.0.0 for Jakarta
 
 **Step 2.** Install Helm Plugins required to deploy ONAP::
 
-  > sudo cp -R ~/oom/kubernetes/helm/plugins/ ~/.helm
+  > cp -R ~/oom/kubernetes/helm/plugins/ ~/.local/share/helm/plugins
+  > helm plugin install https://github.com/chartmuseum/helm-push.git \
+      --version 0.9.0
+
+.. note::
+  The ``--version 0.9.0`` is required as new version of helm (3.7.0 and up) is
+  now using ``push`` directly and helm-push is using ``cm-push`` starting
+  version ``0.10.0`` and up.
+
+**Step 3.** Install Chartmuseum::
+
+  > curl -LO https://s3.amazonaws.com/chartmuseum/release/latest/bin/linux/amd64/chartmuseum
+  > chmod +x ./chartmuseum
+  > mv ./chartmuseum /usr/local/bin
 
+**Step 4.** Install Cert-Manager::
 
-**Step 3.** Customize the helm charts like `oom/kubernetes/onap/values.yaml` or an override
-file like `onap-all.yaml`, `onap-vfw.yaml` or `openstack.yaml` file to suit your deployment
-with items like the OpenStack tenant information.
+  > kubectl apply -f https://github.com/jetstack/cert-manager/releases/download/v1.2.0/cert-manager.yaml
+
+More details can be found :doc:`here <oom_setup_paas>`.
+
+**Step 5.** Customize the Helm charts like `oom/kubernetes/onap/values.yaml` or
+an override file like `onap-all.yaml`, `onap-vfw.yaml` or `openstack.yaml` file
+to suit your deployment with items like the OpenStack tenant information.
 
 .. note::
-  Standard and example override files (e.g. `onap-all.yaml`, `openstack.yaml`) can be found in
-  the `oom/kubernetes/onap/resources/overrides/` directory.
+  Standard and example override files (e.g. `onap-all.yaml`, `openstack.yaml`)
+  can be found in the `oom/kubernetes/onap/resources/overrides/` directory.
 
 
  a. You may want to selectively enable or disable ONAP components by changing
     the ``enabled: true/false`` flags.
 
 
- b. Encrypt the OpenStack password using the shell tool for robot and put it in
-    the robot helm charts or robot section of `openstack.yaml`
+ b. Encrypt the OpenStack password using the shell tool for Robot and put it in
+    the Robot Helm charts or Robot section of `openstack.yaml`
 
 
- c. Encrypt the OpenStack password using the java based script for SO helm charts
-    or SO section of `openstack.yaml`.
+ c. Encrypt the OpenStack password using the java based script for SO Helm
+    charts or SO section of `openstack.yaml`.
 
 
- d. Update the OpenStack parameters that will be used by robot, SO and APPC helm
+ d. Update the OpenStack parameters that will be used by Robot, SO and APPC Helm
     charts or use an override file to replace them.
 
- e. Add in the command line a value for the global master password (global.masterPassword).
+ e. Add in the command line a value for the global master password
+    (global.masterPassword).
 
 
 
@@ -67,11 +91,11 @@ We have different values file available for different contexts.
 
 
 b. Generating ROBOT Encrypted Password:
-The ROBOT encrypted Password uses the same encryption.key as SO but an
+The Robot encrypted Password uses the same encryption.key as SO but an
 openssl algorithm that works with the python based Robot Framework.
 
 .. note::
-  To generate ROBOT ``openStackEncryptedPasswordHere``::
+  To generate Robot ``openStackEncryptedPasswordHere``::
 
     cd so/resources/config/mso/
     /oom/kubernetes/so/resources/config/mso# echo -n "<openstack tenant password>" | openssl aes-128-ecb -e -K `cat encryption.key` -nosalt | xxd -c 256 -p``
@@ -79,7 +103,7 @@ openssl algorithm that works with the python based Robot Framework.
 c. Generating SO Encrypted Password:
 The SO Encrypted Password uses a java based encryption utility since the
 Java encryption library is not easy to integrate with openssl/python that
-ROBOT uses in Dublin and upper versions.
+Robot uses in Dublin and upper versions.
 
 .. note::
   To generate SO ``openStackEncryptedPasswordHere`` and ``openStackSoEncryptedPassword``
@@ -100,32 +124,33 @@ ROBOT uses in Dublin and upper versions.
 
 d. Update the OpenStack parameters:
 
-There are assumptions in the demonstration VNF heat templates about the networking
-available in the environment. To get the most value out of these templates and the
-automation that can help confirm the setup is correct, please observe the following
-constraints.
+There are assumptions in the demonstration VNF Heat templates about the
+networking available in the environment. To get the most value out of these
+templates and the automation that can help confirm the setup is correct, please
+observe the following constraints.
 
 
 ``openStackPublicNetId:``
-  This network should allow heat templates to add interfaces.
-  This need not be an external network, floating IPs can be assigned to the ports on
-  the VMs that are created by the heat template but its important that neutron allow
-  ports to be created on them.
+  This network should allow Heat templates to add interfaces.
+  This need not be an external network, floating IPs can be assigned to the
+  ports on the VMs that are created by the heat template but its important that
+  neutron allow ports to be created on them.
 
 ``openStackPrivateNetCidr: "10.0.0.0/16"``
-  This ip address block is used to assign OA&M addresses on VNFs to allow ONAP connectivity.
-  The demonstration heat templates assume that 10.0 prefix can be used by the VNFs and the
-  demonstration ip addressing plan embodied in the preload template prevent conflicts when
-  instantiating the various VNFs. If you need to change this, you will need to modify the preload
-  data in the robot helm chart like integration_preload_parametes.py and the demo/heat/preload_data
-  in the robot container. The size of the CIDR should be sufficient for ONAP and the VMs you expect
-  to create.
+  This ip address block is used to assign OA&M addresses on VNFs to allow ONAP
+  connectivity. The demonstration Heat templates assume that 10.0 prefix can be
+  used by the VNFs and the demonstration ip addressing plan embodied in the
+  preload template prevent conflicts when instantiating the various VNFs. If
+  you need to change this, you will need to modify the preload data in the
+  Robot Helm chart like integration_preload_parameters.py and the
+  demo/heat/preload_data in the Robot container. The size of the CIDR should
+  be sufficient for ONAP and the VMs you expect to create.
 
 ``openStackOamNetworkCidrPrefix: "10.0"``
-  This ip prefix mush match the openStackPrivateNetCidr and is a helper variable to some of the
-  robot scripts for demonstration. A production deployment need not worry about this
-  setting but for the demonstration VNFs the ip asssignment strategy assumes 10.0 ip prefix.
-
+  This ip prefix mush match the openStackPrivateNetCidr and is a helper
+  variable to some of the Robot scripts for demonstration. A production
+  deployment need not worry about this setting but for the demonstration VNFs
+  the ip asssignment strategy assumes 10.0 ip prefix.
 
 Example Keystone v2.0
 
@@ -138,41 +163,49 @@ Example Keystone v3  (required for Rocky and later releases)
    :language: yaml
 
 
-**Step 4.** To setup a local Helm server to server up the ONAP charts::
+**Step 6.** To setup a local Helm server to server up the ONAP charts::
 
-  > helm serve &
+  > chartmuseum --storage local --storage-local-rootdir ~/helm3-storage -port 8879 &
 
 Note the port number that is listed and use it in the Helm repo add as
 follows::
 
   > helm repo add local http://127.0.0.1:8879
 
-**Step 5.** Verify your Helm repository setup with::
+**Step 7.** Verify your Helm repository setup with::
 
   > helm repo list
   NAME   URL
   local  http://127.0.0.1:8879
 
-**Step 6.** Build a local Helm repository (from the kubernetes directory)::
+**Step 8.** Build a local Helm repository (from the kubernetes directory)::
+
+  > make SKIP_LINT=TRUE [HELM_BIN=<HELM_PATH>] all ; make SKIP_LINT=TRUE [HELM_BIN=<HELM_PATH>] onap
+
+`HELM_BIN`
+  Sets the helm binary to be used. The default value use helm from PATH
 
-  > make SKIP_LINT=TRUE all; make SKIP_LINT=TRUE onap
 
-**Step 7.** Display the onap charts that available to be deployed::
+**Step 9.** Display the onap charts that available to be deployed::
 
-  > helm search onap -l
+  > helm repo update
+  > helm search repo onap
 
 .. literalinclude:: helm-search.txt
 
 .. note::
-  The setup of the Helm repository is a one time activity. If you make changes to your deployment charts or values be sure to use ``make`` to update your local Helm repository.
+  The setup of the Helm repository is a one time activity. If you make changes
+  to your deployment charts or values be sure to use ``make`` to update your
+  local Helm repository.
 
-**Step 8.** Once the repo is setup, installation of ONAP can be done with a
+**Step 10.** Once the repo is setup, installation of ONAP can be done with a
 single command
 
 .. note::
-  The ``--timeout 900`` is currently required in Dublin and up to address long
-  running initialization tasks for DMaaP and SO. Without this timeout value both
-  applications may fail to deploy.
+  The ``--timeout 900s`` is currently required in Dublin and later
+  versions up to address long running initialization tasks for DMaaP
+  and SO. Without this timeout value both applications may fail to
+  deploy.
 
 .. danger::
   We've added the master password on the command line.
@@ -186,40 +219,53 @@ single command
 To deploy all ONAP applications use this command::
 
     > cd oom/kubernetes
-    >  helm deploy dev local/onap --namespace onap --set global.masterPassword=myAwesomePasswordThatINeedToChange -f onap/resources/overrides/onap-all.yaml -f onap/resources/overrides/environment.yaml -f onap/resources/overrides/openstack.yaml --timeout 900
+    >  helm deploy dev local/onap --namespace onap --create-namespace --set global.masterPassword=myAwesomePasswordThatINeedToChange -f onap/resources/overrides/onap-all.yaml -f onap/resources/overrides/environment.yaml -f onap/resources/overrides/openstack.yaml --timeout 900s
 
-All override files may be customized (or replaced by other overrides) as per needs.
+All override files may be customized (or replaced by other overrides) as per
+needs.
 
 `onap-all.yaml`
-  Enables the modules in the ONAP deployment. As ONAP is very modular, it is possible to customize ONAP and disable some components through this configuration file.
+  Enables the modules in the ONAP deployment. As ONAP is very modular, it is
+  possible to customize ONAP and disable some components through this
+  configuration file.
 
 `onap-all-ingress-nginx-vhost.yaml`
-  Alternative version of the `onap-all.yaml` but with global ingress controller enabled. It requires the cluster configured with the nginx ingress controller and load balancer.
-  Please use this file instad `onap-all.yaml` if you want to use experimental ingress controller feature.
+  Alternative version of the `onap-all.yaml` but with global ingress controller
+  enabled. It requires the cluster configured with the nginx ingress controller
+  and load balancer. Please use this file instead `onap-all.yaml` if you want
+  to use experimental ingress controller feature.
 
 `environment.yaml`
   Includes configuration values specific to the deployment environment.
 
-  Example: adapt readiness and liveness timers to the level of performance of your infrastructure
+  Example: adapt readiness and liveness timers to the level of performance of
+  your infrastructure
 
 `openstack.yaml`
-  Includes all the Openstack related information for the default target tenant you want to use to deploy VNFs from ONAP and/or additional parameters for the embedded tests.
+  Includes all the OpenStack related information for the default target tenant
+  you want to use to deploy VNFs from ONAP and/or additional parameters for the
+  embedded tests.
 
-**Step 9.** Verify ONAP installation
+**Step 11.** Verify ONAP installation
 
-Use the following to monitor your deployment and determine when ONAP is ready for use::
+Use the following to monitor your deployment and determine when ONAP is ready
+for use::
 
   > kubectl get pods -n onap -o=wide
 
 .. note::
-  While all pods may be in a Running state, it is not a guarantee that all components are running fine.
+  While all pods may be in a Running state, it is not a guarantee that all
+  components are running fine.
 
-  Launch the healthcheck tests using Robot to verify that the components are healthy::
+  Launch the healthcheck tests using Robot to verify that the components are
+  healthy::
 
     > ~/oom/kubernetes/robot/ete-k8s.sh onap health
 
-**Step 10.** Undeploy ONAP::
+**Step 12.** Undeploy ONAP
+::
 
-  > helm undeploy dev --purge
+  > helm undeploy dev
 
-More examples of using the deploy and undeploy plugins can be found here: https://wiki.onap.org/display/DW/OOM+Helm+%28un%29Deploy+plugins
+More examples of using the deploy and undeploy plugins can be found here:
+https://wiki.onap.org/display/DW/OOM+Helm+%28un%29Deploy+plugins