Hi all, I didn't get any responses here so wondering if I might get a response second time around. I have colleagues telling me the answer is "these problems are easy if you Ansible or Salt", which strikes me intuitively as BS, but has motivated me to dig again to see how others in the Puppet community have solved these problems.
Best regards, Alex On Monday, March 9, 2015 at 6:19:21 PM UTC+11, Alex Harvey wrote: > > Hi all > > I'm after some feedback on best practices with regards to error handling. > > I have two questions: > > Question #1. Most puppet cloud solutions typically a base class that > configures services common to all nodes like the resolver, Nagios, LDAP, > etc. These classes all depend on the existence of external services to > function (i.e. a DNS server; a DHCP server; a Nagios server; an LDAP > server; and a Logstash system). Without these services, puppet is expected > to fail as it applies the said base class. > > Now imagine there's a role that builds a front end web server that applies > a profile that includes the base class. > > If we try to apply that class in a vagrant environment it fails, unless: > > 1) Our vagrant model environment itself firstly provides a DNS, Nagios, > LDAP server - I imagine no one actually does this because no one would have > a development laptop with sufficient grunt to spin up all these services > simultaneously, and not to mention the time it would take to spin them all > up. > 2) We could set up an external dedicated Puppet development environment > whose only purpose is to support developers testing Puppet code - this will > incur an additional ongoing cost to the project, and create a system that > needs to be maintained probably without resources to actually maintain it. > 3) We could allow vagrant instances to be serviced by an actual > development environment used by the application developers - this creates a > management burden - our PuppetDB, Nagios system; LDAP system etc is going > to be continually polluted with junk data relating to these short-lived > development VMs - this feels quite wrong to me. > 4) We add conditional logic into the Puppet code - "unless I am a vagrant > box, apply the firewall, DNS, DHCP, LDAP & logstash classes" - although I > dislike conditional logic, this is the solution I'm leaning towards. > > Or something else? > > Question #2. How do people normally handle the absence of these > services at the beginning of the project, before any of the above-mentioned > external services even exist? > > We could: > > 1) Just let the code fail if the services aren't available - very ugly. > 2) Comment out services like DNS, Nagios etc in the base class until > they've been built - almost as ugly. > 3) Handle the service failures in the code - trouble is, you can't really > tell Puppet not to, say, apply the Nagios class if Nagios server can't be > contacted. > > Hopefully there's a better way. :) > > TIA, > Alex > -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/a304fe3e-8e80-4574-a896-ecce011f117b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
