Issue #11900 has been updated by Mike McLane.
Assignee changed from Mike McLane to Kelsey Hightower
This is under Puppet 2.7.9 under CentOS 5.x and CentOS 6.x.
I am trying to keep to a design pattern where a type of module/class designated
as a "service module" do not include configuration values and we use a module
designated as "site modules" to keep specific configuration classes with all of
our special business bits in them. This allows teams throughout the
organization to create, use, and eventually contribute back to the enterprise
class sharing without exposing their data bits and allows each team to continue
with whatever change management cadence they current follow (all of the teams
have disconnected schedules).
Dropping each and every combination/permutation at the service module level
isn't ideal as it really bloats those classes out -- and it makes some
assumptions about the release cycle of each team. We have data/configuration
bits that may be private and shouldn't be shared between teams. We might be
able to do this at a the site module level, but then we collide with release
cycles.
In our multi-team environment it is important that each team can ingest
enterprise-provided classes but also have the ability to over-ride those
classes with updates either at the team-wide path or at their team-product
specific path.
Simple use case example to help explain might be: we have a /etc/motd class at
the enterprise level inclusion path (classname 'motd' version '1.0.0'),
{$confdir/common/modules/enterprise/motd/}.
TeamA updates classname 'motd' to version '1.1.0', and includes it at their
team path, {$confdir/common/modules/teamA/motd/}.
TeamB updates classname 'motd' to version '1.0.1' (bugfix) and includes it at
their team path, {$confdir/common/modules/teamB/motd/}.
TeamB-developer1 creates their own module for development/testing 'motd' and
updates to version '1.2.0' and includes this at their dynamic environment
(team-product-developername) path,
{$confdir/environments/modules/teamA/$environment/motd/}.
In a case where we set up custom facts that still wouldn't satisfy class file
inclusion paths.. which have at least 3 levels (General to Specific):
o Enterprise
o Team
o Team's Product
Unless each environment (team/product) can manipulate the module inclusion path
from within the module, I'm just not sure how that would work. We want to be
able to use multiple environments and we believe the module multiple include
path usage would make that work.
We also would prefer not to having to restart the puppet masters every time a
new environment needs to be added. Dynamic environments (as I understand)
would allow each team to break their own environment, without breaking the
puppet master. There's some risk in doing a puppet master restart in a case
where someone has bad or broken manifests would prevent the puppet master from
being able to start.
It sounds like we may need to go with a hybrid approach where we have a set of
very static environments and inclusion paths, but then also have a single
dynamic environment option that non-defined environments default to.
I'd like to use ENC (via the dashboard), but the community version of dashboard
lacks fairly significant role based access authentication features.
----------------------------------------
Feature #11900: Dynamic environment interpolation in puppet master configuration
https://projects.puppetlabs.com/issues/11900
Author: Mike McLane
Status: Needs More Information
Priority: Normal
Assignee: Kelsey Hightower
Category: server
Target version:
Affected Puppet version: development
Keywords: dynamic environment, puppet master configuration, interopolated
configuration, environment parameter
Branch:
In providing a single Puppet master to multiple teams, where each team has
their own test/release cadence, we maintain that each team would like to
include their own dynamic module path based on the environment passed from the
agent. We have a re-usability case where an enterprise level of common modules
is provided at the lowest path inclusion priority, the local team has a set of
common modules at the next highest level of include priority, and then the
dynamic environment has the highest level of inclusion priority. This allows
for development and testing cases to be carried out through dynamic pulls of
environment-labeled branches in git.
Some form of regex matching of the environment to the configuration section,
might help in this regard.
In such a setup it would be nice to configure a puppet master as:
<pre>
[teama*]
manifest = $confdir/environments/manifests/teamb/$environment/site.pp
modulepath =
$confdir/environments/modules/teamb/$environment/:$confdir/common/modules/teamb/:$confdir/common/modules/enterprise/
[teamb*]
manifest = $confdir/environments/manifests/teama/$environment/site.pp
modulepath =
$confdir/environments/modules/teama/$environment/:$confdir/common/modules/teama/:$confdir/common/modules/enterprise/
</pre>
...or, alternatively.. such a case where the environment passed in is parsed
within the configuration, allowing config-file variables to be set as such:
<pre>
[production]
# passed in $environment = "team-production-product"
$group = $environment.split("-")[0]
# $releasecycle = $environment.split("-")[1]
# $product = $environment.split("-")[2]
manifest = $confdir/environments/manifests/$group/$environment/site.pp
modulepath =
$confdir/environments/modules/$group/$environment/:$confdir/common/modules/$group/:$confdir/common/modules/enterprise/
</pre>
Within the base environments path, I would initialize the directory as a git
repository and keep a post-receive wrapper script to dynamically fetch
environments based on the $environment path.
--
You have received this notification because you have either subscribed to it,
or are involved in it.
To change your notification preferences, please click here:
http://projects.puppetlabs.com/my/account
--
You received this message because you are subscribed to the Google Groups
"Puppet Bugs" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/puppet-bugs?hl=en.
