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
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
Hey Gary, Thanks for that, I read the link, as well as this article
written by you
http://puppetlabs.com/blog/the-problem-with-separating-data-from-puppet-code/
I think I have 2 use cases here. I need mcollective to do ad-hoc
triggering of jobs and some orchestration based on some criteria, like
I just read another article in the mcollective-users group and re-read
what you put, and see how I have this wrong.
Puppet can do everything I need as far as
role = tomcat
tomcat_installed = no
env=dev
designated_app = MyApp1
then install Tomcat
and the apply the config files.
Mcollective
Awesome Gary, Thanks for the reply.
Will this also populate parameters assigned via an ENC (my case would
be the puppet dashboard)?
Thanks again.
On Feb 16, 3:33 pm, Gary Larizza g...@puppetlabs.com wrote:
Hey there,
Check your cron with crontab -l and you'll see a line that calls
Tony,
No. Those don't become custom fact values, so client's aren't aware of
them.
On Thu, Feb 16, 2012 at 3:34 PM, Tony C tonyjch...@gmail.com wrote:
Awesome Gary, Thanks for the reply.
Will this also populate parameters assigned via an ENC (my case would
be the puppet dashboard)?
I see, but following this page does allow for that
http://projects.puppetlabs.com/projects/mcollective-plugins/wiki/FactsFacterYAML
I just tested it. So in my enterprise, i would much rather control the
facts.yaml using a module of the above listed link and a puppet run,
than allowing a cron job
Our cron entry is declared in the pe_mcollective module that we ship in our
modulepath
-- /opt/puppet/share/puppet/modules/pe_mcollective/manifests/metadata.pp
I'll answer this more in-depth when I get a free second to expound on it,
but I'm a bit tied-up at the moment :)
On Thu, Feb 16, 2012 at
No worries Gary. Thanks for your help already. I'm definitely on your
time so just chime in if / when you have a second.
On Feb 16, 4:00 pm, Gary Larizza g...@puppetlabs.com wrote:
Our cron entry is declared in the pe_mcollective module that we ship in our
modulepath
--
On Thu, Feb 16, 2012 at 3:52 PM, Tony C tonyjch...@gmail.com wrote:
I see, but following this page does allow for that
http://projects.puppetlabs.com/projects/mcollective-plugins/wiki/FactsFacterYAML
I just tested it. So in my enterprise, i would much rather control the
facts.yaml using a
Thanks Nan.
I supposed every one's environment is different. For the facts.d, how
does that work exactly?
On Feb 16, 4:31 pm, Nan Liu n...@puppetlabs.com wrote:
On Thu, Feb 16, 2012 at 3:52 PM, Tony C tonyjch...@gmail.com wrote:
I see, but following this page does allow for that
Let me see if I can help on a couple of things:
1.) Facts.dot.d is from this repo --
https://github.com/ripienaar/facter-facts/tree/master/facts-dot-d Check it
out. You can specify YAML, JSON, Shell, or even a single plain text file
where you write 'factname = factval' and they turn into Facter
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
13 matches
Mail list logo
