Parameterized class development - Ofavre's analysis¶

Puppet classes parameters and smart variables¶

Making the smart-proxy return the parameters¶

Puppet classes parameters are given by the smart-proxy:
The current answer of smart-proxies are:

[
  {
    "amodule::aclass" : 
    {
      "module" : "amodule",
      "name" : "aclass" 
    }
  },
  ...
]

I've extended it to give the extracted parameters, using the Puppet::Parser:

[
  {
    "amodule::aclass" : 
    {
      "module" : "amodule",
      "name" : "aclass",
      "params" : {}   # no parameters
    }
  },
  {
    "amodule::aparameterizedclass" : 
    {
      "module" : "amodule",
      "name" : "aparameterizedclass",
      "params" : {
        "mandatoryParam" : null,
        "optionalNumericParam" : "42",
        "optionalStringParam" : "\"foo\"" 
        "optionalConcatParam" : "company@$::hostname" 
      }
    }
  },
  ...
]

The values of the parameters are either null if there is none, or the string representation of the AST::Leaf (see lib/puppet/parser/ast/leaf.rb).
Its likely not perfect yet.

Storing the parameters in the db¶

We can do multiple things to represent the parameters in the database, but we need to know what we want to do with them before choosing the right representation.
We want to:

• Be able to sync the db when importing puppet classes.
  This means addition, deletion of puppet classes and parameters.
• Control the value of the parameter using a smart-variable, with a potentially complex set of matchers.
  We never want to loose this complex configuration.

So we can directly:

• Create a new smart-variable for each new {puppetclass, parameter} couple on importing
• But we need not to delete a smart-variable for an obsolete {puppetclass, parameter} couple.
  (We could do it automatically if and only if the description and default value were left intact, and there is no matchers).

But this will not be very practical in a few cases:

• New mandatory parameters would need their smart-variable configured, or it will generate errors.
  Hence we need to make this visible somehow.
• An old smart-variable, no longer attached to a valid {puppetclass, parameter} couple cannot be reassigned to a new, valid couple, without erasing an existing (automatically created) smart-variable.
  We would need a conflict resolution, or a mere "confirm overwrite".
• Note that puppetclass or parameter renames cannot, generally speaking, be detected. Hence we can only add/delete.
• As one can use foreman forms to create each environment, puppetclass and parameter, instead of using the import feature, there is no way to warn the user he has deleted a smart-variable for a parameter and left a possibly mandatory parameter with no values.

So we need to easily see the mapping between smart-variables and puppetclasses parameters, as opposed to a global scope smart-variable attached to a puppetclass.
We need to:

• Use a special prefix like: puppetmodule::puppetclass/parametername.

Mandatory parameters¶

First we'll have to make smart-variables explicitly either optional or mandatory.
A mandatory smart-variable has no default value and should raise an error if its matchers yield no value during evaluation.

How could we represent a smart-variable without default value (ie. mandatory)?

• Be close to the code: "strings" are quoted, digits are not, [lists] have brackets, {:hash=>"es"} have braces, and a blank value means no default value.
• Forget about typed values and use a checkbox: string and digits are not quoted, lists and hashes need to be @eval()@ed, and a blank value means an empty string.

What should we do when creating a new host with a class without a smart-variable controlling a mandatory parameter?

• Raise an error "please contact your sysadmin"?
• Provide a text field to provide a value?
  Where should the value be stored? (as a HostParameter, with a "puppetclass::" prefix?)
• Create a smart-variable with a order:fqdn and a matcher on the fqdn for the host to build?

Supporting non uniform classes across environments¶

In puppet, classes are totally separate from an environment to another.
Hence it is possible that classes have the same name in two environments while having different parameters.
Currently puppetclasses are linked to environments with an n-n relation.
This need to be changed to a n-1 relation (envs. having many classes, a class belonging to a single env.).

However, in order to reduce redundancy in the configuration, we may need to bind a smart-variable to multiple environments, ie. to same-named puppet classes across different environments.