Creating a Puppet Master

Puppet for vSphere Admins

Over the last four weeks, we looked at Auto Deploy, which is automation for our VMhost provisioning process. Next up, we’re going to look at Puppet, a tool to automate our VM and Guest OS provisioning.

Recently, I have been working on deploying Puppet by Puppet Labs in our work environment. Puppet is a provisioning and configuration management system. It has been made famous by its ability to simplify cloud management for those running at scale, such as the Obama for America campaign that leveraged AWS and Puppet. Manually provisioning and configuring nodes scales linearly, or worse – 5,000 nodes requires at least 1,000 times the resources as 5 nodes. Automation with a tool like Puppet scales much more gracefully. Managing 5,000 nodes is only incrementally more difficult than managing 5, and growing to 50,000 or shrinking to 500 is just as easy. There are a number of other similar products you might be interested in – Chef, Ansible, and Salt to name a few.

I am interested in Puppet for two primary reasons. First, it has a lot of mindshare and a friendly community. You can easily find numerous blogs addressing common problems, there’s an active irc channel for problems you can’t solve with the help of a search engine, there’s a gigantic public module repository (called Puppet Forge), and you’ll find many candidates who already know Puppet as you grow your team. Second, VMware has invested $30M in Puppet Labs. The increased interaction and development has already resulted in Puppet adding some VMware cloud provisioning features and should ensure those features mature. This should help round out their Software Defined DataCenter (SDDC) efforts.

Continue reading

Adding custom resolution values to MantisBT

Recently, one of our MantisBT users asked us for a custom resolution value. The MantisBT admin guide . In the last paragraph of the suggests this is possible, but doesn’t tell you how. The closest we get is a description on implementing custom status values, plus some questionable google results that require some interpretation. I’ve done the interpretation for you, so you don’t have to. There are two existing variables in the MantisBT code that define the default status values, $g_resolution_enum_string and $s_resolution_enum_string. I’ve shortened the output to just the lines we care about:

[rnelson0@mantis ~]$ grep -R resolution_enum_string /srv/www/mantis/config_defaults_inc.php /srv/www/mantis/lang/*english*
/srv/www/mantis/config_defaults_inc.php:        $g_resolution_enum_string                       = '10:open,20:fixed,30:reopened,40:unable to duplicate,50:not fixable,60:duplicate,70:not a bug,80:suspended,90:wont fix';
/srv/www/mantis/lang/strings_english.txt:$s_resolution_enum_string = '10:open,20:fixed,30:reopened,40:unable to reproduce,50:not fixable,60:duplicate,70:no change required,80:suspended,90:won\'t fix';

You may notice a slight difference – the global var says “unable to duplicate” and the other var says “unable to reproduce”. Without any modifications, “unable to reproduce” is seen by users so we’ll take the value of $s_resolution_enum_string and use it for both.

Continue reading