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 should be used for things like, I want to deploy a new app, use mcollective to shutdown these specific servers, deploy and bring them back up, etc etc etc On Feb 17, 1:13 pm, Tony C <[email protected]> wrote: > 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-pupp... > > 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/andthe > > repositories > > athttp://github.com/puppetlabs/hieraandhttp://github.com/puppetlabs/hie... > > > 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.
