Re: [Openstack-operators] Nodes and configurations management in Puppet
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
Re: [Openstack-operators] Nodes and configurations management in Puppet
Hi Mathieu,
My setup is very similar to yours. Node definitions are in site.pp and
Hiera is used for all configuration. The Hiera hierarchies are also very
similar.
Overall, I have a love/hate relationship with the setup. I could go on in
detail, but it'd be all Puppet-specific rather than OpenStack. I'd be happy
to discuss off-list.
Of if there's enough interest, I can post it here. I just don't want to
muddy up this list with non-OpenStack things.
Thanks,
Joe
On Thu, Sep 25, 2014 at 8:40 AM, Mathieu Gagné mga...@iweb.com wrote:
Hi,
Some of you use Puppet to manage your OpenStack infrastructure.
- How do you manage your node definitions?
Do you have an external ENC?
Or plain site.pp, Puppet Enterprise, theforeman, etc. ?
- How about your configuration?
Do you use Hiera? Or do you rely on the ENC to manage them?
My question is related to the complexity that managing multiple OpenStack
environments (staging/production), regions and cells involves over time.
Is there a magically way to manage node definitions and *especially*
configurations so you guys no have a heart attack each time you have to dig
into them? How about versioning?
To answer my own questions and start the discussion:
I don't use an external ENC. The site.pp manifest has been the one used
since day one. Since we have a strong host naming convention, I didn't see
the limit of this model (yet). Regex has been a good friend so far.
As for configurations, Hiera is used to organize then with a hierarchy to
manage environments and regions specific configurations:
- environments/%{::environment}/regions/%{::openstack_region}/common
- environments/%{::environment}/common
- common
I'm still exploring solutions for cells.
How about you guys?
--
Mathieu
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
