path: root/docs
diff options
authorPanagiotis Karalis <pkaralis@intracom-telecom.com>2019-04-05 19:29:50 +0300
committerPanagiotis Karalis <pkaralis@intracom-telecom.com>2019-05-10 14:02:04 +0300
commitb5c8c8e7a782099cc9f0c53324ae16f321203e16 (patch)
treec1360f04a852dcce83a468cbced7fc282e262716 /docs
parent6369a784f56c30b66c9aa79c251d06780fc4811d (diff)
Allow TCs to consume config info from user's file
The SFC TCs are bound by the installers. This means that the SFC TCs could not run on server or VM which all components (e.g. OS, ODL, etc) are deployed manually and not by an installer, because some information are retrieved directly from installer through deploy factory module. A new yaml file is created by user in order for the important information to be consumed by the respective test scenario during test execution. JIRA: SFC-142 Change-Id: I051bb6406b8aa433c19e4df10396b4789448d42b Signed-off-by: Panagiotis Karalis <pkaralis@intracom-telecom.com>
Diffstat (limited to 'docs')
1 files changed, 11 insertions, 0 deletions
diff --git a/docs/release/userguide/feature.userguide.rst b/docs/release/userguide/feature.userguide.rst
index 0e9ce2c..050a0c8 100644
--- a/docs/release/userguide/feature.userguide.rst
+++ b/docs/release/userguide/feature.userguide.rst
@@ -36,6 +36,17 @@ SFC capabilities and usage
The OPNFV SFC feature can be deployed with either the "os-odl-sfc-ha" or the
"os-odl-sfc-noha" scenario. SFC usage for both of these scenarios is the same.
+Once the deployment has been completed, the SFC test cases use information
+(e.g. INSTALLER IP, Controller IP, etc) of the environment which have been
+retrieved first from the installer in order to execute the SFC test cases properly.
+This is the default behavior.
+In case there is not an installer in place and the server for the SFC test execution
+has been prepared manually, installing all necessary components (e.g. OpenStack OpenDayLight etc)
+by hand. The user should update the "pod.yaml" file, including the all necessary details
+for each node which participates in the scenario.
+In case the dovetail project triggers the SFC test scenarios, the "pod.yaml" file will be prepared
+by dovetail project automatically.
As previously mentioned, Tacker is used as a VNF Manager and SFC Orchestrator. All
the configuration necessary to create working service chains and classifiers can
be performed using the Tacker command line. Refer to the `Tacker walkthrough <https://github.com/trozet/sfc-random/blob/master/tacker_sfc_apex_walkthrough.txt>`_