On Thursday, January 17, 2013 7:05:59 AM UTC-6, Michael Dodwell wrote:
>
>
> Ok so for an example I have a module/class that enables apache vhost
> setup. In this example I have X web servers that are load balanced and i
> want to add all my Y virtual hosts, so working backwards I would want to
> create a group called 'web_vhosts', for example, and add to that Y class
> calls to the same apache vhost creation class but with different variables
> ie servername => "somehost.com"
>
> Or as a more syntax correct manifest:
>
>
> node somenode {
>
> include apache
>
> apache::vhost {
>
>
> "my-site":
> servername => "my-site.com",
> port => 80,
> docroot => "/opt/mysite";
>
> "other-site":
> servername => "other-site.com",
> port => 80,
>
> docroot => "/opt/othersite";
>
> # ETC ETC
>
>
> }
> }
>
I repeat: do not confuse declaring the same class multiple times with
declaring multiple resources of the same defined type. Based on the syntax,
the "apache::vhost" in your example can only be a defined type, not a
class. ENCs cannot directly declare defined type instances (or native type
instances); they can only declare classes and top-level variables. On the
other hand, if "apache::vhost" *were* a class, then it would be invalid to
declare it multiple times with different parameters. Re-read my earlier
comments and the Puppet language documentation until you understand these
things.
You can create a class to declare the appropriate vhost instances -- say
site::vhosts -- but as a class, it can only be declared with any explicit
parameters once, whether by your ENC or in a manifest somewhere. For such
a class to serve your needs, therefore, it must declare *all* vhosts needed
by the target node in one go.
If you want a single site::vhosts class that declares the correct vhosts
for every relevant server, where those vary from server to server, then
you're looking for a data-driven approach. There are a number of
variations on that, but they all involve these pieces:
- A data store / access function. A good and common choice here would
be a YAML-based data store accessed via hiera. You could also use one or
more Puppet class variables, accessed directly. Or you could use virtual
resources as your data, and the realize function or collection operator as
your accessor. There are other possibilities.
- Rules for selecting which data to use. That could come from a vhost
list stored alongside the vhost data or in a global variable or class
parameter, or it could be coded into a class. There are probably other
options for this part, too.
Depending on what you choose for those pieces you also have a selection of
mechanisms for connecting them together to create the class you want. The
choices for that depend on your choices for the other pieces, however.
John
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/Rk0rCBI1g8gJ.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
