Thanks for the advice (again!) John. I'd like to avoid the restrictions that the subclass would cause, so will probably just create a separate environment and change the port based on that. Thanks for distinguishing parsed and applied, was getting a bit mixed up I think.
Andy On Jun 7, 3:04 pm, jcbollinger <john.bollin...@stjude.org> wrote: > 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.
