How do I avoid node level hiera data? How much do you use node hiera data?

asked 2018-05-23 08:48:16 -0500

jpsheffield gravatar image

We've got a fairly normal hiera data hierarchy set up, with a high level "common.yaml" and a low node level "%fqdn.yaml", plus a few levels in between.

What is more unusual is that we have thousands of small applications, and hundreds of development teams moving onto Puppet Enterprise managed infrastructure. They don't really trust it yet.

What they'd like is to be able to specify a time when puppet runs and "changes the server infrastructure" so that it fits into their maintenance windows (eg. run at 3am for server, 4am for server, etc). Our proposed solution is to use a puppet module that takes hiera input and sets up cron on the node to run puppet at the time/schedule required.

Now, we've been told by Puppet engineers to avoid using the node level wherever possible - it's best just to use it for troubleshoot/ PoC activities - which makes sense.

But with a use-case like this I can see that going out the window a bit. Another option is to use a custom fact on the node (to override higher level defaults in hiera) , which would avoid the hiera node data.

I'm not sure what the right question is here, it's one of: - Is this at all sensible? - What is a normal approach / how do you do it? - How much node level hiera data do you have? - Is a large amount of node level actually a big problem? What sort of problems?

As with most of IT I suspect there are a million ways to skin this cat

edit retag flag offensive close merge delete


Rather than change puppet behavior, change the way you deploy puppet code. Why don't you take a more DEVOPS-ish approach and only push your puppet code to the master at 3AM? That way, puppet will continue to ensure your resources are still managed in the 'off hours'.

bschonecker gravatar imagebschonecker ( 2018-05-29 07:19:02 -0500 )edit

In addition, I use node level hiera data all the time to solve 'snowflake' issues. I think Puppet is recommending that you try to eliminate as much snowflake stuff as possible.

bschonecker gravatar imagebschonecker ( 2018-05-29 07:55:00 -0500 )edit

Thanks for the feedback. We are aiming to release the code during a quiet time, however we have global presence so 3AM isn't 3AM everywhere or for all apps unfortunately.

jpsheffield gravatar imagejpsheffield ( 2018-05-29 08:33:37 -0500 )edit

In terms of DevOps'ing this, we can only release the code once to the whole environment, so we're giving teams/developers the ability to choose (in code/params) when it hits their servers. So they can make sure it hits dev/test first for example or in their quiet time, to me this is closer to DevOps

jpsheffield gravatar imagejpsheffield ( 2018-05-29 08:36:04 -0500 )edit