Refactor and clean up specs dir
- Follow new PTI building docs - Add dir for Stein specs - Remove skeleton.rst file because the template is enough - Remove archive specs because they are invalid. - Remove test_tiltles.py because it is useless (no actuall check the spec files), instead, enable pep8 and waring-as-error for .rst files, clear error those files. - Add placeholder.rst for stein/rocky dir, if not they will show error when building docs, delete them when it has approved specs. Change-Id: I8c387c0a480844b111562a9e77eac6ab26c58bce
This commit is contained in:
Nguyen Hai
parent
d528ad99a1
commit
d543040a4e
@ -1,17 +1,9 @@
|
|||||||
# The order of packages is significant, because pip processes them in the order
|
# The order of packages is significant, because pip processes them in the order
|
||||||
# of appearance. Changing the order has an impact on the overall integration
|
# of appearance. Changing the order has an impact on the overall integration
|
||||||
# process, which may cause wedges in the gate later.
|
# process, which may cause wedges in the gate later.
|
||||||
|
|
||||||
actdiag # BSD
|
|
||||||
blockdiag # BSD
|
|
||||||
nwdiag # BSD
|
|
||||||
seqdiag # BSD
|
|
||||||
pbr>=0.6,!=0.7,<1.0 # Apache-2.0
|
|
||||||
sphinx!=1.6.6,<1.7.0,>=1.6.2 # BSD
|
sphinx!=1.6.6,<1.7.0,>=1.6.2 # BSD
|
||||||
openstackdocstheme>=1.18.1 # Apache-2.0
|
openstackdocstheme>=1.18.1 # Apache-2.0
|
||||||
sphinxcontrib-actdiag # BSD
|
sphinxcontrib-actdiag # BSD
|
||||||
sphinxcontrib-blockdiag # BSD
|
sphinxcontrib-blockdiag # BSD
|
||||||
sphinxcontrib-nwdiag # BSD
|
sphinxcontrib-nwdiag # BSD
|
||||||
sphinxcontrib-seqdiag # BSD
|
sphinxcontrib-seqdiag # BSD
|
||||||
testrepository>=0.0.18 # Apache-2.0/BSD
|
|
||||||
testtools>=0.9.34 # MIT
|
|
||||||
@ -22,6 +22,7 @@ Specifications
|
|||||||
:glob:
|
:glob:
|
||||||
:maxdepth: 2
|
:maxdepth: 2
|
||||||
|
|
||||||
|
specs/stein/index
|
||||||
specs/rocky/index
|
specs/rocky/index
|
||||||
specs/queens/index
|
specs/queens/index
|
||||||
specs/pike/index
|
specs/pike/index
|
||||||
@ -29,7 +30,6 @@ Specifications
|
|||||||
specs/newton/index
|
specs/newton/index
|
||||||
specs/mitaka/index
|
specs/mitaka/index
|
||||||
specs/liberty/index
|
specs/liberty/index
|
||||||
specs/archive/index
|
|
||||||
|
|
||||||
Indices and tables
|
Indices and tables
|
||||||
------------------
|
------------------
|
||||||
|
|||||||
12
setup.cfg
12
setup.cfg
@ -11,17 +11,5 @@ classifier =
|
|||||||
License :: OSI Approved :: Apache Software License
|
License :: OSI Approved :: Apache Software License
|
||||||
Operating System :: POSIX :: Linux
|
Operating System :: POSIX :: Linux
|
||||||
|
|
||||||
[build_sphinx]
|
|
||||||
builders = html,man
|
|
||||||
source-dir = doc/source
|
|
||||||
build-dir = doc/build
|
|
||||||
all-files = 1
|
|
||||||
|
|
||||||
[upload_sphinx]
|
|
||||||
upload-dir = doc/build/html
|
|
||||||
|
|
||||||
[pbr]
|
|
||||||
warnerrors = True
|
|
||||||
|
|
||||||
[wheel]
|
[wheel]
|
||||||
universal = 1
|
universal = 1
|
||||||
|
|||||||
@ -1,9 +0,0 @@
|
|||||||
=======
|
|
||||||
Archive
|
|
||||||
=======
|
|
||||||
|
|
||||||
.. toctree::
|
|
||||||
:glob:
|
|
||||||
:maxdepth: 1
|
|
||||||
|
|
||||||
*
|
|
||||||
@ -1,625 +0,0 @@
|
|||||||
..
|
|
||||||
This work is licensed under a Creative Commons Attribution 3.0 Unported
|
|
||||||
License.
|
|
||||||
|
|
||||||
http://creativecommons.org/licenses/by/3.0/legalcode
|
|
||||||
|
|
||||||
|
|
||||||
==========================================
|
|
||||||
Implement Tacker Service Function Chaining
|
|
||||||
==========================================
|
|
||||||
|
|
||||||
Include the URL of your launchpad blueprint:
|
|
||||||
|
|
||||||
https://blueprints.launchpad.net/tacker/+spec/tacker-sfc
|
|
||||||
|
|
||||||
This spec describes the plan to introduce Service Function Chaining (SFC) into
|
|
||||||
Tacker. In it's current state, Tacker allows for managing VNFs; the purpose of
|
|
||||||
this spec is to also include managing SFCs.
|
|
||||||
|
|
||||||
Problem description
|
|
||||||
===================
|
|
||||||
|
|
||||||
There is a large desire from the NFV community to be able to orchestrate and
|
|
||||||
manage SFC. A user of NFV would not only like to be able to create VNFs, but
|
|
||||||
also define SFCs to direct traffic between VNFs. This goes hand in hand with
|
|
||||||
the work already done in Tacker to manage and monitor VNFs, but takes it a step
|
|
||||||
further to include SFC.
|
|
||||||
|
|
||||||
The goal is to be able to define a chain in orchestration via a logical and
|
|
||||||
abstract construct, while being able to render that chain down to the overlay
|
|
||||||
network. The next step is to be able to classify tenant traffic that should
|
|
||||||
flow through that SFC. The combination of VNFs, SFC, and the classification of
|
|
||||||
traffic to flow through them is described as the VNF Forwarding Graph (VNFFG).
|
|
||||||
This spec addresses the changes to Tacker necessary to orchestrate a VNFFG.
|
|
||||||
|
|
||||||
|
|
||||||
Proposed change
|
|
||||||
===============
|
|
||||||
|
|
||||||
The high-level changes needed to Tacker in order to accomodate this new feature
|
|
||||||
will include changes to Tacker Client, Horizon, and Server. Changes include:
|
|
||||||
|
|
||||||
* Add an SFC tab to tacker-horizon where a user can create a chain from already
|
|
||||||
created VNFs, as well as a Classification tab to declare traffic
|
|
||||||
into the chain. These inputs can be implemented in multiple ways, including
|
|
||||||
(1) a TOSCA VNF Forwarding Graph Descriptor (VNFFGD), as
|
|
||||||
well as (2) a simple drop down menu of chaining VNFs in order and then
|
|
||||||
defining classification schemes for tenants. VNFFG describes network
|
|
||||||
functions and how they are connected via yaml templates as input [9]. This is
|
|
||||||
similar to how VNFDs already work in Tacker VNFM. This spec proposes to
|
|
||||||
implement (2) with (1) as a later add on feature.
|
|
||||||
|
|
||||||
* Tacker Client will also need similar changes to allow passing the CRUD Chain
|
|
||||||
and CRUD Classification calls to Tacker Server
|
|
||||||
|
|
||||||
* Tacker Server will need another plugin extension, 'vnffg', similar to 'vnfm'
|
|
||||||
(previously 'servicevm')
|
|
||||||
|
|
||||||
* Drivers for 'vnffg' extension will need to be written. The known drivers to
|
|
||||||
create SFCs are networking-sfc [4] (Neutron based SFC) and OpenDaylight
|
|
||||||
SFC [5]. This spec will implement OpenDaylight supported as a functional
|
|
||||||
driver, and networking-sfc driver (along with others) will be a separate
|
|
||||||
effort. The OpenDaylight driver will be considered experimental, and for
|
|
||||||
testing purposes, until a Neutron driver + networking-odl support is added
|
|
||||||
to be able to create SFC for ODL via Neutron. When that support exists, the
|
|
||||||
OpenDaylight driver shall be deprecated in favor of a Neutron driver.
|
|
||||||
|
|
||||||
* Similarly drivers for Classification will need to be written.
|
|
||||||
These drivers will be handled as "mechanism drivers" which will drive
|
|
||||||
Classification in the main SFC OpenDaylight driver. The default
|
|
||||||
classifier mechanism driver will be 'netvirtsfc" which corresponds to an
|
|
||||||
OpenDaylight classifier for the OVSDB NetVirt project [8]. Upon migration to
|
|
||||||
Neutron driver, this driver will also be deprecated.
|
|
||||||
|
|
||||||
::
|
|
||||||
|
|
||||||
Tacker SFC Overview:
|
|
||||||
+------------------------+
|
|
||||||
| Tacker Server |
|
|
||||||
| |
|
|
||||||
+---------+--------------+
|
|
||||||
|
|
|
||||||
+-------+-------+
|
|
||||||
| |
|
|
||||||
|VNFFG Extension|
|
|
||||||
| Plugin/DB |
|
|
||||||
| |
|
|
||||||
| |
|
|
||||||
+-+-------------+
|
|
||||||
|
|
|
||||||
+------+-------+ +--------------+
|
|
||||||
| |----->|netvirt |
|
|
||||||
| ODL Driver | |mech driver |
|
|
||||||
+--------------+ +--------------+
|
|
||||||
| |
|
|
||||||
v v
|
|
||||||
+----------------------+
|
|
||||||
| OpenDaylight |
|
|
||||||
| Controller |
|
|
||||||
+----------------------+
|
|
||||||
|
|
||||||
Alternatives
|
|
||||||
------------
|
|
||||||
|
|
||||||
None
|
|
||||||
|
|
||||||
Data model impact
|
|
||||||
-----------------
|
|
||||||
|
|
||||||
Data model impact includes the creation of 'vnffg_chain' and 'vnffg_classifier'
|
|
||||||
tables. Those tables will hold the attributes listed below. Another table
|
|
||||||
'acl_match_criteria' will hold the entries of match criteria mapped to the
|
|
||||||
classifier.
|
|
||||||
|
|
||||||
REST API impact
|
|
||||||
---------------
|
|
||||||
|
|
||||||
Two basic methods of SFC creation via the VNFFG extension will be supported.
|
|
||||||
The first is by specifying the VNF instances (already created via VNFM) to use
|
|
||||||
in the chain. The order of these VNFs determine their order in the chain
|
|
||||||
itself. The second method of SFC creation involves using abstract types. A
|
|
||||||
type is declared in the VNFD, determining what type of VNF it is (ex. firewall,
|
|
||||||
nat, etc). This type may be passed into the vnffg-create command, along with
|
|
||||||
the --abstract-types argument, to indicate an abstract type is being used. The
|
|
||||||
VNFFG plugin will then search randomly for a VNF of the specified type to be
|
|
||||||
used in chain creation, unless the registered SFC driver (i.e. opendaylight)
|
|
||||||
supports abstract type selection. OpenDaylight SFC supports being able to
|
|
||||||
select VNFs based on abstract types using many algorithms such as random,
|
|
||||||
round-robin, shortest-path [11].
|
|
||||||
|
|
||||||
In addition, when using abstract types, a VNF instance of that type must already
|
|
||||||
exist for the vnffg-create command to complete successfully. The possibility of
|
|
||||||
being able to automatically spawn a non-existent VNF instance of a desired
|
|
||||||
abstract type (that matches an existing VNFD) is outside the scope of this
|
|
||||||
spec, but may be supported later by an additional spec.
|
|
||||||
|
|
||||||
Example CLI calls:
|
|
||||||
|
|
||||||
To create VNFFG SFC (where testVNF1, and testVNF2 are VNF instances):
|
|
||||||
|
|
||||||
tacker vnffg-create --name mychain --chain testVNF2,testVNF1 --symmetrical True
|
|
||||||
|
|
||||||
To create VNFFG SFC by abstract VNF types (ex. "firewall", "nat"):
|
|
||||||
tacker vnffg-create --name mychain --chain firewall,nat --abstract-types
|
|
||||||
|
|
||||||
To create SFC Classifier for a VNFFG:
|
|
||||||
|
|
||||||
tacker vnffg-classifier-create --name myclass --chain mychain
|
|
||||||
--match tcp_dest=80,ip_proto=6
|
|
||||||
|
|
||||||
**/vnffg/chain**
|
|
||||||
|
|
||||||
::
|
|
||||||
|
|
||||||
+----------------------------------------------------------------------------+
|
|
||||||
|Attribute |Type |Access |Default |Validation/ |Description |
|
|
||||||
|Name | | |Value |Conversion | |
|
|
||||||
+----------------------------------------------------------------------------+
|
|
||||||
|id |string |RO, All |generated |N/A |identity |
|
|
||||||
| |(UUID) | | | | |
|
|
||||||
+----------------------------------------------------------------------------+
|
|
||||||
|name |string |RW, All |'' |string |human+readable |
|
|
||||||
| | | | | |name |
|
|
||||||
+----------------------------------------------------------------------------+
|
|
||||||
|description |string |RW, All |'' |string |description of |
|
|
||||||
| | | | | |Chain |
|
|
||||||
+----------------------------------------------------------------------------+
|
|
||||||
|attributes |dict |RW, All |None |dict |driver specific attr|
|
|
||||||
| | | | | |shown in schema 3 |
|
|
||||||
+----------------------------------------------------------------------------+
|
|
||||||
|tenant_id |string |RW, All |generated |string |project id to |
|
|
||||||
| | | | | |launch SFC |
|
|
||||||
+----------------------------------------------------------------------------+
|
|
||||||
|status |string |RO, All |generated |string |current state |
|
|
||||||
| | | | | |of SFC |
|
|
||||||
+--------------+-------+--------+----------+---------------------------------+
|
|
||||||
|sfc_driver |string |RW, All |Open |string |driver to provision |
|
|
||||||
| | | |Daylight | |SFC |
|
|
||||||
+----------------------------------------------------------------------------+
|
|
||||||
|symmetrical |bool |RW, All |True |bool |Chain allows |
|
|
||||||
| | | | | |reverse traffic |
|
|
||||||
+----------------------------------------------------------------------------+
|
|
||||||
|chain |list |RW, All |None |list |SFC Chain as list of|
|
|
||||||
| | | | | |ordered VNF name/IDs|
|
|
||||||
+----------------------------------------------------------------------------+
|
|
||||||
|abstract_types|bool |RW, All |None |bool |Specify service_ |
|
|
||||||
| | | | | |types in chain |
|
|
||||||
+----------------------------------------------------------------------------+
|
|
||||||
|
|
||||||
+----------------------------------------------------------------------------+
|
|
||||||
|REST Calls |Type |Expected |Body Data |Description |
|
|
||||||
| | |Response |Schema | |
|
|
||||||
+----------------------------------------------------------------------------+
|
|
||||||
|create_chain |post |200 OK |schema 1 | Creates SFC for declared VNFFG|
|
|
||||||
| | | | | |
|
|
||||||
+----------------------------------------------------------------------------+
|
|
||||||
|update_chain |put |200 OK |schema 1 | Updates VNFFG SFC by name or |
|
|
||||||
| | | | | ID |
|
|
||||||
+----------------------------------------------------------------------------+
|
|
||||||
|delete_chain |delete|200 OK |None | Deletes VNFFG SFC by name or |
|
|
||||||
| | | | | ID |
|
|
||||||
+----------------------------------------------------------------------------+
|
|
||||||
|show_chain |get |200 OK |None | Returns output of specific |
|
|
||||||
| | | | | VNFFG chain ID |
|
|
||||||
+----------------------------------------------------------------------------+
|
|
||||||
|list_chains |get |200 OK |None | Returns list of configured |
|
|
||||||
| | | | | VNFFG Names/IDs |
|
|
||||||
+----------------------------------------------------------------------------+
|
|
||||||
|
|
||||||
+----------------------------------------------------------------------------+
|
|
||||||
|REST Call |Type |Negative |Response Message |Scenario |
|
|
||||||
|Failures | |Response | | |
|
|
||||||
+----------------------------------------------------------------------------+
|
|
||||||
|create_chain |post |404 Not |Unknown VNF |No VNFs exist with |
|
|
||||||
| | |Found |Abstract Type |declared abstract type |
|
|
||||||
+----------------------------------------------------------------------------+
|
|
||||||
|create_chain |post |404 Not |VNF does not |No VNFs exist with |
|
|
||||||
| | |Found |exist |declared instance |
|
|
||||||
+----------------------------------------------------------------------------+
|
|
||||||
|update_chain |put |404 Not |Chain does not |No Chain exists with |
|
|
||||||
| | |Found |exist |provided Name/ID |
|
|
||||||
+----------------------------------------------------------------------------+
|
|
||||||
|delete_chain |delete|403 |Chain Update |Chain already being |
|
|
||||||
| | |Forbidden |in progress |updated by a request |
|
|
||||||
+----------------------------------------------------------------------------+
|
|
||||||
|
|
||||||
|
|
||||||
**/vnffg/classifier**
|
|
||||||
|
|
||||||
::
|
|
||||||
|
|
||||||
+----------------------------------------------------------------------------+
|
|
||||||
|Attribute |Type |Access |Default |Validation/ |Description |
|
|
||||||
|Name | | |Value |Conversion | |
|
|
||||||
+----------------------------------------------------------------------------+
|
|
||||||
|id |string |RO, All |generated |N/A |identity |
|
|
||||||
| |(UUID) | | | | |
|
|
||||||
+----------------------------------------------------------------------------+
|
|
||||||
|name |string |RW, All |'' |string |human+readable |
|
|
||||||
| | | | | |name |
|
|
||||||
+----------------------------------------------------------------------------+
|
|
||||||
|description |string |RW, All |'' |string |description of |
|
|
||||||
| | | | | |Classifier |
|
|
||||||
+----------------------------------------------------------------------------+
|
|
||||||
|attributes |dict |RW, All |None |dict |driver specific |
|
|
||||||
| | | | | |attributes |
|
|
||||||
+----------------------------------------------------------------------------+
|
|
||||||
|tenant_id |string |RW, All |generated |string |project id to |
|
|
||||||
| | | | | |create SFCClassifier|
|
|
||||||
+----------------------------------------------------------------------------+
|
|
||||||
|status |string |RO, All |generated |string |current state |
|
|
||||||
| | | | | |of SFC Classifier |
|
|
||||||
+--------------+-------+--------+----------+---------------------------------+
|
|
||||||
|sfc_classifier|string |RW, All |netvirtsfc|string |driver to provision |
|
|
||||||
|_driver | | | | |SFC Classification |
|
|
||||||
+----------------------------------------------------------------------------+
|
|
||||||
|match |dict |RW, All |True |acl_dict |Match criteria |
|
|
||||||
| | | | | |(see supported list)|
|
|
||||||
+----------------------------------------------------------------------------+
|
|
||||||
|chain |string |RW, All |None |string |SFC Chain to |
|
|
||||||
| |(UUID) | | |(UUID) |classify on |
|
|
||||||
+----------------------------------------------------------------------------+
|
|
||||||
|
|
||||||
+----------------------------------------------------------------------------+
|
|
||||||
|REST Calls |Type |Expected |Body Data |Description |
|
|
||||||
| | |Response |Schema | |
|
|
||||||
+----------------------------------------------------------------------------+
|
|
||||||
|create_ |post |200 OK |schema 2 | Creates Classifier for |
|
|
||||||
|classifier | | | | for an SFC |
|
|
||||||
+----------------------------------------------------------------------------+
|
|
||||||
|update_ |put |200 OK |schema 2 | Updates Classifier by name or |
|
|
||||||
|classifier | | | | ID |
|
|
||||||
+----------------------------------------------------------------------------+
|
|
||||||
|delete_ |delete|200 OK |None | Deletes classifier by name or |
|
|
||||||
|classifier | | | | ID |
|
|
||||||
+----------------------------------------------------------------------------+
|
|
||||||
|show_ |get |200 OK |None | Returns output of specific |
|
|
||||||
|classifier | | | | classifier |
|
|
||||||
+----------------------------------------------------------------------------+
|
|
||||||
|list_ |get |200 OK |None | Returns list of configured |
|
|
||||||
|classifiers | | | | Classifier Names/IDs |
|
|
||||||
+----------------------------------------------------------------------------+
|
|
||||||
|
|
||||||
+----------------------------------------------------------------------------+
|
|
||||||
|REST Call |Type |Negative |Response Message |Scenario |
|
|
||||||
|Failures | |Response | | |
|
|
||||||
+----------------------------------------------------------------------------+
|
|
||||||
|create_ |post |404 Not |Chain Instance |No Chain exists with |
|
|
||||||
|classifier | |Found |Not Found |provided Name/ID |
|
|
||||||
+----------------------------------------------------------------------------+
|
|
||||||
|update_ |put |400 Bad |Unknown Match |Unsupported ACL match |
|
|
||||||
|classifier | |Request |Criteria |criteria in request |
|
|
||||||
+----------------------------------------------------------------------------+
|
|
||||||
|delete_ |delete|403 |Classifier update|Classifier already being |
|
|
||||||
|classifier | |Forbidden |in progress |updated by a request |
|
|
||||||
+----------------------------------------------------------------------------+
|
|
||||||
|update_ |put |409 |Conflicting Match|Conflicting ACL match |
|
|
||||||
|classifier | |Conflict |Criteria |associated with the chain|
|
|
||||||
+----------------------------------------------------------------------------+
|
|
||||||
|
|
||||||
|
|
||||||
**Schema Definitions:**
|
|
||||||
|
|
||||||
* Schema 1: This schema describes a typical body for VNFFG SFC request:
|
|
||||||
|
|
||||||
::
|
|
||||||
|
|
||||||
{u'vnffg': {u'attributes': {}, u'name': u'test_chain', u'chain':
|
|
||||||
[u'c0f0500e-4dc4-4321-a188-40a6ecfea0ea',
|
|
||||||
u'9d1c6854-bb71-4a99-934d-7bef3222d0bb'], u'symmetrical': u'True'}}
|
|
||||||
|
|
||||||
* Schema 2: This schema describes a typical body for Classifier request:
|
|
||||||
|
|
||||||
::
|
|
||||||
|
|
||||||
{u'vnffg_classifier': {u'attributes': {}, u'match':
|
|
||||||
{u'source_port': u'80',
|
|
||||||
u'protocol': u'6'}, u'name': u'test_classifier', u'chain':
|
|
||||||
u'9aa6e7e2-2e87-432d-abe9-8e97ffd155cd'}
|
|
||||||
|
|
||||||
* Schema 3: This schema is used to provide extra information about each VNF in
|
|
||||||
the SFC as driver specific attributes about a chain. For example,
|
|
||||||
OpenDaylight driver may need the transport-type, or encapsulation-type
|
|
||||||
specified, while networking-sfc does not. These are handled as optional
|
|
||||||
key,value pairs.
|
|
||||||
|
|
||||||
::
|
|
||||||
|
|
||||||
{u'vnffg':
|
|
||||||
{u'attributes':
|
|
||||||
[{u'9d1c6854-bb71-4a99-934d-7bef3222d0bb':
|
|
||||||
{u'transport-type': u'VXLAN-GPE',
|
|
||||||
u'sfc_encap': u'NSH'}},
|
|
||||||
{u'5e5e72c0-82a9-4318-bcd7-8d965afbae89':
|
|
||||||
{u'transport-type': u'Ethernet',
|
|
||||||
u'sfc_encap': u'None'}}
|
|
||||||
]
|
|
||||||
}
|
|
||||||
}
|
|
||||||
|
|
||||||
|
|
||||||
**Classifier Match Criteria:**
|
|
||||||
|
|
||||||
Supported list of matching attributes for classification are listed below.
|
|
||||||
These are used as key=value pairs in a "match" list specified in schema 2. The
|
|
||||||
match criteria supported by OpenDaylight includes IETF ACL model [6]. In
|
|
||||||
addition, networking-sfc project has passed the supported Classifier match
|
|
||||||
criteria listed in the corresponding spec [7]. Tacker SFC Classifier will
|
|
||||||
aggregate the two into these supported attributes. There should be at least
|
|
||||||
one match criteria attribute specified when creating/updating a classifier
|
|
||||||
from the following available attributes:
|
|
||||||
|
|
||||||
::
|
|
||||||
|
|
||||||
+----------------------------------------------+
|
|
||||||
|Attribute |Description |
|
|
||||||
| | |
|
|
||||||
+----------------------------------------------+
|
|
||||||
|eth_type |Specifies Ethernet frame type |
|
|
||||||
| |See IEEE 802.3 |
|
|
||||||
+----------------------------------------------+
|
|
||||||
|eth_src |Ethernet source address |
|
|
||||||
| | |
|
|
||||||
+----------------------------------------------+
|
|
||||||
|eth_dst |Ethernet destination address |
|
|
||||||
| | |
|
|
||||||
+----------------------------------------------+
|
|
||||||
|vlan_id |VLAN ID |
|
|
||||||
| | |
|
|
||||||
+----------------------------------------------+
|
|
||||||
|vlan_pcp |VLAN Priority |
|
|
||||||
| | |
|
|
||||||
+----------------------------------------------+
|
|
||||||
|mpls_label |MPLS Label |
|
|
||||||
| | |
|
|
||||||
+----------------------------------------------+
|
|
||||||
|mpls_tc |MPLS Traffic Class |
|
|
||||||
| | |
|
|
||||||
+----------------------------------------------+
|
|
||||||
|ip_dscp |IP DSCP (6 bits in ToS field) |
|
|
||||||
| | |
|
|
||||||
+----------------------------------------------+
|
|
||||||
|ip_ecn |IP ECN (2 bits in ToS field) |
|
|
||||||
| | |
|
|
||||||
+----------------------------------------------+
|
|
||||||
|ip_src_prefix |IP source address prefix |
|
|
||||||
| | |
|
|
||||||
+----------------------------------------------+
|
|
||||||
|ip_dst_prefix |IP destination address prefix |
|
|
||||||
| | |
|
|
||||||
+----------------------------------------------+
|
|
||||||
|ip_proto |IP protocol |
|
|
||||||
| | |
|
|
||||||
+----------------------------------------------+
|
|
||||||
|tcp_src |Source TCP port |
|
|
||||||
| | |
|
|
||||||
+----------------------------------------------+
|
|
||||||
|tcp_dest |Destination TCP port |
|
|
||||||
| | |
|
|
||||||
+----------------------------------------------+
|
|
||||||
|tcp_src_ |Source TCP port range |
|
|
||||||
|range_min |minimum value |
|
|
||||||
+----------------------------------------------+
|
|
||||||
|tcp_src_ |Source TCP port range |
|
|
||||||
|range_max |maximum value |
|
|
||||||
+----------------------------------------------+
|
|
||||||
|tcp_dst_ |Destination TCP port range |
|
|
||||||
|range_min |minimum value |
|
|
||||||
+----------------------------------------------+
|
|
||||||
|tcp_dst_ |Destination TCP port range |
|
|
||||||
|range_max |maximum value |
|
|
||||||
+----------------------------------------------+
|
|
||||||
|udp_src |Source UDP port |
|
|
||||||
| | |
|
|
||||||
+----------------------------------------------+
|
|
||||||
|udp_dest |Destination UDP port |
|
|
||||||
| | |
|
|
||||||
+----------------------------------------------+
|
|
||||||
|udp_src_ |Source UDP port range |
|
|
||||||
|range_min |minimum value |
|
|
||||||
+----------------------------------------------+
|
|
||||||
|udp_src_ |Source UDP port range |
|
|
||||||
|range_max |maximum value |
|
|
||||||
+----------------------------------------------+
|
|
||||||
|udp_dst_ |Destination UDP port range |
|
|
||||||
|range_min |minimum value |
|
|
||||||
+----------------------------------------------+
|
|
||||||
|udp_dst_ |Destination UDP port range |
|
|
||||||
|range_max |maximum value |
|
|
||||||
+----------------------------------------------+
|
|
||||||
|sctp_src |SCTP source port |
|
|
||||||
| | |
|
|
||||||
+----------------------------------------------+
|
|
||||||
|sctp_dest |SCTP destination port |
|
|
||||||
| | |
|
|
||||||
+----------------------------------------------+
|
|
||||||
|icmpv4_type |ICMP type |
|
|
||||||
| | |
|
|
||||||
+----------------------------------------------+
|
|
||||||
|icmpv4_code |ICMP code |
|
|
||||||
| | |
|
|
||||||
+----------------------------------------------+
|
|
||||||
|arp_op |ARP opcode |
|
|
||||||
| | |
|
|
||||||
+----------------------------------------------+
|
|
||||||
|arp_spa |ARP source ipv4 address |
|
|
||||||
| | |
|
|
||||||
+----------------------------------------------+
|
|
||||||
|arp_tpa |ARP target ipv4 address |
|
|
||||||
| | |
|
|
||||||
+----------------------------------------------+
|
|
||||||
|arp_sha |ARP source hardware address |
|
|
||||||
| | |
|
|
||||||
+----------------------------------------------+
|
|
||||||
|arp_tha |ARP target hardware address |
|
|
||||||
| | |
|
|
||||||
+----------------------------------------------+
|
|
||||||
|ipv6_src |IPv6 source address |
|
|
||||||
| | |
|
|
||||||
+----------------------------------------------+
|
|
||||||
|ipv6_dst |IPv6 destination address |
|
|
||||||
| | |
|
|
||||||
+----------------------------------------------+
|
|
||||||
|ipv6_flabel |IPv6 Flow Label |
|
|
||||||
| | |
|
|
||||||
+----------------------------------------------+
|
|
||||||
|icmpv6_type |ICMPv6 type |
|
|
||||||
| | |
|
|
||||||
+----------------------------------------------+
|
|
||||||
|icmpv6_code |ICMPv6 code |
|
|
||||||
| | |
|
|
||||||
+----------------------------------------------+
|
|
||||||
|ipv6_nd_target|Target address for ND |
|
|
||||||
| | |
|
|
||||||
+----------------------------------------------+
|
|
||||||
|ipv6_nd_sll |Source link-layer for ND |
|
|
||||||
| | |
|
|
||||||
+----------------------------------------------+
|
|
||||||
|ipv6_nd_tll |Target link-layer for ND |
|
|
||||||
| | |
|
|
||||||
+----------------------------------------------+
|
|
||||||
|neutron_src |Neutron source port |
|
|
||||||
|_port | |
|
|
||||||
+----------------------------------------------+
|
|
||||||
|neutron_dst |Neutron destination port |
|
|
||||||
|_port | |
|
|
||||||
+----------------------------------------------+
|
|
||||||
|tenant_id |OpenStack Tenant ID |
|
|
||||||
| | |
|
|
||||||
+----------------------------------------------+
|
|
||||||
|neutron_net |Neutron Network ID |
|
|
||||||
|_id | |
|
|
||||||
+----------------------------------------------+
|
|
||||||
|
|
||||||
Note: OpenDaylight is able to classify based on tenant_id and neutron_net_id.
|
|
||||||
This means that it is possible to create classifiers that match more than one
|
|
||||||
tenant. Networking-sfc relies on Role Based Access Control (RBAC) to share
|
|
||||||
Classifiers across tenants [8]. Once Neutron supports RBAC along with ODL SFC
|
|
||||||
support, Tacker will migrate to inherently use the RBAC approach. For now, the
|
|
||||||
netvirtsfc driver will be able to classify across multiple tenants.
|
|
||||||
|
|
||||||
Security impact
|
|
||||||
---------------
|
|
||||||
|
|
||||||
Exposes OpenDaylight login information via Tacker configuration file. Similar
|
|
||||||
to Neutron ML2 plugin. Will be removed when OpenDaylight driver is deprecated.
|
|
||||||
|
|
||||||
Notifications impact
|
|
||||||
--------------------
|
|
||||||
|
|
||||||
None
|
|
||||||
|
|
||||||
Other end user impact
|
|
||||||
---------------------
|
|
||||||
|
|
||||||
There will be changes to python-tackerclient for the end user in order to manage
|
|
||||||
SFC. The changes will involve adding new SFC shell extensions to
|
|
||||||
python-tackerclient in order to allow CRUD operations.
|
|
||||||
|
|
||||||
In the case of using OpenDaylight as the SFC driver, an end user may opt to
|
|
||||||
manage SFC by directly logging into OpenDaylight's SFC GUI as another avenue of
|
|
||||||
SFC management.
|
|
||||||
|
|
||||||
There will also be changes to Horizon via the tacker-horizon plugin. These
|
|
||||||
changes will allow a user to specify SFCs and SFC Classifiers from new tabs
|
|
||||||
in Horizon (similar to the design used for VNF Management).
|
|
||||||
|
|
||||||
Performance Impact
|
|
||||||
------------------
|
|
||||||
|
|
||||||
None
|
|
||||||
|
|
||||||
Other deployer impact
|
|
||||||
---------------------
|
|
||||||
|
|
||||||
New configuration will be added to Tackers configuration file. The new
|
|
||||||
configuration will include using "opendaylight" SFC driver, mechanism
|
|
||||||
driver for Classification, and configuring OpenDaylight specific parameters
|
|
||||||
(login, IP address, REST port, etc).
|
|
||||||
|
|
||||||
Configuration impact for OpenStack when using networking-sfc as the SFC driver
|
|
||||||
will require changes to Neutron configuration.
|
|
||||||
|
|
||||||
Configuration impact for OpenStack with OpenDaylight includes modifying Neutron
|
|
||||||
configuration as well as avoiding a potential port conflict between Swift and
|
|
||||||
OpenDaylight on port 8080.
|
|
||||||
|
|
||||||
Developer impact
|
|
||||||
----------------
|
|
||||||
|
|
||||||
None
|
|
||||||
|
|
||||||
Implementation
|
|
||||||
==============
|
|
||||||
|
|
||||||
Assignee(s)
|
|
||||||
-----------
|
|
||||||
|
|
||||||
Primary assignee:
|
|
||||||
trozet
|
|
||||||
|
|
||||||
Other contributors:
|
|
||||||
|
|
||||||
Work Items
|
|
||||||
----------
|
|
||||||
|
|
||||||
1. Add new plugin extension 'sfc' to Tacker-server.
|
|
||||||
2. Port and modify 'opendaylight' sfc driver to Tacker.
|
|
||||||
3. Port and modify 'netvirtsfc' as a classifier driver.
|
|
||||||
4. Port and modify tackerclient API
|
|
||||||
5. Add shell extensions to tackerclient
|
|
||||||
6. Modify tacker_horizon with new interface for creating SFC and Classifiers
|
|
||||||
7. Add unit tests for all of the above
|
|
||||||
8. Integration with OpenDaylight and OVS dependencies (see below)
|
|
||||||
9. Add REST api docs
|
|
||||||
|
|
||||||
Dependencies
|
|
||||||
============
|
|
||||||
|
|
||||||
Main dependencies include SFC work in OpenDaylight and OpenvSwitch (OVS). NSH
|
|
||||||
is used to carry SFC information and provide security for the chain [1]. NSH
|
|
||||||
is not a transport protocol. Therefore it cannot be the outer header of a
|
|
||||||
packet, and must be encapsulated by another protocol. There are multiple ways
|
|
||||||
to do this which currently include using VXLAN+GPE or Ethernet as the
|
|
||||||
encapsulator.
|
|
||||||
|
|
||||||
OpenvSwitch currently has un-official patches to provide NSH from Cisco [2] and
|
|
||||||
Intel. The former allows for VXLAN+GPE NSH enabled OVS while the latter allows
|
|
||||||
for Ethernet NSH encapsulation (but is DPDK only).
|
|
||||||
|
|
||||||
The NSH header must be forwarded to the VNF VM itself so that the VNF can
|
|
||||||
decrement the NSH header and ensure reliability of the chain. The Tacker SFC
|
|
||||||
work is dependent on a solution to this OVS so that a VNF VM would be able to
|
|
||||||
receive an NSH packet.
|
|
||||||
|
|
||||||
Corresponding work must be done in OpenDaylight to allow these changes to be
|
|
||||||
leveraged by OpenDaylight SFC project. The Tacker SFC work is also dependent on
|
|
||||||
the these changes in OpenDaylight.
|
|
||||||
|
|
||||||
Testing
|
|
||||||
=======
|
|
||||||
|
|
||||||
As of now, there are no tempest tests added to Tacker and will be tracked as a
|
|
||||||
separate activity. Ultimately that activity would take place in OPNFV SFC to
|
|
||||||
leverage their Functest and CI teams to perform testing.
|
|
||||||
|
|
||||||
Documentation Impact
|
|
||||||
====================
|
|
||||||
|
|
||||||
New API docs will be added for SFC to the Tacker wiki [3].
|
|
||||||
|
|
||||||
References
|
|
||||||
==========
|
|
||||||
|
|
||||||
[1] https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh/?include_text=1
|
|
||||||
[2] https://github.com/pritesh/ovs/tree/nsh-v8
|
|
||||||
[3] https://wiki.openstack.org/wiki/Tacker/API
|
|
||||||
[4] https://github.com/openstack/networking-sfc/blob/master/doc/source/api.rst
|
|
||||||
[5] https://github.com/opendaylight/sfc
|
|
||||||
[6] https://tools.ietf.org/html/draft-ietf-netmod-acl-model-05
|
|
||||||
[7] https://review.openstack.org/#/c/190463/20/specs/liberty/classifier.rst
|
|
||||||
[8] https://wiki.opendaylight.org/view/OVSDB_Integration:Main
|
|
||||||
[9] http://docs.oasis-open.org/tosca/tosca-nfv/v1.0/tosca-nfv-v1.0.pdf
|
|
||||||
[10] http://www.etsi.org/deliver/etsi_gs/NFV-MAN/001_099/001/01.01.01_60/gs_nfv-man001v010101p.pdf
|
|
||||||
[11] https://github.com/opendaylight/sfc/blob/master/sfc-model/src/main/yang/service-function-scheduler-type.yang
|
|
||||||
@ -55,7 +55,7 @@ Template Changes
|
|||||||
When the user give host properties, Tacker will create a new flavor with those
|
When the user give host properties, Tacker will create a new flavor with those
|
||||||
details by adding those details in heat template. Tacker will handle three
|
details by adding those details in heat template. Tacker will handle three
|
||||||
minimum host properties like 'disk_size' and 'num_cpus' and 'mem_size'.
|
minimum host properties like 'disk_size' and 'num_cpus' and 'mem_size'.
|
||||||
To refer the other properties, refer[1].
|
To refer the other properties, refer [#]_.
|
||||||
|
|
||||||
Tacker will fetch the properties from TOSCA template and add them to HOT
|
Tacker will fetch the properties from TOSCA template and add them to HOT
|
||||||
as below:
|
as below:
|
||||||
@ -157,7 +157,7 @@ Template Changes
|
|||||||
|
|
||||||
In this modified template, users can specify the CIDR of the network, they want
|
In this modified template, users can specify the CIDR of the network, they want
|
||||||
to deploy VNF. If the user specify the CIDR and not the network_id, tacker will
|
to deploy VNF. If the user specify the CIDR and not the network_id, tacker will
|
||||||
automatically create network and corresponding subnet. Refer [2] for the
|
automatically create network and corresponding subnet. Refer [#]_ for the
|
||||||
properties the tacker will support in network_interfaces. For the networks, tacker
|
properties the tacker will support in network_interfaces. For the networks, tacker
|
||||||
will create the network resources at VNF creation time using heat code. So we are not
|
will create the network resources at VNF creation time using heat code. So we are not
|
||||||
storing the network details as network resources are associated with heat stack details.
|
storing the network details as network resources are associated with heat stack details.
|
||||||
@ -170,7 +170,7 @@ Let's see how the above TOSCA template can be converted to HOT network resource.
|
|||||||
type: OS::Neutron::Net
|
type: OS::Neutron::Net
|
||||||
properties:
|
properties:
|
||||||
name: net_internal_dp
|
name: net_internal_dp
|
||||||
|
|
||||||
net_internal_dp_subnet:
|
net_internal_dp_subnet:
|
||||||
type: OS::Neutron::Subnet
|
type: OS::Neutron::Subnet
|
||||||
properties:
|
properties:
|
||||||
|
|||||||
@ -167,14 +167,14 @@ Below would be an example of pinning guest vCPUs to host pCPUs:
|
|||||||
node_templates:
|
node_templates:
|
||||||
VDU1:
|
VDU1:
|
||||||
type: tosca.nodes.nfv.VDU
|
type: tosca.nodes.nfv.VDU
|
||||||
|
|
||||||
capabilities:
|
capabilities:
|
||||||
nfv_compute:
|
nfv_compute:
|
||||||
properties:
|
properties:
|
||||||
num_cpus: 8
|
num_cpus: 8
|
||||||
mem_size: 4096 # Memory Size in MB
|
mem_size: 4096 # Memory Size in MB
|
||||||
disk_size: 8 # Value in GB
|
disk_size: 8 # Value in GB
|
||||||
|
|
||||||
cpu_allocation:
|
cpu_allocation:
|
||||||
cpu_affinity: dedicated
|
cpu_affinity: dedicated
|
||||||
thread_allocation: isolate
|
thread_allocation: isolate
|
||||||
@ -190,7 +190,7 @@ An example of specifying Huge pages be used for a guest VM:
|
|||||||
node_templates:
|
node_templates:
|
||||||
VDU1:
|
VDU1:
|
||||||
type: tosca.nodes.nfv.VDU
|
type: tosca.nodes.nfv.VDU
|
||||||
|
|
||||||
capabilities:
|
capabilities:
|
||||||
nfv_compute:
|
nfv_compute:
|
||||||
properties:
|
properties:
|
||||||
@ -211,7 +211,7 @@ allocation of CPUs and RAM across NUMA nodes:
|
|||||||
node_templates:
|
node_templates:
|
||||||
VDU1:
|
VDU1:
|
||||||
type: tosca.nodes.nfv.VDU
|
type: tosca.nodes.nfv.VDU
|
||||||
|
|
||||||
capabilities:
|
capabilities:
|
||||||
nfv_compute:
|
nfv_compute:
|
||||||
properties:
|
properties:
|
||||||
@ -219,7 +219,7 @@ allocation of CPUs and RAM across NUMA nodes:
|
|||||||
mem_size: 6144
|
mem_size: 6144
|
||||||
disk_size: 8
|
disk_size: 8
|
||||||
numa_nodes:
|
numa_nodes:
|
||||||
|
|
||||||
node1:
|
node1:
|
||||||
id: 0
|
id: 0
|
||||||
vcpus: [ 0,1 ]
|
vcpus: [ 0,1 ]
|
||||||
@ -241,7 +241,7 @@ allocation of CPUs and RAM across NUMA nodes:
|
|||||||
node_templates:
|
node_templates:
|
||||||
VDU1:
|
VDU1:
|
||||||
type: tosca.nodes.nfv.VDU
|
type: tosca.nodes.nfv.VDU
|
||||||
|
|
||||||
capabilities:
|
capabilities:
|
||||||
nfv_compute:
|
nfv_compute:
|
||||||
properties:
|
properties:
|
||||||
@ -264,7 +264,7 @@ sockets, cores and thread count to be exposed to guest:
|
|||||||
node_templates:
|
node_templates:
|
||||||
VDU1:
|
VDU1:
|
||||||
type: tosca.nodes.nfv.VDU
|
type: tosca.nodes.nfv.VDU
|
||||||
|
|
||||||
capabilities:
|
capabilities:
|
||||||
nfv_compute:
|
nfv_compute:
|
||||||
properties:
|
properties:
|
||||||
@ -273,13 +273,13 @@ sockets, cores and thread count to be exposed to guest:
|
|||||||
disk_size: 80
|
disk_size: 80
|
||||||
mem_page_size: 1G
|
mem_page_size: 1G
|
||||||
cpu_allocation:
|
cpu_allocation:
|
||||||
|
|
||||||
cpu_affinity: dedicated
|
cpu_affinity: dedicated
|
||||||
thread_allocation: avoid
|
thread_allocation: avoid
|
||||||
socket_count: 2
|
socket_count: 2
|
||||||
core_count: 2
|
core_count: 2
|
||||||
thread_count: 2
|
thread_count: 2
|
||||||
|
|
||||||
numa_node_count: 2
|
numa_node_count: 2
|
||||||
|
|
||||||
|
|
||||||
@ -295,7 +295,7 @@ network interfaces and sriov nic types:
|
|||||||
node_templates:
|
node_templates:
|
||||||
VDU1:
|
VDU1:
|
||||||
type: tosca.nodes.nfv.VDU
|
type: tosca.nodes.nfv.VDU
|
||||||
|
|
||||||
capabilities:
|
capabilities:
|
||||||
nfv_compute:
|
nfv_compute:
|
||||||
properties:
|
properties:
|
||||||
@ -303,47 +303,47 @@ network interfaces and sriov nic types:
|
|||||||
mem_size: 4096 MB
|
mem_size: 4096 MB
|
||||||
disk_size: 8 GB
|
disk_size: 8 GB
|
||||||
mem_page_size: 1G
|
mem_page_size: 1G
|
||||||
|
|
||||||
cpu_allocation:
|
cpu_allocation:
|
||||||
cpu_affinity: dedicated
|
cpu_affinity: dedicated
|
||||||
thread_allocation: isolate
|
thread_allocation: isolate
|
||||||
socket_count: 2
|
socket_count: 2
|
||||||
core_count: 8
|
core_count: 8
|
||||||
thread_count: 4
|
thread_count: 4
|
||||||
|
|
||||||
numa_node_count: 2
|
numa_node_count: 2
|
||||||
|
|
||||||
CP11:
|
CP11:
|
||||||
type: tosca.nodes.nfv.CP
|
type: tosca.nodes.nfv.CP
|
||||||
|
|
||||||
requirements:
|
requirements:
|
||||||
- virtualbinding: VDU1
|
- virtualbinding: VDU1
|
||||||
- virtualLink: net_mgmt
|
- virtualLink: net_mgmt
|
||||||
|
|
||||||
CP12:
|
CP12:
|
||||||
type: tosca.nodes.nfv.CP
|
type: tosca.nodes.nfv.CP
|
||||||
|
|
||||||
properties:
|
properties:
|
||||||
anti_spoof_protection: false
|
anti_spoof_protection: false
|
||||||
type : sriov
|
type : sriov
|
||||||
requirements:
|
requirements:
|
||||||
- virtualbinding: VDU1
|
- virtualbinding: VDU1
|
||||||
- virtualLink: net_ingress
|
- virtualLink: net_ingress
|
||||||
|
|
||||||
CP13:
|
CP13:
|
||||||
type: tosca.nodes.nfv.CP
|
type: tosca.nodes.nfv.CP
|
||||||
|
|
||||||
properties:
|
properties:
|
||||||
anti_spoof_protection: false
|
anti_spoof_protection: false
|
||||||
type : sriov
|
type : sriov
|
||||||
|
|
||||||
requirements:
|
requirements:
|
||||||
- virtualbinding: VDU1
|
- virtualbinding: VDU1
|
||||||
- virtualLink: net_egress
|
- virtualLink: net_egress
|
||||||
|
|
||||||
net_mgmt:
|
net_mgmt:
|
||||||
type: tosca.nodes.nfv.VL.ELAN
|
type: tosca.nodes.nfv.VL.ELAN
|
||||||
|
|
||||||
net_ingress:
|
net_ingress:
|
||||||
type: tosca.nodes.nfv.VL.ELAN
|
type: tosca.nodes.nfv.VL.ELAN
|
||||||
|
|
||||||
@ -439,9 +439,9 @@ The document will be updated to guide how to use this feature.
|
|||||||
References
|
References
|
||||||
==========
|
==========
|
||||||
|
|
||||||
.. [#] `<http://docs.openstack.org/developer/nova/testing/libvirt-numa.html>`_
|
* http://docs.openstack.org/developer/nova/testing/libvirt-numa.html
|
||||||
.. [#] `<http://redhatstackblog.redhat.com/2015/05/05/cpu-pinning-and-numa-topology-awareness-in-openstack-compute/>`_
|
* http://redhatstackblog.redhat.com/2015/05/05/cpu-pinning-and-numa-topology-awareness-in-openstack-compute/
|
||||||
.. [#] `<https://wiki.openstack.org/wiki/VirtDriverGuestCPUMemoryPlacement>`_
|
* https://wiki.openstack.org/wiki/VirtDriverGuestCPUMemoryPlacement
|
||||||
.. [#] `<https://specs.openstack.org/openstack/nova-specs/specs/kilo/implemented/input-output-based-numa-scheduling.html>`_
|
* https://specs.openstack.org/openstack/nova-specs/specs/kilo/implemented/input-output-based-numa-scheduling.html
|
||||||
.. [#] `<http://specs.openstack.org/openstack/nova-specs/specs/mitaka/approved/virt-driver-cpu-pinning.html>`_
|
* http://specs.openstack.org/openstack/nova-specs/specs/mitaka/approved/virt-driver-cpu-pinning.html
|
||||||
.. [#] `<http://redhatstackblog.redhat.com/2015/03/05/red-hat-enterprise-linux-openstack-platform-6-sr-iov-networking-part-i-understanding-the-basics/>`_
|
* http://redhatstackblog.redhat.com/2015/03/05/red-hat-enterprise-linux-openstack-platform-6-sr-iov-networking-part-i-understanding-the-basics/
|
||||||
|
|||||||
@ -16,22 +16,22 @@ Problem description
|
|||||||
===================
|
===================
|
||||||
|
|
||||||
Tacker uses a private YAML format for VNFD templates that bears a passing
|
Tacker uses a private YAML format for VNFD templates that bears a passing
|
||||||
resemblance to TOSCA but has custom tags and far fewer capabilities. Tacker
|
resemblance to TOSCA but has custom tags and far fewer capabilities. Tacker
|
||||||
also does it's own translation of the VNFD into a Heat template, which
|
also does it's own translation of the VNFD into a Heat template, which
|
||||||
requires maintenance and has far fewer capabilities than other existing
|
requires maintenance and has far fewer capabilities than other existing
|
||||||
projects.
|
projects.
|
||||||
|
|
||||||
This spec documents the changes required in Tacker to support using
|
This spec documents the changes required in Tacker to support using
|
||||||
tosca-parser and heat-translator instead of the existing YAML format
|
tosca-parser and heat-translator instead of the existing YAML format
|
||||||
and custom Heat template generator. Tacker will use heat-translator to
|
and custom Heat template generator. Tacker will use heat-translator to
|
||||||
create the base HOT template, and will make whatever modifications are
|
create the base HOT template, and will make whatever modifications are
|
||||||
needed to support the rapidly-evolving NFV profile.
|
needed to support the rapidly-evolving NFV profile.
|
||||||
|
|
||||||
Proposed change
|
Proposed change
|
||||||
===============
|
===============
|
||||||
|
|
||||||
There tosca-parser[#]_ and heat-translator[#]_ projects have been updated to
|
There tosca-parser [#]_ and heat-translator [#]_ projects have been updated to
|
||||||
support the TOSCA NFV Profile. The tosca-parser project has also accepted
|
support the TOSCA NFV Profile [#]_. The tosca-parser project has also accepted
|
||||||
a patch to allow it to be used by a server providing a pre-formatted YAML
|
a patch to allow it to be used by a server providing a pre-formatted YAML
|
||||||
dictionary instead of a file or URL containing the template.
|
dictionary instead of a file or URL containing the template.
|
||||||
|
|
||||||
@ -40,11 +40,11 @@ and heat-translator projects to eventually replace the custom YAML template
|
|||||||
and HOT template generation used by Tacker today.
|
and HOT template generation used by Tacker today.
|
||||||
|
|
||||||
The initial implementation will coexist with the existing Tacker YAML format,
|
The initial implementation will coexist with the existing Tacker YAML format,
|
||||||
and the interfaces will remain the same. Future work will be required
|
and the interfaces will remain the same. Future work will be required
|
||||||
to separate the TOSCA template processing from the Heat driver and
|
to separate the TOSCA template processing from the Heat driver and
|
||||||
remove the existing template processing.
|
remove the existing template processing.
|
||||||
|
|
||||||
Parameters will be handled as they are today. Both tosca-parser and
|
Parameters will be handled as they are today. Both tosca-parser and
|
||||||
heat-translator accept parameter inputs to be applied to the resulting
|
heat-translator accept parameter inputs to be applied to the resulting
|
||||||
template.
|
template.
|
||||||
|
|
||||||
@ -53,12 +53,12 @@ tosca_simple_profile_for_nfv_1_0_0 profiles in the version field.
|
|||||||
|
|
||||||
Tacker-specific data such as management drivers and monitoring drivers
|
Tacker-specific data such as management drivers and monitoring drivers
|
||||||
will be added to the existing NFV object definitions for use in the TOSCA
|
will be added to the existing NFV object definitions for use in the TOSCA
|
||||||
template. All Tacker extensions will need to be removed from the
|
template. All Tacker extensions will need to be removed from the
|
||||||
translated ToscaTemplate before it is passed to the ToscaTranslator for
|
translated ToscaTemplate before it is passed to the ToscaTranslator for
|
||||||
conversion to HOT.
|
conversion to HOT.
|
||||||
|
|
||||||
The tacker_defs.yaml file will define Tacker-specific types that are
|
The tacker_defs.yaml file will define Tacker-specific types that are
|
||||||
not specific to NFV profile types. The tacker_nfv_defs.yaml file will
|
not specific to NFV profile types. The tacker_nfv_defs.yaml file will
|
||||||
define Tacker-specific NFV types. These files will be
|
define Tacker-specific NFV types. These files will be
|
||||||
automatically added as an import to all VNFDs when they are created, based
|
automatically added as an import to all VNFDs when they are created, based
|
||||||
on the version of the template. The imports must be added by the Tacker
|
on the version of the template. The imports must be added by the Tacker
|
||||||
@ -199,7 +199,7 @@ Data model impact
|
|||||||
-----------------
|
-----------------
|
||||||
|
|
||||||
Initial support for tosca-parser/heat-translator will have no data model
|
Initial support for tosca-parser/heat-translator will have no data model
|
||||||
impact. Future changes may be required to add the ability to specify
|
impact. Future changes may be required to add the ability to specify
|
||||||
multiple different management drivers for different VDUs, and to handle
|
multiple different management drivers for different VDUs, and to handle
|
||||||
CSAR files.
|
CSAR files.
|
||||||
|
|
||||||
@ -234,7 +234,7 @@ Other deployer impact
|
|||||||
---------------------
|
---------------------
|
||||||
|
|
||||||
The plan is to support the existing YAML format and TOSCA together through
|
The plan is to support the existing YAML format and TOSCA together through
|
||||||
the Mitaka cycle. The existing YAML format will be deprecated in Mitaka
|
the Mitaka cycle. The existing YAML format will be deprecated in Mitaka
|
||||||
and removed in Newton.
|
and removed in Newton.
|
||||||
|
|
||||||
Developer impact
|
Developer impact
|
||||||
@ -255,7 +255,7 @@ Work Items
|
|||||||
----------
|
----------
|
||||||
|
|
||||||
- Develop tacker_defs.yaml file to extend the existing TOSCA NFV node
|
- Develop tacker_defs.yaml file to extend the existing TOSCA NFV node
|
||||||
definitions with the properties required by Tacker. File to be stored
|
definitions with the properties required by Tacker. File to be stored
|
||||||
in tacker/vm/tosca/lib
|
in tacker/vm/tosca/lib
|
||||||
|
|
||||||
- Create module tacker.vm.tosca.utils to provide utility methods to manipulate
|
- Create module tacker.vm.tosca.utils to provide utility methods to manipulate
|
||||||
@ -268,7 +268,7 @@ Work Items
|
|||||||
|
|
||||||
- Modify the existing heat driver create() method to detect a TOSCA template
|
- Modify the existing heat driver create() method to detect a TOSCA template
|
||||||
and invoke tosca-parser (ToscaTemplate) and heat-translator (TOSCATranslator)
|
and invoke tosca-parser (ToscaTemplate) and heat-translator (TOSCATranslator)
|
||||||
to generate the HOT template. The generated ToscaTemplate will need to be
|
to generate the HOT template. The generated ToscaTemplate will need to be
|
||||||
processed to remove the Tacker-specific nodes and properties before it
|
processed to remove the Tacker-specific nodes and properties before it
|
||||||
can be processed by TOSCATranslator to generate the HOT template.
|
can be processed by TOSCATranslator to generate the HOT template.
|
||||||
|
|
||||||
@ -292,11 +292,10 @@ Documentation Impact
|
|||||||
|
|
||||||
Documentation of the Tacker-specific extensions to the NFV Profile as defined
|
Documentation of the Tacker-specific extensions to the NFV Profile as defined
|
||||||
by tacker_defs.yaml will be needed, and sample TOSCA templates will need to be
|
by tacker_defs.yaml will be needed, and sample TOSCA templates will need to be
|
||||||
provided. Devstack sample templates will also be needed.
|
provided. Devstack sample templates will also be needed.
|
||||||
|
|
||||||
References
|
References
|
||||||
==========
|
==========
|
||||||
.. [#] https://blueprints.launchpad.net/tosca-parser/+spec/tosca-nfv-support
|
.. [#] https://blueprints.launchpad.net/tosca-parser/+spec/tosca-nfv-support
|
||||||
.. [#] https://blueprints.launchpad.net/heat-translator/+spec/tosca-nfv-support
|
.. [#] https://blueprints.launchpad.net/heat-translator/+spec/tosca-nfv-support
|
||||||
.. [#] TOSCA Simple Profile for Network Functions - http://docs.oasis-open.org/tosca/tosca-nfv/v1.0/csd02/tosca-nfv-v1.0-csd02.html
|
.. [#] TOSCA Simple Profile for Network Functions - http://docs.oasis-open.org/tosca/tosca-nfv/v1.0/tosca-nfv-v1.0.html
|
||||||
|
|
||||||
|
|||||||
@ -262,4 +262,4 @@ New User and Developer guide will be provided.
|
|||||||
|
|
||||||
References
|
References
|
||||||
==========
|
==========
|
||||||
None
|
None
|
||||||
|
|||||||
@ -40,11 +40,11 @@ administrators as they add tacker-server instances for scaling.
|
|||||||
Barbican introduction
|
Barbican introduction
|
||||||
=====================
|
=====================
|
||||||
|
|
||||||
Barbican[1] is a REST API designed for the secure storage, provisioning and
|
Barbican [1]_ is a REST API designed for the secure storage, provisioning and
|
||||||
management of secrets. It is aimed at being useful for all environments,
|
management of secrets. It is aimed at being useful for all environments,
|
||||||
including large ephemeral Clouds.
|
including large ephemeral Clouds.
|
||||||
|
|
||||||
The barbican API [2] includes the following items:
|
The barbican API [2]_ includes the following items:
|
||||||
|
|
||||||
* Secrets API. It provides access to the secret / keying material stored
|
* Secrets API. It provides access to the secret / keying material stored
|
||||||
in the system, including Private Key/Certificate/Password/SSH Keys
|
in the system, including Private Key/Certificate/Password/SSH Keys
|
||||||
@ -118,21 +118,21 @@ Invoked in Nova or Cinder
|
|||||||
-------------------------
|
-------------------------
|
||||||
|
|
||||||
Barbican is introduced into nova and cinder to support the volume
|
Barbican is introduced into nova and cinder to support the volume
|
||||||
encryption feature [3][4].
|
encryption feature [3]_ [4]_.
|
||||||
They invoke castellan as key_mamager, allowing Barbican to securely
|
They invoke castellan as key_mamager, allowing Barbican to securely
|
||||||
generate, store, and present encryption keys.
|
generate, store, and present encryption keys.
|
||||||
|
|
||||||
Invoked in Neutron-lbaas or Magnum
|
Invoked in Neutron-lbaas or Magnum
|
||||||
----------------------------------
|
----------------------------------
|
||||||
|
|
||||||
Neutron-lbaas and Magnum introduces barbican to support TLS [5][6].
|
Neutron-lbaas and Magnum introduces barbican to support TLS [5]_ [6]_.
|
||||||
They invoke barbicanclient directly to store tenants' TLS certificates in
|
They invoke barbicanclient directly to store tenants' TLS certificates in
|
||||||
barbican secure containers.
|
barbican secure containers.
|
||||||
|
|
||||||
Castellan introduction
|
Castellan introduction
|
||||||
----------------------
|
----------------------
|
||||||
|
|
||||||
Castellan[7] is the library of Barbican, working on the principle of providing
|
Castellan [7]_ is the library of Barbican, working on the principle of providing
|
||||||
an abstracted key manager based on the configurations. In this manner,
|
an abstracted key manager based on the configurations. In this manner,
|
||||||
several different management services can be supported through a single
|
several different management services can be supported through a single
|
||||||
interface. In addition to the key manager, Castellan also provides primitives
|
interface. In addition to the key manager, Castellan also provides primitives
|
||||||
@ -188,7 +188,7 @@ How to use castellan
|
|||||||
How to use barbicanclient
|
How to use barbicanclient
|
||||||
-------------------------
|
-------------------------
|
||||||
|
|
||||||
We can refer to castellan to see how to invoke barbicanclient [12]:
|
We can refer to castellan to see how to invoke barbicanclient [12]_:
|
||||||
|
|
||||||
store secret:
|
store secret:
|
||||||
|
|
||||||
@ -240,7 +240,7 @@ There are two methods to generate the context.
|
|||||||
|
|
||||||
1. Using a reserved project
|
1. Using a reserved project
|
||||||
|
|
||||||
Castellan Usage[8] shows a method, saving the credentials in configuration.
|
Castellan Usage [8]_ shows a method, saving the credentials in configuration.
|
||||||
We can create a reserved tenant (e.g. 'tacker-vim-credential-store' or
|
We can create a reserved tenant (e.g. 'tacker-vim-credential-store' or
|
||||||
long living existing created user), and all vims' passwords are saved and
|
long living existing created user), and all vims' passwords are saved and
|
||||||
retrieved in this tenant's domain.
|
retrieved in this tenant's domain.
|
||||||
@ -258,7 +258,7 @@ As discussion in IRC [11], we should not do in this way.
|
|||||||
|
|
||||||
2. Using the operator's context (who creates vim)
|
2. Using the operator's context (who creates vim)
|
||||||
|
|
||||||
The default RBAC policy[9] about secrets are following:
|
The default RBAC policy [9]_ about secrets are following:
|
||||||
|
|
||||||
.. code-block:: ini
|
.. code-block:: ini
|
||||||
|
|
||||||
@ -290,10 +290,10 @@ The default RBAC policy[9] about secrets are following:
|
|||||||
"secrets:get": "rule:all_but_audit",
|
"secrets:get": "rule:all_but_audit",
|
||||||
|
|
||||||
The barbican support a white-list ACL for each secret. It is not
|
The barbican support a white-list ACL for each secret. It is not
|
||||||
convenient to add all projects to the ACL [10] if vim is shared.
|
convenient to add all projects to the ACL [10]_ if vim is shared.
|
||||||
|
|
||||||
In this method, we can not support shared vim. As result of IRC
|
In this method, we can not support shared vim. As result of IRC
|
||||||
discussion [11], in future, vim is limited to be shared with
|
discussion [11]_, in future, vim is limited to be shared with
|
||||||
specified projects via rbac policies, we may add these projects
|
specified projects via rbac policies, we may add these projects
|
||||||
into the ACL of the secret.
|
into the ACL of the secret.
|
||||||
|
|
||||||
|
|||||||
@ -32,22 +32,22 @@ Proposed change
|
|||||||
|
|
||||||
asciiflow::
|
asciiflow::
|
||||||
|
|
||||||
+---------------------+
|
+---------------------+
|
||||||
| mistral workflow |
|
| Mistral workflow |
|
||||||
+-------> vim monitor action |
|
+-------> VIM monitor action |
|
||||||
+--------------+ | | |
|
+--------------+ | | |
|
||||||
| Tacker server+-----+ +------------------+--+
|
| Tacker server+-----+ +------------------+--+
|
||||||
+-----+--------+ |
|
+-----+--------+ |
|
||||||
| |
|
| |
|
||||||
| |
|
| |
|
||||||
| +-------v----------+
|
| +-------v----------+
|
||||||
| | |
|
| | |
|
||||||
| | conductor server |
|
| | Conductor server |
|
||||||
| +------------+ +------+ |
|
| +------------+ +------+ |
|
||||||
| | | | +------------------+
|
| | | | +------------------+
|
||||||
+-------> tacker DB <-----+
|
+-------> Tacker DB <-----+
|
||||||
| |
|
| |
|
||||||
+-------------
|
+------------+
|
||||||
|
|
||||||
|
|
||||||
Since Mistral is an integral part of tacker system, a long-live Mistral workflow
|
Since Mistral is an integral part of tacker system, a long-live Mistral workflow
|
||||||
@ -71,14 +71,14 @@ with the conductor via the following interface VimMonitor:
|
|||||||
|
|
||||||
.. code-block:: python
|
.. code-block:: python
|
||||||
|
|
||||||
class VimMonitorAction2ConductorRPC(object)
|
class VimMonitorAction2ConductorRPC(object)
|
||||||
# update vim's status, action_id is the task action
|
# update vim's status, action_id is the task action
|
||||||
def update_vim (vim_id, status, action_id):
|
def update_vim (vim_id, status, action_id):
|
||||||
# The response message containing the operation result
|
# The response message containing the operation result
|
||||||
# the status should be the passed in by request or 'bad_action'
|
# the status should be the passed in by request or 'bad_action'
|
||||||
# if the action is not the wanted action.
|
# if the action is not the wanted action.
|
||||||
status = rpc call conductor
|
status = rpc call conductor
|
||||||
return status
|
return status
|
||||||
|
|
||||||
|
|
||||||
sequence diagram for register vim:
|
sequence diagram for register vim:
|
||||||
@ -133,12 +133,12 @@ Another way to use mistral is to use a loop workflow:
|
|||||||
|
|
||||||
asciiflow::
|
asciiflow::
|
||||||
|
|
||||||
start_task -----> ping_task ------> update_task
|
start_task -----> ping_task ------> update_task
|
||||||
^ |
|
^ |
|
||||||
| |
|
| |
|
||||||
| |
|
| |
|
||||||
| on_succes |
|
| on_succes |
|
||||||
---------------+
|
+---------------+
|
||||||
|
|
||||||
|
|
||||||
But Mistral will save task executions into Mistral database, so the loop
|
But Mistral will save task executions into Mistral database, so the loop
|
||||||
|
|||||||
@ -34,28 +34,28 @@ Proposed change
|
|||||||
|
|
||||||
asciiflow::
|
asciiflow::
|
||||||
|
|
||||||
+---------------------+
|
+---------------------+
|
||||||
| Mistral workflow |
|
| Mistral workflow |
|
||||||
+-(1)---> VNF monitor action |
|
+-(1)---> VNF monitor action |
|
||||||
+---------------+ | | |
|
+---------------+ | | |
|
||||||
| Tacker server +----+ +--------^------------+
|
| Tacker server +----+ +--------^------------+
|
||||||
+-----+---------+ |
|
+-----+---------+ |
|
||||||
| | |
|
| | |
|
||||||
| | |
|
| | |
|
||||||
| | |
|
| | |
|
||||||
| | |
|
| | |
|
||||||
| | +--------v----+
|
| | +--------v----+
|
||||||
| |----(3)--------> MSG Queue <----+
|
| |----(3)--------> MSG Queue <----+
|
||||||
| +-------------+ (2)
|
| +-------------+ (2)
|
||||||
| |
|
| |
|
||||||
| +-------v----------+
|
| +-------v----------+
|
||||||
| | Tacker |
|
| | Tacker |
|
||||||
| | conductor server |
|
| | conductor server |
|
||||||
| +------+-----+ +------+ |
|
| +------+-----+ +------+ |
|
||||||
| | | | +------------------+
|
| | | | +------------------+
|
||||||
+-------> Tacker DB <-----+
|
+-------> Tacker DB <-----+
|
||||||
| |
|
| |
|
||||||
+-------------
|
+------------+
|
||||||
|
|
||||||
|
|
||||||
(1) Since Mistral is an integral part of tacker system, a long-live Mistral
|
(1) Since Mistral is an integral part of tacker system, a long-live Mistral
|
||||||
@ -81,15 +81,15 @@ VNFPolicyActionRPC:
|
|||||||
|
|
||||||
.. code-block:: python
|
.. code-block:: python
|
||||||
|
|
||||||
class VNFPolicyActionRPC(object)
|
class VNFPolicyActionRPC(object)
|
||||||
# execute policy action
|
# execute policy action
|
||||||
def execute_policy_action(context, vnf, monitor_return_value,
|
def execute_policy_action(context, vnf, monitor_return_value,
|
||||||
policy_actions, action_id):
|
policy_actions, action_id):
|
||||||
# The response message containing the operation result
|
# The response message containing the operation result
|
||||||
# the status should be the passed in by request or 'bad_action'
|
# the status should be the passed in by request or 'bad_action'
|
||||||
# if the action is not the wanted action.
|
# if the action is not the wanted action.
|
||||||
status = rpc call conductor
|
status = rpc call conductor
|
||||||
return status
|
return status
|
||||||
|
|
||||||
|
|
||||||
After workflow is removed due to VNF change or removal, VNFM plugin kills the mistral
|
After workflow is removed due to VNF change or removal, VNFM plugin kills the mistral
|
||||||
@ -97,14 +97,14 @@ action via the following interface VNFPolicyMonitorRPC asynchronously:
|
|||||||
|
|
||||||
.. code-block:: python
|
.. code-block:: python
|
||||||
|
|
||||||
class VNFPolicyMonitorRPC(object)
|
class VNFPolicyMonitorRPC(object)
|
||||||
# kill the mistral action job
|
# kill the mistral action job
|
||||||
def kill(context, action_id):
|
def kill(context, action_id):
|
||||||
pass
|
pass
|
||||||
|
|
||||||
# update the mistral action job
|
# update the mistral action job
|
||||||
def update(context, action_id, parameter):
|
def update(context, action_id, parameter):
|
||||||
pass
|
pass
|
||||||
|
|
||||||
|
|
||||||
The update method in above interface is used to notify policy monitor that changes
|
The update method in above interface is used to notify policy monitor that changes
|
||||||
|
|||||||
@ -153,9 +153,9 @@ One TOSCA template can support multiple VBs and CBs.
|
|||||||
node_templates:
|
node_templates:
|
||||||
VDU1:
|
VDU1:
|
||||||
type: tosca.nodes.nfv.VDU.Tacker
|
type: tosca.nodes.nfv.VDU.Tacker
|
||||||
properties:
|
properties:
|
||||||
image: centos
|
image: centos
|
||||||
flavor: centos
|
flavor: centos
|
||||||
|
|
||||||
CP1:
|
CP1:
|
||||||
type: tosca.nodes.nfv.CP.Tacker
|
type: tosca.nodes.nfv.CP.Tacker
|
||||||
@ -199,8 +199,8 @@ the volume when VDU deleting.
|
|||||||
node_templates:
|
node_templates:
|
||||||
VDU1:
|
VDU1:
|
||||||
type: tosca.nodes.nfv.VDU.Tacker
|
type: tosca.nodes.nfv.VDU.Tacker
|
||||||
properties:
|
properties:
|
||||||
flavor: centos
|
flavor: centos
|
||||||
requirements:
|
requirements:
|
||||||
- local_storage:
|
- local_storage:
|
||||||
node: VB1
|
node: VB1
|
||||||
@ -306,4 +306,4 @@ None
|
|||||||
References
|
References
|
||||||
==========
|
==========
|
||||||
|
|
||||||
.. [1] http://docs.oasis-open.org/tosca/TOSCA-Simple-Profile-YAML/v1.0/csprd01/TOSCA-Simple-Profile-YAML-v1.0-csprd01.html#_Toc430015836
|
* http://docs.oasis-open.org/tosca/TOSCA-Simple-Profile-YAML/v1.0/csprd01/TOSCA-Simple-Profile-YAML-v1.0-csprd01.html#_Toc430015836
|
||||||
|
|||||||
@ -386,6 +386,6 @@ None
|
|||||||
|
|
||||||
References
|
References
|
||||||
==========
|
==========
|
||||||
.. [#first] https://www.zabbix.com/documentation/3.0/manual
|
* https://www.zabbix.com/documentation/3.2/manual
|
||||||
.. [#second] https://share.zabbix.com/
|
* https://share.zabbix.com/
|
||||||
.. [#third] https://www.nagios.org/documentation/
|
* https://www.nagios.org/documentation/
|
||||||
|
|||||||
@ -4,54 +4,82 @@
|
|||||||
|
|
||||||
http://creativecommons.org/licenses/by/3.0/legalcode
|
http://creativecommons.org/licenses/by/3.0/legalcode
|
||||||
|
|
||||||
=======================
|
==================
|
||||||
Title of your blueprint
|
(Placeholder Spec)
|
||||||
=======================
|
==================
|
||||||
|
|
||||||
|
This file is just a placeholder for the specs directory.
|
||||||
|
It will be removed soon after some spec is merged.
|
||||||
|
|
||||||
|
The latest spec template is found at ``specs/template.rst``
|
||||||
|
in the ``tacker-specs`` repository.
|
||||||
|
|
||||||
Problem description
|
Problem description
|
||||||
===================
|
===================
|
||||||
|
|
||||||
|
Sphinx toctree complains if no file exists in a directory
|
||||||
|
specified in toctree glob.
|
||||||
|
|
||||||
|
Use Cases
|
||||||
|
---------
|
||||||
|
|
||||||
|
None
|
||||||
|
|
||||||
Proposed change
|
Proposed change
|
||||||
===============
|
===============
|
||||||
|
|
||||||
|
Add this file. Please remove later when the another spec is approved.
|
||||||
|
|
||||||
Alternatives
|
Alternatives
|
||||||
------------
|
------------
|
||||||
|
|
||||||
|
None
|
||||||
|
|
||||||
Data model impact
|
Data model impact
|
||||||
-----------------
|
-----------------
|
||||||
|
|
||||||
|
None
|
||||||
|
|
||||||
REST API impact
|
REST API impact
|
||||||
---------------
|
---------------
|
||||||
|
|
||||||
|
None
|
||||||
|
|
||||||
Security impact
|
Security impact
|
||||||
---------------
|
---------------
|
||||||
|
|
||||||
|
None
|
||||||
|
|
||||||
Notifications impact
|
Notifications impact
|
||||||
--------------------
|
--------------------
|
||||||
|
|
||||||
|
None
|
||||||
|
|
||||||
Other end user impact
|
Other end user impact
|
||||||
---------------------
|
---------------------
|
||||||
|
|
||||||
|
None
|
||||||
|
|
||||||
Performance Impact
|
Performance Impact
|
||||||
------------------
|
------------------
|
||||||
|
|
||||||
|
None
|
||||||
|
|
||||||
Other deployer impact
|
Other deployer impact
|
||||||
---------------------
|
---------------------
|
||||||
|
|
||||||
|
None
|
||||||
|
|
||||||
Developer impact
|
Developer impact
|
||||||
----------------
|
----------------
|
||||||
|
|
||||||
|
None
|
||||||
|
|
||||||
|
Upgrade impact
|
||||||
|
--------------
|
||||||
|
|
||||||
|
None
|
||||||
|
|
||||||
|
|
||||||
Implementation
|
Implementation
|
||||||
==============
|
==============
|
||||||
@ -59,24 +87,38 @@ Implementation
|
|||||||
Assignee(s)
|
Assignee(s)
|
||||||
-----------
|
-----------
|
||||||
|
|
||||||
|
None
|
||||||
|
|
||||||
Work Items
|
Work Items
|
||||||
----------
|
----------
|
||||||
|
|
||||||
|
None
|
||||||
|
|
||||||
|
|
||||||
Dependencies
|
Dependencies
|
||||||
============
|
============
|
||||||
|
|
||||||
|
None
|
||||||
|
|
||||||
|
|
||||||
Testing
|
Testing
|
||||||
=======
|
=======
|
||||||
|
|
||||||
|
None
|
||||||
|
|
||||||
|
|
||||||
Documentation Impact
|
Documentation Impact
|
||||||
====================
|
====================
|
||||||
|
|
||||||
|
None
|
||||||
|
|
||||||
References
|
References
|
||||||
==========
|
==========
|
||||||
|
|
||||||
|
None
|
||||||
|
|
||||||
|
|
||||||
|
History
|
||||||
|
=======
|
||||||
|
|
||||||
|
None
|
||||||
9
specs/stein/index.rst
Normal file
9
specs/stein/index.rst
Normal file
@ -0,0 +1,9 @@
|
|||||||
|
===========================
|
||||||
|
Tacker Stein Specifications
|
||||||
|
===========================
|
||||||
|
|
||||||
|
.. toctree::
|
||||||
|
:glob:
|
||||||
|
:maxdepth: 1
|
||||||
|
|
||||||
|
*
|
||||||
124
specs/stein/placeholder.rst
Normal file
124
specs/stein/placeholder.rst
Normal file
@ -0,0 +1,124 @@
|
|||||||
|
..
|
||||||
|
This work is licensed under a Creative Commons Attribution 3.0 Unported
|
||||||
|
License.
|
||||||
|
|
||||||
|
http://creativecommons.org/licenses/by/3.0/legalcode
|
||||||
|
|
||||||
|
==================
|
||||||
|
(Placeholder Spec)
|
||||||
|
==================
|
||||||
|
|
||||||
|
This file is just a placeholder for the specs directory.
|
||||||
|
It will be removed soon after some spec is merged.
|
||||||
|
|
||||||
|
The latest spec template is found at ``specs/template.rst``
|
||||||
|
in the ``tacker-specs`` repository.
|
||||||
|
|
||||||
|
Problem description
|
||||||
|
===================
|
||||||
|
|
||||||
|
Sphinx toctree complains if no file exists in a directory
|
||||||
|
specified in toctree glob.
|
||||||
|
|
||||||
|
Use Cases
|
||||||
|
---------
|
||||||
|
|
||||||
|
None
|
||||||
|
|
||||||
|
Proposed change
|
||||||
|
===============
|
||||||
|
|
||||||
|
Add this file. Please remove later when the another spec is approved.
|
||||||
|
|
||||||
|
Alternatives
|
||||||
|
------------
|
||||||
|
|
||||||
|
None
|
||||||
|
|
||||||
|
Data model impact
|
||||||
|
-----------------
|
||||||
|
|
||||||
|
None
|
||||||
|
|
||||||
|
REST API impact
|
||||||
|
---------------
|
||||||
|
|
||||||
|
None
|
||||||
|
|
||||||
|
Security impact
|
||||||
|
---------------
|
||||||
|
|
||||||
|
None
|
||||||
|
|
||||||
|
Notifications impact
|
||||||
|
--------------------
|
||||||
|
|
||||||
|
None
|
||||||
|
|
||||||
|
Other end user impact
|
||||||
|
---------------------
|
||||||
|
|
||||||
|
None
|
||||||
|
|
||||||
|
Performance Impact
|
||||||
|
------------------
|
||||||
|
|
||||||
|
None
|
||||||
|
|
||||||
|
Other deployer impact
|
||||||
|
---------------------
|
||||||
|
|
||||||
|
None
|
||||||
|
|
||||||
|
Developer impact
|
||||||
|
----------------
|
||||||
|
|
||||||
|
None
|
||||||
|
|
||||||
|
Upgrade impact
|
||||||
|
--------------
|
||||||
|
|
||||||
|
None
|
||||||
|
|
||||||
|
|
||||||
|
Implementation
|
||||||
|
==============
|
||||||
|
|
||||||
|
Assignee(s)
|
||||||
|
-----------
|
||||||
|
|
||||||
|
None
|
||||||
|
|
||||||
|
Work Items
|
||||||
|
----------
|
||||||
|
|
||||||
|
None
|
||||||
|
|
||||||
|
|
||||||
|
Dependencies
|
||||||
|
============
|
||||||
|
|
||||||
|
None
|
||||||
|
|
||||||
|
|
||||||
|
Testing
|
||||||
|
=======
|
||||||
|
|
||||||
|
None
|
||||||
|
|
||||||
|
|
||||||
|
Documentation Impact
|
||||||
|
====================
|
||||||
|
|
||||||
|
None
|
||||||
|
|
||||||
|
References
|
||||||
|
==========
|
||||||
|
|
||||||
|
None
|
||||||
|
|
||||||
|
|
||||||
|
History
|
||||||
|
=======
|
||||||
|
|
||||||
|
None
|
||||||
5
test-requirements.txt
Normal file
5
test-requirements.txt
Normal file
@ -0,0 +1,5 @@
|
|||||||
|
# The order of packages is significant, because pip processes them in the order
|
||||||
|
# of appearance. Changing the order has an impact on the overall integration
|
||||||
|
# process, which may cause wedges in the gate later.
|
||||||
|
flake8
|
||||||
|
doc8>=0.6.0 # Apache-2.0
|
||||||
@ -1,97 +0,0 @@
|
|||||||
# Licensed under the Apache License, Version 2.0 (the "License"); you may
|
|
||||||
# not use this file except in compliance with the License. You may obtain
|
|
||||||
# a copy of the License at
|
|
||||||
#
|
|
||||||
# http://www.apache.org/licenses/LICENSE-2.0
|
|
||||||
#
|
|
||||||
# Unless required by applicable law or agreed to in writing, software
|
|
||||||
# distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
|
|
||||||
# WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
|
|
||||||
# License for the specific language governing permissions and limitations
|
|
||||||
# under the License.
|
|
||||||
|
|
||||||
import glob
|
|
||||||
import re
|
|
||||||
|
|
||||||
import docutils.core
|
|
||||||
from docutils.parsers import rst
|
|
||||||
from docutils.parsers.rst import directives
|
|
||||||
import testtools
|
|
||||||
|
|
||||||
|
|
||||||
class FakeDirective(rst.Directive):
|
|
||||||
has_content = True
|
|
||||||
def run(self):
|
|
||||||
return []
|
|
||||||
|
|
||||||
|
|
||||||
directives.register_directive('seqdiag', FakeDirective)
|
|
||||||
directives.register_directive('blockdiag', FakeDirective)
|
|
||||||
directives.register_directive('nwdiag', FakeDirective)
|
|
||||||
directives.register_directive('actdiag', FakeDirective)
|
|
||||||
|
|
||||||
|
|
||||||
class TestTitles(testtools.TestCase):
|
|
||||||
def _get_title(self, section_tree):
|
|
||||||
section = {
|
|
||||||
'subtitles': [],
|
|
||||||
}
|
|
||||||
for node in section_tree:
|
|
||||||
if node.tagname == 'title':
|
|
||||||
section['name'] = node.rawsource
|
|
||||||
elif node.tagname == 'section':
|
|
||||||
subsection = self._get_title(node)
|
|
||||||
section['subtitles'].append(subsection['name'])
|
|
||||||
return section
|
|
||||||
|
|
||||||
def _get_titles(self, spec):
|
|
||||||
titles = {}
|
|
||||||
for node in spec:
|
|
||||||
if node.tagname == 'section':
|
|
||||||
section = self._get_title(node)
|
|
||||||
titles[section['name']] = section['subtitles']
|
|
||||||
return titles
|
|
||||||
|
|
||||||
def _check_trailing_spaces(self, tpl, raw):
|
|
||||||
for i, line in enumerate(raw.split("\n")):
|
|
||||||
trailing_spaces = re.findall(" +$", line)
|
|
||||||
self.assertEqual(
|
|
||||||
0, len(trailing_spaces),
|
|
||||||
"Found trailing spaces on line %s of %s" % (i+1, tpl))
|
|
||||||
|
|
||||||
def _check_titles(self, titles):
|
|
||||||
# No explicit titles check, leaving this as a placeholder
|
|
||||||
return
|
|
||||||
|
|
||||||
def test_template(self):
|
|
||||||
releases = [x.split('/')[1] for x in glob.glob('specs/*/')]
|
|
||||||
for release in releases:
|
|
||||||
if release[0] < 'm':
|
|
||||||
# Don't bother enforcement for specs before Mitaka,
|
|
||||||
# or that belong to 'archive' and 'backlog'
|
|
||||||
continue
|
|
||||||
try:
|
|
||||||
# Support release-specific template.
|
|
||||||
with open("specs/%s-template.rst" % release) as f:
|
|
||||||
template = f.read()
|
|
||||||
except IOError:
|
|
||||||
# Base template if release template not found.
|
|
||||||
with open("specs/template.rst") as f:
|
|
||||||
template = f.read()
|
|
||||||
spec = docutils.core.publish_doctree(template)
|
|
||||||
template_titles = self._get_titles(spec)
|
|
||||||
|
|
||||||
files = glob.glob("specs/%s/*" % release)
|
|
||||||
for filename in files:
|
|
||||||
self.assertTrue(filename.endswith(".rst"),
|
|
||||||
"spec's file must uses 'rst' extension.")
|
|
||||||
|
|
||||||
with open(filename) as f:
|
|
||||||
data = f.read()
|
|
||||||
spec = docutils.core.publish_doctree(data)
|
|
||||||
titles = self._get_titles(spec)
|
|
||||||
self._check_titles(titles)
|
|
||||||
# TODO(kanagaraj-manickam): Fix the same old specs as well
|
|
||||||
if filename.startswith('specs/newton') or \
|
|
||||||
filename.startswith('specs/ocata'):
|
|
||||||
self._check_trailing_spaces(filename, data)
|
|
||||||
24
tox.ini
24
tox.ini
@ -1,17 +1,33 @@
|
|||||||
[tox]
|
[tox]
|
||||||
minversion = 2.0
|
minversion = 2.0
|
||||||
envlist = docs,py27
|
envlist = pep8,docs
|
||||||
skipsdist = True
|
skipsdist = True
|
||||||
|
|
||||||
[testenv]
|
[testenv]
|
||||||
usedevelop = True
|
usedevelop = True
|
||||||
setenv = VIRTUAL_ENV={envdir}
|
setenv = VIRTUAL_ENV={envdir}
|
||||||
install_command = pip install -U {opts} {packages}
|
install_command = pip install -U {opts} {packages}
|
||||||
deps = -r{toxinidir}/requirements.txt
|
deps =
|
||||||
commands = python setup.py testr --slowest --testr-args='{posargs}'
|
-r{toxinidir}/test-requirements.txt
|
||||||
|
-r{toxinidir}/doc/requirements.txt
|
||||||
|
|
||||||
[testenv:venv]
|
[testenv:venv]
|
||||||
commands = {posargs}
|
commands = {posargs}
|
||||||
|
|
||||||
[testenv:docs]
|
[testenv:docs]
|
||||||
commands = sphinx-build -b html doc/source doc/build/html
|
deps = -r{toxinidir}/doc/requirements.txt
|
||||||
|
whitelist_externals = rm
|
||||||
|
commands =
|
||||||
|
rm -fr doc/build
|
||||||
|
sphinx-build -W -b html doc/source doc/build/html
|
||||||
|
|
||||||
|
[testenv:pep8]
|
||||||
|
commands =
|
||||||
|
flake8
|
||||||
|
doc8 --ignore D001 specs/ doc/source README.rst
|
||||||
|
|
||||||
|
[flake8]
|
||||||
|
# E123, E125 skipped as they are invalid PEP-8.
|
||||||
|
show-source = True
|
||||||
|
ignore = E123,E125
|
||||||
|
exclude=.venv,.git,.tox,dist,doc,*lib/python*,*egg,build
|
||||||
|
|||||||
Loading…
Reference in New Issue
Block a user