Currently users must specify the notify clone meta-attribute to true to get clone notifications. It's unlikely anyone disables notifications intentionally (which would be worth some investigation), so we should probably default to sending notifications whenever a resource is cloned and its resource agent supports notify.

We could change the meta-attribute default to true (and potentially deprecate it), or we could drop the meta-attribute and rely on the notify action's enabled meta-attribute to decide whether to send notifications (potentially with an XSL transform to preserve the existing configuration's behavior).

This would change behavior of existing configurations, so it should be done at a major version bump.

Implementation

The scheduler doesn't know resource agent capabilities, nor is there a good way to pass them to it, so the likely implementation would be for the scheduler to always schedule notify actions for clones, and have the controller treat them as no-ops if the agent doesn't support them.

This would make transition graphs unnecessarily larger when the agent doesn't support notify, so we would have to check what difference it makes in a large cluster with multiple clones.