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 role, env and site. I also want my puppet manifests to control the state of a machine, after this orchestration based on the criteria used to trigger and ad-hoc job, just as you stated. For example, for mcollective role = tomcat tomcat_installed = no env=dev designated_app = MyApp1 then install Tomcat After the installation, I would want puppet to run, and if those same criteria matches the logic in my puppet manifest, deploy the proper config files needed to power that tomcat, in that site, for that particular application. So I think it comes down to, where do I put the source of truth. If hiera uses yaml in the backend, can I use Hiera's yaml file to power / etc/puppetlabs/mcollective/facts.yaml? I really like the Puppet Console. Easy to setup, easy to use. I think I understand how Hiera works. When doing a search, it will basically look down the chain and return values that will match whatever you asked for, even if that value is not in the immediate "level" you are searching against. My apologies if I am all over the place. Just really amped to getting this thing off the ground. I feel like I'm right there, I just need to make a decision. On Feb 17, 12:19 pm, Gary Larizza <[email protected]> wrote: > 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 > athttp://github.com/puppetlabs/hieraandhttp://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.
