The right way to create Hiera resources?

363 views
Skip to first unread message

Marc Teale

unread,
Oct 7, 2015, 5:07:29 PM10/7/15
to Puppet Users
Is there a right/approved/standard way to create hiera resources for forge modules that don't do it on their own?  (This is a question about the right way to structure my Puppet code.  I'm not asking how to use hiera_create_resources.)

To create resources from hiera definitions in the past, I've used wrapper classes, the quickshiftn-hiera class (an abandoned fork of hunner-hiera that creates hiera resources without defining them in manifests), and small class I wrote to do the job.  None of them work all that well. 

Let me give you an example of the structuring problem I'm running into:

Say I want to install Elasticsearch.  I go to the forge, I install the module, I include the class in Hiera, and define an instance, like so:

---
classes:
  - 'elasticsearch'
 
elasticsearch::ensure: 'present'
elasticsearch::manage_repo: true
elasticsearch::repo_version: '1.7'
elasticsearch::instance:
  'elasticsearch': {}

 Elasticsearch installs, but no instance is created because the elasticsearch-elasticsearch module doesn't create any hiera resources.  So, what's the right way to create the instance?

Thanks!

jcbollinger

unread,
Oct 8, 2015, 11:31:05 AM10/8/15
to Puppet Users


On Wednesday, October 7, 2015 at 4:07:29 PM UTC-5, Marc Teale wrote:
Is there a right/approved/standard way to create hiera resources for forge modules that don't do it on their own?  (This is a question about the right way to structure my Puppet code.  I'm not asking how to use hiera_create_resources.)


Ok, but it's still not clear what you are asking.  The term "hiera resource" is not meaningful, so I can only guess at what you mean when you ask about creating one.  My first guesses at what it means to "create hiera resource would involve you editing your Hiera data files, however, which is not ordinarily something to which Puppet code structure has any relevance.  So what in the world are you talking about?

 

To create resources from hiera definitions in the past, I've used wrapper classes, the quickshiftn-hiera class (an abandoned fork of hunner-hiera that creates hiera resources without defining them in manifests), and small class I wrote to do the job.  None of them work all that well. 



Are you asking about how to write Puppet code that declares resources with identities and properties drawn from your Hiera data?

 
Let me give you an example of the structuring problem I'm running into:

Say I want to install Elasticsearch.  I go to the forge, I install the module, I include the class in Hiera, and define an instance, like so:

---
classes:
  - 'elasticsearch'
 
elasticsearch::ensure: 'present'
elasticsearch::manage_repo: true
elasticsearch::repo_version: '1.7'
elasticsearch::instance:
  'elasticsearch': {}

 Elasticsearch installs, but no instance is created because the elasticsearch-elasticsearch module doesn't create any hiera resources.  So, what's the right way to create the instance?


It's still not clear what, specifically, you are asking.  Hiera is just a data service.  Site and machine data are very important for using Puppet effectively, and Hiera therefore plays a central role, but in the end it's still just a data service.  You cannot declare resources with Hiera, nor can you declare classes.  The example data you present has no inherent effect at all -- it's just data.

Much of the data is, however, structured in a way that will be meaningful to the catalog builder under certain circumstances.  It also contains data that match up with a common convention by which manifests can use Hiera data to determine which classes to declare.  But these are properties of how the data are used, not of the data themselves.

I guess in the end the question you are posing seems likely to fall into one of two general categories:
  1. How to write Puppet manifest code that can make effective use of Hiera data to declare resources, or
  2. How to write Puppet code that declares resources based on specific data you have already in hand.
Neither of those seems complete, however, inasmuch as one normally needs to design manifests and data together.  Moreover, there is no one approach that is ideal for every circumstance and person.  We can talk about this in the context of a specific example -- maybe elasticsearch -- but that needs to start with your requirements for the resulting configuration of target nodes, and any implementation requirements / preferences you may have.  If you have existing manifest code (even if it's just hiera_include('classes'))  and data to start with then that might be helpful both as a starting point and to further clarify what you're after.


John

Marc Teale

unread,
Oct 14, 2015, 3:33:02 PM10/14/15
to Puppet Users
I'm asking about the latter category.

The problem I'm facing is that Hiera defines a resource, but a lot of forge modules don't create resources from that definition on their own.  (Using elastisearch was a bad example.  After I posted I saw that the module actually does create hiera resources.)

So here's the scenario:
  • I've downloaded the foobar module from the forge.
  • I've defined a foobar::instance in Hiera.
  • The module doesn't create resources from Hiera definitions.
  • The module doesn't have a means to include custom classes within it, so it can't be extended to create the resources without making changes to manifests.  
So I'm asking if there's a best practices method of creating foobar instances from Hiera definitions, be it in another module that does nothing but run create_resources(foobar::instance)modifying the module and then submitting a pull request, or...?

Thanks,
Marc

Ramin K

unread,
Oct 14, 2015, 4:06:54 PM10/14/15
to puppet...@googlegroups.com
On 10/14/15 12:33 PM, Marc Teale wrote:

> So I'm asking if there's a best practices method of creating foobar
> instances from Hiera definitions, be it in another module that does
> nothing but run create_resources(foobar::instance), modifying the module
> and then submitting a pull request, or...?
>
> Thanks,
> Marc

The community answer so far has been to wrap it in a profile class. A
wrapper classes solves the problem of the lookup for creating the
instances and anything else that might need to be done per instance that
is unique to your environment.

I did a talk earlier this year talking about what goes into profile
classes and what problems they solve. Full txt of the talk is also in
the repo.

https://github.com/rkhatibi/sipmug-feb2015/blob/master/Role-Profile-%20What%20goes%20in%20the%20profile%20part.pdf

Ramin

Marc Teale

unread,
Oct 14, 2015, 4:27:05 PM10/14/15
to Puppet Users, ramin...@badapple.net
That's very helpful.  Thank you.

martin...@boomer.digital

unread,
Feb 17, 2017, 1:01:55 PM2/17/17
to Puppet Users, ramin...@badapple.net
Hi Ramin, just wanted to thank you for positing the presentation and the notes - read through them both, and all about organizing puppet code became much clearer! Thanks a lot again!
Reply all
Reply to author
Forward
0 new messages