Skip to main content
http://governance.openstack.org/badges/tripleo-puppet-elements.svg

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.

Instructions

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.

Architecture

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

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

Configuration

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.

Metadata

Release files for tripleo-puppet-elements 16.0.0

For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.

Source distribution (sdist)

Source distribution for tripleo-puppet-elements 16.0.0
File Size Uploaded Provenance
tripleo-puppet-elements-16.0.0.tar.gz 34.7 kB Without provenance Details

Built distribution (wheel)

Table of built distributions (wheels) for tripleo-puppet-elements 16.0.0
File Interpreter ABI Platform
tripleo_puppet_elements-16.0.0-py3-none-any.whl Python 3 none any Details

Total release size: 64.2 kB

Release files / tripleo-puppet-elements-16.0.0.tar.gz

Download URL tripleo-puppet-elements-16.0.0.tar.gz
Size 34.7 kB
Tags Source
SHA-256 checksum
How to use checksums
ac09060f1733f8d088bd9203528cc03a5fe0dd8e8fd31cc9d2c5e62f9850cca6
BLAKE2b-256 checksum
How to use checksums
fee102478452762e7e5b9736a652b6da091d417e63a40dc672d6a16e435ca772
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
No
Uploaded via twine/4.0.1 CPython/3.10.8

Release files / tripleo_puppet_elements-16.0.0-py3-none-any.whl

Download URL tripleo_puppet_elements-16.0.0-py3-none-any.whl
Size 29.6 kB
Tags Python 3
SHA-256 checksum
How to use checksums
8a6e01416f6985e9666381f1424f4ab96ad69c689b75c15a07b0ec60e6de7f3d
BLAKE2b-256 checksum
How to use checksums
87bbca510c001fd97df9a74a0aa147918362baf10b5f47adcf153e0154cb83e9
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
No
Uploaded via twine/4.0.1 CPython/3.10.8

Security for tripleo-puppet-elements 16.0.0

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

No provenance found

None of the files in this release were uploaded with provenance metadata.

A note on package security

PyPI is a repository for distributing packages, not a service for auditing them. While third-party security researchers and our staff do their best to detect and remove malicious packages, PyPI cannot guarantee the quality, security or suitability of any given package.

To learn more about protecting yourself from malicious actors, visit our package security documentation.

Release history Release notifications | RSS feed

This release

16.0.0 This release

2 release files No provenance

2.0.0

Anthropic, PBC Visionary sponsor Bloomberg Visionary sponsor Hudson River Trading Visionary sponsor Meta Visionary sponsor NVIDIA Visionary sponsor Microsoft Sustainability sponsor Depot Continuous Integration AWS Cloud computing and Security Sponsor Datadog Monitoring Fastly CDN Google Download Analytics Sentry Error logging StatusPage Status page