Initial commit for OS-Ansible-Deployment specs

This commit adds basic repo configuration and testing for specs.
Changes include:

* Doc testing
* Index testing
* Build testing
* Initial spec template

Change-Id: I48e4ef1794fb3b698a8346345848bdfa67ccb08b
This commit is contained in:
Kevin Carter 2015-03-16 21:55:11 -05:00
parent bba5149eef
commit ca245c81d9
15 changed files with 806 additions and 0 deletions

18
.gitignore vendored Normal file
View File

@ -0,0 +1,18 @@
*.pyc
# vim swap files
.*.swp
# services' runtime files
*.log
*.pid
.idea/
.DS_Store
*.egg-info
draft/
/.testrepository
/.tox
/doc/build

4
.testr.conf Normal file
View File

@ -0,0 +1,4 @@
[DEFAULT]
test_command=OS_STDOUT_CAPTURE=1 OS_STDERR_CAPTURE=1 OS_TEST_TIMEOUT=60 ${PYTHON:-python} -m subunit.run discover -t ./ . $LISTOPT $IDOPTION
test_id_option=--load-list $IDFILE
test_list_option=--list

3
LICENSE Normal file
View File

@ -0,0 +1,3 @@
This work is licensed under a Creative Commons Attribution 3.0 Unported License.
http://creativecommons.org/licenses/by/3.0/legalcode

45
README.rst Normal file
View File

@ -0,0 +1,45 @@
====================================
OS-Ansible-Deployment Specifications
====================================
This git repository is used to hold approved design specifications for additions
to the OS-Ansible-Deployment project. Reviews of the specs are done in gerrit,
using a similar workflow to how we review and merge changes to the code itself.
The layout of this repository is::
specs/<release>/
You can find an example spec in `doc/source/specs/template.rst`.
Specifications are proposed for a given release by adding them to the
`specs/<release>` directory and posting it for review. The implementation
status of a blueprint for a given release can be found by looking at the
blueprint in launchpad. Not all approved blueprints will get fully implemented.
Specifications have to be re-proposed for every release. The review may be
quick, but even if something was previously approved, it should be re-reviewed
to make sure it still makes sense as written.
Prior to the Juno development cycle, this repository was not used for spec
reviews. Reviews prior to Juno were completed entirely through Launchpad
blueprints::
https://blueprints.launchpad.net/openstack-ansible
Please note, Launchpad blueprints are still used for tracking the
current status of blueprints. For more information, see::
https://wiki.openstack.org/wiki/Blueprints
For more information about working with gerrit, see::
http://docs.openstack.org/infra/manual/developers.html#development-workflow
To validate that the specification is syntactically correct (i.e. get more
confidence in the Jenkins result), please execute the following command::
$ tox
After running ``tox``, the documentation will be available for viewing in HTML
format in the ``doc/build/`` directory.

268
doc/source/conf.py Normal file
View File

@ -0,0 +1,268 @@
# -*- coding: utf-8 -*-
#
# Tempest documentation build configuration file, created by
# sphinx-quickstart on Tue May 21 17:43:32 2013.
#
# This file is execfile()d with the current directory set to its containing dir.
#
# Note that not all possible configuration values are present in this
# autogenerated file.
#
# All configuration values have a default; values that are commented out
# serve to show the default.
import sys
import os
# If extensions (or modules to document with autodoc) are in another directory,
# add these directories to sys.path here. If the directory is relative to the
# documentation root, use os.path.abspath to make it absolute, like shown here.
#sys.path.insert(0, os.path.abspath('.'))
# -- General configuration -----------------------------------------------------
# If your documentation needs a minimal Sphinx version, state it here.
#needs_sphinx = '1.0'
# Add any Sphinx extension module names here, as strings. They can be extensions
# coming with Sphinx (named 'sphinx.ext.*') or your custom ones.
extensions = ['sphinx.ext.autodoc',
'sphinx.ext.intersphinx',
'sphinx.ext.todo',
'sphinx.ext.viewcode',
'oslosphinx'
]
todo_include_todos = True
# Add any paths that contain templates here, relative to this directory.
templates_path = ['_templates']
# The suffix of source filenames.
source_suffix = '.rst'
# The encoding of source files.
#source_encoding = 'utf-8-sig'
# The master toctree document.
master_doc = 'index'
# General information about the project.
project = u'OS-Ansible-Deployment Specs'
copyright = u'2015, OS-Ansible-Deployment'
# The language for content autogenerated by Sphinx. Refer to documentation
# for a list of supported languages.
#language = None
# There are two options for replacing |today|: either, you set today to some
# non-false value, then it is used:
#today = ''
# Else, today_fmt is used as the format for a strftime call.
#today_fmt = '%B %d, %Y'
# List of patterns, relative to source directory, that match files and
# directories to ignore when looking for source files.
exclude_patterns = ['_build']
# The reST default role (used for this markup: `text`) to use for all documents.
#default_role = None
# If true, '()' will be appended to :func: etc. cross-reference text.
#add_function_parentheses = True
# If true, the current module name will be prepended to all description
# unit titles (such as .. function::).
add_module_names = False
# If true, sectionauthor and moduleauthor directives will be shown in the
# output. They are ignored by default.
show_authors = True
# The name of the Pygments (syntax highlighting) style to use.
pygments_style = 'sphinx'
# A list of ignored prefixes for module index sorting.
modindex_common_prefix = ['OS-Ansible-Deployment-specs.']
# -- Options for man page output ----------------------------------------------
man_pages = []
# -- Options for HTML output ---------------------------------------------------
# The theme to use for HTML and HTML Help pages. See the documentation for
# a list of builtin themes.
html_theme = 'nature'
# Theme options are theme-specific and customize the look and feel of a theme
# further. For a list of options available for each theme, see the
# documentation.
#html_theme_options = {}
# Add any paths that contain custom themes here, relative to this directory.
#html_theme_path = []
# The name for this set of Sphinx documents. If None, it defaults to
# "<project> v<release> documentation".
#html_title = None
# A shorter title for the navigation bar. Default is the same as html_title.
#html_short_title = None
# The name of an image file (relative to this directory) to place at the top
# of the sidebar.
#html_logo = None
# The name of an image file (within the static path) to use as favicon of the
# docs. This file should be a Windows icon file (.ico) being 16x16 or 32x32
# pixels large.
#html_favicon = None
# If not '', a 'Last updated on:' timestamp is inserted at every page bottom,
# using the given strftime format.
git_cmd = "git log --pretty=format:'%ad, commit %h' --date=local -n1"
html_last_updated_fmt = os.popen(git_cmd).read()
# If true, SmartyPants will be used to convert quotes and dashes to
# typographically correct entities.
#html_use_smartypants = True
# Custom sidebar templates, maps document names to template names.
#html_sidebars = {}
# Additional templates that should be rendered to pages, maps page names to
# template names.
#html_additional_pages = {}
# If false, no module index is generated.
html_domain_indices = False
# If false, no index is generated.
html_use_index = False
# If true, the index is split into individual pages for each letter.
#html_split_index = False
# If true, links to the reST sources are added to the pages.
#html_show_sourcelink = True
# If true, "Created using Sphinx" is shown in the HTML footer. Default is True.
#html_show_sphinx = True
# If true, "(C) Copyright ..." is shown in the HTML footer. Default is True.
#html_show_copyright = True
# If true, an OpenSearch description file will be output, and all pages will
# contain a <link> tag referring to it. The value of this option must be the
# base URL from which the finished HTML is served.
#html_use_opensearch = ''
# This is the file name suffix for HTML files (e.g. ".xhtml").
#html_file_suffix = None
# Output file base name for HTML help builder.
htmlhelp_basename = 'OS-Ansible-Deployment-Specs-doc'
# -- Options for LaTeX output --------------------------------------------------
latex_elements = {
# The paper size ('letterpaper' or 'a4paper').
#'papersize': 'letterpaper',
# The font size ('10pt', '11pt' or '12pt').
#'pointsize': '10pt',
# Additional stuff for the LaTeX preamble.
#'preamble': '',
}
# Grouping the document tree into LaTeX files. List of tuples
# (source start file, target name, title, author, documentclass [howto/manual]).
latex_documents = [
('index', 'OS-Ansible-Deployment-specs.tex', u'OS-Ansible-Deployment Specs',
u'OS-Ansible-Deployment Team', 'manual'),
]
# The name of an image file (relative to this directory) to place at the top of
# the title page.
#latex_logo = None
# For "manual" documents, if this is true, then toplevel headings are parts,
# not chapters.
#latex_use_parts = False
# If true, show page references after internal links.
#latex_show_pagerefs = False
# If true, show URL addresses after external links.
#latex_show_urls = False
# Documents to append as an appendix to all manuals.
#latex_appendices = []
# If false, no module index is generated.
#latex_domain_indices = True
# -- Options for Texinfo output ------------------------------------------------
# Grouping the document tree into Texinfo files. List of tuples
# (source start file, target name, title, author,
# dir menu entry, description, category)
texinfo_documents = [
('index', 'OS-Ansible-Deployment-specs', u'OS-Ansible-Deployment Design Specs',
u'OS-Ansible-Deployment Team', 'OS-Ansible-Deployment-specs', 'Design specifications for the OS-Ansible-Deployment project.',
'Miscellaneous'),
]
# Documents to append as an appendix to all manuals.
#texinfo_appendices = []
# If false, no module index is generated.
#texinfo_domain_indices = True
# How to display URL addresses: 'footnote', 'no', or 'inline'.
#texinfo_show_urls = 'footnote'
# -- Options for Epub output ---------------------------------------------------
# Bibliographic Dublin Core info.
epub_title = u'OS-Ansible-Deployment Specs'
epub_author = u'OS-Ansible-Deployment Team'
epub_publisher = u'OS-Ansible-Deployment Team'
epub_copyright = u'2015, OS-Ansible-Deployment'
# The language of the text. It defaults to the language option
# or en if the language is not set.
#epub_language = ''
# The scheme of the identifier. Typical schemes are ISBN or URL.
#epub_scheme = ''
# The unique identifier of the text. This can be a ISBN number
# or the project homepage.
#epub_identifier = ''
# A unique identification for the text.
#epub_uid = ''
# A tuple containing the cover image and cover page html template filenames.
#epub_cover = ()
# HTML files that should be inserted before the pages created by sphinx.
# The format is a list of tuples containing the path and title.
#epub_pre_files = []
# HTML files shat should be inserted after the pages created by sphinx.
# The format is a list of tuples containing the path and title.
#epub_post_files = []
# A list of files that should not be packed into the epub file.
#epub_exclude_files = []
# The depth of the table of contents in toc.ncx.
#epub_tocdepth = 3
# Allow duplicate toc entries.
#epub_tocdup = True

19
doc/source/index.rst Normal file
View File

@ -0,0 +1,19 @@
.. OS-Ansible-Deployment documentation master file
============================================
OS-Ansible-Deployment Project Specifications
============================================
Contents:
.. toctree::
:glob:
:maxdepth: 1
specs/*
================
Index and tables
================
* :ref:`search`

1
doc/source/specs Symbolic link
View File

@ -0,0 +1 @@
../../specs/

6
requirements.txt Normal file
View File

@ -0,0 +1,6 @@
docutils==0.9.1
oslosphinx
pbr>=0.6,!=0.7,<1.0
sphinx>=1.1.2,!=1.2.0,<1.3
testrepository>=0.0.18
testtools>=0.9.34

23
setup.cfg Normal file
View File

@ -0,0 +1,23 @@
[metadata]
name = os-ansible-deployment-specs
summary = Design Specifications for os-ansible-deployment
description-file =
README.rst
author = OpenStack
author-email = openstack-ansible@lists.launchpad.net
home-page = https://wiki.openstack.org/wiki/OS-Ansible-Deployment
classifier =
Intended Audience :: Developers
License :: OSI Approved :: Apache Software License
Operating System :: POSIX :: Linux
[build_sphinx]
all_files = 1
build-dir = doc/build
source-dir = doc/source
[pbr]
warnerrors = True
[wheel]
universal = 1

22
setup.py Normal file
View File

@ -0,0 +1,22 @@
#!/usr/bin/env python
# Copyright (c) 2013 Hewlett-Packard Development Company, L.P.
#
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
# http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
# implied.
# See the License for the specific language governing permissions and
# limitations under the License.
# THIS FILE IS MANAGED BY THE GLOBAL REQUIREMENTS REPO - DO NOT EDIT
import setuptools
setuptools.setup(
setup_requires=['pbr'],
pbr=True)

267
specs/template.rst Normal file
View File

@ -0,0 +1,267 @@
Example Spec - Title of your spec
#################################
:date: 2015-02-02 22:00
:tags: used, for, groupings, and, indexing
Update the date of your spec with the date that it was proposed.
Add any tags to the spec that may be of use for people to get what its
about at a glance.
Provide a synopsis as to why you are creating this spec/blueprint.
Include the URL of your launchpad blueprint:
* https://blueprints.launchpad.net/openstack-ansible/+spec/example
Introduction paragraph -- why are we doing anything? A single paragraph of
prose that operators can understand. Describe the problem in as much detail
as you can.
Some notes about using this template:
* Your spec should be in ReSTructured text, like this template.
* Please wrap text at 79 columns.
* The filename in the git repository should match the launchpad URL, for
example a URL of: https://blueprints.launchpad.net/openstack-ansible/+spec/awesome-thing
should be named awesome-thing.rst
* Please do not delete any of the sections in this template. If you have
nothing to say for a whole section, just write: None or N/A
* For help with syntax, see http://sphinx-doc.org/rest.html
* To test out your formatting, build the docs using tox, or see:
http://rst.ninjs.org
* If you would like to provide a diagram with your spec, ascii diagrams are
required. http://asciiflow.com/ is a very nice tool to assist with making
ascii diagrams. The reason for this is that the tool used to review specs is
based purely on plain text. Plain text will allow review to proceed without
having to look at additional files which can not be viewed in gerrit. It
will also allow inline feedback on the diagram itself.
Problem description
===================
A detailed description of the problem:
* For a new feature this might be use cases. Ensure you are clear about the
actors in each use case: End User vs Deployer.
* For a major reworking of something existing it would describe the
problems in that feature that are being addressed.
Proposed change
===============
Provide an overview of the changes you'd like to see implemented. Here is
where you cover the change you propose to make in detail. How do you propose
to solve this problem?
Notable changes:
* list out all of the notable changes.
If this is one part of a larger effort make it clear where this piece ends. In
other words, what's the scope of this effort?
Alternatives
------------
What, if any, are the alternatives to the changes you are proposing? What other
ways could we do this thing? Why aren't we using those? This doesn't have to be
a full literature review, but it should demonstrate that thought has been put
into why the proposed solution is an appropriate one.
Playbook impact
---------------
What impact will there be on the playbooks?
Upgrade impact
--------------
If this change set concerns any kind of upgrade process, describe how it is
supposed to deal with that stuff. For example, if containers are removed and
or have their specific purpose changed how do you indend to deal with the
eventual upgrade from the prospective of an existing installation? Does this
change require documentation to be fully supported or will there be specific
tooling that has to be created in order for the upgrade to be completed?
Security impact
---------------
Describe any potential security impact on the system. Some of the items to
consider include:
* Does this change touch sensitive data such as tokens, keys, or user data?
* Does this change alter a deployed OpenStack API in a way that may impact
security, such as a new way to access sensitive information or a new way to
login?
* Does this change involve cryptography or hashing?
* Does this change require the use of sudo or any elevated privileges?
* Does this change involve using or parsing user-provided data? This could
be directly at the API level or indirectly such as changes to a cache layer.
For more detailed guidance, please see the OpenStack Security Guidelines as
a reference (https://wiki.openstack.org/wiki/Security/Guidelines). These
guidelines are a work in progress and are designed to help you identify
security best practices. For further information, feel free to reach out
to the OpenStack Security Group at openstack-security@lists.openstack.org.
Performance impact
------------------
Describe any potential performance impact on the system. For example, how is
the code executed and does it depend on upstream resources that may be
unavailable?
Examples of things to consider here include:
* Adding a new PPA for upgraded packages, who is the maintainer? Does this
individual push often? How long has this individual/company maintain
specific packages?
* Adding additional pinned packages for use in a python wheel. Does this
package change often? Are there tests?
End user impact
---------------
How would the end user be impacted by this change? The "End User" is defined
as the users of the deployed cloud?
Deployer impact
---------------
How would the deployer be impacted by this change? Discuss things that
will affect how OpenStack will be deployed, such as:
* What config options are being added? Should they be more generic than
proposed? Are the default values ones which will work well in
real deployments?
* Is this a change that takes immediate effect after its merged, or is it
something that has to be explicitly enabled?
* If this change is a new binary, how would it be deployed?
* Please state anything that those doing continuous deployment, or those
upgrading from the previous release, need to be aware of. Also describe
any plans to deprecate configuration values or features. For example, if we
change the name of a play, how do we handle deployments before the change
landed? Do we have a special case in the code? Do we assume that the
operator will recreate containers within the infrastructure of the cloud?
Does this effect running instances within the cloud?
Developer impact
----------------
How does this change impact future developers working on the ansible
playbooks? Discuss things that will affect other developers working on
OS-Ansible-Deployment, such as:
* If this spec proposes a new role, how will that role be deployed? Is this a
new default role? Does this role have a host impact?
Dependencies
------------
Does this blueprint/spec depend one another blueprint or spec?
* Include specific references to specs and/or blueprints in
os-ansible-deployment, or in other projects, that this one either depends on
or is related to.
* Is the new requirement due to an upstream change? If so document it and
provide references to the change.
Implementation
==============
Assignee(s)
-----------
Who is leading the writing of the code? Or is this a blueprint where you're
throwing it out there to see who picks it up?
If more than one person is working on the implementation, please designate the
primary author and contact.
Primary assignee:
<launchpad-id or None>
Other contributors:
<launchpad-id or None>
Please add **IRC nicknames** where applicable.
Work items
----------
Work items or tasks -- break the feature up into the things that need to be
done to implement it. Those parts might end up being done by different people,
but we're mostly trying to understand the timeline for implementation.
Testing
=======
Please discuss how the change will be tested. You should be able to answer the
following questions:
* Does this change impact how gating is done?
* Can this change be tested on a **per-commit** basis?
* Given the instance size restrictions, as found in OpenStack Infra
(8GB Ram, vCPUs <= 8), can the test be run in a resource constrained
environment?
* Is this untestable in given current limitations (specific hardware /
software configurations available)? If so, are there mitigation plans
for this change to be tested within 3rd party testing, gate enhancements,
etc...?
* If the service is not OpenStack specific how can we test the change?
Documentation impact
====================
What is the impact on the docs team of this change? Some changes might require
donating resources to the docs team to have the documentation updated. Don't
repeat details discussed above, but please reference them here.
References
==========
Please add any useful references here. You are not required to have any
reference. Moreover, this specification should still make sense when your
references are unavailable. Examples of what you could include are:
* Links to mailing list or IRC discussions
* Links to relevant research, if appropriate
* Related specifications as appropriate
* Anything else you feel it is worthwhile to refer to

0
tests/__init__.py Normal file
View File

105
tests/test_titles.py Normal file
View File

@ -0,0 +1,105 @@
# Licensed under the Apache License, Version 2.0 (the "License"); you may
# not use this file except in compliance with the License. You may obtain
# a copy of the License at
#
# http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
# WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
# License for the specific language governing permissions and limitations
# under the License.
import glob
import re
import docutils.core
import testtools
class TestTitles(testtools.TestCase):
def _get_title(self, section_tree):
section = {
'subtitles': [],
}
for node in section_tree:
if node.tagname == 'title':
section['name'] = node.rawsource
elif node.tagname == 'section':
subsection = self._get_title(node)
section['subtitles'].append(subsection['name'])
return section
def _get_titles(self, spec):
titles = {}
for node in spec:
if node.tagname == 'section':
section = self._get_title(node)
titles[section['name']] = section['subtitles']
return titles
def _check_titles(self, fname, titles):
expected_titles = [
'Problem description',
'Proposed change',
'Implementation',
'Testing',
'Documentation impact',
'References'
]
self.assertEqual(
sorted(expected_titles),
sorted(titles.keys()),
"Expected titles not found in document %s" % fname
)
proposed = 'Proposed change'
self.assertIn('Alternatives', titles[proposed])
self.assertIn('Dependencies', titles[proposed])
self.assertIn('Deployer impact', titles[proposed])
self.assertIn('Developer impact', titles[proposed])
self.assertIn('End user impact', titles[proposed])
self.assertIn('Performance impact', titles[proposed])
self.assertIn('Playbook impact', titles[proposed])
self.assertIn('Security impact', titles[proposed])
self.assertIn('Upgrade impact', titles[proposed])
impl = 'Implementation'
self.assertIn('Assignee(s)', titles[impl])
self.assertIn('Work items', titles[impl])
def _check_lines_wrapping(self, tpl, raw):
for i, line in enumerate(raw.split("\n")):
if "http://" in line or "https://" in line:
continue
self.assertTrue(
len(line) < 80,
msg="%s:%d: Line limited to a maximum of 79 characters." %
(tpl, i+1)
)
def _check_no_cr(self, tpl, raw):
matches = re.findall('\r', raw)
self.assertEqual(
len(matches), 0,
"Found %s literal carriage returns in file %s" %
(len(matches), tpl)
)
def test_template(self):
files = ['specs/template.rst'] + glob.glob('specs/*/*')
# filtering images subdirectory
files = filter(lambda x: 'images' not in x, files)
for filename in files:
self.assertTrue(
filename.endswith(".rst"),
"spec's file must uses 'rst' extension."
)
with open(filename) as f:
data = f.read()
spec = docutils.core.publish_doctree(data)
titles = self._get_titles(spec)
self._check_titles(filename, titles)
self._check_lines_wrapping(filename, data)
self._check_no_cr(filename, data)

8
tools/with_venv.sh Normal file
View File

@ -0,0 +1,8 @@
#!/bin/bash
tools_path=${tools_path:-$(dirname $0)}
venv_path=${venv_path:-${tools_path}}
venv_dir=${venv_name:-/../.venv}
TOOLS=${tools_path}
VENV=${venv:-${venv_path}/${venv_dir}}
source ${VENV}/bin/activate && "$@"

17
tox.ini Normal file
View File

@ -0,0 +1,17 @@
[tox]
minversion = 1.6
envlist = docs,py27
skipsdist = True
[testenv]
usedevelop = True
setenv = VIRTUAL_ENV={envdir}
install_command = pip install -U {opts} {packages}
deps = -r{toxinidir}/requirements.txt
commands = python setup.py testr --slowest --testr-args='{posargs:}'
[testenv:venv]
commands = {posargs}
[testenv:docs]
commands = python setup.py build_sphinx