Standard defined schema files in VES Collector

Add overall description how to configure
standard defined schema files in VES Collector

Issue-ID: INT-1922
Signed-off-by: Krzysztof Kuzmicki <krzysztof.kuzmicki@nokia.com>
Change-Id: I4e5d7528b8c5b61c3114777afb3a8e48a2671e53

2 files changed, 99 insertions, 2 deletions

diff --git a/docs/docs_StndDefined_Events_Collection_Mechanism.rst b/docs/docs_StndDefined_Events_Collection_Mechanism.rst
new file mode 100644
index 000000000..fd20271ae
--- /dev/null
+++ b/docs/docs_StndDefined_Events_Collection_Mechanism.rst
@@ -0,0 +1,97 @@
+.. This work is licensed under a Creative Commons Attribution 4.0
+   International License. http://creativecommons.org/licenses/by/4.0
+
+.. _docs_StndDefined_Events_Collection_Mechanism:
+
+:orphan:
+
+VES Collector - Standard Defined Events Collection Mechanism
+------------------------------------------------------------
+
+Description
+~~~~~~~~~~~
+
+The target of standard defined events collection mechanism development was to allow collection of events defined by standards organizations using VES Collector,
+and providing them for consumption by analytics applications running on top of DCAE platform. The following features have been implemented:
+
+1. Event routing, based on a new CommonHeader field “stndDefinedNamespace”
+2. Standards-organization defined events can be included using a dedicated stndDefinedFields.data property
+3. Standards-defined events can be validated using openAPI descriptions provided by standards organizations, and indicated in stndDefinedFields.schemaReference
+
+`Standard Defined Events Collection Mechanism description <https://docs.onap.org/projects/onap-dcaegen2/en/honolulu/sections/services/ves-http/stnd-defined-validation.html>`_
+
+.. note::
+
+   VES Collector orchestrated using Helm or Cloudify uses standard defined domain schema files bundled within VES collector image during image build.
+   Also new Helm based installation mechanism for collectors doesn't support yet certain features available with the traditional Cloudify orchestration based mechanisms:
+      - Obtaining X.509 certificates from external CMP v2 server for secure xNF connections
+      - Exposing the Collector port in Dual Stack IPv4/IPv6 networks.
+
+
+How to Configure VES Collector
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+By default config maps containing schema files are defined in the `OOM <https://gerrit.onap.org/r/gitweb?p=oom.git;a=tree;f=kubernetes/dcaegen2/resources/external>`_ repository and installed with dcaegen2 module.
+In Honolulu release in OOM are used schema files from https://forge.3gpp.org/rep/sa5/MnS/blob/SA88-Rel16/OpenAPI/.
+The newest schema files can be found in https://forge.3gpp.org/rep/sa5/MnS/tree/Rel-16-SA-91/OpenAPI
+If for production/test purpose are required different or newest schema files please follow procedure for `config map update <https://docs.onap.org/projects/onap-dcaegen2/en/latest/sections/configuration.html#config-maps>`_.
+
+In order to prepare second instance of VES Collector please follow below procedure:
+
+1. (Optional step) If VES Collector should obtaining X.509 certificates from CMP v2 server for secure xNF connections please follow below steps:
+
+   - Install `Cert Manager <https://docs.onap.org/projects/onap-oom/en/latest/oom_setup_paas.html#cert-manager>`_
+   - Configure `Cert Service <https://docs.onap.org/projects/onap-oom-platform-cert-service/en/honolulu/sections/configuration.html>`_ if external CMP v2 server is in use.
+
+2. If usage of config maps from OOM containing schema files is required please follow procedure for
+   `external repo schema files from OOM connection to VES collector <https://docs.onap.org/projects/onap-dcaegen2/en/honolulu/sections/services/ves-http/installation.html#external-repo-schema-files-from-oom-connection-to-ves-collector>`_
+   with changes described below.
+
+   As new instance of VES Collector will be introduced to ONAP namespace there is need to modify parameters from ``/inputs/k8s-ves-inputs-tls.yaml`` in Bootstrap POD
+
+   - external_port - set here ``node port`` from range ``30000-32767`` not used in ONAP instance
+   - ``service_component_type``, ``service_id``, ``service_component_name_override`` - set here custom service name e.g. ``dcae-ves-collector-std-def-evnents``
+
+   (Optional step) If VES Collector should also obtaining X.509 certificates from CMP v2 and its clients should successfully validate its hostname then following parameters need to modified in ``/inputs/k8s-ves-inputs-tls.yaml`` file.
+
+   - ``external_cert_use_external_tls`` - change from ``false`` to ``true``
+   - ``external_cert_common_name`` - set same value as used in ``service_component_name_override parameter``
+   - ``service_component_name_override`` - add following values:
+      - all IPv4 addresses of ONAP worker hosts
+      - all IPv6 addresses of ONAP worker hosts
+      - all FQDN names of ONAP worker hosts
+      - ``service_component_name_override`` parameter value.
+
+   Deploy new instance of VES collector using ``/inputs/k8s-ves-inputs-tls.yaml``
+
+3. (Optional step) If ONAP is installed in Dual Stack and VES Collector should listen in IPv6 network
+
+   - on RKE node prepare file ``ves-ipv6.yaml`` with following content (an example for ``dcae-ves-collector-std-def-evnents`` service name and node port set to ``30519`` )
+       .. code-block:: bash
+
+         apiVersion: v1
+         kind: Service
+         metadata:
+           name: xdcae-ves-collector-std-def-evnents
+           namespace: onap
+         spec:
+           externalTrafficPolicy: Cluster
+           ipFamily: IPv6
+           ports:
+           - name: xdcae-ves-collector-std-def-evnents
+             nodePort: 30519
+             port: 8443
+             protocol: TCP
+             targetPort: 8443
+           selector:
+             app: dcae-ves-collector-std-def-evnents
+           sessionAffinity: None
+           type: NodePort
+
+   - apply prepared service and check if it working
+       .. code-block:: bash
+
+         kubectl -n onap apply -f ves-ipv6.yaml
+
+         kubectl -n onap get svc | grep collector-std-def-evnents
+         xdcae-ves-collector-std-def-evnents                        NodePort       fd00:101::6ad    <none>                                 8443:30519/TCP                                           28h
\ No newline at end of file
diff --git a/docs/files/csv/usecases-functional-requirements.csv b/docs/files/csv/usecases-functional-requirements.csv
index 908db9578..947187d79 100644
--- a/docs/files/csv/usecases-functional-requirements.csv
+++ b/docs/files/csv/usecases-functional-requirements.csv
@@ -3,7 +3,7 @@ REQ-463;ONAP to support Multi Tenancy (part 2);Olivier Phénix ;
 REQ-457;Extend ORAN A1 Adapter and add A1 Policy Management;John Keeney;
 REQ-458;ONAP CNF orchestration - Enhancements;Lukasz Rajewski;Changes of this feature are described in :ref:`vFW CNF use case <docs_vFW_CNF_CDS>`
 REQ-446;NF Software Upgrade enhancement;Zu Qiang;
-REQ-433;ONAP/3GPP & O-RAN Alignment-Standards Defined Notifications over VES (Honolulu);Damian Nowak;
-REQ-432;IPv4/IPv6 dual stack support in ONAP (Honolulu);Damian Nowak,
+REQ-433;ONAP/3GPP & O-RAN Alignment-Standards Defined Notifications over VES (Honolulu);Damian Nowak;Description how to configure :ref:`Standards Defined Notifications in VES <docs_StndDefined_Events_Collection_Mechanism>`
+REQ-432;IPv4/IPv6 dual stack support in ONAP (Honolulu);Damian Nowak;
 REQ-431;CMPv2 Enhancements for R7;Pawel Baniewski;cmpv2 automated test integrated in CI/CD, see :ref:`automated test page <release_automated_usecases>`
 REQ-400;ETSI-Alignment for Guilin and Honolulu;Byung-Woo Jun;