h1. Parameterized class development - Ofavre's analysis

h2. Puppet classes parameters and smart variables

h3. Making the smart-proxy return the parameters

Puppet classes parameters are given by the smart-proxy:

The current answer of smart-proxies are:

<pre>

[

  {

    "amodule::aclass" : 

    {

      "module" : "amodule",

      "name" : "aclass"

    }

  },

  ...

]

</pre>

I've extended it to give the extracted parameters, using the "@Puppet::Parser@":https://github.com/puppetlabs/puppet/blob/master/lib/puppet/parser:

<pre>

[

  {

    "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"

      }

    }

  },

  ...

]

</pre>

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":https://github.com/puppetlabs/puppet/blob/master/lib/puppet/parser/ast/leaf.rb).

Its likely not perfect yet.

h3. 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?

h2. 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.