Age | Commit message (Collapse) | Author | Files | Lines |
|
(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 tests for the crontab provider exhibited an order dependent failure.
If the spec/integration/provider/cron tests were run before the
spec/unit/provider/cron tests then the global counter that is used by
the crontab provider would not be at the expected value. This isn't
really a problem in practice, but the expectations in the tests were for
a specific count. This updates the checks so that they are resilient to
the exact numbers chosen.
|
|
Adds an numeric suffix to the artifical name that gets generated for
unnamed records in crontabs. It will suppress naming collisions for cronjobs
that use the exact same command string.
|
|
To allow purging of unmanaged resources, they are now implicitly named.
The unit test must take that into account.
|
|
When the catalog contains a cron resource that does not specify a value
for the command property, the transaction would fail with the cryptic
error message 'no command, somehow' under certain conditions.
This error is spurious. Generally, it's quite allowable to manage a subset
of cron properties that does not include the command. Fixed by removing
the devfail invocation. The command property is now handled just like
the 'special' property.
|
|
The previous implementation of the crontab implementation type
determined the filetype to use at load time by calling out to Facter
before the type was loaded, which was both ugly and made it difficult to
test on alternate platforms. This commit overrides the `.filetype`
method to do the detection at runtime so the provider encapsulates all
its logic and the filetype can be stubbed out.
|
|
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)
|