[Openstack-operators] Nodes and configurations management in Puppet

Fischer, Matt matthew.fischer at twcable.com
Thu Sep 25 22:54:20 UTC 2014



On 9/25/14 7:40 AM, "Mathieu Gagné" <mgagne at 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. ?

We manage node definitions using hostnames, the role of the node and some
information about geography and echelon (dev, staging, prod, etc) is
encoded within it. The basic data that gets the node booted and installed
is YAML that puppet turns into cobbler config.


>
>- 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?

We version all our config and hiera data with git on multiple branches.

>
>
>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.


We came up with the host naming convention before we brought up a single
node. Custom facter facts parses the hostname into information like role,
region, etc, that then determines the hiera hierarchy. Clayton wrote most
of that code.

Honestly our hiera stack is probably too complex, but we have the ability
to customize almost every level in something like this simplified view of
our stack:

- hostname
- site/role
- role
- site
- echelon/role
- echelon
- twc-common
- common

There's a geography layer in there too that I did not show. For example,
if you had dev and staging in the same physical site they would share NTP
configs but not Keystone configs, so we try to move common stuff down as
low as possible.

>
>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?


I'd be happy to discuss this with you more any time.

>
>--
>Mathieu
>
>_______________________________________________
>OpenStack-operators mailing list
>OpenStack-operators at lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators


This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.



More information about the OpenStack-operators mailing list