![Flavio Percoco](/assets/img/avatar_default.png)
This patch adds the team's and repository's badges to the README file. The motivation behind this is to communicate the project status and features at first glance. For more information about this effort, please read this email thread: http://lists.openstack.org/pipermail/openstack-dev/2016-October/105562.html To see an example of how this would look like check: https://gist.github.com/39dd99e3df15f4e4602c9fed19edd969 Change-Id: I272463bd05afca3b75d243e50d66d37ceac954b9
91 lines
3.6 KiB
Markdown
91 lines
3.6 KiB
Markdown
Team and repository tags
|
|
========================
|
|
|
|
[![Team and repository tags](http://governance.openstack.org/badges/tripleo-puppet-elements.svg)](http://governance.openstack.org/reference/tags/index.html)
|
|
|
|
<!-- Change things from this point on -->
|
|
|
|
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 (https://wiki.openstack.org/wiki/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://git.openstack.org/openstack/diskimage-builder.git
|
|
git clone https://git.openstack.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.
|