puppet/spec/integration/environments, branch master

(PUP-3162) Expand expected config_version

2014-09-10T20:19:19Z

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

(PUP-3162) Switch to a whitelist for $environment interpolation

2014-09-10T00:26:26Z

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.

(PUP-3162) Prevent $environment interpolation in directory environments

2014-09-08T21:27:42Z

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.

(maint) Remove unused constant from default_manifest_spec

2014-09-08T18:33:08Z

(maint) Namespace constant declaration in specs to prevent warnings

2014-09-03T00:01:13Z

Add module namespacing to two specs declaring an FS constant (for convenience) so that we don't receive warnings about the duplicate declaration.

(PUP-3069) Test both future and current parser with default_manifest

2014-08-30T00:11:01Z

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.

(PUP-3069) Change restrict_environment_manifest name

2014-08-29T21:53:36Z

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.

(PUP-3069) Add an integration spec for default_manifest

2014-08-29T18:33:21Z

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.