From 6fb970627653a5ae6293db6ef36b5a836e98769d Mon Sep 17 00:00:00 2001 From: Alexandru Avadanii Date: Sun, 10 Sep 2017 01:11:23 +0200 Subject: Add & fix licensing in README.rst files, align ext Rename all variations of README files to README.rst. Fix license headers according to OPNFV Contribution Guidelines [1]. Markdown syntax will be switched to rst in an ulterior change. [1] https://wiki.opnfv.org/display/DEV/Contribution+Guidelines Change-Id: I2c71fd62b38f218545507c79c39e07dbd35f7c88 Signed-off-by: Alexandru Avadanii --- README | 10 ---- README.rst | 3 ++ ci/README | 100 ------------------------------------ ci/README.rst | 94 ++++++++++++++++++++++++++++++++++ mcp/config/scenario/README.md | 22 -------- mcp/config/scenario/README.rst | 21 ++++++++ mcp/patches/README.md | 103 ------------------------------------- mcp/patches/README.rst | 107 +++++++++++++++++++++++++++++++++++++++ prototypes/sfc_tacker/README | 54 -------------------- prototypes/sfc_tacker/README.rst | 49 ++++++++++++++++++ 10 files changed, 274 insertions(+), 289 deletions(-) delete mode 100644 README create mode 100644 README.rst delete mode 100644 ci/README create mode 100644 ci/README.rst delete mode 100644 mcp/config/scenario/README.md create mode 100644 mcp/config/scenario/README.rst delete mode 100644 mcp/patches/README.md create mode 100644 mcp/patches/README.rst delete mode 100644 prototypes/sfc_tacker/README create mode 100644 prototypes/sfc_tacker/README.rst diff --git a/README b/README deleted file mode 100644 index 4629763a3..000000000 --- a/README +++ /dev/null @@ -1,10 +0,0 @@ -############################################################################## -# Copyright (c) 2015 Ericsson AB and others. -# stefan.k.berg@ericsson.com -# jonas.bjurel@ericsson.com -# All rights reserved. This program and the accompanying materials -# are made available under the terms of the Apache License, Version 2.0 -# which accompanies this distribution, and is available at -# http://www.apache.org/licenses/LICENSE-2.0 -############################################################################## - diff --git a/README.rst b/README.rst new file mode 100644 index 000000000..e1b9201aa --- /dev/null +++ b/README.rst @@ -0,0 +1,3 @@ +.. This work is licensed under a Creative Commons Attribution 4.0 International License. +.. SPDX-License-Identifier: CC-BY-4.0 +.. (c) 2017 Ericsson AB, Mirantis Inc., Enea AB and others. diff --git a/ci/README b/ci/README deleted file mode 100644 index 898442559..000000000 --- a/ci/README +++ /dev/null @@ -1,100 +0,0 @@ -############################################################################## -# Copyright (c) 2017 Ericsson AB, Mirantis Inc., Enea Software AB and others. -# stefan.k.berg@ericsson.com -# jonas.bjurel@ericsson.com -# All rights reserved. This program and the accompanying materials -# are made available under the terms of the Apache License, Version 2.0 -# which accompanies this distribution, and is available at -# http://www.apache.org/licenses/LICENSE-2.0 -############################################################################## - -Abstract -======== -The fuel/ci directory holds all Fuel@OPNFV programatic abstractions for -the OPNFV community release and continous integration pipeline. -There is now only one Fuel@OPNFV autonomous script for this, complying to the -OPNFV CI pipeline guideline: - - deploy.sh - -USAGE -===== -For usage information of the CI/CD scripts, please run: -./deploy.sh -h - -Details on the CI/CD deployment framework -========================================= - -Overview and purpose --------------------- -The CI/CD deployment script relies on a configuration structure, providing base -installer configuration (part of fuel repo: mcp/config), per POD specific -configuration (part of a separate classified POD configuration repo: securedlab -and deployment scenario configuration (part of fuel repo: mcp/config/scenario). - -- The base installer configuration resembles the least common denominator of all - HW/POD environment and deployment scenarios. These configurations are - normally carried by the the installer projects in this case (Fuel@OPNFV). -- Per POD specific configuration specifies POD unique parameters, the POD - parameter possible to alter is governed by the Fuel@OPNFV project. -- Deployment scenario configuration - provides a high level, POD/HW environment - independent scenario configuration for a specifiv deployment. It defines what - features shall be deployed - as well needed overrides of the base - installer, POD/HW environment configurations. Objects allowed to override - are governed by the Fuel@OPNFV project. - -Executing a deployment ----------------------- -deploy.sh must be executed locally at the target lab/pod/jumpserver -A configuration structure must be provided - see the section below. -It is straight forward to execute a deployment task - as an example: -$ sudo deploy.sh -b file:///home/jenkins/config \ - -l lf -p pod2 -s os-nosdn-nofeature-ha - --b and -i arguments should be expressed in URI style (eg: file://... -or http://...). The resources can thus be local or remote. - -Configuration repository structure ----------------------------------- -The CI deployment engine relies on a configuration directory/file structure -pointed to by the -b option described above. -Normally this points to the secure classified OPNFV securedlab repo to which -only jenkins and andmins have access to, but you may point to any local or -remote strcture fullfilling the diectory/file structure below. -The reason that this configuration structure needs to be secure/hidden -is that there are security sensitive information in the various configuration -files. - -FIXME: Below information is out of date and should be refreshed after PDF -support is fully implemented. - -A local stripped version of this configuration structure with virtual -deployment configurations also exist under build/config/. -Following configuration directory and file structure should adheare to: - -TOP -! -+---- labs - ! - +---- lab-name-1 - ! ! - ! +---- pod-name-1 - ! ! ! - ! ! +---- fuel - ! ! ! - ! ! +---- config - ! ! ! - ! ! +---- dea-pod-override.yaml - ! ! ! - ! ! +---- dha.yaml - ! ! - ! +---- pod-name-2 - ! ! - ! - +---- lab-name-2 - ! ! - - -Creating a deployment scenario ------------------------------- -Please find deploy/scenario/README for instructions on how to create a new -deployment scenario. diff --git a/ci/README.rst b/ci/README.rst new file mode 100644 index 000000000..9f1230dbd --- /dev/null +++ b/ci/README.rst @@ -0,0 +1,94 @@ +.. This work is licensed under a Creative Commons Attribution 4.0 International License. +.. SPDX-License-Identifier: CC-BY-4.0 +.. (c) 2017 Ericsson AB, Mirantis Inc., Enea Software AB and others. + +Abstract +======== +The fuel/ci directory holds all Fuel@OPNFV programatic abstractions for +the OPNFV community release and continous integration pipeline. +There is now only one Fuel@OPNFV autonomous script for this, complying to the +OPNFV CI pipeline guideline: + - deploy.sh + +USAGE +===== +For usage information of the CI/CD scripts, please run: +./deploy.sh -h + +Details on the CI/CD deployment framework +========================================= + +Overview and purpose +-------------------- +The CI/CD deployment script relies on a configuration structure, providing base +installer configuration (part of fuel repo: mcp/config), per POD specific +configuration (part of a separate classified POD configuration repo: securedlab +and deployment scenario configuration (part of fuel repo: mcp/config/scenario). + +- The base installer configuration resembles the least common denominator of all + HW/POD environment and deployment scenarios. These configurations are + normally carried by the the installer projects in this case (Fuel@OPNFV). +- Per POD specific configuration specifies POD unique parameters, the POD + parameter possible to alter is governed by the Fuel@OPNFV project. +- Deployment scenario configuration - provides a high level, POD/HW environment + independent scenario configuration for a specifiv deployment. It defines what + features shall be deployed - as well needed overrides of the base + installer, POD/HW environment configurations. Objects allowed to override + are governed by the Fuel@OPNFV project. + +Executing a deployment +---------------------- +deploy.sh must be executed locally at the target lab/pod/jumpserver +A configuration structure must be provided - see the section below. +It is straight forward to execute a deployment task - as an example: +$ sudo deploy.sh -b file:///home/jenkins/config \ + -l lf -p pod2 -s os-nosdn-nofeature-ha + +-b and -i arguments should be expressed in URI style (eg: file://... +or http://...). The resources can thus be local or remote. + +Configuration repository structure +---------------------------------- +The CI deployment engine relies on a configuration directory/file structure +pointed to by the -b option described above. +Normally this points to the secure classified OPNFV securedlab repo to which +only jenkins and andmins have access to, but you may point to any local or +remote strcture fullfilling the diectory/file structure below. +The reason that this configuration structure needs to be secure/hidden +is that there are security sensitive information in the various configuration +files. + +FIXME: Below information is out of date and should be refreshed after PDF +support is fully implemented. + +A local stripped version of this configuration structure with virtual +deployment configurations also exist under build/config/. +Following configuration directory and file structure should adheare to: + +TOP +! ++---- labs + ! + +---- lab-name-1 + ! ! + ! +---- pod-name-1 + ! ! ! + ! ! +---- fuel + ! ! ! + ! ! +---- config + ! ! ! + ! ! +---- dea-pod-override.yaml + ! ! ! + ! ! +---- dha.yaml + ! ! + ! +---- pod-name-2 + ! ! + ! + +---- lab-name-2 + ! ! + + +Creating a deployment scenario +------------------------------ +Please find deploy/scenario/README for instructions on how to create a new +deployment scenario. diff --git a/mcp/config/scenario/README.md b/mcp/config/scenario/README.md deleted file mode 100644 index 6ecf05f32..000000000 --- a/mcp/config/scenario/README.md +++ /dev/null @@ -1,22 +0,0 @@ -############################################################################## -# Copyright (c) 2017 Mirantis Inc., Enea AB and others. -# All rights reserved. This program and the accompanying materials -# are made available under the terms of the Apache License, Version 2.0 -# which accompanies this distribution, and is available at -# http://www.apache.org/licenses/LICENSE-2.0 -############################################################################## - -Abstract: ---------- -This directory contains configuration files for different OPNFV deployment -feature scenarios used by Fuel@OPNFV, e.g.: -- High availability configuration; -- Type of SDN controller to be deployed; -- OPNFV collaboration project features to be deployed; -- Provisioning of any other sevices; -- POD configuration (baremetal, virtual); - -NOTES: ------- -This directory is highly likely to change and/or be replaced/complemented -by the new PDF (Pod Descriptor File) info in securedlab OPNFV git repo. diff --git a/mcp/config/scenario/README.rst b/mcp/config/scenario/README.rst new file mode 100644 index 000000000..e0f9848ea --- /dev/null +++ b/mcp/config/scenario/README.rst @@ -0,0 +1,21 @@ +.. This work is licensed under a Creative Commons Attribution 4.0 International License. +.. SPDX-License-Identifier: CC-BY-4.0 +.. (c) 2017 Mirantis Inc., Enea AB and others. + +Fuel@OPNFV Scenario Configuration +================================= + +Abstract: +--------- +This directory contains configuration files for different OPNFV deployment +feature scenarios used by Fuel@OPNFV, e.g.: +- High availability configuration; +- Type of SDN controller to be deployed; +- OPNFV collaboration project features to be deployed; +- Provisioning of any other sevices; +- POD configuration (baremetal, virtual); + +NOTES: +------ +This directory is highly likely to change and/or be replaced/complemented +by the new PDF (Pod Descriptor File) info in securedlab OPNFV git repo. diff --git a/mcp/patches/README.md b/mcp/patches/README.md deleted file mode 100644 index eab4d64e3..000000000 --- a/mcp/patches/README.md +++ /dev/null @@ -1,103 +0,0 @@ -Fuel@OPNFV submodule fetching and patching -========================================== - -This directory holds submodule fetching/patching scripts, intended for -working with upstream Fuel/MCP components (e.g.: reclass-system-salt-model) in -developing/applying OPNFV patches (backports, custom fixes etc.). - -The scripts should be friendly to the following 2 use-cases: - - development work: easily cloning, binding repos to specific commits, - remote tracking, patch development etc.; - - to provide parent build scripts an easy method of tracking upstream - references and applying OPNFV patches on top; - -Also, we need to support at least the following modes of operations: - - submodule bind - each submodule patches will be based on the commit ID - saved in the .gitmodules config file; - - remote tracking - each submodule will sync with the upstream remote - and patches will be applied on top of //HEAD; - -Workflow (development) ----------------------- -The standard development workflow should look as follows: - -1. Decide whether remote tracking should be active or not: - NOTE: Setting the following var to any non-empty str enables remote track. - NOTE: Leaving unset will enable remote track for anything but stable branch. - - $ export FUEL_TRACK_REMOTES="" - -2. All Fuel sub-projects are registered as submodules. To initialize them, call: - If remote tracking is active, upstream remote is queried and latest remote - branch HEAD is fetched. Otherwise, checkout commit IDs from .gitmodules. - - $ make sub - -3. Apply patches from `patches//*` to respective submodules via: - - $ make patches-import - - This will result in creation of: - - a tag called `${FUEL_MAIN_TAG}-opnfv-root` at the same commit as Fuel@OPNFV - upstream reference (bound to git submodule OR tracking remote HEAD); - - a new branch `opnfv-fuel` which will hold all the OPNFV patches, - each patch is applied on this new branch with `git-am`; - - a tag called `${FUEL_MAIN_TAG}-opnfv` at `opnfv-fuel/HEAD`; - -4. Modify sub-projects for whatever you need. - Commit your changes when you want them taken into account in the build. - -5. Re-create patches via: - - $ make patches-export - - Each commit on `opnfv-fuel` branch of each subproject will be - exported to `patches/subproject/` via `git format-patch`. - - NOTE: Only commit (-f) submodules when you need to bump upstream ref. - NOTE: DO NOT commit patched submodules! - -6. Clean workbench branches and tags with: - - $ make clean - -7. De-initialize submodules and force a clean clone with: - - $ make deepclean - -Sub-project maintenance ------------------------ -1. Adding a new submodule - If you need to add another subproject, you can do it with `git submodule`. - Make sure that you specify branch (with `-b`), short name (with `--name`): - - $ git submodule -b master add --name reclass-system-salt-model \ - https://github.com/Mirantis/reclass-system-salt-model \ - relative/path/to/submodule - -2. Working with remote tracking for upgrading Fuel components - Enable remote tracking as described above, which at `make sub` will update - ALL submodules (e.g. reclass-system-salt-model) to remote branch (set in - .gitmodules) HEAD. - - * If upstream has NOT already tagged a new version, we can still work on - our patches, make sure they apply etc., then check for new upstream - changes (and that our patches still apply on top of them) by: - - $ make deepclean patches-import - - * If upstream has already tagged a new version we want to pick up, checkout - the new tag in each submodule: - - $ git submodule foreach 'git checkout ' - - * Once satisfied with the patch and submodule changes, commit them: - - enforce FUEL_TRACK_REMOTES to "yes" if you want to constatly use the - latest remote branch HEAD (as soon as upstream pushes a change on that - branch, our next build will automatically include it - risk of our - patches colliding with new upstream changes); - - stage patch changes if any; - - if submodule tags have been updated (relevant when remote tracking is - disabled, i.e. we have a stable upstream baseline), add submodules: - - $ make deepclean sub && git add -f relative/path/to/submodule diff --git a/mcp/patches/README.rst b/mcp/patches/README.rst new file mode 100644 index 000000000..81717b946 --- /dev/null +++ b/mcp/patches/README.rst @@ -0,0 +1,107 @@ +.. This work is licensed under a Creative Commons Attribution 4.0 International License. +.. SPDX-License-Identifier: CC-BY-4.0 +.. (c) 2017 Mirantis Inc., Enea AB and others. + +Fuel@OPNFV submodule fetching and patching +========================================== + +This directory holds submodule fetching/patching scripts, intended for +working with upstream Fuel/MCP components (e.g.: reclass-system-salt-model) in +developing/applying OPNFV patches (backports, custom fixes etc.). + +The scripts should be friendly to the following 2 use-cases: + - development work: easily cloning, binding repos to specific commits, + remote tracking, patch development etc.; + - to provide parent build scripts an easy method of tracking upstream + references and applying OPNFV patches on top; + +Also, we need to support at least the following modes of operations: + - submodule bind - each submodule patches will be based on the commit ID + saved in the .gitmodules config file; + - remote tracking - each submodule will sync with the upstream remote + and patches will be applied on top of //HEAD; + +Workflow (development) +---------------------- +The standard development workflow should look as follows: + +1. Decide whether remote tracking should be active or not: + NOTE: Setting the following var to any non-empty str enables remote track. + NOTE: Leaving unset will enable remote track for anything but stable branch. + + $ export FUEL_TRACK_REMOTES="" + +2. All Fuel sub-projects are registered as submodules. To initialize them, call: + If remote tracking is active, upstream remote is queried and latest remote + branch HEAD is fetched. Otherwise, checkout commit IDs from .gitmodules. + + $ make sub + +3. Apply patches from `patches//*` to respective submodules via: + + $ make patches-import + + This will result in creation of: + - a tag called `${FUEL_MAIN_TAG}-opnfv-root` at the same commit as Fuel@OPNFV + upstream reference (bound to git submodule OR tracking remote HEAD); + - a new branch `opnfv-fuel` which will hold all the OPNFV patches, + each patch is applied on this new branch with `git-am`; + - a tag called `${FUEL_MAIN_TAG}-opnfv` at `opnfv-fuel/HEAD`; + +4. Modify sub-projects for whatever you need. + Commit your changes when you want them taken into account in the build. + +5. Re-create patches via: + + $ make patches-export + + Each commit on `opnfv-fuel` branch of each subproject will be + exported to `patches/subproject/` via `git format-patch`. + + NOTE: Only commit (-f) submodules when you need to bump upstream ref. + NOTE: DO NOT commit patched submodules! + +6. Clean workbench branches and tags with: + + $ make clean + +7. De-initialize submodules and force a clean clone with: + + $ make deepclean + +Sub-project maintenance +----------------------- +1. Adding a new submodule + If you need to add another subproject, you can do it with `git submodule`. + Make sure that you specify branch (with `-b`), short name (with `--name`): + + $ git submodule -b master add --name reclass-system-salt-model \ + https://github.com/Mirantis/reclass-system-salt-model \ + relative/path/to/submodule + +2. Working with remote tracking for upgrading Fuel components + Enable remote tracking as described above, which at `make sub` will update + ALL submodules (e.g. reclass-system-salt-model) to remote branch (set in + .gitmodules) HEAD. + + * If upstream has NOT already tagged a new version, we can still work on + our patches, make sure they apply etc., then check for new upstream + changes (and that our patches still apply on top of them) by: + + $ make deepclean patches-import + + * If upstream has already tagged a new version we want to pick up, checkout + the new tag in each submodule: + + $ git submodule foreach 'git checkout ' + + * Once satisfied with the patch and submodule changes, commit them: + - enforce FUEL_TRACK_REMOTES to "yes" if you want to constatly use the + latest remote branch HEAD (as soon as upstream pushes a change on that + branch, our next build will automatically include it - risk of our + patches colliding with new upstream changes); + - stage patch changes if any; + - if submodule tags have been updated (relevant when remote tracking is + disabled, i.e. we have a stable upstream baseline), add submodules: + + $ make deepclean sub && git add -f relative/path/to/submodule diff --git a/prototypes/sfc_tacker/README b/prototypes/sfc_tacker/README deleted file mode 100644 index 0208b7850..000000000 --- a/prototypes/sfc_tacker/README +++ /dev/null @@ -1,54 +0,0 @@ -# author: Ferenc Cserepkei -# -# (c) 2016 Telefonaktiebolaget L. M. ERICSSON -# -# All rights reserved. This program and the accompanying materials -# are made available under the terms of the Apache License, Version 2.0 -# which accompanies this distribution, and is available at -# http://www.apache.org/licenses/LICENSE-2.0 - -README SFC + Tacker -------------------- - - The Enclosed shell script builds, deploys, orchestrates Tacker, -an Open NFV Orchestrator with in-built general purpose VNF Manager -to deploy and operate Virtual Network Functions (VNFs). - The provided deployment tool is experimental, not fault -tolerant but as idempotent as possible. To use the provided shell -script for provision/deployment, transfer the script to the Openstack -primary controller node, where Your deployed OpenDaylight SDN -controller runs. The deployment tool (poc.tacker-up.sh), expects that -Your primary controller reaches all your OPNFV/Fuel cluster nodes and -has internet connection either directly or via an http proxy, note -that a working and consistent DNS name resolution is a must. - Theory of operation: the deployment tool downloads the source -python packages from GitHub and a json rpc library developed by Josh -Marshall. Besides these sources, downloads software for python/debian -software release. When building succeeds the script deploys the software -components to the OPNFV Cluster nodes. Finally orchestrates the deployed -tacker binaries as an infrastucture/service. The Tacker has two -components: -o Tacker server - what interacts with Openstack and OpenDayLight. -o Tacker client - a command line software talks with the server, - available on all cluster nodes and the access point - to the Tacker service. Note that the tacker - distribution provides a a plugin to the Horizon - OpenStack Gui, but thus Horizon plugin is out of the - scope of this Proof of Concept setup/deployment. -As mentioned, this compilation contains an OpenDayLight SDN controller -with Service Function Chaining and Group based Policy features enabled. - -To acces for your cluster information ssh to the fuel master (10.20.0.2) -and issue command: fuel node. -Here is an output of an example deployment: - -id | status | name | cluster | ip | mac | roles | pending_roles | online | group_id ----|--------|------------------|---------|-----------|-------------------|----------------------------------|---------------|--------|--------- -3 | ready | Untitled (a2:4c) | 1 | 10.20.0.5 | 52:54:00:d3:a2:4c | compute | | True | 1 -4 | ready | Untitled (c7:d8) | 1 | 10.20.0.3 | 52:54:00:00:c7:d8 | cinder, controller, opendaylight | | True | 1 -1 | ready | Untitled (cc:51) | 1 | 10.20.0.6 | 52:54:00:1e:cc:51 | compute | | True | 1 -2 | ready | Untitled (e6:3e) | 1 | 10.20.0.4 | 52:54:00:0c:e6:3e | compute | | True | 1 -[root@fuel-sfc-virt ~]# - -As You can see in this case the poc.tacker-up.sh script should be -transferred and run on node having IP address 10.20.0.3 diff --git a/prototypes/sfc_tacker/README.rst b/prototypes/sfc_tacker/README.rst new file mode 100644 index 000000000..27574a66f --- /dev/null +++ b/prototypes/sfc_tacker/README.rst @@ -0,0 +1,49 @@ +.. This work is licensed under a Creative Commons Attribution 4.0 International License. +.. SPDX-License-Identifier: CC-BY-4.0 +.. (c) 2016 Telefonaktiebolaget L. M. ERICSSON + +README SFC + Tacker +=================== + + The Enclosed shell script builds, deploys, orchestrates Tacker, +an Open NFV Orchestrator with in-built general purpose VNF Manager +to deploy and operate Virtual Network Functions (VNFs). + The provided deployment tool is experimental, not fault +tolerant but as idempotent as possible. To use the provided shell +script for provision/deployment, transfer the script to the Openstack +primary controller node, where Your deployed OpenDaylight SDN +controller runs. The deployment tool (poc.tacker-up.sh), expects that +Your primary controller reaches all your OPNFV/Fuel cluster nodes and +has internet connection either directly or via an http proxy, note +that a working and consistent DNS name resolution is a must. + Theory of operation: the deployment tool downloads the source +python packages from GitHub and a json rpc library developed by Josh +Marshall. Besides these sources, downloads software for python/debian +software release. When building succeeds the script deploys the software +components to the OPNFV Cluster nodes. Finally orchestrates the deployed +tacker binaries as an infrastucture/service. The Tacker has two +components: +o Tacker server - what interacts with Openstack and OpenDayLight. +o Tacker client - a command line software talks with the server, + available on all cluster nodes and the access point + to the Tacker service. Note that the tacker + distribution provides a a plugin to the Horizon + OpenStack Gui, but thus Horizon plugin is out of the + scope of this Proof of Concept setup/deployment. +As mentioned, this compilation contains an OpenDayLight SDN controller +with Service Function Chaining and Group based Policy features enabled. + +To acces for your cluster information ssh to the fuel master (10.20.0.2) +and issue command: fuel node. +Here is an output of an example deployment: + +id | status | name | cluster | ip | mac | roles | pending_roles | online | group_id +---|--------|------------------|---------|-----------|-------------------|----------------------------------|---------------|--------|--------- +3 | ready | Untitled (a2:4c) | 1 | 10.20.0.5 | 52:54:00:d3:a2:4c | compute | | True | 1 +4 | ready | Untitled (c7:d8) | 1 | 10.20.0.3 | 52:54:00:00:c7:d8 | cinder, controller, opendaylight | | True | 1 +1 | ready | Untitled (cc:51) | 1 | 10.20.0.6 | 52:54:00:1e:cc:51 | compute | | True | 1 +2 | ready | Untitled (e6:3e) | 1 | 10.20.0.4 | 52:54:00:0c:e6:3e | compute | | True | 1 +[root@fuel-sfc-virt ~]# + +As You can see in this case the poc.tacker-up.sh script should be +transferred and run on node having IP address 10.20.0.3 -- cgit 1.2.3-korg