Service[foo] fails under --noop if its package has never been installed

[Drew Raines]

Hello!

I'm running `apply --noop` regularly. I would really like to also
do it on a fresh machine before changing bits on the disk.
Unfortunately this fails for Service types because their init
scripts don't yet exist. For example, take ntp:

package { "ntp":
ensure => present,
} ->
service { "ntp":
ensure => running,
}

If I run `sudo puppet apply --noop foo.pp` I get:

Debug: /Stage[main]/Main/Service[ntp]/require: requires
Package[ntp]
Info: Applying configuration version '1396455554'
Debug: Prefetching apt resources for package
Debug: Executing '/usr/bin/dpkg-query -W --showformat
'${Status} ${Package} ${Version}\n''
Debug: Executing '/usr/bin/dpkg-query -W --showformat
'${Status} ${Package} ${Version}\n' ntp'
Notice: /Stage[main]/Main/Package[ntp]/ensure: current_value
purged, should be present (noop)
Debug: /Stage[main]/Main/Package[ntp]: The container
Class[Main] will propagate my refresh event
Debug: Service[ntp](provider=upstart): Could not find ntp.conf
in /etc/init
Debug: Service[ntp](provider=upstart): Could not find ntp.conf
in /etc/init.d
Debug: Service[ntp](provider=upstart): Could not find ntp in
/etc/init
Debug: Service[ntp](provider=upstart): Could not find ntp in
/etc/init.d
Debug: Service[ntp](provider=upstart): Could not find ntp.sh
in /etc/init
Debug: Service[ntp](provider=upstart): Could not find ntp.sh
in /etc/init.d
Error: /Stage[main]/Main/Service[ntp]: Could not evaluate:
Could not find init script or upstart conf file for 'ntp'

I get why this fails. Package["ntp"] hasn't written anything to
disk during the dry run, so Service["ntp"] can't find the right
pieces that it would have needed. I was hoping the
`Package["ntp"] -> Service["ntp"]` relationship would have
accounted for this.

This thread from years ago touches on this but quickly gets into a
semantic discussion about include/require:
https://groups.google.com/d/msg/puppet-users/vTDoxY3OdNI/HOWeN_ZhDJ8J.

I'm mostly curious if I'm cutting across the grain here. I'm
relatively new to Puppet. Is --noop not universally useful for
dry runs? If it is, how can I work around this issue?

Thanks!

Drew

[jcbollinger]

On Wednesday, April 2, 2014 12:12:14 PM UTC-5, Drew Raines wrote:

Hello!

I'm running `apply --noop` regularly.  I would really like to also
do it on a fresh machine before changing bits on the disk.
Unfortunately this fails for Service types because their init
scripts don't yet exist.  For example, take ntp:

    package { "ntp":
      ensure => present,
    } ->
    service { "ntp":
      ensure => running,
    }

If I run `sudo puppet apply --noop foo.pp` I get:

[...]

    Error: /Stage[main]/Main/Service[ntp]: Could not evaluate:
    Could not find init script or upstart conf file for 'ntp'

I get why this fails.  Package["ntp"] hasn't written anything to
disk during the dry run, so Service["ntp"] can't find the right
pieces that it would have needed.  I was hoping the
`Package["ntp"] -> Service["ntp"]` relationship would have
accounted for this.

Nope, sorry.  Puppet running in --noop mode has no visibility into what applying any resource -- especially a package -- would have done, or even into whether applying that resource would have succeeded at all.  The most it can know is what commands it would have run, and that doesn't yield the kind of information you hoped for.  It may at times seem magical, but Puppet is not actually a real boy.

 

This thread from years ago touches on this but quickly gets into a
semantic discussion about include/require:
https://groups.google.com/d/msg/puppet-users/vTDoxY3OdNI/HOWeN_ZhDJ8J.

That is an orthogonal issue.  Yours is specific to --noop mode, and it would occur regardless of resource relationships.

 

I'm mostly curious if I'm cutting across the grain here.  I'm
relatively new to Puppet.  Is --noop not universally useful for
dry runs?  If it is, how can I work around this issue?

Nothing is "universally useful" for dry runs in the sense of accurately predicting all the outcomes of a series of commands that modify the system, without actually running the commands.  This is what testing is for.  The only work around is to change your interpretation of the data: you should not view your result as "Puppet fails" but as "Puppet tries to start the service".  There is also useful information there about when Puppet makes that attempt relative to syncing other resources.


John

[Sven Sporer]

Hi, as John already noted, I'd avoid relying on --noop output to gauge the success of a Puppet run[1], but instead get in the habit of performing real tests. This means testing the bootstrap process of new servers, using Vagrant and serverspec or something similar.

[1] not entirely, of course; I still use it heavily in test environments when developing modules

Sven

[Drew Raines]

Sven Sporer wrote:

> Hi, as John already noted, I'd avoid relying on --noop output to
> gauge the success of a Puppet run[1], but instead get in the
> habit of performing real tests. This means testing the bootstrap
> process of new servers, using Vagrant and serverspec or
> something similar.

That's what I wanted to know -- whether to *expect* it to work. I
already have a pretty extensive staging process with Vagrant, but
inevitably when deploying to a provider or ami I've never used
something is different. I would like to get a successful dry-run
before touching the disk, but if I can't then I'll work around it.

Thanks both for your response!

Drew