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 <[email protected]> wrote: > > > On Saturday, January 30, 2016 at 11:31:36 PM UTC-8, R.I. Pienaar wrote: >> >> >> >> ----- Original Message ----- >> > From: "Corey Osman" <[email protected]> >> > To: "puppet-dev" <[email protected]> >> > 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" <[email protected] <javascript:>> >> >> > To: "puppet-dev" <[email protected] <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 [email protected]. > 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 [email protected]. 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.
