[Openstack-operators] Nodes and configurations management in Puppet
mgagne at iweb.com
Fri Oct 3 21:56:59 UTC 2014
On 2014-10-02 11:50 PM, Michael Dorman wrote:
> 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
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