Jump to: navigation, search

PuppetConfigForNova

Revision as of 23:30, 17 February 2013 by Ryan Lane (talk | contribs) (Text replace - "__NOTOC__" to "")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
  • Launchpad Entry: FIXME
  • Created: 17 Jan 2012
  • Contributors: Andrew Bogott, Ryan Lane

Summary

Support puppet config on instances via the Nova API.

Release Note

Administrators will be able to notify Nova about a list of available puppet classes and their associated variables.

Administrators will be able to set default classes and default variable values cloud-wide or for specified projects.

Users will be able to include and configure a select set of optional Puppet classes and variables for an instance.

Rationale

Currently providing new system configurations on Nova requires the creation of a custom image. Adding Puppet support will allow for much finer-grained control of instance configuration.

User stories

Assumptions

- All images discussed in this design are presumed to be Puppet-ready, with a puppet client preinstalled to run on creation.

- Instances are presumed to know any puppet config info they need at creation time (e.g. how to contact the puppet master).

- All puppet classes are presumed to behave sensibly on all image types.

- The puppet master (if any) may or may not be hosted within openstack; configuration of the master is not addressed by this design.

Design

First, the administrator will notify Nova about the existence of arbitrarily-named classes and variables. This set of classes and variables makes up the Global Puppet Menu. Classes in the Global menu may be turned on by default, and variables given default values.

For a given project, each class on the Global Puppet Menu will have one of three states: Unavailable, Available, or Default. All classes begin in a state of 'unavailable', but the state can be changed via an API call. A state of 'Default' means that those classes will be installed on all instances within the project. Variables are handled similarly, but if they are set to the 'Default' state they will also accept a default value. The set of available or default classes and variables in a project make up the Project Puppet Menu.

Before launch or at runtime, the user of an instance can manipulate classes and variables from the Project Puppet Menu. 'Available' classes can be turned on or off. 'Default' classes are on by default, but may be turned off. The user can also configure puppet variables from the Project Menu as needed.

When in instance is created or the puppet settings for an instance are changed, a site.pp file within the instance will be synchronized to the specified settings.

Implementation

Three new tables will be added to the Nova database: puppet_entries, puppet_project_states and puppet_instance_states. Each class or variable will have a record in puppet_entries (possible with additional information, e.g. data type or default values). Then, for each project, classes or variables can be made available by adding a record to the puppet_project_states relating a class or variable to a project or instance and specifying installation state and default values. Similarly, any time a class or variable state in an instance varies from the state specified in puppet_project_states, it will have an appropriate entry in puppet_instance_states.

Communicating puppet information to instances will be handled by a configurable driver in order to support various puppet configurations. The first driver will use file injection, compiling all of the appropriate data records into a single site.pp file and installing that file in an appropriate location on the instance.

The driver will provide a very simple interface, something like:

puppetize(instance_id, dictionary_of_classes_and_variables)

FIXME: Should we break apart classes and variables so that there are six tables instead of three, and three driver args instead of two?

UI Changes

The 'nova' and/or 'nova-manage' commandline tools will be extended to provide Puppet configuration options. Most likely this interface will include file-based options since the configurations will be long-winded.

Ideally, Horizon will also provide a configuration tool, although this will most likely be left for later.

Code Changes

Migration

Test/Demo Plan

Unresolved issues

BoF agenda and discussion