Age | Commit message (Collapse) | Author | Files | Lines |
|
Commit a1dba44 removed a potentially duplicate log destination when
using `puppet master --compile`, but it also meant that `puppet master
--compile` would default to logging to syslog. This issue revealed other
issues, where running `puppet master --no-daemonize` would log to
syslog, but `puppet master --no-daemonize --verbose` would log to the
console. Inconsistencies like these could lead to very surprising
behavior for users.
This commit refactors the master logging to default to console when the
master is running in the foreground and to syslog when running in the
background. When a log destination is given with '--logdest' the default
log destination is ignored in preference of the explicit log
destination.
|
|
Adding a --cfacter setting that will replace the facter implementation
with the native facter implementation if the following conditions are
met:
* cfacter is installed
* the version of cfacter is at least 0.2.0 (not yet released).
* facter has not evaluated any facts by the time the setting is set.
To accomplish this last point, certain default setting values needed to
be delay-evaluated as they relied on facts. Therefore a :default
for a setting now accepts a Proc and calls the Proc only once when the
default value is needed.
|
|
This commit makes a slight modification to the profiling system,
such that we can register multiple profilers at the same time.
This allows callers to register their own profiler without
worrying about collisions with profilers that might have
been registered by other parts of the code.
|
|
Doc tests with mocking did not work, needed to use a real configured
env.
|
|
adrienthebo/feature/master/pup-1840-tunable-digest-algorithm
Feature/master/pup 1840 tunable digest algorithm
|
|
|
|
Previously resources would end up "floating away" from the catalog that
contained them because they wouldn't use the catalog as their
source for an environment. This also extended to catalogs, which lost
track of their environment at times. So in order to have resources use
the environment of their catalog, the catalog needed to have a
guaranteed environment.
This adds an environment parameter to the catalog constructor and uses
it to drive the environment to use for everything in that catalog. The
resource now uses its catalog's environment, if it has a catalog, or it
uses the new NONE environment, if it does not have a catalog.
When catalogs are deserialized, they also need to have a reference to
*some* environment. However, since they only have a name of the
environment, there isn't any guarantee that an environment of that name
is available locally. To deal with this there is a new "remote"
environment constructor to be able to create references to the remote
environment of the catalog. This is used as the environment of a
deserialized catalog.
We (Joshua Partlow and Andrew Parker) tried to have the environment a
required parameter of catalog construction, but it appears that creating
catalogs is public API and so cannot be changed (we verified this by
checking stdlib tests).
|
|
|
|
A few specs relying on mocking Puppet::Node::Environment.new to return
a specific test environment were colliding with the new environments
cacheing layer. Switched to using puppet override to supply a static
environment.
|
|
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.
|
|
* 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
|
|
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
|
|
|
|
Commit 275ac959db060f80e4b8635e1213cc0c2255c732 prevented specs
that did 'describe Puppet::Face[...]' from working correctly.
That is because the instance returned for the describe call
would then differ if face_collection_spec is run before the
spec in question.
The fix is rather than clearing all face state, save and restore
the global state before and after all examples.
Also correcting a mistake in indirection_base_spec where a ivar
wasn't being used between the before and after clauses.
|
|
The face_collection_base spec attempts to restore global state stored in
Puppet::Interface::FaceCollection so that it doesn't interfere with
other specs that may use faces.
It fails to clear any files required by the autoloader, but clears the
@faces member. The result is that if a face is referenced again from
another spec, it doesn't get defined and added to @faces and cannot be
found.
The fix is to clear the state before and after each example.
The problem can be observed with the following:
rspec spec/unit/interface/face_collection_spec.rb spec/unit/application/face_base_spec.rb
Additionally, the indirection_base spec registers a face but does not remove the face
after the examples have fun. The fix is to remove the face from the FaceCollection after
all examples.
|
|
zaphod42/issue/master/pup-1839-incorrect-settings-when-using-puppet-device
(PUP-1839) Introduce overridden defaults
|
|
Now that the `:memory` level of settings is higher precedence than the
cli level, this can now simply set the confdir, vardir, and certname in
a very normal manner.
|
|
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 previous behavior of setting the value of a configuration setting
was that the value only took effect if a user had not specified a value
for that setting on the command line. This caused lots of confusion and
some unsafe situations where the puppet code tries to override a setting
in order to continue.
This changes the precedence of setting values so that anything set in
the code is higher precedence than the cli values. In order to allow
overriding the defaults that are determined by hooks on settings, this
also adds in an `override_default(setting_name, value)` method so that
the hooks can create new defaults.
|
|
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 allows more parity between puppet agent and puppet apply and also
makes it easier to enable a bunch of testing options for apply.
|
|
This changes the API in a new implementation in a file called file_.rb
The intent is that it should replace the implemntation in File,
or perhaps directly in a Puppet::FileSystem class.
|
|
The master application was not using Puppet.log_exception to log out any
errors that might occur during --compile. This meant that there was no
backtrace information available to diagnose the problem.
|
|
- Previously tests were writing to the shared
%ALLUSERSPROFILE%\PuppetLabs\puppet directory, and would blow
up if this directory did not exist
- Because this directory was shared from one run to the next, failing
tests could be masked by data generated / used by a locally installed
Puppet
- The stubbing of FileSystem::File.exist? to return true was causing
some tests to treat files like c:\dev\null\foo to attempt to be
loaded, which would cause these tests to fail in isolation, but not
when run within the suite
- Had to change some doc specs under Ruby 1.9 / OSX to verify a value
instead of asserting a method was called, to prevent a stack overflow
- In some unit tests, the process of reading / writing settings caused
issues with test loading, so Puppet.settings.use has been stubbed
|
|
- All previous File and FileTest calls to exist? or exists? go through
the new FileSystem::File abstraction so that the implementation can
later be swapped for a Windows specific one to support symlinks
|
|
There were several tests attempting to test the cert application,
the CertificateAuthority and its interface, as well as the inventory
handling by use of excessive stubbing that prevents any real code from
being tested.
The failing overly mocked tests have been removed. Their value was
questionable to begin with.
|
|
Prior to this commit there were 6 different puppet applications
with independent implementaions handling the `--logdest` option,
including two that were logging directly to stderr rather than
using `Puppet.log_exception` helper. This commit pulls those
implementations up into Puppet::Application and unifies against
the single implementation using `Puppet.log_exception`. Additionally
it now has unit tests.
|
|
Since apply doesn't need to change profiling while it is running there
is no need for it to explicitly set the profiling to NONE when it is
disabled. It can just use whatever the default for the system is.
However, since the *tests* will run in the same process we need to add a
method to Profiler to clear it back to the original state.
|
|
This ties the selection of the Puppet::Graph::Prioritizer to the
Puppet[:ordering] setting. In order to make it easier to ensure that all
of the uses of the prioritizer use the same one (because it needs to
track state) this also moves around the relationship of the catalog and
the transaction. Previously the catalog was responsible for converting
itself into a relationship graph. This now puts that responsibility on
the transaction, which much now be constructed with the desired
Prioritizer. The selection is still done in the catalog (because that is
where #apply lives, which is the public starting point of applying a
catalog).
Additionally this adds a random prioritizer.
|
|
Running specs with rspec 2.13 caused a lot of warnings. Many of them actually
exposed preexisting bugs, the most common being a syntax error when expecting
an Exception. These are worth fixing even if we don't bump to rspec 2.13.
|
|
* upstream/stable:
(#21280) Don't create C:/dev/null on Windows
|
|
The puppet apply application uses the "store" report processor by default.
Its process method calls mkdir_p on Puppet[:reportdir]. When executing in a
spec test, Puppet[:reportdir] is '/dev/null/reports'. On Unix, the call to
mkdir_p raises an error, which is ignored (since the test is exercising
apply functionality, not the store report processor). But on Windows, the
call to mkdir_p succeeds.
The existence of the c:/dev/null directory causes bundler to fail, and is
why the windows spec jobs do `rmdir /S /Q C:\dev\null`.
This commit updates the tests to use the "none" report processor, which
skips report processing altogether, since it's not germane to the test.
Cherry-pick of bc92db0b
|
|
The inclusion of `execute_agent` was not used in all of the places it
could be. This uses it more thoroughly, but still not constantly since
there are still many tests that work from small, internal methods that
would need to be reworked.
|
|
When the point at which streams are closed was changed from
Puppet::Daemon#start to Puppet::Daemon#daemonize the error message for
onetime would be lost. This is made slightly more obvious (although
admittedly not much) by pulling daemonization as close as possible to
where it is finally started. The lost message is then solved by
switching from $stderr.puts to Puppet.err for issuing the message.
|
|
This pushes the initialization of different parts of the agent under
various circumstances closer to where the pieces are used. By reducing
the "live-time" of the code the risk of bugs related to partial
initialization is reduced.
Because of the internal refactorings and the tight coupling of the tests
to these internal control flows, many of the tests have been reworked to
take a much more outside-in approach and now mostly (but not completely)
test through a more "public" interface.
|
|
The --centrallogging tried to setup some sort of central aggregation of
logs (see issue #51). However at some point in the past the
--centrallogging flag was disconnected from the internal handling of
this (the code assumed it was called :centrallogs). However, even fixing
that disconnect would not have made this work because the logging system
does not appear to support this kind of setup. The :host logging
destination depends on a class called
Puppet::Network::Client::LogClient, which does not exist.
This simply removes all of that code, including the handling of the
command line options. This results in any user who had been passing
those flags now recieving an error, however, since these were never
documented anywhere that I can find, this is an acceptable risk.
|
|
(maint) Add an integration spec for agent logging.
|
|
|
|
Checks which loggers are initialized, and what the log level is for all
combinations of --onetime, --daemonize, --no-daemonize, --verbose,
--debug, and --logdest called on the agent.
A simple patch for #15187 had unintended side effects to logging
behavior which were hard to track down. This test is intended to give
us visibility on how we expect agent logging to behave and whether or
not this has changed.
There is also a minor change to Puppet::Application#setup_logs that
separates assigning a console log for verbose/debug from setting the
log_level, because this was where one of the bugs was hidden.
|
|
Previously, the test was trying to test that the 'facts' application
could be invoked and return exit code 0 with meaningful output. However,
it causes the 'facter' terminus to be invoked, which actually runs
facter.
Since we don't care what facts are returned, this commit adds an
expection to make sure the indirection#save method is called and returns
successfully.
This was discovered on win2003 due to local facts being present, which
when evaluated, wrote errors into the log.
|
|
* issue/master/20447-filetimeout0-causes-master-to-exit-full:
(Maint) Document Puppet::Daemon
(Maint) Mark the Puppet:Daemon private
(Maint) Remove duplication btwn Daemon and Server
(Maint) Remove unused register code for Server
(Maint) Clean up Daemon tests
(Maint) Inject scheduler into Daemon
(Maint) Inject Pidlock dep into Daemon
|
|
While trying to understand several different code paths in the
Puppet::Daemon code the realization that the tests for the daemon code
had to mock internal methods on the class under test caused me worry. By
removing the mocking of the internal methods it was obvious that there
was another collaborator that is a locking service at play. Services
should normally be injected into, and not created by, the consumer of
the service.
This injects the Puppet::Util::Pidlock into the Daemon and reworks the
points of construction of Daemon objects so that the correct information
is available at the point of construction. This require moving the
Daemon creation from the preinit methods to the setup or run methods in
order to ensure that command line processing and therefore Puppet#[] was
ready at the point of construction so that the correct Puppet[:pidfile]
could be used.
|
|
Add the option stringify_facts which defaults to true. If it is turned
on the current behaviour with turning facts into strings is kept.
If it is false facts are sanitized and only converted to strings if they
aren't booleans, numerics, arrays and hashes. It does this sanitizing in
a nested manner for arrays and hashes.
|
|
|
|
To make it easier to read, pipe output and make shell loop from output
from faces it is good if they are printed one item per line for arrays.
|
|
Without this commit the --debug and --verbose flags can only be used
with the rdoc mode and doesn't interact with the other documentation
types. This commit extracts the logging configuration to apply to all
documentation modes.
In addition this defaults the log level to :warning. Since warning and
above messages will be emitted on stderr this will not affect the normal
operation of the `puppet doc` command. Using --debug or --verbose will
emit messages on stdout, so they should not be used while
programmatically generating docs.
|
|
On Ruby 1.9.3, stubbing `$stdout.puts` will stub out calls to `puts` but
on 1.8.7 this stubbing fails. This commit updates the tests to stub out
the `puts` method on the master object to catch and silence the catalog
outputting in the tests on 1.8.7.
|
|
This commit fixes the infamous error that appeared periodically as:
````
1) Puppet::Application::FaceBase#parse_options should stop if the first thing found is not an action
Failure/Error: @logs.map(&:message).should == ["'basetest' has no 'banana' action. See `puppet help basetest`."]
expected: ["'basetest' has no 'banana' action. See `puppet help basetest`."]
got: ["Could not run Puppet configuration client: Not a directory - /dev/null/state/agent_catalog_run.lock", "'basetest' has no 'banana' action. See `puppet help basetest`."] (using ==)
````
The error came from the spec for Puppet::Application::Kick, which tried
to test the error responses from the application calling Puppet::Run.
Unfortunately only one of the 4 tests actually stubbed out the call
which ends up invoking a puppet run via Puppet::Run.
The reason this was so hard to track down is that it only occured if the
thread that was created for the puppet run executed during the later
test and added a message into the log messages tracked in memory. To
find this the kick test and the face_base test were run repeatedly until
the error occurred.
|
|
The `jj` method can be clobbered if other JSON libraries, notably `json_pure`,
are loaded. When this occurs, `puppet master --compile` silently fails to
produce any output.
|
|
Previously the regexp which attempts to truncate the output
of `puppet describe --list` at the end of a sentence, if it
is within the first 45 characters of the doc string, actually
truncated at the first period/full-stop character. This caused
doc strings which include dots, such as `.k5login`, to be
prematurely truncated.
This commit causes it to instead only truncate at the first
dot-space combination, which is a more reliable indicator of
the end of a sentence.
This also fixes a typo in the spec tests for this code, but
digging further into the code to figure out how to test it
effectively sent me down a rabbit-hole and I gave up.
Paired-With: Michael Hall <mph@puppetlabs.com>
|