Hey Alan, On Fri, May 8, 2009 at 9:11 AM, Trevor Vaughan <peiriann...@gmail.com> wrote: > > Hi, > > I would say that this is a good idea except for the custom fact part. > > Since these are not items that you will 'discover' from the system, a > custom function that looks up items in a table/LDAP server/whatever > would be more appropriate.
I agree with Trevor. It really is about whether or not you are talking about assignment or discovery. If you are discovering intrinsic qualities of a node then a custom fact makes sense. If you are assigning a value to a node or your provisioning tool is assigning that value then a function makes sense. Obviously, there is a gray area here. Alternatively, you could use an external nodes to tool. Currently, LDAP functions as a external nodes terminus, http://reductivelabs.com/trac/puppet/wiki/LDAPNodes. > > This reduces the load on both your clients and your network. Yes, not > by much for only two facts but, once you start down this path, you > will rapidly have a glut of facts that could more easily be discovered > by the server. > > Trevor > > On Wed, May 6, 2009 at 03:26, Greg <greg.b...@gmail.com> wrote: >> >> Alan, >> >> One thing I found handy was to build up 2 custom facts to add into >> facter: defaultroute and site. >> defaultroute is used to determine which site a host is in... >> Personally I found the class heirarchy >> too limited since you can't inherit from multiple places... So you >> would need classes like site1-webserver, >> site2-webserver, site1-database, site2-database and so on... Too >> annoying. >> >> Adding in these custom facts allows you to add in config files based >> on which site the node lives. >> For example: >> >> file { "/etc/resolv.conf": >> source => "puppet:///network/resolv.conf-$site" >> owner => root, group => root, mode => 644 >> } >> >> Heres the custom facts I added. >> (Note: the default route is Solaris specific as I don't need to manage >> any Linux boxes at my site) >> (Also note: My knowledge of Ruby is *really* basic at this stage, >> apologies if this code is bad) >> >> defaultroute.rb: >> Facter.add("defaultroute") do >> setcode do >> defroutefh = File.open("/etc/defaultrouter") >> defroutefh.readline.chomp >> end >> end >> >> site.rb: >> Facter.add("site") do >> setcode do >> case Facter.value('defaultroute') >> when "10.0.0.1" >> "site1" >> when "10.0.0.2", "10.0.0.3" >> "site2" >> else >> "unknown" >> end >> end >> end >> >> Now, this makes the answer to q1 a bit easier... I have mine >> modularised into groups based on what the config is about. Networking >> config is in one module, sudo management in another and so on. That >> way its (hopefully) more sane when you come to make changes. I guess >> the granularity that you put this on is up to you. >> >> 2. I will leave this one to someone more experienced with Puppet than >> me, but I use modules to group similar classes >> together - kind of like a library. Its probably a very simplistic view >> of things, but so far it has worked well for me... >> >> 3. My svn repository is set up as follows: >> >> - baseline/ >> Main trunk - This is where most of the work gets done... Keep >> your live Puppet Master config tree here... >> - tags/ >> Contains discrete release views. >> - branches/ >> Haven't used this yet, but I'm planning on using this for >> larger changes, development work and so forth... >> >> I'm sure I have missed out something that I'm going to need later on, >> but figure its a reasonable starting point... >> > >> > > > > -- Teyo Tyree :: www.reductivelabs.com :: +1.615.275.5066 --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
