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 facts. The facts-dot-d fact just reads a file, parses it, and returns what it parses as Facter facts. It's cool if you have a central source like a CMDB to scrape for facts, but if you're getting started you might want to start and play with custom facts.
2.) Facts.yaml So, MCollective, using the YAML agent, will read a YAML file for its facts/inventory information. Because running facter every time MCollective is called incurs some cost, reading a flat-file is much faster for a tool like MCollective. That's why we use it. We also want to make sure the facts are reasonably up-to-date for when you do Live Management or MCollective queries, so we run that cron job every 15 minutes. You can disable the job if you want and MAKE it so the facts are only updated according to Puppet runs - that's up to how you want to manage your environment. Yes, that inline_template will also return variables IN SCOPE to the facts.yaml file, but that's something of an 'added bonus' rather than a dependable feature. If you WANT that sort of flexibility, you should look to creating custom facts or doing some sort of external data lookup (by querying the Console's REST API, for example). You could also scrape the MySQL DB backend for that information. It's entirely up to you. There are many options available to you, but I'm not sure what you're ultimately wanting to achieve? Hope that helped a bit :) On Thu, Feb 16, 2012 at 5:40 PM, Tony C <[email protected]> wrote: > 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 <[email protected]> wrote: > > On Thu, Feb 16, 2012 at 3:52 PM, Tony C <[email protected]> wrote: > > > I see, but following this page does allow for that > > > > >http://projects.puppetlabs.com/projects/mcollective-plugins/wiki/Fact. > .. > > > > > 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 to do this. Also, the parameters defined in > > > the ENC really help me carve out my infrastructure nicely for my > > > puppet manifests, as well as the ability to run queries in mcollective > > > using these parameters. A good examle would be a group in the > > > Dashboard called PRODUCTION, with a parameter for site=LA > > > > I can see scenarios where I wouldn't want to dump the entire ENC > > content since there's confidential settings though relevant for that > > system, I don't want to make discoverable through mco inventory. > > > > Since you are using PE, another options you can take advantage of > > facts.d directory, and write out custom facts in key=value format in > > txt file under /etc/puppetlabs/facter/facts.d/ > > > > See the puppet_enterprise_installer.txt for example, and this will be > > a fairly straightforward file resource using a template. > > > > Thanks, > > > > 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.
