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:

• 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 easily be reassigned to a new, valid couple, without erasing an existing (automatically created) smart-variable.
  This makes it impractical for the user interface. But note that it is feasible.
• Note that puppetclass or parameter renames cannot, generally speaking, be detected. Hence we can only to add/delete.

So we would need to separate puppetclass parameters from the eventual smart-variables that will control them.
That way:

• We can show the obsolete smart-variables (no longer bound to a value {puppetclass, parameter} couple).
• We can show uncontrolled parameters: puppetclass parameters without a bound smart-variable.
  We can visually separate mandatory uncontrolled parameters from optional ones (which have a default value, hence won't raise errors).
• Provide a way to rebind an obsolete smart-variable to a yet unbound {puppetclass, parameter} couple.
• Provide a way to create a smart-variable for an uncontrolled parameter, presenting a form for the necessary configuration.
• Additionally provide an easy way to automatically create a noop smart-variable for an optional parameter.

So we need to easily see the mapping between smart-variables and puppetclasses parameters.
We can either:

• Store a serialized hash into a new parameters column of the puppetclasses table.
  But this would mean parsing them all to see which are not controlled by a smart-variable.
• Create an entry in the parameters table of type PuppetClassParameter, filling the name and value from the smart-proxy's output and binding it to the corresponding puppetclass.

I favor the second solution. Do you see any other?

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.