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:
parent
d528ad99a1
commit
d543040a4e
@ -1,17 +1,9 @@
|
||||
# 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.
|
||||
|
||||
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
|
||||
openstackdocstheme>=1.18.1 # Apache-2.0
|
||||
sphinxcontrib-actdiag # BSD
|
||||
sphinxcontrib-blockdiag # BSD
|
||||
sphinxcontrib-nwdiag # BSD
|
||||
sphinxcontrib-seqdiag # BSD
|
||||
testrepository>=0.0.18 # Apache-2.0/BSD
|
||||
testtools>=0.9.34 # MIT
|
@ -22,6 +22,7 @@ Specifications
|
||||
:glob:
|
||||
:maxdepth: 2
|
||||
|
||||
specs/stein/index
|
||||
specs/rocky/index
|
||||
specs/queens/index
|
||||
specs/pike/index
|
||||
@ -29,7 +30,6 @@ Specifications
|
||||
specs/newton/index
|
||||
specs/mitaka/index
|
||||
specs/liberty/index
|
||||
specs/archive/index
|
||||
|
||||
Indices and tables
|
||||
------------------
|
||||
|
12
setup.cfg
12
setup.cfg
@ -11,17 +11,5 @@ classifier =
|
||||
License :: OSI Approved :: Apache Software License
|
||||
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]
|
||||
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
|
||||
details by adding those details in heat template. Tacker will handle three
|
||||
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
|
||||
as below:
|
||||
@ -157,7 +157,7 @@ Template Changes
|
||||
|
||||
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
|
||||
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
|
||||
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.
|
||||
|
@ -439,9 +439,9 @@ The document will be updated to guide how to use this feature.
|
||||
References
|
||||
==========
|
||||
|
||||
.. [#] `<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/>`_
|
||||
.. [#] `<https://wiki.openstack.org/wiki/VirtDriverGuestCPUMemoryPlacement>`_
|
||||
.. [#] `<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://redhatstackblog.redhat.com/2015/03/05/red-hat-enterprise-linux-openstack-platform-6-sr-iov-networking-part-i-understanding-the-basics/>`_
|
||||
* 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/
|
||||
* https://wiki.openstack.org/wiki/VirtDriverGuestCPUMemoryPlacement
|
||||
* 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://redhatstackblog.redhat.com/2015/03/05/red-hat-enterprise-linux-openstack-platform-6-sr-iov-networking-part-i-understanding-the-basics/
|
||||
|
@ -31,7 +31,7 @@ Proposed change
|
||||
===============
|
||||
|
||||
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
|
||||
dictionary instead of a file or URL containing the template.
|
||||
|
||||
@ -298,5 +298,4 @@ References
|
||||
==========
|
||||
.. [#] https://blueprints.launchpad.net/tosca-parser/+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
|
||||
|
@ -40,11 +40,11 @@ administrators as they add tacker-server instances for scaling.
|
||||
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,
|
||||
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
|
||||
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
|
||||
encryption feature [3][4].
|
||||
encryption feature [3]_ [4]_.
|
||||
They invoke castellan as key_mamager, allowing Barbican to securely
|
||||
generate, store, and present encryption keys.
|
||||
|
||||
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
|
||||
barbican secure containers.
|
||||
|
||||
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,
|
||||
several different management services can be supported through a single
|
||||
interface. In addition to the key manager, Castellan also provides primitives
|
||||
@ -188,7 +188,7 @@ How to use castellan
|
||||
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:
|
||||
|
||||
@ -240,7 +240,7 @@ There are two methods to generate the context.
|
||||
|
||||
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
|
||||
long living existing created user), and all vims' passwords are saved and
|
||||
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)
|
||||
|
||||
The default RBAC policy[9] about secrets are following:
|
||||
The default RBAC policy [9]_ about secrets are following:
|
||||
|
||||
.. code-block:: ini
|
||||
|
||||
@ -290,10 +290,10 @@ The default RBAC policy[9] about secrets are following:
|
||||
"secrets:get": "rule:all_but_audit",
|
||||
|
||||
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
|
||||
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
|
||||
into the ACL of the secret.
|
||||
|
||||
|
@ -33,8 +33,8 @@ Proposed change
|
||||
asciiflow::
|
||||
|
||||
+---------------------+
|
||||
| mistral workflow |
|
||||
+-------> vim monitor action |
|
||||
| Mistral workflow |
|
||||
+-------> VIM monitor action |
|
||||
+--------------+ | | |
|
||||
| Tacker server+-----+ +------------------+--+
|
||||
+-----+--------+ |
|
||||
@ -42,12 +42,12 @@ asciiflow::
|
||||
| |
|
||||
| +-------v----------+
|
||||
| | |
|
||||
| | conductor server |
|
||||
| | Conductor server |
|
||||
| +------------+ +------+ |
|
||||
| | | | +------------------+
|
||||
+-------> tacker DB <-----+
|
||||
+-------> Tacker DB <-----+
|
||||
| |
|
||||
+-------------
|
||||
+------------+
|
||||
|
||||
|
||||
Since Mistral is an integral part of tacker system, a long-live Mistral workflow
|
||||
@ -138,7 +138,7 @@ asciiflow::
|
||||
| |
|
||||
| |
|
||||
| on_succes |
|
||||
---------------+
|
||||
+---------------+
|
||||
|
||||
|
||||
But Mistral will save task executions into Mistral database, so the loop
|
||||
|
@ -55,7 +55,7 @@ asciiflow::
|
||||
| | | | +------------------+
|
||||
+-------> Tacker DB <-----+
|
||||
| |
|
||||
+-------------
|
||||
+------------+
|
||||
|
||||
|
||||
(1) Since Mistral is an integral part of tacker system, a long-live Mistral
|
||||
|
@ -306,4 +306,4 @@ None
|
||||
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
|
||||
==========
|
||||
.. [#first] https://www.zabbix.com/documentation/3.0/manual
|
||||
.. [#second] https://share.zabbix.com/
|
||||
.. [#third] https://www.nagios.org/documentation/
|
||||
* https://www.zabbix.com/documentation/3.2/manual
|
||||
* https://share.zabbix.com/
|
||||
* https://www.nagios.org/documentation/
|
||||
|
@ -4,54 +4,82 @@
|
||||
|
||||
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
|
||||
===================
|
||||
|
||||
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
|
||||
==============
|
||||
@ -59,24 +87,38 @@ Implementation
|
||||
Assignee(s)
|
||||
-----------
|
||||
|
||||
None
|
||||
|
||||
Work Items
|
||||
----------
|
||||
|
||||
None
|
||||
|
||||
|
||||
Dependencies
|
||||
============
|
||||
|
||||
None
|
||||
|
||||
|
||||
Testing
|
||||
=======
|
||||
|
||||
None
|
||||
|
||||
|
||||
Documentation Impact
|
||||
====================
|
||||
|
||||
None
|
||||
|
||||
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]
|
||||
minversion = 2.0
|
||||
envlist = docs,py27
|
||||
envlist = pep8,docs
|
||||
skipsdist = True
|
||||
|
||||
[testenv]
|
||||
usedevelop = True
|
||||
setenv = VIRTUAL_ENV={envdir}
|
||||
install_command = pip install -U {opts} {packages}
|
||||
deps = -r{toxinidir}/requirements.txt
|
||||
commands = python setup.py testr --slowest --testr-args='{posargs}'
|
||||
deps =
|
||||
-r{toxinidir}/test-requirements.txt
|
||||
-r{toxinidir}/doc/requirements.txt
|
||||
|
||||
[testenv:venv]
|
||||
commands = {posargs}
|
||||
|
||||
[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