[chef-dev] Re: Attribute Validation with chef-attribute-validator


Chronological Thread 
  • From: Daniel DeLeo < >
  • To: Clinton Wolfe < >
  • Cc:
  • Subject: [chef-dev] Re: Attribute Validation with chef-attribute-validator
  • Date: Fri, 15 Nov 2013 09:29:03 -0800


On Tuesday, November 12, 2013 at 9:27 PM, Clinton Wolfe wrote:

Hello all,
At the Chef Community Summit 3 today, I presented a mechanism for defining,
evaluating, and handling validation rules for node attributes.
(snipped) 
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
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?
I think this could be pretty difficult. When cookbook metadata was originally created, only the “depends” field was actually implemented in Chef. Other fields have been used by various applications, in WebUIs and the like. But! Since chef doesn’t use these fields or validate them (and in some cases doesn’t really define what they should contain), in the wild you’ll find all manner of things in there. In a major version bump (Chef 12.0), it’s acceptable to change that, if it’s the best solution. Even so, if there’s a different option that doesn’t break compatibility, I think that would be preferred since we like to get everyone on the new hotness as soon as possible.

Finally, my own inclination is that it’s better to define these things in code. As a major sticking point, there’s no “proc” type in JSON (how could there be?), but that would give you the most sane path to implementing validations that the framework doesn’t support yet. For example, if the framework doesn’t support integer ranges, I can easily write a bit of code to check if a number is in a range (so it’s a valid port number, say). With static data, such a thing wouldn’t be possible.
 

-- Clinton Wolfe


-- 
Daniel DeLeo




Archive powered by MHonArc 2.6.16.

§