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

[Bryan Berry < >]

I second fujin, except u have two options on where to store it

I have run into this same issue w/ my tomcat cookbook

You can store it on the node or you can store it on the run_state object

the node object will be persisted to the main chef repository. If you add too much to the node object, you could end up w/ a lot of crap in your couchdb.

the run_state object is not persisted to couchdb, this makes it ideal for storing passwords or anything you don't want or need persisted to the chef repository

On Tue, Apr 3, 2012 at 8:55 AM, 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