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

[AJ Christensen < >]

I was thinking further about this and thought I'd mention that the
node has a 'run_state' hash that you can chuck stuff into and access
throughout compile time. It will not make it into the node data, but
is fine for temporal (or calculated) data that exists the length of
the run.

node.run_state[:foo] = 'bar'

HTH

--AJ

On 3 April 2012 18:55, AJ Christensen 
<
 >
 wrote:
> I'd suggest storing the data you are receiving from AWS in the node.
> You could (with a bit of fiddling) probably store it in a data-bag
> too, although it would have to be pre-created so machines can update
> it.
>
> The elastic block device LWRP has an example of the former.
>
> Cheers,
>
> --AJ
>
> On 3 April 2012 18:53, Andrea Campi 
> <
 >
>  wrote:
>> On Mon, Apr 2, 2012 at 7:21 PM, Nick Peirson 
>> <
 >
>>  wrote:
>>> Hi all,
>>>
>>> I've only been using chef for a couple of months, so bear with me if I
>>> mangle the terminology :)
>>>
>>> I've got a LWRP that's creating an AWS RDS instance. Within the LWRP I 
>>> wait
>>> till the RDS instance becomes available (while loop + sleep) and get it's
>>> details, of which I'm particularly interested in the endpoint address. I 
>>> can
>>> log this by doing something along the lines of:
>>>
>>> Chef::Log.info("RDS endpoint address is 
>>> #{rds_instance[:endpoint_address]}")
>>>
>>> What I now want to do is subscribe to the resource that's using this
>>> provider to create the rds_instance and for the subscribing resource to 
>>> have
>>> the rds_instance object available, particularly the endpoint address. The
>>> subscribing resource is then going to connect to the RDS instance create a
>>> database, set up some permissions, etc.
>>>
>>> Is there a way to pass this information, e.g. something along the lines of
>>> making the rds_instance object available? If not, my other thought is to
>>> store it on the node or in a data bag, but this seems like a hack to get
>>> round a limitation that's only there due to my lack of knowledge.
>>
>> The interesting thing is that the Notification object (which is used
>> to keep track of queued notifications) holds a reference to resource
>> that triggered the notification.
>> You can see that in the logs:
>>
>>        Chef::Log.info( "#{notification.notifying_resource} sending
>> #{notification.action}"\
>>                        " action to #{notification.resource} (delayed)")
>>
>> However when it's time to call run_action, that reference is dropped.
>>
>> We could store a reference to either the Notification or
>> notification.notifying_resource in the run_context, so that the
>> notified resource could access it.
>> I don't see a real downside here, and it.
>>
>> Thoughts?
>>
>>
>> Andrea