<div dir="ltr">We have a single default node definition. We have a custom fact that determines the node's role based on it's hostname, then includes a derived class ("include role::${::role}") based off of that information. Since we're using something very similar to Craig Dunn's roles/profiles pattern, and we store all the configuration in hiera, I feel like we're getting most of the benefits of an ENC without having to maintain one. <div><br></div><div>Our hiera hierarchy is pretty gross right now, since it's layered on top of what came with puppet_openstack_builder originally. We don't use puppet environments. Since we have a puppet master per site & environment, we haven't had a need for them yet and I'm afraid of this bug: <a href="http://projects.puppetlabs.com/issues/12173">http://projects.puppetlabs.com/issues/12173</a></div><div><br></div><div>We do have a concept of "echelon" in our hierarchy, which functionally is identical to what most people would call "environment". We looked for a synonym for environment to avoid overloading the term. Right now we have 'prod', 'staging' and 'dev' echelons and we can specify values by role inside of each echelon also.</div><div><br></div><div>We also have a site level in our hierarchy that we can again break out per role, but usually don't.</div><div><br></div><div>Lastly, we have a role level in our hierarchy and a main "common" sort of hierarchy. The role hierarchy is *mostly* used to keep role specific configuration out of the main "common" file since that's pretty large. We do sometimes use it for overriding the common hierarchy.</div><div><br></div><div>As far as versioning, we have two long lived branches, "prod" and "master". Master is managed by Gerrit and we do the normal pre-merge testing that you'd expect. Right now the prod branch is managed more manually. When we want to do a deployment prepare a "proposed" branch that should be able to fast-forward merge on to the prod branch, although we always force a merge commit for documentation purposes. The proposed branch is usually just a snapshot of the master branch at a point in time, but sometimes it's more targeted for specific fixes.</div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Sep 25, 2014 at 7:40 AM, Mathieu Gagné <span dir="ltr"><<a href="mailto:mgagne@iweb.com" target="_blank">mgagne@iweb.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
Some of you use Puppet to manage your OpenStack infrastructure.<br>
<br>
- How do you manage your node definitions?<br>
Do you have an external ENC?<br>
Or plain site.pp, Puppet Enterprise, theforeman, etc. ?<br>
<br>
- How about your configuration?<br>
Do you use Hiera? Or do you rely on the ENC to manage them?<br>
<br>
<br>
My question is related to the complexity that managing multiple OpenStack environments (staging/production), regions and cells involves over time.<br>
<br>
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?<br>
<br>
<br>
To answer my own questions and start the discussion:<br>
<br>
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.<br>
<br>
As for configurations, Hiera is used to organize then with a hierarchy to manage environments and regions specific configurations:<br>
<br>
- "environments/%{::environment}<u></u>/regions/%{::openstack_region}<u></u>/common"<br>
- "environments/%{::environment}<u></u>/common"<br>
- common<br>
<br>
I'm still exploring solutions for cells.<br>
<br>
How about you guys?<span class="HOEnZb"><font color="#888888"><br>
<br>
-- <br>
Mathieu<br>
<br>
______________________________<u></u>_________________<br>
OpenStack-operators mailing list<br>
<a href="mailto:OpenStack-operators@lists.openstack.org" target="_blank">OpenStack-operators@lists.<u></u>openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-operators</a><br>
</font></span></blockquote></div><br></div></div>