Let’s go a bit further down the PuppetLabs-Grizzly rabbit hole. We talked quite extensively about these on the #vBrownBag, but some of them need a bit further explanation here.

Background

PuppetLabs/Grizzly is a ‘new’ (new is a relative thing on the internets, and depending on when you find this post, it may not be so very new after-all). I did a quick “getting started” bit with it here.

 Going Deeper

• The PuppetLabs/Grizzly module extends or enhances the existing Stackforge “PuppetLabs-OpenStack” project, rather than replace it.
• The Grizzly module currently defines four roles (here):
  • “Controller” – Most APIs, Keystone, Horizon, Database, Cache, etc
  • “Compute” – Runs the instances, also Open vSwitch
  • “Network” – Neutron and other bits as needed.
  • “Storage” – Glance, Cinder, etc.
• The roles are derived from “Profiles” (here)
• The profiles provide configuration bits for other modules that are pulled in.

Confused? Here’s how it flows visually:

The “configuration” or profile bits are what pull in the values from Hiera and ensure they end up in the respective OpenStack configuration files. Separating the config and role definition allows for a very clean definition for a role. Let’s look at an example, say how does the openrc file get created on the controller. We’ll look at this in reverse order:

The Role: controller.pp

class grizzly::role::controller inherits ::grizzly::role {
class { '::grizzly::profile::rabbitmq': } ->
class { '::grizzly::profile::memcache': } ->
class { '::grizzly::profile::mysql': } ->
class { '::grizzly::profile::keystone': } ->
class { '::grizzly::profile::glance::auth': } ->
class { '::grizzly::profile::cinder::api': } ->
class { '::grizzly::profile::nova::api': } ->
class { '::grizzly::profile::quantum::server': } ->
class { '::grizzly::profile::horizon': }
class { '::grizzly::profile::auth_file': }
}

There we are, a clean role definition. Which is great, but, how does one provide a configuration to it? That’s where the next step comes in.

The Profile: auth_file.pp

To pull in the configuration that auth_file needs, the profile bit is used:

class grizzly::profile::auth_file {
  class { '::openstack::auth_file':
    admin_password  => hiera('grizzly::keystone::admin_password'),
    region_name     => hiera('grizzly::region'),
    controller_node => hiera('grizzly::controller::address::api'),
  }
}

What this does, is draw in the puppetlabs-openstack module, and the auth_file manifest. It then provides it configuration data that’s stored in Hiera. We’re still pretty clean here, but imagine having each of the role’s functions broken out like this. It gets difficult to manage quickly.

Each of the additional roles & profiles work in much the same way.

Assigning a Role to a Node

Now that we’ve investigated how roles are built out of their requisite parts, the assignment of a role to a node is a pretty straightforward affair. That is, as you add the role to a node in much the same way as you define a site or environment manifest. Here is the site.pp example provided:

node 'storage.localdomain' {
  include ::grizzly::role::storage
}

node 'network.localdomain' {
  include ::grizzly::role::network
}

node /compute[0-9]+.localdomain/ {
  include ::grizzly::role::compute
}

Taking a quick look, any node that registers with a hostname matching ‘storage.localdomain’ will be assigned the storage role, and have all of the cinder, glance, etc bits installed. You’d want to adjust this for your environment.

Resources