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.
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:
http://projects.puppetlabs.com/issues/12173
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.
We also have a site level in our hierarchy that we can again break out per
role, but usually don't.
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.
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.
On Thu, Sep 25, 2014 at 7: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
