From 4e457425203cd42635eeea0bde044abf8b119946 Mon Sep 17 00:00:00 2001
From: dfarrelly <david.farrelly@est.tech>
Date: Thu, 2 Apr 2020 08:59:17 +0100
Subject: [PMSH] Update PMSH Frankfurt docs

Issue-ID: DCAEGEN2-1820
Signed-off-by: dfarrelly <david.farrelly@est.tech>
Change-Id: I0ef088ae7f6a97ab101a7097e6ea9bf81424c343
---
 .../pm-subscription-handler/installation.rst       | 54 +++++++++++++++++++---
 1 file changed, 48 insertions(+), 6 deletions(-)

(limited to 'docs/sections/services/pm-subscription-handler/installation.rst')

diff --git a/docs/sections/services/pm-subscription-handler/installation.rst b/docs/sections/services/pm-subscription-handler/installation.rst
index 49da2ea9..3865cfbd 100644
--- a/docs/sections/services/pm-subscription-handler/installation.rst
+++ b/docs/sections/services/pm-subscription-handler/installation.rst
@@ -6,18 +6,60 @@
 Installation
 ============
 
-The PMSH will be configured and instantiated through CLAMP. During instantiation, the PMSH will fetch its configuration
-from the Config Binding Service.
+Due to a bug in the Frankfurt release, the PMSH cannot be deployed through CLAMP. The PMSH can instead be deployed
+using the DCAE Dashboard or via CLI. Steps to deploy using CLI will be shown below.
 
 Deployment Prerequisites
 ^^^^^^^^^^^^^^^^^^^^^^^^
 
-In order to succesfully deploy the PMSH, the following components are required to be running. They
-can be verified by running the healtchecks.
+In order to successfully deploy the PMSH, one will need administrator access to the kubernetes cluster, as a service
+will need to be exposed. As well as this, the following components are required to be running. They can be verified by
+running the health checks.
 
     - DCAE Platform
     - DMaaP
-    - SDC
-    - CLAMP
     - A&AI
     - AAF
+
+The healthcheck can be run from one of the Kubernetes controllers.
+
+.. code-block:: bash
+
+        ./oom/kubernetes/robot/ete-k8s.sh onap health
+
+Deployment Procedure
+^^^^^^^^^^^^^^^^^^^^
+
+To deploy the PMSH in the Frankfurt release, the monitoring policy needs to be pushed directly to CONSUL. The CONSUL
+service must first be exposed.
+
+.. code-block:: bash
+
+        kubectl expose svc -n onap consul-server-ui --name=x-consul-server-ui --type=NodePort
+
+The monitoring policy can then be pushed with the following request, for information on creating a monitoring policy see
+See :ref:`Subscription configuration<Subscription>`
+
+.. code-block:: bash
+
+        curl -X PUT http://<k8s-node-ip>:<consul-port>/v1/kv/dcae-pmsh:policy \
+            -H 'Content-Type: application/json' \
+            -d @monitoring-policy.json
+
+To deploy the PMSH microservice using the deployment handler API, the ``serviceTypeId`` is needed, this can be retrieved
+using the inventory API
+
+.. code-block:: bash
+
+        curl https://<k8s-node-ip>:<inventory-port>/dcae-service-types
+
+The ``serviceTypeId`` for the PMSH can be found under typeID. The PMSH can then be deployed.
+
+.. code-block:: bash
+
+        curl https://<k8s-node-ip>:<dep-handler-port>/dcae-deployments/dcae-pmsh \
+            -H 'Content-Type: application/json' \
+            -d '{
+                "inputs": (),
+                "serviceTypeId": "<typeId>"
+            }'
-- 
cgit 1.2.3-korg