openstack/openstack-chef-specs
Code Issues Proposed changes

Retire openstack-chef: remove repo content

Browse Source 
OpenStack-chef project is retiring
- https://review.opendev.org/c/openstack/governance/+/905279

this commit remove the content of this project repo

Depends-On: https://review.opendev.org/c/openstack/project-config/+/909134
Change-Id: Ie87bb2b994a53b7416f43a9f4c850a2b34e69516
This commit is contained in:
Ghanshyam Mann 2024-02-15 14:17:36 -08:00
parent 1eaa0d539b
commit 75aef65e3d
61 changed files with 8 additions and 2991 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

5
.gitignore vendored
View File

@ -1,5 +0,0 @@
AUTHORS
ChangeLog
build
.tox
*.egg*

3
.zuul.yaml
View File

@ -1,3 +0,0 @@
- project:
templates:
- openstack-specs-jobs

12
CONTRIBUTING.rst
View File

@ -1,12 +0,0 @@
If you would like to contribute to the development of OpenStack,
you must follow the steps in this page:
http://docs.openstack.org/infra/manual/developers.html
Once those steps have been completed, changes to OpenStack
should be submitted for review via the Gerrit tool, following
the workflow documented at:
http://docs.openstack.org/infra/manual/developers.html#development-workflow
Pull requests submitted through GitHub will be ignored.

4
HACKING.rst
View File

@ -1,4 +0,0 @@
openstack-chef-specs Style Commandments
=========================================
Read the OpenStack Style Commandments https://docs.openstack.org/hacking/latest/

175
LICENSE
View File

@ -1,175 +0,0 @@
Apache License
Version 2.0, January 2004
http://www.apache.org/licenses/
TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
1. Definitions.
"License" shall mean the terms and conditions for use, reproduction,
and distribution as defined by Sections 1 through 9 of this document.
"Licensor" shall mean the copyright owner or entity authorized by
the copyright owner that is granting the License.
"Legal Entity" shall mean the union of the acting entity and all
other entities that control, are controlled by, or are under common
control with that entity. For the purposes of this definition,
"control" means (i) the power, direct or indirect, to cause the
direction or management of such entity, whether by contract or
otherwise, or (ii) ownership of fifty percent (50%) or more of the
outstanding shares, or (iii) beneficial ownership of such entity.
"You" (or "Your") shall mean an individual or Legal Entity
exercising permissions granted by this License.
"Source" form shall mean the preferred form for making modifications,
including but not limited to software source code, documentation
source, and configuration files.
"Object" form shall mean any form resulting from mechanical
transformation or translation of a Source form, including but
not limited to compiled object code, generated documentation,
and conversions to other media types.
"Work" shall mean the work of authorship, whether in Source or
Object form, made available under the License, as indicated by a
copyright notice that is included in or attached to the work
(an example is provided in the Appendix below).
"Derivative Works" shall mean any work, whether in Source or Object
form, that is based on (or derived from) the Work and for which the
editorial revisions, annotations, elaborations, or other modifications
represent, as a whole, an original work of authorship. For the purposes
of this License, Derivative Works shall not include works that remain
separable from, or merely link (or bind by name) to the interfaces of,
the Work and Derivative Works thereof.
"Contribution" shall mean any work of authorship, including
the original version of the Work and any modifications or additions
to that Work or Derivative Works thereof, that is intentionally
submitted to Licensor for inclusion in the Work by the copyright owner
or by an individual or Legal Entity authorized to submit on behalf of
the copyright owner. For the purposes of this definition, "submitted"
means any form of electronic, verbal, or written communication sent
to the Licensor or its representatives, including but not limited to
communication on electronic mailing lists, source code control systems,
and issue tracking systems that are managed by, or on behalf of, the
Licensor for the purpose of discussing and improving the Work, but
excluding communication that is conspicuously marked or otherwise
designated in writing by the copyright owner as "Not a Contribution."
"Contributor" shall mean Licensor and any individual or Legal Entity
on behalf of whom a Contribution has been received by Licensor and
subsequently incorporated within the Work.
2. Grant of Copyright License. Subject to the terms and conditions of
this License, each Contributor hereby grants to You a perpetual,
worldwide, non-exclusive, no-charge, royalty-free, irrevocable
copyright license to reproduce, prepare Derivative Works of,
publicly display, publicly perform, sublicense, and distribute the
Work and such Derivative Works in Source or Object form.
3. Grant of Patent License. Subject to the terms and conditions of
this License, each Contributor hereby grants to You a perpetual,
worldwide, non-exclusive, no-charge, royalty-free, irrevocable
(except as stated in this section) patent license to make, have made,
use, offer to sell, sell, import, and otherwise transfer the Work,
where such license applies only to those patent claims licensable
by such Contributor that are necessarily infringed by their
Contribution(s) alone or by combination of their Contribution(s)
with the Work to which such Contribution(s) was submitted. If You
institute patent litigation against any entity (including a
cross-claim or counterclaim in a lawsuit) alleging that the Work
or a Contribution incorporated within the Work constitutes direct
or contributory patent infringement, then any patent licenses
granted to You under this License for that Work shall terminate
as of the date such litigation is filed.
4. Redistribution. You may reproduce and distribute copies of the
Work or Derivative Works thereof in any medium, with or without
modifications, and in Source or Object form, provided that You
meet the following conditions:
(a) You must give any other recipients of the Work or
Derivative Works a copy of this License; and
(b) You must cause any modified files to carry prominent notices
stating that You changed the files; and
(c) You must retain, in the Source form of any Derivative Works
that You distribute, all copyright, patent, trademark, and
attribution notices from the Source form of the Work,
excluding those notices that do not pertain to any part of
the Derivative Works; and
(d) If the Work includes a "NOTICE" text file as part of its
distribution, then any Derivative Works that You distribute must
include a readable copy of the attribution notices contained
within such NOTICE file, excluding those notices that do not
pertain to any part of the Derivative Works, in at least one
of the following places: within a NOTICE text file distributed
as part of the Derivative Works; within the Source form or
documentation, if provided along with the Derivative Works; or,
within a display generated by the Derivative Works, if and
wherever such third-party notices normally appear. The contents
of the NOTICE file are for informational purposes only and
do not modify the License. You may add Your own attribution
notices within Derivative Works that You distribute, alongside
or as an addendum to the NOTICE text from the Work, provided
that such additional attribution notices cannot be construed
as modifying the License.
You may add Your own copyright statement to Your modifications and
may provide additional or different license terms and conditions
for use, reproduction, or distribution of Your modifications, or
for any such Derivative Works as a whole, provided Your use,
reproduction, and distribution of the Work otherwise complies with
the conditions stated in this License.
5. Submission of Contributions. Unless You explicitly state otherwise,
any Contribution intentionally submitted for inclusion in the Work
by You to the Licensor shall be under the terms and conditions of
this License, without any additional terms or conditions.
Notwithstanding the above, nothing herein shall supersede or modify
the terms of any separate license agreement you may have executed
with Licensor regarding such Contributions.
6. Trademarks. This License does not grant permission to use the trade
names, trademarks, service marks, or product names of the Licensor,
except as required for reasonable and customary use in describing the
origin of the Work and reproducing the content of the NOTICE file.
7. Disclaimer of Warranty. Unless required by applicable law or
agreed to in writing, Licensor provides the Work (and each
Contributor provides its Contributions) on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
implied, including, without limitation, any warranties or conditions
of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A
PARTICULAR PURPOSE. You are solely responsible for determining the
appropriateness of using or redistributing the Work and assume any
risks associated with Your exercise of permissions under this License.
8. Limitation of Liability. In no event and under no legal theory,
whether in tort (including negligence), contract, or otherwise,
unless required by applicable law (such as deliberate and grossly
negligent acts) or agreed to in writing, shall any Contributor be
liable to You for damages, including any direct, indirect, special,
incidental, or consequential damages of any character arising as a
result of this License or out of the use or inability to use the
Work (including but not limited to damages for loss of goodwill,
work stoppage, computer failure or malfunction, or any and all
other commercial damages or losses), even if such Contributor
has been advised of the possibility of such damages.
9. Accepting Warranty or Additional Liability. While redistributing
the Work or Derivative Works thereof, You may choose to offer,
and charge a fee for, acceptance of support, warranty, indemnity,
or other liability obligations and/or rights consistent with this
License. However, in accepting such obligations, You may act only
on Your own behalf and on Your sole responsibility, not on behalf
of any other Contributor, and only if You agree to indemnify,
defend, and hold each Contributor harmless for any liability
incurred by, or claims asserted against, such Contributor by reason
of your accepting any such warranty or additional liability.

17
MAINTAINERS.md
View File

@ -1,17 +0,0 @@
This is a list of the core reviewer membership and contact information. Please don't hesitate to reach out of you have questions or concerns related to this project. We are here to help.
PTL: [Samuel Cassiba](mailto:s@cassiba.com?subject=[chef]%20Question%20about%20OpenStack%20and%20Chef)
# Core Reviewers
| Name | IRC handle | Email | TimeZone |
| ---- | ---------- | ----- | -------- |
| Jan Klare | jklare | j.klare@cloudbau.de | UTC+2 |
| Samuel Cassiba | sc` | s@cassiba.com | UTC-8 |
# General Code Reviewers
The current members of openstack-chef are listed here:
https://launchpad.net/~openstack-chef/+members#active

63
README.rst
View File

@ -1,57 +1,10 @@
======================== This project is no longer maintained.
Team and repository tags
========================
.. image:: https://governance.openstack.org/badges/openstack-chef-specs.svg The contents of this repository are still available in the Git
:target: https://governance.openstack.org/reference/tags/index.html source code management system. To see the contents of this
repository before it reached its end of life, please check out the
previous commit with "git checkout HEAD^1".
.. Change things from this point on For any further questions, please email
openstack-discuss@lists.openstack.org or join #openstack-dev on
================================== OFTC.
OpenStack-chef Specifications
==================================
This git repository is used to hold approved design specifications for additions
to the openstack-chef project. Reviews of the specifications 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>/<cookbook>/
You can find an example spec in `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.
Use the Common cookbook directory for specifications that effect multiple
cookbooks. Once the specification is approved and merged, the LaunchPad
blueprint will be updated accordingly.
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-chef
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::
https://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.

164
doc/Makefile
View File

@ -1,164 +0,0 @@
# Makefile for Sphinx documentation
#
# You can set these variables from the command line.
SPHINXOPTS =
SPHINXBUILD = sphinx-build
PAPER =
BUILDDIR = build
# Internal variables.
PAPEROPT_a4 = -D latex_paper_size=a4
PAPEROPT_letter = -D latex_paper_size=letter
ALLSPHINXOPTS = -d $(BUILDDIR)/doctrees $(PAPEROPT_$(PAPER)) $(SPHINXOPTS) source
# the i18n builder cannot share the environment and doctrees with the others
I18NSPHINXOPTS = $(PAPEROPT_$(PAPER)) $(SPHINXOPTS) source
.PHONY: help clean html dirhtml singlehtml pickle json htmlhelp qthelp devhelp epub latex latexpdf text man changes linkcheck doctest gettext
help:
@echo "Please use \`make <target>' where <target> is one of"
@echo " html to make standalone HTML files"
@echo " dirhtml to make HTML files named index.html in directories"
@echo " singlehtml to make a single large HTML file"
@echo " pickle to make pickle files"
@echo " json to make JSON files"
@echo " htmlhelp to make HTML files and a HTML help project"
@echo " qthelp to make HTML files and a qthelp project"
@echo " devhelp to make HTML files and a Devhelp project"
@echo " epub to make an epub"
@echo " latex to make LaTeX files, you can set PAPER=a4 or PAPER=letter"
@echo " latexpdf to make LaTeX files and run them through pdflatex"
@echo " text to make text files"
@echo " man to make manual pages"
@echo " texinfo to make Texinfo files"
@echo " info to make Texinfo files and run them through makeinfo"
@echo " gettext to make PO message catalogs"
@echo " changes to make an overview of all changed/added/deprecated items"
@echo " linkcheck to check all external links for integrity"
@echo " doctest to run all doctests embedded in the documentation (if enabled)"
@echo " wadl to build a WADL file for api.openstack.org"
clean:
-rm -rf $(BUILDDIR)/*
html: check-dependencies
$(SPHINXBUILD) -b html $(ALLSPHINXOPTS) $(BUILDDIR)/html
@echo
@echo "Build finished. The HTML pages are in $(BUILDDIR)/html."
.PHONY: check-dependencies
check-dependencies:
@python -c 'import sphinxcontrib.autohttp.flask' >/dev/null 2>&1 || (echo "ERROR: Missing Sphinx dependencies. Run: pip install sphinxcontrib-httpdomain" && exit 1)
wadl:
$(SPHINXBUILD) -b docbook $(ALLSPHINXOPTS) $(BUILDDIR)/wadl
@echo
@echo "Build finished. The WADL pages are in $(BUILDDIR)/wadl."
dirhtml:
$(SPHINXBUILD) -b dirhtml $(ALLSPHINXOPTS) $(BUILDDIR)/dirhtml
@echo
@echo "Build finished. The HTML pages are in $(BUILDDIR)/dirhtml."
singlehtml:
$(SPHINXBUILD) -b singlehtml $(ALLSPHINXOPTS) $(BUILDDIR)/singlehtml
@echo
@echo "Build finished. The HTML page is in $(BUILDDIR)/singlehtml."
pickle:
$(SPHINXBUILD) -b pickle $(ALLSPHINXOPTS) $(BUILDDIR)/pickle
@echo
@echo "Build finished; now you can process the pickle files."
json:
$(SPHINXBUILD) -b json $(ALLSPHINXOPTS) $(BUILDDIR)/json
@echo
@echo "Build finished; now you can process the JSON files."
htmlhelp:
$(SPHINXBUILD) -b htmlhelp $(ALLSPHINXOPTS) $(BUILDDIR)/htmlhelp
@echo
@echo "Build finished; now you can run HTML Help Workshop with the" \
".hhp project file in $(BUILDDIR)/htmlhelp."
qthelp:
$(SPHINXBUILD) -b qthelp $(ALLSPHINXOPTS) $(BUILDDIR)/qthelp
@echo
@echo "Build finished; now you can run "qcollectiongenerator" with the" \
".qhcp project file in $(BUILDDIR)/qthelp, like this:"
@echo "# qcollectiongenerator $(BUILDDIR)/qthelp/Ceilometer.qhcp"
@echo "To view the help file:"
@echo "# assistant -collectionFile $(BUILDDIR)/qthelp/Ceilometer.qhc"
devhelp:
$(SPHINXBUILD) -b devhelp $(ALLSPHINXOPTS) $(BUILDDIR)/devhelp
@echo
@echo "Build finished."
@echo "To view the help file:"
@echo "# mkdir -p $$HOME/.local/share/devhelp/Ceilometer"
@echo "# ln -s $(BUILDDIR)/devhelp $$HOME/.local/share/devhelp/Ceilometer"
@echo "# devhelp"
epub:
$(SPHINXBUILD) -b epub $(ALLSPHINXOPTS) $(BUILDDIR)/epub
@echo
@echo "Build finished. The epub file is in $(BUILDDIR)/epub."
latex:
$(SPHINXBUILD) -b latex $(ALLSPHINXOPTS) $(BUILDDIR)/latex
@echo
@echo "Build finished; the LaTeX files are in $(BUILDDIR)/latex."
@echo "Run \`make' in that directory to run these through (pdf)latex" \
"(use \`make latexpdf' here to do that automatically)."
latexpdf:
$(SPHINXBUILD) -b latex $(ALLSPHINXOPTS) $(BUILDDIR)/latex
@echo "Running LaTeX files through pdflatex..."
$(MAKE) -C $(BUILDDIR)/latex all-pdf
@echo "pdflatex finished; the PDF files are in $(BUILDDIR)/latex."
text:
$(SPHINXBUILD) -b text $(ALLSPHINXOPTS) $(BUILDDIR)/text
@echo
@echo "Build finished. The text files are in $(BUILDDIR)/text."
man:
$(SPHINXBUILD) -b man $(ALLSPHINXOPTS) $(BUILDDIR)/man
@echo
@echo "Build finished. The manual pages are in $(BUILDDIR)/man."
texinfo:
$(SPHINXBUILD) -b texinfo $(ALLSPHINXOPTS) $(BUILDDIR)/texinfo
@echo
@echo "Build finished. The Texinfo files are in $(BUILDDIR)/texinfo."
@echo "Run \`make' in that directory to run these through makeinfo" \
"(use \`make info' here to do that automatically)."
info:
$(SPHINXBUILD) -b texinfo $(ALLSPHINXOPTS) $(BUILDDIR)/texinfo
@echo "Running Texinfo files through makeinfo..."
make -C $(BUILDDIR)/texinfo info
@echo "makeinfo finished; the Info files are in $(BUILDDIR)/texinfo."
gettext:
$(SPHINXBUILD) -b gettext $(I18NSPHINXOPTS) $(BUILDDIR)/locale
@echo
@echo "Build finished. The message catalogs are in $(BUILDDIR)/locale."
changes:
$(SPHINXBUILD) -b changes $(ALLSPHINXOPTS) $(BUILDDIR)/changes
@echo
@echo "The overview file is in $(BUILDDIR)/changes."
linkcheck:
$(SPHINXBUILD) -b linkcheck $(ALLSPHINXOPTS) $(BUILDDIR)/linkcheck
@echo
@echo "Link check complete; look for any errors in the above output " \
"or in $(BUILDDIR)/linkcheck/output.txt."
doctest:
$(SPHINXBUILD) -b doctest $(ALLSPHINXOPTS) $(BUILDDIR)/doctest
@echo "Testing of doctests in the sources finished, look at the " \
"results in $(BUILDDIR)/doctest/output.txt."

207
doc/source/conf.py
View File

@ -1,207 +0,0 @@
# -*- coding: utf-8 -*-
import datetime
# 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.todo',
'openstackdocstheme'
]
todo_include_todos = True
# The master toctree document.
master_doc = 'index'
# General information about the project.
project = u'OpenStack Chef Specs'
copyright = u'%s, OpenStack Chef Team' % datetime.date.today().year
openstackdocs_repo_name = 'openstack/openstack-chef-specs'
openstackdocs_auto_name = False
openstackdocs_bug_project = 'openstack-chef'
openstackdocs_bug_tag = u'specs'
# 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',
'**template.rst']
# The reST default role (used for this markup: `text`) to use for all documents.
#default_role = None
# If true, '()' will be appended to :func: etc. cross-reference text.
#add_function_parentheses = True
# If true, the current module name will be prepended to all description
# unit titles (such as .. function::).
add_module_names = False
# If true, sectionauthor and moduleauthor directives will be shown in the
# output. They are ignored by default.
show_authors = False
# The name of the Pygments (syntax highlighting) style to use.
pygments_style = 'native'
# A list of ignored prefixes for module index sorting.
modindex_common_prefix = ['openstack-chef-specs.']
version = ''
release = ''
# -- 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 = 'openstackdocs'
# 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 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 = 'OpenStack-Chef-Specsdoc'
# -- Options for LaTeX output --------------------------------------------------
latex_elements = {
# The paper size ('letterpaper' or 'a4paper').
#'papersize': 'letterpaper',
# The font size ('10pt', '11pt' or '12pt').
#'pointsize': '10pt',
# Additional stuff for the LaTeX preamble.
#'preamble': '',
}
# Grouping the document tree into LaTeX files. List of tuples
# (source start file, target name, title, author, documentclass [howto/manual]).
latex_documents = [
('index', 'OpenStack-Chef-specs.tex', u'OpenStack Chef Specs',
u'OpenStack Chef 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', 'OpenStack-Chef-specs', u'OpenStack Chef Design Specs',
u'OpenStack Chef Team', 'openstack-chef-specs',
'Design specifications for the OpenStack Chef 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'

47
doc/source/index.rst
View File

@ -1,47 +0,0 @@
.. openstack-chef-specs documentation master file
=============================================
Specifications for the OpenStack Chef Project
=============================================
Ocata approved specs
====================
.. toctree::
:glob:
:maxdepth: 1
specs/ocata/**
Liberty approved specs
======================
.. toctree::
:glob:
:maxdepth: 1
specs/liberty/**
Kilo approved specs
===================
.. toctree::
:glob:
:maxdepth: 1
specs/kilo/**
Juno approved specs
===================
.. toctree::
:glob:
:maxdepth: 1
specs/juno/**
==================
Indices and tables
==================
* :ref:`search`

1
doc/source/specs
View File

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

5
requirements.txt
View File

@ -1,5 +0,0 @@
openstackdocstheme>=2.2.1 # Apache-2.0
pbr>=2.0
sphinx>=2.0.0,!=2.1.0 # BSD
testrepository>=0.0.18
testtools>=0.9.34

12
setup.cfg
View File

@ -1,12 +0,0 @@
[metadata]
name = openstack-chef-specs
summary = Chef for OpenStack Project Development Specs
description-file =
README.rst
author = OpenStack
author-email = openstack-discuss@lists.openstack.org
home-page = http://specs.openstack.org/openstack/openstack-chef-specs/
classifier =
Intended Audience :: Developers
License :: OSI Approved :: Apache Software License
Operating System :: POSIX :: Linux

22
setup.py
View File

@ -1,22 +0,0 @@
#!/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)

0
specs/icehouse/.gitignore vendored
View File

0
specs/icehouse/block-storage/.gitignore vendored
View File

0
specs/icehouse/ceph/.gitignore vendored
View File

0
specs/icehouse/client/.gitignore vendored
View File

0
specs/icehouse/common/.gitignore vendored
View File

0
specs/icehouse/compute/.gitignore vendored
View File

0
specs/icehouse/cookbook-openstack-integration-test/.gitignore vendored
View File

0
specs/icehouse/dashboard/.gitignore vendored
View File

0
specs/icehouse/data-processing/.gitignore vendored
View File

0
specs/icehouse/database/.gitignore vendored
View File

0
specs/icehouse/identity/.gitignore vendored
View File

0
specs/icehouse/image/.gitignore vendored
View File

0
specs/icehouse/metering/.gitignore vendored
View File

0
specs/icehouse/network/.gitignore vendored
View File

0
specs/icehouse/object-storage/.gitignore vendored
View File

0
specs/icehouse/openstack-manuals/.gitignore vendored
View File

0
specs/icehouse/orchestration/.gitignore vendored
View File

0
specs/juno/.gitignore vendored
View File

0
specs/juno/block-storage/.gitignore vendored
View File

0
specs/juno/ceph/.gitignore vendored
View File

0
specs/juno/client/.gitignore vendored
View File

0
specs/juno/common/.gitignore vendored
View File

116
specs/juno/common/bump-chef-to-11-16.rst
View File

@ -1,116 +0,0 @@
..
This work is licensed under a Creative Commons Attribution 3.0 Unported
License.
http://creativecommons.org/licenses/by/3.0/legalcode
==========================================
Bump Chef gem to 11.16
==========================================
Launchpad blueprint:
https://blueprints.launchpad.net/openstack-chef/+spec/bump-chef-to-11-16
Propose to update all the cookbooks at master branch to use Chef 11.16.
The current version is at 11.12.
Problem description
===================
A detailed description of the problem:
* During each Master branch cycle, we need to keep it up to date with the latest tooling.
Proposed change
===============
Change all the cookbook Gemfile's to use Chef 11.16
Alternatives
------------
none
Data model impact
-----------------
none
REST API impact
---------------
none
Security impact
---------------
none
Notifications impact
--------------------
none
Other end user impact
---------------------
none
Performance Impact
------------------
Should help improve performance as there have been many fixes, for example:
Other deployer impact
---------------------
none
Developer impact
----------------
The current bundle install command will take care of updating
Chef to the required 11.16 version level. No additional steps
should be needed by the developers.
Implementation
==============
Assignee(s)
-----------
Primary assignee:
Mark Vanderwiel (vanderwl)
Other contributors:
none
Work Items
----------
* Each cookbooks Gemfile needs to specific Chef 11.16
Dependencies
============
none
Testing
=======
Basic testing (unit, lint, style, all-in-one) using Chef 11.16 has been done and no issues were found.
Documentation Impact
====================
none
References
==========
* `Chef versions <https://rubygems.org/gems/chef/versions>`_
* `Chef change log <https://github.com/opscode/chef/blob/master/CHANGELOG.md>`_

200
specs/juno/common/cookbook-versioning.rst
View File

@ -1,200 +0,0 @@
..
This work is licensed under a Creative Commons Attribution 3.0 Unported
License.
http://creativecommons.org/licenses/by/3.0/legalcode
==========================================
OpenStack Cookbook Versioning scheme
==========================================
Include the URL of your launchpad blueprint:
https://blueprints.launchpad.net/openstack-chef/+spec/example
There has been multiple threads on the way that cookbook versioning is done.
This doc is to attempt to consolidate and organize and ideally agree upon some
guidelines on the way to bump/change work on the versioning for
`the cookbooks <https://github.com/stackforge/cookbook-openstack-common>`_ for
instance the common cookbook.
Problem description
===================
There is no standardization on the cookbook versioning we have. This doc is the
attempt to give some general guidelines to fix this.
Proposed change
===============
General Guidelines
------------------
When submitting cookbook patches, it is generally required that the version
number (within metadata.rb) is incremented in a manor reflective of the level
of the change. Any patch should also update the CHANGELOG.md and if appropriate
the README.md should reflect the changes and any relevant how-to instructions. The
CHANGELOG.md is our executive summary of changes, it should inform what the change
was in a quick manner.
There are some differences between the development of patches on the Master and
Stable branches. There is more restrictive and vigorous oversight given to changes
on the Stable branches. The Master branch is bleeding edge and can relax the
version requirement in some simple cases to allow for increased productivity.
Semantic Versioning
-------------------
The cookbooks use the Semantic Versioning system (see http://semver.org)
The system uses a three part version number, Major.Minor.Patch.
For example: 9.2.33
The Major number shouldn't change within a development branch. It will reflect the
number that is the Alphabetized Letter of the base OpenStack release,
see: https://wiki.openstack.org/wiki/Releases. An example would be Icehouse
being the 9th letter and the 9th release all the stable cookbooks would be 9.Y.Z.
When the Master branch becomes stabilized, a new Stable branch will be created from
it and the Major number in the Master will be incremented by the core team.
The Minor and Patch numbers will be incremented as described in the branch specific
sections below.
Stable Branch
-------------
The Stable branch cookbooks must leverage the Semantic Versioning system exclusively.
All patches must update the metadata.rb and the CHANGELOG.md at a minimum.
All patches should try to be backwards compatible.
+-------------------------------------------------------------------------+-----------------+
| Stable Branch Example Situations | Level of Change |
+=========================================================================+=================+
| add a recipe | Increment Minor |
+-------------------------------------------------------------------------+-----------------+
| add a function or method | Increment Minor |
+-------------------------------------------------------------------------+-----------------+
| change Gemfile or Berksfile | Increment Minor |
+-------------------------------------------------------------------------+-----------------+
| backport a fix from Master branch | Increment Minor |
+-------------------------------------------------------------------------+-----------------+
| add attribute for a value in a configuration file with the same default | Increment Patch |
+-------------------------------------------------------------------------+-----------------+
| changing a resource option | Increment Patch |
+-------------------------------------------------------------------------+-----------------+
| add a test | Increment Patch |
+-------------------------------------------------------------------------+-----------------+
| fix a broken recipe | Increment Patch |
+-------------------------------------------------------------------------+-----------------+
| re-factoring recipe or test | Increment Patch |
+-------------------------------------------------------------------------+-----------------+
The table above shows some examples of different levels of changes introduced by a patch and
what part of the version number to increment for Stable branches.
Version Locking
^^^^^^^^^^^^^^^
The Stable branches are also locked down by added Berksfile.lock and Gemfile.lock to each
cookbook. If any changes are made to the Gemfile, the Gemfile.lock would also have to be
updated. If any changes are dependent upon other cookbook changes, then the Berkfile.lock
and metadata.rb files would need to be updated accordingly.
Cookbook Dependencies
^^^^^^^^^^^^^^^^^^^^^
When a change requires hits to multiple cookbooks, like when adding attributes to Common, the
metadata.rb file would need to be updated to reflect that required version level. The
Berksfile.lock would also need to be updated with the commit id of the dependent change.
Master Branch
-------------
The master cookbook should leverage the Semantic Versioning system lightly.
We consider the master branch a fast paced "Work in Progress" until we come to the Release
Candidate 1 date (RC-1). This means it will be under rapid and active development where
versioning isn't always required.
All patches must update the CHANGELOG.md at a minimum.
+-------------------------------------------------------------------------+------------------+
| Master Branch Example Situations | Level of Change |
+=========================================================================+==================+
| Branching for a new Stable branch | Increment Major |
+-------------------------------------------------------------------------+------------------+
| add a recipe | Increment Minor |
+-------------------------------------------------------------------------+------------------+
| add a function or method | Increment Minor |
+-------------------------------------------------------------------------+------------------+
| change Gemfile or Berksfile | Increment Minor |
+-------------------------------------------------------------------------+------------------+
| add attribute for a value in a configuration file with the same default | Increment Patch**|
+-------------------------------------------------------------------------+------------------+
| changing a resource option | Increment Patch**|
+-------------------------------------------------------------------------+------------------+
| add a test | Increment Patch**|
+-------------------------------------------------------------------------+------------------+
| fix a broken recipe | Increment Patch**|
+-------------------------------------------------------------------------+------------------+
| re-factoring recipe or test | Increment Patch**|
+-------------------------------------------------------------------------+------------------+
The table above shows some examples of different levels of changes introduced by a patch and
what part of the version number to increment for Master branches.
** There are cases where incrementing the Patch number is not necessary and only updating the
CHANGELOG.md is required. To avoid re-base collisions on Patch number changes and allow more
rapid development, if the change falls within these guidelines, incrementing the Patch version
would not be required.
- When the change only effects a single cookbook
- When the change is just a simple addition of a new attribute for a template and no other
logic change is required
- When a patch only effects the tests
- When a patch only effect the README or other comments
Version Locking
^^^^^^^^^^^^^^^
The Master branch is NOT locked down a Berksfile.lock or Gemfile.lock. Changes to the Berksfile
and Gemfile can be made directly.
Cookbook Dependencies
^^^^^^^^^^^^^^^^^^^^^
When a change requires hits to multiple cookbooks, like when adding attributes to Common, the
metadata.rb file would need to be updated to reflect that required version level.
Implementation
==============
Assignee(s)
-----------
Everyone because this is an over arching process ;)
Work Items
----------
None.
Dependencies
============
None, apart from the community approving these guide lines.
Testing
=======
None.
Documentation Impact
====================
See above, this should also be put on the wiki too.
References
==========
This `youtube video <http://youtu.be/jA9L_g-d-X4>`_ is the major discussion
about this topic. There has also been multiple comments on the google group.

178
specs/juno/common/no-secret-attributes.rst
View File

@ -1,178 +0,0 @@
=================================================
Keep sensitive information out of node attributes
=================================================
https://blueprints.launchpad.net/openstack-chef/+spec/no-secret-attributes
Sensitive information such as passwords should not be stored as node
attributes, because they are persisted back to the server and can therefore
be easily retrieved.
Problem description
===================
Wrapped recipes (e.g. mysql::server) use node attributes for retrieving
sensitive information, such as passwords associated with privileged
accounts. This type of information is specified via items in encrypted
data bags, but because node attributes are involved, the security provided
by the encryption mechanism can easily be defeated by simply retrieving the
node attributes from the server.
For example (from mysql-server):
::
if node['openstack']['db']['root_user_use_databag']
super_password = get_password 'user', node['openstack']['db']['root_user_key']
node.set_unless['mysql']['server_root_password'] = super_password
else
super_password = node['mysql']['server_root_password']
end
The password is retrieved from a (possibly encrypted) data bag and stored
into a node attribute to be consumed downstream by the :code:`server`
recipe in the :code:`mysql` cookbook. After the node is converged, all
someone needs to do to retrieve the password as clear text is execute
:code:`knife node edit NODE_NAME`, thereby defeating a data bag's encryption
capabilities.
Proposed change
===============
The proposed solution is to operate on server resources directly or use
run_state to set passwords, depending on which is available for use in
a given recipe.
Again, using MySQL as an example (operating directly on resource):
::
if node['openstack']['db']['root_user_use_databag']
super_password = get_password 'user', node['openstack']['db']['root_user_key']
else
super_password = node['mysql']['server_root_password']
end
mysql_service node['mysql']['service_name'] do
server_root_password super_password
...
end
The password is stored only in a local variable and directly assigned to the
:code:`mysql_service` resource's :code:`server_root_password` attribute.
The :code:`mysql::server` recipe is not invoked and all of the other resource
attributes are set directly as well (indicated via :code:`...`). Since the
password is never stored as a node attribute, it cannot be retrieved via
:code:`knife node edit NODE_NAME`. Note that other resource attributes (for
instance :code:`port`) can still be set to node-attribute values and thus
their default values can still be specified in :code:`attributes/default.rb`.
Also note that the above example shows that a node attribute can still be
used to store password information, if that is what the user wants to do.
This is done by leaving the :code:`['openstack']['db']['root_user_use_databag']`
set to its default value of :code:`false`.
Alternatives
------------
One alternative would be to have the wrapped recipes fall back to default
attribute values and set the resource attributes directly, as described at
https://sethvargo.com/changing-chef-resources-at-runtime/. However, this
is arguably a non-strategic workaround.
Data model impact
-----------------
none
REST API impact
---------------
none
Security impact
---------------
Security would be improved because passwords would no longer be accessible
as node attributes.
Notifications impact
--------------------
none
Other end user impact
---------------------
None. The recipes would be backward compatible because the mechanisms for
specifying the databag type (encrypted or standard) and name and related
node attributes needed to use data bags would remain unchanged. The only
thing changing would be the mechanics of how the data contained in data
bags is populated into the resources created by the recipes. Note that
end users would still have the option to not use data bags at all.
Performance Impact
------------------
none
Other deployer impact
---------------------
none
Developer impact
----------------
none
Implementation
==============
Assignee(s)
-----------
* jswarren
Work Items
----------
The known impacted recipes are:
* cookbook-openstack-ops-database::mysql-server
* cookbook-openstack-ops-database::postgresql-server
* cookbook-openstack-ops-messaging::rabbitmq-server
Dependencies
============
The cookbooks involved in setting up the resources in question need to
provide a mechanism for setting passwords either as a resource attribute
that can be set directly or as a run_state attribute. Other mechanisms
that do not expose passwords as node attributes should also be acceptable.
Testing
=======
The cookbooks in question would need to be tested to ensure that when
data bags are used to specify passwords that the password values are not
reflected in the attributes (if any) used for setting passwords. In other
words, a given referenced cookbook or recipe might still allow the use
of node attributes to set passwords in addition to the above-mentioned
possible alternatives. However, when node attributes are not used to
specify passwords, the passwords must then not be stored as node
attributes by the referenced recipes.
Documentation Impact
====================
Documentation should not change, since the blackbox behavior of the recipes
should remain unchanged. The documentation associated with the referenced
resource recipes may need to change when accommodations are made for
alternative means of setting passwords, but those changes are orthogonal to
the work described here.
References
==========

0
specs/juno/compute/.gitignore vendored
View File

0
specs/juno/cookbook-openstack-integration-test/.gitignore vendored
View File

0
specs/juno/dashboard/.gitignore vendored
View File

0
specs/juno/data-processing/.gitignore vendored
View File

0
specs/juno/database/.gitignore vendored
View File

0
specs/juno/identity/.gitignore vendored
View File

0
specs/juno/image/.gitignore vendored
View File

0
specs/juno/metering/.gitignore vendored
View File

0
specs/juno/network/.gitignore vendored
View File

176
specs/juno/network/neutron-vpnaas-enablement.rst
View File

@ -1,176 +0,0 @@
=============================
Enable Neutron VPN as Service
=============================
Include the URL of your launchpad blueprint:
https://blueprints.launchpad.net/openstack-chef/+spec/neutron-vpnaas-enablement
Problem description
===================
VPN service is a key feature provided by Neutron to enable Secured Private
connection to OpenStack cloud. The reference VPN implementation in Neutron at
this time is [IPSec]_ VPN, and the IPSec driver is [OPENSWAN]_.
Currently, there is no Chef cookbook support to configure and start Neutron
VPN service.
Proposed change
===============
Add a recipe, and related attribute/unit tests to cookbook-openstack-network
to install, configure and start VPN service.
The packages need to be installed are:
* Ubuntu: neutron-plugin-vpn-agent
* RedHat: openstack-neutron
* Suse: openstack-neutron-vpn-agent
The attributes need to be added includes:
* A new attribute to decide if VPN agent or L3 agent should be started::
['openstack']['network']['enable_vpn']
* New attributes for VPN configurations in /etc/neutron/vpn_agent.ini::
['openstack']['network']['vpn']['vpn_device_driver']
['openstack']['network']['vpn']['ipsec_status_check_interval']
The recipe will check if VPN service should be installed, configured and
started, then uses the attribute value to configure VPN agent configuration
file and start VPN service.
Alternatives
------------
No alternatives at this time.
Data model impact
-----------------
No Data model impact
REST API impact
---------------
No API change
Security impact
---------------
Right now only IKE with "PSK" (Pre-Shared Key) authentication mode is implemented
in Neutron VPNaaS for simplicity. And the psk is a input of IPsec site connection
establishment process.
For example, "secret" psk can be used in a new IPsec site connection::
neutron ipsec-site-connection-create --name vpnconnection1 --vpnservice-id myvpn
--ikepolicy-id ikepolicy1 --ipsecpolicy-id ipsecpolicy1 --peer-address 172.24.4.233
--peer-id 172.24.4.233 --peer-cidr 10.2.0.0/24 --psk secret
Since the authentication and key exchange are not in the scope of starting and
configuring VPN service, there should be no security impact of this Spec.
Notifications impact
--------------------
No notification impact
Other end user impact
---------------------
Performance Impact
------------------
Other deployer impact
---------------------
Developer impact
----------------
Implementation
==============
Assignee(s)
-----------
Primary assignee:
- gekun@cn.ibm.com
Work Items
----------
* Add a new attribute value to decide if VPN agent or L3 agent should be started,
since these two services cannot be started at the same time.
* Add new attributes for VPN configurations in /etc/neutron/vpn_agent.ini and
a new vpn template.
* Add a new recipe to install the VPN packages, configure the [VPN_TEMPLATE]_
and start VPN service
* Enable VPN support in Horizon [VPN_HORIZON]_
Configure /opt/stack/horizon/openstack_dashboard/local/local_settings.py::
OPENSTACK_NEUTRON_NETWORK = {
'enable_vpn': True,
}
* Add validations to ensure VPN service is up and running correctly.
* Add unit tests
* ref to ask openstack on this topic [HOW_TO_SETUP_VPN]_
Dependencies
============
Testing
=======
* Add unit tests for the new recipe.
* For function tests and CI integration tests, at least one node with three NICs is
recommanded. One NIC is used for external network connection, one NIC is used for
data network and the other is used for management network.
Documentation Impact
====================
* Configure attribute ['openstack']['network']['enable_vpn'] = 'True'
to enable VPN service.
* Configure VPN related attributes, for example::
['openstack']['network']['vpn']['vpn_device_driver'] =
neutron.services.vpn.device_drivers.ipsec.OpenSwanDriver
['openstack']['network']['vpn']['ipsec_status_check_interval'] = 60
References
==========
.. [IPSec] `Security Architecture for the Internet Protocol RFC
<http://tools.ietf.org/html/rfc4301>`_
.. [OPENSWAN] `OpenSwan website
<https://www.openswan.org>`_
.. [VPN_TEMPLATE] `VPN template values
<https://docs.openstack.org/trunk/config-reference/content/networking-options-vpn.html>`_
.. [VPN_HORIZON] `VPN support in Horizon <https://review.openstack.org/#/c/108493/1>`_
.. [HOW_TO_SETUP_VPN] `How to setup VPNaaS
<https://ask.openstack.org/en/question/6243/how-to-set-up-neutron-vpn-service-vpnaas/>`_

0
specs/juno/object-storage/.gitignore vendored
View File

0
specs/juno/openstack-manuals/.gitignore vendored
View File

0
specs/juno/orchestration/.gitignore vendored
View File

201
specs/kilo/bare-metal/bare-metal-enablement.rst
View File

@ -1,201 +0,0 @@
==========================================
Enable Bare Metal Service by Chef
==========================================
Include the URL of your launchpad blueprint:
https://blueprints.launchpad.net/openstack-chef/+spec/bare-metal-enablement
OpenStack Bare Metal Service known as Ironic OpenStack project name provisions
Bare Metal machines by leveraging common technologies such as [PXE]_ boot and
[IPMI]_ to cover a wide range of hardware.
Problem description
===================
* OpenStack Bare Metal Service was available as an incubated project in the
"Icehouse" release, with many stability and feature improvements in the
"Juno", it is officially integrated with OpenStack beginning with the "Kilo"
release.
* Currently, there is no Chef cookbook support to install and configure
OpenStack Bare Metal Service.
Proposed change
===============
Add a cookbook included recipes and related attributes/unit tests to install
and configure OpenStack Bare Metal Service.
The packages which need to be installed include:
* Fedora/RHEL: openstack-ironic-api, openstack-ironic-conductor,
openstack-ironic-common and python-ironicclient.
For PXE: tftp-server and syslinux-tftpboot.
For IMPI: ipmitool.
* Ubuntu: ironic-api, ironic-conductor and python-ironicclient.
For PXE: tftpd-hpa, syslinux and syslinux-common.
For IMPI: ipmitool.
Alternatives
------------
None
Data model impact
-----------------
None
REST API impact
---------------
Refer to [REST_API_V1]_ for details.
Security impact
---------------
* Authentication method to use when connecting to OpenStack other components is
keystone with PKI as well as others.
* Allow ironicclient to preform "secure" SSL (https) requests, the SSL/TLS
versions TLSv1.2. TLSv1.0 and TLSv1.1 are only recommended, but the
certificates and key exchange are not in the scope of enabling Bare Metal
Service.
* Hash algorithms to use for hashing PKI tokens include md5, etc.
* The commands which require the use of sudo are:
qemu-img
iscsiadm
blkid
blockdev
mkswap
mkfs
mount
umount
dd
fuser
parted
* About resource exhaustion attack, there is no security impact of this Spec.
Notifications impact
--------------------
None
Other end user impact
---------------------
None
Performance Impact
------------------
None
Other deployer impact
---------------------
None
Developer impact
----------------
None
Implementation
==============
Assignee(s)
-----------
Primary assignee:
- wenchma@cn.ibm.com
Other contributors:
- None
Work Items
----------
* Add a basic cookbook with the default files for getting through first gate
.gitignore
.gitreview
.rubocop.yml
Berksfile
CONTRIBUTING.md
Gemfile
metadata.md
Rakefile
README.md
TESTING.md
/spec/spec_helper.rb
* Add the default attribute file to determine Bare Metal Service configuration
items.
* Add the recipe files to install the packages of Bare Metal Service,
configure the [BARE_METAL_TEMPLATE]_ and start Bare Metal services.
* Add the template files to enable Bare Metal Service to be configurable.
* Add the unit tests.
Dependencies
============
* Ironic requires the supported Bare Metal hardwares, such as x68 servers,
HP iLO, and Intel AMT platforms so far.
* This requires the supported platform operating systems, such as Fedora,
RHEL and Ubuntu.
* This depends on the blueprint [BARE_METAL_ENABLEMENT]_
* This requires configuring the Bare Metal Service's driver for Compute Service.
* This requires the setup of supported boot mode, such as [PXE]_ and [IPMI]_.
Testing
=======
* Add unit tests for the recipes.
* For function and CI integration test, at least one node with OpenStack
all-in-one deployment is recommended.
Documentation Impact
====================
* Add README.md.
References
==========
.. [BARE_METAL_TEMPLATE] `Bare Metal Template values
<https://docs.openstack.org/trunk/config-reference/content/ch_configuring-openstack-bare-metal.html>`_
.. [BARE_METAL_ENABLEMENT] `Bare Metal enablement blueprint
<https://blueprints.launchpad.net/openstack-chef/+spec/bare-metal-enablement>`_
.. [IPMI] `IPMI tool source code
<http://ipmitool.sourceforge.net/>`_
.. [PXE] `PXE user guide
<https://docs.openstack.org/developer/ironic/deploy/user-guide.html#pxe>`_
.. [REST_API_V1] `Bare Metal RESTful Web API v1
<https://docs.openstack.org/developer/ironic/webapi/v1.html>`_
`Bare Metal Service Installation Guide
<https://docs.openstack.org/developer/ironic/deploy/install-guide.html>`_

155
specs/kilo/network/enable-dvr-in-chef-cookbook.rst
View File

@ -1,155 +0,0 @@
=======================================================
Enable Distributed Virtual Router(DVR) in chef cookbook
=======================================================
Include the URL of your launchpad blueprint:
https://blueprints.launchpad.net/openstack-chef/+spec/enable-dvr-chef-cookbook
Problem description
===================
Currently DVR is disabled by default in Neutron and not allowed to be
configured in Network cookbook. After deployed, user has to manually modify
the Neutron configuration files to enable DVR.
Proposed change
===============
The following attribute file in cookbook-openstack-network will be modified:
* default.rb
We will add attribute ['openstack']['network']['router_distributed'] in it.
User can set this attribute to 'auto', true and false. When this attribute is
set to 'auto', chef cookbook will do enough check, like checking whether
network type ML2 extensions support DVR, checking whether OVS is enabled,
after that chef cookbook will enable DVR or output warning messages and logs
to tell user what happened. And considering only GRE and VXLAN network types
support DVR, router_distributed's true and false setting will only work in
the two network types. To VLAN network type, DVR will be disabled by default
even router_distributed is set to true, warning messages will be given to
user to notify why DVR config doesn't work.
The following template files in cookbook-openstack-network will be modified:
* neutron.conf.erb
* l3_agent.ini.erb
* ovs_neutron_plugin.ini.erb
* ml2_conf.ini.erb
Modify attribute 'router_distributed' in neutron.conf.erb, 'agent_mode' in
l3_agent.ini.erb, 'enable_distributed_routing' and 'l2_population' in
ovs_neutron_plugin.ini.erb, 'mechanism_drivers' in ml2_conf.ini.erb. These
attributes can be found in the howto link in the following References section.
The following recipe files in cookbook-openstack-network may be modified:
* l3_agent.rb
DVR gives a new data path for vms, like East-West communication, give
compute nodes external IPs to make vms can get floating IPs not only from
network nodes. And DVR will only work on nodes which has L3 agent and OVS
agent, and these will installed for network node role and compute node role.
l3_agent.ini.erb will need query the current node is compute node or network
node when DVR is enabled. We will use existing network node role and compute
node role to deal with that. If a node have both the two roles, we will
consider this node as network node.
If necessary we also need methods to make sure necessary packages
like iproute are installed on compute node.
DVR is supported by network type GRE and VXLAN, but not VLAN yet, so
we also need a method to make sure the current network type is either GRE
or VXLAN, the network type need maps to key name tunnel_types in
ovs_neutron_plugin.ini with values of gre or vxlan. If current network type
is VLAN, we should stop the configuration of DVR. And we also need methods
to make sure necessary
network resource like tunnel network bridge are created on compute node.
If necessary we will change the role definition for compute node.
We did test and enabled DVR on Redhat and Ubuntu, but not all versions have
been tested. So in cookbook, we will deal with details from different
platforms and releases affected and output warning messages and logs to OS
we will not support.
Alternatives
------------
Another option to case that DVR is enabled while tunnel_types is vlan,
is that we can cover that value by gre or vxlan for tunnel_type in
ovs_neutron_plugin.ini. Consider that if user decides to enable DVR,
user can accept changing in openvswitch agent config file.
Data model impact
-----------------
REST API impact
---------------
Implementation
==============
Assignee(s)
-----------
Primary assignee:
<lzklibj@cn.ibm.com>
Other contributors:
Work Items
----------
Dependencies
============
Testing
=======
Add attribute 'router_distributed' => 'true' in environment file,
then deploy a 1+N environment or a multiple network nodes environment.
(All-in-one case is unnecessary, we can consider it similar to 1+0 case)
Check if config files are modified according to the list in the wiki Neutron
DVR HowTo page.
Build network N1 and N2, router R1, add subnets of N1 and N2 to R1 as
interfaces, before booting any instances, we should see nothing listed in the
output when running "ip netns" on the compute nodes. Boot instances on N1 and
N2 on different compute nodes, we should see network namespace on those compute
nodes by running "ip netns".
ip-netns is process network namespace management command. You can run
"ip netns help" to get more usage. And "ip netns" is short for
"ip netns list", it will show all of the named network namespaces, which
are under /var/run/netns.
Also, we can ping from vm to vm while checking output by running tcpdump
from compute nodes. If we boot vm1 on N1 on CN1(compute node 1), and vm2
on N2 on CN2, after we logon vm1(it doesn't matter we logon from network
node or CN1), we can ping vm2 and run 'tcpdump | grep -i "X"' on CN1 or CN2,
while "X" is your network type, we will find ICMP packages data path is
directly from CN1 to CN2, without passing network nodes (in a 1+N case, ICMP
packages will need centralized network node to transmit when DVR is disabled).
Documentation Impact
====================
* User can set ['openstack']['network']['router_distributed'] to 'auto' to
let chef cookbook configure for DVR aumotically, enable DVR or give warning
messages.
* DVR will be enabled by default when network type is GRE or VXLAN,
user can set ['openstack']['network']['router_distributed]' to 'false'
in override_attributes to disable it.
* When set ['openstack']['network']['router_distributed'] to 'true', user
should check follow attributes to enable DVR: check ['openstack']['network']
['core_plugin'] has value 'neutron.plugins.ml2.plugin.ML2Plugin', check
['openstack']['network']['ml2']['mechanism_drivers'] has value 'openvswitch'
and check ['openstack']['compute']['network']['plugins'] has value
'openvswitch'.
References
==========
<https://wiki.openstack.org/wiki/Neutron/DVR>
<https://wiki.openstack.org/wiki/Neutron/DVR/HowTo>

170
specs/kilo/openstack-docker/openstack-docker.rst
View File

@ -1,170 +0,0 @@
=================================================
Configure openstack services with docker support
=================================================
Include the URL of your launchpad blueprint:
https://blueprints.launchpad.net/openstack-chef/+spec/docker-driver-configuration
The Docker driver is a hypervisor driver for OpenStack Nova Compute. It was introduced with the Havana release.
Docker is an open-source engine which automates the deployment of applications as highly portable, self-sufficient
containers which are independent of hardware, language, framework, packaging system and hosting provider.
Refer [OPENSTACK_DOCKER_DOCUMENTATION]_.
This new change proposed will enable deployment and configuration of nova-docker driver, glance repo configuration
and any needed config to support seemless managment of docker nodes in openstack cloud.
Problem description
===================
* Currently, openstack-compute does not support nova-docker driver
* Currently, openstack-image does not support docker container formats
for images which includes docker and dockerref
* [OPENSTACK_DOCKER_COOKBOOK_OLD]_ is an available
option which is not maintained for last 2 years and it has embedded
2 years old driver.
Proposed change
===============
Add support in openstack-compute cookbook to configure [NOVA_DOCKER_DRIVER]_.
Current support will be to download the nova docker driver from git repo and configure.
Also change openstack-image to support container formats for docker images
which includes docker and dockerref
Alternatives
------------
None
Data model impact
-----------------
None
REST API impact
---------------
None
Security impact
---------------
None
Notifications impact
--------------------
None
Other end user impact
---------------------
None
Performance Impact
------------------
None
Other deployer impact
---------------------
None
Developer impact
----------------
None
Implementation
==============
Assignee(s)
-----------
Primary assignee:
- skairali@cn.ibm.com
Other contributors:
- ashish.billore1@in.ibm.com
Work Items
----------
* Add new attributes to openstack-compute
* Change openstack-compute / nova.conf.erb template for including nova-docker driver
* Add new recipe for docker configuration in openstack-compute
* Change compute.rb recipe in openstack-compute to include the new recipe based on configuration
* Add the unit tests.
* Change openstack-image and add new container formats in attributes
Dependencies
============
* In order to configure nova-docker driver - compute nodes should be pre installed with
docker runtime. Users can opt to use cookbook [CHEF_DOCKER]_
In case above cookbook does not support the OS where compute is getting configured
use doucmentation which is available at [DOCKER_RUNTIME_INSTALLATION]_.
* This depends on Nova Docker driver [NOVA_DOCKER_DRIVER]_.
Currently a git clone of above source in .zip format is required to complete nova configuration
Testing
=======
* Add unit tests for the recipes.
* For function and CI integration test, at least one node with OpenStack
all-in-one deployment is recommended.
* In order to configure a compute node as docker compute(while testing using openstack-chef-repo)
override the attribute to true using environment which indicates whether a node is docker type or not
* Prior to testing, install docker runtime to all compute nodes. Refer Dependencies for more details
Documentation Impact
====================
* Change README.md. in openstack-compute
References
==========
.. [CHEF_DOCKER] `Chef docker cookbook
<https://github.com/bflad/chef-docker>`_
.. [DOCKER_RUNTIME_INSTALLATION] `Docker runtime installation
<https://docs.docker.com/installation>`_
.. [NOVA_DOCKER_DRIVER] `Nova docker driver
<https://github.com/stackforge/nova-docker/tree/master>`_
.. [OPENSTACK_DOCKER_COOKBOOK_OLD] `OpenStack Docker cookbook old
<https://github.com/paulczar/cookbook-openstack-docker>`_
.. [OPENSTACK_DOCKER_DOCUMENTATION] `OpenStack Docker Documentation
<https://wiki.openstack.org/wiki/Docker>`_
Possible Future Enhancements
============================
Change openstack-telemetry cookbook to support monitoring of docker computes

232
specs/liberty/all/refactor_config_templates.rst
View File

@ -1,232 +0,0 @@
..
This work is licensed under a Creative Commons Attribution 3.0 Unported
License.
http://creativecommons.org/licenses/by/3.0/legalcode
=================================================
Refactor configuration templates in all cookbooks
=================================================
URL of launchpad blueprint:
https://blueprints.launchpad.net/openstack-chef/+spec/refactor-configuration-templates
Problem description
===================
Our templates for the configurations files for all services have grown through
the years and it is getting harder and harder to figure out where to set a
specific option that goes into the config files. The same is true for reading
these configuration files after they have been rendered, since they contain a
lot more options and code than actually needed or used. Additionally every time
one of the OpenStack service projects adds or removes an configuration option,
we manually need to add an attribute, some conditions and an entry in the
template for this. Same goes for every change in the defaults, that is either
not reflected at all in our config files, or set explicitly to the same thing,
which is just unneeded code after all. Finally, the fact that all of our
templates are quite big blocks of code and even contain some hardcoded values
for specific configuration options, which came from the original configuration
files imported years ago, does not help with keeping up with the multiple changes
in the service projects.
Proposed change
===============
The templates for OpenStack service configurations files should implement or use
a logic of setting the needed key-value configuration options in the appropriate
section automatically from properly defined chef attributes.
* logic to render proper configuration files needs to be defined and added
(example given below)
* attributes used for or in configurations templates need to be checked and
refactored to fit this logic
* commonly used configuration options should be handled in one place
* only needed configuration options should be set in the configuration files
after rendering the template
* configuration options that are specific to only a few setups should be removed
from the default attributes and recipes (especially the switchcases for them)
and moved to the documentation. Although this will mean to remove
functionality in the sense of removing some switchcases and attributes in the
original cookbooks, this should not mean to loose these completely, but rather
move them to the documentation to allow an easy implementation in wrapper
cookbooks.
Scope
-----
This spec tries to define a refactoring process that implements a more elegant
handling of template files for OpenStack service configurations throughout all
cookbooks used to deploy OpenStack.
End user impact
---------------
* Users of the cookbooks will be able to wrap all OpenStack chef cookbook more
easily and set configuration options if needed without patching the actual
templates.
* Old wrapper cookbooks before this change will stop working partially and
would need to be refactored accordingly. The same is true for all environment
files that include configuration options for the services via attributes.
* Reading configuration files will become a lot easier, since only specifically
wanted and needed options will be included in them.
* The user can add environment and company specific comments in the service
configuration files via attributes.
Developer impact
----------------
Cookbook developers will not need to add attributes for configuration templates,
nor should there be any need to change existing attributes to fit the changing
defaults in OpenStack service projects. It should become easier to read the
overall cookbook, since a big part of the code in the templates and attribute
files will be cut or moved with this feature. Therefore it might be easier to
contribute as a newcomer without spending hours to understand how all the
attributes work with each other (given that the logic used to render the
templates is easier to understand of course).
Implementation
==============
Assignee(s)
-----------
Primary assignee:
<j-klare>
Other contributors:
Work Items
----------
* define a generic structure for templates, that can be used for most of the
configuration files
* main config files for services look like this for all configuration
options:
[section]
# optional comment or description
key = value (usually simple boolean, numeric or string)
# optional comment or description
key = [ array which could be large ]
* create a logic to render configuration files from properly set chef attributes
* attributes could look like this for main configuration files (e.g. nova
or neutron.conf):
::
default['openstack'][service]['conf'][section][key] =
value
without a comment:
::
default['openstack'][service]['conf'][section]['debug'] =
true
with a comment:
::
default['openstack'][service]['conf'][section]['debug'] =
{ set_to: true, comment: 'this option is the switch to enable/disable debug loggging' }
cookbook-openstack-common/templates/common.conf.erb :
::
<% @service_config.each do |section, values| -%>
[<%= section %>]
<% values.each do |key, value| -%>
<% if value.class == Hash -%>
<%= "# {value['comment']}" -%>
<%= key %> = <%= value['set_to'] %>
<% else -%>
<%= key %> = <%= value %>
<% end -%>
<% end -%>
<% end -%>
cookbook-openstack-compute/recipes/common.rb :
::
...
# activesupport currently needs to be upgraded, since the one used in
# chef 12 is too old (3.2.19) and does not include the needed deep_merge
chef_gem 'activesupport' do
action :upgrade
version '4.2.4'
end
require 'active_support'
...
neutron_admin_password = get_password 'service', 'openstack-network'
identity_admin_endpoint = admin_endpoint 'identity-admin'
identity_uri = identity_uri_transform(identity_admin_endpoint)
...
secrets = {
neutron: {
admin_password: neutron_admin_password,
...
},
keystone_authtoken: {
identity_uri: identity_uri,
...
},
...
}
# merge node attributes with secrets like passwords etc. for
# usage in template['/etc/nova/nova.conf']
nova_config_options =
node['openstack']['compute']['conf'].deep_merge(secrets)
template '/etc/nova/nova.conf' do
source 'common.conf.erb'
cookbook 'openstack-common'
owner node['openstack']['compute']['user']
group node['openstack']['compute']['group']
mode 00640
variables(
service_config: nova_config_options
)
end
...
cookbook-openstack-compute/templates/nova.conf.erb -- not needed anymore
* add a link to documentation/config reference to all config files
* refactor currently used attributes to fit into that logic
* adapt specs
* define a set of minimal needed attributes to create a working stack and move
the rest of the attributes into documentation
* remove attributes that would set configuration options that are equal to the
defaults
* propagate not backward compatible change at a fitting point in time without
making a lot of people angry
Testing
=======
* lint and style tests with rubocop (as is)
* unit tests with chefspec with special focus on testing the proper rendering of
the configuration templates (including the sections)
* integration testing with chef provisioning
Documentation Impact
====================
These patches should move a good part of the currently defined attributes to the
documentation as examples for specific setups.
References
==========

164
specs/liberty/network/ip-address-movement-for-ovs-bridges.rst
View File

@ -1,164 +0,0 @@
===================================
IP address movement for ovs bridges
===================================
Include the URL of your launchpad blueprint:
https://blueprints.launchpad.net/openstack-chef/+spec/ip-movement
Problem description
===================
Neutron openvswitch plugin uses ovs bridges to manage network stream. Recipe
openvswitch, l3_agent, and vpn_agent use ovs commands to create those bridges
and will plug the corresponding NICs to each of them. But those recipes do not
move the NICs' IP addresses to the bridges, which will lead to the NIC IP address
can not be accessed once finish the bridges creation.
Proposed change
===============
Add recipes to move IP address from NIC to bridge. Make sure those IP addresses
can also be accessed after finish the bridge creation.
Three attributes will be added, including:
* ['openstack']['network']['ip_movement']['enable']: Boolean attribute to decide
whether IP movement should be enabled or not. Default to true.
* ['openstack']['network']['ip-movement']['timeout']: Integer attribute to decide
the timeout of IP movement. IP movement uses 'service network restart' (for fedora
platform) and 'ifdown', 'ifup' (for ubuntu platform) commands to let network
configurations take effect. This attribute decides how long the node should wait
for the network to become operational again after executing the previous commands.
And it default to 180.
* ['openstack']['network']['ip-movement']['validate-ip']: String of IP address pinged
by ip movement in the of its operations to check whether the ip movement is succeed.
Default to nil. Means this ip movement will use default gateway to check its status.
Two libraries will be added, including:
* ip-movement-fedora: This library includes the fedora platform IP movement configurations.
* ip-movement-ubuntu: This library includes the ubuntu platform IP movement configurations.
One resource will be added, including:
* ovs_bridge: This resource will create the ovs bridge and move the ip address to the
corresponding bridge depend on the resource attributes.
openvswitch and l3-agent recipes will changed to use this new resource create ovs bridge.
Alternatives
------------
Like devstack, using ovs commands and ip commands to flush the ip address in NIC,
and add ip address to ovs bridge can also move the ip address to the bridges. But
this is a temporary move. After network restart or reboot the OS, the ip address
will go back to NIC. We need make sure this movement is persistent by write those
configurations to network configuration files.
Data model impact
-----------------
None
REST API impact
---------------
None
Security impact
---------------
None
Notifications impact
--------------------
None
Other end user impact
---------------------
None
Performance Impact
------------------
None
Other deployer impact
---------------------
None
Implementation
==============
Assignee(s)
-----------
Primary assignee:
- hwhu@cn.ibm.com
Other contributors:
- jckasper@us.ibm.com
- lzklibj@cn.ibm.com
Work Items
----------
* Add new attributes to openstack-network.
* Add ovs_bridge resource and provider.
* Add ip-movement-fedora library to handle fedora platform IP movement configurations.
* Add ip-movement-ubuntu library to configure ubuntu platform IP movement configurations.
* Add the unit tests.
* Change openvswitch and l3-agent recipes use ovs_bridge resource to create ovs bridge.
Dependencies
============
* IP movement use 'service network restart' , 'ifdown' and 'ifup' to let network
configurations take effect. Those scripts are contained in initscripts packege.
This cookbook will install it.
Testing
=======
* Add unit tests for the new recipes.
* For function tests and CI integration tests, at least an all-in-one openstack
configured with neutron openvswitch plugin and enabled l3 service is needed.
Documentation Impact
====================
* Configure attribute ['openstack']['network']['ip-movement']['enable'] = 'True'
to enable IP movement.
* Using ['openstack']['network']['ip-movement']['timeout'] to configure the timeout
of IP movement. This attribute decides how long the node should wait for the network
to become operational again after executing the previous commands.
* IP movement default to use default gateway to check its network connections in the
end of its operations. Assign an ip address to ['openstack']['network']['ip-movement']
['validate-ip'] attribute to use another ip address instead.
References
==========
* `Red Hat network scripts integration <https://github.com/osrg/openvswitch/blob/mpls-nx/rhel/README.RHEL>`_
* `README.Debian for openvswitch-switch <https://github.com/horms/openvswitch/blob/devel/add-group-help-fix/debian/openvswitch-switch.README.Debian>`_

204
specs/liberty/openstack-powervm/openstack-powervm.rst
View File

@ -1,204 +0,0 @@
..
This work is licensed under a Creative Commons Attribution 3.0 Unported
License.
http://creativecommons.org/licenses/by/3.0/legalcode
=================================================
Configure openstack services with PowerVM support
=================================================
Include the URL of your launchpad blueprint:
https://blueprints.launchpad.net/openstack-chef/+spec/openstack-powervm
IBM PowerVM is a hypervisor that the POWER platform supports.
PowerVM admins can see benefits in their environments by making use of OpenStack.
The nova driver (along with a Neutron ML2 compatible agent and ceilometer
agent) will provide capability for admins of PowerVM to use OpenStack natively.
The PowerVM drivers are opensource and currently being worked in the StackForge
community.
For Nova, the PowerVM compute driver is on the openstack base incubation track.
For Neutron the driver will follow the BYOD model set forth in the Neutron extension
decomposition. There is a blueprint for supporting a PowerVM compute
inspector in Ceilometer at least for the L release.
In a later release it's been expressed that the Ceilometer compute notifications model may change.
For PowerVM systems this ML2 agent would replace the default openvswitch agent for compute nodes
with the PowerVM SEA ML2 agent.
Refer [OPENSTACK_NOVA_POWERVM]_.
Refer [OPENSTACK_NEUTRON_POWERVM]_.
Refer [OPENSTACK_CEILOMETER_POWERVM]_.
Refer [POWERVM_CEILOMETER_COMPUTE]_.
This new change proposed will enable deployment and configuration of the
PowerVM Nova compute driver, Neutron ML2 agent and Ceilometer compute inspector.
Similar to VMWare, this is an addition to support another type of hypervisor.
Problem description
===================
* Currently, cookbook-openstack-compute does not support the deployment and
configuration of the PowerVM Nova compute driver.
* Currently, cookbook-openstack-network does not support the deployment and
configuration of the PowerVM Neutron ML2 agent.
* Currently, cookbook-openstack-telemetry does not support the deployment and
configuration of the PowerVM Ceilometer compute inspector.
Proposed change
===============
Add support in cookbook-openstack-* cookbooks to configure the PowerVM Nova
compute driver, Neutron ML2 agent and Ceilometer compute inspector.
* A new configuration attribute will be added in order to deploy PowerVM drivers
* If the new attribute is enabled, it will auto set other attributes and
automatically include the PowerVM recipes
* By default, PowerVM drivers will be downloaded from source code on Stackforge
* A new configuration attribute will allow to download from either source code
or public package repository
* A new configuration attribute will allow to override the package repository url
Alternatives
------------
* User manually downloads code from Stackforge and deploy/configure the PowerVM
Nova compute driver, Neutron ML2 agent and Ceilometer compute inspector.
* User extends the existing OpenStack Puppet modules to deploy and configure
the PowerVM Nova compute driver, Neutron ML2 agent and Ceilometer compute inspector.
Refer [OPENSTACK_PUPPET_NOVA]_.
Refer [OPENSTACK_PUPPET_NEUTRON]_.
Refer [OPENSTACK_PUPPET_CEILOMETER]_.
Data model impact
-----------------
None
REST API impact
---------------
None
Security impact
---------------
None
Notifications impact
--------------------
None
Other end user impact
---------------------
None
Performance Impact
------------------
None
Other deployer impact
---------------------
* Deployment of PowerVM drivers has to be explicitly enabled
* As of now, we're considering the use of configuration attributes rather than
roles to deploy PowerVM drivers since its usage is not considered generic yet.
* The deployer will be able to deploy the PowerVM drivers from different sources
(github, public or private package repositories) by overriding
configuration attributes.
Developer impact
----------------
None
Implementation
==============
Assignee(s)
-----------
Primary assignee:
dclain
Other contributors:
thorst
Work Items
----------
* Work with the PowerVM Driver team to fully understand all of the
configuration options
* Add new attributes to openstack-compute, openstack-network,
openstack-telemetry to support PowerVM
* Change openstack-compute / nova.conf.erb template for including
configuration specific to the PowerVM Nova compute driver
* Change openstack-compute / rootwrap.conf.erb template for including filters
specific to the PowerVM Nova compute driver
* Add new recipe for PowerVM configuration in openstack-compute
* Change openstack-net work / ml2_conf.ini.erb in openstack-network for
including configuration specific to the PowerVM Neutron ML2 agent
* Add new recipe for the PowerVM Neutron ML2 agent configuration in
openstack-network
* Add new recipe for the PowerVM Ceilometer inspector configuration in
openstack-telemetry
* Add Unit Tests for each new recipe
* Extend openstack-chef-repo to test all-in-one PowerVM nova-network
Dependencies
============
* TBD
Testing
=======
* Add unit tests for the recipes
* Add new test, environment to support all-in-one PowerVM nova compute using
openstack-chef-repo
* We will report our function and CI integration test results (using
openstack-chef-repo) back to the Chef team.
Documentation Impact
====================
* Update README.md in openstack-compute, openstack-network, openstack-telemetry
cookbooks to expose the PowerVM configuration attributes and how to enable it
* Update README.md in openstack-chef-repo cookbook to explain
* Add documentation in openstack-chef-repo/doc to explain how to test a PowerVM
specific all-in-one compute configuration
References
==========
.. [OPENSTACK_NOVA_POWERVM] `PowerVM driver for OpenStack Nova compute driver
<https://github.com/stackforge/nova-powervm>`_
.. [OPENSTACK_NEUTRON_POWERVM] `PowerVM driver for OpenStack Neutron ML2 agent
<https://github.com/stackforge/neutron-powervm>`_
.. [OPENSTACK_CEILOMETER_POWERVM] `PowerVM driver for OpenStack Ceilometer
compute inspector <https://github.com/stackforge/ceilometer-powervm>`_
.. [OPENSTACK_PUPPET_NOVA] `OpenStack Nova Puppet Module
<https://github.com/openstack/puppet-nova>`_
.. [OPENSTACK_PUPPET_NEUTRON] `OpenStack Neutron Puppet Module
<https://github.com/openstack/puppet-neutron>`_
.. [OPENSTACK_PUPPET_CEILOMETER] `OpenStack Ceilometer Puppet Module
<https://github.com/openstack/puppet-ceilometer>`_
.. [POWERVM_CEILOMETER_COMPUTE] `PowerVM Ceilometer Compute Launchpad
<https://launchpad.net/ceilometer-powervm>`_

127
specs/ocata/all/drop-admin-endpoints.rst
View File

@ -1,127 +0,0 @@
..
This work is licensed under a Creative Commons Attribution 3.0 Unported
License.
http://creativecommons.org/licenses/by/3.0/legalcode
=======================================================
Stop generating admin endpoints in the keystone catalog
=======================================================
The admin endpoints offer no special functionality, users may talk to the
public endpoints instead. The only historic use case has been the keystone
v2 admin endpoint, but with keystone v3 API, even that is no longer needed.
Problem description
===================
Currently we generate admin endpoints for almost all services. As the service
catalog is sent to the API user for every transaction, this generates some
amount of overhead, as these endpoints aren't really needed anymore. Dropping
them will also reduce the time needed for chef runs.
Proposed change
===============
Drop the admin endpoints from all identity_registration recipes in our
cookbooks. This will affect:
- cookbook-openstack-block-storage
- cookbook-openstack-compute
- cookbook-openstack-identity
- cookbook-openstack-image
- cookbook-openstack-networking
- cookbook-openstack-orchestration
- cookbook-openstack-telemetry
Alternatives
------------
Stick to the status quo.
Data model impact
-----------------
None
REST API impact
---------------
None
Security impact
---------------
Deployments that have been using a different admin endpoint with restricted
access may need to switch to using the internal endpoint instead.
Notifications impact
--------------------
None
Other end user impact
---------------------
None
Performance Impact
------------------
The size of the service catalog will be reduced, as well as the duration of
chef runs, both with positively impact performance.
Other deployer impact
---------------------
Deployments that in some way make unexpected use of the admin endpoints will
need to be adapted.
Developer impact
----------------
None
Implementation
==============
Assignee(s)
-----------
Primary assignee:
<j-rosenboom-j>
Other contributors:
<jklare>
Work Items
----------
- Update identity_registration recipes
- Check for unknown dependencies
Dependencies
============
None
Testing
=======
Our integration tests should have sufficient coverage in order to make sure
that this change doesn't have any negative impact.
Documentation Impact
====================
None
References
==========
None

323
specs/template.rst
View File

@ -1,323 +0,0 @@
..
This work is licensed under a Creative Commons Attribution 3.0 Unported
License.
http://creativecommons.org/licenses/by/3.0/legalcode
==========================================
Example Spec - The title of your blueprint
==========================================
Include the URL of your launchpad blueprint:
https://blueprints.launchpad.net/openstack-chef/+spec/example
Introduction paragraph -- why are we doing anything? A single paragraph of
prose that operators can understand. The title and this first paragraph
should be used as the subject line and body of the commit message
respectively.
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-chef/+spec/awesome-thing
should be named awesome-thing.rst
* Please do not delete any of the sections in this template. If you have
nothing to say for a whole section, just write: None
* For help with syntax, see http://sphinx-doc.org/rest.html
* To test out your formatting, build the docs using tox and see the generated
HTML file in doc/build/html/specs/<path_of_your_file>
* 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
===============
Here is where you cover the change you propose to make in detail. How do you
propose to solve this problem?
If this is one part of a larger effort make it clear where this piece ends. In
other words, what's the scope of this effort?
Alternatives
------------
What other ways could we do this thing? Why aren't we using those? This doesn't
have to be a full literature review, but it should demonstrate that thought has
been put into why the proposed solution is an appropriate one.
Data model impact
-----------------
Changes which require modifications to the data model often have a wider impact
on the system. The community often has strong opinions on how the data model
should be evolved, from both a functional and performance perspective. It is
therefore important to capture and gain agreement as early as possible on any
proposed changes to the data model.
Questions which need to be addressed by this section include:
* What new data objects and/or database schema changes is this going to
require?
* What database migrations will accompany this change.
* How will the initial set of new data objects be generated, for example if you
need to take into account existing instances, or modify other existing data
describe how that will work.
REST API impact
---------------
Each API method which is either added or changed should have the following
* Specification for the method
* A description of what the method does suitable for use in
user documentation
* Method type (POST/PUT/GET/DELETE)
* Normal http response code(s)
* Expected error http response code(s)
* A description for each possible error code should be included
describing semantic errors which can cause it such as
inconsistent parameters supplied to the method, or when an
instance is not in an appropriate state for the request to
succeed. Errors caused by syntactic problems covered by the JSON
schema defintion do not need to be included.
* URL for the resource
* Parameters which can be passed via the url
* JSON schema definition for the body data if allowed
* JSON schema definition for the response data if any
* Example use case including typical API samples for both data supplied
by the caller and the response
* Discuss any policy changes, and discuss what things a deployer needs to
think about when defining their policy.
Example JSON schema definitions can be found in the openstack-chef tree
https://git.openstack.org/cgit/openstack/openstack-chef/tree/openstack-chef/api/openstack/compute/schemas/v3
Note that the schema should be defined as restrictively as
possible. Parameters which are required should be marked as such and
only under exceptional circumstances should additional parameters
which are not defined in the schema be permitted (eg
additionaProperties should be False).
Reuse of existing predefined parameter types such as regexps for
passwords and user defined names is highly encouraged.
Security impact
---------------
Describe any potential security impact on the system. Some of the items to
consider include:
* Does this change touch sensitive data such as tokens, keys, or user data?
* Does this change alter the API in a way that may impact security, such as
a new way to access sensitive information or a new way to login?
* Does this change involve cryptography or hashing?
* Does this change require the use of sudo or any elevated privileges?
* Does this change involve using or parsing user-provided data? This could
be directly at the API level or indirectly such as changes to a cache layer.
* Can this change enable a resource exhaustion attack, such as allowing a
single API interaction to consume significant server resources? Some examples
of this include launching subprocesses for each connection, or entity
expansion attacks in XML.
For more detailed guidance, please see the OpenStack Security Guidelines as
a reference (https://wiki.openstack.org/wiki/Security/Guidelines). These
guidelines are a work in progress and are designed to help you identify
security best practices. For further information, feel free to reach out
to the OpenStack Security Group at openstack-security@lists.openstack.org.
Notifications impact
--------------------
Please specify any changes to notifications. Be that an extra notification,
changes to an existing notification, or removing a notification.
Other end user impact
---------------------
Aside from the API, are there other ways a user will interact with this
feature?
* Does this change have an impact on python-openstack-chefclient? What does the user
interface there look like?
Performance Impact
------------------
Describe any potential performance impact on the system, for example
how often will new code be called, and is there a major change to the calling
pattern of existing code.
Examples of things to consider here include:
* A periodic task might look like a small addition but if it calls conductor or
another service the load is multiplied by the number of nodes in the system.
* Scheduler filters get called once per host for every instance being created,
so any latency they introduce is linear with the size of the system.
* A small change in a utility function or a commonly used decorator can have a
large impacts on performance.
* Calls which result in a database queries (whether direct or via conductor)
can have a profound impact on performance when called in critical sections of
the code.
* Will the change include any locking, and if so what considerations are there
on holding the lock?
Other deployer impact
---------------------
Discuss things that will affect how you deploy and configure OpenStack
that have not already been mentioned, such as:
* What config options are being added? Should they be more generic than
proposed (for example a flag that other hypervisor drivers might want to
implement as well)? Are the default values ones which will work well in
real deployments?
* Is this a change that takes immediate effect after its merged, or is it
something that has to be explicitly enabled?
* If this change is a new binary, how would it be deployed?
* Please state anything that those doing continuous deployment, or those
upgrading from the previous release, need to be aware of. Also describe
any plans to deprecate configuration values or features. For example, if we
change the directory name that instances are stored in, how do we handle
instance directories created before the change landed? Do we move them? Do
we have a special case in the code? Do we assume that the operator will
recreate all the instances in their cloud?
Developer impact
----------------
Discuss things that will affect other developers working on OpenStack,
such as:
* If the blueprint proposes a change to the driver API, discussion of how
other hypervisors would implement the feature is required.
Implementation
==============
Assignee(s)
-----------
Who is leading the writing of the code? Or is this a blueprint where you're
throwing it out there to see who picks it up?
If more than one person is working on the implementation, please designate the
primary author and contact.
Primary assignee:
<launchpad-id or None>
Other contributors:
<launchpad-id or None>
Work Items
----------
Work items or tasks -- break the feature up into the things that need to be
done to implement it. Those parts might end up being done by different people,
but we're mostly trying to understand the timeline for implementation.
Dependencies
============
* Include specific references to specs and/or blueprints in openstack-chef, or in other
projects, that this one either depends on or is related to.
* If this requires functionality of another project that is not currently used
by openstack-chef (such as the glance v2 API when we previously only required v1),
document that fact.
* Does this feature require any new library dependencies or code otherwise not
included in OpenStack? Or does it depend on a specific version of library?
Testing
=======
Please discuss how the change will be tested. We especially want to know what
tempest tests will be added. It is assumed that unit test coverage will be
added so that doesn't need to be mentioned explicitly, but discussion of why
you think unit tests are sufficient and we don't need to add more tempest
tests would need to be included.
Is this untestable in gate given current limitations (specific hardware /
software configurations available)? If so, are there mitigation plans (3rd
party testing, gate enhancements, etc).
Documentation Impact
====================
What is the impact on the docs team of this change? Some changes might require
donating resources to the docs team to have the documentation updated. Don't
repeat details discussed above, but please reference them here.
References
==========
Please add any useful references here. You are not required to have any
reference. Moreover, this specification should still make sense when your
references are unavailable. Examples of what you could include are:
* Links to mailing list or IRC discussions
* Links to notes from a summit session
* Links to relevant research, if appropriate
* Related specifications as appropriate (e.g. if it's an EC2 thing, link the
EC2 docs)
* Anything else you feel it is worthwhile to refer to

16
tox.ini
View File

@ -1,16 +0,0 @@
[tox]
envlist = docs
[testenv]
basepython = python3
usedevelop = True
setenv = VIRTUAL_ENV={envdir}
deps = -r{toxinidir}/requirements.txt
commands = python setup.py testr --slowest --testr-args='{posargs}'
[testenv:venv]
commands = {posargs}
[testenv:docs]
commands =
sphinx-build -W -b html doc/source doc/build/html