On Fri, Jul 1, 2011 at 12:25, Ken Barber <[email protected]> wrote:
> So I've been working on various modules that have very complex data > requirements ... for example the bind zone configuration resource is > fairly complex in that it can have anywhere up to 40 different > attributes: > > http://ftp.isc.org/isc/bind9/cur/9.8/doc/arm/Bv9ARM.ch06.html#zone_statement_grammar > > Some of these attributes also require arrays and hashes to be passed > in puppet so I can easily convert them to bind grammar. > > Now this is all very well and good - but I face the issue of trying to > validate these complex structures. In answer to this I created this > function: > > https://github.com/puppetlabs/puppetlabs-functions/blob/master/lib/puppet/parser/functions/kwalify.rb > > Which allows validation using kwalify: > > http://www.kuwata-lab.com/kwalify/ruby/users-guide.01.html#schema > > This function monopolizes kwalify schema validation techniques - so I > can use Puppet hashes and arrays to create kwalify schemas to validate > my resource input. Some examples: > > https://github.com/puppetlabs/puppetlabs-functions/blob/master/examples/kwalify-1.pp > https://github.com/puppetlabs/puppetlabs-functions/blob/master/examples/kwalify-2.pp > > This is great in that I can now combine my validation into 1 data > structure and use that to validate ... > > Now this in of itself is interesting but I started to think about the > wider case. What if I wanted to validate _every_ parameter in a class > or resource? > > So I created this: > > https://github.com/puppetlabs/puppetlabs-functions/blob/master/lib/puppet/parser/functions/validate_resource.rb > > This converts all the params in a class or resource into a hash, and > goes looking for a separate schema file to use as validation. The idea > being, I can define a module_name/manifests/init.pp file with a class > in it, and a corresponding module_name/manifests/init.schema file for > its complex validation. This way you can create classes in the normal > layout structure, and have each class have a corresponding schema > file. > > Some examples: > > https://github.com/puppetlabs/puppetlabs-functions/blob/master/examples/validate_resource-1.pp > https://github.com/puppetlabs/puppetlabs-functions/blob/master/examples/validate_resource-1.schema > > https://github.com/puppetlabs/puppetlabs-functions/blob/master/examples/validate_resource-2.pp > https://github.com/puppetlabs/puppetlabs-functions/blob/master/examples/validate_resource-2.schema > > So now - I can allow complex structures to be passed, and have > validation in kwalify do most of the heavy lifting for validation ... > but also ... if someone was keen - they could use the kwalify schema > files - dynamically create a form in an ENC tool for parameterized > classes data entry purposes. > > So the obvious debate to be made is weither this kind of complex > validation lives in the language or not ... but I do generally feel > that the current language support doesn't go deep enough to express > the data needed by a class and/or an ENC tool - kwalify comes a little > closer even if it isn't the correct implementation it certainly is > closer to the kind of information that needs to be expressed. > > Anyway ... just want to put these ideas out there and see what people think. I think you nailed the point of complexity there: our current language support doesn't do what we need, and kwalify is probably the best choice for a validation language right now. My major concern around this is that separate schema and class make it hard for folks to keep them in sync; I know when I was doing Win32 development and we needed to maintain a separate "export" file next to our code, the most common failure was to forget to update that. I would ideally like to see this integrated as part of typing in the language, so you would express constraints when you declare the parameters to your class or define. That would give the assurance that both were always consistent, and have only one place to view the data. I can't honestly say if I like this as an interim step on the way: it gives us the capability now, and cheaply, which is pretty darn awesome. We would really benefit from some uniform way to do this, and it would let us test kwalify in the real world. OTOH, it also means that we should support it to some degree as time goes on. I would hate to let folks use it, then give them the short stick when it comes to moving to whatever final mode we use. On the gripping hand, it could be that language integration first would show us this is not the right approach (though I can't imagine how) and all... So, yeah. Definitely not the wrong approach, and a good choice of tools and an excellent balance of prototype cost vs results. I think I will defer any final answer over to our UX master, Randall, about the best way to try integrating this. Technically, though, it looks pretty sound. Daniel I nearly said "kwalify is the least worst choice", because aside from Rx (http://rx.codesimply.com/) it is one of the few validation languages that was both complete enough and simple enough to use. It still felt painful to use, though, in the real world. -- ⎋ Puppet Labs Developer – http://puppetlabs.com ♲ Made with 100 percent post-consumer electrons -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en.
