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

[Steven Danna < >]

> 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.

This is my preference as well.  I'd prefer to define rules either very
close to where attribute defaults are set (in attribute files
typically) or where they are used.  We discussed the Proc-type
validation in the summit meeting and I think it is vital to make this
feature extensible.

On Fri, Nov 15, 2013 at 9:29 AM, Daniel DeLeo 
<
 >
 wrote:
>
> 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
> (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?
>
> 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
>