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 <greg.b...@gmail.com> 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 <n...@puppetlabs.com> wrote:
>
>
>
>
>
>
>
> > On Thu, Feb 16, 2012 at 3:19 PM, Tony C <tonyjch...@gmail.com> 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 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.
