docs: describe caveat and workaround for multiple fpm pools

[igolman]

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 :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]

Released as: 10.2.2