Merge "docs: Ensure literal block rendering"
[oom.git] / docs / oom_quickstart_guide.rst
index 501deda..bd5e3ee 100644 (file)
@@ -30,7 +30,7 @@ file like onap-all.yaml, onap-vfw.yaml or openstack.yaml file to suit your deplo
 OpenStack tenant information.
 
 .. note::
-  Standard and example override files (e.g. onap-all.yaml, openstack.yaml) can be found in 
+  Standard and example override files (e.g. onap-all.yaml, openstack.yaml) can be found in
   the oom/kubernetes/onap/resources/overrides/ directory.
 
 
@@ -77,22 +77,65 @@ Java encryption library is not easy to integrate with openssl/python that
 ROBOT uses in Dublin.
 
 .. note::
-  To generate SO openStackEncryptedPasswordHere :
+  To generate SO openStackEncryptedPasswordHere and openStackSoEncryptedPassword:
+
+  SO_ENCRYPTION_KEY=`cat ~/oom/kubernetes/so/resources/config/mso/encryption.key`
 
-  SO_ENCRYPTION_KEY=`cat ~/oom/kubenertes/so/resources/config/mso/encrypt.key`
   OS_PASSWORD=XXXX_OS_CLEARTESTPASSWORD_XXXX
 
   git clone http://gerrit.onap.org/r/integration
-  cd integration/deployment/heat/onap-oom/scripts
+
+  cd integration/deployment/heat/onap-rke/scripts
+
+
   javac Crypto.java
+
+  [ if javac is not installed 'apt-get update ; apt-get install default-jdk' ]
+
   java Crypto "$OS_PASSWORD" "$SO_ENCRYPTION_KEY"
 
 
 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.
+
+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.
+
+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.
+
+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.
+
+
+Example Keystone v2.0 
 .. literalinclude:: example-integration-override.yaml
    :language: yaml
 
+Example Keystone v3  (required for Rocky and later releases)
+.. literalinclude:: example-integration-override-v3.yaml
+   :language: yaml
+
+
+
 **Step 4.** To setup a local Helm server to server up the ONAP charts::
 
   > helm serve &
@@ -128,32 +171,42 @@ single command
   The --timeout 900 is currently required in Dublin to address long running initialization tasks
   for DMaaP and SO. Without this timeout value both applications may fail to deploy.
 
- a. To deploy all ONAP applications use this command::
+To deploy all ONAP applications use this command::
 
     > cd oom/kubernetes
-    > helm deploy dev local/onap --namespace onap -f onap/resources/overrides/onap-all.yaml -f onap/resources/overrides/openstack.yaml --timeout 900
+    > helm deploy dev local/onap --namespace onap -f onap/resources/overrides/onap-all.yaml -f onap/resources/overrides/environment.yaml -f onap/resources/overrides/openstack.yaml --timeout 900
 
- b. If you are using a custom override (e.g. integration-override.yaml) use this command::
+All override files may be customized (or replaced by other overrides) as per needs.
 
-    > helm deploy dev local/onap -f /root/integration-override.yaml --namespace onap --timeout 900
+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.
 
- c. If you have a slower cloud environment you may want to use the public-cloud.yaml
-    which has longer delay intervals on database updates.::
+environment.yaml
 
-    > helm deploy dev local/onap -f /root/oom/kubernetes/onap/resources/environments/public-cloud.yaml -f /root/integration-override.yaml --namespace onap --timeout 900
+  Includes configuration values specific to the deployment environment.
 
+  Example: adapt readiness and liveness timers to the level of performance of your infrastructure
 
-**Step 9.** Commands to interact with the OOM installation
+openstack.yaml
 
-Use the following to monitor your deployment and determine when ONAP is
-ready for use::
+  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::
 
   > kubectl get pods -n onap -o=wide
 
-Undeploying onap can be done using the following command::
+.. note::
+  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.
+
+  > ~/oom/kubernetes/robot/ete-k8s.sh onap health
 
-  > helm undeploy dev --purge
+**Step 10.** Undeploy ONAP
 
+> helm undeploy dev --purge
 
 More examples of using the deploy and undeploy plugins can be found here: https://wiki.onap.org/display/DW/OOM+Helm+%28un%29Deploy+plugins