On 10/3/14, 3:56 PM, "Mathieu Gagné" <mga...@iweb.com> wrote:
>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. At this point, it’s all the same group, so it just works. We did start using hiera-eyaml a while back, which keeps any of the ‘secrets’ encrypted, so theoretically we could make this repo non-private. But then it’s back to the standard key management problem. > >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. No real integration testing to speak of today. The fact that we don’t use any branches on the hiera repo simplifies it a bit, but it does make it tricky for testing across multiple branches of each repo. > >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. You should check out hiera-eyaml if you haven’t already (https://github.com/TomPoulton/hiera-eyaml ). Doesn’t solve All The Problems, but helps. > > >> 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. =) Just because you can, doesn’t mean you should, right? > >-- >Mathieu _______________________________________________ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
