Openstack:Getting Started with COE development

From DocWiki

Revision as of 01:15, 7 May 2013 by Michchap (Talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Cisco's Edition of Openstack (COE) is almost entirely composed of Puppet modules with a small number of bash scripts. At its core, puppet is a system that enables users to describe the state of the system they are managing, and the puppet runtime will ensure that the system matches that state. Do do this, puppet manages a number of what are termed "Resources". For example, puppet can ensure that a package is installed, that a file has certain contents, or that a service is running. In fact, for many simple deployments, these three resources will cover all of what is required. These resources can be grouped into classes and modules, to allow developers to separate concerns.

Before attempting to modify COE, it is recommended that developers are comfortable writing their own puppet modules. There is a wealth of information on the Puppetlabs site including a tutorial on how to work with Puppet.

COE Structure

COE currently uses 33 Puppet modules, each managing a particular part of the deployment, plus a "manifests" package that ties together the modules. For example, the naginator module is used to install the nagios monitoring system on all nodes, so in the manifests package there are lines of puppet that enable this module for each node. The way this is structured, there is a class called control, and a class called compute within the manifests, like so:

manifests/core.pp

class control() {
  #the things we want on each openstack controller
}

class compute() {
  #the things we want on each openstack compute node
}

So to have a compute node, in site.pp we could have a line such as:

manifests/site.pp

node my_compute_node {
  class { compute: }
}

This allows us to easily configure the compute and control nodes separately. To have something on every node, such as an apt key, we create a node type and inherit our nodes from that, like so:

manifests/core.pp

node base {
  class { "naginator::base_target":
  }
}

manifests/site.pp

node my_compute_node inherits base { 
  class { compute: }
}

These are the two main mechanisms in place for controlling what is installed on the nodes managed by puppet. If you look through the folsom-manifests repository, you'll see that there are a number of differences to what is shown above:

  1. There are a large number of arguments to each of the classes. This allows customisation without having to edit anything more than site.pp.
  2. There is more than one base class. Because the build node sits outside the openstack cluster but is still managed by puppet, there is a base node type, then inheriting from that that there is os_base for openstack nodes and build-node for the build node.
  3. Nodes seem to be defined twice in site.pp. This is because they are defined once for the build node via their out of band address so that it can PXE boot and install ubuntu, and once so that puppet can manage them.

Rating: 5.0/5 (1 vote cast)

Personal tools