On May 9, 2:33 pm, Joe <[email protected]> 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 [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
