Hi Corey, I needed to validate my data against a known set of Hiera and/or ENC data for compliance validation and did it with a function: https://github.com/trevor-vaughan/pupmod-compliance.
I would *love* to see something like this hit the core language, but there are quite a few cases where I have items that can be a Boolean, Number, or String (I'm still not loving needing to convert Numbers to Strings everywhere for consistency) so it gets difficult to use the Puppet 4 inbuilt validators. The linked function certainly doesn't meet everyone's use case, but it fulfills my needs for the moment. Thanks Trevor On Sun, Jan 31, 2016 at 3:37 PM, Corey Osman <co...@logicminds.biz> wrote: > > > On Saturday, January 30, 2016 at 11:31:36 PM UTC-8, R.I. Pienaar wrote: >> >> >> >> ----- Original Message ----- >> > From: "Corey Osman" <co...@logicminds.biz> >> > To: "puppet-dev" <puppe...@googlegroups.com> >> > Sent: Saturday, January 30, 2016 7:47:03 PM >> > Subject: Re: [Puppet-dev] RFC - A specification for module schemas >> >> > On Friday, January 29, 2016 at 10:47:48 PM UTC-8, R.I. Pienaar wrote: >> >> >> >> >> >> >> >> ----- Original Message ----- >> >> > From: "Corey Osman" <co...@logicminds.biz <javascript:>> >> >> > To: "puppet-dev" <puppe...@googlegroups.com <javascript:>> >> >> > Sent: Saturday, January 30, 2016 5:45:05 AM >> >> > Subject: [Puppet-dev] RFC - A specification for module schemas >> >> >> >> > Hi, >> >> > >> >> > I wanted to bring up a conversation in hopes that we as a community >> can >> >> create a >> >> > specification for something I am calling module schemas. Before I >> get >> >> into >> >> > that I want to provide a little background info. >> >> > >> >> > This all started a few years ago when hiera first came out. Data >> >> seperation in >> >> > the form of parameters and auto hiera lookups quickly became the >> norm >> >> and >> >> > reusable modules exploded into what the forge is today . Because of >> the >> >> > popularity of hiera, data validation is now a major problem though. >> >> Without >> >> > good data, excellent modules become useless. >> >> > >> >> > Puppet 4 and stdlib brought many new functions and ways to validate >> >> incoming >> >> > data, and I consider puppet 4 to now be a loosely typed language >> now. >> >> Hell, >> >> > there was even this a long time ago: >> >> > https://github.com/puppetlabs/puppetlabs-kwalify >> >> > <https://github.com/puppetlabs/puppetlabs-kwalify> But puppet only >> >> does so >> >> > much, and while having validation reside in code might make >> >> troubleshooting a >> >> > snap, there is still a delay in the feedback loop when the code is >> >> tightly >> >> > coupled with an external “database” of data. Data that is inserted >> by >> >> non >> >> > puppet developers who don’t know YAML or data structures. >> >> > >> >> > So with that said I want to introduce something new to puppet module >> >> > development, called module schemas. A module schema is a >> specification >> >> that >> >> > details the inner workings of a module. For right now this means a >> >> detailed >> >> > specification of all the parameters for classes and definitions used >> >> inside a >> >> > module who’s goal is to make it impossible to insert a bad data >> >> structure. But >> >> > ideally, we can specify so much more (functions, types, providers, >> >> templates) >> >> > even hiera calls in weird places like templates and functions, which >> are >> >> > usually things that do not get documented and are hard to reference >> and >> >> usually >> >> > requires looking at source code. >> >> > >> >> > What does such a schema look like? >> >> > >> >> > Here is a example schema for the apache module which contains 446 >> >> parameters!. >> >> > >> >> >> https://github.com/logicminds/puppet_module_schemas/blob/master/apache_schema.yaml >> >> >> >> This in general is something I've wanted for a long time, and I think >> >> we're almost >> >> getting for free now in Puppet 4 >> >> >> >> In Puppet 4 you can do: >> >> >> >> class x(String $y) { } >> >> >> >> or >> >> >> >> class x(String $y[1,10]) { } >> >> >> >> or >> >> >> >> class x(Pattern[/\A[a-z].*/]) { } >> >> >> >> or >> >> class x(Enum["stopped", "running"] $y) { } >> >> >> >> and many more including very complex matchers. This is a lot more >> >> featureful AND >> >> maps 1:1 to the capabilities puppet has natively. >> >> >> > >> > This is one drawback of using an external schema parser, puppet has way >> > more useful types to check against. Of course Puppet 3 only has the >> basics >> > (bool, string, array, hash). I have thought about forking the kwalify >> > parser and making more data types so it would be more aware of some >> puppet >> > data types (absolute path, cert_type, ...). I could go down that >> route, >> > but I would probably be the only maintainer. >> > >> > >> > >> > >> >> >> >> I think there are ways now to introspect the classes and extract this >> >> metadata >> >> automagically, if not then I think *that* is the feature we should get >> >> added to >> >> Puppet and from there build the external validation, introspection and >> >> testing >> >> for data as that will give a solution that progresses as Puppet does >> and >> >> give a >> >> lot more "real" results than trying to map this stuff externally to >> what >> >> Puppet >> >> supports >> >> >> >> The puppet lookup or similar CLI can be extended to include >> validation. >> >> >> > >> > While having this built into puppet would be ideal, there are still >> people >> > on 2.7, and many more on 3.x so it might take some time to migrate them >> to >> > 4.3.x. Not to mention almost all forge modules don't include type >> checking >> > in fear that they will discriminate against 3.Xers. (At least thats how >> I >> > feel. Internal private modules are a different story. ) >> > >> > Having a tool external to puppet means that it is version independent. >> You >> > don't have to upgrade to puppet 4.X to get validation. I think this >> alone >> > is a very good use case. I also believe there is room for an internal >> > puppet tool as well which would eventually replace the external tool. >> > Furthermore, having an external schema also means that when you do >> upgrade >> > to puppet 4.x you can map your external schema to puppet data types and >> > update 3.x code to utilize data types with a tool to retrofit those >> > additions automatically. >> > >> >> helping people shoot themselves in the foot by using out of date software >> and >> soon to be unsupported versions of puppet is a mistake. Look to the >> future and >> build for the future. Puppet 4 is VERY VERY different from puppet 3 to >> the point >> of being something entirely new. >> > > I think we have strayed off topic here. Being able to validate hiera > should be something that can easily be done by anyone no matter which > version of puppet they use. The core problem is bad data going into hiera > and then into puppet. The consensus is that we all know this is problem. > While my primary goal was to validate hiera, I think there are other use > cases for having an intermediate serialization format of the module's > interfaces stored in a file or retrieved dynamically with a puppet face. > > To summarize some of the points discussed: > > Building a schema: > - We need a higher level API for gathering module types, parameters, > and default values given a module, file, class or parameter > - Puppet should provide a way to output this information in a > serialized format and pure ruby objects > - format should be pluggable with customizable formats (JSON, > YAML, Module Schema, .hiera data schema, ..) > - should leverage puppet's built in datatypes > - build a hiera data schema based on all the modules in puppet's > modules path specific for each puppet environment > > Validating data > - Given a hiera data schema, hiera should be able to validate its data, > implemented by each backend provider > - hiera data schemas are unique to every user > > Help not force people to use puppet 4 > - Given a module schema, retrofit puppet 3 code with puppet 4 data > types into the module's source code > - swagger like functionality, with the exception that its updating > code > - This helps people move from puppet 3 to puppet 4 > - Folks who cannot move to puppet 4 immediately can get the best of both > worlds with a easier way to migrate to puppet 4 > > Module Schema > - This was never discussed, what should this look like? Schemas are > necessary whether they are statically or dynamically generated. > example: > https://github.com/logicminds/puppet_module_schemas/blob/master/apache_schema.yaml > > > > Corey > > >> >> Maintaining backwards support will simply ensure you rapidly become >> obsolete. >> >> What you're proposing is big and important and the data landscape in >> Puppet has >> and will continue to change quite rapidly, Puppet 3 compatibility will >> just >> mean you end up NOT serving a ever growing user base as people adopt >> Puppet 4. >> >> -- > You received this message because you are subscribed to the Google Groups > "Puppet Developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to puppet-dev+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/puppet-dev/ac864374-172d-470e-ab58-2e315bdae4eb%40googlegroups.com > <https://groups.google.com/d/msgid/puppet-dev/ac864374-172d-470e-ab58-2e315bdae4eb%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 -- This account not approved for unencrypted proprietary information -- -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/CANs%2BFoWaSubN%2BkJ2Yh9uYPM575CicdieyCtzALPcAyAL6p3-9w%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
