diff --git a/.gitignore b/.gitignore deleted file mode 100644 index fc46136..0000000 --- a/.gitignore +++ /dev/null @@ -1,7 +0,0 @@ -.stestr/ -doc/build -*.egg-info -*.pyc -.tox -AUTHORS -Changelog diff --git a/.stestr.conf b/.stestr.conf deleted file mode 100644 index dcdf16e..0000000 --- a/.stestr.conf +++ /dev/null @@ -1,4 +0,0 @@ -[DEFAULT] -test_path=./tests -top_dir=./ - diff --git a/.zuul.yaml b/.zuul.yaml deleted file mode 100644 index 9919896..0000000 --- a/.zuul.yaml +++ /dev/null @@ -1,9 +0,0 @@ -- project: - templates: - - openstack-specs-jobs - check: - jobs: - - openstack-tox-py37 - gate: - jobs: - - openstack-tox-py37 diff --git a/CONTRIBUTING.rst b/CONTRIBUTING.rst deleted file mode 100644 index 1edbb37..0000000 --- a/CONTRIBUTING.rst +++ /dev/null @@ -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. diff --git a/HACKING.rst b/HACKING.rst deleted file mode 100644 index 02b83c5..0000000 --- a/HACKING.rst +++ /dev/null @@ -1,4 +0,0 @@ -puppet-openstack-specs Style Commandments -========================================= - -Read the OpenStack Style Commandments https://docs.openstack.org/hacking/latest/ diff --git a/LICENSE b/LICENSE deleted file mode 100644 index 67db858..0000000 --- a/LICENSE +++ /dev/null @@ -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. diff --git a/MANIFEST.in b/MANIFEST.in deleted file mode 100644 index 90f8a7a..0000000 --- a/MANIFEST.in +++ /dev/null @@ -1,6 +0,0 @@ -include AUTHORS -include ChangeLog -exclude .gitignore -exclude .gitreview - -global-exclude *.pyc \ No newline at end of file diff --git a/README.rst b/README.rst index 90892f8..4ee2c5f 100644 --- a/README.rst +++ b/README.rst @@ -1,14 +1,10 @@ -======================== -Team and repository tags -======================== +This project is no longer maintained. -.. image:: https://governance.openstack.org/tc/badges/puppet-openstack-specs.svg - :target: https://governance.openstack.org/tc/reference/tags/index.html +The contents of this repository are still available in the Git +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 - -=============================== -puppet-openstack-specs -=============================== - -Puppet OpenStack modules specs repository +For any further questions, please email +openstack-discuss@lists.openstack.org or join #openstack-dev on +OFTC. diff --git a/doc/Makefile b/doc/Makefile deleted file mode 100644 index 54a1a50..0000000 --- a/doc/Makefile +++ /dev/null @@ -1,163 +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 ' where 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." diff --git a/doc/source/conf.py b/doc/source/conf.py deleted file mode 100755 index 624bedf..0000000 --- a/doc/source/conf.py +++ /dev/null @@ -1,72 +0,0 @@ -# Licensed under the Apache License, Version 2.0 (the "License"); -# you may not use this file except in compliance with the License. -# You may obtain a copy of the License at -# -# http://www.apache.org/licenses/LICENSE-2.0 -# -# Unless required by applicable law or agreed to in writing, software -# distributed under the License is distributed on an "AS IS" BASIS, -# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or -# implied. -# See the License for the specific language governing permissions and -# limitations under the License. - -import datetime - -# sys.path.insert(0, os.path.abspath('../..')) -# -- General configuration ---------------------------------------------------- - -# Add any Sphinx extension module names here, as strings. They can be -# extensions coming with Sphinx (named 'sphinx.ext.*') or your custom ones. -extensions = [ - 'openstackdocstheme', - #'sphinx.ext.intersphinx', - 'yasfb', -] - -# Feed configuration for yasfb -feed_base_url = 'https://specs.openstack.org/openstack/puppet-openstack-specs' -feed_author = 'Puppet OpenStack Team' - -exclude_patterns = [ - 'template.rst', - '**/template.rst', -] - -# autodoc generation is a bit aggressive and a nuisance when doing heavy -# text edit cycles. -# execute "export SPHINX_DEBUG=1" in your terminal to disable - -# The suffix of source filenames. -source_suffix = '.rst' - -# The master toctree document. -master_doc = 'index' - -# General information about the project. -copyright = u'%s, OpenStack Foundation' % datetime.date.today().year - -# 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 = True - -# The name of the Pygments (syntax highlighting) style to use. -pygments_style = 'native' - -# -- Options for HTML output -------------------------------------------------- - -# The theme to use for HTML and HTML Help pages. Major themes that come with -# Sphinx are currently 'default' and 'sphinxdoc'. -html_theme_path = [] -html_theme = "openstackdocs" -html_static_path = [] - -# Example configuration for intersphinx: refer to the Python standard library. -#intersphinx_mapping = {'http://docs.python.org/': None} -# openstackdocstheme options -openstackdocs_repo_name = 'openstack/puppet-openstack-specs' -openstackdocs_bug_project = 'puppet-openstack-specs' -openstackdocs_bug_tag = '' diff --git a/doc/source/index.rst b/doc/source/index.rst deleted file mode 100644 index 615d668..0000000 --- a/doc/source/index.rst +++ /dev/null @@ -1,51 +0,0 @@ -.. puppet openstack documentation master file - -======================================= -Puppet OpenStack Program Specifications -======================================= - -Icehouse approved specs: - -.. toctree:: - :glob: - :maxdepth: 1 - - specs/icehouse/* - -Juno approved specs: - -.. toctree:: - :glob: - :maxdepth: 1 - - specs/juno/* - -Kilo approved specs: - -.. toctree:: - :glob: - :maxdepth: 1 - - specs/kilo/* - -Liberty approved specs: - -.. toctree:: - :glob: - :maxdepth: 1 - - specs/liberty/* - -Newton approved specs: - -.. toctree:: - :glob: - :maxdepth: 1 - - specs/newton/* - -================== -Indices and tables -================== - -* :ref:`search` diff --git a/doc/source/specs b/doc/source/specs deleted file mode 120000 index 87a4030..0000000 --- a/doc/source/specs +++ /dev/null @@ -1 +0,0 @@ -../../specs \ No newline at end of file diff --git a/requirements.txt b/requirements.txt deleted file mode 100644 index 81a36cd..0000000 --- a/requirements.txt +++ /dev/null @@ -1,6 +0,0 @@ -pbr!=2.1.0,>=2.0.0 # Apache-2.0 -sphinx>=3.5.1 # BSD -openstackdocstheme>=2.2.1 # Apache-2.0 -stestr>=2.0.0 -testtools>=0.9.34 -yasfb>=0.5.1 diff --git a/setup.cfg b/setup.cfg deleted file mode 100644 index 31cf267..0000000 --- a/setup.cfg +++ /dev/null @@ -1,12 +0,0 @@ -[metadata] -name = puppet-openstack-specs -summary = Puppet OpenStack modules specs repository -description_file = - README.rst -author = OpenStack -author_email = openstack-discuss@lists.openstack.org -home_page = http://specs.openstack.org/openstack/puppet-openstack-specs/ -classifier = - Intended Audience :: Developers - License :: OSI Approved :: Apache Software License - Operating System :: POSIX :: Linux diff --git a/setup.py b/setup.py deleted file mode 100755 index 7eeb36b..0000000 --- a/setup.py +++ /dev/null @@ -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) \ No newline at end of file diff --git a/specs/icehouse/common-openstack-configuration-provider.rst b/specs/icehouse/common-openstack-configuration-provider.rst deleted file mode 100644 index e35347e..0000000 --- a/specs/icehouse/common-openstack-configuration-provider.rst +++ /dev/null @@ -1,123 +0,0 @@ -.. - This work is licensed under a Creative Commons Attribution 3.0 Unported - License. - - http://creativecommons.org/licenses/by/3.0/legalcode - -======================================= -Common OpenStack Configuration Provider -======================================= - -https://blueprints.launchpad.net/puppet-openstacklib/+spec/common-openstack-configuration-provider - -This spec is about introducing a common configuration provider based on -the ini_setting provider from puppetlabs-inifile. Other configuration -providers would now inherit from this provider instead. - - -Problem description -=================== - -All puppet modules for OpenStack uses the ini_setting provider as their -grounds for their specialized version. - -Recent work has been started to implement a secret parameter where changes -for a specific configuration value would be hidden from Puppet logs. -This work is and will be duplicated across all the specialized providers, -violating the DRY concept. - - -Proposed change -=============== - -Introduce a common configuration provider which could be used by other -specialized configuration providers. This common provider would provide -a basic set of features. Example of such features are the secret parameter -and the capitalization of boolean values. - - -Alternatives ------------- - -Without this proposition, we should have to continue using the ini_setting -provider as the base of our specialized configuration providers and -implement/copy features in each of them. - -We could also try proposing our features and changes to upstream so -we don't have to maintain them anymore. Those changes might however not -fit the vision of upstream, like the capitalization of boolean values. - -Data model impact ------------------ - -None - -Module API impact ------------------ - -This proposition does not include any change to any module API. - -End user impact ---------------- - -None - -Performance Impact ------------------- - -None - -Deployer impact ---------------- - -This proposition introduces a new mandatory dependency on openstacklib. - -Those deploying from the master branch and/or using Puppetfile would need to -install the openstacklib puppet module. - -Developer impact ----------------- - -None - -Implementation -============== - -Assignee(s) ------------ - -Primary assignee: - mgagne - -Other contributors: - None - - -Work Items ----------- - -* Create openstack_ini_setting provider -* Refactor the existing configuration providers to use openstack_ini_setting. - - -Dependencies -============ - -None - - -Testing -======= - -* Unit test fixtures of all puppet modules would need to be updated - to install openstacklib. - -Documentation Impact -==================== - -None - -References -========== - -None diff --git a/specs/icehouse/common-openstack-database-resource.rst b/specs/icehouse/common-openstack-database-resource.rst deleted file mode 100644 index 3765117..0000000 --- a/specs/icehouse/common-openstack-database-resource.rst +++ /dev/null @@ -1,213 +0,0 @@ -.. - This work is licensed under a Creative Commons Attribution 3.0 Unported - License. - - http://creativecommons.org/licenses/by/3.0/legalcode - -================================== -Common OpenStack Database Resource -================================== - -https://blueprints.launchpad.net/puppet-openstacklib/+spec/commmon-openstack-database-resource - -This spec proposes to introduce defined resource types in openstacklib to -provide a common interface for setting up databases used by the major OpenStack -services. The current modules for these services would use this interface -rather than duplicating code across these modules. - -Problem description -=================== - -Nearly all of the Puppet modules for OpenStack services set up a database for -themselves and most of them do this using nearly identical code. This causes a -great deal of repetition across modules and will lead to inconsistencies. - -Proposed change -=============== - -Abstract the database functionality into defined resource types in the -openstacklib module. This resource would implement the same functionality as -the db::mysql class and db::mysql::host_access type already do in ceilometer, -cinder, glance, heat, keystone, neutron, and nova and will make the ability to -configure postgresql databases consistent. The new resource would use the -newest mysql and postgresql modules. - -Alternatives ------------- - -The alternative to implementing this feature in openstacklib is to maintain the -database setup functionality in each module separately. This would necessitate -updating the postgresql classes in each module to work with the current version -of the postgresql module as well as adding postgresql support to the heat module. -If additional backends are desired they would have to be implemented in each -module individually. - -Data model impact ------------------ - -The ceilometer, cinder, glance, heat, keystone, neutron, and nova modules -would be updated to depend on the openstacklib module and use the new database -resources to configure their respective databases. - -The mysql and postgresql subclasses of ceilometer, cinder, glance, heat, -keystone, neutron, and nova modules would have their current code replaced -with a call to the new defined resource type in openstacklib. No new classes -would be needed for these modules, except for heat which would need to have a -postgresql subclass added. - -Module API impact ------------------ - -* New defined resource types: - - openstacklib::db::mysql - openstacklib::db::postgresql - - A later spec may introduce an openstacklib::db::mongodb resource. - -* Parameters for openstacklib::db::mysql: - - dbname : The name of the database; - string; optional; default to the $title of the resource, i.e. 'nova' - user : The database user to create; - string; optional; default to the $title of the resource, i.e. 'nova' - password_hash : Password hash to use for the database user for this service; - string; required - host : The IP address or hostname of the user in mysql_grant; - string; optional; default to '127.0.0.1' - charset : The charset to use for the database; - string; optional; default to 'utf8' - collate : The collate to use for the database; - string; optional; default to 'utf8_unicode_ci' - allowed_hosts : Additional hosts that are allowed to access this database; - array or string; optional; default to undef - privileges : Privileges given to the database user; - string or array of strings; optional; default to 'ALL' - -* Example use case for openstacklib::db::mysql: - - In ::nova::db::mysql:: - - ::openstacklib::db::mysql { 'nova': - password_hash => '2470C0C06DEE42FD1618BB99005ADCA2EC9D1E19', - notify => Exec['nova-db-sync'], - } - - would create a mysql database called 'nova' with user 'nova@127.0.0.1'. It - would not allow other hosts access to the database. It will re-execute the - 'nova-db-sync' exec when the database refreshes. - - Another example in ::keystone::db::mysql:: - - ::openstacklib::db::mysql { 'keystone': - password_hash => '2470C0C06DEE42FD1618BB99005ADCA2EC9D1E19', - host => '1.2.3.4', - allowed_hosts => ['1.2.3.4', '5.6.7.8'], - notify => Exec['keystone-manage db_sync'], - before => Service['keystone'], - } - - would create a mysql database called 'keystone' with user 'keystone@1.2.3.4' - and grants to 'keystone' on hosts '1.2.3.4' and '5.6.7.8'. The database will - be set up before the keystone service is started and the 'keystone-manage - db_sync' exec will be re-executed when it refreshes. - -* Parameters for openstacklib::db::postgresql: - - dbname : The name of the database; - string; optional; default to the $title of the resource, i.e. 'nova' - user : The database user to create; - string; optional; default to the $title of the resource, i.e. 'nova' - password_hash : Password hash to use for the database user for this service; - string; required - encoding : The charset or encoding to use for the database; - string; optional; default to undef - -* Example use case for openstacklib::db::postgresql - - In ::nova::db::postgresql:: - - ::openstacklib::db::postgresql { 'nova': - password_hash => '2470C0C06DEE42FD1618BB99005ADCA2EC9D1E19', - notify => Exec['nova-db-sync'], - } - - would create a postgresql database called 'nova' with user 'nova'. It will - re-execute the 'nova-db-sync' exec when the database refreshes. - - Another example in ::keystone::db::postgresql:: - - ::openstacklib::db::postgresql { 'keystone': - password_hash => '2470C0C06DEE42FD1618BB99005ADCA2EC9D1E19', - notify => Exec['nova-db-sync'], - before => Service['keystone'], - } - - would create a postgresql database called 'keystone' with user 'keystone'. - The database will be set up before the keystone service is started and the - 'keystone-manage db_sync' exec will be re-executed when it refreshes. - - -End user impact ---------------------- - -None aside from the API. - -Performance Impact ------------------- - -None - -Deployer impact ---------------------- - -The user needs to install the openstacklib module prior to using the -ceilometer, cinder, glance, heat, keystone, neutron, or nova modules. - -Developer impact ----------------- - -Changes to database setup will happen in the openstacklib module rather than in -the individual OpenStack service modules. - -Implementation -============== - -Assignee(s) ------------ - -Primary assignee: - krinkle - -Other contributors: - None - -Work Items ----------- - -* Create new defined resource type in openstacklib. - -* Update ceilometer, cinder, glance, heat, keystone, neutron, and nova modules - to depend on openstacklib and use the new resource. - -Dependencies -============ - -None - -Testing -======= - -Unit test fixtures of all puppet modules would need to be updated to install -openstacklib. Existing tests in these modules would be replicated in -openstacklib. - -Documentation Impact -==================== - -None - -References -========== - -None diff --git a/specs/icehouse/common-openstack-identity-resource.rst b/specs/icehouse/common-openstack-identity-resource.rst deleted file mode 100644 index 61ef7d6..0000000 --- a/specs/icehouse/common-openstack-identity-resource.rst +++ /dev/null @@ -1,173 +0,0 @@ -.. - This work is licensed under a Creative Commons Attribution 3.0 Unported - License. - - http://creativecommons.org/licenses/by/3.0/legalcode - -================================== -Common OpenStack Identity Resource -================================== - -https://blueprints.launchpad.net/puppet-openstacklib/+spec/common-openstack-identity-resource - -This spec proposes to introduce defined resource types in openstacklib to -provide a common interface for setting up Keystone resources used by the major OpenStack -services. The current modules for these services would use this interface -rather than duplicating code across these modules. - -Problem description -=================== - -Nearly all of the Puppet modules for OpenStack services set up Keystone users, roles, -tenants and endpoints for themselves and most of them do this using nearly identical -code. This causes a great deal of repetition across modules and will lead to -inconsistencies. - -Proposed change -=============== - -Abstract the identity functionality into defined resource types in the -keystone::auth type already done in most of OpenStack modules. -openstacklib module. This resource would implement the same functionality as we had before -with Keystone resources management. -The new resource would use the newest identity modules. - -Alternatives ------------- - -The alternative to implementing this feature in openstacklib is to maintain the -Keystone resources management functionality in each module separately. - -Data model impact ------------------ - -The OpenStack modules would be updated to depend to use -the new identity resources to configure their respective Keystone resources. - -Some modules would have their current code replaced -with a call to the new defined resource type in openstacklib. No new classes -would be needed for these modules. - -Module API impact ------------------ - -* New defined resource type: - - openstacklib::identity - -* Parameters for openstacklib::service_identity: - - password : Password to create for the service user; - string; required - auth_name : The name of the service user; - string; optional; default to the $title of the resource, i.e. 'nova' - service_name : Name of the service; - string; required - public_url : Public endpoint URL; - string; required - internal_url : Internal endpoint URL; - string; required - admin_url : Admin endpoint URL; - string; required - region : Endpoint region; - string; optional: default to 'RegionOne' - tenant : Service tenant; - string; optional: default to 'services' - domain : User domain (keystone v3); - string; optional: default to undef - email : Service email; - string; optional: default to '$auth_name@localhost' - configure_endpoint : Whether to create the endpoint. - string; optional: default to True - configure_user : Whether to create the user. - string; optional: default to True - configure_user_role : Whether to create the user role. - string; optional: default to True - -* Example use case for openstacklib::service_identity: - - In ::nova::keystone::auth:: - - ::openstacklib::service_identity { 'nova': - password => 'secrete', - auth_name => 'nova', - domain => 'domain1', - service_name => 'compute', - public_url => 'https://my-nova-api.com:8774/v2', - admin_url => 'https://my-nova-api.com:8774/v2', - internal_url => 'https://my-nova-api.com:8774/v2', - notify => Service['nova-api'], - } - - would create user, tenant, role and endpoint for OpenStack Compute API service and restart nova-api. - -In the case of multiple endpoints version (Keystone & Nova v2+v3), we would have to use two times ::openstacklib::service_identity with v3 optional and disabled by default for backward compatibility. In Nova, we have an EC2 endpoint and we will also use the new function exactly how it is in current puppet-nova code. - -In the case of multiple regions, it would be suggested to use Hiera and the new nova::keystone::auth with is consumming a define function in openstacklib, to create multiple resources in multiple regions. - -In the case of a dedicated Keystone server, it's obvious the nova::keystone::auth classes are only set for Keystone nodes, otherwise it will lead to catalog compilation issues since keystone.conf is not on other nodes. - - -End user impact ---------------------- - -None aside from the API. - -Performance Impact ------------------- - -None - -Deployer impact ---------------------- - -The user needs to install the openstacklib module prior to using the -OpenStack modules. - -Developer impact ----------------- - -Changes to keystone setup will happen in the openstacklib module rather than in -the individual OpenStack service modules. - -Implementation -============== - -Assignee(s) ------------ - -Primary assignee: - EmilienM - -Other contributors: - None - -Work Items ----------- - -* Create new defined resource type in openstacklib. - -* Update ceilometer, cinder, glance, heat, keystone, neutron, and nova modules - to depend on openstacklib and use the new resource. - -Dependencies -============ - -None - -Testing -======= - -Unit test fixtures of all puppet modules would need to be updated to install -openstacklib. Existing tests in these modules would be replicated in -openstacklib. - -Documentation Impact -==================== - -README will be updated for each module consuming this new feature. - -References -========== - -None diff --git a/specs/icehouse/extras-repository-refactor.rst b/specs/icehouse/extras-repository-refactor.rst deleted file mode 100644 index bf0cfb1..0000000 --- a/specs/icehouse/extras-repository-refactor.rst +++ /dev/null @@ -1,160 +0,0 @@ -.. - This work is licensed under a Creative Commons Attribution 3.0 Unported - License. - - http://creativecommons.org/licenses/by/3.0/legalcode - -========================================== -Repository Management in Extras -========================================== - -Include the URL of your launchpad blueprint: - -https://blueprints.launchpad.net/puppet-openstack/+spec/extras-repository-refactor - -Problem description -=================== - -Currently it is necessary to maintain a separate module to handle base -repositories and any other repos that are needed for operation. This patch seeks -to allow arbitrary definitions of repositories via hash parameters and -create_resources integrated with and alongside the rdo and uca options already -available. - -This patch will also define a sensible directory structure to use, so that common -code between similar systems can be shared. - -Proposed change -=============== - -Create classes that manage arbitrary repositories but also RDO and UCA. -Share code for similar systems where possible. -Define directory structure for repo management - -Alternatives ------------- - -Port the current repo management code across - -This results in an implicit requirement to use either data-bindings or another class -with collectors to override resources in the case where the user wants to provide -their own baseurl for epel, or provide a proxy, since the parameters for those -resources are not exposed to the class. - -If every parameter for each resource is exposed, we end up with a bloated interface -for the classes. - -A suggestion was made to use stahnma's epel class, but this is an even greater -exaggeration of this problem since that class has so many parameters. Instead, -we should offer to not manage epel, and allow the user to include the epel module -if they wish, while continuing to offer a convenience parameter with the current -defaults. - -Data model impact ------------------ - -None - -Module API impact ------------------ - -New classes for debian: - -openstack_extras::repo::debian::ubuntu -openstack_extras::repo::debian::debian -openstack_extras::repo::debian::params - -Parameters for debian osfamily: - - release : The openstack release name - - manage_[uca|whz] : whether to add the default uca/wheezy repo - - source_hash : a hash of apt::source resources - - source_defaults : a hash of apt::source parameters for defaults - - package_require : whether to use a collector for all packages to require apt-get update - -New classes for redhat: - -openstack_extras::repo::redhat::redhat -openstack_extras::repo::redhat::params - -Parameters for redhat osfamily: - - release : The openstack release name - - manage_rdo : whether to add the default rdo repo - - repo_hash : a hash of yumrepo resources - - repo_defaults : a hash of yumrepo parameters for defaults - - gpgkey_hash : a hash of file resources to create gpg keys - - gpgkey_defaults : a hash of file parameters for defaults - - purge_unmanaged : whether to purge unmanaged yum repos from yum.repos.d - - package_require : whether to use a collector for all packages to require all yum repos - -Directory structure should follow: - -openstack_extras::repo::${downcase(::osfamily)}::${downcase(::operatingsystem)} - -currently redhat, centos, fedora all handled using RDO, but leave the option to diverge later - -New functions: - -We need some functions that will perform validation on the hashes passed to file and yumrepo -to catch typos as early as possible. - -End user impact ---------------------- - -None - -Performance Impact ------------------- - -None - -Deployer impact ---------------------- - -Allows deployers to manage all repos on their system without -having to make their own class. - -Deployers will need to understand how to pass resource hashes -around in order to take advantage of this. Hiera example will -be provided. All users of the current repo mgmt system should -migrate to the new format at their leisure - the old classes -will not be changed. - -Developer impact ----------------- - -None - -Implementation -============== - -Assignee(s) ------------ - -michchap - -Work Items ----------- - -debian/ubuntu support -redhat/centos/fedora support - -Dependencies -============ - -Adds apt dependency to openstack_extras - -Testing -======= - -rspec for unit tests -will be integrated into aptira's product during testing for integration tests - -Documentation Impact -==================== - -Complete change of repo management API - -References -========== - -None diff --git a/specs/icehouse/use-aviator-in-module-resources.rst b/specs/icehouse/use-aviator-in-module-resources.rst deleted file mode 100644 index 64938f9..0000000 --- a/specs/icehouse/use-aviator-in-module-resources.rst +++ /dev/null @@ -1,238 +0,0 @@ -.. - This work is licensed under a Creative Commons Attribution 3.0 Unported - License. - - http://creativecommons.org/licenses/by/3.0/legalcode - -=============================== -Use Aviator in Module Resources -=============================== - -https://blueprints.launchpad.net/puppet-openstacklib/+spec/use-aviator-in-module-resources - -This spec proposes to incorporate an interface to the OpenStack API in -openstacklib with the purpose of improving maintainability and promoting a more -configurable authentication interface. The providers would avoid the use of -the Python-based command-line OpenStack clients in favor of using Aviator, a -Ruby API binding for OpenStack. The corresponding types would implement an -interface for configuring authentication and endpoint details. - -Problem description -=================== - -The OpenStack puppet modules contain a number of types and providers to access -OpenStack services via their API endpoints. Currently they rely on the -Python-based command-line clients to access these endpoints. The command-line -clients make requests at the respective OpenStack services, parse the response -and restructure it as a human-readable string. This means that the puppet -providers that wrap around these clients are heavily dependent on the format of -the restructured strings to interpret it correctly. Since these clients are -part of fast-paced projects, the output format is subject to change -unpredictably on each new release (which happens fairly frequently; -keystoneclient, for example, releases every few days or weeks -https://github.com/openstack/python-keystoneclient/releases), causing -the puppet modules to have a high maintenance cost. Moreover, the clients often -output warning messages that are not useful to the puppet modules and are -currently explicitly ignored. This adds additional complexity to parsing the -client output. - -A related problem is that the providers currently rely on the presence of a -service configuration file on localhost. This means that the puppet -modules must rely on authentication information residing in a configuration -file on the node, whose state may or may not be managed by Puppet and -therefore may be improperly configured or missing (due to misconfiguration or -due to the service residing on another host). - -Finally, there is some common functionality, such as configuration of -authentication endpoints and credentials that a number of modules share that -is currently duplicated across the modules. This will lead to inconsistency -across the modules. - -Proposed change -=============== - -The proposed solution is to use the Aviator Ruby library instead of the -command-line clients as an interface to the OpenStack services. The -openstacklib module will add a dependency on the aimonb/aviator puppet -module. This module contains aviator as well as all of its dependencies within -its lib/puppet/features directory, so no gems need to be installed on the -master or the agents. Since Aviator returns pure JSON objects in its -responses, the providers in the puppet modules that need to interact with the -OpenStack REST API will parse the JSON returned directly from the service, -rather than the string output as interpreted by the command-line client. This -means that maintenance of the providers in the OpenStack puppet modules only -needs to keep up with changes to the REST API, and not with the command-line -clients, whose output is subject to change more frequently. - -Using a Ruby library also helps promote the value that API wrappers should -reflect the idioms of the language in which they were written. - -This change opens the opportunity to update the way the endpoint URI and -authentication parameters are handled in order to provide a greater degree of -configurability to the module user. Much of the logic for configuring endpoints -and credentials is duplicated across the modules and can be abstracted out to -the openstacklib module. - -Alternatives ------------- - -Without implementing these changes in the providers, the module maintainers -will have to continue to watch for changes in the command-line clients and -update the providers to handle these changes appropriately. - -Fog is another Ruby binding for OpenStack that could be uses as an alternative -to Aviator, but it is too large to incorporate into the module and is too -overbearing for our needs. - -The providers could implement the REST client functionality themselves, but -this adds significant complexity to the providers when a library can accomplish -this already. - -Data model impact ------------------ - -None - -Module API impact ------------------ - -Aviator provides a variety of ways to authenticate to OpenStack services, -among them providing credentials at run time. The existing types need to have -parameters added to accept these credentials as well as endpoint URIs. The -openstacklib module will implement a class Puppet::Provider::Aviator that -inherits from Puppet::Provider. This class will implement an authenticate -method and an endpoint method, both of which will accept parameters that can -be passed from a type's parameters as well as the service being utilized. The -providers in the openstack modules will use this class as a :parent, e.g.:: - - Puppet::Type.type(:keystone_service).provide( - :aviator, - :parent => Puppet::Provider::Aviator - ) do - - -The authenticate method will replace methods like auth_keystone and -auth_neutron. The endpoint method will replace methods like get_admin_endpoint -(in keystone) and get_auth_endpoint (in glance and neutron). These methods -currently rely on parsing the configuration file with methods such as -neutron_conf or keystone_file. Those methods will remain, but other methods -need to be written to accept credential and endpoint for the authenticate and -endpoint methods. They will fall back to reading the configuration file. This -will offer the modules a more robust and consistent way of authenticating -without relying on configuration files. - -The authenticate method needs to ensure that a connection is retried -appropriately if needed. - -The list_* methods will need to be rewritten to use the new authenticate and -endpoint methods. - -The parse_* methods will need to be rewritten to parse JSON objects rather -than strings. - -Every provider in the various OpenStack modules that currently uses a -command-line tool in order to function will be rewritten to use calls to -aviator. These can be identified by providers that contain a "commands" or -"optional_commands" statement to import a command-line tool as a Ruby -function. - -The remove_warnings methods in puppet-keystone and puppet-glance will be -removed. - -End user impact ---------------------- - -An end user of the OpenStack modules will need to pull in the openstacklib -module. They will have the option to supply authentication information to the -reworked types, but this will be optional and the providers will default to -using data from configuration files if these parameters are not defined. - -Performance Impact ------------------- - -None - -Deployer impact ---------------------- - -The user needs to install the openstacklib module prior to using the types that -interact with the REST endpoints in the OpenStack modules. - -Developer impact ----------------- - -Developers of the module plugins will have to learn the Aviator API and will -no longer have to use the Python-based command-line clients. - -Implementation -============== - -Assignee(s) ------------ - -Primary assignee: - krinkle (crinkle on freenode) - -Work Items ----------- - -* Update the Modulefile or metadata.json and .fixtures.yml in openstacklib to - reflect the new dependency on aimonb/aviator - -* Add providers to openstacklib to wrap some of the common procedures that will - be done with Aviator, such as authentication - -* Update the providers in the OpenStack modules, starting with puppet- - keystone, to use Aviator and the new functions provided by openstacklib - -* Add new authentication and endpoint configuration parameters to the module - types, with options to configure from parameters specified in the manifest, a - .conf file, or openrc. - -Dependencies -============ - -None - -Testing -======= - -Unit test fixtures of all the OpenStack puppet modules will need to be updated -to install openstacklib. - -Documentation Impact -==================== - -None - -References -========== - -Relevant research: - -* Error messages changing often - - Bug: https://bugs.launchpad.net/puppet-keystone/+bug/1340447 - - The keystone command-line client is subject to change its output - unexpectedly, causing the puppet modules to fail to parse it properly. - -* Retrying neutron connections - - Bug: https://bugs.launchpad.net/fuel/+bug/1246795 - Discussion: http://irclog.perlgeek.de/puppet-openstack/2014-07-21#i_9056413 - - Numerous error messages from the neutron command-line client indicate that - a request should be retried. Using HTTP responses via Aviator rather than - error strings to detect when a retry is necessary makes the regexes easier - to write and interpret. - -* Caching query results - - Bug: https://bugs.launchpad.net/puppet-neutron/+bug/1344293 - Discussion: http://irclog.perlgeek.de/puppet-openstack/2014-07-16#i_9036216 - - Caching values during authentication can cause problems when setting up - multiple services within one puppet run. The rewritten providers will need to - be careful to fetch fresh values when authenticating to various services with - Aviator. diff --git a/specs/juno/pacemaker-provider-for-openstack.rst b/specs/juno/pacemaker-provider-for-openstack.rst deleted file mode 100644 index e75f395..0000000 --- a/specs/juno/pacemaker-provider-for-openstack.rst +++ /dev/null @@ -1,192 +0,0 @@ -.. - This work is licensed under a Creative Commons Attribution 3.0 Unported - License. - - http://creativecommons.org/licenses/by/3.0/legalcode - -========================================== -Pacemaker provider for Openstack services -========================================== - -https://blueprints.launchpad.net/puppet-nova/+spec/pacemaker-provider-for-openstack - -It is a common practice to make services managed by Pacemaker in Linux HA clusters. -Puppet modules for Openstack should be able to ensure both standard and Pacemaker -providers for Openstack services as well. - -In order to achieve this as a transparent solution (w/o modifications to the core -Puppet modules for Openstack) special wrapping classes should be created in -puppet-openstack_extras. These wrappers should contain overrides for Openstack -services as a Pacemaker service provider and ensure creation of corresponding -Pacemaker resources as well. - -Problem description -=================== - -A detailed description of the problem: - -Puppet modules for Openstack configure services in a classic way, such as -system service providers. -For HA clusters, though, operators might have wanted to have an option -to delegate Openstack services management for Pacemaker instead. -Pacemaker OCF scripts provide very good options for cluster-wide resources -management and Puppet should deliver this options as well. - -Proposed change -=============== - -A Pacemaker service provider and special wrapper class or classes, like -``openstack_extras::pacemaker::heat`` or ``openstack_extras::pacemaker::nova`` -should be created as well as Resource Agents (OCF) scripts for related cluster -resources management. Once a wrapper class is included in the Puppet catalog, -it would override the default service provider of the corresponding Openstack -service configured by its base core module. That will ensure a transparent way -of HA configuration for Openstack services without any modifications to the -base core modules, such as puppet-nova or puppet-heat and so on. - -For the first stage of implementation, there should be only a service provider -for Pacemaker created and put into the openstack_extras. That will assume the -deployers should use their own custom classes and Resource Agents (OCF) scripts -for the cluster resources configuration. - -The second stage should be a creation of a basic HA wrapper class (or classes) -shipped with a generic OCF scripts for the cluster resources definition which -could benefit every developer. Of course, there should be a way for deployer -to use his custom OCF scripts as well. - -Note, that Puppet modules for Openstack will not configure Openstack services -in HA by default. Also, related infra services (such as MySQL or RabbitMQ) -should not be configured by Puppet Openstack core modules, so we do not expect -it for HA provider as well. But HA provider still could be used to do so, -if user wants to override some basic service provider to HA one. By design, -it should work transparently for whichever service in Puppet catalog. - -The module for Pacemaker and Corosync to be used with this HA provider is a -puppetlabs/corosync. - -Alternatives ------------- - -The another option is to use puppet-openstacklibs instead of extras. - -There is also an option to switch to another module for Pacemaker and Corosync -instead of puppetlabs/corosync. The former one does not support clones, -location constraints, operates via pcs/crmsh CLI which are not good then cluster -is being deoplyed in parallel. So, it could make sence to redesign it -completely, or switch from it to another module, or provide an option to specify -which module deployer wants to use. - -A completely another approach could be considered as well. -Pacemaker provider configuration could be ensured as a simple pipe, i.e. we -are passing a some external class name (and its params as a hash) into the -corresponding Openstack classes. This approach resembles the one for -``rabbitmq_class`` which uses ``rabbitmq::server`` as a default value but -could be anything else. But for this case it should be some Pacemaker or -Corosync related class instead. - -Each Openstack class providing the service should be as well extended then -with the following parameters: - -* ``pacemaker_provider`` (or ``ha-mode``) type parameter. The default value - should be ``false`` for backward compatibility reasons. - -* ``corosync_class`` or ``pacemaker_class`` reference to a some external - class which should be used for Corosync (Pacemaker) resources definition. - The default value should be ``false`` for backward compatibility reasons. - -* One for ``resource_hash`` parameters being passed into the aforementioned - class above. - -Data model impact ------------------ - -None - -Module API impact ------------------ - -None - -End user impact ---------------------- - -The user will be able to configure Openstack services in a much -more flexible and Highly available way. - -Performance Impact ------------------- - -There would be no performance impact, if default service provider for -Openstack services is used. The performance of Pacemaker provider is -deeply tight with the Pacemaker or Corosync Puppet module chosen by -the user. Anyway, the cluster resources definition for services should -be done only once, hence the performance impact will be the minimal in -overall deployment process and near to none in later operations. - -Deployer impact ---------------------- - -The deployment behavior will not change at all for the case with wrapper -classes in puppet-openstack_extras (openstacklibs). -The only action required would be to include a wrapper classes for Openstack -services in catalog in order to ensure Pacemaker provider for them. -For the approach with an external class reference, the deployer would -have to provide a valid Pacemaker or Corosync class reference for some -external module in catalog and a valid hash of parameters for it. - -Developer impact ----------------- - -None - -Implementation -============== - -Assignee(s) ------------ - -Primary assignee: - bogdando - -Other contributors: - idv1985 - -Work Items ----------- - -* Create a service provider for Pacemaker (HA provider) as a part of the - openstack_extras. - -* Create a basic HA wrapper classes shipped with a generic OCF scripts for - the cluster resources definition and an option to specify a custom OCF - scripts as well. - -* Describe in documentation how HA provider could be used with Puppet modules - for Openstack to configure Openstack services in HA. - -* (optional) Describe in documentation how HA provider could be used to - configure related services, such as RabbitMQ and MySQL in HA. - -Dependencies -============ - -None - -Testing -======= - -The feature should be tested with the rspecs provided. - - -Documentation Impact -==================== - -The feature should be described in the docs for puppet-openstack_extras -(or openstacklibs) module or core Puppet modules for Openstack for the case -with external Corosync (Pacemaker) classes. -New wrapper classes should be described and usage examples provided. - -References -========== - -None diff --git a/specs/juno/use-openstackclient-in-aviator-resources.rst b/specs/juno/use-openstackclient-in-aviator-resources.rst deleted file mode 100644 index 9e3c6e8..0000000 --- a/specs/juno/use-openstackclient-in-aviator-resources.rst +++ /dev/null @@ -1,160 +0,0 @@ -.. - This work is licensed under a Creative Commons Attribution 3.0 Unported - License. - - http://creativecommons.org/licenses/by/3.0/legalcode - -======================================= -Use OpenstackClient in Module Resources -======================================= - -https://blueprints.launchpad.net/puppet-openstacklib/+spec/use-openstackclient-in-module-resources - -This spec proposes to alter the course proposed in blueprint: -use-aviator-in-module-resources. The preferred solution to the problem -description is to use the universal OpenStack command-line client. - -Problem description -=================== - -The original problem is framed in the original Aviator blueprint. - -The problem that this spec proposes to solve is that using the API -directly adds increased complexity which decreases maintainability. The -providers must manage HTTP sessions themselves, which reinvents the -wheel. - -Aviator also does not appear to be actively keeping up with new changes -in OpenStack. It does not yet have support for the Neutron API. It also -only has partial support for the Keystone V3 API, which is an immediate -requirement. The workload to contribute upstream to Aviator to fulfill -these requirements is quite high compared to the workload involved to -incorporate openstackclient. - -Proposed change -=============== - -Work to use Aviator in the base provider in the openstacklib module has -already been done. This work lays out the options that providers can use -for authenticating against the REST APIs. The work to convert the -providers to use the Aviator base provider has not been completed. - -The change would simply swap the calls to the Aviator library with calls -to the openstack command. The base provider will no longer have to -manage sessions itself, which means not having to differentiate between -a password-authenticated session and using a token directly. - -OpenStackClient is actively keeping up with API changes and is rapidly -developing, so we will monitor its progress and work with the developers -to get features we need and fix bugs. - -Alternatives ------------- - -The alternative is to continue on the path with Aviator. - -Data model impact ------------------ - -None. - -Module API impact ------------------ - -The log_file parameter that puppet/util/aviator added to the puppet -types would no longer be necessary since that was a requirement only -for Aviator. - -The OpenStack client is bundled with other OpenStack services so it -needs a manifest to install it explicitly. - -The version of openstackclient available on Debian, Ubuntu, and RedHat -is 0.4.0. A 1.0.0 release will be available by Kilo. In the meantime, -the 0.4.0 version is sufficient for our needs as it can format its -output in CSV format. - -We need to take advantage of OpenStackClient's Keystone API v3 -capabilities in a Juno feature release of the keystone module. In order -for the keystone module to maintain backwards compatibility during this -cycle, we will first incorporate the base provider into the keystone -module, since we cannot bump the dependency on openstacklib without a -major release. Once these changes are backported into the Juno branch, -we will extract the base provider into the openstacklib module in -preparation for the Kilo release. Then we can migrate providers from -the other modules on their master branches, targeting Kilo. - -End user impact ---------------------- - -There should be no end user impact. - -Performance Impact ------------------- - -OpenStackClient may not be as fast as using the API directly, but it is -certainly not slower than using the individual command line clients. -OpenStackClient plans to soon provide the ability to cache resources -locally in order to speed up requests, so using that functionality -should increase performance. - -Deployer impact ---------------------- - -None. - -Developer impact ----------------- - -The parameters of the base provider's request() method can change -slightly to better mirror how parameters will be passed to openstack(), -but this is not a hard requirement as long as all the necessary -information is passed to openstack(). - -Implementation -============== - -Assignee(s) ------------ - -Primary assignee: - krinkle - richm - -Work Items ----------- - -* Rewrite the base provider in openstacklib to reflect these changes. Work - for this has already been started. -* Rewrite the keystone providers to inherit from the new base provider - and utilize its methods. -* Rewrite providers for other modules - -Dependencies -============ - -None - -Testing -======= - -Unit tests will be revised and simplified. Rather than using VCR with -HTTP recorded sessions as fixtures we will simply stub the openstack() -method. - -Documentation Impact -==================== - -None - -References -========== - -* Proofs of concept, still works in progress: - - Base provider: https://review.opendev.org/#/c/134843/ - - keystone_tenant rewritten: https://review.opendev.org/#/c/134844/ - -* Mailing list discussion: - - https://groups.google.com/a/puppetlabs.com/forum/#!topic/puppet-openstack/GJwDHNAFVYw - -* IRC discussion: (starting at 14:36:50) - - http://eavesdrop.openstack.org/meetings/puppet_openstack/2014/puppet_openstack.2014-11-17-14.01.log.html diff --git a/specs/kilo/api-v3-support.rst b/specs/kilo/api-v3-support.rst deleted file mode 100644 index b650223..0000000 --- a/specs/kilo/api-v3-support.rst +++ /dev/null @@ -1,764 +0,0 @@ -.. - This work is licensed under a Creative Commons Attribution 3.0 Unported - License. - - http://creativecommons.org/licenses/by/3.0/legalcode - -=================================================== -Support Keystone v3 API in OpenStack puppet modules -=================================================== - -Launchpad blueprint: - -https://blueprints.launchpad.net/puppet-keystone/+spec/api-v3-support - -Beginning with Icehouse, Keystone has declared the v3 API (URLs with /v3) fully -supported, and beginning with Kilo, Keystone has deprecated the v2 API (URLs -with /v2.0). The OpenStack puppet modules should use the v3 API wherever -possible. Keystone will continue to fully support v2 and v3 at the same time -for the next couple of cycles. - -.. _project-is-tenant-note: -.. note:: Project is used instead of tenant - - Keystone has renamed "tenant" to "project". Everywhere in the v3 API, - `openstack` command line tool, environment variables, Keystone documentation, - and elsewhere, project is used instead of tenant. However, in - puppet-keystone, we still use the keystone_tenant resource. - -Problem description -=================== - -There are a number of features that are only available with the v3 API: - -* The ability to for one user, to delegate to another user, the authority to - perform certain tasks, using the Keystone v3 Trusts extension. For example: - - * Have a service launch an instance on behalf of a user without that user - having to first authenticate (e.g. for auto-scaling at 3 AM). - * Delegate restricted nova API access to (implicitly) untrusted in-instance - processes. - * Provide access to accounts and containers on swift without using ACLs. - * http://techs.enovance.com/5858/role-delegation-in-keystone-trusts - -* The ability to have multiple domains, each with its own separate identity - backend. One of the most important use cases is to put the OpenStack service - accounts in a "service" domain, backed by an SQL identity backend, and have - the default domain (that is, the domain that is used if not explicitly - specified in the request) point to the enterprise LDAP server, both in - read-write and read-only mode. In order to do this, the services will need - to use v3 for authentication and specify the domain for the user and for the - project. - -Proposed change -=============== - -In Keystone, the *domain* is the container for users, groups, and projects. -Other identity resources, such as roles, services, and endpoints, are not -contained within a domain. In order to uniquely identify a Keystone resource -by name, it must be qualified with the domain name. This is a problem with -naming puppet resources, which must have a unique name. The string "::" can be -used to construct a unique Puppet resource name from a name part and a domain -name part. However, existing manifests expect to be able to name resources -without the domain part, and it may be difficult for operators to change -manifests to make all Keystone resource names have the domain in them. -Therefore, the puppet-keystone v3 support implementation must support current -manifests as much as possible. Consider this case:: - - # Composition layer - class { '::glance::keystone::auth': - region => $region, - password => $glance_user_password, - public_address => $public_url, - admin_address => $admin_url, - internal_address => $internal_url, - } - - # puppet-glance - class glance::keystone::auth( - $password, - $email = 'glance@localhost', - $auth_name = 'glance', - $configure_user = true, - $configure_user_role = true, - ... - $tenant = 'services', - ... - ) { - ... - keystone::resource::service_identity { $auth_name: - configure_user => $configure_user, - configure_user_role => $configure_user_role, - ... - tenant => $tenant, - ... - } - ... - } - - # puppet-keystone - define keystone::resource::service_identity( - ... - $auth_name = $name, - ... - $tenant = 'services', - ... - ) { - ... - keystone_user { $auth_name: - ensure => 'present', - enabled => true, - password => $password, - email => $email, - tenant => $tenant, - ignore_default_tenant => $ignore_default_tenant, - domain => $user_domain_real, - } - } - - if $configure_user_role { - keystone_user_role { "${auth_name}@${tenant}": - ensure => 'present', - roles => $roles, - } - } - -The puppet-keystone code must be able to use just `glance` as the name without -it having to be qualified by a domain. The puppet-keystone code must be smart -enough to figure out that there is only one user named `glance` among all of -the domains, figure out which domain it is in, and use it. Same with the -`service` project, and with the `glance@service` user role. As long as there -is only one resource with the given name, the code should work. However, if -there is a `glance` user in `domain1`, and a `glance` user in `domain2`, it is -the responsibility of the manifest writer to fully qualify both user names. -There is no way for puppet-keystone, when given a username of `glance`, to know -if it is referring to `glance::domain1` or `glance::domain2`. We will need to -warn puppet users that the use of "::" in Keystone resource names (such as a -user named "foo::bar") is not supported. - -.. _back-compat-note: -.. note:: Resource names with "::domainname" are not required if the resource names are unique - - One of the goals of this effort is to preserve backwards compatibility with - existing manifests and other related Puppet code. You do not have to declare - a resource name with "::domainname" if the base resource name is unique among - all domains. For example, if you have only one user named `glance` among all - domains, you can refer to this using only 'glance' in keystone_user and - keystone_user_role resources. The puppet-keystone code will determine if - there is only one user named glance among all domains, and will know that if - you just specify `glance` it means the unique user named glance in whatever - domain it happens to be in. However, if the resource name is **not** unique, - you **must** specify the '::domainname' part in the resource name. - -.. _finding-unique-resources-note: -.. note:: How to find unique resources - - You can use `openstack user list --long` and `openstack project list --long` - to search through all domains (with admin credentials - that is, use a user - that has the role `admin`), then grep for users that you want to ensure are - unique. If the users are coming from your enterprise identity provider - (e.g. an LDAP server, an SQL database), use the tools provided to search for - users. The `keystone_user` and `keystone_tenant` resource code will both - search through all domains looking for user and project resources, so you can - also use `puppet resource keystone_user` and `puppet resource - keystone_tenant` to see what Puppet's "view" is of the deployment. - -Puppet resource declarations that have a name with "::" and a domain part will -look like this:: - - keystone_user { 'admin::services': ...} - keystone_user { 'admin::users': ...} - keystone_tenant { 'admin::services': ...} - -These would declare two different admin users - one for the "services" domain, -and one for the "users" domain, and create a project called "admin" in -the services domain. - -The current keystone_user_role resource looks like this:: - - keystone_user_role { 'glance@services': roles => ['admin'] } - -This assigns the user "glance" to the role of "admin" in the project -"services". With Keystone v3, if you need to specify a domain name, the -declarations will look like this:: - - keystone_user_role { 'sysadmin::admin_domain@administrators::services': roles => ['admin']} - keystone_user_role { 'sysadmin::admin_domain@::users': roles => ['admin']} - -This would assign the user "sysadmin" in the domain "admin_domain" to the role -"admin" in the project "administrators" in the domain "services". The last one -would assign the user "sysadmin" in the domain "admin_domain" the role of -"admin" in the domain "users". If the project name (the string after the "@" -character) starts with "::", `keystone_user_role`, will assume it is a domain -name and this role is a domain scoped role instead of a project scoped role. - -When you name a resource with '::domainname', you **must** consistently use -that name everywhere. For example, if you need to have multiple projects in -different domains with the name `service`, you will need to declare the -resource like this: `keystone_tenant { 'service::domain1': ...}`. If you -use that project in a keystone_user resource, you **must** use it like this: -`keystone_user { 'username': tenant => 'service::domain1', ... }`. If you use -that project in a keystone_user_role resource, you **must** use it like this: -`keystone_user_role { 'username@service::domain1': ... }`. - -The resources that are part of a domain, namely keystone_user, keystone_tenant, -keystone_group, will have a **domain** parameter. The domain parameter will -override any domain specified in the name. For example, if you have:: - - keystone_user { 'user::foodomain': - domain => 'bardomain', - } - -The domain parameter 'bardomain' would override the domain specified in the -resource title 'foodomain'. In this case, the domain in the title would just -serve to make the resource unique (as opposed to "user" or -"user::anotherdomain"). - -Why have both a domain parameter and a domain in the resource name? There may -be cases where you want to override the domain. Using a parameter makes it -easier to use some of the puppet facilities for doing overrides. In most -cases, the domain parameter would not be used. Instead, the domain would be -specified as part of the resource name, in order to unique-ify the resource -name. - -.. note:: About the "@" character in keystone_user_role - - The "@" character is a valid character in Keystone user names. The way - keystone_user_role works is that everything before the **last** "@" is part - of the username, and everything after the **last** "@" is part of the project - name. So "user@domain.com@project" has a username of "user@domain.com" and a - project name of "project". This also means that the "@" character is **NOT** - a valid character in project names or in domain names. Keystone v3 doesn't - change this, this is the way it has always been, as a side effect of choosing - "@" as the delimiter character for keystone_user_role. - -For legacy applications, there are two cases: - -* The v2.0 api is being used - using a URL ending in "/v2.0" and using - OpenStack with `OS_IDENTITY_API_VERSION=2`, or omitting the api version - altogether. In this case, Keystone, not puppet-keystone, will implicitly add - a 'default domain' to the request. The default domain is specified in the - Keystone config with the **identity/default_domain_id** configuration - parameter. - -.. _domain-search-note: - -* The v3 api is being used - using a URL ending in "/v3" and using OpenStack - with `OS_IDENTITY_API_VERSION=3`. In this case, the Keystone server side - will **not** implicitly add a default domain - the domain must be explicitly - specified on the client side, either in the resource title (`keystone_user { - 'admin::domain' }`) or in a parameter (`keystone_user {'admin': domain => - 'domain'}`). In order to accommodate legacy puppet code that does not - specify a domain in either of these two ways, the keystone provider will - attempt to determine a domain to use by the following methods in order: - - * default_domain_id from keystone.conf - * 'Default' - the Keystone "default" default domain, if none is specified in - identity/default_domain_id in keystone.conf - -.. note:: Using default_domain_id and other settings from keystone.conf - - Using the default_domain_id from keystone.conf is considered *deprecated*. - Developers *must* allow the domain to be explicitly provided everywhere, and - users should specify the domain wherever possible. - -Keystone v3 provides two new API objects - *domain* and *group*. There will -need to be puppet-keystone resources for each of these - **keystone_domain** -and **keystone_group**. In order to create roles with groups, there will need -to be a **keystone_group_role** resource. This resource will work exactly like -keystone_user_role, except for groups. - -The **openstack** command line tool provided by the python-openstackclient -package has full Keystone v3 support. This command will be used by puppet to -access the Keystone v3 API and features. Version 1.0.2 or later of this -command is required for all features. The `puppet-openstacklib` `openstack` -provider will support using Keystone v2 or v3 credentials. - -All of the domain-aware Keystone resources (such as keystone_user) will always -add a *domain* argument for those operations which require a domain (such as -creating a user), or use the resource *id* instead of the resource *name* -wherever possible to avoid having to use the domain. In Keystone, the *id* is -guaranteed to be unique among all domains. - -For trust support, a **keystone_trust** resource will be added. This resource -will be used to manage trusts. - -**Puppet Modules Other Than puppet-keystone** - -There are a few changes that will need to be made to every OpenStack Puppet -module to allow Keystone v3 authentication: - -* Allow specifying the domain for users and projects - -Any place where a manifest specifies a user or project used for Keystone -authentication will need to be changed to add parameters for the domain of the -user and the domain of the project (and renaming tenant to project is -probably a good idea since Keystone uses *project* in Icehouse and later -:ref:`Use Project `). - -In addition, the resource name may be specified as `name::domainname`. The -puppet-keystone code will handle this case. It should not be necessary for -other puppet modules to split resource names by "::" to get the base name part -and the domain part. It should just pass these names down to the -puppet-keystone code which should handle it. - -For ease of use, an additional *default domain* parameter can be added which -will be used for both the user and project. For example, from glance:: - - class glance::api( - ... - $keystone_tenant = 'services', - $keystone_user = 'glance', - ... - $keystone_user_domain = undef, - $keystone_project_domain = undef, - $keystone_default_domain = undef, - ... - ) - -`$keystone_user_domain` is used to specify the domain of the `$keystone_user`, -and `$keystone_project_domain` is used to specify the domain of the -`$keystone_tenant`. If the user or the project domain is omitted, and -`$keystone_default_domain` is specified, then that value will be used for the -missing user or project domain. Puppet modules that pass authentication -parameters will need to be able to pass domain arguments. For example, from -`puppet-glance/lib/puppet/providers/glance.rb`:: - - def self.request(service, action, properties=nil) - super - rescue Puppet::Error::OpenstackAuthInputError => error - glance_request(service, action, error, properties) - end - -That is, try the `openstack` request with the provided credentials, and if that -fails, fall back to try the request again with the credentials from the glance -config file. The module local request method (e.g. `glance_request`) will need -to be able to pass in the user domain, project domain, and other v3 -authentication parameters from its config file as authentication arguments. - -* Use `keystone::resource::authtoken` and the new `keystone_authtoken` parameters in config files - -The application config files are usually managed with a config resource. For -example, the file `/etc/glance/glance-api.conf` is managed with a -`glance_api_config` resource, `/etc/glance/glance-registry.conf` is managed -with a `glance_registry_config` resource, etc. The config section that -contains the Keystone authentication parameters is `keystone_authtoken`. For -v3, there are some name changes (`admin_user => username`) and several new -parameters for domains and other v3 resources. To make it easier to manage -this section, a new Keystone resource `keystone::resource::authtoken` has been -added. For example, instead of doing this:: - - glance_api_config { - 'keystone_authtoken/admin_tenant_name': value => $keystone_tenant; - 'keystone_authtoken/admin_user' : value => $keystone_user; - 'keystone_authtoken/admin_password' : value => $keystone_password, - secret => true; - ... - } - -manifests should do this instead:: - - keystone::resource::authtoken { 'glance_api_config': - username => $keystone_user, - password => $keystone_password, - auth_url => $real_identity_uri, - project_name => $keystone_tenant, - user_domain_name => $keystone_user_domain, - project_domain_name => $keystone_project_domain, - default_domain_name => $keystone_default_domain, - cacert => $ca_file, - ... - } - -The use of `keystone::resource::authtoken` makes it easy to avoid mistakes, -and makes it easier to support some of the newer authentication types coming -with Keystone Kilo and later, such as Kerberos, Federation, etc. -`keystone::resource::authtoken` knows how to handle the case where the -`username` is specified as `user::domainname` and will use the `domainname` part -as the `user_domain_name` if the `user_domain_name` is not provided. Same with -`project_name`. - -* Do not use a version suffix in Keystone authentication URLs - -For example, for any URL used to perform authentication to Keystone, such as -provided by the `OS_AUTH_URL`, `--os-auth-url`, or similar configuration -parameters, do not add a Keystone API version suffix to the URL. For example, -use `http://keystone.host:35357/` instead of `http://keystone.host:35357/v2.0/` -or `http://keystone.host:35357/v3/`. Both the `openstack` resource provider, -and the `keystonemiddleware` used for service to Keystone authentication, will -determine if v3 can be used based on the parameters given. - -Alternatives ------------- - -There aren't really any alternatives to support for domains, groups, and -trusts. - -Data model impact ------------------ - -* The addition of the keystone_trust, keystone_domain, keystone_group, - keystone_group_role resources - -This will mostly be using the existing resources as a template to create the -new resources. This should be very straightforward. - -* The addition of domain and group to the other puppet-keystone resources - -For example, being able to create a user in a specific domain will require the -addition of domain property to keystone_user. Likewise with projects and -keystone_tenant. For service accounts, the resource -keystone::resource::service_identity hides most of the actual implementation, -so it should be easy to assign domains to service accounts without having to -change other puppet modules. - - -Module API impact ------------------ - -Each API method which is either added or changed should have the following, -depending upon if it is a new class or an addition to an existing class. - -* New defined resource types: - - * Name - - keystone_domain - - * Description - - This resource represents a Keystone domain. It can optionally be used to - ensure that the default_domain_id is set. - - * Parameters for keystone_domain: - - name : Domain name; - string; required; namevar - enabled : Domain is enabled for use; - boolean; optional: default to True - description : Domain description; - string; optional; default to undef - id : Domain id assigned by Keystone; - string; required; read-only - is_default : If this is true, the specified domain is the default domain, - and the provider will ensure that this is the [identity] - default_domain_id value in the keystone.conf file; - boolean; optional: default to False - - * Example use:: - - keystone_domain { 'services': - ensure => present, - description => 'Domain to use for service accounts', - enabled => true, - } - - * Name - - keystone::resource::authtoken - - * Description - - This resource provides a convenient, safe way to update the Keystone - authentication parameters in application config files which use a - `*_config` resource. - The username and project_name parameters may be given in the form - "name::domainname". The authtoken resource will use the domains in - the following order: - 1) The given domain parameter (user_domain_name or project_domain_name) - 2) The domain given as the "::domainname" part of username or project_name - 3) The default_domain_name - - * Parameters for keystone::resource::authtoken - - [*name*] - The name of the resource corresponding to the config file. For example, - keystone::authtoken { 'glance_api_config': ... } - Where 'glance_api_config' is the name of the resource used to manage - the glance api configuration. - string; required - - [*username*] - The name of the service user; - string; required - - [*password*] - Password to create for the service user; - string; required - - [*auth_url*] - The URL to use for authentication. - string; required - - [*auth_plugin*] - The plugin to use for authentication. - string; optional: default to 'password' - - [*user_id*] - The ID of the service user; - string; optional: default to undef - - [*user_domain_name*] - (Optional) Name of domain for $username - Defaults to undef - - [*user_domain_id*] - (Optional) ID of domain for $username - Defaults to undef - - [*project_name*] - Service project name; - string; optional: default to undef - - [*project_id*] - Service project ID; - string; optional: default to undef - - [*project_domain_name*] - (Optional) Name of domain for $project_name - Defaults to undef - - [*project_domain_id*] - (Optional) ID of domain for $project_name - Defaults to undef - - [*domain_name*] - (Optional) Use this for auth to obtain a domain-scoped token. - If using this option, do not specify $project_name or $project_id. - Defaults to undef - - [*domain_id*] - (Optional) Use this for auth to obtain a domain-scoped token. - If using this option, do not specify $project_name or $project_id. - Defaults to undef - - [*default_domain_name*] - (Optional) Name of domain for $username and $project_name - If user_domain_name is not specified, use $default_domain_name - If project_domain_name is not specified, use $default_domain_name - Defaults to undef - - [*default_domain_id*] - (Optional) ID of domain for $user_id and $project_id - If user_domain_id is not specified, use $default_domain_id - If project_domain_id is not specified, use $default_domain_id - Defaults to undef - - [*trust_id*] - (Optional) Trust ID - Defaults to undef - - [*cacert*] - (Optional) CA certificate file for TLS (https) - Defaults to undef - - [*cert*] - (Optional) Certificate file for TLS (https) - Defaults to undef - - [*key*] - (Optional) Key file for TLS (https) - Defaults to undef - - [*insecure*] - If true, explicitly allow TLS without checking server cert against any - certificate authorities. WARNING: not recommended. Use with caution. - boolean; Defaults to false (which means be secure) - - * Example use:: - - keystone::resource::authtoken { 'glance_api_config': - username => $keystone_user, - password => $keystone_password, - auth_url => $real_identity_uri, - project_name => $keystone_tenant, - user_domain_name => $keystone_user_domain, - project_domain_name => $keystone_project_domain, - default_domain_name => $keystone_default_domain, - cacert => $ca_file, - } - -* New parameters for keystone_user, keystone_tenant: - - * Name - - domain : Domain name; - string; optional: default see :ref:`Domain Search Note ` - - * Description - - Name of the domain to which the resource belongs. - - * Resources affected: - - keystone_user - keystone_tenant - - * Reason for addition: - - With Keystone v3, you can have a resource with the same name in multiple - domains. It is the combination of name and domain that uniquely identifies - a resource. With Keystone v3, users, groups, and projects exist inside - domains, so the domain must be specified when creating these resources. - -* Changed parameters: - - * Name: - - title : The Puppet resource title; - string; required; - - * Resources affected: - - keystone_user - keystone_tenant - keystone_user_role - keystone_group - keystone_group_role - keystone::roles::admin - keystone::resource::service_identity - - * Reason for change: - - With Keystone v3, you can have a resource with the same name in multiple - domains. In Puppet, you cannot have two resources with the same title. - With Keystone resources, the title is usually also the name of the - resource. By using "name::domain" in the resource title, you can uniquely - identify the resource to Puppet, as well as specify both the resource name - and domain. The affected resources have been changed to look for a title - in the form "name::domain". - - * Example use:: - - keystone_user { 'admin::admin_domain': - ensure => present, - enabled => true, - tenant => 'admin', - email => 'admin@localhost', - password => 'itsasecret', - } - - -End user impact ---------------- - -There should be no mandatory end user impact. Existing manifests should -continue to work exactly as before. See also :ref:`Backwards Compatibility Note `. - -Users wanting to create users and projects in domains other than the default -domain will need to change their manifests in order to pass in the domain or -specify the domain in the resource title. Note that there may be several -layers of resources/classes in manifests before the actual declaration of the -keystone resource, so intermediate resources/classes may need to be changed so -that the domain can be passed all the way down to the keystone resource. - -Performance Impact ------------------- - -There will be additional domain lookups, in order to map domain ids to domain -names in certain calls. For example, when creating a user, the create call -will return the domain id, not the domain name, but the domain name is needed -for resource name/title/domain comparisons. The keystone provider provides -utility methods for this, and will cache the results of domain lookups. - -Deployer impact ---------------- - -None other than what has been already mentioned. - -Developer impact ----------------- - -Developers will have to make themselves aware of the new Keystone v3 -authentication parameters mentioned in the links and elsewhere in this -documentation, and will need to make sure composition layers, config files, -etc. allow the specification of those parameters such as user domains, project -domains, etc. - -Implementation -============== - -Assignee(s) ------------ - -Primary assignee: - rmeggins (IRC nick richm) - -Other contributors: - gilles@redhat.com (IRC nick gildub) - ichavero (IRC nick imcsk8) - -Work Items ----------- - -puppet-keystone - -* Create keystone_domain resource -* Create domain splitting utility code -* Create domain id to name mapping code -* Add domain support to keystone_user -* Add domain support to keystone_tenant -* Add domain support to keystone_user_role -* Add default domain support to class keystone -* Add admin user domain, admin tenant domain, and service tenant domain to - class keystone::roles::admin -* Create keystone::resource::authtoken -* Convert keystone_service and keystone_endpoint to use the v3 api -* Convert keystone_role to use the v3 api - -Other puppet-modules - -* Allow specifying the domain for users and projects -* Use `keystone::resource::authtoken` and the new `keystone_authtoken` - parameters in config files -* Do not use a version suffix in Keystone authentication URLs - -Dependencies -============ - -* https://blueprints.launchpad.net/puppet-openstacklib/+spec/use-openstackclient-in-module-resources - - * Use OpenstackClient in Module Resources - * puppet-keystone has already been converted to use the openstack provider. - All other puppet modules will need to be converted to use the openstack - provider from puppet-openstacklib. -* https://blueprints.launchpad.net/puppet-openstacklib/+spec/auth-consolidation - - * Restructures authentication for resource providers - * puppet-keystone has already been converted to do this. - All other puppet modules will need to be converted. -* python-openstackclient version 1.0.2 or later is required for full - functionality. 1.0.1 may be used for testing purposes, but will not provide - the full functionality required. -* python-keystonemiddleware version 1.3 or later is required for OpenStack - services to perform service to Keystone v3 authentication. - -Testing -======= - -If and when tempest tests are available for puppet-keystone, tests of the -functionality in this blueprint should be added. - - -Documentation Impact -==================== - -The README.md and the examples in the examples directory will be updated. - -References -========== - -Openstack client: http://docs.openstack.org/developer/python-openstackclient/ - -Keystone v3 REST API: http://developer.openstack.org/api-ref-identity-v3.html - -Trust extension: -https://github.com/openstack/identity-api/blob/master/v3/src/markdown/identity-api-v3-os-trust-ext.md - -and: https://wiki.openstack.org/wiki/Keystone/Trusts - -Service to Keystone v3 authentication: -http://www.jamielennox.net/blog/2015/02/23/v3-authentication-with-auth-token-middleware/ - -New Keystone v3 authentication parameters in config files: -http://www.jamielennox.net/blog/2015/02/17/loading-authentication-plugins/ diff --git a/specs/kilo/auth-restructure.rst b/specs/kilo/auth-restructure.rst deleted file mode 100644 index 2678781..0000000 --- a/specs/kilo/auth-restructure.rst +++ /dev/null @@ -1,199 +0,0 @@ -.. - This work is licensed under a Creative Commons Attribution 3.0 Unported - License. - - http://creativecommons.org/licenses/by/3.0/legalcode - -================================================================== -Restructure authentication for OpenStack Puppet resource providers -================================================================== - -Launchpad blueprint: - -https://blueprints.launchpad.net/puppet-openstacklib/+spec/auth-restructure - -Since OpenStack Puppet modules providers are managing their resources using -python-openstackclient (OSC), the 'openstack' CLI, to interface to OpenStack, -the mechanism which is used for holding authentication data is causing -unnecessary complexity and an inconsistent behavior for providers depending on -their context usage. - - -Problem description -==================== - -The authentication data is currently stored as a type parameter ':auth'. -Having the authentication information as type parameter makes the credentials -available in an instance context but not in class context such as when a -resource is used in general context, for example in self.instances method. - -This has several consequences: - -1. It creates code duplication down the road to work around the fact there -isn't authentication data provided in a general context, for example in keystone -provider: - -* lib/puppet/provider/keystone_tenant/openstack.rb#L60 - -* lib/puppet/provider/keystone_tenant/openstack.rb#L73 - -When dealing with authentication, each provider has to duplicate every method -in regards of instance or class context. - -2. Consequently, it appears that even in a general context, authentication -information has to be obtained from somewhere. Which means the authentication -mechanism needs to be revisited to have a consistent way of setting the -credentials in a consistent way no matter the context. - -Also, independently of this problem but related to the authentication data, a -security issue came up when using command line options to pass credentials to -openstack command, for instance '--os_password=blah'. The risk is for a spawned -process to have the information displayed, i.e. with a 'PS' command. - -And finally, a change in the way the credentials are obtained changes with step -2. which formalizes the default RC file to be used if needed: - -1. Environment variables OS_* are used by default and will be overridden only if - defined below - -2. If not enough credentials then OS_* variables defined in RC file to be used. - The default is located current user (per execution of Puppet) home directory: - $HOME/openrc - -3. If authentication fails it's up to the provider to implement a failsafe to - use configuration file to find the credentials. - -Proposed change -=============== - -Therefore the need to review the architecture of handling the authentication -data while offering the same features to the OpenStack providers. - -The fist change removes the :auth parameter from the types. -This is replaced with a combination of a auth module, and a credentials object. - -Replacing the polymorphism approach used by providers inheriting from -Puppet::Provider::Openstack class by a module. -The authentication related methods are moved to the module. - -The module creates an interface to the provider classes. -When a provider 'extend' the module, all the methods defined in the module -are available to the 'inheriting' class as class methods. - -The authentication methods are acting at a sublevel, leaving the superclass -Puppet::Provider::Openstack to deal purely interfacing with openstack client. - -The openstacklib structure is used as follow, using keystone provider cases: - -class Puppet::Provider::Openstack -end - -class Puppet::Provider::Keystone < Puppet::Provider::Openstack -end - -class Puppet::Provider::Keystone_tenant < Puppet::Provider::Keystone -end - -The module is extended by the provider intermediate class, for instance -class Puppet::Provider::Keystone < Puppet::Provider::Openstack -extend Puppet::Provider::Openstack::Auth -end - -Secondly a credentials class Puppet::Provider::Openstack::Credentials -makes manipulating the authentication data not only easier but allows a class -instance variable @credentials to hold the information into a dedicated object. - -To address the security issue point: -Credentials passed on a CLI must be forbidden in order to not be visible via PS -commands. - -This is enforced by using of `withenv` method from Puppet Util library could help: -https://github.com/puppetlabs/puppet/blob/3.0.0/lib/puppet/util.rb#L39-L51 - -Note: - Although using ENV instead of CLI parameters doesn't remove issues such as: - "puppet resource keystone_user foo email=foo@example.com password=test" - In order to avoid the above, the related provider type API would have to be - changed as well. - -Alternatives ------------- - -This is an alternative way to the existing solution, other was have not been -envisaged so far. - -Data model impact ------------------ - -The goal of this effort is: no data model impact. Existing manifests should -continue to work as before. - - -Module API impact ------------------ - -None other than what has been already mentioned. - -End user impact ---------------------- - -There should be no mandatory end user impact. Existing manifests should -continue to work exactly as before. - -Operations wanting use different authentication should be able to provide it. - -Performance Impact ------------------- - -The `request` method and helper methods used by it should cache the contents of -files instead of opening/reading/parsing/closing every time. - - -Deployer impact ---------------------- - -None other than what has been already mentioned. - -Developer impact ----------------- - -None. - -Implementation -============== - -Assignee(s) ------------ - -Primary assignee: - gilles@redhat.com (IRC nick gildub) - -Other contributors: - rmeggins (IRC nick richm) - -Work Items ----------- - -* Implement the code described in the "Module API impact" section. - -Dependencies -============ - -None - -Testing -======= - -Write tests for the new beaker CI test framework. - - -Documentation Impact -==================== - -The README.md and the examples in the examples directory will be updated. - -References -========== - -Openstack client: http://docs.openstack.org/developer/python-openstackclient/ -Openstack client config file: http://docs.openstack.org/developer/python-openstackclient/configuration.html#configuration-files diff --git a/specs/kilo/master-policy.rst b/specs/kilo/master-policy.rst deleted file mode 100644 index 9ed0267..0000000 --- a/specs/kilo/master-policy.rst +++ /dev/null @@ -1,124 +0,0 @@ -.. - This work is licensed under a Creative Commons Attribution 3.0 Unported - License. - - http://creativecommons.org/licenses/by/3.0/legalcode - -======================== -Define our master policy -======================== - -The blueprint has been created for puppet-nova, but affects all modules: -https://blueprints.launchpad.net/puppet-openstack/+spec/master-policy - -Problem description -=================== - -Here are the problems that lead us to write this blueprint: - -* OpenStack projects use to update their configuration files and API every - release, with all the time backward compatibility support. When using - deprecated configuration parameters, OpenStack projects uses WARNING level - in logging files (visible when the program starts), that warn operators to - update configuration files so they have the latest options. -* Since the beginning of the Puppet modules project, master branch has always been - the development branch and be used to integrate features from OpenStack master - or very recent release. Until now, master branch always meant to be used to test - the last stable OpenStack release. -* Over the time, our community grew and we've got contributions and - more feedback from operators world that complained master branch was broken - for a recent stable release. -* When fixing a bug in master, we often miss to backport it to stable branches - because it requires manual work (cherry-pick). This is problem #4: what can - we backport to stable branches? - -Proposed change -=============== - -* Accept that master branch is not supposed to work on stable releases of OpenStack. -* Functional testing CI jobs should pass using the latest testing package repositories - from the Ubuntu and RHEL distributions. -* Submit a feature in master only if it can be tested by functional testing CI jobs. - We make an announcement on the mailing-list each time we update the repositories for - the functional tests. -* Help developers to easily backport patches to stable branches when needed. - -Alternatives ------------- - -* Creating a branch called 'future/' for those changes that would get merged - back into master and then into 'stable/' when that branch is created. - -Data model impact ------------------ - -Data model needs to be backward compatible at least 2 releases. - -Module API impact ------------------ - -Module API needs to be backward compatible at least 2 releases. - -End user impact ---------------------- - -None. - -Performance Impact ------------------- - -None. - -Deployer impact ---------------------- - -Deployers will need to be more careful if they used to run master branches. - -* use master if they target a deployment with the current development version. -* use stable branches if they plan to deploy a stable version of OpenStack. - -Developer impact ----------------- - -Developers will need to figure if their patch can be tested by the current state of master. -Also, they will need to be more engaged in backport policy and make sure to cherry-pick interesting -bugfixes and features to the right stable branches. - -Implementation -============== - -Assignee(s) ------------ - -Primary assignee: - emilienm - -Work Items ----------- - -None. - -Dependencies -============ - -None. - -Testing -======= - -Beaker jobs are in place and working on master (which is running Kilo at this time). - -Documentation Impact -==================== - -We need to update the Wiki to explain this policy to our contributors. - -References -========== - -* Mailing list discussion: - - http://lists.openstack.org/pipermail/openstack-dev/2015-April/061640.html - -* Etherpad: - - https://etherpad.openstack.org/p/puppet-openstack-master-policy - - https://etherpad.openstack.org/p/liberty-summit-design-puppet-master-branch diff --git a/specs/liberty/enabling-federation.rst b/specs/liberty/enabling-federation.rst deleted file mode 100644 index b9a1d94..0000000 --- a/specs/liberty/enabling-federation.rst +++ /dev/null @@ -1,270 +0,0 @@ -.. - This work is licensed under a Creative Commons Attribution 3.0 Unported - License. - - http://creativecommons.org/licenses/by/3.0/legalcode - -=================== -Enabling Federation -=================== -:tags: federation - -`bp enabling-federation `_ - -The purpose of this spec is to provide an efficient way for cloud -administrators to configure their Keystone as a Service Provider or Identity -Provider in order to use Identity Federation. - -Problem description -=================== - -As a cloud administrator, I want a fast and convenient way to configure my -Keystone (Kilo version or newer) as a Service Provider or as an Identity -Provider. Nowadays, the manual configuration of such features can be -cumbersome and error prone. - - -Proposed change -=============== - -Introduce two new classes, one to configure Keystone as a Service Provider -and the other to configure Keystone as an Identity Provider. - -* Service Provider - - Keystone as Service Provider can be configured in three different ways: - - Using OpenID Connect protocol. - - Using SAML protocol with mellon module. - - Using SAML protocol with Shibboleth module. - - Each possibility mentioned above will have a class with the proper - attributes to configure Keystone files. - - As attributes for this class we can have: - - method: - The method to be used for federation authentication. - - plugin: - The plugin for the authentication method. - -* Identity Provider - - There will be a class identity_provider to configure Keystone as an Identity - Provider, by installing the necessary packages and adding the necessary - configuration to the keystone.conf file. Currently Keystone can only provide - SAML assertions. - - - As attributes for this class we can have: - - * Required - - - certfile: - Path of the certfile for SAML signing. The attribute ssl_ca_certs from - Keystone can be used. - - keyfile: - Path of the keyfile for SAML signing. The attribute ssl_ca_key from - Keystone can be used. - - idp_entity_id: - Entity ID value for unique Identity Provider identification. - - idp_sso_endpoint: - Identity Provider Single-Sign-On service value, required in the Identity - Provider's metadata. - - idp_metadata_path: - Path to the Identity Provider Metadata file. - - * Optional - this attributes will be undef. - - - idp_organization_name: - Organization name the installation belongs to. - - idp_organization_display_name: - Organization name to be displayed. - - idp_organization_url: - URL of the organization. - - idp_contact_company: - Company of contact person. - - idp_contact_name: - Given name of contact person - - idp_contact_surname: - Surname of contact person. - - idp_contact_email: - Email address of contact person. - - idp_contact_telephone: - Telephone number of contact person. - - idp_contact_type: - Contact type. - - To know more about this attributes see `Table 7.28 `_. - - -.. note:: - For the Federated Identity feature, any web server is allowed since it - supports SAML or OpenID Connector. In this spec we are only considering the - use of Apache, since it supports both and have more documentation. To know - more about some values for the attributes see reference number two. - -.. note:: - For the Service Provider, there are some packages that Keystone needs. - For example, in a Debian based distribution: the packages - ``libapache2-mod-shib2`` or ``libapache-mod-auth-mellon`` for SAML2 support - and ``libapache2-auth-openidc`` for OpenID Connect support. - -.. note:: - For the Identity Provider, there are some packages that Keystone needs. - For example, in a Debian/Ubuntu distribution: the packages ``pysaml2`` and - ``xmlsec1`` are necessary. - -.. note:: - The apache packages required for the Service Provider will be installed - using the defined type ``apache::mod`` from puppetlabs-apache, according - to the selected module. - -.. note:: - Only the configurations that belongs to Keystone's configuration files will - be applied by puppet. - - -Alternatives ------------- -Keep these setups as they are right now: manually install packages and add -necessary changes to configuration files. - - -Data model impact ------------------ - -None - -Module API impact ------------------ - -Everything has been already mentioned in Proposed change. - - -End user impact ---------------------- - -None - -Performance Impact ------------------- - -None - -Deployer impact ---------------------- - -To use this the modules from this feature the cloud operator/admin will need -to apply during or after Keystone is installed and running over apache. - -``site.pp`` example - Keystone as a Service Provider using Mellon:: - - class { 'keystone::federation::mellon': - idps_urls => 'https://ipa.rdodom.test/idp', - saml_dir => '/etc/httpd/saml2/test', - http_conf => '/etc/httpd/conf.d/keystone-mellon.conf', - service => 'keystone', - saml_base => '/v3', - saml_auth => 'OS-FEDERATION/identity_providers/ipsilon/protocols/saml2/auth', - saml_sp => 'mellon', - saml_sp_logout => 'logout', - saml_sp_postresp => 'postResponse', - enable_ssl => false, - sp_port => 5000, - } - -``site.pp`` example - Keystone as an Identity Provider:: - - class { 'keystone::federation::identity_provider': - idp_entity_id => 'https://keystone.example.com/v3/OS-FEDERATION/saml2/idp', - idp_sso_endpoint => 'https://keystone.example.com/v3/OS-FEDERATION/saml2/sso', - idp_metadata_path => '/etc/keystone/saml2_idp_metadata.xml', - } - - - -Examples of the configurations added to Keystone and Apache can be found below: - -**For Identity Provider:** - -See topic `Keystone as an Identity Provider (IdP) `_. - -**For Service Provider** - -See topic `Keystone as a Service Provider (SP) `_. - -* For Shibboleth configuration see `Setup Shibboleth - `_. - -* For OpenID configuration see `Setup OpenID Connect - `_. - -* For mod_auth_mellon, see `Setup Mellon - `_. - - - -Developer impact ----------------- - -None - -Implementation -============== - -Assignee(s) ------------ - -Primary assignee: - iurygregory - - -Work Items ----------- - -* Create a class for the Identity Provider configuration, which will apply - the extra configurations to the Keystone configuration file and install all - necessary packages to make Keystone work as Identity Provider. -* Write tests to ensure that the Identity Provider configuration is valid. -* Create one class for each possibility of Service Provider. -* Write tests to ensure that each class of Service Provider is valid. -* Provide documentation in README to explain how to use federation classes -* Provide some manifest example in examples directory with a real deployment - with shibboleth, by using eventual external module for that. - -Dependencies -============ - -* The Keystone version should be at least stable/kilo. -* This feature will be only supported if Keystone is running over an Apache. - -Testing -======= - -* Create spec tests files for each configurable parameter used by the new - Identity/Service Providers classes, to ensure that all applied settings - are valid. -* Create functional tests with acceptance. - -Documentation Impact -==================== - -Add examples in the puppet-keystone repository for both classes. - - -References -========== - -1. Summit video: https://www.youtube.com/watch?v=PxNM8tBdCs4 -2. http://docs.openstack.org/kilo/config-reference/content/config_overview.html - Chapter 7. Identity service - Identity service configuration - - for identity provider take a look at [saml] - - for service provider take a look at [auth] -3. http://rodrigods.com/ -4. http://irclog.perlgeek.de/puppet-openstack/2015-05-19 - start: 19:26 -5. http://docs.openstack.org/developer/keystone/configure_federation.html - diff --git a/specs/liberty/support-for-keystone-domain-configuration.rst b/specs/liberty/support-for-keystone-domain-configuration.rst deleted file mode 100644 index 5c30d2c..0000000 --- a/specs/liberty/support-for-keystone-domain-configuration.rst +++ /dev/null @@ -1,140 +0,0 @@ -.. - This work is licensed under a Creative Commons Attribution 3.0 Unported - License. - - http://creativecommons.org/licenses/by/3.0/legalcode - -============================ -Support domain configuration -============================ -:tags: keystone,domain - -`Launchpad blueprint `_ - -Offer a way to configure multiple domains for Openstack with keystone -API v3. - -Problem description -=================== - -As a deployer, I would like to install OpenStack keystone running API -v3 and be able to configure multiple domains. - -This requires multiple keystone configuration files. Openstack expects -such configuration in a file named ``keystone.$domain.conf`` in a -directory defined by ``identity/domain_config_dir`` in -``keystone.conf``. It's ``/etc/keystone/domains`` by default. - -Proposed change -=============== - -Make a new provider ``keystone_domain_config``. The syntax would be to -allow the use of the domain in the resource name:: - - keystone_domain_config { - "services::ldap/url": value => $url; - } - -This will set the ``[ldap]`` section ``url`` to the value of ``$url`` -in the configuration file -``/etc/keystone/domains/keystone.services.conf`` - -I'm proposing ``::`` as the delimiter since that's what the proposed -keystone v3 patch uses. Note that in this case, the domain comes -first, before the ``::`` - -This implementation will be a subclass keystone_config. - -Alternatives ------------- - -It should be noted that the rest API offer a way to do it directly -without the configuration file, but it's currently unavailable to the -openstack cli see this `openstackclient bug -`_. -When this becomes available, the file creation can be removed in favor -of the cli. - -Another way to do it would be to add the missing name parsing in -"keystone_config". The lesser encapsulation means that when the -openstack cli finally supports the direct modification of the -configuration, we won't be able to adjust the provider easily. - -Data model impact ------------------ - -None - -Module API impact ------------------ - -Everything has been already mentioned in Proposed change. - -End user impact ---------------------- - -None - -Performance Impact ------------------- - -None - -Deployer impact ---------------------- - -If a deployer use a parameter with ``::`` in it, then the left side of -the string will be interpreted as a domain and put in the domain file, -not in the keystone.conf file. There is no such parameter for the -moment in the whole configuration and it's unlikely that they ever -will be. - -Developer impact ----------------- - -None - -Implementation -============== - -Assignee(s) ------------ - -Primary assignee: - sofer-athlan-guyot - -Other contributors: - rmeggins - -Work Items ----------- - -* Create a unit rspec; -* Create a functional test; -* Add the name parsing and file path logic in the provider; - -Dependencies -============ - -* The keystone version must be at least stable/kilo. - -Testing -======= - -For the moment the functional test are covered by beaker. Future -change in the puppet gate can make tempest tests useful for this -feature. - -Documentation Impact -==================== - -Add a examples in the puppet-keystone repository for this feature. - -References -========== - -1. `Official documentation; `_ - -2. `Discussion on trello; `_ - -3. `Domain configuration management API `_ diff --git a/specs/newton/config-deprecation-for-inifile-provider.rst b/specs/newton/config-deprecation-for-inifile-provider.rst deleted file mode 100644 index 9d2cddf..0000000 --- a/specs/newton/config-deprecation-for-inifile-provider.rst +++ /dev/null @@ -1,172 +0,0 @@ -.. - This work is licensed under a Creative Commons Attribution 3.0 Unported - License. - - http://creativecommons.org/licenses/by/3.0/legalcode - -========================================== -Configuration File Deprecation Support -========================================== - -`Launchpad blueprint `_ - -Allow the inifile (config file) providers to handle deprecated options. This -should include cleaning up old deprecated names from config files and also -allow using the deprecated name instead of the new name. - -Problem description -=================== - -When moving to new releases of OpenStack, config file options are frequently -deprecated because they're no longer needed, or they've been renamed. - -After an upgrade this means that operators will frequently have the old and new -config option in place, but the old option is no longer used or maintained. - -Additionally, when upgrading it can be useful to update the Puppet modules -before actually upgrading the service. A frequent problem when doing this is -that the newer module only supports the new names for options instead of the -older deprecated names. - -Proposed change -=============== - -Add additional parameters to the openstacklib inifile provider help manage -cleanup removed and renamed configuration options. All inifile providers in -other OpenStack Puppet modules that derive from this provider would inherit the -new behavior. The syntax would allow specifying the old name for options which -could be used to purge the old names or to use them in preference to the new -names. For example:: - - cinder_config { 'oslo_logging/new_option': - deprecated_name => 'DEFAULT/old_option_name', - value => $value, - } - -In this case, it would populate the ``oslo_logging/new_option`` key in the -Cinder config file with the contents of ``$value`` as normally expected. -However, it would also purge the old name ``DEFAULT/old_option_name`` as given -by ``deprecated_name``. - -The following new parameters would be supported: - -``deprecated_name`` - This is a string or array of old names that have been deprecated. Array - should be supported because there are sometimes multiple names that have been - deprecated in a single release. Defaults to an empty array. - -``purge_deprecated`` - If true, and if ``use_deprecated`` is false, then any ``deprecated_name`` - values provided will be treated as if they had been specified separately with - an ensure value of ``absent``. Defaults to true. - -``use_deprecated`` - If true, then the inifile provider will act as if additional resources of the - same type were specified for each ``deprecated_name`` with the same - ``value`` and ``ensure`` parameters. Defaults to false. - -It's expected that both ``use_deprecated`` and ``purge_deprecated`` would be -set globally for each config provider as needed, either using resource defaults -or resource collectors. - -Alternatives ------------- - -Currently the old deprecated options left behind cause no harm. We could -ignore this issue. This has the downside that it is not clear which value is -currently used. - -The inifile provider could be set to purge unmanaged options. Currently we -depend on distributions to provide a base configuration file. In the past -there have been issues with the OpenStack Puppet modules not managing all -required options and depending on values provided in the base configuration -files. This approach would require testing all of the existing modules to -ensure they manage all needed options and also changing acceptance tests to use -the purge functionality to prevent regressions. - -Data model impact ------------------ - -None - -Module API impact ------------------ - -Everything has been already mentioned in Proposed change. - -End user impact ---------------------- - -None - -Performance Impact ------------------- - -Potential implementations might create additional resources to ensure the -deprecated config value state. This could increase the number of resources -being managed and the Puppet catalog size. - -A small amount of additional overhead may be incurred to find and remove the -deprecated names. - - -Deployer impact ---------------------- - -Existing configuration files with deprecated options would be removed as -described. When this occurs, services will be restarted. Impact of this is -expected to be minimal since most of these changes would occur between major -releases of the modules. In that case, the deployer is expected to be -upgrading services and restarting them already. - -It is expected that deployers may set ``use_deprecated`` to true in -preparation to for upgrades, allowing upgrading the Puppet modules in some -cases before upgrading the services they manage. - -Deployers that wish to disable the new behavior could set the -``purge_deprecated`` parameter to false. - - -Developer impact ----------------- - -Developers would need to populate the ``deprecated_names`` parameter when -renaming configuration options. - -Implementation -============== - -Assignee(s) ------------ - -Primary assignee: - clayton-oneill (IRC nick clayton) - -Work Items ----------- - -* Identify existing option with deprecation as test candidate -* Create a unit rspec in openstacklib and child module -* Create a functional test in openstacklib and child module -* Add implementation to openstacklib inifile provider - -Dependencies -============ - -None - -Testing -======= - -Unit and functional should be added to ensure base functionality and prevent -regressions. - -Documentation Impact -==================== - -Currently documentation of inifile providers is spotty. This may be an -opportunity to move that documentation into the ``openstacklib`` module. - -References -========== -None diff --git a/specs/template.rst b/specs/template.rst deleted file mode 100644 index 1a69031..0000000 --- a/specs/template.rst +++ /dev/null @@ -1,272 +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/puppet-[projectname]/+spec/example - -Introduction paragraph -- why are we doing anything? A single paragraph of -prose that operators can understand. - -Some notes about using this template: - -* Your spec should be in ReSTructured text, like this template. - -* Please wrap text at 79 columns. - -* The filename in the git repository should match the launchpad URL, for - example a URL of: https://blueprints.launchpad.net/nova/+spec/awesome-thing - should be named awesome-thing.rst - -* Please do not delete any of the sections in this template. If you have - nothing to say for a whole section, just write: None - -* For help with syntax, see http://sphinx-doc.org/rest.html - -* To test out your formatting, build the docs using tox, or see: - http://rst.ninjs.org - -* If you would like to provide a diagram with your spec, 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. - -Module API impact ------------------ - -Each API method which is either added or changed should have the following, -depending upon if it is a new class or an addition to an existing class. - -* For new classes: - - * Specification for the class. - - * A description of what the class does suitable for use in - user documentation. - - * Documentation of all parameters, including default values. - -* For new parameters: - - * Documentation, including parameters. - - * Reason for addition (rather than using config classes). - -* For deprecations: - - * Reason for deprecation. - - * Alternative to deprecated parameters. - - * Scheduled release for deprecated parameter removal. - -* Example use case including typical API samples. - -* Discuss any policy changes, and discuss what things a deployer needs to - think about when defining their policy. - -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 . - -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-novaclient? 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? - -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 Puppet OpenStack, -such as. - -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: - - -Other contributors: - - -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 nova, 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 Nova (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 diff --git a/tests/__init__.py b/tests/__init__.py deleted file mode 100644 index e69de29..0000000 diff --git a/tests/test_titles.py b/tests/test_titles.py deleted file mode 100644 index c9a0c32..0000000 --- a/tests/test_titles.py +++ /dev/null @@ -1,92 +0,0 @@ -# Licensed under the Apache License, Version 2.0 (the "License"); you may -# not use this file except in compliance with the License. You may obtain -# a copy of the License at -# -# http://www.apache.org/licenses/LICENSE-2.0 -# -# Unless required by applicable law or agreed to in writing, software -# distributed under the License is distributed on an "AS IS" BASIS, WITHOUT -# WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the -# License for the specific language governing permissions and limitations -# under the License. - -import glob - -import docutils.core -import testtools - - -class TestTitles(testtools.TestCase): - def _get_title(self, section_tree): - section = { - 'subtitles': [], - } - for node in section_tree: - if node.tagname == 'title': - section['name'] = node.rawsource - elif node.tagname == 'section': - subsection = self._get_title(node) - section['subtitles'].append(subsection['name']) - return section - - def _get_titles(self, spec): - titles = {} - for node in spec: - if node.tagname == 'section': - section = self._get_title(node) - titles[section['name']] = section['subtitles'] - return titles - - def _check_titles(self, titles): - self.assertEqual(7, len(titles)) - - problem = 'Problem description' - self.assertIn(problem, titles) - self.assertEqual(0, len(titles[problem])) - - proposed = 'Proposed change' - self.assertIn(proposed, titles) - self.assertEqual( - [ - 'Alternatives', - 'Data model impact', - 'Module API impact', - 'End user impact', - 'Performance Impact', - 'Deployer impact', - 'Developer impact', - ], - titles[proposed]) - - impl = 'Implementation' - self.assertIn(impl, titles) - self.assertEqual(2, len(titles[impl])) - self.assertIn('Assignee(s)', titles[impl]) - self.assertIn('Work Items', titles[impl]) - - deps = 'Dependencies' - self.assertIn(deps, titles) - self.assertEqual(0, len(titles[deps])) - - testing = 'Testing' - self.assertIn(testing, titles) - self.assertEqual(0, len(titles[testing])) - - docs = 'Documentation Impact' - self.assertIn(docs, titles) - self.assertEqual(0, len(titles[docs])) - - refs = 'References' - self.assertIn(refs, titles) - self.assertEqual(0, len(titles[refs])) - - def test_template(self): - files = ['specs/template.rst'] + glob.glob('specs/*/*') - for filename in files: - self.assertTrue(filename.endswith(".rst"), - "spec's file must uses 'rst' extension.") - with open(filename) as f: - data = f.read() - spec = docutils.core.publish_doctree(data) - titles = self._get_titles(spec) - self._check_titles(titles) diff --git a/tox.ini b/tox.ini deleted file mode 100644 index ee44d67..0000000 --- a/tox.ini +++ /dev/null @@ -1,20 +0,0 @@ -[tox] -minversion = 3.1 -envlist = docs,py37 -skipsdist = True -ignore_basepython_conflict = True - -[testenv] -basepython = python3 -usedevelop = True -setenv = VIRTUAL_ENV={envdir} -deps = - -c{env:TOX_CONSTRAINTS_FILE:https://releases.openstack.org/constraints/upper/master} - -r{toxinidir}/requirements.txt -commands = stestr run --slowest {posargs} - -[testenv:venv] -commands = {posargs} - -[testenv:docs] -commands = sphinx-build -W -b html doc/source doc/build/html