Retire tripleo-incubator

This project is no logner maintained or used as part of TripleO.

Change-Id: I0c9d052d2b3e3a3e656342042461b330c74139f0
Related-Bug: #1768590
Alex Schultz 5 years ago
parent b445339881
commit ed8fed7aa2

.gitignore vendored

@ -1,33 +0,0 @@

@ -1,4 +0,0 @@

@ -1,20 +0,0 @@
If you would like to contribute to the development of OpenStack,
you must follow the steps in documented at:
Once those steps have been completed, changes to OpenStack
should be submitted for review via the Gerrit tool, following
the workflow documented at:
Pull requests submitted through GitHub will not be seen.
Bugs should be filed on Launchpad, not GitHub:

@ -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.
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"
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.
- 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.
.. [1]
.. [2]

@ -1,202 +0,0 @@
Apache License
Version 2.0, January 2004
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,
implied, including, without limitation, any warranties or conditions
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.
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
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
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::
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 <>`_.
For any further questions, please email or join #openstack-dev on

@ -1,5 +0,0 @@
if [ -z "${OS_CLOUDPROMPT_ENABLED:-}" ]; then

@ -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
# 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):'In: ' + os.path.abspath('.'))
source_dir = app.srcdir
build_dir = app.outdir'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 = [
# 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 = [
'%s.tex' % project,
u'%s Documentation' % project,
u'OpenStack Foundation', 'manual'),
# Example configuration for intersphinx: refer to the Python standard library.
intersphinx_mapping = {'': None}

@ -1,494 +0,0 @@
Deploying TripleO
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
- Continuous integration (Zuul/Jenkins)
- Monitoring and alerting (Ceilometer/nagios/etc)
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
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 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
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 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 depends on Keystone. The same three deployment options exist as
for Nova.
Keystone has no external dependencies. The same three deployment options
exist as for Nova.
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
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)`_
- 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`:
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.
- 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
- Build the images you need (add any local elements you need to the
- 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'.
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
- Reconfigure the networking within the VM to match your physical
- If you had exotic hardware needs, replace the deploy images that the
bootstack creates.
- 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.
- 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.
- Build the images you need (add any local elements you need to the
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
- Enroll your vanilla image into the glance of that install.
- Enroll your other datacentre machines into that nova baremetal
- 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.
- 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
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 -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
( ).
Also note that dnsmasq may have to be stopped as they both listen to ``*:dhcps``
( ).
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/ \
--interface=br-ctlplane \
- When you setup the seed, use <seedip> instead of, 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 ```` 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
( ).

@ -1,53 +0,0 @@
TripleO Incubator
Getting Started
.. toctree::
:maxdepth: 1
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
Further Information
.. toctree::
:maxdepth: 1
Indices and tables
* :ref:`genindex`
* :ref:`modindex`
* :ref:`search`

File diff suppressed because one or more lines are too long


Width:  |  Height:  |  Size: 19 KiB

@ -1,133 +0,0 @@
TripleO Overcloud deployment with Puppet
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
```` 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
# Do not manage /etc/hosts via cloud-init
# 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::
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
.. [1]
.. [2]

@ -1,29 +0,0 @@
Tripleo team resources
- Launchpad team (lets you get our ssh keys etc easily):
- Demo and staging PPAs (for custom binaries):
apt-add-repository ppa:tripleo/demo
apt-add-repository ppa:tripleo/demo-staging
- Git repositories:
- IRC: duh.

@ -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.
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:
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
[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:
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:
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
Currently we enable two booleans in TripleO.
setsebool -P domain_kernel_load_modules 1
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
When a boolean is enabled, it should be enabled within the element that requires
"semanage boolean -l" lists the booleans that are available in the current
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
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.
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
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.
Under "Version-Release number" include the package and version of the affected
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,101 +0,0 @@
Troubleshooting tips
VM won't boot
Make sure the partition table is correct. See
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
Be sure that the hostname in nova\\_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
scripts/ -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 ;
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\_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 how TripleO all works is essential. Working through :doc:`devtest` is
highly recommended.
.. image:: overview.svg
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
However, if you are building lots of images, having a local mirror of the
things you are installing can be extremely advantageous.
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
Take the time to learn the plumbing - nova, nova-bm or ironic, glance, keystone

Binary file not shown.

Binary file not shown.

Binary file not shown.

Binary file not shown.

Binary file not shown.

@ -1,469 +0,0 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!-- Created with Inkscape ( -->
inkscape:version=" r9886"
id="title4133">TripleO Concept</title>
id="defs4" />
inkscape:window-maximized="0" />
rdf:resource="" />
<dc:title>TripleO Concept</dc:title>
<dc:title>Clint Byrum</dc:title>
<dc:title>HP Cloud Services</dc:title>
rdf:resource="" />
rdf:resource="" />
rdf:resource="" />
rdf:resource="" />
rdf:resource="" />