stackforge/puppet_openstack_builder
Code Issues Proposed changes

Added more doc on stack-builder data flow

Browse Source
This commit is contained in:
Michael Chapman
2013-10-14 17:06:51 +11:00
parent 73a22a152e
commit 8cded0a3b9
1 changed files with 33 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

33
stack-builder/README.md
View File

@@ -189,3 +189,36 @@ Example:
sb log -t 18dbb77039754173b68d9deabbb88505
## Data Flow
There are broadly two data categories of concern: data that controls the build environment, such as how many virtual machines to build and which networks to put them on, and data that controls the openstack cluster that is build using puppet. Stack-builder defines the former as conf data and the latter as user data.
### User data
Since user data is really just serving as an input to puppet, it config is quite simple to deal with: there are four yaml files in data/hiera\_data - user.yaml, jenkins.yaml, user.common and user.[scenario].yaml that are loaded into a single dictionary in python, along with any environment variables with the prefix osi\_user\_. The order or precedence is env. vars > user.yaml > jenkins.yaml > user.common > user.[scenario].yaml. After these have all been loaded and the dictionary has been created, this is written to a string and sent to every virtual machine as /root/user.yaml. This is then copied to /etc/puppet/data/hiera\_data/user.yaml by the deploy script. Because user.yaml has the highest precedence in hiera, this can be used to override any settings in the openstack puppet modules.
The sb meta command can be used with the flag '-c user' to inspect the data that will be loaded.
### Conf data + build configuration
Config data is slightly more complex, since it effectively deals with preparing the cluster to run puppet. First, depending on which scenario has been selected, the script will load data/nodes/[scenario].yaml. This will define which VMs to create and which networks to create. The script will use the quantum API to create the appropriate networks along with ports for each VM. In the network section of the yaml file, some of the networks are also mappings themselves, such as build-server: networks: ci: cobbler\_node\_ip. A dictionary of runtime-config is created, with each of these mappings set as a key, and the value set as the IP address obtained for the appropriate port from quantum. So we end up with a dictionary that might look like this in a 2\_role scenario:
runtime\_config = {'cobbler\_node\_ip' : '10.123.0.22',
'control_node_ip' : '10.123.0.23'}
This is the runtime config, and any data set here will override data from either environment variables or config files.
Environment variables with the prefix osi\_conf\_ are put into the dictionary along with everything from data/config.yaml. Environment variables take precedence over config.yaml.
This leaves us with a dictionary of all the config values we care about.
This is written to a string and pushed to each node as /root/config.yaml
The sb meta command can be used with the flag '-c conf' to inspect what will be loaded.
Now that networks have been created and runtime+static config has been loaded, data/nodes/[scenario].yaml is examined again, this time to look at which fragments are specified for each node. Fragments are small snippets of bash in the stack-builder/fragments directory, and the list for each node will determine which ones are needed for each node. For example, the puppet master will need to run puppet apply, while the puppet agents will need to run puppet agent. Templating is in use in these fragments, and after they have been composed into a single string for each node, substitution occurs for each value in the runtime-config. This lets the agent nodes know where the master is, and lets compute nodes know where the controller is (from runtime data); lets nodes know which domain they are a part of, and which ntp server to sync with (needed to run puppet, from config.yaml), and any user specified overrides to change per run, such as a particular repository or branch to use for a puppet module (from environment variables). After templating has been handled, the final scripts are written to /root/deploy on each node. Cloud init will blindly execute whatever it finds there on each node.
The sb frag command can be used to inspect what these build scripts will look like on each node
One of the fragments will load /root/config.yaml and export all its values as environment variables with the prefix FACTER\_, making them available to the initial puppet setup. Be very careful when changing config.yaml, since for example, changing 'Ubuntu' to 'ubuntu' will prevent puppet from running, and in general system facts can be overridden causing strange behavior.