[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.
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?
--
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.
Re: [Puppet Users] Using catalog inventory/Puppet::Resource::Catalog?
- Original Message - > From: "Nick Cammorato" > To: puppet-users@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 -- 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.
Re: [Puppet Users] Using catalog inventory/Puppet::Resource::Catalog?
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.
On Thursday, July 12, 2012 7:14:16 PM UTC-4, R.I. Pienaar wrote:
>
>
>
> - Original Message -
> > From: "Nick Cammorato"
> > To: puppet-users@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
>
>
--
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/-/5PJdUxXAAaYJ.
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.
Re: [Puppet Users] Using catalog inventory/Puppet::Resource::Catalog?
- Original Message -
> From: "Nick Cammorato"
> To: puppet-users@googlegroups.com
> Sent: Saturday, July 14, 2012 3:04:48 PM
> Subject: Re: [Puppet Users] Using catalog inventory/Puppet::Resource::Catalog?
>
> 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.
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::installapache::logrotate
Does this method not work for you?
--
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.
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.
On Saturday, July 14, 2012 11:36:50 AM UTC-4, R.I. Pienaar wrote:
>
>
>
> - Original Message -
> > From: "Nick Cammorato"
> > To: puppet-users@googlegroups.com
> > Sent: Saturday, July 14, 2012 3:04:48 PM
> > Subject: Re: [Puppet Users] Using catalog
> inventory/Puppet::Resource::Catalog?
> >
> > 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.
>
> 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::installapache::logrotate
>
>
> Does this method not work for you?
>
--
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/-/aTomd-7TN9sJ.
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.
Re: [Puppet Users] Using catalog inventory/Puppet::Resource::Catalog?
- Original Message - > From: "Nick Cammorato" > To: puppet-users@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 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.
Re: [Puppet Users] Using catalog inventory/Puppet::Resource::Catalog?
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. On Saturday, July 14, 2012 12:33:02 PM UTC-4, R.I. Pienaar wrote: > > > > - Original Message - > > From: "Nick Cammorato" > > To: puppet-users@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-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.
Re: [Puppet Users] Using catalog inventory/Puppet::Resource::Catalog?
On 14 Jul 2012, at 18:36, Nick Cammorato 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" > > To: puppet-users@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-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. -- 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.
