diff --git a/requirements.txt b/doc/requirements.txt similarity index 71% rename from requirements.txt rename to doc/requirements.txt index 8d8e8dc8..1edb4dbe 100644 --- a/requirements.txt +++ b/doc/requirements.txt @@ -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 diff --git a/doc/source/index.rst b/doc/source/index.rst index 8cd5930e..e6ebb396 100644 --- a/doc/source/index.rst +++ b/doc/source/index.rst @@ -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 ------------------ diff --git a/setup.cfg b/setup.cfg index b3085656..7157ce11 100644 --- a/setup.cfg +++ b/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 diff --git a/specs/archive/index.rst b/specs/archive/index.rst deleted file mode 100644 index fbf4e687..00000000 --- a/specs/archive/index.rst +++ /dev/null @@ -1,9 +0,0 @@ -======= -Archive -======= - -.. toctree:: - :glob: - :maxdepth: 1 - - * diff --git a/specs/archive/tacker-sfc.rst b/specs/archive/tacker-sfc.rst deleted file mode 100644 index b8ed4390..00000000 --- a/specs/archive/tacker-sfc.rst +++ /dev/null @@ -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 diff --git a/specs/mitaka/automatic-resource-creation.rst b/specs/mitaka/automatic-resource-creation.rst index caa89ba3..4c74e87f 100644 --- a/specs/mitaka/automatic-resource-creation.rst +++ b/specs/mitaka/automatic-resource-creation.rst @@ -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: diff --git a/specs/mitaka/enhanced-placement.rst b/specs/mitaka/enhanced-placement.rst index 561a9a8e..3b975f4c 100644 --- a/specs/mitaka/enhanced-placement.rst +++ b/specs/mitaka/enhanced-placement.rst @@ -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/ diff --git a/specs/mitaka/tosca-parser-integration.rst b/specs/mitaka/tosca-parser-integration.rst index b0867b7d..e21903d4 100644 --- a/specs/mitaka/tosca-parser-integration.rst +++ b/specs/mitaka/tosca-parser-integration.rst @@ -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 diff --git a/specs/newton/event_logging.rst b/specs/newton/event_logging.rst index 69129895..88c3860f 100644 --- a/specs/newton/event_logging.rst +++ b/specs/newton/event_logging.rst @@ -262,4 +262,4 @@ New User and Developer guide will be provided. References ========== -None \ No newline at end of file +None diff --git a/specs/pike/encryption-with-barbican.rst b/specs/pike/encryption-with-barbican.rst index 57640843..19f5cbcb 100644 --- a/specs/pike/encryption-with-barbican.rst +++ b/specs/pike/encryption-with-barbican.rst @@ -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. diff --git a/specs/pike/mistral_vim_monitor.rst b/specs/pike/mistral_vim_monitor.rst index 47280599..8f6441aa 100644 --- a/specs/pike/mistral_vim_monitor.rst +++ b/specs/pike/mistral_vim_monitor.rst @@ -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 diff --git a/specs/pike/mistral_vnf_monitor_policies.rst b/specs/pike/mistral_vnf_monitor_policies.rst index 40190fc6..316521c0 100644 --- a/specs/pike/mistral_vnf_monitor_policies.rst +++ b/specs/pike/mistral_vnf_monitor_policies.rst @@ -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 diff --git a/specs/pike/persistent-block-storage.rst b/specs/pike/persistent-block-storage.rst index 681adb76..58fce25d 100755 --- a/specs/pike/persistent-block-storage.rst +++ b/specs/pike/persistent-block-storage.rst @@ -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 diff --git a/specs/queens/zabbix-plugin.rst b/specs/queens/zabbix-plugin.rst index add1466e..284e4883 100644 --- a/specs/queens/zabbix-plugin.rst +++ b/specs/queens/zabbix-plugin.rst @@ -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/ \ No newline at end of file +* https://www.zabbix.com/documentation/3.2/manual +* https://share.zabbix.com/ +* https://www.nagios.org/documentation/ diff --git a/specs/skeleton.rst b/specs/rocky/placeholder.rst similarity index 56% rename from specs/skeleton.rst rename to specs/rocky/placeholder.rst index f4465da9..9aaa6f08 100644 --- a/specs/skeleton.rst +++ b/specs/rocky/placeholder.rst @@ -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 diff --git a/specs/stein/index.rst b/specs/stein/index.rst new file mode 100644 index 00000000..1063bb0a --- /dev/null +++ b/specs/stein/index.rst @@ -0,0 +1,9 @@ +=========================== +Tacker Stein Specifications +=========================== + +.. toctree:: + :glob: + :maxdepth: 1 + + * diff --git a/specs/stein/placeholder.rst b/specs/stein/placeholder.rst new file mode 100644 index 00000000..9aaa6f08 --- /dev/null +++ b/specs/stein/placeholder.rst @@ -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 diff --git a/test-requirements.txt b/test-requirements.txt new file mode 100644 index 00000000..06e1ebce --- /dev/null +++ b/test-requirements.txt @@ -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 diff --git a/tests/__init__.py b/tests/__init__.py deleted file mode 100644 index e69de29b..00000000 diff --git a/tests/test_titles.py b/tests/test_titles.py deleted file mode 100644 index 0e04b288..00000000 --- a/tests/test_titles.py +++ /dev/null @@ -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) diff --git a/tox.ini b/tox.ini index 9ebd4508..aa17e0a5 100644 --- a/tox.ini +++ b/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