Add NF addressing method as ENV.
[sim/o1-interface.git] / docs / overview.rst
index d478ca5..c389809 100644 (file)
@@ -340,6 +340,8 @@ The network function can run in standalone mode when the **NTS_NF_STANDALONE_STA
 
 Other than this, the network-function will operate just as it would when started by the manager and it can be controller through the **nts-network-function.yang** interface.
 
+The default mount point addressing method is "docker-mapping". However this behaviour can be changed by setting the  **NTS_NF_MOUNT_POINT_ADDRESSING_METHOD** enviroment variable to "host-mapping". When "host-mapping" is chosen, all the host ports must be fowareded from Docker by the user when running the network function, and **NTS_HOST_IP** and **NTS_HOST_xxxx_PORT** enviroment variables should be set for the network function to know how to perform its tasks.
+
 Datastore random population
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
@@ -429,15 +431,16 @@ Fault generation is controlled using a combination of JSON and YANG settings. Fr
         ]
     }
 
-    * **fault-rules** node should be a main node in *config.json* for the respective network function in order for the fault generation to be enabled
-    * **yang-notif-template** - template of the yang notification model in current network function. can be "" to disable notifications. must always be present
-    * **choosing-method** - method to choose the fault. can be either *linear* or *random*, and must always be present
-    * **faults** list of faults to choose from by "choosing-method". it can contain any number of fields, custom ones, along with the mandatory VES fields presented below:
-        * **condition**
-        * **object**
-        * **severity** - should correspond to VES defined: NORMAL, WARNING, MINOR, MAJOR, CRITICAL (case sensitive)
-        * **date-time**
-        * **specific-problem**
+- **fault-rules** node should be a main node in *config.json* for the respective network function in order for the fault generation to be enabled
+- **yang-notif-template** - template of the yang notification model in current network function. can be "" to disable notifications. must always be present
+- **choosing-method** - method to choose the fault. can be either *linear* or *random*, and must always be present
+- **faults** list of faults to choose from by "choosing-method". it can contain any number of fields, custom ones, along with the mandatory VES fields presented below:
+
+    - **condition**
+    - **object**
+    - **severity** - should correspond to VES defined: NORMAL, WARNING, MINOR, MAJOR, CRITICAL (case sensitive)
+    - **date-time**
+    - **specific-problem**
 
 On the **yang-notif-template** and on any of the fields, there are two options for creating "dynamic" content (also see example above):
 - **variables** - any field put in between %% will be replaced with the field's value
@@ -496,6 +499,7 @@ Below all the available enviroment variables are listed. Please note that if a v
 - **NTS_BUILD_VERSION** - defines build version, set by Dockerfile
 - **NTS_BUILD_DATE** - defines build date, set by Dockerfile
 - **NTS_NF_STANDALONE_START_FEATURES** - when value is not blank, it allows the network function to run in standalone mode; see "Network function standalone mode" sub-chapter for this
+- **NTS_NF_MOUNT_POINT_ADDRESSING_METHOD** - either "docker-mapping" or "host-mapping"; available only when running in network function STANDALONE MODE
 
 - **DOCKER_ENGINE_VERSION** - Docker engine version, defaults to 1.40 if not set
 - **HOSTNAME** - Container hostname