Tony,

You might want to look at Hiera and doing this INSIDE Puppet instead of MC.
 MC is awesome for orchestration and ad-hoc triggering of jobs, but it
sounds like what YOU want to do is ensure a final state of a machine based
on its role, environment, and site.

Hiera allows you to specify a hierarchy (such as node-specific, then role,
environment, and so on all the way down to a global file that has all your
defaults in it) and return data based on the hierarchy that is pertinent to
your node.  For example, if you wanted to ensure that all App-nodes had
Tomcat, you could have Hiera search through the hierarchy for a 'classes'
parameter and return an array of ALL the classes that were declared in
every level of the hierarchy.  At the app-node level of the hierarchy, you
would have 'tomcat' returned as a value for the 'classes' parameter.  This
would allow you to dynamically classify ALL app-nodes to include the tomcat
class without having to change a bunch of individual node declarations in
Puppet.  It would also let you limit/change behavior based on their
environment, role, and so on.  Does this make sense?

Check out the blog post here -->
http://puppetlabs.com/blog/first-look-installing-and-using-hiera/ and the
repositories at http://github.com/puppetlabs/hiera and
http://github.com/puppetlabs/hiera-puppet



On Fri, Feb 17, 2012 at 10:47 AM, Tony C <[email protected]> wrote:

> Gary and Greg, wow, thanks a whole lot. I've been reading the same
> things you typed, in different posts, but for some reason after
> reading your posts, the light bulb went off and almost everything came
> together for me. How do I use facts.d? I understand what it does, but
> how can I leverage puppet and facter to
>
> Bottom line, it all depends on our requirements. I basically want to
> be able to query Mcollective based on facts, such as env, site, and
> application. The place i work uses weblogic and they build out a brand
> new WLS domain for every application set, so I want to do something
> like (excuse my pseudo code here, not a developer)
>
> if app = MyAppSet1,
>  if site = LA
>    if env=Dev
>      do some action
>
> At first I thought I could use custom facts but shot that idea down
> because of how it distributes to every puppet client. Now that I have
> read about confine, I maybe able to pull off some combination of
> confine and group parameters specified in the Puppet Console?
>
> I'm going to play with this today and see what I come up with. I think
> there are a few different ways of pulling off what I need, and I do
> thank everyone who has put in the time to reply.
>
> - Tony
>
>
> On Feb 16, 7:19 pm, Greg <[email protected]> wrote:
> > As far as I know thats true... One option to limit facts is to use
> > confine to limit where its gets run.
> >
> > For example, here is a fact that is clearly only applicable for
> > Solaris hosts:
> >
> >     Facter.add("obpversion") do
> >         confine :kernel => :sunos
> >         setcode do
> >                 %x{/usr/sbin/prtconf -V}.chomp.split(" ")[1]
> >         end
> >     end
> >
> > Whilst this won't stop it from being downloaded, it will mean that the
> > code will only be run on hosts that meet the requirements.
> >
> > Hope that helps...
> >
> > On Feb 17, 11:23 am, Nan Liu <[email protected]> wrote:
> >
> >
> >
> >
> >
> >
> >
> > > On Thu, Feb 16, 2012 at 3:19 PM, Tony C <[email protected]> wrote:
> > > > I'm not sure if this is the right group or not, but i'll start here.
> >
> > > > I have Puppet enterprise 2.0, playing around with custom facts.
> >
> > > > I have noticed that adding a custom fact to any module will
> distribute
> > > > that fact to all machines, regardless if they are assigned to that
> > > > module or not. Is there a way around this, or is this just by design?
> >
> > > Gary already pointed out the cron job. I'm not aware of an easy way to
> > > perform limited pluginsync, it's either all or nothing. The reason
> > > this is not possible, puppet need facts to compile catalog to know
> > > what modules belong to a node, and puppet can't compile without facts,
> > > so chicken and egg. For example, puppet can't know if it should
> > > pluginsync my_fact if it's in my_module with the following code:
> >
> > > if $my_fact {include my_module}
> >
> > > HTH,
> >
> > > Nan
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> 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.
>
>


-- 

Gary Larizza
Professional Services Engineer
Puppet Labs

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
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.

Reply via email to