Order two calls of parameterized classes

[Ugo Bellavance]

Hi,

I would need to execute a command after the execution of another and I didn't find anything on the web regarding this.  Here's the code:

  if $vhost_name_fact != undef {

  } else {

    zendserver::sdk::command { "vhost_add_${vhostname}_${port}":

      target             => $target,

      api_command        => 'vhostAdd',

      additional_options => $additional_options,

    }

    zendserver::sdk::command { "vhost_reload_${vhostname}_${port}":

      target             => $target,

      api_command        => 'restartPhp',

    }

  }

I would like to have the second command to always be executed once the first one has been executed.  How would I do that?

Thanks,

Ugo

[Pete Brown]

The require meta parameter will do that.

--
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 puppet-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/9d740bb9-1239-4c0f-935e-7b949b1c7ac6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Matthew Kennedy]

Because puppet is declarative you can only have one instance of a resource with a particular title in the catalog. This means you cannot have two instances of a class in the catalog (though you can include a class multiple times but it only exists in the catalog once)

Luckily you do not have two instances of a class.  'zendserver::sdk::command' appears to be a defined type.

Defined types generate resources. You can have multiple instances of a type so long as the title is unique. This is exactly what your example shows, two instances of 'zendserver::sdk::command' with two different titles.

Now the good part for you. Defined types contain all of their unique resources.  This means that any resources that get generated by 'zendserver::sdk::command' will honor the ordering metaparameters. See https://docs.puppet.com/puppet/4.10/lang_defined_types.html#containment

The only thing you need to do to order your commands is add a -> after the closing } of the first command ie

    zendserver::sdk::command { "vhost_add_${vhostname}_${port}":

      target             => $target,

      api_command        => 'vhostAdd',

      additional_options => $additional_options,

    } ->

    zendserver::sdk::command { "vhost_reload_${vhostname}_${port}":

      target             => $target,

      api_command        => 'restartPhp',

    }

Now all resources generated by Zendserver::Sdk::Command["vhost_reload_${vhostname}_${port}"] will apply /after/ the resources generated by Zendserver::Sdk::Command["vhost_add_${vhostname}_${port}"]

Peace,
Matt

To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/CAJ8DPF6nexPDcsYUqrtU4KYq_th6D_wyevdqNKzh32UwV1iQ9w%40mail.gmail.com.

[Ugo Bellavance]

On Thursday, June 1, 2017 at 6:08:01 PM UTC-4, Pete Brown wrote:

The require meta parameter will do that.

Ok, but how to formulate it with the variables?

[Ugo Bellavance]

On Thursday, June 1, 2017 at 11:39:26 PM UTC-4, Matthew Kennedy wrote:

Because puppet is declarative you can only have one instance of a resource with a particular title in the catalog. This means you cannot have two instances of a class in the catalog (though you can include a class multiple times but it only exists in the catalog once)

Luckily you do not have two instances of a class.  'zendserver::sdk::command' appears to be a defined type.

That was on purpose :).

 

Defined types generate resources. You can have multiple instances of a type so long as the title is unique. This is exactly what your example shows, two instances of 'zendserver::sdk::command' with two different titles.

Now the good part for you. Defined types contain all of their unique resources.  This means that any resources that get generated by 'zendserver::sdk::command' will honor the ordering metaparameters. See https://docs.puppet.com/puppet/4.10/lang_defined_types.html#containment

The only thing you need to do to order your commands is add a -> after the closing } of the first command ie

    zendserver::sdk::command { "vhost_add_${vhostname}_${port}":

      target             => $target,

      api_command        => 'vhostAdd',

      additional_options => $additional_options,

    } ->

    zendserver::sdk::command { "vhost_reload_${vhostname}_${port}":

      target             => $target,

      api_command        => 'restartPhp',

    }

Now all resources generated by Zendserver::Sdk::Command["vhost_reload_${vhostname}_${port}"] will apply /after/ the resources generated by Zendserver::Sdk::Command["vhost_add_${vhostname}_${port}"]

As simple as that?  Great.  I tried it and the reload did run after the add, but I can't see from the logs that the reload has the add as dependency.

With your suggested change:

Debug: /Stage[main]/Main/Node[default]/Zendserver::Vhost[vhost1test91]/Zendserver::Vhost::Add[vhost1test91]/Zendserver::Sdk::Command[vhost_add_vhost1test_91]/Exec[zsapi_vhost_add_vhost1test_91]: The container Zendserver::Sdk::Command[vhost_add_vhost1test_91] will propagate my refresh event

Debug: Zendserver::Sdk::Command[vhost_add_vhost1test_91]: The container Zendserver::Vhost::Add[vhost1test91] will propagate my refresh event

Debug: /Stage[main]/Main/Node[default]/Zendserver::Vhost[vhost1test91]/Zendserver::Vhost::Add[vhost1test91]/Zendserver::Sdk::Command[vhost_reload_vhost1test_91]/Exec[zsapi_vhost_reload_vhost1test_91]/returns: Exec try 1/3

Debug: Exec[zsapi_vhost_reload_vhost1test_91](provider=posix): Executing '/usr/local/zend/bin/zs-client.sh restartPhp --target=localadmin  '

Debug: Executing '/usr/local/zend/bin/zs-client.sh restartPhp --target=localadmin  '

Without your change (my original code):

Debug: /Stage[main]/Main/Node[default]/Zendserver::Vhost[vhost1test91]/Zendserver::Vhost::Remove[vhost1test91]/Zendserver::Sdk::Command[vhost_remove_vhost1test_91]/Exec[zsapi_vhost_remove_vhost1test_91]: The container Zendserver::Sdk::Command[vhost_remove_vhost1test_91] will propagate my refresh event

Debug: Zendserver::Sdk::Command[vhost_remove_vhost1test_91]: The container Zendserver::Vhost::Remove[vhost1test91] will propagate my refresh event

Debug: /Stage[main]/Main/Node[default]/Zendserver::Vhost[vhost1test91]/Zendserver::Vhost::Remove[vhost1test91]/Zendserver::Sdk::Command[vhost_reload_vhost1test_91]/Exec[zsapi_vhost_reload_vhost1test_91]/returns: Exec try 1/3

Debug: Exec[zsapi_vhost_reload_vhost1test_91](provider=posix): Executing '/usr/local/zend/bin/zs-client.sh restartPhp --target=localadmin  '

Debug: Executing '/usr/local/zend/bin/zs-client.sh restartPhp --target=localadmin  '

I don't see any difference.

Thanks,

[Ugo Bellavance]

As simple as that?  Great.  I tried it and the reload did run after the add, but I can't see from the logs that the reload has the add as dependency.

With your suggested change:

Debug: /Stage[main]/Main/Node[default]/Zendserver::Vhost[vhost1test91]/Zendserver::Vhost::Add[vhost1test91]/Zendserver::Sdk::Command[vhost_add_vhost1test_91]/Exec[zsapi_vhost_add_vhost1test_91]: The container Zendserver::Sdk::Command[vhost_add_vhost1test_91] will propagate my refresh event

Debug: Zendserver::Sdk::Command[vhost_add_vhost1test_91]: The container Zendserver::Vhost::Add[vhost1test91] will propagate my refresh event

Debug: /Stage[main]/Main/Node[default]/Zendserver::Vhost[vhost1test91]/Zendserver::Vhost::Add[vhost1test91]/Zendserver::Sdk::Command[vhost_reload_vhost1test_91]/Exec[zsapi_vhost_reload_vhost1test_91]/returns: Exec try 1/3

Debug: Exec[zsapi_vhost_reload_vhost1test_91](provider=posix): Executing '/usr/local/zend/bin/zs-client.sh restartPhp --target=localadmin  '

Debug: Executing '/usr/local/zend/bin/zs-client.sh restartPhp --target=localadmin  '

Without your change (my original code):

Debug: /Stage[main]/Main/Node[default]/Zendserver::Vhost[vhost1test91]/Zendserver::Vhost::Remove[vhost1test91]/Zendserver::Sdk::Command[vhost_remove_vhost1test_91]/Exec[zsapi_vhost_remove_vhost1test_91]: The container Zendserver::Sdk::Command[vhost_remove_vhost1test_91] will propagate my refresh event

Debug: Zendserver::Sdk::Command[vhost_remove_vhost1test_91]: The container Zendserver::Vhost::Remove[vhost1test91] will propagate my refresh event

Debug: /Stage[main]/Main/Node[default]/Zendserver::Vhost[vhost1test91]/Zendserver::Vhost::Remove[vhost1test91]/Zendserver::Sdk::Command[vhost_reload_vhost1test_91]/Exec[zsapi_vhost_reload_vhost1test_91]/returns: Exec try 1/3

Debug: Exec[zsapi_vhost_reload_vhost1test_91](provider=posix): Executing '/usr/local/zend/bin/zs-client.sh restartPhp --target=localadmin  '

Debug: Executing '/usr/local/zend/bin/zs-client.sh restartPhp --target=localadmin  '

I don't see any difference.

I think I found it:

Debug: /Stage[main]/Main/Node[default]/Zendserver::Vhost[vhost1]/Zendserver::Vhost::Add[vhost1]/Zendserver::Sdk::Command[vhost_add_vhost1_80]/before: requires Zendserver::Sdk::Command[vhost_reload_vhost1_80]

 

[Matthew Kennedy]

You got it. Note that the arrow operators do exactly the same thing as the before and require metaparameters so you could have add one of those to one of the resources. Personally when a manifest has resources that are more serial or scripty I prefer the obvious expression adding a chain of ->'d resources had.

--

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 puppet-users...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/d53e3826-43fc-42ef-86cb-1a3bf4649efc%40googlegroups.com.