Difference between revisions of "PuppetConfigForNova"
Line 21: | Line 21: | ||
All images discussed in this design are presumed to be Puppet-ready, with a puppet client preinstalled to run on startup. | All images discussed in this design are presumed to be Puppet-ready, with a puppet client preinstalled to run on startup. | ||
+ | |||
+ | Instances will magically know any puppet config info they need. | ||
The puppet server may or may not be hosted within openstack; it will be identified by an arbitrary hostname. | The puppet server may or may not be hosted within openstack; it will be identified by an arbitrary hostname. | ||
== Design == | == Design == | ||
+ | |||
+ | FIXME: be blind to image type -- assume classes are cross-platform | ||
+ | FIXME: Also manage on a global basis as well as per-project | ||
Each image type within a given project can be configured with a Puppet server. Information about contacting this server (hostname, keys, path, whatever) will be provided to instances on creation. | Each image type within a given project can be configured with a Puppet server. Information about contacting this server (hostname, keys, path, whatever) will be provided to instances on creation. |
Revision as of 22:39, 19 January 2012
- Launchpad Entry: FIXME
- Created: 17 Jan 2012
- Contributors: Andrew Bogott, Ryan Lane
Summary
Release Note
Administrators will be able to include a set of mandatory or optional Puppet classes in a project.
Users will be able to include and configure a select set of optional Puppet classes in 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 startup.
Instances will magically know any puppet config info they need.
The puppet server may or may not be hosted within openstack; it will be identified by an arbitrary hostname.
Design
FIXME: be blind to image type -- assume classes are cross-platform FIXME: Also manage on a global basis as well as per-project
Each image type within a given project can be configured with a Puppet server. Information about contacting this server (hostname, keys, path, whatever) will be provided to instances on creation.
Each image type within a given project can be configured with a list of required classes. This set of classes will be injected into each instance on creation.
Each image type within a given project can be configured with a list of optional classes.
Users will be able to query an instance about optional and required classes. Users will be able to select or deselect optional classes.
(FIXME: also, variables) (FIXME: should we support modules control instead of or in addition to class control?)
Implementation
FIXME: Wikimedia's Puppet setup uses LDAP to manage the set of classes on an instance. That's probably not practical for openstack, so we may need to return to ordinary file-based control. Of course, that'll make querying a specific instance pretty hard; we can mirror instance config in the database, but then we run the risk of getting out of sync.
UI Changes
The 'nova' and/or 'nova-manage' commandline tools will be extended to provide Puppet configuration options. Most likely this interface will include a --file option since the configurations will be long-winded.
Ideally, Horizon will also provide a configuration tool, although this will most likely be left for later.