On Wednesday, January 2, 2013 3:51:37 PM UTC, jcbollinger wrote:
>
>
> On Saturday, December 22, 2012 12:20:10 PM UTC-6, Luke Bigum wrote:
>>
>> Hi all,
>>
>> Does anyone know of a way to inspect resources that are already parsed in
>> a node's manifest during catalog compilation? This would certainly need
>> some serious Ruby Fu.
>>
>
>
> This is a bad idea. If your the Puppet circuits in your brain didn't trip
> over "inspect", they certainly should have sounded the alarm over "serious
> Ruby Fu". You are fighting against the tool.
>
>
>>
>> As an example, imagine I have a number of arbitrary files defined by
>> multiple classes and it is impossible to get an all encompassing list of
>> these files:
>>
>> file { 'woof': }
>> file { 'cows': }
>> file { 'meow': }
>> ...
>> $all_files = inline_template(...)
>>
>> I would like to be able to gather those file names into a Puppet variable
>> - this would be parse order dependent. It would be fantastic if it could
>> handle exported resources that have just been collected as well.
>>
>
>
> And "parse-order dependent"? Of course it is. You need a
> Puppet-bogometer.
>
> So what configuration objective are you actually trying to accomplish
> here? There is likely a more robust, less Rubyriffic way to accomplish it.
>
>
Ohh don't worry, John, my bogometer was going off like crazy, the needle
almost broke ;-)
I'm taking shortcuts in my spare time with a tool that's probably 70% right
for the job. It's for monitoring - I really like the idea of a Puppet
module to describe or advertise how to monitor itself, it keeps them very
self contained.
Just a bit more on this - I generally see three categories of monitoring
tools. Ones that are configured separately from your CRM and end up being a
source of truth on their own are in my mind the worst. The next level up
are ones either defined from or derived from your CRM. The best are
auto-discovery, but they cost an absolute fortune. I'm trying to move my
team from the first one to the second one with as little "new tools" as
possible, which is where the "70% right for the job" comment comes from.
I'm using exported resources to describe how modules are monitored. The
problem is that exported resources are not the equivalent of raw
information passing. So when I want to start doing trickier things like
group and analyse what is collected, exported resources don't cut it
because it's not what they are designed for.
Specifically what I was trying to do was collect exported resources of the
same type and group them on the monitoring server. There is no predefined
list of service names anywhere (unless you parse the node definitions) so
that's why I wanted to go from resource collection to Array of Strings. A
colleague has managed to reduce my 300 lines to 50 though so the need for
craziness is reduced somewhat. We still need to do the "Export a File"
trick and run a script on the monitoring server to build the complex
configuration that exported resources are not designed to handle.
The next iteration of this work might be to scrap resource collection in
favour of querying PuppetDB directly to figure out what to monitor, but
that's a lot more work than I'm prepared to do at this stage. Maybe in a
few months... ;-)
-Luke
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/OLpl0Bx1q5kJ.
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.
