Added documentation on handling multiple php-fpm service restarts when provisioning multiple FPM pools. This serves as an addendum to PR 365 and a RFC at once.
While the change in PR 365 was not entirely incorrect (default :delayed notification :timer was explicitly set), it did not address the issue at all.
After investigating the problem further and testing a working solution, I’d like to share my findings.
Since chef-client v18,unified_mode true is the default setting for custom resources.
With unified_mode true enabled:
Single-phase Execution: Properties and actions are unified, meaning that everything inside the resource (properties, actions, notifications) is evaluated in one continuous phase.
End-of-Action Notifications: Notifications set as :delayed within a custom resource action (like action :install) are queued to be processed once the action completes, rather than waiting until the end of the Chef client run.
This means that my previous assertion in PR 365 was incorrect. Although the service resource notification was indeed set to :delayed, due to unified_mode true it was triggered at the end of the action :install block within the fpm_pool resource, not at the end of the chef-client run.
Documentation has been added; feedback is welcome.
Issues Resolved
Caveat and possible Workaround for managing multiple FPM pools documented.
Check List
[-] A summary of changes made is included in the CHANGELOG under ## Unreleased
[-] New functionality includes testing.
[-] New functionality has been documented in the README if applicable.
kitchen-porter
commented
2 weeks ago
Description
Added documentation on handling multiple php-fpm service restarts when provisioning multiple FPM pools. This serves as an addendum to PR 365 and a RFC at once.
While the change in PR 365 was not entirely incorrect (default
:delayednotification:timerwas explicitly set), it did not address the issue at all.After investigating the problem further and testing a working solution, I’d like to share my findings.
Since
chef-client v18,unified_mode true is the default setting for custom resources.With
unified_mode trueenabled::delayedwithin a custom resource action (likeaction :install) are queued to be processed once the action completes, rather than waiting until the end of the Chef client run.This means that my previous assertion in PR 365 was incorrect. Although the service resource notification was indeed set to
:delayed, due tounified_mode trueit was triggered at the end of theaction :installblock within thefpm_poolresource, not at the end of thechef-clientrun.Documentation has been added; feedback is welcome.
Issues Resolved
Caveat and possible Workaround for managing multiple FPM pools documented.
Check List
## Unreleased