Jump to: navigation, search

Difference between revisions of "PackageConfigForNova"

 
m (Text replace - "__NOTOC__" to "")
 
Line 1: Line 1:
__NOTOC__
+
 
 
* '''Launchpad Entry''': FIXME
 
* '''Launchpad Entry''': FIXME
 
* '''Created''': 27 Jan 2012
 
* '''Created''': 27 Jan 2012

Latest revision as of 23:30, 17 February 2013

  • Launchpad Entry: FIXME
  • Created: 27 Jan 2012
  • Contributors: Andrew Bogott, Ryan Lane

Summary

Support per-instance package configuration via the Nova API. A 'package' may be a puppet class, a chef recipe, an apt package, etc.

Release Note

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

Administrators will be able to set the default set of packages to be installed (either cloud-wide or for specified projects.)

Users will be able to include and configure a select set of packages for a given instance.

Rationale

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

User stories

Assumptions

- This design assumes that system configuration can be described via two data types, 'packages' and 'variables'. In implementation a 'package' may actually represent a script or recipe, but it should correspond to a single unit of system configuration.

- All images discussed in this design are presumed already contain the necessary tools to process the data or files provided by the package configuration.

- Similarly, processing of configuration and communication of that config between nova and the instance will be managed by a driver whose internals are not discussed here.

- Packages are presumed to be cross-platform such that the installation of a given package will do something sensible on all instances regardless of guest OS. Clearly the implementation of a package may vary by OS.

Design

Nova configuration will provide the following option:

  • package_management_driver

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

For a given project, each package in the Global Package 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 packages 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 Package Menu.

Before launch or at runtime, the user of an instance can manipulate classes and variables from the Project Package 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 Package variables from the Project Menu as needed.

When an instance is created or the package settings for an instance are changed, the package management driver will be invoked with the new set of packages and variables. This updated list will be communicated to the guest instance, as if by magic.

Implementation

Three new tables will be added to the Nova database: package_entries, package_project_states and package_instance_states. Each class or variable will have a record in package_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 package_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 package_project_states, it will have an appropriate entry in package_instance_states.

Communicating Package information to instances will be handled by the package_management_driver. For example, in an install using puppet, the driver could place the selected packages into an LDAP database that is shared with the instance, or it could generate a sites.pp file on a volume shared with the instance.

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

configure_packages(instance_id, dictionary_of_classes_and_variables)

UI Changes

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

$ nova package-add <instance-id> apache2

or

$ nova package-config <instance-id> --file <file with list of packages and variables>

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