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. =)
-- Mathieu _______________________________________________ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators