Your File['Config'] -> Exec['stop'] -> Package['foo'] -> Exec['start'] should do what you want.
Can you also try to require Exec['stop'] in your package foo? Also, the refreshonly => true on you stop exec I don't think it matters. You will need a notify Exec[stop] in your config for that. On Fri, Sep 19, 2014 at 10:00 PM, Jake Lundberg <[email protected]> wrote: > Yes Cristian, I understand that, but the issue is less the order of the > Execs in relation to each other, but when the Execs run in relation to the > config file resource and the package resource. I need for the stop Exec > to run before the package is installed, and then the start Exec to run. > This may be an issue with using Execs in the first place due to the way the > get collected and their execution strategy to reduce duplicate runs. > > I'm hoping execution order is: File['Config'] -> Exec['stop'] -> > Package['foo'] -> Exec['start'] > (In fact I used that exact ordering syntax at one point). > > BTW, using: > Exec['stop'] -> Exec['start'] did cause stop to run before start, just > AFTER Package['foo'] is installed, so thank you for that. This doesn't > solve my issue however as I really need the stop to run before package > installation/upgrade. > > Jake > > On Friday, September 19, 2014 11:13:11 AM UTC-7, Cristian Falcas wrote: >> >> The order of resources in the manifest doesn't matter. Puppet will build >> a graph from all resources and dependencies and executes resources from the >> same level randomly. >> >> You need something like this: >> >> exec { "start": >> path => "/usr/local/sbin/:/usr/local/ >> jdk/bin:/bin:/sbin:/usr/sbin:/usr/bin", >> command => '/usr/local/sbin/control.sh start', >> refreshonly => true, >> logoutput => true, >> require => [File['/usr/local/sbin/control.sh'], Exec['stop'], >> } >> >> >> >> >> On Fri, Sep 19, 2014 at 8:59 PM, Jake Lundberg <[email protected]> >> wrote: >> >>> Puppet 3.6.2 >>> >>> First, I understand that Execs try not to run multiple times if called >>> many times by many resources and typically wait until they've all been >>> "collected" from all resources, but I have a specific case where I need >>> different Execs to run in a particular order based on a set of resources >>> that change. >>> >>> The basic pattern is: >>> 1. Install/update Configuration file (configuration gets updated on all >>> version changes) >>> 2. Stop Exec script subscribes to Configuration file >>> 3. Package Install/update notifies Start Exec script >>> 4. Package requires Configuration file >>> >>> The basic resource ordering in the manifest looks like: >>> >>> require foo::config # This contains the File['Config'] resource >>> >>> #This might be redundant, but trying to force this relationship >>> File['Config'] -> Package["foo"] >>> >>> package { ["foo"]: >>> ensure => "${version}-${release}", >>> notify => Exec['start'] >>> } >>> >>> # Start, stop, restart functions for ads server >>> file {"/usr/local/sbin/control.sh": >>> source => "puppet:///modules/foo/control.sh", >>> ensure => present, >>> owner => root, >>> group => root, >>> mode => 0744, >>> } >>> >>> exec { "stop": >>> path => "/usr/local/sbin/:/usr/local/ >>> jdk/bin:/bin:/sbin:/usr/sbin:/usr/bin", >>> command => '/usr/local/sbin/control.sh stop', >>> refreshonly => true, >>> logoutput => true, >>> subscribe => File['Config'], >>> require => File['/usr/local/sbin/control.sh'] >>> } >>> >>> exec { "start": >>> path => "/usr/local/sbin/:/usr/local/ >>> jdk/bin:/bin:/sbin:/usr/sbin:/usr/bin", >>> command => '/usr/local/sbin/control.sh start', >>> refreshonly => true, >>> logoutput => true, >>> require => File['/usr/local/sbin/control.sh'] >>> } >>> >>> >>> However, when puppet apply runs this is what happens: >>> >>> 1. Configuration file is installed/updated, schedules a refresh of Stop >>> Exec >>> 2. Package is installed, schedules refresh of Start Exec >>> 3. Start Exec runs >>> 4. Stop Exec runs >>> >>> There's probably a better way of doing this (possibly with run stages), >>> I'm just curious why this plan does not work. I'm very open to >>> improvements. >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Puppet Users" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> To view this discussion on the web visit https://groups.google.com/d/ >>> msgid/puppet-users/b892a4d6-4356-40ab-95a2-ab8ca218e2d1% >>> 40googlegroups.com >>> <https://groups.google.com/d/msgid/puppet-users/b892a4d6-4356-40ab-95a2-ab8ca218e2d1%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> -- > You received this message because you are subscribed to the Google Groups > "Puppet Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/puppet-users/5650e7cd-267c-45ac-9ae0-df0c144c508c%40googlegroups.com > <https://groups.google.com/d/msgid/puppet-users/5650e7cd-267c-45ac-9ae0-df0c144c508c%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/CAMo7R_eL6fArTivVLhcMDd1VghtyvzgjPg1Q58Zur9xdKvqnCQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
