Using Foreman with Puppet 3 data binding

I've been experimenting today with an idea to connect Foreman into
Puppet 3, using its new "data binding" terminus. This was added to
support Hiera lookups without requiring explicit hiera() function calls.

It simply performs Hiera lookups on all class parameters that haven't
been specified, e.g.

class foo($bar) { … }

include foo

This would automatically look up the key "foo::bar" via the data binding
implementation.

With Foreman, we'd normally include "foo" from the ENC interface and
supply parameters there. Where data binding is particularly useful is
where you have multiple levels of classes, since you don't have to pass
parameters through all the levels. A good example would be roles:

this gets added to the host in Foreman

class role::webserver {
include httpd
}

class httpd($document_root, $user, $group) {
# …
}

Puppet 3 will look up "httpd::document_root", "httpd::user" and
"httpd::group" automatically, without us needing to supply them in the
role class.

There are two pieces to the implementation:

  1. Foreman plugin, foreman_param_lookup
    (https://github.com/domcleal/foreman_param_lookup)

This exposes a simple route to look up parameters for a given host and
class. It extends the Classification model which normally works only
for classes that are associated with the host, by performing the
parameter lookup for the supplied class instead.

  1. Puppet module, foreman_data_binding
    (https://github.com/domcleal/foreman_data_binding)

This adds a new terminus to the data_binding indirector that just
queries the URL above.

Going back to the above example, with the "httpd" class imported in
Foreman, you could define matchers and the hierarchy through the Foreman
interface and it would automatically get used whenever the httpd class
was included, whether directly in the ENC or elsewhere.

I don't see that this replaces the ENC, but instead complements it by
making smart class parameters extend deeper into the Puppet manifests,
beyond what the ENC interface offers.

Thoughts and comments are welcome.

··· -- Dominic Cleal Red Hat Engineering

>
> I've been experimenting today with an idea to connect Foreman into
> Puppet 3, using its new "data binding" terminus. This was added to
> support Hiera lookups without requiring explicit hiera() function calls.
>
> It simply performs Hiera lookups on all class parameters that haven't
> been specified, e.g.
>
> class foo($bar) { … }
>
> include foo
>
> This would automatically look up the key "foo::bar" via the data binding
> implementation.
>
> With Foreman, we'd normally include "foo" from the ENC interface and
> supply parameters there. Where data binding is particularly useful is
> where you have multiple levels of classes, since you don't have to pass
> parameters through all the levels. A good example would be roles:
>
> # this gets added to the host in Foreman
> class role::webserver {
> include httpd
> }
>
> class httpd($document_root, $user, $group) {
> # …
> }
>
> Puppet 3 will look up "httpd::document_root", "httpd::user" and
> "httpd::group" automatically, without us needing to supply them in the
> role class.
>
> There are two pieces to the implementation:
>
> 1. Foreman plugin, foreman_param_lookup
> (https://github.com/domcleal/foreman_param_lookup)
>
> This exposes a simple route to look up parameters for a given host and
> class. It extends the Classification model which normally works only
> for classes that are associated with the host, by performing the
> parameter lookup for the supplied class instead.
>
> 2. Puppet module, foreman_data_binding
> (https://github.com/domcleal/foreman_data_binding)
>
> This adds a new terminus to the data_binding indirector that just
> queries the URL above.
>
> Going back to the above example, with the "httpd" class imported in
> Foreman, you could define matchers and the hierarchy through the Foreman
> interface and it would automatically get used whenever the httpd class
> was included, whether directly in the ENC or elsewhere.
>
> I don't see that this replaces the ENC, but instead complements it by
> making smart class parameters extend deeper into the Puppet manifests,
> beyond what the ENC interface offers.
>
> Thoughts and comments are welcome.
>
>
Not played with this at all, but I do really like the idea and concept.

··· On Friday, January 18, 2013 11:48:47 AM UTC-6, Dominic Cleal wrote:


Dominic Cleal
Red Hat Engineering

I think that's a really awesome idea, and helps us deal with issues
around class import of complex modules, and so on. Looking forward to
a demo :wink:

I'm not sure it helps with class imports, since the classes still need
to be loaded into Foreman in order to manage parameters and matchers.

Happy to do a demo sometime.

··· On 21/01/13 10:59, Greg Sutcliffe wrote: > I think that's a really awesome idea, and helps us deal with issues > around class import of complex modules, and so on. Looking forward to > a demo ;)


Dominic Cleal
Red Hat Engineering

Sorry, that was badly worded. I mean, when you're nagivating/writing a
several-layers deep module, knowing the user will still be able to
easily bind data to the variables is a big plus. (I'm thinking
specifically about how our puppet::server::* subclasses work here).

··· On 21 January 2013 12:05, Dominic Cleal wrote: > I'm not sure it helps with class imports, since the classes still need > to be loaded into Foreman in order to manage parameters and matchers.