Notifications from an aggregate LWRP

Chef Infra (archive)
1

I am working on what I’ll call an aggregate LWRP: it aggregates a number of
subresources so that they can be treated as one. In my example the provider
installs a package, creates a directory, and builds a couple of config
files from templates, by using the resource DSL in the provider’s action
method. However I’m struggling to get notifications from the aggregate
resource working. It seems like this would be a common pattern, but I
haven’t found any examples that deal with the notification problem. I’ve
tried a few different approaches:

  1. In the action method of my provider, adding the subresources to an
    array, then iterating over the subresources’ updated? methods at the end of
    the action method to determine whether or not to call
    new_resource.updated_by_last_action(true).
  2. Same as number 1, but iterating in a ruby_block which is the final
    subresource, to defer the updated? checks from compile time to execution
    time.
  3. Defining a ruby_block subresource with action :nothing, and sending
    it a :create notification from the subresources, then relying on the
    ruby_block to call new_resource.updated_by_last_action(true).

None of these approaches result in subscribers to the aggregate resource
being notified when a subresource is updated. This has left me with the
following questions:

  1. Is there an example of such an aggregate resource and its provider
    that someone could point me to?
  2. Is there a better way to accomplish my goal (notification when any of
    a group of resources is updated, without the subscriber having to know
    about each of the grouped resources)?
  3. Does this comment on line 67 of provider.rb (Chef 0.10.8) explain why
    notifications don’t seem to escape my aggregate resource: “…resources
    within this block cannot interact with resources outside, e.g.,
    manipulating notifies”, and if so, how can I get around this limitation?

Thanks,

Kevin Christen

2

Haven't tried it, but it might work:

In your lwrp, create and action 'send notification' , and when you create a sub resources subscribe your new resource to execute this action.
The body of this action would only include calling the updated_by_last action.

On Feb 12, 2012, at 11:51 AM, Kevin Christen kevin.christen@gmail.com wrote:

I am working on what I'll call an aggregate LWRP: it aggregates a number of subresources so that they can be treated as one. In my example the provider installs a package, creates a directory, and builds a couple of config files from templates, by using the resource DSL in the provider's action method. However I'm struggling to get notifications from the aggregate resource working. It seems like this would be a common pattern, but I haven't found any examples that deal with the notification problem. I've tried a few different approaches:
In the action method of my provider, adding the subresources to an array, then iterating over the subresources' updated? methods at the end of the action method to determine whether or not to call new_resource.updated_by_last_action(true).
Same as number 1, but iterating in a ruby_block which is the final subresource, to defer the updated? checks from compile time to execution time.
Defining a ruby_block subresource with action :nothing, and sending it a :create notification from the subresources, then relying on the ruby_block to call new_resource.updated_by_last_action(true).
None of these approaches result in subscribers to the aggregate resource being notified when a subresource is updated. This has left me with the following questions:
Is there an example of such an aggregate resource and its provider that someone could point me to?
Is there a better way to accomplish my goal (notification when any of a group of resources is updated, without the subscriber having to know about each of the grouped resources)?
Does this comment on line 67 of provider.rb (Chef 0.10.8) explain why notifications don't seem to escape my aggregate resource: "...resources within this block cannot interact with resources outside, e.g., manipulating notifies", and if so, how can I get around this limitation?
Thanks,

Kevin Christen

3

Andi,

That did the trick. For anyone listening along, in my subresource:

notifies :send_notification, new_resource, :immediately

and in my LWRP:

action :send_notification do
new_resource.updated_by_last_action(true)
end

Then subscribers to my aggregate LWR get notified only if the subresource
changes, and they get notified according to their own declared timing.

Thanks for the help,
Kevin Christen

On Sun, Feb 12, 2012 at 11:05 AM, Andiabes andi.abes@gmail.com wrote:

Haven't tried it, but it might work:

In your lwrp, create and action 'send notification' , and when you create
a sub resources subscribe your new resource to execute this action.
The body of this action would only include calling the updated_by_last
action.

On Feb 12, 2012, at 11:51 AM, Kevin Christen kevin.christen@gmail.com
wrote:

I am working on what I'll call an aggregate LWRP: it aggregates a number
of subresources so that they can be treated as one. In my example the
provider installs a package, creates a directory, and builds a couple of
config files from templates, by using the resource DSL in the provider's
action method. However I'm struggling to get notifications from the
aggregate resource working. It seems like this would be a common pattern,
but I haven't found any examples that deal with the notification problem.
I've tried a few different approaches:

  1. In the action method of my provider, adding the subresources to an
    array, then iterating over the subresources' updated? methods at the end of
    the action method to determine whether or not to call
    new_resource.updated_by_last_action(true).
  2. Same as number 1, but iterating in a ruby_block which is the final
    subresource, to defer the updated? checks from compile time to execution
    time.
  3. Defining a ruby_block subresource with action :nothing, and sending
    it a :create notification from the subresources, then relying on the
    ruby_block to call new_resource.updated_by_last_action(true).

None of these approaches result in subscribers to the aggregate resource
being notified when a subresource is updated. This has left me with the
following questions:

  1. Is there an example of such an aggregate resource and its provider
    that someone could point me to?
  2. Is there a better way to accomplish my goal (notification when any
    of a group of resources is updated, without the subscriber having to know
    about each of the grouped resources)?
  3. Does this comment on line 67 of provider.rb (Chef 0.10.8) explain
    why notifications don't seem to escape my aggregate resource: "...resources
    within this block cannot interact with resources outside, e.g.,
    manipulating notifies", and if so, how can I get around this limitation?

Thanks,

Kevin Christen