Ask Your Question
0

Notify two exec resources or better use subcribe? [closed]

asked 2017-10-04 12:10:35 -0600

mknl gravatar image

Hi,

I'm looking for the best option to do something like:

tidy { '/parent-path-tidy-should-do-something':
        recurse => 3,
        matches => [ 'search-string1', 'search-string2', 'search-string3'],
        rmdirs  => false,
        notify => [ Exec['my-exec1'], Exec['my-exec2'] ];
    }


exec {'my-exec1':
    cwd     => '/sbin',
    path    => '/sbin',
    command => 'my-command1',
    refreshonly => true,
}

exec {'my-exec2':
    cwd     => '/sbin',
    path    => '/sbin',
    command => 'my-command2',
    refreshonly => true,
}

Basically tidy is doing what it should but it seems like that the second exec will be ignored somehow. I just tested the command on the host after other classes based on this one failed becasue the command did not run. After execute the command manually and trigger another puppet run everything is fine so I'm pretty sure that the command was not triggered/notified correctly.

Is there any more clean way to ensure that both "execs" will be executed correctly? I'm not sure if using an aray of execs is fully supported? (at least it does not produce any error) Eventually it is better to use subscribe (to the same tidy resource) in both execs?

Thanks for any advice

edit retag flag offensive reopen merge delete

Closed for the following reason the question is answered, right answer was accepted by Kai Burghardt
close date 2017-10-10 13:42:50.543880

Comments

I can also do it like this: notify => Exec['my-exec1', 'my-exec2']; The problem is my command is not executed and I don't know why. I want it to be executed only in case the tidy runs (via refreshonly, what is most probably only a one-timer) but it looks like that it does not trigger anything. :-/

mknl gravatar imagemknl ( 2017-10-05 10:08:55 -0600 )edit

1 Answer

Sort by ยป oldest newest most voted
1

answered 2017-10-06 20:46:34 -0600

reesek gravatar image

I ran a quick test and your code seems to work fine for me:

WWT vgtpuppetmaster manifests # cat test.pp 
file { '/tmp/test.txt':
  ensure  => present,
  content => "hello there",
  notify  => [ Exec['my-exec1'], Exec['my-exec2'] ],
}


exec {'my-exec1':
    path        => '/bin',
    command     => 'echo hello > /tmp/hello.txt',
    refreshonly => true,
}

exec {'my-exec2':
    path        => '/bin',
    command     => 'echo there > /tmp/there.txt',
    refreshonly => true,
}

--

WWT vgtpuppetmaster manifests # puppet apply test.pp 
Notice: Compiled catalog for vgtpuppetmaster.wwt.com in environment production in 0.10 seconds
Notice: /Stage[main]/Main/File[/tmp/test.txt]/ensure: defined content as '{md5}161bc25962da8fed6d2f59922fb642aa'
Notice: /Stage[main]/Main/Exec[my-exec1]: Triggered 'refresh' from 1 events
Notice: /Stage[main]/Main/Exec[my-exec2]: Triggered 'refresh' from 1 events
Notice: Applied catalog in 0.25 seconds
WWT vgtpuppetmaster manifests # 
WWT vgtpuppetmaster manifests # cat /tmp/test.txt 
hello thereWWT vgtpuppetmaster manifests # 
WWT vgtpuppetmaster manifests # 
WWT vgtpuppetmaster manifests # cat /tmp/hello.txt 
hello
WWT vgtpuppetmaster manifests # cat /tmp/there.txt 
there

Only difference is I corrected a syntactical error by replacing the ; with a , on the notify attribute, although to my surprise, it did compile and apply with the ;. If an attribute were to follow notify, it would fail, however.

If you're still having trouble, perhaps consider concatenating your commands within one exec, like:

exec {'my-exec':
    path        => '/bin',
    command     => 'echo hello > /tmp/hello.txt ; echo there > /tmp/there.txt',
    refreshonly => true,
}
edit flag offensive delete link more

Comments

The semicolon ain't a syntax error. It separates actual instances of one and the same resource type. See the code examples for instance at https://docs.puppet.com/puppet/latest/lang_resources_advanced.html#per-expression-default-attributes

Kai Burghardt gravatar imageKai Burghardt ( 2017-10-07 07:45:52 -0600 )edit

ah. Okay. That makes sense. My perception was the context of the code wasn't abundantly clear in that regard, since there's only a single resource body. My thinking/point was if the tidy resource were ever refactored, the addition of an attribute to the existing body after the notify (continued...)

reesek gravatar imagereesek ( 2017-10-07 10:51:58 -0600 )edit

without changing the semicolon to a comma would then result in a parse error. You'd get: Error: Could not parse for environment production: Syntax error at '=>' - Thanks for the explanation!

reesek gravatar imagereesek ( 2017-10-07 10:54:49 -0600 )edit

Thanks a lot for your replies and the additional infos regarding ';' and ','. So using ';' at the end of tidy is no real mistake (it is just the end of my ressource body and as there is only one it is ok).

mknl gravatar imagemknl ( 2017-10-09 02:49:11 -0600 )edit

Furthermore as far as I remember I didn't see the "... Exec[my-exec1/2]: Triggered ..." log entries (but the entries what tidy is doing) so eventually tidy is behaving a bit strangre here. I will test around a bit more and let you know.

mknl gravatar imagemknl ( 2017-10-09 02:50:41 -0600 )edit

Question Tools

1 follower

Stats

Asked: 2017-10-04 12:10:35 -0600

Seen: 71 times

Last updated: Oct 06