On Jun 7, 4:30 am, Andy Taylor <andytaylo...@gmail.com> wrote: > Hi, > > 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). John -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. 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.
