Comments inline. On 9 Mar 2015 17:19, "Alex Harvey" <alexharv...@gmail.com> 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.
You are using puppet to manage your cloud instances right? If you use images for your instances (using something like packer and provisioning them with puppet) they will load up pretty quickly. You could set dependencies on the instances each instance requires. So your instances become just another resource. > 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. Um why? Use the same puppet code to manage your dev environments. > 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. See above. I use vagrant for my development environment and it is managed with the same code as my live environment. > 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. :) As I mentioned above. Manage your instances with puppet and set dependencies. I tend to think of everything as a resource these days. Erik Dalén's puppetdbquery module would also be useful. https://forge.puppetlabs.com/dalen/puppetdbquery > > 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/885c44d1-2303-4ce5-8647-f964916b5bb9%40googlegroups.com . > For more options, visit https://groups.google.com/d/optout. -- 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/CAM8R_x8hhBX1OkuzJwQMFsc2MA-9%2B0wjjaTHeQ6Fy3S0ZE2jiA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
