"russell.fulton" <russell.ful...@gmail.com> writes:
> Firstly thank you Daniel for your response on the scope stuff in templates
> -- I had read that doc and missed it.
No worries - happy to help. As an incidental aside, if you actually continue
the same thread by replying to a previous message my mail client highlights it
for me attention, and I am less likely to skip over it.[1]
> I am still struggling with this and I suspect that there may well be a
> better way of doing what I need so as the subject says I am going back
> to basics. In this post I will try and abstract out what I am trying
> to do and what my assumptions are.
>
> I have monitor machines:
> These have one or more sensors:
> sensors run have one or more interfaces.
> all sensors are clones of a master template
[...]
> Where I am having problems is within the sensor define where I am trying to
> get the value of $rule_categories associated with the parameter $master.
> i.e. I want to qualify the variable $rule_categories dependent on the value
> of the parameter $master $rule_categories = ${$master}::rule_categories to
> use a perlism. I suspect that this is not possible ?? I don't see any way
> of doing that indirection in erb either.
You can, using something ugly like this:
<%= scope.lookupvar("#{master}::rule_categories") %>
OTOH, if you can avoid that I would strongly advise it. That sort of thing is
pretty ugly, and might get broken by side-effect later on because it isn't
really how things are supposed to work. :(
You mentioned that some of your data is automatically generated:
> The master and host files are generated by my management system:
To my eye that sounds like your external database contains the knowledge of
which rules should apply to which sensor, right?
I would probably just skip the entire puppet side for that and use this:
node foo.example.com {
sensor { "sensor001": }
}
define sensor () {
$rules = generate("/usr/local/sbin/get-rules-for ${fqdn} ${name}")
# ...and that emits a single string with the right data.
}
You can use the split function to turn that into a puppet array if you need it
to be, incidentally. (Generate runs on the puppetmaster, not the client, BTW.)
When your master data is stored outside of puppet there is nothing even
remotely wrong with querying that service to get at that data. We do that
for a few bits and pieces, like "what IP *should* this host have".
That also saves you having to model the "master" stuff in puppet at all, which
it sounds to me like you only want so that your actual sensor definitions make
sense.
Using the external, authoritative data source means you don't duplicate that
information, even if it ends up "copied" multiple times in the final
instructions sent down to the client.
Regards,
Daniel
Footnotes:
[1] ...of course, the few days after our central firewall goes "pop" and we
can't source suitable hardware to replace it I don't pay much attention
to anything outside my own offices. ;)
--
✣ Daniel Pittman ✉ dan...@rimspace.net ☎ +61 401 155 707
♽ made with 100 percent post-consumer electrons
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-us...@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.
