FAQ
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.

Search Discussions

  • Felix Frank at Jun 7, 2012 at 9:54 am

    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.
  • Andy Taylor at Jun 7, 2012 at 10:45 am
    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 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.
  • Jcbollinger at Jun 7, 2012 at 2:04 pm

    On Jun 7, 4:30 am, Andy Taylor 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.
  • Andy Taylor at Jun 8, 2012 at 12:53 pm
    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 wrote:
    On Jun 7, 4:30 am, Andy Taylor 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.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppuppet-users @
categoriespuppet
postedJun 7, '12 at 9:30a
activeJun 8, '12 at 12:53p
posts5
users3
websitepuppetlabs.com

People

Translate

site design / logo © 2022 Grokbase