Browse Source
Every repo needs a first commit, eh? Most of this is based on the neutron and neutron-specs project layouts. Change-Id: I17a41fc30f8f8499c679afad14019c0755582bc6changes/82/102482/9
23 changed files with 1396 additions and 0 deletions
@ -0,0 +1,4 @@
|
||||
[DEFAULT] |
||||
test_command=${PYTHON:-python} -m subunit.run discover octavia $LISTOPT $IDOPTION |
||||
test_id_option=--load-list $IDFILE |
||||
test_list_option=--list |
@ -0,0 +1,20 @@
|
||||
Octavia Style Commandments |
||||
======================= |
||||
This project was ultimately spawned from work done on the Neutron project. |
||||
As such, we tend to follow Neutron conventions regarding coding style. |
||||
|
||||
- We follow the OpenStack Style Commandments: |
||||
http://docs.openstack.org/developer/hacking/ |
||||
|
||||
Octavia Specific Commandments |
||||
-------------------------- |
||||
|
||||
- [N320] Validate that LOG messages, except debug ones, have translations |
||||
|
||||
Creating Unit Tests |
||||
------------------- |
||||
For every new feature, unit tests should be created that both test and |
||||
(implicitly) document the usage of said feature. If submitting a patch for a |
||||
bug that had no unit test, a new passing unit test should be added. If a |
||||
submitted bug fix does have a unit test, be sure to add a new one that fails |
||||
without the patch and passes with the patch. |
@ -0,0 +1,176 @@
|
||||
|
||||
Apache License |
||||
Version 2.0, January 2004 |
||||
http://www.apache.org/licenses/ |
||||
|
||||
TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION |
||||
|
||||
1. Definitions. |
||||
|
||||
"License" shall mean the terms and conditions for use, reproduction, |
||||
and distribution as defined by Sections 1 through 9 of this document. |
||||
|
||||
"Licensor" shall mean the copyright owner or entity authorized by |
||||
the copyright owner that is granting the License. |
||||
|
||||
"Legal Entity" shall mean the union of the acting entity and all |
||||
other entities that control, are controlled by, or are under common |
||||
control with that entity. For the purposes of this definition, |
||||
"control" means (i) the power, direct or indirect, to cause the |
||||
direction or management of such entity, whether by contract or |
||||
otherwise, or (ii) ownership of fifty percent (50%) or more of the |
||||
outstanding shares, or (iii) beneficial ownership of such entity. |
||||
|
||||
"You" (or "Your") shall mean an individual or Legal Entity |
||||
exercising permissions granted by this License. |
||||
|
||||
"Source" form shall mean the preferred form for making modifications, |
||||
including but not limited to software source code, documentation |
||||
source, and configuration files. |
||||
|
||||
"Object" form shall mean any form resulting from mechanical |
||||
transformation or translation of a Source form, including but |
||||
not limited to compiled object code, generated documentation, |
||||
and conversions to other media types. |
||||
|
||||
"Work" shall mean the work of authorship, whether in Source or |
||||
Object form, made available under the License, as indicated by a |
||||
copyright notice that is included in or attached to the work |
||||
(an example is provided in the Appendix below). |
||||
|
||||
"Derivative Works" shall mean any work, whether in Source or Object |
||||
form, that is based on (or derived from) the Work and for which the |
||||
editorial revisions, annotations, elaborations, or other modifications |
||||
represent, as a whole, an original work of authorship. For the purposes |
||||
of this License, Derivative Works shall not include works that remain |
||||
separable from, or merely link (or bind by name) to the interfaces of, |
||||
the Work and Derivative Works thereof. |
||||
|
||||
"Contribution" shall mean any work of authorship, including |
||||
the original version of the Work and any modifications or additions |
||||
to that Work or Derivative Works thereof, that is intentionally |
||||
submitted to Licensor for inclusion in the Work by the copyright owner |
||||
or by an individual or Legal Entity authorized to submit on behalf of |
||||
the copyright owner. For the purposes of this definition, "submitted" |
||||
means any form of electronic, verbal, or written communication sent |
||||
to the Licensor or its representatives, including but not limited to |
||||
communication on electronic mailing lists, source code control systems, |
||||
and issue tracking systems that are managed by, or on behalf of, the |
||||
Licensor for the purpose of discussing and improving the Work, but |
||||
excluding communication that is conspicuously marked or otherwise |
||||
designated in writing by the copyright owner as "Not a Contribution." |
||||
|
||||
"Contributor" shall mean Licensor and any individual or Legal Entity |
||||
on behalf of whom a Contribution has been received by Licensor and |
||||
subsequently incorporated within the Work. |
||||
|
||||
2. Grant of Copyright License. Subject to the terms and conditions of |
||||
this License, each Contributor hereby grants to You a perpetual, |
||||
worldwide, non-exclusive, no-charge, royalty-free, irrevocable |
||||
copyright license to reproduce, prepare Derivative Works of, |
||||
publicly display, publicly perform, sublicense, and distribute the |
||||
Work and such Derivative Works in Source or Object form. |
||||
|
||||
3. Grant of Patent License. Subject to the terms and conditions of |
||||
this License, each Contributor hereby grants to You a perpetual, |
||||
worldwide, non-exclusive, no-charge, royalty-free, irrevocable |
||||
(except as stated in this section) patent license to make, have made, |
||||
use, offer to sell, sell, import, and otherwise transfer the Work, |
||||
where such license applies only to those patent claims licensable |
||||
by such Contributor that are necessarily infringed by their |
||||
Contribution(s) alone or by combination of their Contribution(s) |
||||
with the Work to which such Contribution(s) was submitted. If You |
||||
institute patent litigation against any entity (including a |
||||
cross-claim or counterclaim in a lawsuit) alleging that the Work |
||||
or a Contribution incorporated within the Work constitutes direct |
||||
or contributory patent infringement, then any patent licenses |
||||
granted to You under this License for that Work shall terminate |
||||
as of the date such litigation is filed. |
||||
|
||||
4. Redistribution. You may reproduce and distribute copies of the |
||||
Work or Derivative Works thereof in any medium, with or without |
||||
modifications, and in Source or Object form, provided that You |
||||
meet the following conditions: |
||||
|
||||
(a) You must give any other recipients of the Work or |
||||
Derivative Works a copy of this License; and |
||||
|
||||
(b) You must cause any modified files to carry prominent notices |
||||
stating that You changed the files; and |
||||
|
||||
(c) You must retain, in the Source form of any Derivative Works |
||||
that You distribute, all copyright, patent, trademark, and |
||||
attribution notices from the Source form of the Work, |
||||
excluding those notices that do not pertain to any part of |
||||
the Derivative Works; and |
||||
|
||||
(d) If the Work includes a "NOTICE" text file as part of its |
||||
distribution, then any Derivative Works that You distribute must |
||||
include a readable copy of the attribution notices contained |
||||
within such NOTICE file, excluding those notices that do not |
||||
pertain to any part of the Derivative Works, in at least one |
||||
of the following places: within a NOTICE text file distributed |
||||
as part of the Derivative Works; within the Source form or |
||||
documentation, if provided along with the Derivative Works; or, |
||||
within a display generated by the Derivative Works, if and |
||||
wherever such third-party notices normally appear. The contents |
||||
of the NOTICE file are for informational purposes only and |
||||
do not modify the License. You may add Your own attribution |
||||
notices within Derivative Works that You distribute, alongside |
||||
or as an addendum to the NOTICE text from the Work, provided |
||||
that such additional attribution notices cannot be construed |
||||
as modifying the License. |
||||
|
||||
You may add Your own copyright statement to Your modifications and |
||||
may provide additional or different license terms and conditions |
||||
for use, reproduction, or distribution of Your modifications, or |
||||
for any such Derivative Works as a whole, provided Your use, |
||||
reproduction, and distribution of the Work otherwise complies with |
||||
the conditions stated in this License. |
||||
|
||||
5. Submission of Contributions. Unless You explicitly state otherwise, |
||||
any Contribution intentionally submitted for inclusion in the Work |
||||
by You to the Licensor shall be under the terms and conditions of |
||||
this License, without any additional terms or conditions. |
||||
Notwithstanding the above, nothing herein shall supersede or modify |
||||
the terms of any separate license agreement you may have executed |
||||
with Licensor regarding such Contributions. |
||||
|
||||
6. Trademarks. This License does not grant permission to use the trade |
||||
names, trademarks, service marks, or product names of the Licensor, |
||||
except as required for reasonable and customary use in describing the |
||||
origin of the Work and reproducing the content of the NOTICE file. |
||||
|
||||
7. Disclaimer of Warranty. Unless required by applicable law or |
||||
agreed to in writing, Licensor provides the Work (and each |
||||
Contributor provides its Contributions) on an "AS IS" BASIS, |
||||
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or |
||||
implied, including, without limitation, any warranties or conditions |
||||
of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A |
||||
PARTICULAR PURPOSE. You are solely responsible for determining the |
||||
appropriateness of using or redistributing the Work and assume any |
||||
risks associated with Your exercise of permissions under this License. |
||||
|
||||
8. Limitation of Liability. In no event and under no legal theory, |
||||
whether in tort (including negligence), contract, or otherwise, |
||||
unless required by applicable law (such as deliberate and grossly |
||||
negligent acts) or agreed to in writing, shall any Contributor be |
||||
liable to You for damages, including any direct, indirect, special, |
||||
incidental, or consequential damages of any character arising as a |
||||
result of this License or out of the use or inability to use the |
||||
Work (including but not limited to damages for loss of goodwill, |
||||
work stoppage, computer failure or malfunction, or any and all |
||||
other commercial damages or losses), even if such Contributor |
||||
has been advised of the possibility of such damages. |
||||
|
||||
9. Accepting Warranty or Additional Liability. While redistributing |
||||
the Work or Derivative Works thereof, You may choose to offer, |
||||
and charge a fee for, acceptance of support, warranty, indemnity, |
||||
or other liability obligations and/or rights consistent with this |
||||
License. However, in accepting such obligations, You may act only |
||||
on Your own behalf and on Your sole responsibility, not on behalf |
||||
of any other Contributor, and only if You agree to indemnify, |
||||
defend, and hold each Contributor harmless for any liability |
||||
incurred by, or claims asserted against, such Contributor by reason |
||||
of your accepting any such warranty or additional liability. |
||||
|
@ -0,0 +1,6 @@
|
||||
include README.rst |
||||
include LICENSE |
||||
|
||||
exclude .gitignore |
||||
exclude .gitreview |
||||
global-exclude *.pyc |
@ -0,0 +1,17 @@
|
||||
======== |
||||
Octavia |
||||
======== |
||||
|
||||
Operator-grade open source scalable load balancer. |
||||
|
||||
The Octavia project seeks to become the standard operator-grade load balancer |
||||
in use in large OpenStack deployments. Note that it is not competing with the |
||||
Neutron LBaaS extension and may never actually replace it. Rather, Octavia |
||||
should be seen as "yet another vendor" which is accessed via a driver for |
||||
Neutron LBaaS. |
||||
|
||||
For more information on project direction and guiding principles for |
||||
contributors, please see the CONSTITUTION.rst file in this directory, or |
||||
specifications in the specs/ subdirectory. Other documentation can be |
||||
found in the docs/ directory. |
||||
|
@ -0,0 +1,273 @@
|
||||
# -*- coding: utf-8 -*- |
||||
# |
||||
# Tempest documentation build configuration file, created by |
||||
# sphinx-quickstart on Tue May 21 17:43:32 2013. |
||||
# |
||||
# This file is execfile()d with the current directory set to its containing dir. |
||||
# |
||||
# Note that not all possible configuration values are present in this |
||||
# autogenerated file. |
||||
# |
||||
# All configuration values have a default; values that are commented out |
||||
# serve to show the default. |
||||
|
||||
import sys |
||||
import os |
||||
|
||||
# If extensions (or modules to document with autodoc) are in another directory, |
||||
# add these directories to sys.path here. If the directory is relative to the |
||||
# documentation root, use os.path.abspath to make it absolute, like shown here. |
||||
#sys.path.insert(0, os.path.abspath('.')) |
||||
|
||||
# -- General configuration ----------------------------------------------------- |
||||
|
||||
# If your documentation needs a minimal Sphinx version, state it here. |
||||
#needs_sphinx = '1.0' |
||||
|
||||
# Add any Sphinx extension module names here, as strings. They can be extensions |
||||
# coming with Sphinx (named 'sphinx.ext.*') or your custom ones. |
||||
extensions = ['sphinx.ext.autodoc', |
||||
'sphinx.ext.intersphinx', |
||||
'sphinx.ext.todo', |
||||
'sphinx.ext.viewcode', |
||||
'sphinxcontrib.blockdiag', |
||||
'sphinxcontrib.actdiag', |
||||
'sphinxcontrib.seqdiag', |
||||
'sphinxcontrib.nwdiag', |
||||
'sphinxcontrib.googlechart.graphviz', |
||||
'oslosphinx' |
||||
] |
||||
|
||||
todo_include_todos = True |
||||
|
||||
# Add any paths that contain templates here, relative to this directory. |
||||
templates_path = ['_templates'] |
||||
|
||||
# The suffix of source filenames. |
||||
source_suffix = '.rst' |
||||
|
||||
# The encoding of source files. |
||||
#source_encoding = 'utf-8-sig' |
||||
|
||||
# The master toctree document. |
||||
master_doc = 'index' |
||||
|
||||
# General information about the project. |
||||
project = u'Octavia' |
||||
copyright = u'2014, OpenStack Octavia Team' |
||||
|
||||
# The language for content autogenerated by Sphinx. Refer to documentation |
||||
# for a list of supported languages. |
||||
#language = None |
||||
|
||||
# There are two options for replacing |today|: either, you set today to some |
||||
# non-false value, then it is used: |
||||
#today = '' |
||||
# Else, today_fmt is used as the format for a strftime call. |
||||
#today_fmt = '%B %d, %Y' |
||||
|
||||
# List of patterns, relative to source directory, that match files and |
||||
# directories to ignore when looking for source files. |
||||
exclude_patterns = ['_build'] |
||||
|
||||
# The reST default role (used for this markup: `text`) to use for all documents. |
||||
#default_role = None |
||||
|
||||
# If true, '()' will be appended to :func: etc. cross-reference text. |
||||
#add_function_parentheses = True |
||||
|
||||
# If true, the current module name will be prepended to all description |
||||
# unit titles (such as .. function::). |
||||
add_module_names = False |
||||
|
||||
# If true, sectionauthor and moduleauthor directives will be shown in the |
||||
# output. They are ignored by default. |
||||
show_authors = False |
||||
|
||||
# The name of the Pygments (syntax highlighting) style to use. |
||||
pygments_style = 'sphinx' |
||||
|
||||
# A list of ignored prefixes for module index sorting. |
||||
modindex_common_prefix = ['octavia.'] |
||||
|
||||
# -- Options for man page output ---------------------------------------------- |
||||
man_pages = [] |
||||
|
||||
# -- Options for HTML output --------------------------------------------------- |
||||
|
||||
# The theme to use for HTML and HTML Help pages. See the documentation for |
||||
# a list of builtin themes. |
||||
html_theme = 'nature' |
||||
|
||||
# Theme options are theme-specific and customize the look and feel of a theme |
||||
# further. For a list of options available for each theme, see the |
||||
# documentation. |
||||
#html_theme_options = {} |
||||
|
||||
# Add any paths that contain custom themes here, relative to this directory. |
||||
#html_theme_path = [] |
||||
|
||||
# The name for this set of Sphinx documents. If None, it defaults to |
||||
# "<project> v<release> documentation". |
||||
#html_title = None |
||||
|
||||
# A shorter title for the navigation bar. Default is the same as html_title. |
||||
#html_short_title = None |
||||
|
||||
# The name of an image file (relative to this directory) to place at the top |
||||
# of the sidebar. |
||||
#html_logo = None |
||||
|
||||
# The name of an image file (within the static path) to use as favicon of the |
||||
# docs. This file should be a Windows icon file (.ico) being 16x16 or 32x32 |
||||
# pixels large. |
||||
#html_favicon = None |
||||
|
||||
# If not '', a 'Last updated on:' timestamp is inserted at every page bottom, |
||||
# using the given strftime format. |
||||
git_cmd = "git log --pretty=format:'%ad, commit %h' --date=local -n1" |
||||
html_last_updated_fmt = os.popen(git_cmd).read() |
||||
|
||||
# If true, SmartyPants will be used to convert quotes and dashes to |
||||
# typographically correct entities. |
||||
#html_use_smartypants = True |
||||
|
||||
# Custom sidebar templates, maps document names to template names. |
||||
#html_sidebars = {} |
||||
|
||||
# Additional templates that should be rendered to pages, maps page names to |
||||
# template names. |
||||
#html_additional_pages = {} |
||||
|
||||
# If false, no module index is generated. |
||||
html_domain_indices = False |
||||
|
||||
# If false, no index is generated. |
||||
html_use_index = False |
||||
|
||||
# If true, the index is split into individual pages for each letter. |
||||
#html_split_index = False |
||||
|
||||
# If true, links to the reST sources are added to the pages. |
||||
#html_show_sourcelink = True |
||||
|
||||
# If true, "Created using Sphinx" is shown in the HTML footer. Default is True. |
||||
#html_show_sphinx = True |
||||
|
||||
# If true, "(C) Copyright ..." is shown in the HTML footer. Default is True. |
||||
#html_show_copyright = True |
||||
|
||||
# If true, an OpenSearch description file will be output, and all pages will |
||||
# contain a <link> tag referring to it. The value of this option must be the |
||||
# base URL from which the finished HTML is served. |
||||
#html_use_opensearch = '' |
||||
|
||||
# This is the file name suffix for HTML files (e.g. ".xhtml"). |
||||
#html_file_suffix = None |
||||
|
||||
# Output file base name for HTML help builder. |
||||
htmlhelp_basename = 'Octavia-Specsdoc' |
||||
|
||||
|
||||
# -- Options for LaTeX output -------------------------------------------------- |
||||
|
||||
latex_elements = { |
||||
# The paper size ('letterpaper' or 'a4paper'). |
||||
#'papersize': 'letterpaper', |
||||
|
||||
# The font size ('10pt', '11pt' or '12pt'). |
||||
#'pointsize': '10pt', |
||||
|
||||
# Additional stuff for the LaTeX preamble. |
||||
#'preamble': '', |
||||
} |
||||
|
||||
# Grouping the document tree into LaTeX files. List of tuples |
||||
# (source start file, target name, title, author, documentclass [howto/manual]). |
||||
latex_documents = [ |
||||
('index', 'Octavia-specs.tex', u'Octavia Specs', |
||||
u'OpenStack Octavia Team', 'manual'), |
||||
] |
||||
|
||||
# The name of an image file (relative to this directory) to place at the top of |
||||
# the title page. |
||||
#latex_logo = None |
||||
|
||||
# For "manual" documents, if this is true, then toplevel headings are parts, |
||||
# not chapters. |
||||
#latex_use_parts = False |
||||
|
||||
# If true, show page references after internal links. |
||||
#latex_show_pagerefs = False |
||||
|
||||
# If true, show URL addresses after external links. |
||||
#latex_show_urls = False |
||||
|
||||
# Documents to append as an appendix to all manuals. |
||||
#latex_appendices = [] |
||||
|
||||
# If false, no module index is generated. |
||||
#latex_domain_indices = True |
||||
|
||||
# -- Options for Texinfo output ------------------------------------------------ |
||||
|
||||
# Grouping the document tree into Texinfo files. List of tuples |
||||
# (source start file, target name, title, author, |
||||
# dir menu entry, description, category) |
||||
texinfo_documents = [ |
||||
('index', 'Octavia-specs', u'Octavia Design Specs', |
||||
u'OpenStack Octavia Team', 'octavia-specs', 'Design specifications for the Octavia project.', |
||||
'Miscellaneous'), |
||||
] |
||||
|
||||
# Documents to append as an appendix to all manuals. |
||||
#texinfo_appendices = [] |
||||
|
||||
# If false, no module index is generated. |
||||
#texinfo_domain_indices = True |
||||
|
||||
# How to display URL addresses: 'footnote', 'no', or 'inline'. |
||||
#texinfo_show_urls = 'footnote' |
||||
|
||||
|
||||
# -- Options for Epub output --------------------------------------------------- |
||||
|
||||
# Bibliographic Dublin Core info. |
||||
epub_title = u'Octavia Specs' |
||||
epub_author = u'OpenStack Octavia Team' |
||||
epub_publisher = u'OpenStack Octavia Team' |
||||
epub_copyright = u'2014, OpenStack Octavia Team' |
||||
|
||||
# The language of the text. It defaults to the language option |
||||
# or en if the language is not set. |
||||
#epub_language = '' |
||||
|
||||
# The scheme of the identifier. Typical schemes are ISBN or URL. |
||||
#epub_scheme = '' |
||||
|
||||
# The unique identifier of the text. This can be a ISBN number |
||||
# or the project homepage. |
||||
#epub_identifier = '' |
||||
|
||||
# A unique identification for the text. |
||||
#epub_uid = '' |
||||
|
||||
# A tuple containing the cover image and cover page html template filenames. |
||||
#epub_cover = () |
||||
|
||||
# HTML files that should be inserted before the pages created by sphinx. |
||||
# The format is a list of tuples containing the path and title. |
||||
#epub_pre_files = [] |
||||
|
||||
# HTML files shat should be inserted after the pages created by sphinx. |
||||
# The format is a list of tuples containing the path and title. |
||||
#epub_post_files = [] |
||||
|
||||
# A list of files that should not be packed into the epub file. |
||||
#epub_exclude_files = [] |
||||
|
||||
# The depth of the table of contents in toc.ncx. |
||||
#epub_tocdepth = 3 |
||||
|
||||
# Allow duplicate toc entries. |
||||
#epub_tocdup = True |
@ -0,0 +1,27 @@
|
||||
.. octavia-specs documentation master file |
||||
|
||||
============================== |
||||
Octavia Project Specifications |
||||
============================== |
||||
|
||||
Contents: |
||||
|
||||
.. toctree:: |
||||
:glob: |
||||
:maxdepth: 1 |
||||
|
||||
specs/* |
||||
|
||||
Version 1 specs: |
||||
|
||||
.. toctree:: |
||||
:glob: |
||||
:maxdepth: 1 |
||||
|
||||
specs/version1/* |
||||
|
||||
================== |
||||
Indices and tables |
||||
================== |
||||
|
||||
* :ref:`search` |
@ -0,0 +1,13 @@
|
||||
actdiag |
||||
blockdiag |
||||
docutils==0.11 |
||||
nwdiag |
||||
oslosphinx |
||||
pbr>=0.6,<1.0 |
||||
seqdiag |
||||
sphinx |
||||
sphinxcontrib-actdiag |
||||
sphinxcontrib-blockdiag |
||||
sphinxcontrib-nwdiag |
||||
sphinxcontrib-seqdiag |
||||
sphinxcontrib-googlechart |
@ -0,0 +1,29 @@
|
||||
[metadata] |
||||
name = octavia |
||||
summary = OpenStack Octavia Scalable Load Balancer as as Service |
||||
description-file = |
||||
README.rst |
||||
author = OpenStack |
||||
author-email = openstack-dev@lists.openstack.org |
||||
home-page = http://www.openstack.org/ |
||||
classifier = |
||||
Environment :: OpenStack |
||||
Intended Audience :: Developers |
||||
Intended Audience :: Information Technology |
||||
Intended Audience :: System Administrators |
||||
License :: OSI Approved :: Apache Software License |
||||
Operating System :: POSIX :: Linux |
||||
Programming Language :: Python |
||||
Programming Language :: Python :: 2.7 |
||||
Programming Language :: Python :: 3.3 |
||||
|
||||
[build_sphinx] |
||||
all_files = 1 |
||||
build-dir = doc/build |
||||
source-dir = doc/source |
||||
|
||||
[pbr] |
||||
warnerrors = True |
||||
|
||||
[wheel] |
||||
universal = 1 |
@ -0,0 +1,21 @@
|
||||
#!/usr/bin/env python |
||||
# Copyright (c) 2014 eNovance |
||||
# |
||||
# 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 setuptools |
||||
|
||||
setuptools.setup( |
||||
setup_requires=['pbr'], |
||||
pbr=True) |
@ -0,0 +1,106 @@
|
||||
# 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 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) |
||||
directives.register_directive('graphviz', 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_titles(self, titles): |
||||
self.assertEqual(7, len(titles)) |
||||
|
||||
problem = 'Problem description' |
||||
self.assertIn(problem, titles) |
||||
self.assertEqual(0, len(titles[problem])) |
||||
|
||||
proposed = 'Proposed change' |
||||
self.assertIn(proposed, titles) |
||||
self.assertIn('Alternatives', titles[proposed]) |
||||
self.assertIn('Data model impact', titles[proposed]) |
||||
self.assertIn('REST API impact', titles[proposed]) |
||||
self.assertIn('Security impact', titles[proposed]) |
||||
self.assertIn('Notifications impact', titles[proposed]) |
||||
self.assertIn('Other end user impact', titles[proposed]) |
||||
self.assertIn('Performance Impact', titles[proposed]) |
||||
self.assertIn('Other deployer impact', titles[proposed]) |
||||
self.assertIn('Developer impact', titles[proposed]) |
||||
|
||||
impl = 'Implementation' |
||||
self.assertIn(impl, titles) |
||||
self.assertEqual(2, len(titles[impl])) |
||||
self.assertIn('Assignee(s)', titles[impl]) |
||||
self.assertIn('Work Items', titles[impl]) |
||||
|
||||
deps = 'Dependencies' |
||||
self.assertIn(deps, titles) |
||||
self.assertEqual(0, len(titles[deps])) |
||||
|
||||
testing = 'Testing' |
||||
self.assertIn(testing, titles) |
||||
self.assertEqual(0, len(titles[testing])) |
||||
|
||||
docs = 'Documentation Impact' |
||||
self.assertIn(docs, titles) |
||||
self.assertEqual(0, len(titles[docs])) |
||||
|
||||
refs = 'References' |
||||
self.assertIn(refs, titles) |
||||
self.assertEqual(0, len(titles[refs])) |
||||
|
||||
def test_template(self): |
||||
files = glob.glob('specs/*.rst') + glob.glob('specs/*/*') |
||||
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) |
@ -0,0 +1,33 @@
|
||||
// This work is licensed under a Creative Commons Attribution 3.0 |
||||
// Unported License. |
||||
// |
||||
// http://creativecommons.org/licenses/by/3.0/legalcode |
||||
digraph G { |
||||
label="Sample Graph" |
||||
|
||||
subgraph cluster_0 { |
||||
style=filled; |
||||
color=lightgrey; |
||||
node [style=filled,color=white]; |
||||
a0 -> a1 -> a2 -> a3; |
||||
label = "process #1"; |
||||
} |
||||
|
||||
subgraph cluster_1 { |
||||
node [style=filled]; |
||||
b0 -> b1 -> b2 -> b3; |
||||
label = "process #2"; |
||||
color=blue |
||||
} |
||||
|
||||
start -> a0; |
||||
start -> b0; |
||||
a1 -> b3; |
||||
b2 -> a3; |
||||
a3 -> a0; |
||||
a3 -> end; |
||||
b3 -> end; |
||||
|
||||
start [shape=Mdiamond]; |
||||
end [shape=Msquare]; |
||||
} |
@ -0,0 +1,82 @@
|
||||
.. |
||||
This work is licensed under a Creative Commons Attribution 3.0 Unported |
||||
License. |
||||
|
||||
http://creativecommons.org/licenses/by/3.0/legalcode |
||||
|
||||
========================================== |
||||
Title of your blueprint |
||||
========================================== |
||||
|
||||
|
||||
Problem description |
||||
=================== |
||||
|
||||
|
||||
Proposed change |
||||
=============== |
||||
|
||||
|
||||
Alternatives |
||||
------------ |
||||
|
||||
|
||||
Data model impact |
||||
----------------- |
||||
|
||||
|
||||
REST API impact |
||||
--------------- |
||||
|
||||
|
||||
Security impact |
||||
--------------- |
||||
|
||||
|
||||
Notifications impact |
||||
-------------------- |
||||
|
||||
|
||||
Other end user impact |
||||
--------------------- |
||||
|
||||
|
||||
Performance Impact |
||||
------------------ |
||||
|
||||
|
||||
Other deployer impact |
||||
--------------------- |
||||
|
||||
|
||||
Developer impact |
||||
---------------- |
||||
|
||||
|
||||
Implementation |
||||
============== |
||||
|
||||
Assignee(s) |
||||
----------- |
||||
|
||||
|
||||
Work Items |
||||
---------- |
||||
|
||||
|
||||
Dependencies |
||||
============ |
||||
|
||||
|
||||
Testing |
||||
======= |
||||
|
||||
|
||||
Documentation Impact |
||||
==================== |
||||
|
||||
|
||||
References |
||||
========== |
||||
|
||||
|
@ -0,0 +1,465 @@
|
||||
.. |
||||
This work is licensed under a Creative Commons Attribution 3.0 Unported |
||||
License. |
||||
|
||||
http://creativecommons.org/licenses/by/3.0/legalcode |
||||
|
||||
========================================== |
||||
Example Spec - The title of your blueprint |
||||
========================================== |
||||
|
||||
Include the URL of your launchpad blueprint: |
||||
|
||||
https://blueprints.launchpad.net/octavia/+spec/example |
||||
|
||||
Introduction paragraph -- why are we doing anything? A single paragraph of |
||||
prose that operators can understand. |
||||
|
||||
Some notes about using this template: |
||||
|
||||
* Your spec should be in ReSTructured text, like this template. |
||||
|
||||
* Please wrap text at 80 columns. |
||||
|
||||
* The filename in the git repository should match the launchpad URL, for |
||||
example a URL of: https://blueprints.launchpad.net/octavia/+spec/awesome-thing |
||||
should be named awesome-thing.rst |
||||
|
||||
* Please do not delete any of the sections in this template. If you have |
||||
nothing to say for a whole section, just write: None |
||||
|
||||
* For help with syntax, see http://sphinx-doc.org/rest.html |
||||
|
||||
* To test out your formatting, build the docs using tox, or see: |
||||
http://rst.ninjs.org |
||||
|
||||
* If you would like to provide a diagram with your spec, text representations |
||||
are preferred. http://asciiflow.com/ is a very nice tool to assist with |
||||
making ascii diagrams. blockdiag is another tool. These are described below. |
||||
For more complicated diagrams that need "real" graphics, yet still should |
||||
be in the git revision control system, GraphViz .dot files are acceptable. |
||||
If you require an image (screenshot) for your BP, attaching that to the BP |
||||
and checking it in is also accepted. However, text representations are prefered. |
||||
|
||||
* Diagram examples |
||||
|
||||
asciiflow:: |
||||
|
||||
+----------+ +-----------+ +----------+ |
||||
| A | | B | | C | |
||||
| +-----+ +--------+ | |
||||
+----------+ +-----------+ +----------+ |
||||
|
||||
blockdiag |
||||
|
||||
.. blockdiag:: |
||||
|
||||
blockdiag sample { |
||||
a -> b -> c; |
||||
} |
||||
|
||||
actdiag |
||||
|
||||
.. actdiag:: |
||||
|
||||
actdiag { |
||||
write -> convert -> image |
||||
lane user { |
||||
label = "User" |
||||
write [label = "Writing reST"]; |
||||
image [label = "Get diagram IMAGE"]; |
||||
} |
||||
lane actdiag { |
||||
convert [label = "Convert reST to Image"]; |
||||
} |
||||
} |
||||
|
||||
nwdiag |
||||
|
||||
.. nwdiag:: |
||||
|
||||
nwdiag { |
||||
network dmz { |
||||
address = "210.x.x.x/24" |
||||
|
||||
web01 [address = "210.x.x.1"]; |
||||
web02 [address = "210.x.x.2"]; |
||||
} |
||||
network internal { |
||||
address = "172.x.x.x/24"; |
||||
|
||||
web01 [address = "172.x.x.1"]; |
||||
web02 [address = "172.x.x.2"]; |
||||
db01; |
||||
db02; |
||||
} |
||||
} |
||||
|
||||
seqdiag |
||||
|
||||
.. seqdiag:: |
||||
|
||||
seqdiag { |
||||
browser -> webserver [label = "GET /index.html"]; |
||||
browser <-- webserver; |
||||
browser -> webserver [label = "POST /blog/comment"]; |
||||
webserver -> database [label = "INSERT comment"]; |
||||
webserver <-- database; |
||||
browser <-- webserver; |
||||
} |
||||
|
||||
graphviz |
||||
|
||||
.. graphviz:: |
||||
|
||||
digraph G { |
||||
label="Sample Graph" |
||||
|
||||
subgraph cluster_0 { |
||||
style=filled; |
||||
color=lightgrey; |
||||
node [style=filled,color=white]; |
||||
a0 -> a1 -> a2 -> a3; |
||||
label = "process #1"; |
||||
} |
||||
|
||||
subgraph cluster_1 { |
||||
node [style=filled]; |
||||
b0 -> b1 -> b2 -> b3; |
||||
label = "process #2"; |
||||
color=blue |
||||
} |
||||
|
||||
start -> a0; |
||||
start -> b0; |
||||
a1 -> b3; |
||||
b2 -> a3; |
||||
a3 -> a0; |
||||
a3 -> end; |
||||
b3 -> end; |
||||
|
||||
start [shape=Mdiamond]; |
||||
end [shape=Msquare]; |
||||
} |
||||
|
||||
graphviz (external file) |
||||
|
||||
.. graphviz:: example.dot |
||||
|
||||
|
||||
Problem description |
||||
=================== |
||||
|
||||
A detailed description of the problem: |
||||
|
||||
* For a new feature this might be use cases. Ensure you are clear about the |
||||
actors in each use case: End User vs Deployer |
||||
|
||||
* For a major reworking of something existing it would describe the |
||||
problems in that feature that are being addressed. |
||||
|
||||
|
||||
Proposed change |
||||
=============== |
||||
|
||||
Here is where you cover the change you propose to make in detail. How do you |
||||
propose to solve this problem? |
||||
|
||||
If this is one part of a larger effort make it clear where this piece ends. In |
||||
other words, what's the scope of this effort? |
||||
|
||||
Alternatives |
||||
------------ |
||||
|
||||
What other ways could we do this thing? Why aren't we using those? This doesn't |
||||
have to be a full literature review, but it should demonstrate that thought has |
||||
been put into why the proposed solution is an appropriate one. |
||||
|
||||
Data model impact |
||||
----------------- |
||||
|
||||
Changes which require modifications to the data model often have a wider impact |
||||
on the system. The community often has strong opinions on how the data model |
||||
should be evolved, from both a functional and performance perspective. It is |
||||
therefore important to capture and gain agreement as early as possible on any |
||||
proposed changes to the data model. |
||||
|
||||
Questions which need to be addressed by this section include: |
||||
|
||||
* What new data objects and/or database schema changes is this going to require? |
||||
|
||||
* What database migrations will accompany this change. |
||||
|
||||
* How will the initial set of new data objects be generated, for example if you |
||||
need to take into account existing instances, or modify other existing data |
||||
describe how that will work. |
||||
|
||||
REST API impact |
||||
--------------- |
||||
|
||||
Octavia includes several internal APIs (all of which should be versioned). |
||||
In defining how API(s) are affected by this change, make sure to |
||||
clearly indicate which API(s) specifically are being altered, which version |
||||
of the API(s) are being altered, and other pertinent details as described |
||||
below. |
||||
|
||||
While we are not using Neutron's attribute map facility since Octavia is |
||||
not Neutron, following the tried-and-true guidelines Neutron uses around |
||||
API changes is a good idea, including defining attribute map tables. For |
||||
reference: |
||||
|
||||
For each API resource to be implemented using Neutron's attribute map |
||||
facility (see the neutron.api.v2.attributes), describe the resource |
||||
collection and specify the name, type, and other essential details of |
||||
each new or modified attribute. A table similar to the following may |
||||
be used: |
||||
|
||||
+----------+-------+---------+---------+------------+--------------+ |
||||
|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 | |
||||
+----------+-------+---------+---------+------------+--------------+ |
||||
|color |string |RW, admin|'red' |'red', |color | |
||||
| | | | |'yellow', or|indicating | |
||||
| | | | |'green' |state | |
||||
+----------+-------+---------+---------+------------+--------------+ |
||||
|
||||
|
||||
Here is the other example of the table using csv-table |
||||
|
||||
|
||||
.. csv-table:: CSVTable |
||||
:header: Attribute Name,Type,Access,Default Value,Validation Conversion,Description |
||||
|
||||
id,string (UUID),"RO, all",generated,N/A,identity |
||||
name,string,"RW, all","''",string,human-readable name |
||||
color,string,"RW, admin",red,"'red', 'yellow' or 'green'",color indicating state |
||||
|
||||
|
||||
Each API method which is either added or changed that does not use |
||||
Neutron's attribute map facility should have the following: |
||||
|
||||
* Specification for the method |
||||
|
||||
* A description of what the method does suitable for use in |
||||
user documentation |
||||
|
||||
* Method type (POST/PUT/GET/DELETE) |
||||
|
||||
* Normal http response code(s) |
||||
|
||||
* Expected error http response code(s) |
||||
|
||||
* A description for each possible error code should be included |
||||
describing semantic errors which can cause it such as |
||||
inconsistent parameters supplied to the method, or when an |
||||
instance is not in an appropriate state for the request to |
||||
succeed. Errors caused by syntactic problems covered by the JSON |
||||
schema defintion do not need to be included. |
||||
|
||||
* URL for the resource |
||||
|
||||
* Parameters which can be passed via the url |
||||
|
||||
* JSON schema definition for the body data if allowed |
||||
|
||||
* JSON schema definition for the response data if any |
||||
|
||||
* Example use case including typical API samples for both data supplied |
||||
by the caller and the response |
||||
|
||||
* Discuss any API policy changes, and discuss what things a deployer needs to |
||||
think about when defining their API policy. This is in reference to the |
||||
policy.json file. |
||||
|
||||
Note that the schema should be defined as restrictively as |
||||
possible. Parameters which are required should be marked as such and |
||||
only under exceptional circumstances should additional parameters |
||||
which are not defined in the schema be permitted (eg |
||||
additionaProperties should be False). |
||||
|
||||
Reuse of existing predefined parameter types such as regexps for |
||||
passwords and user defined names is highly encouraged. |
||||
|
||||
Security impact |
||||
--------------- |
||||
|
||||
Describe any potential security impact on the system. Some of the items to |
||||
consider include: |
||||
|
||||
* Does this change touch sensitive data such as tokens, keys, or user data? |
||||
|
||||
* Does this change alter the API in a way that may impact security, such as |
||||
a new way to access sensitive information or a new way to login? |
||||
|
||||
* Does this change involve cryptography or hashing? |
||||
|
||||
* Does this change require the use of sudo or any elevated privileges? |
||||
|
||||
* Does this change involve using or parsing user-provided data? This could |
||||
be directly at the API level or indirectly such as changes to a cache layer. |
||||
|
||||
* Can this change enable a resource exhaustion attack, such as allowing a |
||||
single API interaction to consume significant server resources? Some examples |
||||
of this include launching subprocesses for each connection, or entity |
||||
expansion attacks in XML. |
||||
|
||||
For more detailed guidance, please see the OpenStack Security Guidelines as |
||||
a reference (https://wiki.openstack.org/wiki/Security/Guidelines). These |
||||
guidelines are a work in progress and are designed to help you identify |
||||
security best practices. For further information, feel free to reach out |
||||
to the OpenStack Security Group at openstack-security@lists.openstack.org. |
||||
|
||||
Notifications impact |
||||
-------------------- |
||||
|
||||
Please specify any changes to notifications. Be that an extra notification, |
||||
changes to an existing notification, or removing a notification. |
||||
|
||||
Other end user impact |
||||
--------------------- |
||||
|
||||
Aside from the API, are there other ways a user will interact with this feature? |
||||
Keep in mind that 'user' in this context could mean either tenant or operator. |
||||
|
||||
* Does this change have an impact on python-neutronclient? What does the user |
||||
interface there look like? |
||||
|
||||
Performance Impact |
||||
------------------ |
||||
|
||||
Describe any potential performance impact on the system, for example |
||||
how often will new code be called, and is there a major change to the calling |
||||
pattern of existing code. |
||||
|
||||
Examples of things to consider here include: |
||||
|
||||
* A periodic task might look like a small addition but if it calls conductor or |
||||
another service the load is multiplied by the number of nodes in the system. |
||||
|
||||
* A small change in a utility function or a commonly used decorator can have a |
||||
large impacts on performance. |
||||
|
||||
* Calls which result in a database queries (whether direct or via conductor) can |
||||
have a profound impact on performance when called in critical sections of the |
||||
code. |
||||
|
||||
* Will the change include any locking, and if so what considerations are there on |
||||
holding the lock? |
||||
|
||||
Other deployer impact |
||||
--------------------- |
||||
|
||||
Discuss things that will affect how you deploy and configure OpenStack |
||||
that have not already been mentioned, such as: |
||||
|
||||
* What config options are being added? Should they be more generic than |
||||
proposed (for example a flag that other hypervisor drivers might want to |
||||
implement as well)? Are the default values ones which will work well in |
||||
real deployments? |
||||
|
||||
* Is this a change that takes immediate effect after its merged, or is it |
||||
something that has to be explicitly enabled? |
||||
|
||||
* If this change is a new binary, how would it be deployed? |
||||
|
||||
* Please state anything that those doing continuous deployment, or those |
||||
upgrading from the previous release, need to be aware of. Also describe |
||||
any plans to deprecate configuration values or features. For example, if we |
||||
change the directory name that instances are stored in, how do we handle |
||||
instance directories created before the change landed? Do we move them? Do |
||||
we have a special case in the code? Do we assume that the operator will |
||||
recreate all the instances in their cloud? |
||||
|
||||
Developer impact |
||||
---------------- |
||||
|
||||
Discuss things that will affect other developers working on OpenStack, |
||||
such as: |
||||
|
||||
* If the blueprint proposes a change to the API, discussion of how other |
||||
plugins would implement the feature is required. |
||||
|
||||
|
||||
Implementation |
||||
============== |
||||
|
||||
Assignee(s) |
||||
----------- |
||||
|
||||
Who is leading the writing of the code? Or is this a blueprint where you're |
||||
throwing it out there to see who picks it up? |
||||
|
||||
If more than one person is working on the implementation, please designate the |
||||
primary author and contact. |
||||
|
||||
Primary assignee: |
||||
<launchpad-id or None> |
||||
|
||||
Other contributors: |
||||
<launchpad-id or None> |
||||
|
||||
Work Items |
||||
---------- |
||||
|
||||
Work items or tasks -- break the feature up into the things that need to be |
||||
done to implement it. Those parts might end up being done by different people, |
||||
but we're mostly trying to understand the timeline for implementation. |
||||
|
||||
|
||||
Dependencies |
||||
============ |
||||
|
||||
* Include specific references to specs and/or blueprints in octavia, or in other |
||||
projects, that this one either depends on or is related to. |
||||
|
||||
* If this requires functionality of another project that is not currently used |
||||
by Octavia document that fact. |
||||
|
||||
* Does this feature require any new library dependencies or code otherwise not |
||||
included in OpenStack? Or does it depend on a specific version of library? |
||||
|
||||
|
||||
Testing |
||||
======= |
||||
|
||||
Please discuss how the change will be tested. We especially want to know what |
||||
tempest tests will be added. It is assumed that unit test coverage will be |
||||
added so that doesn't need to be mentioned explicitly, but discussion of why |
||||
you think unit tests are sufficient and we don't need to add more tempest |
||||
tests would need to be included. |
||||
|
||||
Is this untestable in gate given current limitations (specific hardware / |
||||
software configurations available)? If so, are there mitigation plans (3rd |
||||
party testing, gate enhancements, etc). |
||||
|
||||
|
||||
Documentation Impact |
||||
==================== |
||||
|
||||
What is the impact on the docs team of this change? Some changes might require |
||||
donating resources to the docs team to have the documentation updated. Don't |
||||
repeat details discussed above, but please reference them here. |
||||
|
||||
|
||||
References |
||||
========== |
||||
|
||||
Please add any useful references here. You are not required to have any |
||||
reference. Moreover, this specification should still make sense when your |
||||
references are unavailable. Examples of what you could include are: |
||||
|
||||
* Links to mailing list or IRC discussions |
||||
|
||||
* Links to notes from a summit session |
||||
|
||||
* Links to relevant research, if appropriate |
||||
|
||||
* Related specifications as appropriate (e.g. link any vendor documentation) |
||||
|
||||
* Anything else you feel it is worthwhile to refer to |
@ -0,0 +1,82 @@
|
||||
.. |
||||
This work is licensed under a Creative Commons Attribution 3.0 Unported |
||||
License. |
||||
|
||||
http://creativecommons.org/licenses/by/3.0/legalcode |
||||
|
||||
========================================== |
||||
Title of your blueprint |
||||
========================================== |
||||
|
||||
|
||||
Problem description |
||||
=================== |
||||
|
||||
|
||||
Proposed change |
||||
=============== |
||||
|
||||
|
||||
Alternatives |
||||
------------ |
||||
|
||||
|
||||
Data model impact |
||||
----------------- |
||||
|
||||
|
||||
REST API impact |
||||
--------------- |
||||
|
||||
|
||||
Security impact |
||||
--------------- |
||||
|
||||
|
||||
Notifications impact |
||||
-------------------- |
||||
|
||||
|
||||
Other end user impact |
||||
--------------------- |
||||
|
||||
|
||||
Performance Impact |
||||
------------------ |
||||
|
||||
|
||||
Other deployer impact |
||||
--------------------- |
||||
|
||||
|
||||
Developer impact |
||||
---------------- |
||||
|
||||
|
||||
Implementation |
||||
============== |
||||
|
||||
Assignee(s) |
||||
----------- |
||||
|
||||
|
||||
Work Items |
||||
---------- |
||||
|
||||
|
||||
Dependencies |
||||
============ |
||||
|
||||
|
||||
Testing |
||||
======= |
||||
|
||||
|
||||
Documentation Impact |
||||
==================== |
||||
|
||||
|
||||
References |
||||
========== |
||||
|
||||
|
@ -0,0 +1,12 @@
|
||||
hacking>=0.9.1,<0.10 |
||||
|
||||
cliff>=1.6.0 |
||||
coverage>=3.6 |
||||
discover |
||||
fixtures>=0.3.14 |
||||
mock>=1.0 |
||||
python-subunit>=0.0.18 |
||||
ordereddict |
||||
testrepository>=0.0.18 |
||||
testtools>=0.9.34 |
||||
WebTest>=2.0 |
@ -0,0 +1,23 @@
|
||||
[tox] |
||||
minversion = 1.6 |
||||
envlist = docs,py27,py33,pep8 |
||||
skipsdist = True |
||||
|
||||
[testenv] |
||||
usedevelop = True |
||||
setenv = VIRTUAL_ENV={envdir} |
||||
install_command = pip install -U {opts} {packages} |
||||
deps = -r{toxinidir}/requirements.txt |
||||
-r{toxinidir}/test-requirements.txt |
||||
commands = python setup.py testr --slowest --testr-args='{posargs}' |
||||
|
||||
[testenv:pep8] |
||||
commands = flake8 |
||||
|
||||
[testenv:docs] |
||||
commands = python setup.py build_sphinx |
||||
|
||||
[flake8] |
||||
ignore = None |
||||
exclude = .tox,doc |
||||
show-source = true |
Loading…
Reference in new issue