| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Previously the test failed on windows, because we were expecting the
environment config_version to return on POSIX path. But on Windows it is
expanded based on the current drive.
Paired-with: Josh Partlow <joshua.partlow@puppetlabs.com>
|
|
Previous commit blacklisted a small set of settings from having
$environment interpolated. After some discussion, we decided to broaden
this to a whitelist, and the only setting we can currently think of
needing $environment interpolation when using directory environments is
config_version.
We also decided to not halt startup for default_manifest with
$environment in it, as these errors are difficult to read with the
current error reporting from a rack master. So the validation for
default_manifest is removed.
|
|
There are a few settings for which interpolation of $environment does
not make sense when using directory environments.
* default_manifest -> defines either the relative path to manifests
within a directory environment, or an absolute path to manifests to be
used by all directory environments. It is currently a configuration
error to set $environment within default_manifest.
* basemodulepath -> conceptually, this is intended for supplemental
modules required for all environments, and should not vary by
environment.
* environmentpath -> this is the base path defining what directory
environments can be found. Interpolating $environment within it makes no
sense.
Additionally, both environmentpath and basemodulepath are required by
the environment loaders during initialization. They will interpolate
relative to a specified environment if you interogate config, but in a
running master instance, will have interpolated to the default
environment regardless of the current environment being processed for a
catalog, for instance.
A last case, irregardless of type of environment, is the pathological
case of attempting to interpolate $environment within environment.
This, unsurprisingly, causes a stack overflow.
This patch adjusts the Puppet::Settings interpolation code so that
$environment is not interpolated within any of these four settings when
using directory environments (so, when the environmentpath has been
set).* So assuming a confdir=/etc/puppet,
basemodulepath=$confdir/modules/$environment will be interpolated as
'/etc/puppet/modules/$environment' and a warning will be logged.
*Currently setting $environment in default_manifest will error out
when puppet loads as a setting validation error, and this behavior will
never be reached.
|
|
|
|
Add module namespacing to two specs declaring an FS constant (for
convenience) so that we don't receive warnings about the duplicate
declaration.
|
|
Previously the environments/default_manifest_spec.rb was only running
with the current parser. This runs the set of tests for both the future
and current parser cases.
|
|
After discussion with Nick Fagerlund and Henrik Lindberg, changing
restrict_environment_manifest setting to
disable_per_environment_manifest to more clearly reflect what the
setting does.
|
|
This adds integration testing of the new default_manifest and
restrict_environment_manifest settings. It tests all the way from
Puppet initialization from actual puppet.conf files and
environment/manifest files through catalog compilation, simulating
Puppet master activity. Since these settings are purely server-side
constructs, in that they do not impact the agent beyond the contents of
the final catalog the agent receives, I believe this is sufficient to
validate them.
|
