Open Stack

On 10/3/14, 3:56 PM, "Mathieu Gagné" <mgagne at 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