.. 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:
.. 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.
> 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
+where <BRANCH> can be an official release tag, such as
* 4.0.0-ONAP for Dublin
* 5.0.1-ONAP for El Alto
> sudo cp -R ~/oom/kubernetes/helm/plugins/ ~/.helm
-**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.
+**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.
.. note::
Standard and example override files (e.g. `onap-all.yaml`, `openstack.yaml`) can be found in
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
+ 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).
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``
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``
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
.. 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
single 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
-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
-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
> ~/oom/kubernetes/robot/ete-k8s.sh onap health
-**Step 10.** Undeploy ONAP::
+**Step 10.** Undeploy ONAP
+::
> helm undeploy dev --purge
Code Review / oom.git / blobdiff