| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
A catalog used to have the symbolic name if it's environment set, but
did not retain a reference to the actual environment instance. This
could would likely allow the catalog to reference it's original
environment for a legacy, memoized environment, but does not work with
newer cacheing models for directory environments. The problem was
showing up specifically in the
spec/integration/parser/ruby_manifest_spec which would compile a catalog
and then interrogate the catalog to see if it contained the expected
resources. Resources have unfortunate behavior causing them to lookup
environment in order to load types in support of the
Resource#parse_title. But the current_environment retrieved by the
resource in the spec was likely different than the one overridden during
compilation, and if it had never performed an initial import, might fail
attempting to lookup classes which were not on its path.
To short circuit some of this madness, the compiler is explicitly
setting a new Catalog#environment_instance, and Catalog#to_catalog is
ensuring that it copies when duplicating. Catalog#resource then
overrides current_environment to this instance.
|
|
resources
Without this patch, file resources will always try to checksum
themselves using MD5. On FIPS 140-2 compliant hosts, this will
fail. This patch adds sha256 as a permissible value for the File
resource's checksum parameter, and makes the checksum parameter
default to using the digest_algorithm, as set in the puppet.conf.
|
|
Using the have_resource matcher makes the tests a little shorter and
more expressive. It also uses the common way of matching so that we can
get better error reporting.
It turns out that one of the tests was matching against the incorrect
class name, so that is now fixed.
This also extracts a be_resource matcher so that you can match against
an individual resource independent of a catalog.
|
|
The tests used various ways to contruct the catalog. However, putting
together a catalog isn't always as simple as just calling compile.
compile_to_catalog puts all of the steps together in a way that is easy
to use in the tests.
|
|
When defaults were set using future evaluator and the resource has
a qualified name, the registration of the default was not recognized
because scope requires every segment of a qualified name to be upper
cased.
This adds upper casing of every segment. An integration test checks
that the capitalization works.
|
|
* upstream/stable:
(PUP-2158) Unlist configured environment
(PUP-2158) Test dynamic environments with an empty environmentpath
(PUP-2158) Fix integration apply application spec
(PUP-2129) Fix issues with false interpolation start (no-such-method)
(PUP-2158) Report 404 for missing environment
(PUP-2158) Default a missing manifest to no_manifest
(PUP-2158) Hide dir envs behind a feature flag
Conflicts:
lib/puppet/node/environment.rb
spec/unit/environments_spec.rb
|
|
With the environmentpath defaulting to an empty string, we were
attempting to create a '/production' environment directory in the spec
and failing because of permission issues. Setting environmentpath to a
temp directory before hand now, which was it what was being done in the
test_helper.rb previously.
|
|
The tests were often creating environments that didn't need to have
manifests. Since we didn't have a way of specifying that when they
were written, we used '' to fill in the blank. This actually caused a
large number of tests to try to find code to load in the PWD, which
caused tests to break if a developer had parse errors in manifests being
used for testing in the root directory of their puppet project. This
changes the manifest to be optional and removes '' from those tests. The
tests no longer fail if a bad manifest is in the PWD :D
|
|
In too many cases, having the directory environments enabled by default
caused many user's dynamic environments to be detected as directory
environments. This caused broken environments, sometimes in very subtle
ways.
This changes it so that directory environments are not enabled by
default, but can be turned on. It does this by defaulting the
environmentpath to the empty string, and using the empty string to
denote disabled directory environments. When directory environments are
enabled, legacy environments are disabled, and vice versa.
|
|
The problem was that nil was not transformed to undef for the result
of a parameter default expression and nil was interpreted as value
missing by the 3x class/define logic.
This adds a transformation in the PopsBridge by introducing a new kind
of bridging expression. Likewise, a transformation was needed back again
to nil as the value was set in TypeCalculator when performing an
inference and symbol :undef can not be used where a String is expected.
It was also observed in PUP-1964 that the error that surfaced lacked
location information. This was caused by the transformation of
unparenthesized call, where the transformed call expression did not
get location information set.
Tests added for the two different problems.
The factory method for recording position now also checks if the
end_locateable is void of location information (which can happen
in some transformations).
|
|
With Access Control Entries (ACEs) on Windows, we currently use AddAccessDeniedAce
which does not include inheritance and propagation, but AddAccessDeniedAceEx does.
We are already using AddAccessAllowedAceEx when setting access allowed ACEs and
we should use the same behavior for denied ACEs. This commit provides that ability.
Without this commit we will not be able to properly manage access denied
ACEs with inheritance to child objects.
|
|
(PUP-1587) crontab: make sure that invalid crontabs aren't written out
(PUP-1586) remove obsolete unit test
(PUP-1586) allow managing existing cronjobs without caring for command
Signed-off-by: Charlie Sharpsteen <Charlie Sharpsteen chuck@puppetlabs.com>
|
|
|
|
Periodically this test would fail with a message about some path being a
directory. It turns out that what was happening was that that generated
name for the temp directory would end in "one" or "two". This caused the
test to detect the directory entry in the response from the search
request to be one of the files and so it would try to read the contents,
which wasn't possible because it was the directory.
This changes it to check for the files by the full path and use
"include_in_any_order" to pull together two tests into one.
|
|
The change in PUP-1220 (turning off access to dynamic scope)
accidentally also turned off access to inherited scope.
This is a big problem because it blocks the most used pattern of getting
parameters into classes in modules (and then accessing them in
templates).
|
|
The change in PUP-1220 (turning off access to dynamic scope)
accidentally also turned off access to inherited scope.
This is a big problem because it blocks the most used pattern of getting
parameters into classes in modules (and then accessing them in
templates).
|
|
ffrank/ticket/master/PUP-1585-cron-duplication-with-target
(PUP-1585) and (PUP-1624) cron: handle the user and target properties better
|
|
When a --modulepath option is supplied from the CLI to override the node
environment's modulepath, it can be made up of multiple directories with a
path separator. The path is now split so multiple paths are correctly
searched.
|
|
ffrank/ticket/master/22800-dynamic-lookup-in-templates
(PUP-1220) apply proper scoping rules to scope#to_hash
|
|
jpartlow/issue/master/pup-1765-puppet-apply-ignores-cmdline-modulepath
(PUP-1765) Directory env respects cmdline modulepath and manifest
|
|
The addition of directory environments in PUP-1118 caused a regression
in the behavior of --modulepath and --manifest set from the commandline.
Three cases are seen:
1) given a '$confdir/environments/production' directory,
`puppet apply -e 'include "modclass"' --modulepath /some/other/modpath`
fails to find the modclass from /some/other/modpath. The same problem
is seen if a specific directory environment such as '--environment
direnv' is set (assuming that direnv exists).
2) given a '$confdir/environments/production' directory,
`puppet module install foo --modulepath /some/other/modpath`
installs to '$confdir/environments/production'. If a specific directory
environments such as '--environment direnv' is set, then it incorrectly
installs to "$confdir/environments/direnv'.
3) given a '$confdir/environments/production' directory,
`puppet master --manifest /some/other.pp`
does not execute '/some/other.pp' when an agent calls in without
specifying an environment.
To fix these cases we are now explicitly overriding the configured
environment with the stored :cli modulepath and/or manifest setting,
both at application run time and when handling a v1 http api call.
|
|
The regression fix for #19876 caused yet another regression in cron
resources that manage the target property, but not the user property.
The earlier fix made sure that a cron resource would not try and manage
a matching record from another user's crontab. It did so by comparing
the record's target to the resource's user property.
When the user is unmanaged, but the target is specified instead, this
would cause puppet to ignore the record on disk and add it once more.
This is fixed by comparing the record's target to either the user
property or the target property. If there is a should-value for the
user, it is used, otherwise the provider falls back to the target
should-value.
|
|
'adrienthebo-issue/master/pup-542-deep_freeze_arrays_numerics_booleans'
* adrienthebo-issue/master/pup-542-deep_freeze_arrays_numerics_booleans:
(PUP-542) Test the gamut of mutation
(maint) Detect reparse when :code changes
(maint) Allow arrays, bools, and numerics to be frozen
|
|
There are a lot of ways that the facts hash could be mutated. This
checks that none of those ways can happen.
|
|
The last segment of a qualified variable name is allowed to start
with an underscore. Previously this was only allowed for a single
segment.
|
|
|
|
When opting in with trusted_node_data or immutable_node_data the facts
are also available via $facts, an immutable hash of data.
|
|
It is permissible to manage cron entries and not manage the command
property. However, if the entry doesn't exist on the target system yet,
puppet should not try to create it.
In other words, a cron resource without a should value for the command
property can only be synced to a valid state if the corresponding resource
on the target system has a valid command value already.
cron { "foo": minute => 1 }
is alright with an existing crontab of
# Puppet Name: foo
* * * * * /some/command
but not with a crontab not yet containing the entry named 'foo'.
This change prevents the sync operation in the error scenario.
|
|
During a Puppet[:setting] call, legacy environment settings would be
loaded from a puppet.conf stanza. But settings from directory
environments would never be seen. Areas in the codebase could obtain
per environment settings by looking them up directly from an
environment. However a call to puppet config or to an application with
--configprint, would return the default modulepath if redirected to a
directory environment using the --environment setting.
A ValuesFromCurrentEnvironment class has been added to Settings to
lookup environment settings not found in puppet.conf if there is a match
with the :current_environment from the Context.
Because of the need to access a global modulepath for environment and
directory loader construction, a setting, :basemodulepath, has been
added, so that we can initialize without fear of recursing infinitely
looking up :modulepath.
The possibility for recursion has been there since at least 3.0.0:
[legacy]
modulepath=/foo:$modulepath
would overflow the stack. It could now be:
[legacy]
modulepath=/foo:$basemodulepath
|
|
- An issue was discovered where the values returned from
Puppet::FileSystem.stat and Puppet::Util::Windows::Security.get_mode
were not aligning as they should. The call to get_mode returns
a mode value that should more correctly express a simulated POSIX
mode on Windows
- The stat instance returned from Ruby has been further monkey-patched
on Windows to add an appropriate mode value using the existing
lower-level code that reads a files security descriptor.
- Some tests that were performing special handling of mode values were
updated now that mode should be more consistent across platforms.
- In some cases, an existing call to File.chmod was changed to call
set_mode under Windows. In the future, our FileSystem abstraction
should be modified to create an OS-agnostic single point of entry
for setting mode on files.
|
|
As suggested by Henrik Lindberg, make the parser only behave correctly
when parser=future is configured. If working manifests rely on the
regression, the next point release won't break them. Instead, users can
test for this using the configuration setting.
The next major release should adopt the fix as standard behavior and
the legacy support should be removed. Since the variable lookups in
templates relies on the accessing of local attributes, there is no
way to issue deprecation warnings to users.
|
|
The fix for #1427 added an instance method to the scope class
for exporting all variables from the local scope. This method
apparently re-implemented the dynamic scoping rules.
When those were removed, the #to_hash method was left as was.
As a result, dynamic scoping still worked from within templates,
when using the @variable syntax in the erb code.
Fix this by using the new #enclosing_scope method so that proper
scoping rules are used instead.
|
|
(PUP-1670) Add validate_cmd parameter to file type
|
|
If this parameter is set, then this file will only be written if
the command specified returns 0.
Also adds a validate_replacement parameter to allow specifying some
other string to use for specifying temporary file name instead of the
default of '%'.
|
|
This is a very rough draft for a spec test wrt. the "mode" parameter.
Testing group and owner is difficult since unprivileged rspec users
cannot use chown or chgrp.
This is open for discussion and should be revised before merging.
|
|
* pr/2024:
(PUP-649) Loosen checks for crontab provider
(PUP-649) Use class instance variable
(#3220) uniquify implicit record names
(#3220) save overhead in cron type unit test and add cleanup
(#3220) make the unit test "generating cron resources" match the new behaviour
(#3220) fix a cron testing quirk with potential benefits for normale operation
(#3220) make sure that generated cron resources belong to the correct user
(#3220) crontab: allow purging unmanaged resources
Closes GH-2024
|
|
The problem was that unmanaged cronjobs would be parsed, but
not implicitly named.
Workaround: Pick an implicit name. It's derived from the command.
The provider will never put this implicit name into a crontab file
when writing it back to disk.
The names are not unique if several unmanaged jobs execute the same
command. That's a wrinkle and not mission critical, but it can
be surprising for users, because the "duplicates" will not be
purged during the first run.
|
|
Both `puppet apply` and `puppet parser validate` were relying on the
legacy environment behavior to implicit draw in the setting of
Puppet[:manifest]. But the new directory environments do not pay
attention to Puppet[:manifest] and thus a call such as `puppet apply
foo.pp --environment dir_env` would not apply foo.pp if dir_env was in
the $environmentpath.
This change explicitly creates a new environment based off the currently
configured environment and overrides with the manifest this to be
applied or validated.
|
|
This is because these methods are also used for deserialization from
other formats than PSON. The method for serializing a object is called
to_data_hash, so makes sense to call this from_data_hash.
|
|
|
|
The future evaluator is only really in play when both the parser is
future and the evaluator is future. The old check left out the evaluator
portion of that check and so ended up using the wrong CodeMerger when
using the current evaluator with the future parser.
|
|
Previously BlockExpression would skip evaluating any AST nodes that
implement an instantiate method. The assumption was that instiate only
existed on Hostclass, Node, and Definition AST nodes and those same
classes also did not implement an evaluate method. With the introduction
of the PopsBridge::Program class, this entire house of assumption cards
came falling down, since it impelements both instantiate and evaluate.
The only thing that truly prevented BlockExpression from calling
evaluate was that the default evaluate implementation on Parser::AST
raised a Puppet::DevError to try to catch the case of evaluate not
being implemented for an AST class. Since Parser::AST is entirely
internal and missing an evaluate should show up very quickly in tests,
we can just as easily make evaluate a noop by default, which then
simplifies BlockExpression.
This change fixes the problem where the body of pp files were loaded,
but not evaluated when using the future evaluator and a directory of
manifest files. The problem was triggered by the BlockExpression logic
interacting with the PopsBridge::Program object and the structure
created by the Puppet::Pops::Parser::CodeMerger.
|
|
Instead of creating environments directly, we need to go through the
configured environment loaders, otherwise environments can't come from
other places.
|
|
|
|
* upstream/stable:
(maint) Fix rdoc generator for Ruby 2.1.0
(maint) Fix a comment.
(maint) Fix can't modify frozen Symbol error on Ruby 2.1.0
(PUP-1389) Embed the extra NULL within the string
(PUP-1389) Simplify logic for appending extra NULL
(PUP-1389) ReplaceFile to FFI / move wide_string
(PUP-1389) Ensure wide strings have double null terminators
PUP-1322 Do not fail hard on unparseable files
(maint) Correct documentation of each function
(maint) Fix acceptance test for scheduled_task deletion
Conflicts:
lib/puppet/parser/functions/each.rb
|
|
This reverts commit cf4501c7a97c106994c2ef81756c2081f56feeef, reversing
changes made to fcf482aa85708fe20f38cd96d6d92fc58ee78cf6.
|
|
|
|
|
|
|
|
|
