Param bizarreness when nesting defines


#1

Okay, y’all, here’s an odd one:

I have my local runit recipe patched to configure svlogd-emitted log files
as sources for remote logging. The obvious implementation is such:

logged_file “#{sv_dir_name}/log/main/current” do
tag "sv-#{params[:name]}"
end

However, when doing so, the tag gets instantiated as “sv-”

If, however, I do the following:

sv_name = params[:name]
logged_file “#{sv_dir_name}/log/main/current” do
tag "sv-#{sv_name}"
end

all works properly.

WTF?!


#2

I can confirm that issue. Here is what failed for us:

iptables_rule “mysql_internal” do
variables :mysql_ip => internal_ip(node)
end

It works, if I do it like this:

mysql_ip = internal_ip(node)
iptables_rule “mysql_internal” do
variables :mysql_ip => mysql_ip
end

Can anyone shed any light on this one? It’s an ugly pitfall

  • Matthias

I have my local runit recipe patched to configure svlogd-emitted log files as sources for remote logging. The obvious implementation is such:

logged_file “#{sv_dir_name}/log/main/current” do
tag "sv-#{params[:name]}"
end

However, when doing so, the tag gets instantiated as “sv-”

If, however, I do the following:

sv_name = params[:name]
logged_file “#{sv_dir_name}/log/main/current” do
tag "sv-#{sv_name}"
end

all works properly.

WTF?!


#3

On 19 January 2011 04:53, Matthias Marschall mm@agileweboperations.com wrote:

I can confirm that issue. Here is what failed for us:

iptables_rule “mysql_internal” do
variables :mysql_ip => internal_ip(node)
end

It works, if I do it like this:

mysql_ip = internal_ip(node)
iptables_rule “mysql_internal” do
variables :mysql_ip => mysql_ip
end

Can anyone shed any light on this one? It’s an ugly pitfall

  • Matthias

I believe this is known - the contents of the define are replaced with
the definitions contents (directly) so nested definitions always
clobber eachother.

Use an lwr/p

I have my local runit recipe patched to configure svlogd-emitted log files as sources for remote logging. The obvious implementation is such:

logged_file “#{sv_dir_name}/log/main/current” do
tag "sv-#{params[:name]}"
end

However, when doing so, the tag gets instantiated as “sv-”

If, however, I do the following:

sv_name = params[:name]
logged_file “#{sv_dir_name}/log/main/current” do
tag "sv-#{sv_name}"
end

all works properly.

WTF?!


#4

On Jan 19, 2011, at 10:56 AM, AJ Christensen wrote:

Use an lwr/p

I hear this allot now. Are there any good examples of LWRP’s using templates, services, etc? There seems to be a gap between the limitations of a define and the “must do everything by hand” nature of an LWRP.

–Brian


#5

On Wed, Jan 19, 2011 at 4:34 PM, Brian Akins brian@akins.org wrote:

Use an lwr/p

I hear this allot now. Are there any good examples of LWRP’s using
templates, services, etc? There seems to be a gap between the limitations
of a define and the “must do everything by hand” nature of an LWRP.

Example of a LWRP that uses Chef resources directly:

https://github.com/opscode/cookbooks/blob/master/daemontools/providers/service.rb

See the enable action.


Opscode, Inc
Joshua Timberman, Technical Evangelist
IRC, Skype, Twitter, Github: jtimberman


#6

On Jan 19, 2011, at 6:47 PM, Joshua Timberman wrote:

Example of a LWRP that uses Chef resources directly:

https://github.com/opscode/cookbooks/blob/master/daemontools/providers/service.rb

See the enable action.

Nice.

So, if I wanted this service to be able to notify others ( by calling new_resource.updated_by_last_action(true), right?) how could I know if the directory, for example, got created, so I’d want to pass that notify up? Asked another way: how do I pass along the updated status of the underlying resources if I use them in an LWRP.

Thanks for the example, it points me in the right direction, at least.

–Brian


#7

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Jan 20, 2011, at 5:38 PM, Brian Akins wrote:

So, if I wanted this service to be able to notify others ( by calling new_resource.updated_by_last_action(true), right?) how could I know if the directory, for example, got created, so I’d want to pass that notify up? Asked another way: how do I pass along the updated status of the underlying resources if I use them in an LWRP.

They’re just resources, so they can be accessed like any others through a notification handler. You’d need to use subscribes.

daemontools_service “my_service” do
directory "/etc/service/my_service"
end

file “/tmp/i_got_updated_by_a_directory” do
subscribes :create, "directory[/etc/service/my_service]"
end

However, I probably wouldn’t do that, and instead notify/subscribe the LWRP resource.


Opscode, Inc
Joshua Timberman, Technical Evangelist
IRC, Skype, Twitter, Github: jtimberman

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (Darwin)

iEYEARECAAYFAk04/lMACgkQO97WSdVpzT3VwQCgjpka6nIz8ddjE8NV0JhmNqg9
Jh4An0NRyvkFV1QkqjBg9+D1GakE0suC
=aYT/
-----END PGP SIGNATURE-----