More Opsware joys and headaches

The more I work with Opsware, the more I think the tool was just designed with a much different philosophy than my own. To translate – the product isn’t bad, I just don’t agree with it ( I didn’t agree with BMC alot more tho’ ). I’m much more of a hardcore Puppet user than I am anything and while Puppet has it’s problems, I believe in it’s methodology completely and I think that is causing some issues as I try and implement Opsware in a more ‘puppet’-ish way.

For instance, OS installs. Opsware has some OS installation/sequence stuff that’s neat but nothing that we are seriously looking at using ( for many reasons, such as source control of the ks files and more complicated scripting ). Instead, we are trying to implement in such a manner that we can do the following:

* Install minimal OS
* Install Opsware agent
* Remediate policies

Once the opsware agent is installed, the system will automatically be put into some dynamic device groups. These dynamic groups have membership based off certain criteria; they also have software policies attached to them. That way, when a system is placed into a group or meets a certain criteria and automatically becomes a member of a group, it automatically is assigned to certain software policies that need to be remediated. This is really cool and can be extremely helpful for organizing your hosts.

The problem here is that the software policies have subpar methods for checking whether the policy is compliant or not. You can add quite a few items to software policies ( scripts, other policies, packages, app configs ) – but it basically only checks whether a package is installed ( and it doesn’t even do that in a satisfactory manner ). Therefore, you have to take any work that you’ve done via your software policy and then duplicate that work into an Audit that can check and verify that the work stays in place ( or is in fact, needed at all ).

This brings you to the next issue – that once an audit figures out that something is wrong, it can’t fix it by applying the software policy, so once again, you have to duplicate the software policy script into the remediation section of the audit – that or document the audit somehow to inform the operator to fix the issues by remediating a software policy onto the host.

In the Puppet world, this is an example of *one* thing. You have a resource. If you assign that resource to a host, it checks to see if that resource exists. If it doesn’t, it adds it. If someone changes the resource on the host ( not thru Puppet ), then Puppet changes it back. I don’t need to define my resource 3 times – once to install it, once to verify it and once to fix any changes; it’s all taken care of by the one resource.

I’ve heard through the rumor-mill that the new 7.8 release of Opsware SA is supposed to have a much better A&R module for auditing and remediating, so I’m eager to see what changes it brings along. Hopefully, it and I will agree with each other a little better on how things should be done in the world of configuration management.

Till then, I’ll keep on truckin’ on.