Using catalog inventory/Puppet::Resource::Catalog?

[Nick Cammorato]

I'd like to be able to get a list of all of the classes being applied to my nodes and insert this as a list into mcollective's facts.yaml file.  The reason for this is that I have a couple post-commit hooks that parse out changes to specific modules/classes for changelog purposes and I'm considering adding in a call to mco find to include a list of affected nodes in the report.  Which means the facts need to be there to be found.

Now, puppet stores this in /var/lib/puppet/client_yaml/catalog/${fqdn}.yaml, and I could write it up as a custom fact extremely easily, or I could drop down to ruby and parse it out of the catalog that way, but I'm wondering if there's a built in path of exposure to that information somewhere.  Just a list of all classes in the catalog.  Anyone know offhand?

[R.I.Pienaar]

----- Original Message -----
> From: "Nick Cammorato" <nick_ca...@terc.edu>
> To: puppet...@googlegroups.com
> Sent: Thursday, July 12, 2012 5:35:28 PM
> Subject: [Puppet Users] Using catalog inventory/Puppet::Resource::Catalog?
>
> I'd like to be able to get a list of all of the classes being applied
> to my nodes and insert this as a list into mcollective's facts.yaml
> file. The reason for this is that I have a couple post-commit hooks
> that parse out changes to specific modules/classes for changelog
> purposes and I'm considering adding in a call to mco find to include
> a list of affected nodes in the report. Which means the facts need
> to be there to be found.

mcollective already knows what classes are on a host, you can access it
on the cli:

mco rpc rpcutil inventory -I some.host

[Nick Cammorato]

I'm going to try this again and hope I forgot to hit submit rather than having a message to the list pending for approval.

I want a list of classes contained in the puppet catalog that's been applied to the node, not management classes.  At least in mco 2.0.0 with minimal configuration, an mco inventory some.host or mco rpc rpcutil inventory -I some.host lists facts and mgmt classes.  Now, I'm fairly new to mcollective, so I might be missing something obvious, in which case I'd greatly appreciate being told what :)

What I started with was as an erb template for facts.yaml:
<%
# Gather all of our scope variables
gather_vars = scope.to_hash.reject{ |k,v| k.to_s =~ /(uptime|free|timestamp|id|name|title|rsa|dsa)/ }
# And then all of classes
gather_vars.store('classcatalog', classes.sort.uniq.join(', ')) -%>
<%= gather_vars.to_yaml %>

And boom I can do an mco find --with-fact classcatalog=/corosync/ and it'll list all my nodes which use my corosync modules.

Which appears to work, but I'm a bit leary of this since so much in puppet depends on order of execution and I've seen some odd scoping issues with staging.  So while I have this being populated last, and use an ENC 90% of the time(which populates the management classes), and it all works, it might break in the future.  I was hoping there was another way of exposing this.

[R.I.Pienaar]

I am not following, you do not need to gather this information for
mcollective to be aware of classes.

Puppet creates a file on every node that has a list of all the classes
on said node, on my machines this is in /var/lib/puppet/classes.txt

So I configure mcollective with:

classesfile = /var/lib/puppet/classes.txt

and now I can just do mco find -C /someclass/ and it does what you want
no need to try and turn those into a fact or anything like that.

And if I do 'mco inventory some.node' I get a section displayed like:

Configuration Management Classes:
apache apache::config
apache::install apache::logrotate


Does this method not work for you?

[Nick Cammorato]

Sorry, I should've clarified.  I was hoping to use the management classes for something other than puppet classes(more abstract things like nagios hostgroups, some of which share names with classes).  If I can't reliably populate the facts with class information though, I might not have a choice.

[R.I.Pienaar]

----- Original Message -----
> From: "Nick Cammorato" <nick_ca...@terc.edu>
> To: puppet...@googlegroups.com
> Sent: Saturday, July 14, 2012 5:02:29 PM
> Subject: Re: [Puppet Users] Using catalog inventory/Puppet::Resource::Catalog?
>

> Sorry, I should've clarified. I was hoping to use the management
> classes for something other than puppet classes(more abstract things
> like nagios hostgroups, some of which share names with classes). If
> I can't reliably populate the facts with class information though, I
> might not have a choice.

i could add a feature where instead of just classes.txt it reads a list of files
and search against them all, then you can use puppet classes as well as another
file you manage in some other way

[Nick Cammorato]

That would actually be nice for other reasons, but I think I can whip something up to do that on my own if I need it.  After giving it a bit of thought, I realized this is yet another thing where I can do exactly what I'd like to do but just not quite exactly the way I'd like to do it.  This seems to keep happening to me with anything related to ruby.  I fight the framework for a while, bang my head into walls, then finally accept it and grow to love whatever it was I didn't initially like.

There's no actual need to have puppet classes as facts and other information as management classes when I can just insert what I was going to insert as a management class in as a fact.

IE: What I wanted to do was have a management class monitor that corresponds to a group of nodes residing in the same network/host segment that do different things, a fact class=monitor that corresponds to the puppet nagios servers class, a fact environment=monitor that dictates a puppet environment, and a hostgroups=monitor fact that corresponds to the nagios hostgroup monitor.  Moving the class=monitor fact to the management class doesn't preclude me from adding a security-zone=monitor or a dozen other facts like that for the purposes of ridiculous granularity in categorization and that can be inserted in a number of different ways.  It's just not quite the organizational hierarchy I originally envisioned, but it accomplishes exactly the same thing.

I'm still kind of curious if there's a reliable way to access the class list or full catalog during any point in a puppet run though, because I can think of a few other things that might be useful for(and a few ways to make things spectacularly blow up).  But now that's way more academic.

[R.I.Pienaar]

On 14 Jul 2012, at 18:36, Nick Cammorato <nick_ca...@terc.edu> wrote:

That would actually be nice for other reasons, but I think I can whip something up to do that on my own if I need it.  After giving it a bit of thought, I realized this is yet another thing where I can do exactly what I'd like to do but just not quite exactly the way I'd like to do it.  This seems to keep happening to me with anything related to ruby.  I fight the framework for a while, bang my head into walls, then finally accept it and grow to love whatever it was I didn't initially like.

I think that's quite a general thing though isn't it. Any system is designed with goals and some concept of what is The Right Thing and when you understand those and embrace then suddenly the system works best. 

There's no actual need to have puppet classes as facts and other information as management classes when I can just insert what I was going to insert as a management class in as a fact.

IE: What I wanted to do was have a management class monitor that corresponds to a group of nodes residing in the same network/host segment that do different things, a fact class=monitor that corresponds to the puppet nagios servers class, a fact environment=monitor that dictates a puppet environment, and a hostgroups=monitor fact that corresponds to the nagios hostgroup monitor.  Moving the class=monitor fact to the management class doesn't preclude me from adding a security-zone=monitor or a dozen other facts like that for the purposes of ridiculous granularity in categorization and that can be inserted in a number of different ways.  It's just not quite the organizational hierarchy I originally envisioned, but it accomplishes exactly the same thing.

You could just have a bunch of empty classes that you include on a node as a kind of tag which would probably have the same end result

I'm still kind of curious if there's a reliable way to access the class list or full catalog during any point in a puppet run though, because I can think of a few other things that might be useful for(and a few ways to make things spectacularly blow up).  But now that's way more academic.

I dot think there is a reliable way really no

On Saturday, July 14, 2012 12:33:02 PM UTC-4, R.I. Pienaar wrote:

----- Original Message -----
> From: "Nick Cammorato" <nick_ca...@terc.edu>
> To: puppet...@googlegroups.com
> Sent: Saturday, July 14, 2012 5:02:29 PM
> Subject: Re: [Puppet Users] Using catalog inventory/Puppet::Resource::Catalog?
>
> Sorry, I should've clarified. I was hoping to use the management
> classes for something other than puppet classes(more abstract things
> like nagios hostgroups, some of which share names with classes). If
> I can't reliably populate the facts with class information though, I
> might not have a choice.

i could add a feature where instead of just classes.txt it reads a list of files
and search against them all, then you can use puppet classes as well as another
file you manage in some other way

--
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/-/7E1uLxzFaIsJ.
To post to this group, send email to puppet...@googlegroups.com.
To unsubscribe from this group, send email to puppet-users...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.