Bug when using array in file resource?

[Justin Lloyd]

I'm trying to use an array on a file resource to create symlinks. If I have multiple elements in the array, I get a redefinition error showing it's replacing $name or $title with the CLASS name rather than the RESOURCE name. Here's a simplified example using one array element, where I'd expect to end up with /tmp/link.a pointing to /etc/motd. Notice it says it created the file with the element name but the filename actually contains the class name:

root@ops-puppet02:/tmp# cat test.pp
class foo {
    file { [ 'a' ]:
        ensure => link,
        path   => "/tmp/link.${name}",
        target => "/etc/motd",
    }
}
include foo

root@ops-puppet02:/tmp# puppet apply test.pp
notice: /Stage[main]/Foo/File[a]/ensure: created
notice: Finished catalog run in 0.02 seconds

root@ops-puppet02:/tmp# ls -l link*
lrwxrwxrwx 1 root root 9 2012-02-13 17:12 link.foo -> /etc/motd

If I change the array from [ 'a' ] to [ 'a', 'b' ], then given the above logic it will attempt to redefine, leading to this output:

Cannot alias File[b] to ["/tmp/link.foo"] at /tmp/test.pp:6; resource ["File", "/tmp/link.foo"] already defined at /tmp/test.pp:6

Seems like a bug, but maybe I'm missing something. Suggestions?

Justin

--
“We don’t need to increase our goods nearly as much as we need to scale down our wants. Not wanting something is as good as possessing it.” -- Donald Horban

[Justin]

Forgot to mention I'm running Puppet 2.7.10 on Ubuntu 10.04.3.

[Nan Liu]

On Mon, Feb 13, 2012 at 3:21 PM, Justin Lloyd <jst...@gmail.com> wrote:
> I'm trying to use an array on a file resource to create symlinks. If I have
> multiple elements in the array, I get a redefinition error showing it's
> replacing $name or $title with the CLASS name rather than the RESOURCE name.
> Here's a simplified example using one array element, where I'd expect to end
> up with /tmp/link.a pointing to /etc/motd. Notice it says it created the
> file with the element name but the filename actually contains the class
> name:
>
> root@ops-puppet02:/tmp# cat test.pp
> class foo {
>     file { [ 'a' ]:
>         ensure => link,
>         path   => "/tmp/link.${name}",
>         target => "/etc/motd",
>     }
> }

$name is not the file resource title 'a'.

> include foo
>
> root@ops-puppet02:/tmp# puppet apply test.pp
> notice: /Stage[main]/Foo/File[a]/ensure: created
> notice: Finished catalog run in 0.02 seconds
>
> root@ops-puppet02:/tmp# ls -l link*
> lrwxrwxrwx 1 root root 9 2012-02-13 17:12 link.foo -> /etc/motd
>
> If I change the array from [ 'a' ] to [ 'a', 'b' ], then given the above
> logic it will attempt to redefine, leading to this output:
>
> Cannot alias File[b] to ["/tmp/link.foo"] at /tmp/test.pp:6; resource
> ["File", "/tmp/link.foo"] already defined at /tmp/test.pp:6
>
> Seems like a bug, but maybe I'm missing something. Suggestions?

It's not a bug per se, but rather you need to create a define type.

define my_symlink {
file { $name:
ensure => symlink,

path => "/tmp/link.${name}",
target => '/etc/motd',
}
}

and then

my_symlink { ['a', 'b']: }

HTH,

Nan

[Justin Lloyd]

I was wondering if I'd need to create a define() but the language guide's description seems misleading, at least to me. From the 6th paragraph of the Resources section:

http://docs.puppetlabs.com/guides/language_guide.html#resources

The field before the colon is the resource’s title, which must be unique and can be used to refer to the resource in other parts of the Puppet configuration.

--
You received this message because you are subscribed to the Google Groups "Puppet Users" group.
To post to this group, send email to puppet...@googlegroups.com.
To unsubscribe from this group, send email to puppet-users...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.

[Nan Liu]

On Mon, Feb 13, 2012 at 3:37 PM, Justin Lloyd <jst...@gmail.com> wrote:
> I was wondering if I'd need to create a define() but the language guide's
> description seems misleading, at least to me. From the 6th paragraph of the
> Resources section:
>
> http://docs.puppetlabs.com/guides/language_guide.html#resources
>
> The field before the colon is the resource’s title, which must be unique and
> can be used to refer to the resource in other parts of the Puppet
> configuration.

You can refer to the title of the resource in a defined type as $name,
you can't use $name when you declare a resource. This page explains in
further detail about the unique constraint:

http://docs.puppetlabs.com/learning/definedtypes.html

HTH,

Nan

[Justin Lloyd]

Ok, thanks for the tip.

HTH,

Nan

--
You received this message because you are subscribed to the Google Groups "Puppet Users" group.
To post to this group, send email to puppet...@googlegroups.com.
To unsubscribe from this group, send email to puppet-users...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.

[pdurkin]

I'm not convinced that Justin wasn't correct about this being a bug.  I'm having a similar issue

class myclass (...) {

  # some extra stuff here

  $file_list = [ 'a', 'b' ..., 'n' ]
  file { $file_list :
       ensure => 'file',
       source => "puppet://modules/myclass/$title",
       path   => "/tmp/$title"
      }

results in the "cannot alias file [a] to [/tmp/myclass]".  For some reason the resource title in my file is resolving to the class name rather than the file name.

The solution provided above seems to change the semantics.  myclass becomes a defined type instead and the list of files is moved outside and passed in as multiple instances are created.  That's a work around.

Another would be to not use a list and simply define each file separately in the class, that avoids having to use the $title to abstract the definition into a single resource definition.  I can do that quite easily but in my case I have about 100 files so it makes this much less readable.  Found someone had already explained the issue here: http://www.nico.schottelius.org/blog/puppet-name-is-not-as-expected-but-classname/.

Does anyone have an answer as to why $title in this case is resolving to the class title rather than the resource title?  Is that expected and is there a variable I could use instead that would resolve to the name of the resource I'm declaring rather than the class or defined type I'm declaring it in?

I also tested this and it's not to do with the list, if I use put in each file individually and use $title or $name it still resolves to the class name

thanks

Paul

[Benjamin Priestman]

I had trouble with this one, too.

 

The documentation also made me think I could do something like this, but I think this is a lack of clarity in the documntation, not a code bug. $title or $name (they seem to get used interchangeably) always seem to refer to the $name or $title of the class or type they are in, not the name of a resource within a class or type. In a recent project, I ended up creating four layers of chained defined types in order to model a set of websites with similar but varying features.

 

This also means that when you pass an array of items to a defined type, you need to make sure that it can construct evrything that's different about each instance of your resource from just the array you pass in as the resource's name. I think the key here is that you can't access $title/$name from outside a resource/class/type but only from inside.

 

In later versions of puppet and/or with the stdlib module, you can also use the create_resources function to create a bunch of resources from an array.

 

Ben

[jcbollinger]

On Monday, November 5, 2012 12:37:45 AM UTC-6, pdurkin wrote:

I'm not convinced that Justin wasn't correct about this being a bug.  I'm having a similar issue

How many people do you need to tell you that the behavior you observe is intended?  File a ticket against the documentation if you like, but the behavior is as designed, well-entrenched, broadly relied-upon, and useful.

 

class myclass (...) {

  # some extra stuff here

  $file_list = [ 'a', 'b' ..., 'n' ]
  file { $file_list :
       ensure => 'file',
       source => "puppet://modules/myclass/$title",
       path   => "/tmp/$title"
      }

results in the "cannot alias file [a] to [/tmp/myclass]".  For some reason the resource title in my file is resolving to the class name rather than the file name.

Yes.  That's as it should be.  Variables are always resolved in the innermost scope in which they appear.  Other than the top-level scope, scopes are established only by node bocks, definition bodies, and class bodies.  In particular, they are not established by resource declarations such as your example file declaration.  Nor is there a functionality gap -- Nan already explained how to get the behavior you want.

 

The solution provided above seems to change the semantics.  myclass becomes a defined type instead and the list of files is moved outside and passed in as multiple instances are created.  That's a work around.

You are hypothesizing an implementation to criticize, instead of considering how to model your problem in a way that harmonizes with Puppet.  Consider this:

define mymodule::modulefile() {
  file { $name :
    ensure => 'file',
    source => "puppet:///mymodule/$name",

    path   => "/tmp/$name"
  }
}

class mymodule::myclass {

  $file_list = [ 'a', 'b' ..., 'n' ]

  mymodule::modulefile { $file_list : }
}

Your class remains a class, and continues to define the file list itself.  The definition 'mymodule::modulefile' represents a type of file that has the particular relationship you want between its 'path' and 'source'.
 

Another would be to not use a list and simply define each file separately in the class, that avoids having to use the $title to abstract the definition into a single resource definition.  I can do that quite easily but in my case I have about 100 files so it makes this much less readable.  Found someone had already explained the issue here: http://www.nico.schottelius.org/blog/puppet-name-is-not-as-expected-but-classname/.

Does anyone have an answer as to why $title in this case is resolving to the class title rather than the resource title?  Is that expected and is there a variable I could use instead that would resolve to the name of the resource I'm declaring rather than the class or defined type I'm declaring it in?

I also tested this and it's not to do with the list, if I use put in each file individually and use $title or $name it still resolves to the class name

Look at it another way: if you were invoking a function, would you expect variable references among the parameters to be resolved by the caller or by the function?  They are resolved by the caller, of course.  Resource declarations are not function calls, but they work analogously in this regard.


John

[pdurkin]

Thanks John, I'll inline my responses

Paul

On Monday, November 5, 2012 6:26:55 PM UTC+4, jcbollinger wrote:

On Monday, November 5, 2012 12:37:45 AM UTC-6, pdurkin wrote:

I'm not convinced that Justin wasn't correct about this being a bug.  I'm having a similar issue

How many people do you need to tell you that the behavior you observe is intended?  File a ticket against the documentation if you like, but the behavior is as designed, well-entrenched, broadly relied-upon, and useful.

I think I understand where my confusion comes from.  I read the same document as Justin, at: http://docs.puppetlabs.com/guides/language_guide.html the section on Resources states " Resources describe some aspect of a system; it might be a file, a service, a package" then further in the same section: "Most resources have an attribute (often called simply name) whose value will default to the title if you don’t specify it. (Internally, this is called the “namevar.”) For the file type, the path will default to the title".  It uses "name", "title" and "namevar" but these are not referring to variables but to attributes and parts of the resource.  They are referred to later as variables on the same page but only in respect to defined resources and classes, so I guess that is why I assumed they were variables everywhere.

In answer to your question of how many people, so far you are the first to say it is intended and a misinterpretation of the documentation.  Nans post simply said that $name is not the file resource title, nothing about intentions or design, and I'm obviously not alone on my misinterpretation of the documentation since this thread and the blog post both have the same point.

 

class myclass (...) {

  # some extra stuff here

  $file_list = [ 'a', 'b' ..., 'n' ]
  file { $file_list :
       ensure => 'file',
       source => "puppet://modules/myclass/$title",
       path   => "/tmp/$title"
      }

results in the "cannot alias file [a] to [/tmp/myclass]".  For some reason the resource title in my file is resolving to the class name rather than the file name.

Yes.  That's as it should be.  Variables are always resolved in the innermost scope in which they appear.  Other than the top-level scope, scopes are established only by node bocks, definition bodies, and class bodies.  In particular, they are not established by resource declarations such as your example file declaration.  Nor is there a functionality gap -- Nan already explained how to get the behavior you want.

 

The solution provided above seems to change the semantics.  myclass becomes a defined type instead and the list of files is moved outside and passed in as multiple instances are created.  That's a work around.

You are hypothesizing an implementation to criticize, instead of considering how to model your problem in a way that harmonizes with Puppet.  Consider this:

define mymodule::modulefile() {
  file { $name :
    ensure => 'file',
    source => "puppet:///mymodule/$name",

    path   => "/tmp/$name"
  }
}

class mymodule::myclass {
  $file_list = [ 'a', 'b' ..., 'n' ]
  mymodule::modulefile { $file_list : }
}

Your class remains a class, and continues to define the file list itself.  The definition 'mymodule::modulefile' represents a type of file that has the particular relationship you want between its 'path' and 'source'.
 

Yes, you are correct, sorry.  I'm not trying to hypothesize, I didn't find Nans solution as clear as you have written it here.  It seemed to me that he was suggesting rewriting the class as a defined type rather than creating a new defined type and using it in the class.  The solution provided uses a defined type to create a new scope so that the variable 'name' gets the value required.  Name can then be used in the resource declaration as I tried to do it directly in the class.

It's a pity there's no way to refer to the title of a resource in the declaration since that would be a more concise (and presumably then clearer) way to have defined all the files.  I understand your analogy below about functions and resource declarations however I'm not yet adept enough with puppet to start recognising how it is implemented, for the moment I'm still having to read documentation and ask questions.