| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Previously, the windows service provider rescued exceptions of type
Win32::Service::Error. However, FFI-based versions of win32-service (v0.8.x)
no longer raise that type of error. Instead they raise SystemCallError.
So previously, if puppet failed to manage a service, e.g. service didn't
exist, puppet would try to rescue the exception specifying a class that
was not defined:
puppet resource service foo ensure=stopped
Error: /Service[foo]: Could not evaluate: uninitialized constant Win32::Service::Error
This regression was introduced as part of PUP-1283 when we migrated from
win32-service version 0.7.x to 0.8.x.
This commit modifies the various provider methods to more broadly rescue
StandardErrors and updates the spec tests to handle the negative cases.
Paired-with: Ethan J Brown <ethan@puppetlabs.com>
|
|
|
|
(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>
|
|
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.
|
|
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.
|
|
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.
|
|
The initial fix for 23141 didn't account for a remount when
options were specified. This caused integration tests to
fail because a) the integration tests assumed mounted is always
false when the mountcmd is called (not true for a remount), and
b) the integration tests weren't updated to consider the 'update'
option.
This patch updates the remount method to append ',update' if
there are already options, and updates the integration tests
accordingly.
|
|
|
|
The mount provider explicitly passes the mountoptions to the mount
command with the "-o" parameter. While this works in most cases it fails
when the option property contains an option that needs to be unique as
the default behaviour of the mount command seems to be to merge fstab
options with explicitly definied options via the commandline.
Since the mountprovider always updates the /etc/fstab file before
attempting to mount we should not need to pass the options explicitly.
The current code mentions some weired behaviour on MacOSX so we keep the
original behaviour on MacOS and drop the explicit options on
all other platforms.
This also fixes #7791
|
|
The crontab provider fails to apply the change to a cronjob if
the schedule has been a special schedule such as @daily. Paraphrasing
from the bug report, assuming this crontab:
@reboot /bin/true
this manifest won't work correctly:
cron{ "test": minute => 50 }
even though puppet will correctly detect that the 'minute' property
needs changing from "absent". The special schedule will remain.
The fix allows this workaround:
cron{ "test": minute => 50, special => absent }
|
|
The previous final cron test was Very Bad. It relied on an edge case
that sidestepped #2251.
Assume user1 and user2 and a cronjob X that moves from user1 to user2.
Normally, this will trigger #2251 and fill user2's crontab with duplicates
until at some point, another cronjob of user1's needs changing and the
provider behaves as tested.
In many real life scenarios, it can be months or weeks before this happens.
Testing for the behaviour agreed upon in the redmine ticket makes more
sense, because we can now make sure that the edge case will not hide
unwanted behavior that emerges in the average case.
|
|
Since windows doesn't have a functional crontab provider, it doesn't
make sense to run integration tests for cron on windows.
|
|
The cronprovider defines two record_types :crontab and :freebsd_special
to handle the following crontab records:
@daily /bin/my_daily_command
0 0 * * * /bin/my_daily_command
This has a few issues:
a)
The merging of the name (the comment before the cronentry itself) and
the environment variables only happens for the :crontab record_type
but not for the :freebsd_special record_type so information may get
lost (#16809)
b)
When parsing an existing record the record_type can be automatically
determined (depending on which regex matched) but when creating a new
entry the record_type is undefined and the default :crontab is used.
So if a new cronentry is created with the :special property set it is
still treated as a crontab entry (so the to_line hook of the :crontab
record_type is used and not of the :freebsd_special record_type)
which is kind of confusing.
c)
It is really hard to change the time of a cronentry from the special
format to a normal format (or vise versa) e.g. if we already have the
following cronentry
# Puppet Name: foo
* * * * * /bin/foo
and we have defined the following resource
cron { "foo":
special => daily,
}
the resource is treatd as in sync because the existing cronentry is
parsed as a :crontab record_type and this record_type doesn't define a
:special field that could be out of sync
This patch now only uses one record_type that internally parses the
timefield as either the old format (minute,hour,monthday,month,weekday)
or the special format. This way the above issues go away (but the
different to_line, post_parse hooks get a bit more difficult to handle
both entries)
|
|
|
|
Without this patch Ruby 1.9 is still complaining loudly about trying to
parse the spec files. The previous attempt to clean up this problem in
edc3ddf works for Ruby 1.8 but not 1.9.
I'd prefer to remove the shebang lines entirely, but doing so will cause
encoding errors in Ruby 1.9. This patch strives for a happy middle
ground of convincing Ruby it is actually working with Ruby while not
confusing it to think it should exec() to rspec.
This patch is the result of the following command run against the source
tree:
find spec -type f -print0 | \
xargs -0 perl -pl -i -e 's,^\#\!\s?/(.*)rspec,\#! /usr/bin/env ruby,'
|
|
Correct the typo missing :if=> in the previous
checkin 45e165016534b6c786d269a7825e72599c9beaa6
|
|
Previously, the pending for solaris was specified incorrectly resulting in the test being pending in all platforms.
This checkin corrects this mistake. Since Facter[:osfamily] is stubbed before each tests, we save the family value before
starting and use it to compare.
|
|
Priror to this commit, Puppet had many conditionals based of the
operatingsystem fact returning `:solaris`. This fact now
supports (and can return) several different version of Solaris.
Change the conditionals in Puppet which rely on Solaris to rely on
the osfamily fact instead, to prevent issues with this change in
Facter.
<hailee@puppetlabs.com>
|
|
Unless we are able to mock the operating system Fact, we will not be
able to run all the mount parsing tests running on each platforms.
However this is not required. We could aswell run the platform specific
test on the specific platform. However this is not done at present.
We are just making it pending for solaris since other platforms pass.
for the mount_spec, the mocked operating system value is not reflected
in lib/puppet/provider/mount/parsed.rb needing @blockdevice to be passed
in even though we are impersonating as Darwin
|
|
Without this patch some spec files are using `ruby -S rspec` and others
are using `rspec`.
We should standardize on a single form of the interpreter used for spec
files.
`ruby -S rspec` is the best choice because it correctly informs editors
such as Vim with Syntastic that the file is a Ruby file rather than an
Rspec file.
|
|
* upstream/2.7rc:
(#14761) Add boot, reboot to excludes list for redhat provider
(maint) Disable upstart spec test on windows
(#14615) Final stub fixes for the tests.
(#14615) Fix provider spec tests to work on non gentoo systems
maint: Make it easier to test the service provider
(Maint) Close filehandles after read in upstart
Update CHANGELOG, conf/redhat/puppet.spec for 2.7.15rc3
(#14615) Exclude helperscripts in gentoo service provider
Conflicts:
CHANGELOG
conf/redhat/puppet.spec
spec/integration/provider/service/init_spec.rb
spec/unit/provider/service/init_spec.rb
This commit undoes the restriction on the upstart spec that kept it from
running on windows. And allowed a freebsd test to begin running on 1.9
series ruby
|
|
Before the change the directories to search for initscripts (e.g.
`/etc/init.d`, `/sbin/init.d`) were stored in a class variable that was
calculated at load time. This way stubbing `operatingsystem` in test
cases did not change the value of `@defpath`.
Turning the class variable in a class method. This way stubbing
operatingsystem does change the result when querying defpath. The fact
lookup should be relativly cheap so we do not have to cache the
value in a class variable.
|
|
* 2.7.x:
Revert "Fix incorrect argument handling for expire in NodeExpirer"
Fix #14123 for Windows
Fix incorrect argument handling for expire in NodeExpirer
Fix filebucket specs on Windows
(#8778) Make '' == undef commutative in the DSL
(#14173) Enforce that filebucket paths must be absolute
(#14127) Add integration tests for ssh_authorized_key
maint: refactor integration specs for ssh_authorized_key
(#14127) ssh_authorized_keys grammer fails on blank lines.
(#14123) Puppet shouldn't explode if PATH contains ~nonexistent_user
Conflicts:
lib/puppet/provider/ssh_authorized_key/parsed.rb
lib/puppet/util.rb
|
|
Test the behaviour of the ssh_authorized key type when modifying a file
with different kind of text lines (inline comment and blank lines)
|
|
Replace all before blocks and instance variables with rspec let methods
and move the stubbing of File.chmod that happened in all tests to the
top to reduce code duplication.
|
|
A whole bunch of tests scattered through the system fail on Windows, around
features that are not supported on that platform. (They are things that only
the master does, which an agent-only platform doesn't need to support.)
These were tagged `fails_on_windows` to allow filtering them from rspec runs,
which is great, but doesn't actually communicate nearly as much useful
information as it would if we used the "conditionally pending" facilities that
rspec has supported since 2.3.
That gives us two key things: one, it works automatically based on our
knowledge of the platform, which means you can't forget to turn off failing
tests.
Two, it means that if the test starts unexpectedly passing we also get a
failure, since we should respond to "works when it shouldn't" as seriously as
"fails when it shouldn't".
Signed-off-by: Daniel Pittman <daniel@puppetlabs.com>
|
|
Now we have passing tests on Ruby 1.9, we can make all those tags go away and
enable the full suite. Now anything that fails should be treated like a real
failure, which is reasonable since this is a real and supported platform.
Signed-off-by: Daniel Pittman <daniel@puppetlabs.com>
|
|
* stschulte/ticket/2.7.x/9544:
(#9544) Stub command in package spec that needs root priviledges
|
|
|
|
|
|
The portage package provider on gentoo uses the helper program eix to
query packages. Eix uses a cache and the portage provider calls
eix-update in case the cache is out of date. The eix-update needs root
priviledges (or the user at least has to be in the portage group) that
may not be the case when running the specs.
Stub the update_eix method to prevent puppet from modifying the current
system when running the specs.
|
|
fails_on_windows tag not removed, because there are still errors
running gem.bat on Windows
|
|
into 2.7rc
|
|
This provider takes some of its inspiration from the appdmg provider
used with OS X. It will maintain a list of packages that have been
installed and removed from the system via the provider in a directory
under Puppet's vardir called db/package/msi. These state files will
be named the same as the resource name with '.yml' appended. The
state files will be a hash containing the resource name, the install
options used, and the source location of the MSI.
Any properties that a user wishes to provide to the MSI can be
specified as key/value pairs in the install_options parameter. For
example:
package { 'mysql':
provider => msi,
source => 'E:\mysql.msi',
ensure => installed,
install_options => { 'INSTALLDIR' => 'C:\mysql' },
}
The MSI properties specified by install_options will be appropriately
quoted when invoking msiexec.exe to install the MSI.
Because the source parameter is integral to the functionality of being
able to install and uninstall MSI packages, we also override
validate_source to make sure that the source parameter is always set,
and is not an empty string when using this provider.
|
|
The mount, shell, and ssh_authorized_key types are not supported on
Windows, so these spec tests have been disabled when running on
Windows.
One of the compiler spec tests fails on Windows because
Puppet::Util.execute attempts to execute a program named "git rev-parse
HEAD". This has different semantics than Unix, where the command is
splatted, Kernel.exec(*command). Since this truly is a Windows bug, I
removed the fails_on_windows tag and updated ticket #8410.
Reviewed-by: Jacob Helwig <jacob@puppetlabs.com>
(cherry picked from commit d9ce88d10707268fe41c8f3ad1166137fe8e202f)
|
|
Many spec tests fail on Windows because there are no default
providers implemented for Windows yet. Several others are
failing due to Puppet::Util::Cacher not working correctly,
so for now the tests that are known to fail are marked with
:fails_on_windows => true. To skip these tests, you can run:
rspec --tag ~fails_on_windows spec
Reviewed-by: Jacob Helwig <jacob@puppetlabs.com>
(cherry picked from commit 255c5b4663bd389d2c87a2d39ec350034421a6f0)
Conflicts:
spec/unit/resource/catalog_spec.rb
|
|
The option property of the ssh_authorized_key type supports an array of
options. To prevent user errors we fail when the user tries to pass
multiple option as a single string like "option1,option2" instead of an
array. A single option however can also include a comma. Sample option:
from="host1,host2".
Add tests that demonstrate that the new value validation on options
is to strict.
|
|
|
|
By running:
rspec spec --tag ~@fails_on_ruby_1.9.2
We can now just run the specs that pass under Ruby 1.9. Obviously in
the long term we want to have all the specs passing, but until then we
need notification when we regress. From now on new code will be
required to pass under Ruby 1.9, and Jenkins will give us email
notification if it doesn't or if we break something that was already
working.
Reviewed-by: Daniel Pittman <daniel@puppetlabs.com>
|
|
Add tests to show the issue that one key is not moved from one keyfile
to another keyfile if target is not in sync.
Reviewed-By: Nick Lewis
Reviewed-By: Josh Cooper
|
|
We now use a shebang of: #!/usr/bin/env rspec
This enables the direct execution of spec tests again, which was lost earlier
during the transition to more directly using the rspec2 runtime environment.
|
|
rspec2 automatically sets a bunch of load-path stuff we were by hand, so we
can just stop. As a side-effect we can now avoid a whole pile of stupid things
to try and include the spec_helper.rb file...
...and then we can stop protecting spec_helper from evaluating twice, since we
now require it with a consistent name. Yay.
Reviewed-By: Pieter van de Bruggen <pieter@puppetlabs.com>
|
|
Fixing test errors:
wrong argument type Symbol (expected Proc)
undefined method `lines' for #<Array:0x1020823e0>
Reviewed-by: Nick Lewis <nick@puppetlabs.com>
|
|
Running the specs under Ruby 1.9 didn't work using the lambda to recurse
down directories to find the spec_helper. Standardizing the way to find
spec_helper like the rest of specs seemed like the way to go.
Here's the command line perl I used to make the change:
perl -p -i -e "s/Dir.chdir.*lambda.*spec_helper.*$/require
File.expand_path(File.dirname(__FILE__) + '\/..\/..\/spec_helper')/"
`find spec -name "*_spec.rb"`
Then I fixed the number of dots for files that weren't two levels from
the spec dir and whose tests failed.
Reviewed-by: Nick Lewis <nick@puppetlabs.com>
|
|
* 2.6.x: (36 commits)
Updated CHANGELOG for 2.6.7rc1
(#5073) Download plugins even if you're filtering on tags
Fix #5610: Prevent unnecessary RAL lookups
Revert "Merge branch 'ticket/2.6.x/5605' of git://github.com/stschulte/puppet into 2.6.next"
(#6723) Fix withenv environment restoration bug
(#6689) Remove extraneous include of Puppet::Util in InventoryActiveRecord
Remove extra trailing whitespace from lib/puppet/resource.rb
(#5428) More fully "stub" Puppet::Resource::Reference for use with storedconfigs
(#6707) Fix typo in rest_authconfig.rb
(#6689) Make inventory_active_record terminus search quickly
(#5392) Give a better error when realizing a non-existant resource
(#2645) Adding a less-stubby test to verify the "system" attribute's behavior
Update CHANGELOG for 2.6.6
maint: Remove serialization of InventoryFact values
maint: Rename InventoryHost to InventoryNode
Fixed #2645 - Added support for creating system users
maint: Remove spec run noise
maint:Refactor of mount provider integration tests
(#6338) Support searching on metadata in InventoryActiveRecord terminus
(#6338) Implement search for InventoryActiveRecord facts terminus
...
This merge includes essentially reverting #4904's change to the mount
type since tests that came in from 2.6.x specified different
behavior and what's correct is not clear to me. I've reopened #4904 and
added it to our backlog, and talked to Nigel about the RFC that's
currently out on the puppet-users mailing list for a bigger refactor of
how the mount provider works.
Manually Resolved Conflicts:
spec/spec_helper.rb
spec/unit/indirector/queue_spec.rb
|
|
When adding a test for #6309, decided to refactor mount provider
integration tests by adding return value to check_fstab method.
Paired-with:Paul Berry <paul@puppetlabs.com>
|
|
Paired-with: Max Martin <max@puppetlabs.com>
|
|
There were two problems:
* In lib/puppet/type/mount.rb, we were calling provider.mounted? to
determine whether we needed to execute "mount" after updating the
in-memory fstab record. This wasn't working properly because
provider.mounted? makes its decision based on the data stored in the
in-memory fstab record. Since the fstab record had just been
updated, provider.mounted? was incorrectly returning true even
though the device wasn't actually mounted. Fixed this by checking
provider.mounted? before updating the in-memory fstab record.
* Calling mount from this point in lib/puppet/type/mount.rb is
actually too early, because even though the in-memory fstab record
has been created, its contents have not been written to `/etc/fstab`
yet. Fixed this by storing a :needs_mount entry in the
property_hash and checking it at the end of the flush() method.
Reviewed-by: Jacob Helwig <jacob@puppetlabs.com>
|
|
mount, and umount are located under /bin, instead of /sbin on Linux, so we
adjust the ExecutionStub to accept either location.
Paired-with: Jacob Helwig <jacob@puppetlabs.com>
|
|
These tests form a starting point for integration testing the mount
provider, using the new Puppet::Util::ExecutionStub mechanism to
simulate the state of the machine in response to the execution of
"mount" and "umount" commands. The tests currently work around some
known bugs (6628, 6632, and 6633).
Reviewed-by: Max Martin <max@puppetlabs.com>
|
