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.
Copyright
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:
https://docs.openstack.org/releasenotes/tripleo-puppet-elements
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)
| File | Size | Uploaded | Provenance | |
|---|---|---|---|---|
| tripleo-puppet-elements-16.0.0.tar.gz | 34.7 kB | Without provenance | Details |
Built distribution (wheel)
| File | Interpreter | ABI | Platform | Reset |
|---|---|---|---|---|
| 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.