On Jun 7, 4:30 am, Andy Taylor wrote:
I'm currently trying to achieve the following: a program's listen port
changes depending on the presence of another service, specifically
with Varnish and Apache.
So for example, if Varnish is installed on a server, Apache should
listen on 8080. If it isn't, then Apache should listen on 80.
I've found a few ways of doing it, but was wondering if anyone else
had run into anything similar and have found a better solution.
Possible ways so far:
1. Have Varnish/non-Varnish systems separated by environment and have
a conditional in the module which changes the listen port dependent on
the environment of the node;
2. Use the 'defined' function (I've done a fair bit of reading on
this, and it looks like it isn't really recommended due to parse order
issues, and might even be removed in a future Puppet release)
3. Have the Varnish module create a resource of some sort and have the
Apache module check for its existence. But I assume I will run into
parse ordering issues with this, unless I put Varnish in a pre run
stage or similar.
As Felix said, subclassing is another option, provided that (in this
example) it is never the case that Varnish is wanted but Apache isn't,
and also that the Apache class is not parameterized.
Do not do (2) or (3). Both have parse-order issues, and these are not
solved by run stages (nor by any other use of resource relationships)
because stages influence only the order resources are *applied*, not
the order they are *parsed*.
The bottom line is that you need to give all your classes the details
they need about what the node's configuration is supposed to be. That
information is not conveyed reliably by which classes or resources
have already been declared at any particular point. Subclassing
addresses the problem by associating sub- and superclasses. All other
reliable solutions, including your (1), revolve around one form or
another of configuration variable: a global variable, a class variable
of some well-known params class, a piece of external data (e.g. from
hiera), or a class parameter. (I include the last only for
completeness; I rarely recommend class parameterization to anyone.)
Personally, I would give the subclass approach careful consideration,
but if I chose not to go that route then I would rely on an external
hiera data store. I might put a specific flag in the data describing
whether Varnish (for this example) is supposed to be present, or else
I might simply rely on the presence or absence of Varnish data for the
node in question. Overall, however, all of the data-driven approaches
are variations on the theme of your (1).
You received this message because you are subscribed to the Google Groups "Puppet Users" group.
To post to this group, send email to email@example.com.
To unsubscribe from this group, send email to firstname.lastname@example.org.
For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.