At the Chef Community Summit 3 today, I presented a mechanism for defining,
evaluating, and handling validation rules for node attributes. It’s packaged
as a rubygem (http://github.com/clintoncwolfe/chef-attribute-validator) which
implements the rules engine, and a thin cookbook
(http://github.com/clintoncwolfe/attribute-validator) which installs the gem
and then runs the validation at either compile-time or convergence time,
depending what the user places in their runlist. The gem may also be used
directly, either from recipes or from CI tooling, etc.
Rules are defined as attributes themselves, so it’s easy for an
implementation cookbook to define validation rules right alongside the defaults
for the attributes. Rules use wildcarded paths (using shell glob wildcards) to
select attributes, and have a number of checks to select from (type, regex,
The code is fairly young but well-tested; there are some missing features,
but it’s useful now. I’d welcome any feedback/suggestions, here or as github
issues. And collaborators welcome :).
There was also some discussion about incorporating the functionality into
chef core. I’d generally welcome that, though I think we should allow the
gem/cookbook approach to mature a bit to see how the functionality evolves.
One particular suggestion was to examine the (rule-defining) cookbook’s
metadata.rb, and look at the ‘attribute’ DSL. In discussion, the consensus
seemed to be that the attribute DSL was intended to define validation rules,
but nothing was enforcing them. To me, reading the metadata DSL docs
(http://docs.opscode.com/config_rb_metadata.html), the actual intent wasn’t
clear; it seemed like the attribute properties might actually be intended to
generate a UI to set attributes.
So: should the chef-attribute-validator gem try to read rules from
metadata.rb (in addition to, or instead of, reading the rules from attributes)?
If the metadata.rb is the authoritative source of validation rules, should it
be extended to somehow allow wildcarding?
– Clinton Wolfe