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

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

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.