[Openstack-operators] Nodes and configurations management in Puppet

Mathieu Gagné mgagne at iweb.com
Fri Oct 3 21:56:59 UTC 2014

On 2014-10-02 11:50 PM, Michael Dorman wrote:
> r10k
> deploys the Puppet environments (Œmaster¹ and Œprod¹ which correspond to
> git branches), heira data, and all the modules.  Hiera data is in a
> separate (private) git repo, but there¹s only a master branch there.

Are people maintaining the manifests/modules able to access the Hiera 
private repository? Should someone wish to introduce a new manifest 
requiring a new Hiera value, how does he make sure it get added to the 
private repository?

How do we make sure someone introducing a new Hiera config asks the 
other people to add it to the private repository.

Are there tests in place combining your manifests/modules and Hiera 
repositories to validate that the catalog compiles correctly?

We do have this test in one of our project and it's kind of cool. But 
manifests, some modules and Hiera are all in the same repository, easing 
its maintenance, tests and deployment.

Our team are struggling to come up with a clever way to handle Hiera 
secrets as not all people contributing to our manifests/modules should 
be able to access them. The challenges are related to tests, packaging 
and distributions. We have yet to come up with ideas, so it's mostly 
exploration and popular consultation for now.

> I¹ve been a big fan of the role/profile model, too, and it¹s worked well
> for us.  One thing I¹ve thought about is specifying a list of profile
> classes for each node or node type in hiera, rather than maintaining a
> mostly static role module.  Then we can just hiera_include(), which is the
> method we use in site.pp to include the role class now.  I¹d be interested
> in others thoughts on this idea.  I can¹t really think of a compelling
> reason to switch, other than it¹s kind of clever.

Unless you face strong limitations with your actual model, I don't see 
any reason to switch to a "pure" role model. =)


More information about the OpenStack-operators mailing list