FAQ
Hello,

I'm trying to figure out the best solution for using facts of other
nodes in manifests.

I understand the use of exported configs and the concat module but, I
think, when using someone's contributed module, unless they wrote the
module using those solutions, I would have to rewrite the module
myself.

Here is the best way I can explain the particular problem I'm running
into. Maybe I'm totally on the wrong path with this.

class my_mysql_server {
class { 'mysql::server': }
# other stuff as needed
# ...
}

node node1.example.com {
class { 'my_mysql_server': }
}

node node2.example.com {
class { 'some::app::db':
db_username => 'foo',
db_password => 'password',
db_host => $my_mysql_server::fqdn,
}
}

In this case, 'some::app' is a contributed module. $db_host in 'db.pp'
simply references a single variable in a template - not a loop and not
using concat.

This does work, but I'm not entirely comfortable with it. For one, if
my_mysql_server is never applied, $fqdn will not be available. This
generally won't happen in the above example, but it's still a concern
I have. Secondly, if I choose to apply my_mysql_server to two nodes,
there would be more than one result for db_host. I'm not exactly sure
how to get around this.

What's the best practice for this type of situation? Should I just
hard-code the fqdn of my_mysql_server and be done with it? Or is there
a more dynamic way to do this?

Thanks,
Joe

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

  • Ohad Levy at May 10, 2012 at 7:14 pm

    On Wed, May 9, 2012 at 10:33 PM, Joe wrote:

    Hello,

    I'm trying to figure out the best solution for using facts of other
    nodes in manifests.

    I understand the use of exported configs and the concat module but, I
    think, when using someone's contributed module, unless they wrote the
    module using those solutions, I would have to rewrite the module
    myself.

    Here is the best way I can explain the particular problem I'm running
    into. Maybe I'm totally on the wrong path with this.

    class my_mysql_server {
    class { 'mysql::server': }
    # other stuff as needed
    # ...
    }

    node node1.example.com {
    class { 'my_mysql_server': }
    }

    node node2.example.com {
    class { 'some::app::db':
    db_username => 'foo',
    db_password => 'password',
    db_host => $my_mysql_server::fqdn,
    }
    }

    In this case, 'some::app' is a contributed module. $db_host in 'db.pp'
    simply references a single variable in a template - not a loop and not
    using concat.

    This does work, but I'm not entirely comfortable with it. For one, if
    my_mysql_server is never applied, $fqdn will not be available. This
    generally won't happen in the above example, but it's still a concern
    I have. Secondly, if I choose to apply my_mysql_server to two nodes,
    there would be more than one result for db_host. I'm not exactly sure
    how to get around this.

    What's the best practice for this type of situation? Should I just
    hard-code the fqdn of my_mysql_server and be done with it? Or is there
    a more dynamic way to do this?
    if you are interested in using foreman, see
    http://blog.theforeman.org/2012/01/getting-foreman-search-results-into.html

    Ohad
    Thanks,
    Joe

    --
    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.
    --
    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.
  • Joe Topjian at May 10, 2012 at 8:03 pm
    Hi Ohad,

    I currently do not use foreman, but this is good incentive to look into it.
    Thank you very much.

    Joe

    --
    Joe Topjian
    Systems Administrator
    Cybera Inc.

    www.cybera.ca

    Cybera is a not-for-profit organization that works to spur and support
    innovation, for the economic benefit of Alberta, through the use
    of cyberinfrastructure.

    --
    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 May 10, 2012 at 9:49 pm

    On May 9, 2:33 pm, Joe wrote:
    Hello,

    I'm trying to figure out the best solution for using facts of other
    nodes in manifests.

    You can use other nodes' exported resources, if there are any, but you
    cannot use other nodes' facts. Multiple nodes can use the same data,
    however, by obtaining them from the same source, be it global
    variables, class variables, or external data (e.g. extdata or hiera).

    I understand the use of exported configs and the concat module but, I
    think, when using someone's contributed module, unless they wrote the
    module using those solutions, I would have to rewrite the module
    myself.

    It depends what you want to do, but needing to modify a third-party
    module for this purpose is not unlikely. Actually, needing to modify
    a third-party module is not so unlikely in general.

    Here is the best way I can explain the particular problem I'm running
    into. Maybe I'm totally on the wrong path with this.

    class my_mysql_server {
    class { 'mysql::server': }
    # other stuff as needed
    # ...

    }

    node node1.example.com {
    class { 'my_mysql_server': }

    }

    node node2.example.com {
    class { 'some::app::db':
    db_username => 'foo',
    db_password => 'password',
    db_host => $my_mysql_server::fqdn,
    }

    }

    In this case, 'some::app' is a contributed module. $db_host in 'db.pp'
    simply references a single variable in a template - not a loop and not
    using concat.

    I don't quite follow that. "References"? Do you mean that class
    some::app::db relies on a template that interpolates the value of the
    db_host parameter?

    This does work, but I'm not entirely comfortable with it. For one, if
    my_mysql_server is never applied, $fqdn will not be available. This
    generally won't happen in the above example, but it's still a concern
    I have.

    On the contrary, in your example you will have that problem all the
    time. It doesn't matter what classes have been applied to other
    nodes. Only classes applied to the same node are accessible to each
    other. For your example to work, therefore, classes 'my_mysql_server'
    and 'some::app::db' would need to be applied to the same node, and
    each would see the other in the form they were applied to that node.
    In that case you don't need to rely on information about other nodes,
    so the question is moot.

    Secondly, if I choose to apply my_mysql_server to two nodes,
    there would be more than one result for db_host. I'm not exactly sure
    how to get around this.

    No. There is only any value at all for $my_mysql_server::fqdn if
    class my_mysql_server has been applied to the node being configured.
    In that case its value is the one value specified for that node.

    What's the best practice for this type of situation? Should I just
    hard-code the fqdn of my_mysql_server and be done with it? Or is there
    a more dynamic way to do this?

    Hard coding it is the quick and dirty way. It's not necessarily
    wrong, but it will make your manifests more difficult to maintain as
    they grow in number and complexity.

    You can instead use an external node classifier to declare your
    classes and their parameters. That does require you to write or
    obtain an ENC, set it up for your configuration, etc. Foreman is one
    possibility there, and the Puppet Dashboard provides another.

    If you're not already using an ENC, however, then I would recommend
    putting the DB server name into an external data store and reading it
    into your manifest via a Puppet function. The built-in extlookup()
    function provides an approach of this sort. Hiera provides a more
    flexible approach of the same kind, and it will be a built-in starting
    with the next major version of Puppet (Telly).


    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.
  • Joe Topjian at May 10, 2012 at 10:45 pm
    Hi John,

    You can use other nodes' exported resources, if there are any, but you
    cannot use other nodes' facts. Multiple nodes can use the same data,
    however, by obtaining them from the same source, be it global
    variables, class variables, or external data (e.g. extdata or hiera).
    Understood.

    I don't quite follow that. "References"? Do you mean that class
    some::app::db relies on a template that interpolates the value of the
    db_host parameter?
    Yes.

    On the contrary, in your example you will have that problem all the
    time. It doesn't matter what classes have been applied to other
    nodes. Only classes applied to the same node are accessible to each
    other. For your example to work, therefore, classes 'my_mysql_server'
    and 'some::app::db' would need to be applied to the same node, and
    each would see the other in the form they were applied to that node.
    In that case you don't need to rely on information about other nodes,
    so the question is moot.
    OK, I understand now. Thank you.

    Hard coding it is the quick and dirty way. It's not necessarily
    wrong, but it will make your manifests more difficult to maintain as
    they grow in number and complexity.

    You can instead use an external node classifier to declare your
    classes and their parameters. That does require you to write or
    obtain an ENC, set it up for your configuration, etc. Foreman is one
    possibility there, and the Puppet Dashboard provides another.

    If you're not already using an ENC, however, then I would recommend
    putting the DB server name into an external data store and reading it
    into your manifest via a Puppet function. The built-in extlookup()
    function provides an approach of this sort. Hiera provides a more
    flexible approach of the same kind, and it will be a built-in starting
    with the next major version of Puppet (Telly).
    Thank you for the options - it's appreciated.

    Joe


    --
    Joe Topjian
    Systems Administrator
    Cybera Inc.

    www.cybera.ca

    Cybera is a not-for-profit organization that works to spur and support
    innovation, for the economic benefit of Alberta, through the use
    of cyberinfrastructure.

    --
    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.
  • Dan Bode at May 10, 2012 at 10:00 pm
    You may want to have a look at this function:

    https://github.com/puppetlabs/puppetlabs-nodesearch

    it doest map exactly to your use case, but the implementation of it is
    close to what the implementation for your solution may look like.

    Its worth noting that once the next generation of storeconfigs comes out
    (which is REALLY soon), it will have better APIs to support these kinds of
    functions and I intend to write puppet functions that support these kinds
    of use cases.
    On Wed, May 9, 2012 at 12:33 PM, Joe wrote:

    Hello,

    I'm trying to figure out the best solution for using facts of other
    nodes in manifests.

    I understand the use of exported configs and the concat module but, I
    think, when using someone's contributed module, unless they wrote the
    module using those solutions, I would have to rewrite the module
    myself.

    Here is the best way I can explain the particular problem I'm running
    into. Maybe I'm totally on the wrong path with this.

    class my_mysql_server {
    class { 'mysql::server': }
    # other stuff as needed
    # ...
    }

    node node1.example.com {
    class { 'my_mysql_server': }
    }

    node node2.example.com {
    class { 'some::app::db':
    db_username => 'foo',
    db_password => 'password',
    db_host => $my_mysql_server::fqdn,
    }
    }

    In this case, 'some::app' is a contributed module. $db_host in 'db.pp'
    simply references a single variable in a template - not a loop and not
    using concat.

    This does work, but I'm not entirely comfortable with it. For one, if
    my_mysql_server is never applied, $fqdn will not be available. This
    generally won't happen in the above example, but it's still a concern
    I have. Secondly, if I choose to apply my_mysql_server to two nodes,
    there would be more than one result for db_host. I'm not exactly sure
    how to get around this.

    What's the best practice for this type of situation? Should I just
    hard-code the fqdn of my_mysql_server and be done with it? Or is there
    a more dynamic way to do this?

    Thanks,
    Joe

    --
    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.
    --
    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.
  • Joe Topjian at May 10, 2012 at 10:47 pm
    Hi Dan,

    You may want to have a look at this function:
    https://github.com/puppetlabs/puppetlabs-nodesearch

    it doest map exactly to your use case, but the implementation of it is
    close to what the implementation for your solution may look like.
    This definitely looks useful. Thank you!

    Its worth noting that once the next generation of storeconfigs comes out
    (which is REALLY soon), it will have better APIs to support these kinds of
    functions and I intend to write puppet functions that support these kinds
    of use cases.
    Good to know - thanks!

    Joe


    --
    Joe Topjian
    Systems Administrator
    Cybera Inc.

    www.cybera.ca

    Cybera is a not-for-profit organization that works to spur and support
    innovation, for the economic benefit of Alberta, through the use
    of cyberinfrastructure.

    --
    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
postedMay 10, '12 at 5:44p
activeMay 10, '12 at 10:47p
posts7
users4
websitepuppetlabs.com

People

Translate

site design / logo © 2022 Grokbase