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. Thanks :) -- 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On 06/07/2012 11:30 AM, Andy Taylor wrote:> 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;What do you mean by "environment"? I think this should be a hiera based approach, which would seem all right to me.> 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)Exactly. Don''t do this.> 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 long as your dependencies are simple, you can do a subclass based approach. Say your apache port is defined inside the apache::config class, you could devise something like this: class apache::config::alt_port($port) inherits apache::config { # override the contents of ports config file File["/etc/apache2/ports.conf"] { content => ... } } Then the varnish module includes this subclass class { "apache::config::alt_port": port => "8080" } Note that this will get you in trouble as soon as two separate instances want to fiddle with apache''s port. A hiera based approach will most likely allow you to keep things much cleaner. Cheers, Felix -- 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Thanks for your reply Fenix. By environment I meant Puppet
environment, so for example, I''d have production and development.
Production contains Varnish, Development is always non-Varnish. I then
have a selector in the apache module which, depending on the
environment, grabs a Hiera value, so something like:
$apachelisten = $::environment ? {
''production'' => $apache::params::prod_listen,
''development'' => $apache::params::dev_listen,
}
Then in params.pp:
class apache::params {
$prod_listen = hiera(''apache_prod_listen'')
etc.
or do you think there is a better way of doing this with Hiera?
On Jun 7, 10:54 am, Felix Frank <felix.fr...@alumni.tu-berlin.de>
wrote:> On 06/07/2012 11:30 AM, Andy Taylor wrote:
>
> > 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;
>
> What do you mean by "environment"? I think this should be a hiera
based
> approach, which would seem all right to me.
>
> > 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)
>
> Exactly. Don''t do this.
>
> > 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 long as your dependencies are simple, you can do a subclass based
> approach. Say your apache port is defined inside the apache::config
> class, you could devise something like this:
>
> class apache::config::alt_port($port) inherits apache::config {
> # override the contents of ports config file
> File["/etc/apache2/ports.conf"] { content => ... }
>
> }
>
> Then the varnish module includes this subclass
>
> class { "apache::config::alt_port": port => "8080" }
>
> Note that this will get you in trouble as soon as two separate instances
> want to fiddle with apache''s port.
> A hiera based approach will most likely allow you to keep things much
> cleaner.
>
> Cheers,
> Felix
--
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.