This project is no logner maintained or used as part of TripleO. Change-Id: I0c9d052d2b3e3a3e656342042461b330c74139f0 Related-Bug: #1768590 Depends-On: https://review.openstack.org/#/c/565836/changes/38/565838/1
Alex Schultz
5 years ago
parent
b445339881
commit
ed8fed7aa2
@ -1,33 +0,0 @@
|
||||
*.swp
|
||||
*~
|
||||
*.qcow2
|
||||
|
||||
.DS_Store
|
||||
|
||||
*.egg
|
||||
*.egg-info
|
||||
*.pyc
|
||||
|
||||
doc/source/devtest*.rst
|
||||
openstack-tools
|
||||
scripts/ceilometer
|
||||
scripts/cinder
|
||||
scripts/generate-keystone-pki
|
||||
scripts/glance
|
||||
scripts/heat
|
||||
scripts/init-keystone
|
||||
scripts/ironic
|
||||
scripts/keystone
|
||||
scripts/nova
|
||||
scripts/neutron
|
||||
scripts/openstack
|
||||
scripts/os-apply-config
|
||||
scripts/register-nodes
|
||||
scripts/setup-neutron
|
||||
scripts/swift
|
||||
|
||||
.tox
|
||||
doc/build
|
||||
|
||||
AUTHORS
|
||||
ChangeLog
|
||||
@ -1,4 +0,0 @@
|
||||
[gerrit]
|
||||
host=review.openstack.org
|
||||
port=29418
|
||||
project=openstack/tripleo-incubator.git
|
||||
@ -1,20 +0,0 @@
|
||||
Contributing
|
||||
============
|
||||
|
||||
If you would like to contribute to the development of OpenStack,
|
||||
you must follow the steps in documented at:
|
||||
|
||||
http://docs.openstack.org/infra/manual/developers.html#development-workflow
|
||||
|
||||
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 not be seen.
|
||||
|
||||
Bugs should be filed on Launchpad, not GitHub:
|
||||
|
||||
https://bugs.launchpad.net/tripleo
|
||||
|
||||
@ -1,70 +0,0 @@
|
||||
TripleO Style Guidelines
|
||||
========================
|
||||
|
||||
- Step 1: Read the OpenStack Style Guidelines [1]_
|
||||
- Step 2: Read Bashate [2]_
|
||||
- Step 3: See specific guidelines below
|
||||
|
||||
TripleO Specific Guidelines
|
||||
---------------------------
|
||||
|
||||
There is plenty of code that does not adhere to these conventions currently.
|
||||
However it is useful to have conventions as consistently formatted code is
|
||||
easier to read and less likely to hide bugs. New code should adhere to these
|
||||
conventions, and developers should consider sensible adjustment of existing
|
||||
code when working nearby.
|
||||
|
||||
Formatting
|
||||
~~~~~~~~~~
|
||||
Please follow conventions described in OpenStack style guidelines [1]_ and Bashate [2]_.
|
||||
|
||||
- Order lists whenever possible, whether in code or data. If the order doesn't
|
||||
matter, use a case-insensitive alphabetical sort. This makes them easier to
|
||||
compare with ``diff``-like tools.
|
||||
- "a" < "B" < "c"
|
||||
- "a" < "ab"
|
||||
- "2" < "10"
|
||||
|
||||
Bash
|
||||
~~~~
|
||||
As well as those rules described in Bashate [2]_:
|
||||
|
||||
- The interpreter is ``/bin/bash``.
|
||||
- Provide a shebang ``#!/bin/bash`` if you intend your script to be run rather than sourced.
|
||||
- Use ``set -e`` and ``set -o pipefail`` to exit early on errors.
|
||||
- Use ``set -u`` to catch typos in variable names.
|
||||
- Use ``$()`` not `````` for subshell commands.
|
||||
- Double quote substitutions by default. It's OK to omit quotes if it's
|
||||
important that the result be multiple words. EG given VAR="a b":
|
||||
|
||||
``echo "${VAR}"``
|
||||
Quote variables.
|
||||
``echo "$(echo a b)"``
|
||||
Quote subshells.
|
||||
``echo "$(echo "${VAR}")"``
|
||||
In subshells, the inner quotes must not be escaped.
|
||||
``function print_b() { echo "$2"; }; print_b ${VAR}``
|
||||
You must omit quotes for a variable to be passed as multiple arguments.
|
||||
``ARRAY=(${VAR}); echo "${#ARRAY[@]}" = 2``
|
||||
You must omit quotes to form a multi-element array.
|
||||
|
||||
- Avoid repeated/copy-pasted code. Make it a function, or a shared script, etc.
|
||||
|
||||
Script Input
|
||||
~~~~~~~~~~~~
|
||||
- Avoid environment variables as input. Prefer command-line arguments.
|
||||
- If passing structured data, use JSON.
|
||||
- Avoid passing substantial amounts of bare data (eg JSON) on the command
|
||||
line. It is preferred to place the data in a file and pass the filename.
|
||||
Using process substitution ``<()`` can help with this.
|
||||
|
||||
Variables
|
||||
~~~~~~~~~
|
||||
- Within a shell script, variables that are defined for local use should be
|
||||
lower_cased. Variables that are passed in or come from outside the script
|
||||
should be UPPER_CASED.
|
||||
|
||||
References
|
||||
----------
|
||||
.. [1] http://docs.openstack.org/developer/hacking/
|
||||
.. [2] http://git.openstack.org/cgit/openstack-dev/bashate/tree/README.rst
|
||||
@ -1,202 +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.
|
||||
|
||||
END OF TERMS AND CONDITIONS
|
||||
|
||||
APPENDIX: How to apply the Apache License to your work.
|
||||
|
||||
To apply the Apache License to your work, attach the following
|
||||
boilerplate notice, with the fields enclosed by brackets "[]"
|
||||
replaced with your own identifying information. (Don't include
|
||||
the brackets!) The text should be enclosed in the appropriate
|
||||
comment syntax for the file format. We also recommend that a
|
||||
file or class name and description of purpose be included on the
|
||||
same "printed page" as the copyright notice for easier
|
||||
identification within third-party archives.
|
||||
|
||||
Copyright [yyyy] [name of copyright owner]
|
||||
|
||||
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.
|
||||
@ -1,13 +1,10 @@
|
||||
========================
|
||||
Team and repository tags
|
||||
========================
|
||||
This project is no longer maintained.
|
||||
|
||||
.. image:: http://governance.openstack.org/badges/tripleo-incubator.svg
|
||||
:target: http://governance.openstack.org/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
|
||||
|
||||
This Repo is Deprecated
|
||||
=======================
|
||||
|
||||
Please see the `current TripleO docs <http://docs.openstack.org/developer/tripleo-docs/>`_.
|
||||
For any further questions, please email
|
||||
openstack-dev@lists.openstack.org or join #openstack-dev on
|
||||
Freenode.
|
||||
|
||||
@ -1,5 +0,0 @@
|
||||
# Add OS_CLOUDNAME to PS1
|
||||
if [ -z "${OS_CLOUDPROMPT_ENABLED:-}" ]; then
|
||||
export PS1=\${OS_CLOUDNAME:+"(\$OS_CLOUDNAME)"}$PS1
|
||||
export OS_CLOUDPROMPT_ENABLED=1
|
||||
fi
|
||||
@ -1,32 +0,0 @@
|
||||
# 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.
|
||||
|
||||
import os
|
||||
|
||||
from sphinx import errors
|
||||
|
||||
|
||||
def builder_inited(app):
|
||||
app.info('In: ' + os.path.abspath('.'))
|
||||
source_dir = app.srcdir
|
||||
build_dir = app.outdir
|
||||
app.info('Generating devtest from %s into %s' % (source_dir, build_dir))
|
||||
ret = os.system('scripts/extract-docs')
|
||||
if ret:
|
||||
raise errors.ExtensionError(
|
||||
"Error generating %s/devtest.rst" % build_dir)
|
||||
|
||||
|
||||
def setup(app):
|
||||
app.connect('builder-inited', builder_inited)
|
||||
@ -1 +0,0 @@
|
||||
.. include:: ../../CONTRIBUTING.rst
|
||||
@ -1 +0,0 @@
|
||||
.. include:: ../../HACKING.rst
|
||||
@ -1 +0,0 @@
|
||||
.. include:: ../../README.rst
|
||||
@ -1,50 +0,0 @@
|
||||
# -*- coding: utf-8 -*-
|
||||
|
||||
import os
|
||||
import sys
|
||||
|
||||
sys.path.insert(0, os.path.abspath('../..'))
|
||||
sys.path.insert(0, os.path.abspath('../'))
|
||||
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 = [
|
||||
'sphinx.ext.autodoc',
|
||||
'sphinx.ext.intersphinx',
|
||||
'oslosphinx',
|
||||
'ext.extract_docs'
|
||||
]
|
||||
|
||||
# The suffix of source filenames.
|
||||
source_suffix = '.rst'
|
||||
|
||||
# The master toctree document.
|
||||
master_doc = 'index'
|
||||
|
||||
# General information about the project.
|
||||
project = u'TripleO'
|
||||
copyright = u'2013, OpenStack Foundation'
|
||||
|
||||
# The name of the Pygments (syntax highlighting) style to use.
|
||||
pygments_style = 'sphinx'
|
||||
|
||||
# -- Options for HTML output --------------------------------------------------
|
||||
|
||||
# Output file base name for HTML help builder.
|
||||
htmlhelp_basename = '%sdoc' % project
|
||||
|
||||
# Grouping the document tree into LaTeX files. List of tuples
|
||||
# (source start file, target name, title, author, documentclass
|
||||
# [howto/manual]).
|
||||
latex_documents = [
|
||||
('index',
|
||||
'%s.tex' % project,
|
||||
u'%s Documentation' % project,
|
||||
u'OpenStack Foundation', 'manual'),
|
||||
]
|
||||
|
||||
# Example configuration for intersphinx: refer to the Python standard library.
|
||||
intersphinx_mapping = {'http://docs.python.org/': None}
|
||||
@ -1,494 +0,0 @@
|
||||
Deploying TripleO
|
||||
=================
|
||||
|
||||
Components
|
||||
----------
|
||||
|
||||
Essential Components
|
||||
^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Essential components make up the self-deploying infrastructure that is
|
||||
the heart of TripleO.
|
||||
|
||||
- Baremetal machine deployment (Nova Baremetal, soon to be 'Ironic')
|
||||
|
||||
- Baremetal volume management (Cinder - not available yet)
|
||||
|
||||
- Cluster orchestration (Heat)
|
||||
|
||||
- Machine image creation (Diskimage-builder)
|
||||
|
||||
- In-instance configuration management
|
||||
(os-apply-config+os-refresh-config, and/or Chef/Puppet/Salt)
|
||||
|
||||
- Image management (Glance)
|
||||
|
||||
- Network management (Neutron)
|
||||
|
||||
- Authentication and service catalog (Keystone)
|
||||
|
||||
Additional Components
|
||||
^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
These components add value to the TripleO story, making it safer to
|
||||
upgrade and evolve an environment, but are secondary to the core thing
|
||||
itself.
|
||||
|
||||
- Continuous integration (Zuul/Jenkins)
|
||||
|
||||
- Monitoring and alerting (Ceilometer/nagios/etc)
|
||||
|
||||
Dependencies
|
||||
------------
|
||||
|
||||
Each component can only be deployed once its dependencies are available.
|
||||
|
||||
TripleO is built on a Linux platform, so a Linux environment is required
|
||||
both to create images and as the OS that will run on the machines. If
|
||||
you have no Linux machines at all, you can download a live CD from a
|
||||
number of vendors, which will permit you to run diskimage-builder to get
|
||||
going.
|
||||
|
||||
Diskimage-builder
|
||||
^^^^^^^^^^^^^^^^^
|
||||
|
||||
An internet connection is also required to download the various packages
|
||||
used in preparing each image.
|
||||
|
||||
The machine images built *can* depend on Heat metadata, or they can just
|
||||
contain configured Chef/Puppet/Salt credentials, depending on how much
|
||||
of TripleO is in use. Avoiding Heat is useful when doing a incremental
|
||||
adoption of TripleO (see later in this document).
|
||||
|
||||
Baremetal machine deployment
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Baremetal deployments are delivered via Nova. Additionally, the network
|
||||
must be configured so that the baremetal host machine can receive TFTP
|
||||
from any physical machine that is being booted.
|
||||
|
||||
Nova
|
||||
^^^^
|
||||
|
||||
Nova depends on Keystone, Glance and Neutron. In future Cinder will be
|
||||
one of the dependencies.
|
||||
|
||||
There are three ways the service can be deployed:
|
||||
|
||||
- Via diskimage-builder built machine images, configured via a running
|
||||
Heat cluster. This is the normal TripleO deployment.
|
||||
|
||||
- Via the special bootstrap node image, which is built by
|
||||
diskimage-builder and contains a full working stack - nova, glance,
|
||||
keystone and neutron, configured by statically generated Heat
|
||||
metadata. This approach is used to get TripleO up and running.
|
||||
|
||||
- By hand - e.g. using devstack, or manually/chef/puppet/packages on a
|
||||
dedicated machine. This can be useful for incremental adoption of
|
||||
TripleO.
|
||||
|
||||
Cinder
|
||||
^^^^^^
|
||||
|
||||
Cinder is needed for persistent storage on bare metal machines. That
|
||||
aspect of TripleO is not yet available : when an instance is deleted,
|
||||
the storage is deleted with it.
|
||||
|
||||
Neutron
|
||||
^^^^^^^
|
||||
|
||||
Neutron depends on Keystone. The same three deployment options exist as
|
||||
for Nova. The Neutron network node(s) must be the only DHCP servers on
|
||||
the network.
|
||||
|
||||
Glance
|
||||
^^^^^^
|
||||
|
||||
Glance depends on Keystone. The same three deployment options exist as
|
||||
for Nova.
|
||||
|
||||
Keystone
|
||||
^^^^^^^^
|
||||
|
||||
Keystone has no external dependencies. The same three deployment options
|
||||
exist as for Nova.
|
||||
|
||||
Heat
|
||||
^^^^
|
||||
|
||||
Heat depends on Nova, Cinder and Keystone. The same three deployment
|
||||
options exist as for Nova.
|
||||
|
||||
In-instance configuration
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
The os-apply-config and os-refresh-config tools depend on Heat to
|
||||
provide cluster configuration metadata. They can be used before Heat is
|
||||
functional if a statically prepared metadata file is placed in the Heat
|
||||
path : this is how the bootstrap node works.
|
||||
|
||||
os-apply-config and os-refresh-config can be used in concert with
|
||||
Chef/Puppet/Salt, or not used at all, if you configure your services via
|
||||
Chef/Puppet/Salt.
|
||||
|
||||
The reference TripleO elements do not depend on Chef/Puppet/Salt, to
|
||||
avoid conflicting when organisations with an investment in
|
||||
Chef/Puppet/Salt start using TripleO.
|
||||
|
||||
Deploying TripleO incrementally
|
||||
-------------------------------
|
||||
|
||||
The general sequence is:
|
||||
|
||||
- Examine the current state of TripleO and assess where non-automated
|
||||
solutions will be needed for your environment. E.g. at the time of
|
||||
writing VLAN support requires baking the VLAN configuration into your
|
||||
built disk images.
|
||||
|
||||
- Decide how much of TripleO you will adopt. See `Example deployments (possible today)`_
|
||||
below.
|
||||
|
||||
- Install diskimage-builder somewhere and use it to build the disk
|
||||
images your configuration will require.
|
||||
|
||||
- Bring up the aspects of TripleO you will be using, starting with a
|
||||
boot-stack node (which you can run in a KVM VM in your datacentre),
|
||||
using that to bring up an actual machine and transfer bare metal
|
||||
services onto it, and then continuing up the stack.
|
||||
|
||||
Current caveats / workarounds
|
||||
-----------------------------
|
||||
|
||||
These are all documented in README.rst and in the
|
||||
`TripleO bugtracker`_.
|
||||
|
||||
.. _`TripleO bugtracker`: https://launchpad.net/tripleo
|
||||
|
||||
No API driven persistent storage
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Every 'nova boot' will reset the data on the machine it deploys to. To
|
||||
do incremental image based updates they have to be done within the
|
||||
runnning image. 'takeovernode' can do that, but as yet we have not
|
||||
written rules to split out persistent data into another partition - so
|
||||
some assembly required.
|
||||
|
||||
VLANs for physical nodes require customised images (rather than just metadata).
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
If you require VLANs you should create a diskimage-builder element to
|
||||
add the vlan package and vlan configuration to /etc/network/interfaces
|
||||
as a first-boot rule.
|
||||
|
||||
New seed image creation returns tmpfs space errors (systems with < 9GB of RAM)
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Creating a new seed image takes up to 4.5GB of space inside a /tmp/imageXXXXX
|
||||
directory. tmpfs can take up to 50% of RAM and systems with less than 9GB of
|
||||
RAM will fail in this step. When using ``diskimage-builder`` directly, you can
|
||||
prevent the space errors by:
|
||||
|
||||
- avoiding tmpfs with ``--no-tmpfs`` or
|
||||
- specifying a minimum tmpfs size required with ``--min-tmpfs`` (which can be used
|
||||
in conjunction with setting the environment variable ``TMP_DIR`` to override the
|
||||
default temporary directory)
|
||||
|
||||
If you are using ``boot-seed-vm``, set the environment variable ``DIB_NO_TMPFS=1``.
|
||||
|
||||
Example deployments (possible today)
|
||||
------------------------------------
|
||||
|
||||
Baremetal only
|
||||
^^^^^^^^^^^^^^
|
||||
|
||||
In this scenario you make use of the baremetal driver to deploy
|
||||
unspecialised machine images, and perform specialisation using
|
||||
Chef/Puppet/Salt - whatever configuration management toolchain you
|
||||
prefer. The baremetal host system is installed manually, but a TripleO
|
||||
image is used to deploy it.
|
||||
|
||||
It scales within any one broadcast domain to the capacity of the single
|
||||
baremetal host.
|
||||
|
||||
Prerequisites
|
||||
~~~~~~~~~~~~~
|
||||
|
||||
- A boot-stack image setup to run in KVM.
|
||||
|
||||
- A vanilla image.
|
||||
|
||||
- A userdata script to configure new instances to run however you want.
|
||||
|
||||
- A machine installed with your OS of choice in your datacentre.
|
||||
|
||||
- Physical machines configured to netboot in preference to local boot.
|
||||
|
||||
- A list of the machines + their IPMI details + mac addresses.
|
||||
|
||||
- A network range larger than the maximum number of concurrent deploy
|
||||
operations to run in parallel.
|
||||
|
||||
- A network to run the instances on large enough to supply one ip per
|
||||
instance.
|
||||
|
||||
HOWTO
|
||||
~~~~~
|
||||
|
||||
- Build the images you need (add any local elements you need to the
|
||||
commands)
|
||||
|
||||
- Copy ``tripleo-image-elements/elements/seed-stack-config/config.json`` to
|
||||
``tripleo-image-elements/elements/seed-stack-config/local.json`` and
|
||||
change the virtual power manager to 'nova...impi.IPMI'.
|
||||
https://bugs.launchpad.net/tripleo/+bug/1178547::
|
||||
|
||||
disk-image-create -o bootstrap vm boot-stack local-config ubuntu
|
||||
disk-image-create -o ubuntu ubuntu
|
||||
|
||||
The ``local-config`` element will copy your ssh key and your HTTP proxy
|
||||
settings in the disk image during the creation process.
|
||||
|
||||
The ``stackuser`` element will create a user ``stack`` with the password ``stack``.
|
||||
|
||||
``disk-image-create`` will create a image with a very small disk size
|
||||
that at to be resized for example by cloud-init. You can use
|
||||
``DIB_IMAGE_SIZE`` to increase this initial size, in GB.
|
||||
|
||||
- Setup a VM using bootstrap.qcow2 on your existing machine, with eth1
|
||||
bridged into your datacentre LAN.
|
||||
|
||||
- Run up that VM, which will create a self contained nova baremetal
|
||||
install.
|
||||
|
||||
- Reconfigure the networking within the VM to match your physical
|
||||
network. https://bugs.launchpad.net/tripleo/+bug/1178397
|
||||
https://bugs.launchpad.net/tripleo/+bug/1178099
|
||||
|
||||
- If you had exotic hardware needs, replace the deploy images that the
|
||||
bootstack creates. https://bugs.launchpad.net/tripleo/+bug/1178094
|
||||
|
||||
- Enroll your vanilla image into the glance of that install. Be sure to
|
||||
use ``tripleo-incubator/scripts/load-image`` as that will extract the
|
||||
kernel and ramdisk and register them appropriately with glance.
|
||||
|
||||
- Enroll your other datacentre machines into that nova baremetal
|
||||
install. A script that takes your machine inventory and prints out
|
||||
something like::
|
||||
|
||||
nova baremetal-node-create --pm_user XXX --pm_address YYY --pm_password ZZZ COMPUTEHOST 24 98304 2048 MAC
|
||||
|
||||
can be a great help - and can be run from outside the environment.
|
||||
|
||||
- Setup admin users with SSH keypairs etc. e.g.::
|
||||
|
||||
nova keypair-add --pub-key .ssh/authorized_keys default
|
||||
|
||||
- Boot them using the ubuntu.qcow2 image, with appropriate user data to
|
||||
connect to your Chef/Puppet/Salt environments.
|
||||
|
||||
Baremetal with Heat
|
||||
^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
In this scenario you use the baremetal driver to deploy specialised
|
||||
machine images which are orchestrated by Heat.
|
||||
|
||||
Prerequisites.
|
||||
~~~~~~~~~~~~~~
|
||||
|
||||
- A boot-stack image setup to run in KVM.
|
||||
|
||||
- A vanilla image with cfn-tools installed.
|
||||
|
||||
- A seed machine installed with your OS of choice in your datacentre.
|
||||
|
||||
HOWTO
|
||||
~~~~~
|
||||
|
||||
- Build the images you need (add any local elements you need to the
|
||||
commands)::
|
||||
|
||||
disk-image-create -o bootstrap vm boot-stack ubuntu heat-api
|
||||
disk-image-create -o ubuntu ubuntu cfn-tools
|
||||
|
||||
- Setup a VM using bootstrap.qcow2 on your existing machine, with eth1
|
||||
bridged into your datacentre LAN.
|
||||
|
||||
- Run up that VM, which will create a self contained nova baremetal
|
||||
install.
|
||||
|
||||
- Enroll your vanilla image into the glance of that install.
|
||||
|
||||
- Enroll your other datacentre machines into that nova baremetal
|
||||
install.
|
||||
|
||||
- Setup admin users with SSH keypairs etc.
|
||||
|
||||
- Create a Heat stack with your application topology. Be sure to use
|
||||
the image id of your cfn-tools customised image.
|
||||
|
||||
GRE Neutron OpenStack managed by Heat
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
In this scenario we build on Baremetal with Heat to deploy a full
|
||||
OpenStack orchestrated by Heat, with specialised disk images for
|
||||
different OpenStack node roles.
|
||||
|
||||
Prerequisites.
|
||||
~~~~~~~~~~~~~~
|
||||
|
||||
- A boot-stack image setup to run in KVM.
|
||||
|
||||
- A vanilla image with cfn-tools installed.
|
||||
|
||||
- A seed machine installed with your OS of choice in your datacentre.
|
||||
|
||||
- At least 4 machines in your datacentre, one of which manually installed with
|
||||
a recent Linux (libvirt 1.0+ or newer required).
|
||||
|
||||
- L2 network with private address range
|
||||
|
||||
- L3 accessible management network (via the L2 default router)
|
||||
|
||||
- VLAN with public IP ranges on it
|
||||
|
||||
Needed data
|
||||
~~~~~~~~~~~
|
||||
|
||||
- a JSON file describing your baremetal machines in a format described
|
||||
in :ref:`devtest-environment-configuration` (see: nodes), making sure to
|
||||
include all MAC addresses for all network interface cards as well as the
|
||||
IPMI (address, user, password) details for them.
|
||||
|
||||
- 2 spare contiguous ip addresses on your L2 network for seed deployment.
|
||||
|
||||
- 1 spare ip address for your seed VM, and one spare for talking to it on it's
|
||||
bridge (seedip, seediplink)
|
||||
|
||||
- 3 spare ip addresses for your undercloud tenant network + neutron services.
|
||||
|
||||
- Public IP address to be your undercloud endpoint
|
||||
|
||||
- Public IP address to be your overcloud endpoint
|
||||
|
||||
Install Seed
|
||||
~~~~~~~~~~~~
|
||||
|
||||
Follow the 'devtest' guide but edit the seed config.json to:
|
||||
|
||||
- change the dnsmasq range to the seed deployment range
|
||||
|
||||
- change the heat endpoint details to refer to your seed ip address
|
||||
|
||||
- change the ctlplane ip and cidr to match your seed ip address
|
||||
|
||||
- change the power manager line nova.virt.baremetal.ipmi.IPMI and
|
||||
remove the virtual subsection.
|
||||
|
||||
- setup proxy arp (this and the related bits are used to avoid messing about
|
||||
with the public NIC and bridging: you may choose to use that approach
|
||||
instead...)::
|
||||
|
||||
sudo sysctl net/ipv4/conf/all/proxy_arp=1
|
||||
arp -s <seedip> -i <external_interface> -D <external_interface> pub
|
||||
ip addr add <seediplink>/32 dev brbm
|
||||
ip route add <seedip>/32 dev brbm src <seediplink>
|
||||
|
||||
- setup ec2 metadata support::
|
||||
|
||||
iptables -t nat -A PREROUTING -d 169.254.169.254/32 -i <external_interface> -p tcp -m tcp --dport 80 -j DNAT --to-destination <seedip>:8775
|
||||
|
||||
- setup DHCP relay::
|
||||
|
||||
sudo apt-get install dhcp-helper
|
||||
|
||||
and configure it with ``-s <seedip>``
|
||||
Note that isc-dhcp-relay fails to forward responses correctly, so dhcp-helper is preferred
|
||||
( https://bugs.launchpad.net/ubuntu/+bug/1233953 ).
|
||||
|
||||
Also note that dnsmasq may have to be stopped as they both listen to ``*:dhcps``
|
||||
( https://bugs.launchpad.net/ubuntu/+bug/1233954 ).
|
||||
|
||||
Disable the ``filter-bootps`` cronjob (``./etc/cron.d/filter-bootp``) inside the seed vm and reset the table::
|
||||
|
||||
sudo iptables -F FILTERBOOTPS
|
||||
|
||||
edit /etc/init/novabm-dnsmasq.conf::
|
||||
|
||||
exec dnsmasq --conf-file= \
|
||||
--keep-in-foreground \
|
||||
--port=0 \
|
||||
--dhcp-boot=pxelinux.0,<seedip>,<seedip> \
|
||||
--bind-interfaces \
|
||||
--pid-file=/var/run/dnsmasq.pid \
|
||||
--interface=br-ctlplane \
|
||||
--dhcp-range=<seed_deploy_start>,<seed_deploy_end>,<network_cidr>
|
||||
|
||||
- When you setup the seed, use <seedip> instead of 192.0.2.1, and you may need to edit seedrc.
|
||||
|
||||
- For setup-neutron:
|
||||
setup-neutron <start of seed deployment> <end of seed deployment> <cidr of network> <seedip> <metadata server> ctlplane
|
||||
|
||||
- Validate networking:
|
||||
|
||||
- From outside the seed host you should be able to ping <seedip>
|
||||
- From the seed VM you should be able to ping <all ipmi addresses>
|
||||
- From outside the seed host you should be able to get a response from the dnsmasq running on <seedip>
|
||||
|
||||
- Create your deployment ramdisk with baremetal in mind::
|
||||
|
||||
$TRIPLEO_ROOT/diskimage-builder/bin/disk-image-create $NODE_DIST -a \
|
||||
$NODE_ARCH -o $TRIPLEO_ROOT/undercloud boot-stack nova-baremetal \
|
||||
os-collect-config stackuser $DHCP_DRIVER -p linux-image-generic mellanox \
|
||||
serial-console --offline
|
||||
|
||||
- If your hardware has something other than eth0 plugged into the network,
|
||||
fix your file injection template -
|
||||
``/opt/stack/nova/nova/virt/baremetal/net-static.ubuntu.template`` inside the
|
||||
seed vm, replacing the enumerated interface values with the right interface
|
||||
to use (e.g. auto eth2... iface eth2 inet static..)
|
||||
|
||||
Deploy Undercloud
|
||||
~~~~~~~~~~~~~~~~~
|
||||
|
||||
Use ``heat stack-create`` per the devtest documentation to boot your undercloud.
|
||||
But use the ``undercloud-bm.yaml`` file rather ``than undercloud-vm.yaml``.
|
||||
|
||||
Once it's booted:
|
||||
|
||||
- ``modprobe 8021q``
|
||||
|
||||
- edit ``/etc/network/interfaces`` and define your vlan
|
||||
|
||||
- delete the default route on your internal network
|
||||
|
||||
- add a targeted route to your management l3 range via the internal network router
|
||||
|
||||
- add a targeted route to ``169.254.169.254`` via <seedip>
|
||||
|
||||
- ``ifup`` the vlan interface
|
||||
|
||||
- fix your resolv.conf
|
||||
|
||||
- configure the undercloud per devtest.
|
||||
|
||||
- upgrade your quotas::
|
||||
|
||||
nova quota-update --cores node_size*machine_count --instances machine_count --ram node_size*machine_count admin-tenant-id
|
||||
|
||||
|
||||
Deploy Overcloud
|
||||
~~~~~~~~~~~~~~~~
|
||||
|
||||
Follow devtest again, but modify the images you build per the undercloud notes, and for machines you put public services on, follow the undercloud notes to fix them up.
|
||||
|
||||
Example deployments (future)
|
||||
----------------------------
|
||||
|
||||
WARNING: Here be draft notes.
|
||||
|
||||
VM seed + bare metal under cloud
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
- need to be aware nova metadata wont be available after booting as the
|
||||
default rule assumes this host never initiates requests
|
||||
( https://bugs.launchpad.net/tripleo/+bug/1178487 ).
|
||||
@ -1,53 +0,0 @@
|
||||
TripleO Incubator
|
||||
=================
|
||||
|
||||
Getting Started
|
||||
---------------
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
||||
README
|
||||
userguide
|
||||
devtest
|
||||
HACKING
|
||||
|
||||
Detailed notes
|
||||
---------------
|
||||
|
||||
.. tip::
|
||||
|
||||
The following docs each contain detailed notes about one of the scripts corresponding to one of the high-level stages of a TripleO deployment. You should be familiar with the content in the `Getting Started`_ section above before diving into these docs.
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
||||
devtest_variables
|
||||
devtest_setup
|
||||
devtest_testenv
|
||||
devtest_update_network
|
||||
devtest_ramdisk
|
||||
devtest_seed
|
||||
devtest_undercloud
|
||||
devtest_overcloud
|
||||
devtest_overcloud_images
|
||||
devtest_end
|
||||
|
||||
Further Information
|
||||
-------------------
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
||||
deploying
|
||||
puppet
|
||||
resources
|
||||
troubleshooting
|
||||
CONTRIBUTING
|
||||
selinux-guide
|
||||
|
||||
|
||||
Indices and tables
|
||||
==================
|
||||
|
||||
* :ref:`genindex`
|
||||
* :ref:`modindex`
|
||||
* :ref:`search`
|
||||
|
Before Width: | Height: | Size: 19 KiB |
@ -1,133 +0,0 @@
|
||||
TripleO Overcloud deployment with Puppet
|
||||
========================================
|
||||
|
||||
Intro
|
||||
-----
|
||||
|
||||
This document outlines how to deploy a TripleO overcloud using Puppet
|
||||
for configuration. TripleO currently supports using Puppet for configuration
|
||||
using Heat metadata directly via the normal os-collect-config/os-refresh-config
|
||||
agents. No puppet-master or puppet DB infrastructure is required.
|
||||
|
||||
Building Images
|
||||
---------------
|
||||
When building TripleO images for use with Puppet the following elements
|
||||
should be installed:
|
||||
|
||||
- ``hosts``
|
||||
- ``os-net-config``
|
||||
- ``os-collect-config``
|
||||
- ``heat-config-puppet``
|
||||
- ``puppet-modules``
|
||||
- ``hiera``
|
||||
|
||||
The ``hosts`` and ``os-net-config`` are normal TripleO image elements and are still
|
||||
used to deploy basic physical networking configuration required to bootstrap
|
||||
the node.
|
||||
|
||||
The ``os-collect-config``, and ``heat-config-puppet`` elements provide mechanism
|
||||
to run ``puppet apply`` commands that have been configured via Heat software
|
||||
deployment configurations.
|
||||
|
||||
The ``puppet-modules`` element installs all of the required ``stackforge
|
||||
puppet-*`` modules. This element has two modes of operation: package or source
|
||||
installs. The package mode assumes that all of the required modules exist in
|
||||
a single distribution provided package. The source mode deploys the puppet
|
||||
modules from Git at image build time and automatically links them into
|
||||
``/etc/puppet/modules``. The source mode makes use of source repositories so
|
||||
you can, for example, pin to a specific ``puppetlabs-mysql`` module version by setting::
|
||||
|
||||
DIB_REPOREF_puppetlabs_mysql=<GIT COMMIT HASH>
|
||||
|
||||
The ``hiera`` element provides a way to configure the hiera.yaml and hieradata
|
||||
files on each node directly via Heat metadata. The ``tripleo-heat-templates``
|
||||
are used to drive this configuration.
|
||||
|
||||
When building images for use with Puppet it is important to note that
|
||||
regardless of whether you use source or package mode to install these core
|
||||
elements the actual OpenStack service packages (Nova, Neutron, Keystone, etc)
|
||||
will need to be installed via normal distro packages. This is required in
|
||||
order to work with the stackforge puppet modules.
|
||||
|
||||
The OpenStack service packages can be installed at DIB time via the -p
|
||||
option or at deployment time when Puppet is executed on each node.
|
||||
|
||||
Heat Templates
|
||||
--------------
|
||||
|
||||
When deploying an overcloud with Heat only the newer
|
||||
``overcloud-without-mergepy.yaml`` supports Puppet. To enable Puppet simply use
|
||||
the ``overcloud-resource-registry-puppet.yaml`` instead of the normal
|
||||
``overcloud-resource-registry.yaml`` with your Heat ``stack-create`` command.
|
||||
|
||||
Running Devtest Overcloud with Delorean on Fedora
|
||||
-------------------------------------------------
|
||||
|
||||
This section describes the variables required in order to run
|
||||
``devtest_overcloud.sh`` with Puppet. It assumes you have a fully working
|
||||
TripleO undercloud (or seed) which has been preconfigured to work
|
||||
in your environment.
|
||||
|
||||
.. note::
|
||||
|
||||
The following instructions assume this pre-existing config from a normal devtest Fedora setup::
|
||||
|
||||
export NODE_DIST='fedora selinux-permissive'
|
||||
export DIB_RELEASE=21
|
||||
export RDO_RELEASE=kilo
|
||||
|
||||
# Enable packages for all elements by default
|
||||
export DIB_DEFAULT_INSTALLTYPE=package
|
||||
|
||||
# Do not manage /etc/hosts via cloud-init
|
||||
export DIB_CLOUD_INIT_ETC_HOSTS=''
|
||||
|
||||
# Set ROOT_DISK == NODE_DISK (no ephemeral partition)
|
||||
export ROOT_DISK=40
|
||||
export NODE_DISK=40
|
||||
|
||||
By default TripleO uses puppet for configuration only. Packages (RPMs, etc)
|
||||
are typically installed at image build time.
|
||||
|
||||
If you wish to have packages installed at deploy time via Puppet it
|
||||
is important to have a working undercloud nameserver. You can configure
|
||||
this by adding the appropriate undercloud.nameserver setting
|
||||
settings to your undercoud-env.json file. Alternately, If going directly
|
||||
from the seed to the overcloud then you'll need to set seed.nameserver
|
||||
in your testenv.json. If you wish to install packages at deploy
|
||||
time you will also need to set EnablePackageInstall to true in your
|
||||
overcloud-resource-registry-puppet.yaml (see below for instructions
|
||||
on how to override your Heat resource registry).
|
||||
|
||||
1) Git clone the tripleo-puppet-elements [1]_ project into your $TRIPLEO_ROOT. This is currently a non-standard image elements repository and needs to be manually cloned in order to build Puppet images.
|
||||
|
||||
2) Add tripleo-puppet-elements to your ELEMENTS_PATH::
|
||||
|
||||
export ELEMENTS_PATH=$ELEMENTS_PATH:$TRIPLEO_ROOT/tripleo-puppet-elements/elements:$TRIPLEO_ROOT/heat-templates/hot/software-config/elements
|
||||
|
||||
3) Set a variable so that a custom puppet image gets built and loaded into Glance::
|
||||
|
||||
export OVERCLOUD_DISK_IMAGES_CONFIG=$TRIPLEO_ROOT/tripleo-incubator/scripts/overcloud_puppet_disk_images.yaml
|
||||
|
||||
4) Override the tripleo-heat-templates resource registry::
|
||||
|
||||
export RESOURCE_REGISTRY_PATH="$TRIPLEO_ROOT/tripleo-heat-templates/overcloud-resource-registry-puppet.yaml"
|
||||
|
||||
5) Configure your Delorean repo URL. This is used to fetch more recently built upstream packages for your OpenStack services::
|
||||
|
||||
export DELOREAN_REPO_URL="http://trunk.rdoproject.org/f21/current/"
|
||||
|
||||
For more information on Delorean see [2]_
|
||||
|
||||
6) Enable the use of stackforge modules from Git. This is to work around the fact that the Fedora RPM doesn't have support for all the required modules yet::
|
||||
|
||||
export DIB_INSTALLTYPE_puppet_modules=source
|
||||
|
||||
7) Source your undercloud environment RC file (perhaps via the select-cloud script). Then execute devtest_overcloud.sh::
|
||||
|
||||
devtest_overcloud.sh
|
||||
|
||||
References
|
||||
----------
|
||||
.. [1] http://git.openstack.org/openstack/tripleo-puppet-elements/
|
||||
.. [2] https://github.com/openstack-packages/delorean
|
||||
@ -1,29 +0,0 @@
|
||||
Tripleo team resources
|
||||
======================
|
||||
|
||||
- Launchpad team (lets you get our ssh keys etc easily):
|
||||
|
||||
::
|
||||
|
||||
https://launchpad.net/~tripleo
|
||||
|
||||
- Demo and staging PPAs (for custom binaries):
|
||||
|
||||
::
|
||||
|
||||
apt-add-repository ppa:tripleo/demo
|
||||
apt-add-repository ppa:tripleo/demo-staging
|
||||
|
||||
- Git repositories:
|
||||
|
||||
::
|
||||
|
||||
https://git.openstack.org/cgit/?q=tripleo
|
||||
https://git.openstack.org/cgit/?q=tuskar
|
||||
https://git.openstack.org/cgit/openstack/diskimage-builder
|
||||
|
||||
- IRC: duh.
|
||||
|
||||
::
|
||||
|
||||
irc://irc.freenode.net/#tripleo
|
||||
@ -1,283 +0,0 @@
|
||||
SELinux Developer Guide
|
||||
=======================
|
||||
|
||||
|
||||
Do I have a SELinux problem?
|
||||
----------------------------
|
||||
|
||||
At the moment SELinux is set to run in permissive mode in TripleO. This means
|
||||
that problems are logged but not blocked. To see if you have a SELinux problem
|
||||
that needs to be fixed, examine /var/log/audit/audit.log in your local
|
||||
development environment or from the TripleO-CI log archive. You may need to
|
||||
examine the log files for multiple nodes (undercloud and/or overcloud).
|
||||
|
||||
Any line that has "denied" is a problem. This guide will talk about common
|
||||
problems and how to fix them.
|
||||
|
||||
|
||||
Workflow
|
||||
--------
|
||||
|
||||
All changes are assumed to have been tested locally before a patch is submitted
|
||||
upstream for review. Testing should include inspecting the local audit.log to
|
||||
see that no new SELinux errors were logged.
|
||||
|
||||
If an error was logged, it should be fixed using the guidelines described below.
|
||||
|
||||
If no errors were logged, then the change is submitted for review. In addition
|
||||
to getting the change to pass CI, the audit.log archived from the CI runs should
|
||||
be inspected to see no new SELinux errors were logged. Problems should be fixed
|
||||
until the audit.log is clear of new errors.
|
||||
|
||||
The archived audit.log file can be found in the logs directory for each
|
||||
individual instance that is brought up. For example the seed instance log files
|
||||
can be seen here:
|
||||
|
||||
http://logs.openstack.org/03/115303/1/check-tripleo/check-tripleo-novabm-overcloud-f20-nonha/e5bef5c/logs/seed_logs/
|
||||
|
||||
audit.log is audit.txt.gz.
|
||||
|
||||
ps -efZ output can be found in host_info.txt.gz.
|
||||
|
||||
|
||||
Updating SELinux file security contexts
|
||||
---------------------------------------
|
||||
|
||||
The targeted policy expects directories and files to be placed in certain
|
||||
locations. For example, nova normally has files under /var/log/nova and
|
||||
/var/lib/nova. Its executables are placed under /usr/bin.
|
||||
|
||||
::
|
||||
|
||||
[user@server files]$ pwd
|
||||
/etc/selinux/targeted/contexts/files
|
||||
[user@server files]$ grep nova *
|
||||
file_contexts:/var/lib/nova(/.*)? system_u:object_r:nova_var_lib_t:s0
|
||||
file_contexts:/var/log/nova(/.*)? system_u:object_r:nova_log_t:s0
|
||||
file_contexts:/var/run/nova(/.*)? system_u:object_r:nova_var_run_t:s0
|
||||
file_contexts:/usr/bin/nova-api -- system_u:object_r:nova_api_exec_t:s0
|
||||
file_contexts:/usr/bin/nova-cert -- system_u:object_r:nova_cert_exec_t:s0
|
||||
|
||||
TripleO diverges from what the target policy expects and places files and
|
||||
executables in different locations. When a file or directory is not properly
|
||||
labeled the service may fail to startup. A SELinux AVC denial is logged to
|
||||
/var/log/audit.log when SELinux detects that a service doesn't have permission
|
||||
to access a file or directory.
|
||||
|
||||
When the ephemeral element is active, upstream TripleO places /var/log and
|
||||
/var/lib under the ephemeral mount point, /mnt/state. The directories and files
|
||||
on these locations may not have the correct file security contexts if they were
|
||||
installed outside of yum.
|
||||
|
||||
The directories and files in the ephemeral disk must be updated to have the
|
||||
correct security context. Here is an example for nova:
|
||||
|
||||
https://github.com/openstack/tripleo-image-elements/blob/master/elements/nova/os-refresh-config/configure.d/20-nova-selinux#L6
|
||||
|
||||
::
|
||||
|
||||
semanage fcontext -a -t nova_var_lib_t "/mnt/state/var/lib/nova(/.*)?"
|
||||
restorecon -Rv /mnt/state/var/lib/nova
|
||||
semanage fcontext -a -t nova_log_t "/mnt/state/var/log/nova(/.*)?"
|
||||
restorecon -Rv /mnt/state/var/log/nova
|
||||
|
||||
For nova we use semanage to relabel /mnt/state/var/lib/nova with the type
|
||||
nova_var_lib_t and /mnt/state/var/log/nova with the type nova_var_log_t. Then
|
||||
we call restorecon to apply the labels.
|
||||
|
||||
To see a file's security context run "ls -lZ <filename>".
|
||||
|
||||
::
|
||||
|
||||
[user@server]# ls -lZ /mnt/state/var/lib
|
||||
drwxr-xr-x. root root system_u:object_r:file_t:s0 boot-stack
|
||||
drwxrwx---. ceilometer ceilometer system_u:object_r:file_t:s0 ceilometer
|
||||
drwxr-xr-x. root root system_u:object_r:file_t:s0 cinder
|
||||
drwxrwx---. glance glance system_u:object_r:glance_var_lib_t:s0 glance
|
||||
drwxr-xr-x. mysql mysql system_u:object_r:mysqld_db_t:s0 mysql
|
||||
drwxrwx---. neutron neutron system_u:object_r:neutron_var_lib_t:s0 neutron
|
||||
drwxrwxr-x. nova nova system_u:object_r:nova_var_lib_t:s0 nova
|
||||
drwxrwx---. rabbitmq rabbitmq system_u:object_r:rabbitmq_var_lib_t:s0 rabbitmq
|
||||
|
||||
TripleO installs many components under /opt/stack/venvs/. Executables under
|
||||
/opt/stack/venvs/<component>/bin need to be relabeled. For these we do a path
|
||||
substitution to tell SELinux policy that /usr/bin and
|
||||
/opt/stack/venvs/<component>/bin are equivalent. When the image is relabeled
|
||||
during image build or during first boot, SELinux will relabel the files under
|
||||
/opt/stack/stack/venvs/<component>/bin as if they were installed under /usr/bin.
|
||||
|
||||
An example of a path substitution for nova:
|
||||
|
||||
https://github.com/openstack/tripleo-image-elements/blob/master/elements/nova/install.d/nova-source-install/74-nova
|
||||
|
||||
::
|
||||
|
||||
add-selinux-path-substitution /usr/bin $NOVA_VENV_DIR/bin
|
||||
|
||||
|
||||
Allowing port access
|
||||
--------------------
|
||||
|
||||
Services are granted access to a prespecified set of ports by the
|
||||
selinux-policy. A list of ports for a service can be seen using
|
||||
|
||||
::
|
||||
|
||||
semanage port -l | grep http
|
||||
|
||||
You can grant a service access to additional ports by using semanage.
|
||||
|
||||
::
|
||||
|
||||
semanage port -a -t http_port_t -p tcp 9876
|
||||
|
||||
If the port you are adding is a standard or default port, then it would be
|
||||
appropriate to also file a bug against upstream SELinux to ask for the policy
|
||||
to include it by default.
|
||||
|
||||
|
||||
Using SELinux booleans
|
||||
----------------------
|
||||
|
||||
Sometimes a problem can be fixed by toggling a SELinux boolean to allow certain
|
||||
actions.
|
||||
|
||||
Currently we enable two booleans in TripleO.
|
||||
|
||||
https://github.com/openstack/tripleo-image-elements/blob/master/elements/keepalived/os-refresh-config/configure.d/20-keepalived-selinux
|
||||
|
||||
::
|
||||
|
||||
setsebool -P domain_kernel_load_modules 1
|
||||
|
||||
https://github.com/openstack/tripleo-image-elements/blob/master/elements/haproxy/os-refresh-config/configure.d/20-haproxy-selinux
|
||||
|
||||
::
|
||||
|
||||
setsebool -P haproxy_connect_any 1
|
||||
|
||||
domain_kernel_load_modules is used with the keepalived element to allow
|
||||
keepalive to load kernel modules.
|
||||
|
||||
haproxy_connect_any is used with the haproxy element to allow it to proxy any
|
||||
port.
|
||||
|
||||
When a boolean is enabled, it should be enabled within the element that requires
|
||||
it.
|
||||
|
||||
"semanage boolean -l" lists the booleans that are available in the current
|
||||
policy.
|
||||
|
||||
When would you know to use a boolean? Generating a custom policy for the denials
|
||||
you are seeing will tell you whether a boolean can be used to fix the denials.
|
||||
|
||||
For example, when I generated a custom policy for the haproxy denials I was
|
||||
seeing in audit.log, the custom policy stated that haproxy_connect_any could be
|
||||
used to fix the denials.
|
||||
|
||||
::
|
||||
|
||||
#!!!! This avc can be allowed using the boolean 'haproxy_connect_any'
|
||||
allow haproxy_t glance_registry_port_t:tcp_socket name_bind;
|
||||
|
||||
#!!!! This avc can be allowed using the boolean 'haproxy_connect_any'
|
||||
allow haproxy_t neutron_port_t:tcp_socket name_bind;
|
||||
|
||||
How to generate a custom policy is discussed in the next section.
|
||||
|
||||
|
||||
Generating a custom policy
|
||||
--------------------------
|
||||
|
||||
If relabeling or toggling a boolean doesn't solve your problem, the next step is
|
||||
to generate a custom policy used as an hotfix to allow the actions that SELinux
|
||||
denied.
|
||||
|
||||
To generate a custom policy, use this command
|
||||
|
||||
::
|
||||
|
||||
ausearch -m AVC | audit2allow -M <custom-policy-name>
|
||||
|
||||
.. note:: Not all AVCs should be allowed from an ausearch. In fact, most of
|
||||
them are likely leaked file descriptors, mislabeled files, and bugs in code.
|
||||
|
||||
The custom policies are stored under
|
||||
tripleo-image-elements/elements/selinux/custom-policies. We use a single policy
|
||||
file for each component (one for nova, keystone, etc..). It is organized as per
|
||||
component to mirror how the policies are organized upstream. When you generate
|
||||
your custom policy, instead of dropping in a new file, you may need to edit an
|
||||
existing policy file to include the new changes.
|
||||
|
||||
Each custom policy file must contain comments referencing the upstream bugs
|
||||
(Launchpad and upstream SELinux) that the policy is intended to fix. The
|
||||
comments help with housekeeping. When a bug is fixed upstream, a developer can
|
||||
then quickly search for the bug number and delete the appropriate lines from the
|
||||
custom policy file that are no longer needed.
|
||||
|
||||
Example: https://review.openstack.org/#/c/107233/3/elements/selinux/custom-policies/tripleo-selinux-ssh.te
|
||||
|
||||
|
||||
Filing bugs for SELinux policy updates
|
||||
--------------------------------------
|
||||
|
||||
The custom policy is meant to be used as a temporary solution until the
|
||||
underlying problem is addressed. Most of the time, the upstream SELinux policy
|
||||
needs to be updated to incorporate the rules suggested by the custom policy. To
|
||||
ensure that that upstream policy is updated, we need to file a bug against the
|
||||
selinux-policy package.
|
||||
|
||||
For Fedora, use this link to create a bug
|
||||
|
||||
https://bugzilla.redhat.com/enter_bug.cgi?component=selinux-policy&product=Fedora
|
||||
|
||||
For RHEL 7, use this link to create a bug, and file against the
|
||||
openstack-selinux component, not the selinux-policy component because it is
|
||||
released less frequently.
|
||||
|
||||
https://bugzilla.redhat.com/enter_bug.cgi?product=Red%20Hat%20OpenStack
|
||||
|
||||
Under "Version-Release number" include the package and version of the affected
|
||||
component.
|
||||
|
||||
::
|
||||
|
||||
Example:
|
||||
selinux-policy-3.12.1-179.fc20.noarch
|
||||
selinux-policy-targeted-3.12.1-179.fc20.noarch
|
||||
openssh-6.4p1-5.fc20.i686
|
||||
openssh-clients-6.4p1-5.fc20.i686
|
||||
openssh-server-6.4p1-5.fc20.i686
|
||||
|
||||
Include the ps -efZ output from the affected system. And most importantly
|
||||
attach the /var/log/audit/audit.log to the bug.
|
||||
|
||||
Also file a bug in Launchpad, referencing the bugzilla. When you commit the
|
||||
custom policy into github, the commit message should reference the Launchpad
|
||||
bug ID. The Launchpad bug should also be tagged with "selinux" to make SELinux
|
||||
bugs easier to find.
|
||||
|
||||
Setting SELinux to enforcing mode
|
||||
---------------------------------
|
||||
|
||||
By default in TripleO, SELinux runs in permissive mode. This is set in the
|
||||
NODE_DIST environment variable in the devtest scripts.
|
||||
|
||||
::
|
||||
|
||||
export NODE_DIST="fedora selinux-permissive"
|
||||
|
||||
To set SELinux to run in enforcing mode, remove the selinux-permissive element
|
||||
by adding this line to your ~/.devtestrc file.
|
||||
|
||||
::
|
||||
|
||||
export NODE_DIST="fedora"
|
||||
|
||||
|
||||
Additional Resources
|
||||
--------------------
|
||||
|
||||
1. http://openstack.redhat.com/SELinux_issues
|
||||
2. http://docs.fedoraproject.org/en-US/Fedora/19/html/Security_Guide/ch09.html
|
||||
|
||||
@ -1,101 +0,0 @@
|
||||
Troubleshooting tips
|
||||
====================
|
||||
|
||||
VM won't boot
|
||||
-------------
|
||||
|
||||
Make sure the partition table is correct. See
|
||||
https://bugs.launchpad.net/nova/+bug/1088652.
|
||||
|
||||
Baremetal
|
||||
---------
|
||||
|
||||
If you get a no hosts found error in the schedule/nova logs, check:
|
||||
|
||||
::
|
||||
|
||||
mysql nova -e 'select * from compute_nodes;'
|
||||
|
||||
After adding a bare metal node, the bare metal backend writes an entry
|
||||
to the compute nodes table, but it takes about 5 seconds to go from A to
|
||||
B.
|
||||
|
||||
Be sure that the hostname in nova\_bm.bm\_nodes (service\_host) is the
|
||||
same than the one used by nova. If no value has been specified using the
|
||||
flag "host=" in nova.conf, the default one is:
|
||||
|
||||
::
|
||||
|
||||
python -c "import socket; print socket.getfqdn()"
|
||||
|
||||
You can override this value when populating the bm database using the -h
|
||||
flag:
|
||||
|
||||
::
|
||||
|
||||
scripts/populate-nova-bm-db.sh -i "xx:xx:xx:xx:xx:xx" -j "yy:yy:yy:yy:yy:yy" -h "nova_hostname" add
|
||||
|
||||
|
||||
DHCP Server Work Arounds
|
||||
------------------------
|
||||
|
||||
If you don't control the DHCP server on your flat network you will need
|
||||
to at least have someone put the MAC address of the server your trying
|
||||
to provision in there DHCP server.
|
||||
|
||||
::
|
||||
|
||||
host bm-compute001 {
|
||||
hardware ethernet 78:e7:d1:XX:XX:XX ;
|
||||
next-server 10.0.1.2 ;
|
||||
filename "pxelinux.0";
|
||||
}
|
||||
|
||||
Write down the MAC address for the IPMI management interface and the NIC
|
||||
your booting from. You will also need to know the IP address of both.
|
||||
Most DHCP server won't expire the IP leased to quickly so if your lucky
|
||||
you will get the same IP each time you reboot. With that information
|
||||
bare-metal can generate the correct pxelinux.cfg/. (???? Commands to
|
||||
tell nova?)
|
||||
|
||||
In the provisional environment I have there was another problem. The
|
||||
DHCP Server was already modified to point to a next-server. A quick work
|
||||
around was to redirect the connections using iptables.
|
||||
|
||||
::
|
||||
|
||||
modprobe nf_nat_tftp
|
||||
|
||||
baremetal_installer="<ip address>/<mask>"
|
||||
iptables -t nat -A PREROUTING -i eth2 -p udp --dport 69 -j DNAT --to ${baremetal_installer}:69
|
||||
iptables -t nat -A PREROUTING -i eth2 -p tcp --dport 10000 -j DNAT --to ${baremetal_installer}:10000
|
||||
iptables -A FORWARD -p udp -i eth2 -o eth2 -d ${baremetal_installer} --dport 69 -j ACCEPT
|
||||
iptables -A FORWARD -p tcp -i eth2 -o eth2 -d ${baremetal_installer} --dport 10000 -j ACCEPT
|
||||
iptables -t nat -A POSTROUTING -j MASQUERADE
|
||||
|
||||
Notice the additional rules for port 10000. It is for the bare-metal
|
||||
interface (???) You should have matching reverse DNS too. We experienced
|
||||
problems connecting to port 10000 (????). That may be very unique to my
|
||||
environment btw.
|
||||
|
||||
Image Build Race Condition
|
||||
--------------------------
|
||||
|
||||
Multiple times we experienced a failure to build a good bootable image.
|
||||
This is because of a race condition hidden in the code currently. Just
|
||||
remove the failed image and try to build it again.
|
||||
|
||||
Once you have a working image check the Nova DB to make sure the it is
|
||||
not flagged as removed (???)
|
||||
|
||||
Virtual Machines
|
||||
----------------
|
||||
|
||||
VM's booting terribly slowly in KVM?
|
||||
------------------------------------
|
||||
|
||||
Check the console, if the slowdown happens right after probing for
|
||||
consoles - wait 2m or so and you should see a serial console as the next
|
||||
line output after the vga console. If so you're likely running into
|
||||
https://bugzilla.redhat.com/show\_bug.cgi?id=750773. Remove the serial
|
||||
device from your machine definition in libvirt, and it should fix it.
|
||||
@ -1,39 +0,0 @@
|
||||
Using TripleO
|
||||
=============
|
||||
|
||||
Learning
|
||||
--------
|
||||
|
||||
Learning how TripleO all works is essential. Working through :doc:`devtest` is
|
||||
highly recommended.
|
||||
|
||||
Overview
|
||||
--------
|
||||
|
||||
.. image:: overview.svg
|
||||
|
||||
Setup
|
||||
-----
|
||||
|
||||
The script `install-dependencies` from incubator will install the basic tools
|
||||
needed to build and deploy images via TripleO. What it won't do is larger scale
|
||||
tasks like configuring a Ubuntu/Fedora/etc mirror, a pypi mirror, squid or
|
||||
similar HTTP caches etc. If you are deploying rarely, these things are
|
||||
optional.
|
||||
|
||||
However, if you are building lots of images, having a local mirror of the
|
||||
things you are installing can be extremely advantageous.
|
||||
|
||||
Operating
|
||||
---------
|
||||
|
||||
The general design of TripleO is intended to produce small unix-like tools
|
||||
that can be used to drive arbitrary cloud deployments. It is expected that
|
||||
you will either wrap them in higher order tools (such as CM tools, custom UI's
|
||||
or even just targeted scripts). TripleO is building a dedicated API to unify
|
||||
all these small tools for common case deployments, called Tuskar, but that is
|
||||
not yet ready for prime time. We'll start using it ourselves as it becomes
|
||||
ready.
|
||||
|
||||
Take the time to learn the plumbing - nova, nova-bm or ironic, glance, keystone
|
||||
etc.
|
||||
Binary file not shown.
Binary file not shown.
Binary file not shown.
Binary file not shown.
Binary file not shown.
Binary file not shown.
Binary file not shown.
