Best practice for creating resources out of Hiera?

85 views
Skip to first unread message

John Morton

unread,
Apr 27, 2014, 1:25:18 PM4/27/14
to puppet...@googlegroups.com
I made a module called resource_factory:

https://forge.puppetlabs.com/jaydub/resource_factory

It has two parts. One is the resource_factory class, the other is the defined_resource_factory resource type. They both do the same kind of thing — wrap around create_resources with a hiera look up on some key. The difference is that the class creates defined_resource_factory instances by default, and those instances are where you put the resource types and hiera keys for the stuff you really want to create. Everything's configured in hiera without a lot of site specific classes.

Question is: have I just reinvented the wheel on some existing best practice, and if so, how are the grown ups creating resources out of Hiera?

John

Felix Frank

unread,
Apr 28, 2014, 8:55:30 AM4/28/14
to puppet...@googlegroups.com
Hi,

this is really, really meta (http://xkcd.com/917/).

I'm a little cautious of building something like this:
http://thedailywtf.com/Articles/The_Enterprise_Rules_Engine.aspx

I'd have to play with your module though in order to get a feel about
wether it is rather useful or over the top.

One remark about your README - it's true that the adoption of functions
is not mentioned in the current documentation, but please note that you
can trace past documentations and easily bisect the origin of any
specific feature:

http://docs.puppetlabs.com/references/3.2.2/function.html
http://docs.puppetlabs.com/references/2.7.20/function.html
etc.

Also, git. :-)

Cheers,
Felix

John Morton

unread,
Apr 29, 2014, 4:22:28 PM4/29/14
to puppet...@googlegroups.com


On Monday, 28 April 2014 20:55:30 UTC+12, Felix.Frank wrote:
Hi,

this is really, really meta (http://xkcd.com/917/).

Nevertheless, I nailed it?
 
I'm a little cautious of building something like this:
http://thedailywtf.com/Articles/The_Enterprise_Rules_Engine.aspx

Oh, come on. If you didn't like domain specific languages you'd be avoiding this puppet manifest muck and use Chef, instead. The point of them, and configuration files to some extent, is to achieve greater brevity, safety and maintainability than a general purpose language. They only turn into Enterprise Rules Engines when the result is a verbose, obfuscated, mess.
 
I'd have to play with your module though in order to get a feel about
wether it is rather useful or over the top.

With this, I get to separate resource configuration data from manifest code by writing short, pithy YAML, so I think I'm winning.

And admittedly, I could have called it something like resource_map and made the primary hiera data a simple mapping of resource types to keys, rather than the more recursive and distastefully named solution I've published, but kind of the point is, shouldn't there be an easier way? Baked into the hiera/puppet bindings?

One remark about your README - it's true that the adoption of functions
is not mentioned in the current documentation, but please note that you
can trace past documentations and easily bisect the origin of any
specific feature:

http://docs.puppetlabs.com/references/3.2.2/function.html
http://docs.puppetlabs.com/references/2.7.20/function.html
etc.

Also, git. :-)

Right now, having documentation at all puts me head and shoulders above the long tail of Puppet Forge module authors. Now I guess I could be motivated to go through the last half dozen references and annotate the functions with version introductions, and changes, but only if I believed the pull request would be accepted, and the trend continued.

John

jcbollinger

unread,
Apr 30, 2014, 2:43:29 PM4/30/14
to puppet...@googlegroups.com


I think you've reinvented MS Word.  I mean, it looks slick and featureful, but the old DOS "edit" program was all I needed or wanted for many tasks.  It's not as over-the-top as the Enterprise Rules Engine (but thanks, Felix, for that reference :-)), but create_resources() is not such a central feature of Puppet that dolling it up or wrapping it in additional layers of abstraction is a big benefit for most folks.

The grown ups avoid modeling resources (as such) in their hiera data.  Resources are best modeled in Puppet DSL -- that's what it's for.  External data are better expressed in more raw form; that makes them easier to understand and use.  At times, the natural form of the data lends itself to use with create_resources(), or can easily be made to do.  Occasionally, intentionally structuring external data for use with create_resources() is the best way to approach a problem.  At these times, create_resources() already provides a reasonable interface.

If the module serves you well then great.  Thanks for sharing it, and I hope others find it useful, too.  Personally, though, I have no use whatever for such a thing.


John

Reply all
Reply to author
Forward
0 new messages