Hash Access... Frustrating!

[Douglas Garstang]

Boy... accessing hashes in puppet is downright painful.

I have this in a yaml file...

glusterfs_volumes:
gfsvol01:
master_node: gfs01.us1.xxx.com
transport: tcp
replicas: 0
nodes:
- gfs01.us1.xxx.com
hostname: gfs01
state: mounted
- gfs02.us1.xxx.com
hostname: gfs02
state: unmounted
- gfs03.us1.xxx.com
hostname: gfs03
state: mounted

I'm loading it with:

$config = hiera('glusterfs_volumes')
$nodes = $config['gfsvol01']['nodes']
... etc

Works fine. I'm also calling a definition like this:

glusterfs::add_bricks {
[$nodes]:
master_node => "$master_node",
brick_store => "$brick_store",
volume_name => "$name",
require => Glusterfs::Add_peers[$nodes];
}

The question is, how do I access the hostname and state keys inside each node?

The following (inside add_bricks):

$node = $name['hostname']
notice ("DEBUG nodes=$name")
notice ("DEBUG NODE=$node")

yields, for each call to add_bricks:

DEBUG nodes=statemountedgfs01.us1.xxx.com hostnamegfs01
DEBUG NODE=

I can see the hash in $name... I just can't access the 'state' or
'hostname' keys, which are obviously there.

How...?

Doug.

[jcbollinger]

Resource names are strings.  If you try to use a hash as a resource name then it will be flattened.

Generally speaking, you have several options: you could load the hash into a class variable, and have your definitions access it from there.  You could also pass it as a parameter to your definition.  You could even have the definition load it (again) via hiera.  Sometimes the create_resources() function is convenient for unpacking a hash of hashes.

I'm afraid I cannot recommend any specifics to you, however, because your YAML is not valid (according to http://yaml-online-parser.appspot.com/ and my own eyes), so I don't know what the data structure is supposed to be.  It looks like something based on create_resources() might work out nicely for you, but I can't be sure.


John

[Douglas Garstang]

Having fixed the yaml...

glusterfs_volumes:
gfsvol01:
master_node: gfs01.us1.xxx.com
transport: tcp
replicas: 0
nodes:

- name: gfs01.us1.xxx.com
bricks:
- /var/bricks/b1
- name: gfs02.us1.xxx.com
bricks:
- /var/bricks/b2
- name: gfs03.us1.xxx.com
bricks:
- /var/bricks/b3

The issue is now.... how do I iterate over the nodes? They are no
longer an array. They are an array of hashes, which puppet doesn't
want to iterate over.

Doug.

> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/puppet-users/-/cS8_5qGpd8wJ.
> 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.



--
Regards,

Douglas Garstang
http://www.linkedin.com/in/garstang
Email: doug.g...@gmail.com
Cell: +1-805-340-5627

[Douglas Garstang]

It looks like it's flattening the darned thing out... :(

err: Could not retrieve catalog from remote server: Could not intern
from pson: Could not convert from pson: Could not find relationship
source "Glusterfs::Add_peers[bricks/var/bricks/b3namegfs03.us1.xxx.com]"

:(

[Jenner La Fave]

You still can't use anything other than a string as a resource title. Since you're passing an array of hashes, it's being converted to a string, specifically by Puppet::Resource::Type#set_name_and_namespace, which does @name = name.to_s.downcase.

In your case, you'll probably want to use the create_resources function (http://docs.puppetlabs.com/references/stable/function.html#createresources). Something like 

$config = hiera('glusterfs_volumes') 

create_resources(glusterfs::add_brick, $config['gfsvol01']['nodes'])

might work.

-- Jenner

[Douglas Garstang]

Thanks. I'll check it out. Does anyone know where the docs for this
are? All the links on the puppet web site are broken for
create_resources.

Doug.

> https://groups.google.com/d/msg/puppet-users/-/EVvYyUf5qxcJ.

[Douglas Garstang]

Oops. There's a working link.... right there...

On Tue, Aug 28, 2012 at 7:38 PM, Douglas Garstang