On 14 Jul 2012, at 18:36, Nick Cammorato <nick_cammor...@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_cammor...@terc.edu> > > 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.
