Merge "Fix formats for doc's information"
This commit is contained in:
commit
ade8cb5351
@ -24,7 +24,7 @@ OpenStack to enable it be an EPA compute node for deploying high performance
|
|||||||
VNFs.
|
VNFs.
|
||||||
|
|
||||||
Below table shows the configurations needed for the different features across
|
Below table shows the configurations needed for the different features across
|
||||||
BIOS, Hypervisor and OpenStack
|
BIOS, Hypervisor and OpenStack.
|
||||||
|
|
||||||
+----------------+------+------------+-----------+
|
+----------------+------+------------+-----------+
|
||||||
| | BIOS | Hypervisor | OpenStack |
|
| | BIOS | Hypervisor | OpenStack |
|
||||||
@ -84,7 +84,7 @@ nova.conf file.
|
|||||||
|
|
||||||
The SR-IOV feature enablement requires configuration on both the controller
|
The SR-IOV feature enablement requires configuration on both the controller
|
||||||
and compute nodes. Please refer link similar to below for the appropriate
|
and compute nodes. Please refer link similar to below for the appropriate
|
||||||
OpenStack release to setup SR-IOV
|
OpenStack release to setup SR-IOV:
|
||||||
http://docs.openstack.org/networking-guide/adv-config-sriov.html
|
http://docs.openstack.org/networking-guide/adv-config-sriov.html
|
||||||
|
|
||||||
The CPU Pinning feature enablement requires configuring the nova.conf on
|
The CPU Pinning feature enablement requires configuring the nova.conf on
|
||||||
|
@ -161,7 +161,7 @@ Vnfs
|
|||||||
|
|
||||||
**GET /v1.0/vnfs**
|
**GET /v1.0/vnfs**
|
||||||
|
|
||||||
List vnfs - Lists instantiated vnfs in VNF Manager
|
List vnfs - Lists instantiated vnfs in VNF Manager.
|
||||||
|
|
||||||
::
|
::
|
||||||
|
|
||||||
|
@ -80,7 +80,7 @@ returns 'failure' tacker will respawn the VNF.
|
|||||||
Actions
|
Actions
|
||||||
--------
|
--------
|
||||||
The available actions that a monitor driver can call when a particular event
|
The available actions that a monitor driver can call when a particular event
|
||||||
occurs
|
occurs.
|
||||||
|
|
||||||
#. respawn
|
#. respawn
|
||||||
#. log
|
#. log
|
||||||
|
@ -29,11 +29,11 @@ Preparing the OpenStack site
|
|||||||
1. Create a new 'nfv' project and admin privileged 'nfv' user on the remote
|
1. Create a new 'nfv' project and admin privileged 'nfv' user on the remote
|
||||||
OpenStack site.
|
OpenStack site.
|
||||||
2. Create the required neutron networks for management, packet in and packet
|
2. Create the required neutron networks for management, packet in and packet
|
||||||
out networks that will be used by VNFs
|
out networks that will be used by VNFs.
|
||||||
|
|
||||||
Register a new OpenStack VIM
|
Register a new OpenStack VIM
|
||||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||||
To register a new OpenStack VIM inside Tacker
|
To register a new OpenStack VIM inside Tacker.
|
||||||
|
|
||||||
::
|
::
|
||||||
|
|
||||||
@ -137,7 +137,7 @@ To delete a VIM :
|
|||||||
Features
|
Features
|
||||||
~~~~~~~~
|
~~~~~~~~
|
||||||
* VIMs are shared across tenants -- As an admin operator, the user can register
|
* VIMs are shared across tenants -- As an admin operator, the user can register
|
||||||
a VIM once and allow tenants to deploy VNFs on the registered VIM
|
a VIM once and allow tenants to deploy VNFs on the registered VIM.
|
||||||
* Pluggable driver module framework allowing Tacker to interact with multiple
|
* Pluggable driver module framework allowing Tacker to interact with multiple
|
||||||
VIM types.
|
VIM types.
|
||||||
* Compatible for OpenStack versions starting from Kilo.
|
* Compatible for OpenStack versions starting from Kilo.
|
||||||
|
@ -15,7 +15,7 @@ tacker/tests/functional.
|
|||||||
|
|
||||||
Writing a testcase:A testcase is written by declaring a class name derived from
|
Writing a testcase:A testcase is written by declaring a class name derived from
|
||||||
class base.BaseTackerTest. BaseTackerTest is class declared in
|
class base.BaseTackerTest. BaseTackerTest is class declared in
|
||||||
tacker/tests/functional/vnfd/base.py
|
tacker/tests/functional/vnfd/base.py.
|
||||||
|
|
||||||
A testcase body typically looks as below:
|
A testcase body typically looks as below:
|
||||||
|
|
||||||
@ -38,13 +38,13 @@ base.BaseTackerTest. Testcases typically has sections to setup, test, validate
|
|||||||
results and finally cleanup.
|
results and finally cleanup.
|
||||||
|
|
||||||
Input yaml files: These are input files used in testcases for operations like
|
Input yaml files: These are input files used in testcases for operations like
|
||||||
create vnfd or create vnf. The location of files is tacker/tests/etc/samples/
|
create vnfd or create vnf. The location of files is tacker/tests/etc/samples/.
|
||||||
|
|
||||||
requirements.txt and test-requirements.txt : The file requirements.txt and
|
requirements.txt and test-requirements.txt : The file requirements.txt and
|
||||||
test-requirements.txt lists all the packages needed for functional test.
|
test-requirements.txt lists all the packages needed for functional test.
|
||||||
These packages are installed during devstack installation. If there are any
|
These packages are installed during devstack installation. If there are any
|
||||||
new packages needed for functional test make sure they are added in
|
new packages needed for functional test make sure they are added in
|
||||||
test-requirements.txt
|
test-requirements.txt.
|
||||||
|
|
||||||
Asserting values in testcase: The base class BaseTackerTest
|
Asserting values in testcase: The base class BaseTackerTest
|
||||||
inherits base.TestCase which has inbuild assert functions which can be used in
|
inherits base.TestCase which has inbuild assert functions which can be used in
|
||||||
@ -117,11 +117,10 @@ Committing testcase and opening a review:
|
|||||||
=========================================
|
=========================================
|
||||||
|
|
||||||
* Once testcase is added in local setup, commit the testcase and open for
|
* Once testcase is added in local setup, commit the testcase and open for
|
||||||
review using below guidelines,
|
review using below guidelines:
|
||||||
* http://docs.openstack.org/infra/manual/developers.html
|
http://docs.openstack.org/infra/manual/developers.html
|
||||||
|
|
||||||
Sample testcase:
|
Sample testcase:
|
||||||
================
|
================
|
||||||
* Check sample tests under following directory:
|
* Check sample tests under following directory:
|
||||||
|
https://github.com/openstack/tacker/blob/master/tacker/tests/functional/
|
||||||
https://github.com/openstack/tacker/blob/master/tacker/tests/functional/
|
|
||||||
|
@ -65,9 +65,9 @@ vdus:
|
|||||||
management:
|
management:
|
||||||
*network*: **net_mgmt**
|
*network*: **net_mgmt**
|
||||||
|
|
||||||
management: **True**
|
*management*: **True**
|
||||||
|
|
||||||
addresses:
|
*addresses*:
|
||||||
\- 192.168.120.11
|
\- 192.168.120.11
|
||||||
pkt_in:
|
pkt_in:
|
||||||
*network*: **net0**
|
*network*: **net0**
|
||||||
@ -101,7 +101,7 @@ interface IP **addresses** during each deploy of the VNF.
|
|||||||
|
|
||||||
The next step is to substitute the identified parameter values that will be
|
The next step is to substitute the identified parameter values that will be
|
||||||
provided at deploy time with { get_input: <param_name>}. For example, the
|
provided at deploy time with { get_input: <param_name>}. For example, the
|
||||||
instance_type: **m1.tiny** would now be replaced as
|
instance_type: **m1.tiny** would now be replaced as:
|
||||||
**instance_type: {get_input: flavor}**. The **get_input** is a reserved
|
**instance_type: {get_input: flavor}**. The **get_input** is a reserved
|
||||||
keyword in the template that indicates value will be supplied at deploy time
|
keyword in the template that indicates value will be supplied at deploy time
|
||||||
for the parameter instance_type. The **flavor** is the variable that will
|
for the parameter instance_type. The **flavor** is the variable that will
|
||||||
@ -110,7 +110,7 @@ that will be supplied at VNF deploy time.
|
|||||||
|
|
||||||
The template in above section will look like below when parameterized for
|
The template in above section will look like below when parameterized for
|
||||||
**instance_type**, **user_data**, **user_data_format** and management
|
**instance_type**, **user_data**, **user_data_format** and management
|
||||||
interface IP **addresses**
|
interface IP **addresses**.
|
||||||
|
|
||||||
|
|
||||||
template_name: cirros_user_data
|
template_name: cirros_user_data
|
||||||
@ -150,9 +150,9 @@ vdus:
|
|||||||
management:
|
management:
|
||||||
*network*: **net_mgmt**
|
*network*: **net_mgmt**
|
||||||
|
|
||||||
management: **True**
|
*management*: **True**
|
||||||
|
|
||||||
addresses: **{ get_input: mgmt_ip}**
|
*addresses*: **{ get_input: mgmt_ip}**
|
||||||
pkt_in:
|
pkt_in:
|
||||||
*network*: **net0**
|
*network*: **net0**
|
||||||
pkt_out:
|
pkt_out:
|
||||||
@ -216,10 +216,11 @@ Key Summary
|
|||||||
\- xxx.xxx.xxx.xxx
|
\- xxx.xxx.xxx.xxx
|
||||||
- An example of a vnf-create python-tackerclient command specifying a
|
- An example of a vnf-create python-tackerclient command specifying a
|
||||||
parameterized template and parameter values file would like below:
|
parameterized template and parameter values file would like below:
|
||||||
|
|
||||||
"tacker vnf-create --vnfd-name <vnfd_name> --param-file <param_yaml_file>
|
"tacker vnf-create --vnfd-name <vnfd_name> --param-file <param_yaml_file>
|
||||||
<vnf_name>"
|
<vnf_name>"
|
||||||
- Specifying a parameter values file during VNF creation is also supported in
|
- Specifying a parameter values file during VNF creation is also supported in
|
||||||
Horizon UI.
|
Horizon UI.
|
||||||
- Sample VNFD parameterized templates and parameter values files can be found
|
- Sample VNFD parameterized templates and parameter values files can be found
|
||||||
at https://github.com/openstack/tacker/tree/master/samples
|
at https://github.com/openstack/tacker/tree/master/samples.
|
||||||
|
|
||||||
|
@ -20,7 +20,7 @@ Manual Installation
|
|||||||
===================
|
===================
|
||||||
|
|
||||||
This document describes how to install and run Tacker manually on the
|
This document describes how to install and run Tacker manually on the
|
||||||
controller node
|
controller node.
|
||||||
|
|
||||||
Pre-requisites
|
Pre-requisites
|
||||||
==============
|
==============
|
||||||
@ -76,7 +76,7 @@ Installing Tacker server
|
|||||||
exit;
|
exit;
|
||||||
..
|
..
|
||||||
|
|
||||||
2). Create users, roles and endpoints
|
2). Create users, roles and endpoints.
|
||||||
|
|
||||||
a). Source the admin credentials to gain access to admin-only CLI commands:
|
a). Source the admin credentials to gain access to admin-only CLI commands:
|
||||||
|
|
||||||
@ -156,7 +156,7 @@ d). Provide an endpoint to tacker service.
|
|||||||
|
|
||||||
..
|
..
|
||||||
|
|
||||||
6). Create 'tacker' directory in '/var/log'
|
6). Create 'tacker' directory in '/var/log'.
|
||||||
|
|
||||||
.. note::
|
.. note::
|
||||||
|
|
||||||
@ -218,7 +218,7 @@ d). Provide an endpoint to tacker service.
|
|||||||
|
|
||||||
.. note::
|
.. note::
|
||||||
|
|
||||||
The below command is for Ubuntu Operating System
|
The below command is for Ubuntu Operating System.
|
||||||
|
|
||||||
.. code-block:: console
|
.. code-block:: console
|
||||||
|
|
||||||
@ -279,7 +279,7 @@ Install Tacker horizon
|
|||||||
/usr/share/openstack-dashboard/openstack_dashboard/enabled/
|
/usr/share/openstack-dashboard/openstack_dashboard/enabled/
|
||||||
..
|
..
|
||||||
|
|
||||||
4). Restart Apache server
|
4). Restart Apache server.
|
||||||
|
|
||||||
.. code-block:: console
|
.. code-block:: console
|
||||||
|
|
||||||
@ -333,3 +333,4 @@ Add following parameters to config.yaml if VIM is using keystone v3:
|
|||||||
.. note::
|
.. note::
|
||||||
Here username must point to the user having 'admin' and 'advsvc' role on the
|
Here username must point to the user having 'admin' and 'advsvc' role on the
|
||||||
project that will be used for deploying VNFs.
|
project that will be used for deploying VNFs.
|
||||||
|
3). Restart tacker server.
|
||||||
|
Loading…
Reference in New Issue
Block a user