summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorgalstrom21 <jshepher@rackspace.com>2014-07-24 20:49:01 -0500
committerJJ Asghar <jj@getchef.com>2014-07-25 12:13:09 -0500
commit9159089b365325595da545488bb9c33e50d12e78 (patch)
treeff96aabdf2cb4adc9e323430e17e76e68210ad28
parent3ad97ca277083e8c1349894debbf6d7db7cfbeeb (diff)
Filling in the initial layout for the repo.
Notes
Notes (review): Verified+2: Jenkins Code-Review+2: Matt Ray <matthewhray@gmail.com> Code-Review+2: Justin Shepherd <jshepher@rackspace.com> Workflow+1: Justin Shepherd <jshepher@rackspace.com> Code-Review+1: JJ Asghar <jj@getchef.com> Submitted-by: Jenkins Submitted-at: Fri, 25 Jul 2014 21:52:05 +0000 Reviewed-on: https://review.openstack.org/109471 Project: stackforge/openstack-chef-specs Branch: refs/heads/master
-rw-r--r--.gitignore5
-rw-r--r--README.rst45
-rw-r--r--doc/source/conf.py269
-rw-r--r--doc/source/index.rst35
l---------doc/source/specs1
-rw-r--r--requirements.txt6
-rw-r--r--setup.cfg23
-rw-r--r--setup.py22
-rw-r--r--specs/icehouse/.gitignore0
-rw-r--r--specs/icehouse/block-storage/.gitignore0
-rw-r--r--specs/icehouse/ceph/.gitignore0
-rw-r--r--specs/icehouse/client/.gitignore0
-rw-r--r--specs/icehouse/common/.gitignore0
-rw-r--r--specs/icehouse/compute/.gitignore0
-rw-r--r--specs/icehouse/cookbook-openstack-integration-test/.gitignore0
-rw-r--r--specs/icehouse/dashboard/.gitignore0
-rw-r--r--specs/icehouse/data-processing/.gitignore0
-rw-r--r--specs/icehouse/database/.gitignore0
-rw-r--r--specs/icehouse/identity/.gitignore0
-rw-r--r--specs/icehouse/image/.gitignore0
-rw-r--r--specs/icehouse/metering/.gitignore0
-rw-r--r--specs/icehouse/network/.gitignore0
-rw-r--r--specs/icehouse/object-storage/.gitignore0
-rw-r--r--specs/icehouse/openstack-manuals/.gitignore0
-rw-r--r--specs/icehouse/orchestration/.gitignore0
-rw-r--r--specs/icehouse/template.rst323
-rw-r--r--specs/juno/.gitignore0
-rw-r--r--specs/juno/block-storage/.gitignore0
-rw-r--r--specs/juno/ceph/.gitignore0
-rw-r--r--specs/juno/client/.gitignore0
-rw-r--r--specs/juno/common/.gitignore0
-rw-r--r--specs/juno/compute/.gitignore0
-rw-r--r--specs/juno/cookbook-openstack-integration-test/.gitignore0
-rw-r--r--specs/juno/dashboard/.gitignore0
-rw-r--r--specs/juno/data-processing/.gitignore0
-rw-r--r--specs/juno/database/.gitignore0
-rw-r--r--specs/juno/identity/.gitignore0
-rw-r--r--specs/juno/image/.gitignore0
-rw-r--r--specs/juno/metering/.gitignore0
-rw-r--r--specs/juno/network/.gitignore0
-rw-r--r--specs/juno/object-storage/.gitignore0
-rw-r--r--specs/juno/openstack-manuals/.gitignore0
-rw-r--r--specs/juno/orchestration/.gitignore0
-rw-r--r--specs/juno/template.rst323
-rw-r--r--specs/template.rst323
-rw-r--r--tox.ini15
46 files changed, 1390 insertions, 0 deletions
diff --git a/.gitignore b/.gitignore
new file mode 100644
index 0000000..1698aef
--- /dev/null
+++ b/.gitignore
@@ -0,0 +1,5 @@
1AUTHORS
2ChangeLog
3build
4.tox
5*.egg*
diff --git a/README.rst b/README.rst
new file mode 100644
index 0000000..4f202ac
--- /dev/null
+++ b/README.rst
@@ -0,0 +1,45 @@
1==================================
2OpenStack-chef Specifications
3==================================
4
5This git repository is used to hold approved design specifications for additions
6to the openstack-chef project. Reviews of the specs are done in gerrit, using a similar
7workflow to how we review and merge changes to the code itself.
8
9The layout of this repository is::
10
11 specs/<release>/<cookbook>/
12
13You can find an example spec in `specs/template.rst`.
14
15Specifications are proposed for a given release by adding them to the
16`specs/<release>` directory and posting it for review. The implementation
17status of a blueprint for a given release can be found by looking at the
18blueprint in launchpad. Not all approved blueprints will get fully implemented.
19
20Specifications have to be re-proposed for every release. The review may be
21quick, but even if something was previously approved, it should be re-reviewed
22to make sure it still makes sense as written.
23
24Prior to the Juno development cycle, this repository was not used for spec
25reviews. Reviews prior to Juno were completed entirely through Launchpad
26blueprints::
27
28 http://blueprints.launchpad.net/openstack-chef
29
30Please note, Launchpad blueprints are still used for tracking the
31current status of blueprints. For more information, see::
32
33 https://wiki.openstack.org/wiki/Blueprints
34
35For more information about working with gerrit, see::
36
37 https://wiki.openstack.org/wiki/Gerrit_Workflow
38
39To validate that the specification is syntactically correct (i.e. get more
40confidence in the Jenkins result), please execute the following command::
41
42 $ tox
43
44After running ``tox``, the documentation will be available for viewing in HTML
45format in the ``doc/build/`` directory.
diff --git a/doc/source/conf.py b/doc/source/conf.py
new file mode 100644
index 0000000..9906912
--- /dev/null
+++ b/doc/source/conf.py
@@ -0,0 +1,269 @@
1# -*- coding: utf-8 -*-
2#
3# Tempest documentation build configuration file, created by
4# sphinx-quickstart on Tue May 21 17:43:32 2013.
5#
6# This file is execfile()d with the current directory set to its containing dir.
7#
8# Note that not all possible configuration values are present in this
9# autogenerated file.
10#
11# All configuration values have a default; values that are commented out
12# serve to show the default.
13
14import sys
15import os
16
17# If extensions (or modules to document with autodoc) are in another directory,
18# add these directories to sys.path here. If the directory is relative to the
19# documentation root, use os.path.abspath to make it absolute, like shown here.
20#sys.path.insert(0, os.path.abspath('.'))
21
22# -- General configuration ---------------------------------------------------
23
24# If your documentation needs a minimal Sphinx version, state it here.
25#needs_sphinx = '1.0'
26
27# Add any Sphinx extension module names here, as strings. They can be extensions
28# coming with Sphinx (named 'sphinx.ext.*') or your custom ones.
29extensions = ['sphinx.ext.autodoc',
30 'sphinx.ext.intersphinx',
31 'sphinx.ext.todo',
32 'sphinx.ext.viewcode',
33 'oslosphinx'
34 ]
35
36todo_include_todos = True
37
38# Add any paths that contain templates here, relative to this directory.
39templates_path = ['_templates']
40
41# The suffix of source filenames.
42source_suffix = '.rst'
43
44# The encoding of source files.
45#source_encoding = 'utf-8-sig'
46
47# The master toctree document.
48master_doc = 'index'
49
50# General information about the project.
51project = u'Chef for Openstack Specs'
52copyright = u'2014, Chef for Openstack Team'
53
54# The language for content autogenerated by Sphinx. Refer to documentation
55# for a list of supported languages.
56#language = None
57
58# There are two options for replacing |today|: either, you set today to some
59# non-false value, then it is used:
60#today = ''
61# Else, today_fmt is used as the format for a strftime call.
62#today_fmt = '%B %d, %Y'
63
64# List of patterns, relative to source directory, that match files and
65# directories to ignore when looking for source files.
66exclude_patterns = ['_build']
67
68# The reST default role (used for this markup: `text`) to use for all documents.
69#default_role = None
70
71# If true, '()' will be appended to :func: etc. cross-reference text.
72#add_function_parentheses = True
73
74# If true, the current module name will be prepended to all description
75# unit titles (such as .. function::).
76add_module_names = False
77
78# If true, sectionauthor and moduleauthor directives will be shown in the
79# output. They are ignored by default.
80show_authors = False
81
82# The name of the Pygments (syntax highlighting) style to use.
83pygments_style = 'sphinx'
84
85# A list of ignored prefixes for module index sorting.
86modindex_common_prefix = ['openstack-chef-specs.']
87
88# -- Options for man page output ----------------------------------------------
89man_pages = []
90
91# -- Options for HTML output ---------------------------------------------------
92
93# The theme to use for HTML and HTML Help pages. See the documentation for
94# a list of builtin themes.
95html_theme = 'nature'
96
97# Theme options are theme-specific and customize the look and feel of a theme
98# further. For a list of options available for each theme, see the
99# documentation.
100#html_theme_options = {}
101
102# Add any paths that contain custom themes here, relative to this directory.
103#html_theme_path = []
104
105# The name for this set of Sphinx documents. If None, it defaults to
106# "<project> v<release> documentation".
107#html_title = None
108
109# A shorter title for the navigation bar. Default is the same as html_title.
110#html_short_title = None
111
112# The name of an image file (relative to this directory) to place at the top
113# of the sidebar.
114#html_logo = None
115
116# The name of an image file (within the static path) to use as favicon of the
117# docs. This file should be a Windows icon file (.ico) being 16x16 or 32x32
118# pixels large.
119#html_favicon = None
120
121# If not '', a 'Last updated on:' timestamp is inserted at every page bottom,
122# using the given strftime format.
123git_cmd = "git log --pretty=format:'%ad, commit %h' --date=local -n1"
124html_last_updated_fmt = os.popen(git_cmd).read()
125
126# If true, SmartyPants will be used to convert quotes and dashes to
127# typographically correct entities.
128#html_use_smartypants = True
129
130# Custom sidebar templates, maps document names to template names.
131#html_sidebars = {}
132
133# Additional templates that should be rendered to pages, maps page names to
134# template names.
135#html_additional_pages = {}
136
137# If false, no module index is generated.
138html_domain_indices = False
139
140# If false, no index is generated.
141html_use_index = False
142
143# If true, the index is split into individual pages for each letter.
144#html_split_index = False
145
146# If true, links to the reST sources are added to the pages.
147#html_show_sourcelink = True
148
149# If true, "Created using Sphinx" is shown in the HTML footer. Default is True.
150#html_show_sphinx = True
151
152# If true, "(C) Copyright ..." is shown in the HTML footer. Default is True.
153#html_show_copyright = True
154
155# If true, an OpenSearch description file will be output, and all pages will
156# contain a <link> tag referring to it. The value of this option must be the
157# base URL from which the finished HTML is served.
158#html_use_opensearch = ''
159
160# This is the file name suffix for HTML files (e.g. ".xhtml").
161#html_file_suffix = None
162
163# Output file base name for HTML help builder.
164htmlhelp_basename = 'Openstack-Chef-Specsdoc'
165
166
167# -- Options for LaTeX output --------------------------------------------------
168
169latex_elements = {
170# The paper size ('letterpaper' or 'a4paper').
171#'papersize': 'letterpaper',
172
173# The font size ('10pt', '11pt' or '12pt').
174#'pointsize': '10pt',
175
176# Additional stuff for the LaTeX preamble.
177#'preamble': '',
178}
179
180# Grouping the document tree into LaTeX files. List of tuples
181# (source start file, target name, title, author, documentclass [howto/manual]).
182latex_documents = [
183 ('index', 'Openstack-Chef-specs.tex', u'Chef for Openstack Specs',
184 u'Chef for OpenStack Team', 'manual'),
185]
186
187# The name of an image file (relative to this directory) to place at the top of
188# the title page.
189#latex_logo = None
190
191# For "manual" documents, if this is true, then toplevel headings are parts,
192# not chapters.
193#latex_use_parts = False
194
195# If true, show page references after internal links.
196#latex_show_pagerefs = False
197
198# If true, show URL addresses after external links.
199#latex_show_urls = False
200
201# Documents to append as an appendix to all manuals.
202#latex_appendices = []
203
204# If false, no module index is generated.
205#latex_domain_indices = True
206
207# -- Options for Texinfo output ------------------------------------------------
208
209# Grouping the document tree into Texinfo files. List of tuples
210# (source start file, target name, title, author,
211# dir menu entry, description, category)
212texinfo_documents = [
213 ('index', 'Openstack-Chef-specs', u'Chef for Openstack Design Specs',
214 u'Chef for OpenStack Team', 'openstack-chef-specs',
215 'Design specifications for the Chef for Openstack project.',
216 'Miscellaneous'),
217]
218
219# Documents to append as an appendix to all manuals.
220#texinfo_appendices = []
221
222# If false, no module index is generated.
223#texinfo_domain_indices = True
224
225# How to display URL addresses: 'footnote', 'no', or 'inline'.
226#texinfo_show_urls = 'footnote'
227
228
229# -- Options for Epub output ---------------------------------------------------
230
231# Bibliographic Dublin Core info.
232epub_title = u'Chef for Openstack Specs'
233epub_author = u'Chef for OpenStack Team'
234epub_publisher = u'Chef for OpenStack Team'
235epub_copyright = u'2014, Chef for OpenStack Team'
236
237# The language of the text. It defaults to the language option
238# or en if the language is not set.
239#epub_language = ''
240
241# The scheme of the identifier. Typical schemes are ISBN or URL.
242#epub_scheme = ''
243
244# The unique identifier of the text. This can be a ISBN number
245# or the project homepage.
246#epub_identifier = ''
247
248# A unique identification for the text.
249#epub_uid = ''
250
251# A tuple containing the cover image and cover page html template filenames.
252#epub_cover = ()
253
254# HTML files that should be inserted before the pages created by sphinx.
255# The format is a list of tuples containing the path and title.
256#epub_pre_files = []
257
258# HTML files shat should be inserted after the pages created by sphinx.
259# The format is a list of tuples containing the path and title.
260#epub_post_files = []
261
262# A list of files that should not be packed into the epub file.
263#epub_exclude_files = []
264
265# The depth of the table of contents in toc.ncx.
266#epub_tocdepth = 3
267
268# Allow duplicate toc entries.
269#epub_tocdup = True
diff --git a/doc/source/index.rst b/doc/source/index.rst
new file mode 100644
index 0000000..a6f2c2e
--- /dev/null
+++ b/doc/source/index.rst
@@ -0,0 +1,35 @@
1.. openstack-chef-specs documentation master file
2
3=========================================
4Openstack for Chef Project Specifications
5=========================================
6
7Contents:
8
9.. toctree::
10 :glob:
11 :maxdepth: 1
12
13 specs/*
14
15Juno approved specs:
16
17.. toctree::
18 :glob:
19 :maxdepth: 1
20
21 specs/juno/*
22
23Icehouse approved specs:
24
25.. toctree::
26 :glob:
27 :maxdepth: 1
28
29 specs/icehouse/*
30
31==================
32Indices and tables
33==================
34
35* :ref:`search`
diff --git a/doc/source/specs b/doc/source/specs
new file mode 120000
index 0000000..87a4030
--- /dev/null
+++ b/doc/source/specs
@@ -0,0 +1 @@
../../specs \ No newline at end of file
diff --git a/requirements.txt b/requirements.txt
new file mode 100644
index 0000000..bdd3e93
--- /dev/null
+++ b/requirements.txt
@@ -0,0 +1,6 @@
1docutils==0.9.1
2oslosphinx
3pbr>=0.6,<1.0
4sphinx>=1.1.2,<1.2
5testrepository>=0.0.18
6testtools>=0.9.34
diff --git a/setup.cfg b/setup.cfg
new file mode 100644
index 0000000..492f4f0
--- /dev/null
+++ b/setup.cfg
@@ -0,0 +1,23 @@
1[metadata]
2name = openstack-chef-specs
3summary = Chef for Openstack Project Development Specs
4description-file =
5 README.rst
6author = OpenStack
7author-email = openstack-dev@lists.openstack.org
8home-page = http://www.openstack.org/
9classifier =
10 Intended Audience :: Developers
11 License :: OSI Approved :: Apache Software License
12 Operating System :: POSIX :: Linux
13
14[build_sphinx]
15all_files = 1
16build-dir = doc/build
17source-dir = doc/source
18
19[pbr]
20warnerrors = True
21
22[wheel]
23universal = 1
diff --git a/setup.py b/setup.py
new file mode 100644
index 0000000..70c2b3f
--- /dev/null
+++ b/setup.py
@@ -0,0 +1,22 @@
1#!/usr/bin/env python
2# Copyright (c) 2013 Hewlett-Packard Development Company, L.P.
3#
4# Licensed under the Apache License, Version 2.0 (the "License");
5# you may not use this file except in compliance with the License.
6# You may obtain a copy of the License at
7#
8# http://www.apache.org/licenses/LICENSE-2.0
9#
10# Unless required by applicable law or agreed to in writing, software
11# distributed under the License is distributed on an "AS IS" BASIS,
12# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
13# implied.
14# See the License for the specific language governing permissions and
15# limitations under the License.
16
17# THIS FILE IS MANAGED BY THE GLOBAL REQUIREMENTS REPO - DO NOT EDIT
18import setuptools
19
20setuptools.setup(
21 setup_requires=['pbr'],
22 pbr=True)
diff --git a/specs/icehouse/.gitignore b/specs/icehouse/.gitignore
new file mode 100644
index 0000000..e69de29
--- /dev/null
+++ b/specs/icehouse/.gitignore
diff --git a/specs/icehouse/block-storage/.gitignore b/specs/icehouse/block-storage/.gitignore
new file mode 100644
index 0000000..e69de29
--- /dev/null
+++ b/specs/icehouse/block-storage/.gitignore
diff --git a/specs/icehouse/ceph/.gitignore b/specs/icehouse/ceph/.gitignore
new file mode 100644
index 0000000..e69de29
--- /dev/null
+++ b/specs/icehouse/ceph/.gitignore
diff --git a/specs/icehouse/client/.gitignore b/specs/icehouse/client/.gitignore
new file mode 100644
index 0000000..e69de29
--- /dev/null
+++ b/specs/icehouse/client/.gitignore
diff --git a/specs/icehouse/common/.gitignore b/specs/icehouse/common/.gitignore
new file mode 100644
index 0000000..e69de29
--- /dev/null
+++ b/specs/icehouse/common/.gitignore
diff --git a/specs/icehouse/compute/.gitignore b/specs/icehouse/compute/.gitignore
new file mode 100644
index 0000000..e69de29
--- /dev/null
+++ b/specs/icehouse/compute/.gitignore
diff --git a/specs/icehouse/cookbook-openstack-integration-test/.gitignore b/specs/icehouse/cookbook-openstack-integration-test/.gitignore
new file mode 100644
index 0000000..e69de29
--- /dev/null
+++ b/specs/icehouse/cookbook-openstack-integration-test/.gitignore
diff --git a/specs/icehouse/dashboard/.gitignore b/specs/icehouse/dashboard/.gitignore
new file mode 100644
index 0000000..e69de29
--- /dev/null
+++ b/specs/icehouse/dashboard/.gitignore
diff --git a/specs/icehouse/data-processing/.gitignore b/specs/icehouse/data-processing/.gitignore
new file mode 100644
index 0000000..e69de29
--- /dev/null
+++ b/specs/icehouse/data-processing/.gitignore
diff --git a/specs/icehouse/database/.gitignore b/specs/icehouse/database/.gitignore
new file mode 100644
index 0000000..e69de29
--- /dev/null
+++ b/specs/icehouse/database/.gitignore
diff --git a/specs/icehouse/identity/.gitignore b/specs/icehouse/identity/.gitignore
new file mode 100644
index 0000000..e69de29
--- /dev/null
+++ b/specs/icehouse/identity/.gitignore
diff --git a/specs/icehouse/image/.gitignore b/specs/icehouse/image/.gitignore
new file mode 100644
index 0000000..e69de29
--- /dev/null
+++ b/specs/icehouse/image/.gitignore
diff --git a/specs/icehouse/metering/.gitignore b/specs/icehouse/metering/.gitignore
new file mode 100644
index 0000000..e69de29
--- /dev/null
+++ b/specs/icehouse/metering/.gitignore
diff --git a/specs/icehouse/network/.gitignore b/specs/icehouse/network/.gitignore
new file mode 100644
index 0000000..e69de29
--- /dev/null
+++ b/specs/icehouse/network/.gitignore
diff --git a/specs/icehouse/object-storage/.gitignore b/specs/icehouse/object-storage/.gitignore
new file mode 100644
index 0000000..e69de29
--- /dev/null
+++ b/specs/icehouse/object-storage/.gitignore
diff --git a/specs/icehouse/openstack-manuals/.gitignore b/specs/icehouse/openstack-manuals/.gitignore
new file mode 100644
index 0000000..e69de29
--- /dev/null
+++ b/specs/icehouse/openstack-manuals/.gitignore
diff --git a/specs/icehouse/orchestration/.gitignore b/specs/icehouse/orchestration/.gitignore
new file mode 100644
index 0000000..e69de29
--- /dev/null
+++ b/specs/icehouse/orchestration/.gitignore
diff --git a/specs/icehouse/template.rst b/specs/icehouse/template.rst
new file mode 100644
index 0000000..06cbf50
--- /dev/null
+++ b/specs/icehouse/template.rst
@@ -0,0 +1,323 @@
1..
2 This work is licensed under a Creative Commons Attribution 3.0 Unported
3 License.
4
5 http://creativecommons.org/licenses/by/3.0/legalcode
6
7==========================================
8Example Spec - The title of your blueprint
9==========================================
10
11Include the URL of your launchpad blueprint:
12
13https://blueprints.launchpad.net/openstack-chef/+spec/example
14
15Introduction paragraph -- why are we doing anything? A single paragraph of
16prose that operators can understand. The title and this first paragraph
17should be used as the subject line and body of the commit message
18respectively.
19
20Some notes about using this template:
21
22* Your spec should be in ReSTructured text, like this template.
23
24* Please wrap text at 79 columns.
25
26* The filename in the git repository should match the launchpad URL, for
27 example a URL of: https://blueprints.launchpad.net/openstack-chef/+spec/awesome-thing
28 should be named awesome-thing.rst
29
30* Please do not delete any of the sections in this template. If you have
31 nothing to say for a whole section, just write: None
32
33* For help with syntax, see http://sphinx-doc.org/rest.html
34
35* To test out your formatting, build the docs using tox and see the generated
36 HTML file in doc/build/html/specs/<path_of_your_file>
37
38* If you would like to provide a diagram with your spec, ascii diagrams are
39 required. http://asciiflow.com/ is a very nice tool to assist with making
40 ascii diagrams. The reason for this is that the tool used to review specs is
41 based purely on plain text. Plain text will allow review to proceed without
42 having to look at additional files which can not be viewed in gerrit. It
43 will also allow inline feedback on the diagram itself.
44
45Problem description
46===================
47
48A detailed description of the problem:
49
50* For a new feature this might be use cases. Ensure you are clear about the
51 actors in each use case: End User vs Deployer
52
53* For a major reworking of something existing it would describe the
54 problems in that feature that are being addressed.
55
56
57Proposed change
58===============
59
60Here is where you cover the change you propose to make in detail. How do you
61propose to solve this problem?
62
63If this is one part of a larger effort make it clear where this piece ends. In
64other words, what's the scope of this effort?
65
66Alternatives
67------------
68
69What other ways could we do this thing? Why aren't we using those? This doesn't
70have to be a full literature review, but it should demonstrate that thought has
71been put into why the proposed solution is an appropriate one.
72
73Data model impact
74-----------------
75
76Changes which require modifications to the data model often have a wider impact
77on the system. The community often has strong opinions on how the data model
78should be evolved, from both a functional and performance perspective. It is
79therefore important to capture and gain agreement as early as possible on any
80proposed changes to the data model.
81
82Questions which need to be addressed by this section include:
83
84* What new data objects and/or database schema changes is this going to
85 require?
86
87* What database migrations will accompany this change.
88
89* How will the initial set of new data objects be generated, for example if you
90 need to take into account existing instances, or modify other existing data
91 describe how that will work.
92
93REST API impact
94---------------
95
96Each API method which is either added or changed should have the following
97
98* Specification for the method
99
100 * A description of what the method does suitable for use in
101 user documentation
102
103 * Method type (POST/PUT/GET/DELETE)
104
105 * Normal http response code(s)
106
107 * Expected error http response code(s)
108
109 * A description for each possible error code should be included
110 describing semantic errors which can cause it such as
111 inconsistent parameters supplied to the method, or when an
112 instance is not in an appropriate state for the request to
113 succeed. Errors caused by syntactic problems covered by the JSON
114 schema defintion do not need to be included.
115
116 * URL for the resource
117
118 * Parameters which can be passed via the url
119
120 * JSON schema definition for the body data if allowed
121
122 * JSON schema definition for the response data if any
123
124* Example use case including typical API samples for both data supplied
125 by the caller and the response
126
127* Discuss any policy changes, and discuss what things a deployer needs to
128 think about when defining their policy.
129
130Example JSON schema definitions can be found in the openstack-chef tree
131http://git.openstack.org/cgit/openstack/openstack-chef/tree/openstack-chef/api/openstack/compute/schemas/v3
132
133Note that the schema should be defined as restrictively as
134possible. Parameters which are required should be marked as such and
135only under exceptional circumstances should additional parameters
136which are not defined in the schema be permitted (eg
137additionaProperties should be False).
138
139Reuse of existing predefined parameter types such as regexps for
140passwords and user defined names is highly encouraged.
141
142Security impact
143---------------
144
145Describe any potential security impact on the system. Some of the items to
146consider include:
147
148* Does this change touch sensitive data such as tokens, keys, or user data?
149
150* Does this change alter the API in a way that may impact security, such as
151 a new way to access sensitive information or a new way to login?
152
153* Does this change involve cryptography or hashing?
154
155* Does this change require the use of sudo or any elevated privileges?
156
157* Does this change involve using or parsing user-provided data? This could
158 be directly at the API level or indirectly such as changes to a cache layer.
159
160* Can this change enable a resource exhaustion attack, such as allowing a
161 single API interaction to consume significant server resources? Some examples
162 of this include launching subprocesses for each connection, or entity
163 expansion attacks in XML.
164
165For more detailed guidance, please see the OpenStack Security Guidelines as
166a reference (https://wiki.openstack.org/wiki/Security/Guidelines). These
167guidelines are a work in progress and are designed to help you identify
168security best practices. For further information, feel free to reach out
169to the OpenStack Security Group at openstack-security@lists.openstack.org.
170
171Notifications impact
172--------------------
173
174Please specify any changes to notifications. Be that an extra notification,
175changes to an existing notification, or removing a notification.
176
177Other end user impact
178---------------------
179
180Aside from the API, are there other ways a user will interact with this
181feature?
182
183* Does this change have an impact on python-openstack-chefclient? What does the user
184 interface there look like?
185
186Performance Impact
187------------------
188
189Describe any potential performance impact on the system, for example
190how often will new code be called, and is there a major change to the calling
191pattern of existing code.
192
193Examples of things to consider here include:
194
195* A periodic task might look like a small addition but if it calls conductor or
196 another service the load is multiplied by the number of nodes in the system.
197
198* Scheduler filters get called once per host for every instance being created,
199 so any latency they introduce is linear with the size of the system.
200
201* A small change in a utility function or a commonly used decorator can have a
202 large impacts on performance.
203
204* Calls which result in a database queries (whether direct or via conductor)
205 can have a profound impact on performance when called in critical sections of
206 the code.
207
208* Will the change include any locking, and if so what considerations are there
209 on holding the lock?
210
211Other deployer impact
212---------------------
213
214Discuss things that will affect how you deploy and configure OpenStack
215that have not already been mentioned, such as:
216
217* What config options are being added? Should they be more generic than
218 proposed (for example a flag that other hypervisor drivers might want to
219 implement as well)? Are the default values ones which will work well in
220 real deployments?
221
222* Is this a change that takes immediate effect after its merged, or is it
223 something that has to be explicitly enabled?
224
225* If this change is a new binary, how would it be deployed?
226
227* Please state anything that those doing continuous deployment, or those
228 upgrading from the previous release, need to be aware of. Also describe
229 any plans to deprecate configuration values or features. For example, if we
230 change the directory name that instances are stored in, how do we handle
231 instance directories created before the change landed? Do we move them? Do
232 we have a special case in the code? Do we assume that the operator will
233 recreate all the instances in their cloud?
234
235Developer impact
236----------------
237
238Discuss things that will affect other developers working on OpenStack,
239such as:
240
241* If the blueprint proposes a change to the driver API, discussion of how
242 other hypervisors would implement the feature is required.
243
244
245Implementation
246==============
247
248Assignee(s)
249-----------
250
251Who is leading the writing of the code? Or is this a blueprint where you're
252throwing it out there to see who picks it up?
253
254If more than one person is working on the implementation, please designate the
255primary author and contact.
256
257Primary assignee:
258 <launchpad-id or None>
259
260Other contributors:
261 <launchpad-id or None>
262
263Work Items
264----------
265
266Work items or tasks -- break the feature up into the things that need to be
267done to implement it. Those parts might end up being done by different people,
268but we're mostly trying to understand the timeline for implementation.
269
270
271Dependencies
272============
273
274* Include specific references to specs and/or blueprints in openstack-chef, or in other
275 projects, that this one either depends on or is related to.
276
277* If this requires functionality of another project that is not currently used
278 by openstack-chef (such as the glance v2 API when we previously only required v1),
279 document that fact.
280
281* Does this feature require any new library dependencies or code otherwise not
282 included in OpenStack? Or does it depend on a specific version of library?
283
284
285Testing
286=======
287
288Please discuss how the change will be tested. We especially want to know what
289tempest tests will be added. It is assumed that unit test coverage will be
290added so that doesn't need to be mentioned explicitly, but discussion of why
291you think unit tests are sufficient and we don't need to add more tempest
292tests would need to be included.
293
294Is this untestable in gate given current limitations (specific hardware /
295software configurations available)? If so, are there mitigation plans (3rd
296party testing, gate enhancements, etc).
297
298
299Documentation Impact
300====================
301
302What is the impact on the docs team of this change? Some changes might require
303donating resources to the docs team to have the documentation updated. Don't
304repeat details discussed above, but please reference them here.
305
306
307References
308==========
309
310Please add any useful references here. You are not required to have any
311reference. Moreover, this specification should still make sense when your
312references are unavailable. Examples of what you could include are:
313
314* Links to mailing list or IRC discussions
315
316* Links to notes from a summit session
317
318* Links to relevant research, if appropriate
319
320* Related specifications as appropriate (e.g. if it's an EC2 thing, link the
321 EC2 docs)
322
323* Anything else you feel it is worthwhile to refer to
diff --git a/specs/juno/.gitignore b/specs/juno/.gitignore
new file mode 100644
index 0000000..e69de29
--- /dev/null
+++ b/specs/juno/.gitignore
diff --git a/specs/juno/block-storage/.gitignore b/specs/juno/block-storage/.gitignore
new file mode 100644
index 0000000..e69de29
--- /dev/null
+++ b/specs/juno/block-storage/.gitignore
diff --git a/specs/juno/ceph/.gitignore b/specs/juno/ceph/.gitignore
new file mode 100644
index 0000000..e69de29
--- /dev/null
+++ b/specs/juno/ceph/.gitignore
diff --git a/specs/juno/client/.gitignore b/specs/juno/client/.gitignore
new file mode 100644
index 0000000..e69de29
--- /dev/null
+++ b/specs/juno/client/.gitignore
diff --git a/specs/juno/common/.gitignore b/specs/juno/common/.gitignore
new file mode 100644
index 0000000..e69de29
--- /dev/null
+++ b/specs/juno/common/.gitignore
diff --git a/specs/juno/compute/.gitignore b/specs/juno/compute/.gitignore
new file mode 100644
index 0000000..e69de29
--- /dev/null
+++ b/specs/juno/compute/.gitignore
diff --git a/specs/juno/cookbook-openstack-integration-test/.gitignore b/specs/juno/cookbook-openstack-integration-test/.gitignore
new file mode 100644
index 0000000..e69de29
--- /dev/null
+++ b/specs/juno/cookbook-openstack-integration-test/.gitignore
diff --git a/specs/juno/dashboard/.gitignore b/specs/juno/dashboard/.gitignore
new file mode 100644
index 0000000..e69de29
--- /dev/null
+++ b/specs/juno/dashboard/.gitignore
diff --git a/specs/juno/data-processing/.gitignore b/specs/juno/data-processing/.gitignore
new file mode 100644
index 0000000..e69de29
--- /dev/null
+++ b/specs/juno/data-processing/.gitignore
diff --git a/specs/juno/database/.gitignore b/specs/juno/database/.gitignore
new file mode 100644
index 0000000..e69de29
--- /dev/null
+++ b/specs/juno/database/.gitignore
diff --git a/specs/juno/identity/.gitignore b/specs/juno/identity/.gitignore
new file mode 100644
index 0000000..e69de29
--- /dev/null
+++ b/specs/juno/identity/.gitignore
diff --git a/specs/juno/image/.gitignore b/specs/juno/image/.gitignore
new file mode 100644
index 0000000..e69de29
--- /dev/null
+++ b/specs/juno/image/.gitignore
diff --git a/specs/juno/metering/.gitignore b/specs/juno/metering/.gitignore
new file mode 100644
index 0000000..e69de29
--- /dev/null
+++ b/specs/juno/metering/.gitignore
diff --git a/specs/juno/network/.gitignore b/specs/juno/network/.gitignore
new file mode 100644
index 0000000..e69de29
--- /dev/null
+++ b/specs/juno/network/.gitignore
diff --git a/specs/juno/object-storage/.gitignore b/specs/juno/object-storage/.gitignore
new file mode 100644
index 0000000..e69de29
--- /dev/null
+++ b/specs/juno/object-storage/.gitignore
diff --git a/specs/juno/openstack-manuals/.gitignore b/specs/juno/openstack-manuals/.gitignore
new file mode 100644
index 0000000..e69de29
--- /dev/null
+++ b/specs/juno/openstack-manuals/.gitignore
diff --git a/specs/juno/orchestration/.gitignore b/specs/juno/orchestration/.gitignore
new file mode 100644
index 0000000..e69de29
--- /dev/null
+++ b/specs/juno/orchestration/.gitignore
diff --git a/specs/juno/template.rst b/specs/juno/template.rst
new file mode 100644
index 0000000..06cbf50
--- /dev/null
+++ b/specs/juno/template.rst
@@ -0,0 +1,323 @@
1..
2 This work is licensed under a Creative Commons Attribution 3.0 Unported
3 License.
4
5 http://creativecommons.org/licenses/by/3.0/legalcode
6
7==========================================
8Example Spec - The title of your blueprint
9==========================================
10
11Include the URL of your launchpad blueprint:
12
13https://blueprints.launchpad.net/openstack-chef/+spec/example
14
15Introduction paragraph -- why are we doing anything? A single paragraph of
16prose that operators can understand. The title and this first paragraph
17should be used as the subject line and body of the commit message
18respectively.
19
20Some notes about using this template:
21
22* Your spec should be in ReSTructured text, like this template.
23
24* Please wrap text at 79 columns.
25
26* The filename in the git repository should match the launchpad URL, for
27 example a URL of: https://blueprints.launchpad.net/openstack-chef/+spec/awesome-thing
28 should be named awesome-thing.rst
29
30* Please do not delete any of the sections in this template. If you have
31 nothing to say for a whole section, just write: None
32
33* For help with syntax, see http://sphinx-doc.org/rest.html
34
35* To test out your formatting, build the docs using tox and see the generated
36 HTML file in doc/build/html/specs/<path_of_your_file>
37
38* If you would like to provide a diagram with your spec, ascii diagrams are
39 required. http://asciiflow.com/ is a very nice tool to assist with making
40 ascii diagrams. The reason for this is that the tool used to review specs is
41 based purely on plain text. Plain text will allow review to proceed without
42 having to look at additional files which can not be viewed in gerrit. It
43 will also allow inline feedback on the diagram itself.
44
45Problem description
46===================
47
48A detailed description of the problem:
49
50* For a new feature this might be use cases. Ensure you are clear about the
51 actors in each use case: End User vs Deployer
52
53* For a major reworking of something existing it would describe the
54 problems in that feature that are being addressed.
55
56
57Proposed change
58===============
59
60Here is where you cover the change you propose to make in detail. How do you
61propose to solve this problem?
62
63If this is one part of a larger effort make it clear where this piece ends. In
64other words, what's the scope of this effort?
65
66Alternatives
67------------
68
69What other ways could we do this thing? Why aren't we using those? This doesn't
70have to be a full literature review, but it should demonstrate that thought has
71been put into why the proposed solution is an appropriate one.
72
73Data model impact
74-----------------
75
76Changes which require modifications to the data model often have a wider impact
77on the system. The community often has strong opinions on how the data model
78should be evolved, from both a functional and performance perspective. It is
79therefore important to capture and gain agreement as early as possible on any
80proposed changes to the data model.
81
82Questions which need to be addressed by this section include:
83
84* What new data objects and/or database schema changes is this going to
85 require?
86
87* What database migrations will accompany this change.
88
89* How will the initial set of new data objects be generated, for example if you
90 need to take into account existing instances, or modify other existing data
91 describe how that will work.
92
93REST API impact
94---------------
95
96Each API method which is either added or changed should have the following
97
98* Specification for the method
99
100 * A description of what the method does suitable for use in
101 user documentation
102
103 * Method type (POST/PUT/GET/DELETE)
104
105 * Normal http response code(s)
106
107 * Expected error http response code(s)
108
109 * A description for each possible error code should be included
110 describing semantic errors which can cause it such as
111 inconsistent parameters supplied to the method, or when an
112 instance is not in an appropriate state for the request to
113 succeed. Errors caused by syntactic problems covered by the JSON
114 schema defintion do not need to be included.
115
116 * URL for the resource
117
118 * Parameters which can be passed via the url
119
120 * JSON schema definition for the body data if allowed
121
122 * JSON schema definition for the response data if any
123
124* Example use case including typical API samples for both data supplied
125 by the caller and the response
126
127* Discuss any policy changes, and discuss what things a deployer needs to
128 think about when defining their policy.
129
130Example JSON schema definitions can be found in the openstack-chef tree
131http://git.openstack.org/cgit/openstack/openstack-chef/tree/openstack-chef/api/openstack/compute/schemas/v3
132
133Note that the schema should be defined as restrictively as
134possible. Parameters which are required should be marked as such and
135only under exceptional circumstances should additional parameters
136which are not defined in the schema be permitted (eg
137additionaProperties should be False).
138
139Reuse of existing predefined parameter types such as regexps for
140passwords and user defined names is highly encouraged.
141
142Security impact
143---------------
144
145Describe any potential security impact on the system. Some of the items to
146consider include:
147
148* Does this change touch sensitive data such as tokens, keys, or user data?
149
150* Does this change alter the API in a way that may impact security, such as
151 a new way to access sensitive information or a new way to login?
152
153* Does this change involve cryptography or hashing?
154
155* Does this change require the use of sudo or any elevated privileges?
156
157* Does this change involve using or parsing user-provided data? This could
158 be directly at the API level or indirectly such as changes to a cache layer.
159
160* Can this change enable a resource exhaustion attack, such as allowing a
161 single API interaction to consume significant server resources? Some examples
162 of this include launching subprocesses for each connection, or entity
163 expansion attacks in XML.
164
165For more detailed guidance, please see the OpenStack Security Guidelines as
166a reference (https://wiki.openstack.org/wiki/Security/Guidelines). These
167guidelines are a work in progress and are designed to help you identify
168security best practices. For further information, feel free to reach out
169to the OpenStack Security Group at openstack-security@lists.openstack.org.
170
171Notifications impact
172--------------------
173
174Please specify any changes to notifications. Be that an extra notification,
175changes to an existing notification, or removing a notification.
176
177Other end user impact
178---------------------
179
180Aside from the API, are there other ways a user will interact with this
181feature?
182
183* Does this change have an impact on python-openstack-chefclient? What does the user
184 interface there look like?
185
186Performance Impact
187------------------
188
189Describe any potential performance impact on the system, for example
190how often will new code be called, and is there a major change to the calling
191pattern of existing code.
192
193Examples of things to consider here include:
194
195* A periodic task might look like a small addition but if it calls conductor or
196 another service the load is multiplied by the number of nodes in the system.
197
198* Scheduler filters get called once per host for every instance being created,
199 so any latency they introduce is linear with the size of the system.
200
201* A small change in a utility function or a commonly used decorator can have a
202 large impacts on performance.
203
204* Calls which result in a database queries (whether direct or via conductor)
205 can have a profound impact on performance when called in critical sections of
206 the code.
207
208* Will the change include any locking, and if so what considerations are there
209 on holding the lock?
210
211Other deployer impact
212---------------------
213
214Discuss things that will affect how you deploy and configure OpenStack
215that have not already been mentioned, such as:
216
217* What config options are being added? Should they be more generic than
218 proposed (for example a flag that other hypervisor drivers might want to
219 implement as well)? Are the default values ones which will work well in
220 real deployments?
221
222* Is this a change that takes immediate effect after its merged, or is it
223 something that has to be explicitly enabled?
224
225* If this change is a new binary, how would it be deployed?
226
227* Please state anything that those doing continuous deployment, or those
228 upgrading from the previous release, need to be aware of. Also describe
229 any plans to deprecate configuration values or features. For example, if we
230 change the directory name that instances are stored in, how do we handle
231 instance directories created before the change landed? Do we move them? Do
232 we have a special case in the code? Do we assume that the operator will
233 recreate all the instances in their cloud?
234
235Developer impact
236----------------
237
238Discuss things that will affect other developers working on OpenStack,
239such as:
240
241* If the blueprint proposes a change to the driver API, discussion of how
242 other hypervisors would implement the feature is required.
243
244
245Implementation
246==============
247
248Assignee(s)
249-----------
250
251Who is leading the writing of the code? Or is this a blueprint where you're
252throwing it out there to see who picks it up?
253
254If more than one person is working on the implementation, please designate the
255primary author and contact.
256
257Primary assignee:
258 <launchpad-id or None>
259
260Other contributors:
261 <launchpad-id or None>
262
263Work Items
264----------
265
266Work items or tasks -- break the feature up into the things that need to be
267done to implement it. Those parts might end up being done by different people,
268but we're mostly trying to understand the timeline for implementation.
269
270
271Dependencies
272============
273
274* Include specific references to specs and/or blueprints in openstack-chef, or in other
275 projects, that this one either depends on or is related to.
276
277* If this requires functionality of another project that is not currently used
278 by openstack-chef (such as the glance v2 API when we previously only required v1),
279 document that fact.
280
281* Does this feature require any new library dependencies or code otherwise not
282 included in OpenStack? Or does it depend on a specific version of library?
283
284
285Testing
286=======
287
288Please discuss how the change will be tested. We especially want to know what
289tempest tests will be added. It is assumed that unit test coverage will be
290added so that doesn't need to be mentioned explicitly, but discussion of why
291you think unit tests are sufficient and we don't need to add more tempest
292tests would need to be included.
293
294Is this untestable in gate given current limitations (specific hardware /
295software configurations available)? If so, are there mitigation plans (3rd
296party testing, gate enhancements, etc).
297
298
299Documentation Impact
300====================
301
302What is the impact on the docs team of this change? Some changes might require
303donating resources to the docs team to have the documentation updated. Don't
304repeat details discussed above, but please reference them here.
305
306
307References
308==========
309
310Please add any useful references here. You are not required to have any
311reference. Moreover, this specification should still make sense when your
312references are unavailable. Examples of what you could include are:
313
314* Links to mailing list or IRC discussions
315
316* Links to notes from a summit session
317
318* Links to relevant research, if appropriate
319
320* Related specifications as appropriate (e.g. if it's an EC2 thing, link the
321 EC2 docs)
322
323* Anything else you feel it is worthwhile to refer to
diff --git a/specs/template.rst b/specs/template.rst
new file mode 100644
index 0000000..06cbf50
--- /dev/null
+++ b/specs/template.rst
@@ -0,0 +1,323 @@
1..
2 This work is licensed under a Creative Commons Attribution 3.0 Unported
3 License.
4
5 http://creativecommons.org/licenses/by/3.0/legalcode
6
7==========================================
8Example Spec - The title of your blueprint
9==========================================
10
11Include the URL of your launchpad blueprint:
12
13https://blueprints.launchpad.net/openstack-chef/+spec/example
14
15Introduction paragraph -- why are we doing anything? A single paragraph of
16prose that operators can understand. The title and this first paragraph
17should be used as the subject line and body of the commit message
18respectively.
19
20Some notes about using this template:
21
22* Your spec should be in ReSTructured text, like this template.
23
24* Please wrap text at 79 columns.
25
26* The filename in the git repository should match the launchpad URL, for
27 example a URL of: https://blueprints.launchpad.net/openstack-chef/+spec/awesome-thing
28 should be named awesome-thing.rst
29
30* Please do not delete any of the sections in this template. If you have
31 nothing to say for a whole section, just write: None
32
33* For help with syntax, see http://sphinx-doc.org/rest.html
34
35* To test out your formatting, build the docs using tox and see the generated
36 HTML file in doc/build/html/specs/<path_of_your_file>
37
38* If you would like to provide a diagram with your spec, ascii diagrams are
39 required. http://asciiflow.com/ is a very nice tool to assist with making
40 ascii diagrams. The reason for this is that the tool used to review specs is
41 based purely on plain text. Plain text will allow review to proceed without
42 having to look at additional files which can not be viewed in gerrit. It
43 will also allow inline feedback on the diagram itself.
44
45Problem description
46===================
47
48A detailed description of the problem:
49
50* For a new feature this might be use cases. Ensure you are clear about the
51 actors in each use case: End User vs Deployer
52
53* For a major reworking of something existing it would describe the
54 problems in that feature that are being addressed.
55
56
57Proposed change
58===============
59
60Here is where you cover the change you propose to make in detail. How do you
61propose to solve this problem?
62
63If this is one part of a larger effort make it clear where this piece ends. In
64other words, what's the scope of this effort?
65
66Alternatives
67------------
68
69What other ways could we do this thing? Why aren't we using those? This doesn't
70have to be a full literature review, but it should demonstrate that thought has
71been put into why the proposed solution is an appropriate one.
72
73Data model impact
74-----------------
75
76Changes which require modifications to the data model often have a wider impact
77on the system. The community often has strong opinions on how the data model
78should be evolved, from both a functional and performance perspective. It is
79therefore important to capture and gain agreement as early as possible on any
80proposed changes to the data model.
81
82Questions which need to be addressed by this section include:
83
84* What new data objects and/or database schema changes is this going to
85 require?
86
87* What database migrations will accompany this change.
88
89* How will the initial set of new data objects be generated, for example if you
90 need to take into account existing instances, or modify other existing data
91 describe how that will work.
92
93REST API impact
94---------------
95
96Each API method which is either added or changed should have the following
97
98* Specification for the method
99
100 * A description of what the method does suitable for use in
101 user documentation
102
103 * Method type (POST/PUT/GET/DELETE)
104
105 * Normal http response code(s)
106
107 * Expected error http response code(s)
108
109 * A description for each possible error code should be included
110 describing semantic errors which can cause it such as
111 inconsistent parameters supplied to the method, or when an
112 instance is not in an appropriate state for the request to
113 succeed. Errors caused by syntactic problems covered by the JSON
114 schema defintion do not need to be included.
115
116 * URL for the resource
117
118 * Parameters which can be passed via the url
119
120 * JSON schema definition for the body data if allowed
121
122 * JSON schema definition for the response data if any
123
124* Example use case including typical API samples for both data supplied
125 by the caller and the response
126
127* Discuss any policy changes, and discuss what things a deployer needs to
128 think about when defining their policy.
129
130Example JSON schema definitions can be found in the openstack-chef tree
131http://git.openstack.org/cgit/openstack/openstack-chef/tree/openstack-chef/api/openstack/compute/schemas/v3
132
133Note that the schema should be defined as restrictively as
134possible. Parameters which are required should be marked as such and
135only under exceptional circumstances should additional parameters
136which are not defined in the schema be permitted (eg
137additionaProperties should be False).
138
139Reuse of existing predefined parameter types such as regexps for
140passwords and user defined names is highly encouraged.
141
142Security impact
143---------------
144
145Describe any potential security impact on the system. Some of the items to
146consider include:
147
148* Does this change touch sensitive data such as tokens, keys, or user data?
149
150* Does this change alter the API in a way that may impact security, such as
151 a new way to access sensitive information or a new way to login?
152
153* Does this change involve cryptography or hashing?
154
155* Does this change require the use of sudo or any elevated privileges?
156
157* Does this change involve using or parsing user-provided data? This could
158 be directly at the API level or indirectly such as changes to a cache layer.
159
160* Can this change enable a resource exhaustion attack, such as allowing a
161 single API interaction to consume significant server resources? Some examples
162 of this include launching subprocesses for each connection, or entity
163 expansion attacks in XML.
164
165For more detailed guidance, please see the OpenStack Security Guidelines as
166a reference (https://wiki.openstack.org/wiki/Security/Guidelines). These
167guidelines are a work in progress and are designed to help you identify
168security best practices. For further information, feel free to reach out
169to the OpenStack Security Group at openstack-security@lists.openstack.org.
170
171Notifications impact
172--------------------
173
174Please specify any changes to notifications. Be that an extra notification,
175changes to an existing notification, or removing a notification.
176
177Other end user impact
178---------------------
179
180Aside from the API, are there other ways a user will interact with this
181feature?
182
183* Does this change have an impact on python-openstack-chefclient? What does the user
184 interface there look like?
185
186Performance Impact
187------------------
188
189Describe any potential performance impact on the system, for example
190how often will new code be called, and is there a major change to the calling
191pattern of existing code.
192
193Examples of things to consider here include:
194
195* A periodic task might look like a small addition but if it calls conductor or
196 another service the load is multiplied by the number of nodes in the system.
197
198* Scheduler filters get called once per host for every instance being created,
199 so any latency they introduce is linear with the size of the system.
200
201* A small change in a utility function or a commonly used decorator can have a
202 large impacts on performance.
203
204* Calls which result in a database queries (whether direct or via conductor)
205 can have a profound impact on performance when called in critical sections of
206 the code.
207
208* Will the change include any locking, and if so what considerations are there
209 on holding the lock?
210
211Other deployer impact
212---------------------
213
214Discuss things that will affect how you deploy and configure OpenStack
215that have not already been mentioned, such as:
216
217* What config options are being added? Should they be more generic than
218 proposed (for example a flag that other hypervisor drivers might want to
219 implement as well)? Are the default values ones which will work well in
220 real deployments?
221
222* Is this a change that takes immediate effect after its merged, or is it
223 something that has to be explicitly enabled?
224
225* If this change is a new binary, how would it be deployed?
226
227* Please state anything that those doing continuous deployment, or those
228 upgrading from the previous release, need to be aware of. Also describe
229 any plans to deprecate configuration values or features. For example, if we
230 change the directory name that instances are stored in, how do we handle
231 instance directories created before the change landed? Do we move them? Do
232 we have a special case in the code? Do we assume that the operator will
233 recreate all the instances in their cloud?
234
235Developer impact
236----------------
237
238Discuss things that will affect other developers working on OpenStack,
239such as:
240
241* If the blueprint proposes a change to the driver API, discussion of how
242 other hypervisors would implement the feature is required.
243
244
245Implementation
246==============
247
248Assignee(s)
249-----------
250
251Who is leading the writing of the code? Or is this a blueprint where you're
252throwing it out there to see who picks it up?
253
254If more than one person is working on the implementation, please designate the
255primary author and contact.
256
257Primary assignee:
258 <launchpad-id or None>
259
260Other contributors:
261 <launchpad-id or None>
262
263Work Items
264----------
265
266Work items or tasks -- break the feature up into the things that need to be
267done to implement it. Those parts might end up being done by different people,
268but we're mostly trying to understand the timeline for implementation.
269
270
271Dependencies
272============
273
274* Include specific references to specs and/or blueprints in openstack-chef, or in other
275 projects, that this one either depends on or is related to.
276
277* If this requires functionality of another project that is not currently used
278 by openstack-chef (such as the glance v2 API when we previously only required v1),
279 document that fact.
280
281* Does this feature require any new library dependencies or code otherwise not
282 included in OpenStack? Or does it depend on a specific version of library?
283
284
285Testing
286=======
287
288Please discuss how the change will be tested. We especially want to know what
289tempest tests will be added. It is assumed that unit test coverage will be
290added so that doesn't need to be mentioned explicitly, but discussion of why
291you think unit tests are sufficient and we don't need to add more tempest
292tests would need to be included.
293
294Is this untestable in gate given current limitations (specific hardware /
295software configurations available)? If so, are there mitigation plans (3rd
296party testing, gate enhancements, etc).
297
298
299Documentation Impact
300====================
301
302What is the impact on the docs team of this change? Some changes might require
303donating resources to the docs team to have the documentation updated. Don't
304repeat details discussed above, but please reference them here.
305
306
307References
308==========
309
310Please add any useful references here. You are not required to have any
311reference. Moreover, this specification should still make sense when your
312references are unavailable. Examples of what you could include are:
313
314* Links to mailing list or IRC discussions
315
316* Links to notes from a summit session
317
318* Links to relevant research, if appropriate
319
320* Related specifications as appropriate (e.g. if it's an EC2 thing, link the
321 EC2 docs)
322
323* Anything else you feel it is worthwhile to refer to
diff --git a/tox.ini b/tox.ini
new file mode 100644
index 0000000..50fe956
--- /dev/null
+++ b/tox.ini
@@ -0,0 +1,15 @@
1[tox]
2envlist = docs
3
4[testenv]
5usedevelop = True
6setenv = VIRTUAL_ENV={envdir}
7install_command = pip install -U {opts} {packages}
8deps = -r{toxinidir}/requirements.txt
9commands = python setup.py testr --slowest --testr-args='{posargs}'
10
11[testenv:venv]
12commands = {posargs}
13
14[testenv:docs]
15commands = python setup.py build_sphinx