Puppet elements for deployment of OpenStack
Go to file
Andreas Jaeger 276d2cf9b6 Cleanup py27 support
This repo is now testing only with Python 3, so let's make
a few cleanups:
- Add requires on python >= 3.6 to setup.cfg so that pypi and pip
  know about the requirement
- Remove obsolete sections from setup.cfg
- Update requirements, no need for python_version anymore
- Use newer openstackdocstheme and Sphinx versions
- Remove install_command from tox.ini, the default is fine
- Remove babel.cfg, it's not needed
- move basepython into testenv

Change-Id: I4c0e3b9b12c6b46c3b6b6a2f8f96e6996421dd8d
2020-05-03 17:12:48 +02:00
doc/source Bump the openstackdocstheme extension to 1.20 2019-08-09 15:59:56 +08:00
elements overcloud-compute: add ndctl package to manage NVDIMMs 2020-04-14 15:21:51 +02:00
releasenotes Remove libvirt package 2019-10-31 20:04:44 +01:00
tests Update repository after OpenStack migration 2014-10-02 09:53:08 -04:00
tools tox: Keeping going with docs 2019-11-03 02:55:08 +08:00
zuul.d update tox tests for py3 2020-02-04 21:26:49 +00:00
.gitignore Add reno support 2017-01-27 10:58:48 -05:00
.gitreview OpenDev Migration Patch 2019-04-19 19:42:08 +00:00
.testr.conf Update repository after OpenStack migration 2014-10-02 09:53:08 -04:00
LICENSE Basic structure imported from tripleo-image-elements 2014-09-08 18:58:08 -04:00
MANIFEST.in Basic structure imported from tripleo-image-elements 2014-09-08 18:58:08 -04:00
README.rst update git.openstack.org to opendev 2019-05-20 19:28:22 +00:00
requirements.txt Cleanup py27 support 2020-05-03 17:12:48 +02:00
run-flake8 Update repository after OpenStack migration 2014-10-02 09:53:08 -04:00
setup.cfg Cleanup py27 support 2020-05-03 17:12:48 +02:00
setup.py Basic structure imported from tripleo-image-elements 2014-09-08 18:58:08 -04:00
test-requirements.txt Cleanup py27 support 2020-05-03 17:12:48 +02:00
tox.ini Cleanup py27 support 2020-05-03 17:12:48 +02:00


Team and repository tags


Puppet building rules for OpenStack images

These elements are used to build disk images for deploying OpenStack via Heat. They are built as part of the TripleO umbrella project.


Checkout this source tree and also the diskimage builder, export an ELEMENTS_PATH to add elements from this tree, and build any disk images you need:

git clone https://opendev.org/openstack/diskimage-builder.git
git clone https://opendev.org/openstack/tripleo-puppet-elements.git
export ELEMENTS_PATH=tripleo-puppet-elements/elements
diskimage-builder/bin/disk-image-create -u base vm bootstrap local-config stackuser heat-cfntools -a i386 -o bootstrap

Common element combinations

Always include heat-cfntools in images that you intend to boot via heat : if that is not done, then the user ssh keys are not reliably pulled down from the metadata server due to interactions with cloud-init.


OpenStack images are intended to be deployed and maintained using Nova + Heat.

As such they should strive to be stateless, maintained entirely via automation.


In a running OpenStack there are several categories of config.

  • per user - e.g. ssh key registration with nova: we repeat this sort of config every time we add a user.
  • local node - e.g. nova.conf or ovs-vsctl add-br br-ex : settings that apply individually to machines
  • inter-node - e.g. credentials on rabbitmq for a given nova compute node
  • application state - e.g. 'neutron net-create ...' : settings that apply to the whole cluster not on a per-user / per-tenant basis
We have five places we can do configuration in TripleO:
  • image build time
  • in-instance heat-driven (ORC scripts)
  • in-instance first-boot scripts [deprecated]
  • from outside via APIs
  • orchestrated by Heat

Our current heuristic for deciding where to do any particular configuration step:

  • per user config should be done from the outside via APIs, even for users like 'admin' that we know we'll have. Note that service accounts are different - they are a form of inter-node configuration.
  • local node configuration should be done via ORC driven by Heat and/or configuration management system metadata.
  • inter-node configuration should be done by working through Heat. For instance, creating a rabbit account for a nova compute node is something that Heat should arrange, though the act of creating is probably done by a script on the rabbit server - triggered by Heat - and applying the config is done on the compute node by the local node script - again triggered by Heat.
  • application state changes should be done from outside via APIs
  • first-boot scripts should not be used.

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.

Release notes for the project can be found at: