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.
On Wed, May 9, 2012 at 10:33 PM, Joe <Joe.Topjian@cybera.ca> 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.
Hi Ohad,> if you are interested in using foreman, see > http://blog.theforeman.org/2012/01/getting-foreman-search-results-into.html >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.
On May 9, 2:33 pm, Joe <Joe.Topj...@cybera.ca> 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.
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 <Joe.Topjian@cybera.ca> 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.
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.
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.