[chef] Re: Re: Using data generated in a LWRP

[Nick Peirson < >]

On 06/04/2012 07:36, Andrea Campi wrote:

> I've done a spike on my idea and it looks doable. However, that made
> me think harder and I'm not sure it's such a great idea.
>
> Say you have resources A and B that both notify resource C.
> At the risk of over-generalizing, I'm assuming C may then respond
> differently based on who notified it.
> The consequence then is that C will likely not be idempotent.
>
> As another way to look at it, imagine the run fails between the moment
> A triggers it and when C runs.
> On the next run, C will not be notified and will likely do nothing.
> There are a bunch of assumptions in here, but in general, you don't want this.
>
> In your case, I would create a node attribute with your RDS endpoint.
> C could then be written in an idempotent way; for example, it would
> somehow notice that the address has changed on one or more resource,
> and do its thing.
>
> Hand-waving aside, would this make sense for you?
>
> Andrea
I'm more interested in subscribing to my RDS action than notifying it in my
current use case. Let me try and clarify my use case.

I've got an RDS LWRP. It has a create action which tests for the existence of
the RDS instance before trying to create it.

Whether it's created it or not, I'm currently setting an attribute(?) on
node.run_state to contain a hash containing data about the RDS instance and
set updated_by_last_action to true. If I'm unable to create or find the
instance, I raise an exception (or let it bubble up from the underlying RDS
class), however I suppose I could change this to just not set
updated_by_last_action to true.

I don't want to persist the RDS data on the node as RDS doesn't run on a node
like, for example, MySQL does. It's not specific to a node and it's feasible
that the recipe could be run from multiple nodes. If I could run chef on an
RDS instance, life would be much simpler :) Maybe looking at other use cases
where chef is controlling resources that aren't on the node itself would help
determine the best way to handle this situation?

As it stands, I instead use the information on node.run_state to update a
data bag with the current details from the RDS LWRP create action. Using the
solution you described I could subscribe to the notification from the
creation of the RDS instance and use the information directly from the
notification object, which seems more explicit.

In practice I could make my RDS LWRP write immediately to a data bag, however
I'm aiming for nicely decoupled, re-usable components, which I've achieved to
some extent. Thanks to the help from this list, I've got a workaround by
(ab)using node.run_state. My opinion is if your solution was implemented then
it gives the potential of producing cleaner code, but if it doesn't get
implemented I still have a working solution.

Thanks
Nick