On Jun 24, 7:53 am, Daniel Maher <dma...@milestonelab.com> wrote: > Hello, > > I would like to know if there is a (sane) way to allow multiple > declarations of the same exported resource to result in only one > instance of that resource being instantiated on a given node.
No. In fact, it is not sane for multiple nodes to export the same resource in the first place. > Allow me to explain : > - Node "infra" includes class "syslog::server". > - Definition "syslog__naglog" allows configuration snippets to be added > to the syslog configuration. > - Many nodes contain class "snmpd". > - Class "snmpd" calls definition "syslog__naglog" as an exported > resource in the form "@@syslog_naglog", thus there are multiple > declarations for this resource across the ecosystem. > - Class "syslog::server" realizes the exported resource in the forst > "Syslog__naglog <<||>>". > > Now this will, predictably, result in a "cannot override local resource" > problem. I could fix this by ensuring that each instantiation has a > unique name (via $fqdn or some such), however, that would result in each > node adding a configuration snippet to the syslog.conf on node "infra", > which is not in fact what I'm looking for. > > I'm looking for a way to say to node "infra" that since class "snmpd" is > out there, somewhere, regardless of how many times, that one (and only > one) configuration line should be added to the local syslog config - and > I'd like to be able to do this from the "snmpd" class. I'm confused here. If all the exports of syslog_naglog are the same, then why do you need to export it at all? There can't be anything node-specific in it (else the exports wouldn't be the same), so any node that wants it should be able to declare it for itself. Alternatively, if the exported resources do have node-specific bits in them, then how do you suppose Puppet would know which one to collect? > I know that I could do it rather simply from class "syslog::server" (for > example), but I'd like it to be dynamic - I'd like other modules to be > able to trigger the addition of a given configuration snippet in the > syslog config of node "infra". Other modules or other nodes? > Can this be done ? Is this realistic ? Is there another approach that > would be better ? I would greatly appreciate any and all commentary. Would it be an issue for node "infra" to have Syslog_naglog when in fact no nodes have class snmpd? If not, then skip all the exported resource stuff and just have infra declare Syslog_naglog locally. If so, then consider what would happen if all the nodes that once had class snmpd were removed from service. Syslog_naglog might no longer be exported (if you clean the storeconfig database), but unless you've been very clever, the corresponding line will remain in infra's syslog configuration, only unmanaged. (How to avoid that is left as an exercise for the reader.) If you're not being clever enough to get rid of the syslog line dynamically in the event that all the snmpd servers go away, then it's silly to struggle over inserting it dynamically only when there are snmpd servers around. There's a point where elegance -- if that's what it is -- must give way to pragmatism. I bet you've already spent more time on the problem than a solution would ever have saved you. 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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
