openstack/tacker-specs
Code Issues Proposed changes

Refactor and clean up specs dir

Browse Source 
- 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 2018-04-03 22:32:30 +09:00
parent d528ad99a1
commit d543040a4e
21 changed files with 336 additions and 892 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
requirements.txt → doc/requirements.txt
View File

@ -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

2
doc/source/index.rst
View File

@ -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
View File

@ -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

9
specs/archive/index.rst
View File

@ -1,9 +0,0 @@
=======
Archive
=======
.. toctree::
:glob:
:maxdepth: 1
*

625
specs/archive/tacker-sfc.rst
View File

@ -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

6
specs/mitaka/automatic-resource-creation.rst
View File

@ -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.
@ -170,7 +170,7 @@ Let's see how the above TOSCA template can be converted to HOT network resource.
type: OS::Neutron::Net
properties:
name: net_internal_dp
net_internal_dp_subnet:
type: OS::Neutron::Subnet
properties:

54
specs/mitaka/enhanced-placement.rst
View File

@ -167,14 +167,14 @@ Below would be an example of pinning guest vCPUs to host pCPUs:
node_templates:
VDU1:
type: tosca.nodes.nfv.VDU
capabilities:
nfv_compute:
properties:
num_cpus: 8
mem_size: 4096 # Memory Size in MB
disk_size: 8 # Value in GB
cpu_allocation:
cpu_affinity: dedicated
thread_allocation: isolate
@ -190,7 +190,7 @@ An example of specifying Huge pages be used for a guest VM:
node_templates:
VDU1:
type: tosca.nodes.nfv.VDU
capabilities:
nfv_compute:
properties:
@ -211,7 +211,7 @@ allocation of CPUs and RAM across NUMA nodes:
node_templates:
VDU1:
type: tosca.nodes.nfv.VDU
capabilities:
nfv_compute:
properties:
@ -219,7 +219,7 @@ allocation of CPUs and RAM across NUMA nodes:
mem_size: 6144
disk_size: 8
numa_nodes:
node1:
id: 0
vcpus: [ 0,1 ]
@ -241,7 +241,7 @@ allocation of CPUs and RAM across NUMA nodes:
node_templates:
VDU1:
type: tosca.nodes.nfv.VDU
capabilities:
nfv_compute:
properties:
@ -264,7 +264,7 @@ sockets, cores and thread count to be exposed to guest:
node_templates:
VDU1:
type: tosca.nodes.nfv.VDU
capabilities:
nfv_compute:
properties:
@ -273,13 +273,13 @@ sockets, cores and thread count to be exposed to guest:
disk_size: 80
mem_page_size: 1G
cpu_allocation:
cpu_affinity: dedicated
thread_allocation: avoid
socket_count: 2
core_count: 2
thread_count: 2
numa_node_count: 2
@ -295,7 +295,7 @@ network interfaces and sriov nic types:
node_templates:
VDU1:
type: tosca.nodes.nfv.VDU
capabilities:
nfv_compute:
properties:
@ -303,47 +303,47 @@ network interfaces and sriov nic types:
mem_size: 4096 MB
disk_size: 8 GB
mem_page_size: 1G
cpu_allocation:
cpu_affinity: dedicated
thread_allocation: isolate
socket_count: 2
core_count: 8
thread_count: 4
numa_node_count: 2
CP11:
type: tosca.nodes.nfv.CP
requirements:
- virtualbinding: VDU1
- virtualLink: net_mgmt
CP12:
type: tosca.nodes.nfv.CP
properties:
anti_spoof_protection: false
type : sriov
requirements:
- virtualbinding: VDU1
- virtualLink: net_ingress
CP13:
type: tosca.nodes.nfv.CP
properties:
anti_spoof_protection: false
type : sriov
requirements:
- virtualbinding: VDU1
- virtualLink: net_egress
net_mgmt:
type: tosca.nodes.nfv.VL.ELAN
net_ingress:
type: tosca.nodes.nfv.VL.ELAN
@ -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/

29
specs/mitaka/tosca-parser-integration.rst
View File

@ -16,22 +16,22 @@ Problem description
===================
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
requires maintenance and has far fewer capabilities than other existing
projects.
This spec documents the changes required in Tacker to support using
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
needed to support the rapidly-evolving NFV profile.
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
There tosca-parser [#]_ and heat-translator [#]_ projects have been updated to
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.
@ -40,11 +40,11 @@ and heat-translator projects to eventually replace the custom YAML template
and HOT template generation used by Tacker today.
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
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
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
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
conversion to HOT.
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
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
@ -199,7 +199,7 @@ Data model impact
-----------------
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
CSAR files.
@ -234,7 +234,7 @@ Other deployer impact
---------------------
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.
Developer impact
@ -255,7 +255,7 @@ Work Items
----------
- 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
- 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
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
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
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
==========
.. [#] 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

2
specs/newton/event_logging.rst
View File

@ -262,4 +262,4 @@ New User and Developer guide will be provided.
References
==========
None
None

20
specs/pike/encryption-with-barbican.rst
View File

@ -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.

60
specs/pike/mistral_vim_monitor.rst
View File

@ -32,22 +32,22 @@ Proposed change
asciiflow::
+---------------------+
| mistral workflow |
+-------> vim monitor action |
+--------------+ | | |
| Tacker server+-----+ +------------------+--+
+-----+--------+ |
| |
| |
| +-------v----------+
| | |
| | conductor server |
| +------------+ +------+ |
| | | | +------------------+
+-------> tacker DB <-----+
| |
+-------------
+---------------------+
| Mistral workflow |
+-------> VIM monitor action |
+--------------+ | | |
| Tacker server+-----+ +------------------+--+
+-----+--------+ |
| |
| |
| +-------v----------+
| | |
| | Conductor server |
| +------------+ +------+ |
| | | | +------------------+
+-------> Tacker DB <-----+
| |
+------------+
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
class VimMonitorAction2ConductorRPC(object)
# update vim's status, action_id is the task action
def update_vim (vim_id, status, action_id):
# The response message containing the operation result
# the status should be the passed in by request or 'bad_action'
# if the action is not the wanted action.
status = rpc call conductor
return status
class VimMonitorAction2ConductorRPC(object)
# update vim's status, action_id is the task action
def update_vim (vim_id, status, action_id):
# The response message containing the operation result
# the status should be the passed in by request or 'bad_action'
# if the action is not the wanted action.
status = rpc call conductor
return status
sequence diagram for register vim:
@ -133,12 +133,12 @@ Another way to use mistral is to use a loop workflow:
asciiflow::
start_task -----> ping_task ------> update_task
^ |
| |
| |
| on_succes |
---------------+
start_task -----> ping_task ------> update_task
^ |
| |
| |
| on_succes |
+---------------+
But Mistral will save task executions into Mistral database, so the loop

76
specs/pike/mistral_vnf_monitor_policies.rst
View File

@ -34,28 +34,28 @@ Proposed change
asciiflow::
+---------------------+
| Mistral workflow |
+-(1)---> VNF monitor action |
+---------------+ | | |
| Tacker server +----+ +--------^------------+
+-----+---------+ |
| | |
| | |
| | |
| | |
| | +--------v----+
| |----(3)--------> MSG Queue <----+
| +-------------+ (2)
| |
| +-------v----------+
| | Tacker |
| | conductor server |
| +------+-----+ +------+ |
| | | | +------------------+
+-------> Tacker DB <-----+
| |
+-------------
+---------------------+
| Mistral workflow |
+-(1)---> VNF monitor action |
+---------------+ | | |
| Tacker server +----+ +--------^------------+
+-----+---------+ |
| | |
| | |
| | |
| | |
| | +--------v----+
| |----(3)--------> MSG Queue <----+
| +-------------+ (2)
| |
| +-------v----------+
| | Tacker |
| | conductor server |
| +------+-----+ +------+ |
| | | | +------------------+
+-------> Tacker DB <-----+
| |
+------------+
(1) Since Mistral is an integral part of tacker system, a long-live Mistral
@ -81,15 +81,15 @@ VNFPolicyActionRPC:
.. code-block:: python
class VNFPolicyActionRPC(object)
# execute policy action
def execute_policy_action(context, vnf, monitor_return_value,
policy_actions, action_id):
# The response message containing the operation result
# the status should be the passed in by request or 'bad_action'
# if the action is not the wanted action.
status = rpc call conductor
return status
class VNFPolicyActionRPC(object)
# execute policy action
def execute_policy_action(context, vnf, monitor_return_value,
policy_actions, action_id):
# The response message containing the operation result
# the status should be the passed in by request or 'bad_action'
# if the action is not the wanted action.
status = rpc call conductor
return status
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
class VNFPolicyMonitorRPC(object)
# kill the mistral action job
def kill(context, action_id):
pass
class VNFPolicyMonitorRPC(object)
# kill the mistral action job
def kill(context, action_id):
pass
# update the mistral action job
def update(context, action_id, parameter):
pass
# update the mistral action job
def update(context, action_id, parameter):
pass
The update method in above interface is used to notify policy monitor that changes

12
specs/pike/persistent-block-storage.rst
View File

@ -153,9 +153,9 @@ One TOSCA template can support multiple VBs and CBs.
node_templates:
VDU1:
type: tosca.nodes.nfv.VDU.Tacker
properties:
image: centos
flavor: centos
properties:
image: centos
flavor: centos
CP1:
type: tosca.nodes.nfv.CP.Tacker
@ -199,8 +199,8 @@ the volume when VDU deleting.
node_templates:
VDU1:
type: tosca.nodes.nfv.VDU.Tacker
properties:
flavor: centos
properties:
flavor: centos
requirements:
- local_storage:
node: VB1
@ -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

6
specs/queens/zabbix-plugin.rst
View File

@ -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/

48
specs/skeleton.rst → specs/rocky/placeholder.rst
View File

@ -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
View File

@ -0,0 +1,9 @@
===========================
Tacker Stein Specifications
===========================
.. toctree::
:glob:
:maxdepth: 1
*

124
specs/stein/placeholder.rst Normal file
View 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
View 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

0
tests/__init__.py
View File

97
tests/test_titles.py
View File

@ -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
View File

@ -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