summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorMike Fedosin <mfedosin@mirantis.com>2016-10-10 19:37:46 +0300
committerMike Fedosin <mfedosin@mirantis.com>2016-10-10 19:58:31 +0300
commit04ddf7a26fbeb18356733c2a8d2b6ac3d2cd2ba6 (patch)
tree6f9402f7945a474dc9abc9fac62a0ad52e0560a7
parent57f8e34c8dc443c0670aeacfc6a0518c0e737c12 (diff)
Initial commitHEADmaster
Notes
Notes (review): Code-Review+2: Darja Shakhray <damalyavkina@gmail.com> Code-Review+2: Mike Fedosin <mfedosin@gmail.com> Workflow+1: Mike Fedosin <mfedosin@gmail.com> Verified+2: Jenkins Submitted-by: Jenkins Submitted-at: Sun, 23 Oct 2016 21:05:28 +0000 Reviewed-on: https://review.openstack.org/382028 Project: openstack/glare-specs Branch: refs/heads/master
-rw-r--r--.gitignore10
-rw-r--r--.testr.conf7
-rw-r--r--LICENSE3
-rw-r--r--README.rst57
-rw-r--r--doc/source/conf.py276
-rw-r--r--doc/source/index.rst19
-rw-r--r--doc/source/redirect.py52
l---------doc/source/specs1
-rw-r--r--requirements.txt9
-rw-r--r--setup.cfg23
-rwxr-xr-xsetup.py22
-rw-r--r--specs/ocata/approved/lite-specs.rst47
l---------specs/ocata/template.rst1
-rw-r--r--specs/template.rst337
-rw-r--r--tests/__init__.py0
-rw-r--r--tests/test_titles.py110
-rw-r--r--tox.ini25
17 files changed, 999 insertions, 0 deletions
diff --git a/.gitignore b/.gitignore
new file mode 100644
index 0000000..6efcb00
--- /dev/null
+++ b/.gitignore
@@ -0,0 +1,10 @@
1AUTHORS
2ChangeLog
3build
4.tox
5.venv
6*.egg*
7*.swp
8*.swo
9*.pyc
10.testrepository
diff --git a/.testr.conf b/.testr.conf
new file mode 100644
index 0000000..62d9081
--- /dev/null
+++ b/.testr.conf
@@ -0,0 +1,7 @@
1[DEFAULT]
2test_command=OS_STDOUT_CAPTURE=${OS_STDOUT_CAPTURE:-1} \
3 OS_STDERR_CAPTURE=${OS_STDERR_CAPTURE:-1} \
4 OS_TEST_TIMEOUT=${OS_TEST_TIMEOUT:-60} \
5 ${PYTHON:-python} -m subunit.run discover tests $LISTOPT $IDOPTION
6test_id_option=--load-list $IDFILE
7test_list_option=--list
diff --git a/LICENSE b/LICENSE
new file mode 100644
index 0000000..75a29c4
--- /dev/null
+++ b/LICENSE
@@ -0,0 +1,3 @@
1This work is licensed under a Creative Commons Attribution 3.0 Unported License.
2
3http://creativecommons.org/licenses/by/3.0/legalcode
diff --git a/README.rst b/README.rst
new file mode 100644
index 0000000..0e74d87
--- /dev/null
+++ b/README.rst
@@ -0,0 +1,57 @@
1==============================
2OpenStack Glare Specifications
3==============================
4
5This git repository is used to hold approved design specifications for additions
6to the Glare 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>/
12
13Where there are two sub-directories:
14
15 specs/<release>/approved: specifications approved but not yet implemented
16 specs/<release>/implemented: implemented specifications
17
18This directory structure allows you to see what we thought about doing,
19decided to do, and actually got done. Users interested in functionality in a
20given release should only refer to the ``implemented`` directory.
21
22You can find an example spec in `doc/source/specs/template.rst`.
23
24Specifications are proposed for a given release by adding them to the
25`specs/<release>` directory and posting it for review. The implementation
26status of a blueprint for a given release can be found by looking at the
27blueprint in launchpad. Not all approved blueprints will get fully implemented.
28
29Specifications have to be re-proposed for every release. The review may be
30quick, but even if something was previously approved, it should be re-reviewed
31to make sure it still makes sense as written.
32
33Prior to the Kilo development cycle this repository was not used for
34spec reviews. Reviews prior to Juno were completed entirely through
35Launchpad blueprints::
36
37 http://blueprints.launchpad.net/glare
38
39Starting from the Kilo-1 developement milestone Glare performs the pilot of
40the specs repos approach.
41
42Please note, Launchpad blueprints are still used for tracking the
43current status of blueprints. For more information, see::
44
45 https://wiki.openstack.org/wiki/Blueprints
46
47For more information about working with gerrit, see::
48
49 http://docs.openstack.org/infra/manual/developers.html#development-workflow
50
51To validate that the specification is syntactically correct (i.e. get more
52confidence in the Jenkins result), please execute the following command::
53
54 $ tox
55
56After running ``tox``, the documentation will be available for viewing in HTML
57format in the ``doc/build/`` directory.
diff --git a/doc/source/conf.py b/doc/source/conf.py
new file mode 100644
index 0000000..d8caebe
--- /dev/null
+++ b/doc/source/conf.py
@@ -0,0 +1,276 @@
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 datetime
15import subprocess
16import sys
17import os
18
19# If extensions (or modules to document with autodoc) are in another directory,
20# add these directories to sys.path here. If the directory is relative to the
21# documentation root, use os.path.abspath to make it absolute, like shown here.
22sys.path.insert(0, os.path.abspath('.'))
23on_rtd = os.environ.get('READTHEDOCS', None) == 'True'
24
25# -- General configuration -----------------------------------------------------
26
27# If your documentation needs a minimal Sphinx version, state it here.
28#needs_sphinx = '1.0'
29
30# Add any Sphinx extension module names here, as strings. They can be extensions
31# coming with Sphinx (named 'sphinx.ext.*') or your custom ones.
32extensions = ['redirect',
33 'sphinx.ext.autodoc',
34 'sphinx.ext.todo',
35 'sphinx.ext.viewcode',
36 'yasfb',
37 ]
38
39# Feed configuration for yasfb
40feed_base_url = 'http://glare-specs.readthedocs.org'
41feed_author = 'OpenStack Glare Team'
42
43todo_include_todos = True
44
45# Add any paths that contain templates here, relative to this directory.
46templates_path = ['_templates']
47
48# The suffix of source filenames.
49source_suffix = '.rst'
50
51# The encoding of source files.
52#source_encoding = 'utf-8-sig'
53
54# The master toctree document.
55master_doc = 'index'
56
57# General information about the project.
58project = u'Glare Specs'
59copyright = u'%s, OpenStack Glare Team' % datetime.date.today().year
60
61# The language for content autogenerated by Sphinx. Refer to documentation
62# for a list of supported languages.
63#language = None
64
65# There are two options for replacing |today|: either, you set today to some
66# non-false value, then it is used:
67#today = ''
68# Else, today_fmt is used as the format for a strftime call.
69#today_fmt = '%B %d, %Y'
70
71# List of patterns, relative to source directory, that match files and
72# directories to ignore when looking for source files.
73exclude_patterns = [
74 '_build',
75 '**/template.rst',
76]
77
78# The reST default role (used for this markup: `text`) to use for all documents.
79#default_role = None
80
81# If true, '()' will be appended to :func: etc. cross-reference text.
82#add_function_parentheses = True
83
84# If true, the current module name will be prepended to all description
85# unit titles (such as .. function::).
86add_module_names = False
87
88# If true, sectionauthor and moduleauthor directives will be shown in the
89# output. They are ignored by default.
90show_authors = False
91
92# The name of the Pygments (syntax highlighting) style to use.
93pygments_style = 'sphinx'
94
95# A list of ignored prefixes for module index sorting.
96modindex_common_prefix = ['glare-specs.']
97
98# -- Options for man page output ----------------------------------------------
99man_pages = []
100
101# -- Options for HTML output ---------------------------------------------------
102
103# Theme options are theme-specific and customize the look and feel of a theme
104# further. For a list of options available for each theme, see the
105# documentation.
106#html_theme_options = {}
107
108# Add any paths that contain custom themes here, relative to this directory.
109#html_theme_path = []
110
111# The name for this set of Sphinx documents. If None, it defaults to
112# "<project> v<release> documentation".
113#html_title = None
114
115# A shorter title for the navigation bar. Default is the same as html_title.
116#html_short_title = None
117
118# The name of an image file (relative to this directory) to place at the top
119# of the sidebar.
120#html_logo = None
121
122# The name of an image file (within the static path) to use as favicon of the
123# docs. This file should be a Windows icon file (.ico) being 16x16 or 32x32
124# pixels large.
125#html_favicon = None
126
127# If not '', a 'Last updated on:' timestamp is inserted at every page bottom,
128# using the given strftime format.
129git_cmd = ["git", "log", "--pretty=format:'%ad, commit %h'", "--date=local",
130 "-n1"]
131html_last_updated_fmt = subprocess.Popen(
132 git_cmd, stdout=subprocess.PIPE).communicate()[0]
133
134# If true, SmartyPants will be used to convert quotes and dashes to
135# typographically correct entities.
136#html_use_smartypants = True
137
138# Custom sidebar templates, maps document names to template names.
139#html_sidebars = {}
140
141# Additional templates that should be rendered to pages, maps page names to
142# template names.
143#html_additional_pages = {}
144
145# If false, no module index is generated.
146html_domain_indices = False
147
148# If false, no index is generated.
149html_use_index = False
150
151# If true, the index is split into individual pages for each letter.
152#html_split_index = False
153
154# If true, links to the reST sources are added to the pages.
155#html_show_sourcelink = True
156
157# If true, "Created using Sphinx" is shown in the HTML footer. Default is True.
158#html_show_sphinx = True
159
160# If true, "(C) Copyright ..." is shown in the HTML footer. Default is True.
161#html_show_copyright = True
162
163# If true, an OpenSearch description file will be output, and all pages will
164# contain a <link> tag referring to it. The value of this option must be the
165# base URL from which the finished HTML is served.
166#html_use_opensearch = ''
167
168# This is the file name suffix for HTML files (e.g. ".xhtml").
169#html_file_suffix = None
170
171# Output file base name for HTML help builder.
172htmlhelp_basename = 'Glare-Specsdoc'
173
174
175# -- Options for LaTeX output --------------------------------------------------
176
177latex_elements = {
178# The paper size ('letterpaper' or 'a4paper').
179#'papersize': 'letterpaper',
180
181# The font size ('10pt', '11pt' or '12pt').
182#'pointsize': '10pt',
183
184# Additional stuff for the LaTeX preamble.
185#'preamble': '',
186}
187
188# Grouping the document tree into LaTeX files. List of tuples
189# (source start file, target name, title, author, documentclass [howto/manual]).
190latex_documents = [
191 ('index', 'Glare-specs.tex', u'Glare Specs',
192 u'OpenStack Glare Team', 'manual'),
193]
194
195# The name of an image file (relative to this directory) to place at the top of
196# the title page.
197#latex_logo = None
198
199# For "manual" documents, if this is true, then toplevel headings are parts,
200# not chapters.
201#latex_use_parts = False
202
203# If true, show page references after internal links.
204#latex_show_pagerefs = False
205
206# If true, show URL addresses after external links.
207#latex_show_urls = False
208
209# Documents to append as an appendix to all manuals.
210#latex_appendices = []
211
212# If false, no module index is generated.
213#latex_domain_indices = True
214
215# -- Options for Texinfo output ------------------------------------------------
216
217# Grouping the document tree into Texinfo files. List of tuples
218# (source start file, target name, title, author,
219# dir menu entry, description, category)
220texinfo_documents = [
221 ('index', 'Glare-specs', u'Glare Design Specs',
222 u'OpenStack Glare Team', 'glare-specs', 'Design specifications for the Glare project.',
223 'Miscellaneous'),
224]
225
226# Documents to append as an appendix to all manuals.
227#texinfo_appendices = []
228
229# If false, no module index is generated.
230#texinfo_domain_indices = True
231
232# How to display URL addresses: 'footnote', 'no', or 'inline'.
233#texinfo_show_urls = 'footnote'
234
235
236# -- Options for Epub output ---------------------------------------------------
237
238# Bibliographic Dublin Core info.
239epub_title = u'Glare Specs'
240epub_author = u'OpenStack Glare Team'
241epub_publisher = u'OpenStack Glare Team'
242epub_copyright = u'2014, OpenStack Glare Team'
243
244# The language of the text. It defaults to the language option
245# or en if the language is not set.
246#epub_language = ''
247
248# The scheme of the identifier. Typical schemes are ISBN or URL.
249#epub_scheme = ''
250
251# The unique identifier of the text. This can be a ISBN number
252# or the project homepage.
253#epub_identifier = ''
254
255# A unique identification for the text.
256#epub_uid = ''
257
258# A tuple containing the cover image and cover page html template filenames.
259#epub_cover = ()
260
261# HTML files that should be inserted before the pages created by sphinx.
262# The format is a list of tuples containing the path and title.
263#epub_pre_files = []
264
265# HTML files shat should be inserted after the pages created by sphinx.
266# The format is a list of tuples containing the path and title.
267#epub_post_files = []
268
269# A list of files that should not be packed into the epub file.
270#epub_exclude_files = []
271
272# The depth of the table of contents in toc.ncx.
273#epub_tocdepth = 3
274
275# Allow duplicate toc entries.
276#epub_tocdup = True
diff --git a/doc/source/index.rst b/doc/source/index.rst
new file mode 100644
index 0000000..ed47a76
--- /dev/null
+++ b/doc/source/index.rst
@@ -0,0 +1,19 @@
1.. glare-specs documentation master file
2
3====================
4Glare Specifications
5====================
6
7Ocata specs:
8
9.. toctree::
10 :glob:
11 :maxdepth: 1
12
13 specs/ocata/approved/*
14
15==================
16Indices and tables
17==================
18
19* :ref:`search`
diff --git a/doc/source/redirect.py b/doc/source/redirect.py
new file mode 100644
index 0000000..5f47428
--- /dev/null
+++ b/doc/source/redirect.py
@@ -0,0 +1,52 @@
1# A simple sphinx plugin which creates HTML redirections from old names
2# to new names. It does this by looking for files named "redirect" in
3# the documentation source and using the contents to create simple HTML
4# redirection pages for changed filenames.
5
6# Stolen from openstack/nova-specs
7
8import os.path
9
10from sphinx.application import ENV_PICKLE_FILENAME
11from sphinx.util.console import bold
12
13
14def setup(app):
15 from sphinx import application
16 if not isinstance(app, application.Sphinx):
17 return
18 app.connect('build-finished', emit_redirects)
19
20
21def process_redirect_file(app, path, ent):
22 parent_path = path.replace(app.builder.srcdir, app.builder.outdir)
23 with open(os.path.join(path, ent)) as redirects:
24 for line in redirects.readlines():
25 from_path, to_path = line.rstrip().split(' ')
26 from_path = from_path.replace('.rst', '.html')
27 to_path = to_path.replace('.rst', '.html')
28
29 redirected_filename = os.path.join(parent_path, from_path)
30 redirected_directory = os.path.dirname(redirected_filename)
31 if not os.path.exists(redirected_directory):
32 os.makedirs(redirected_directory)
33 with open(redirected_filename, 'w') as f:
34 f.write('<html><head><meta http-equiv="refresh" content="0; '
35 'url=%s" /></head></html>'
36 % to_path)
37
38
39def emit_redirects(app, exc):
40 app.builder.info(bold('scanning %s for redirects...') % app.builder.srcdir)
41
42 def process_directory(path):
43 for ent in os.listdir(path):
44 p = os.path.join(path, ent)
45 if os.path.isdir(p):
46 process_directory(p)
47 elif ent == 'redirects':
48 app.builder.info(' found redirects at %s' % p)
49 process_redirect_file(app, path, ent)
50
51 process_directory(app.builder.srcdir)
52 app.builder.info('...done')
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..0ad7340
--- /dev/null
+++ b/requirements.txt
@@ -0,0 +1,9 @@
1# The order of packages is significant, because pip processes them in the order
2# of appearance. Changing the order has an impact on the overall integration
3# process, which may cause wedges in the gate later.
4
5pbr>=0.6,!=0.7,<1.0
6sphinx>=1.1.2,!=1.2.0,!=1.3b1,<1.3
7testrepository>=0.0.18
8testtools>=0.9.34
9yasfb
diff --git a/setup.cfg b/setup.cfg
new file mode 100644
index 0000000..1f19366
--- /dev/null
+++ b/setup.cfg
@@ -0,0 +1,23 @@
1[metadata]
2name = glare-specs
3summary = OpenStack Glare 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 100755
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/ocata/approved/lite-specs.rst b/specs/ocata/approved/lite-specs.rst
new file mode 100644
index 0000000..6a04429
--- /dev/null
+++ b/specs/ocata/approved/lite-specs.rst
@@ -0,0 +1,47 @@
1:orphan:
2
3===============
4Glare Spec Lite
5===============
6
7Please keep this template section in place and add your own copy of it between
8the markers. Please fill only one Spec Lite per commit.
9
10<Title of your Spec Lite>
11-------------------------
12
13:problem: <What is the driver to make the change.>
14
15:solution: <High level description what needs to get done. For example: "We
16 need to add client function X.Y.Z to interact with new server
17 functionality Z".>
18
19:impacts: <All possible \*Impact flags (same as in commit messages) or 'None'.>
20
21Optionals (remove this line and fill or remove the rest until End of Template):
22+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
23
24:how: <More technical details than the high level overview of `solution` if
25 needed.>
26
27:alternatives: <Any alternative approaches that might be worth of bringing to
28 discussion.>
29
30:timeline: <Estimation of the time needed to complete the work.>
31
32:link: <Link to the change in gerrit that already would provide the `solution`.
33 After commiting the Spec Lite depend the change to the Spec Lite
34 commit.>
35
36:reviewers: <If reviewers has been agreed for the functionality, list them
37 here.>
38
39:assignee: <If known, list who is going to work on the feature implementation
40 here>
41
42End of Template
43+++++++++++++++
44
45
46Add your Spec Lite before this line
47===================================
diff --git a/specs/ocata/template.rst b/specs/ocata/template.rst
new file mode 120000
index 0000000..dc9373e
--- /dev/null
+++ b/specs/ocata/template.rst
@@ -0,0 +1 @@
../template.rst \ No newline at end of file
diff --git a/specs/template.rst b/specs/template.rst
new file mode 100644
index 0000000..1991262
--- /dev/null
+++ b/specs/template.rst
@@ -0,0 +1,337 @@
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/glare/+spec/example
14
15Introduction paragraph -- why are we doing anything? A single paragraph of
16prose that operators can understand.
17
18Some notes about using this template:
19
20* Your spec should be in ReSTructured text, like this template.
21
22* Please wrap text at 79 columns.
23
24* The filename in the git repository should match the launchpad URL, for
25 example a URL of: https://blueprints.launchpad.net/glare/+spec/awesome-thing
26 should be named awesome-thing.rst
27
28* Please do not delete any of the sections in this template. If you have
29 nothing to say for a whole section, just write: None
30
31* For help with syntax, see http://sphinx-doc.org/rest.html
32
33* To test out your formatting, build the docs using tox, or see:
34 https://www.siafoo.net/reST.xml
35
36* If you would like to provide a diagram with your spec, ascii diagrams are
37 required. http://asciiflow.com/ is a very nice tool to assist with making
38 ascii diagrams. The reason for this is that the tool used to review specs is
39 based purely on plain text. Plain text will allow review to proceed without
40 having to look at additional files which can not be viewed in gerrit. It
41 will also allow inline feedback on the diagram itself.
42
43* If your specification proposes any changes to the Glare REST API such
44 as changing parameters which can be returned or accepted, or even
45 the semantics of what happens when a client calls into the API, then
46 you should add the APIImpact flag to the commit message. Specifications with
47 the APIImpact flag can be found with the following query:
48
49 https://review.openstack.org/#/q/status:open+project:openstack/glare-specs+message:apiimpact,n,z
50
51
52Problem description
53===================
54
55A detailed description of the problem:
56
57* For a new feature this might be use cases. Ensure you are clear about the
58 actors in each use case: End User vs Deployer
59
60* For a major reworking of something existing it would describe the
61 problems in that feature that are being addressed.
62
63
64Proposed change
65===============
66
67Here is where you cover the change you propose to make in detail. How do you
68propose to solve this problem?
69
70If this is one part of a larger effort make it clear where this piece ends. In
71other words, what's the scope of this effort?
72
73Alternatives
74------------
75
76What other ways could we do this thing? Why aren't we using those? This doesn't
77have to be a full literature review, but it should demonstrate that thought has
78been put into why the proposed solution is an appropriate one.
79
80Data model impact
81-----------------
82
83Changes which require modifications to the data model often have a wider impact
84on the system. The community often has strong opinions on how the data model
85should be evolved, from both a functional and performance perspective. It is
86therefore important to capture and gain agreement as early as possible on any
87proposed changes to the data model.
88
89Questions which need to be addressed by this section include:
90
91* What new data objects and/or database schema changes is this going to
92 require?
93
94* What database migrations will accompany this change?
95
96* How will the initial set of new data objects be generated? For example if you
97 need to take into account existing images, or modify other existing data,
98 describe how that will work.
99
100REST API impact
101---------------
102
103An /api directory is now included for REST API updates. Each API method which
104is either added or changed should have the following:
105
106* Specification for the method
107
108 * A description of what the method does suitable for use in
109 user documentation
110
111 * Method type (POST/PUT/GET/DELETE/PATCH)
112
113 * Normal http response code(s)
114
115 * Expected error http response code(s)
116
117 * A description for each possible error code should be included
118 describing semantic errors which can cause it such as
119 inconsistent parameters supplied to the method, or when an
120 instance is not in an appropriate state for the request to
121 succeed. Errors caused by syntactic problems covered by the JSON
122 schema definition do not need to be included.
123
124 * URL for the resource
125
126 * Parameters which can be passed via the URL
127
128 * JSON schema definition for the body data if allowed
129
130 * JSON schema definition for the response data if any
131
132* Example use case including typical API samples for both data supplied
133 by the caller and the response
134
135* Discuss any policy changes, and discuss what things a deployer needs to
136 think about when defining their policy.
137
138Example JSON schema definitions can be found in the Glare tree
139http://git.openstack.org/cgit/openstack/glare/tree/glare/tests/functional/test_schemas.py
140
141Note that the schema should be defined as restrictively as
142possible. Parameters which are required should be marked as such and
143only under exceptional circumstances should additional parameters
144which are not defined in the schema be permitted (i.e.
145additionalProperties should be False).
146
147Reuse of existing predefined parameter types such as regexps for
148passwords and user defined names is highly encouraged.
149
150Security impact
151---------------
152
153Describe any potential security impact on the system. Some of the items to
154consider include:
155
156* Does this change touch sensitive data such as tokens, keys, or user data?
157
158* Does this change alter the API in a way that may impact security, such as
159 a new way to access sensitive information or a new way to login?
160
161* Does this change involve cryptography or hashing?
162
163* Does this change require the use of sudo or any elevated privileges?
164
165* Does this change involve using or parsing user-provided data? This could
166 be directly at the API level or indirectly such as changes to a cache layer.
167
168* Can this change enable a resource exhaustion attack, such as allowing a
169 single API interaction to consume significant server resources? Some examples
170 of this include launching subprocesses for each connection, or entity
171 expansion attacks in XML.
172
173For more detailed guidance, please see the OpenStack Security Guidelines as
174a reference (https://wiki.openstack.org/wiki/Security/Guidelines). These
175guidelines are a work in progress and are designed to help you identify
176security best practices. For further information, feel free to reach out
177to the OpenStack Security Group at openstack-security@lists.openstack.org.
178
179Notifications impact
180--------------------
181
182Please specify any changes to notifications. This includes introduction of a
183new notification, changes to an existing notification, or removing a
184notification.
185
186Versioning impact
187-----------------
188
189Discuss how your change affects versioning and backward compatibility:
190
191* Can it break any existing DSL code even in theory?
192
193* Can it break API consumers that are using older python-glareclient versions
194 or non-python clients?
195
196* If you make changes to Glare package please state how the version number
197 should be incremented?
198
199* Does your change require newer version of external or internal component?
200
201* How to keep backward compatibility with code and consumers that were
202 available prior to your change?
203
204Other end user impact
205---------------------
206
207Aside from the API, are there other ways a user will interact with this
208feature?
209
210* Does this change have an impact on python-glareclient? What does the user
211 interface there look like?
212
213Performance Impact
214------------------
215
216Describe any potential performance impact on the system. How often will new
217code be called? Is there a major change to the calling pattern of existing
218code?
219
220Examples of things to consider here include:
221
222* A small change in a utility function or a commonly used decorator can have a
223 large impact on performance.
224
225* Calls which result in database queries can have a profound impact on
226 performance when called in critical sections of the code.
227
228* Will the change include any locking, and if so what considerations are there
229 on holding the lock?
230
231Deployer impact
232---------------
233
234Discuss things that will affect how you deploy and configure OpenStack
235that have not already been mentioned, such as:
236
237* Is this a change that takes immediate effect after its merged, or is it
238 something that has to be explicitly enabled?
239
240* If this change is a new binary, how would it be deployed?
241
242* Please state anything that those doing continuous deployment, or those
243 upgrading from the previous release, need to be aware of. Also describe
244 any plans to deprecate configuration values or features. For example, if we
245 change the directory name that widgets are stored in, how do we handle
246 widget directories created before the change landed? Do we move them? Do
247 we have a special case in the code? Do we assume that the operator will
248 recreate all the widgets in their cloud?
249
250Developer impact
251----------------
252
253Discuss things that will affect other developers working on OpenStack,
254such as:
255
256* If the blueprint proposes a change to the store API, discussion of how
257 stores would implement the feature is required.
258
259
260Implementation
261==============
262
263Assignee(s)
264-----------
265
266Who is leading the writing of the code? Or is this a blueprint where you're
267throwing it out there to see who picks it up?
268
269If more than one person is working on the implementation, please designate the
270primary author and contact.
271
272Primary assignee:
273 <launchpad-id or None>
274
275Other contributors:
276 <launchpad-id or None>
277
278Work Items
279----------
280
281Work items or tasks -- break the feature up into the things that need to be
282done to implement it. Those parts might end up being done by different people,
283but we're mostly trying to understand the timeline for implementation.
284
285
286Dependencies
287============
288
289* Include specific references to specs and/or blueprints in glare, or in other
290 projects, that this one either depends on or is related to.
291
292* If this requires functionality of another project that is not currently used
293 by Glare: document that fact.
294
295* Does this feature require any new library dependencies or code otherwise not
296 included in OpenStack? Or does it depend on a specific version of library?
297
298
299Testing
300=======
301
302Please discuss how the change will be tested. We especially want to know what
303tempest tests will be added. It is assumed that unit test coverage will be
304added so that doesn't need to be mentioned explicitly, but discussion of why
305you think unit tests are sufficient and we don't need to add more tempest
306tests would need to be included.
307
308Is this untestable in gate given current limitations (specific hardware /
309software configurations available)? If so, are there mitigation plans (3rd
310party testing, gate enhancements, etc).
311
312
313Documentation Impact
314====================
315
316What is the impact on the docs team of this change? Some changes might require
317donating resources to the docs team to have the documentation updated. Don't
318repeat details discussed above, but please reference them here.
319
320
321References
322==========
323
324Please add any useful references here. You are not required to have any
325reference. Moreover, this specification should still make sense when your
326references are unavailable. Examples of what you could include are:
327
328* Links to mailing list or IRC discussions
329
330* Links to notes from a summit session
331
332* Links to relevant research, if appropriate
333
334* Related specifications as appropriate (e.g., if it's an EC2 thing, link the
335 EC2 docs)
336
337* Anything else you feel it is worthwhile to refer to
diff --git a/tests/__init__.py b/tests/__init__.py
new file mode 100644
index 0000000..e69de29
--- /dev/null
+++ b/tests/__init__.py
diff --git a/tests/test_titles.py b/tests/test_titles.py
new file mode 100644
index 0000000..231da2c
--- /dev/null
+++ b/tests/test_titles.py
@@ -0,0 +1,110 @@
1# Licensed under the Apache License, Version 2.0 (the "License"); you may
2# not use this file except in compliance with the License. You may obtain
3# a copy of the License at
4#
5# http://www.apache.org/licenses/LICENSE-2.0
6#
7# Unless required by applicable law or agreed to in writing, software
8# distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
9# WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
10# License for the specific language governing permissions and limitations
11# under the License.
12
13import glob
14import re
15
16import docutils.core
17import testtools
18
19
20class TestTitles(testtools.TestCase):
21 def _get_title(self, section_tree):
22 section = {
23 'subtitles': [],
24 }
25 for node in section_tree:
26 if node.tagname == 'title':
27 section['name'] = node.rawsource
28 elif node.tagname == 'section':
29 subsection = self._get_title(node)
30 section['subtitles'].append(subsection['name'])
31 return section
32
33 def _get_titles(self, spec):
34 titles = {}
35 for node in spec:
36 if node.tagname == 'section':
37 section = self._get_title(node)
38 titles[section['name']] = section['subtitles']
39 return titles
40
41 def _check_titles(self, fname, titles):
42 expected_titles = ('Problem description', 'Proposed change',
43 'Implementation', 'Dependencies',
44 'Testing', 'Documentation Impact',
45 'References')
46 self.assertEqual(
47 sorted(expected_titles),
48 sorted(titles.keys()),
49 "Expected titles not found in document %s" % fname)
50
51 proposed = 'Proposed change'
52 self.assertIn('Alternatives', titles[proposed])
53 self.assertIn('Data model impact', titles[proposed])
54 self.assertIn('REST API impact', titles[proposed])
55 self.assertIn('Versioning impact', titles[proposed])
56 self.assertIn('Other end user impact', titles[proposed])
57 self.assertIn('Deployer impact', titles[proposed])
58 self.assertIn('Developer impact', titles[proposed])
59
60 impl = 'Implementation'
61 self.assertIn('Assignee(s)', titles[impl])
62 self.assertIn('Work Items', titles[impl])
63
64 def _check_titles_lite(self, fname, titles):
65 self.assertEqual(
66 ['Glare Spec Lite'],
67 sorted(titles.keys()),
68 "Expected titles not found in document %s" % fname)
69
70 def _check_lines_wrapping(self, tpl, raw):
71 for i, line in enumerate(raw.split("\n")):
72 if "http://" in line or "https://" in line:
73 continue
74 self.assertTrue(
75 len(line) < 80,
76 msg="%s:%d: Line limited to a maximum of 79 characters." %
77 (tpl, i+1))
78
79 def _check_no_cr(self, tpl, raw):
80 matches = re.findall('\r', raw)
81 self.assertEqual(
82 len(matches), 0,
83 "Found %s literal carriage returns in file %s" %
84 (len(matches), tpl))
85
86
87 def _check_trailing_spaces(self, tpl, raw):
88 for i, line in enumerate(raw.split("\n")):
89 trailing_spaces = re.findall(" +$", line)
90 self.assertEqual(len(trailing_spaces),0,
91 "Found trailing spaces on line %s of %s" % (i+1, tpl))
92
93
94 def test_template(self):
95 files = ['specs/template.rst'] + glob.glob('specs/*/*/*')
96 for filename in files:
97 self.assertTrue(filename.endswith(".rst"),
98 "spec's file must uses 'rst' extension.")
99 with open(filename) as f:
100 data = f.read()
101
102 spec = docutils.core.publish_doctree(data)
103 titles = self._get_titles(spec)
104 if 'Glare Spec Lite' in titles:
105 self._check_titles_lite(filename, titles)
106 else:
107 self._check_titles(filename, titles)
108 self._check_lines_wrapping(filename, data)
109 self._check_no_cr(filename, data)
110 self._check_trailing_spaces(filename, data)
diff --git a/tox.ini b/tox.ini
new file mode 100644
index 0000000..ad122cf
--- /dev/null
+++ b/tox.ini
@@ -0,0 +1,25 @@
1[tox]
2minversion = 1.6
3envlist = docs,py27
4skipsdist = True
5
6[testenv]
7usedevelop = True
8setenv = VIRTUAL_ENV={envdir}
9passenv = http_proxy HTTP_PROXY https_proxy HTTPS_PROXY no_proxy NO_PROXY
10install_command = pip install -U {opts} {packages}
11deps = -r{toxinidir}/requirements.txt
12commands = python setup.py testr --slowest --testr-args='{posargs}'
13basepython = python2
14
15[testenv:venv]
16commands = {posargs}
17
18[testenv:docs]
19commands = python setup.py build_sphinx
20
21[testenv:doc8]
22deps =
23 -r{toxinidir}/requirements.txt
24 doc8
25commands = doc8 doc/source