On Monday, September 2, 2013 5:57:44 AM UTC-5, kashif wrote:
>
>
> Hi
> I am using create_resource to create a dir and then mount it. I am using
> two create_resources and want one to be completed before other.
>
> $mount_point = hiera('test::mount_point', [])
> $defaults = {
> 'ensure' => 'directory',
> }
> $mountit = hiera('test::mountit')
> create_resources (file, $mount_point, $defaults)
> create_resources (mount, $mountit)
>
> hiera_yaml is
>
> test::mount_point:
> '/local_area':
> owner: root
> group: root
> mode: 0644
>
> test::mountit:
> '/local_area':
> device : "mymachine:/software"
> fstype : "nfs"
> ensure : "mounted"
> options : "nfsvers=3,tcp,noatime,hard,intr,exec,rw,bg,nosuid"
> atboot : true
> # require : [ File['/local_area'] ],
>
>
> It works if I comment out require line but fail with this error if I
> un-comment require line
>
> Error: Failed to apply catalog: Could not find dependency
> File['/local_area'] for Mount[/local_area]
>
I didn't think it was possible to record resource references in an Hiera
data file. Or more precisely, I *know* YAML has no concept of resource
references, and I don't think either Hiera itself or create_resources() has
any special tooling to convert strings that have the form of resource
references into bona fide resource references.
>
> Is there any other way to chain two create_resources statements ?
>
>
You cannot chain function calls because they happen during catalog
compilation, not during catalog application. You can declare resource
relationships after the fact, however, with the chaining operator:
File['/local_area'] -> Mount['/local_area']
That you are using create_resources() (why?) suggests that you may not want
to put explicit chains such as that into your manifests, but there are a
number of ways to deal with that. For example, if you can rely on all the
mount titles to be the mount point names (i.e. you are not specifying any
'name' parameters for the mounts) then you can extract the mount point list
via the keys() function provided by puppetlabs-stdlib. You can then use a
defined type to declare the needed relationships:
class site::mounts1 {
# ...
$mount_points = keys($mountit)
site::mountpoint_relationship { $mount_points: }
}
define site::mountpoint_relationship() {
File[$name] -> Mount[$name]
}
But you can do better than that. Supposing that you want all your mount
point directories to be configured the same (since they will be invisible
anyway when the remote FS is mounted), why do you need to describe them
separately in your hiera data? Moreover, wouldn't it make sense to better
connect declaration of the mount with declaration of the mount point? To
do that, just extend the scope of the definition to encompass full
declaration of mount and mount point, based on the data for the mount.
Here's one slightly roundabout way to do that:
class site::mounts2 {
# ...
$mount_points = keys($mountit)
site::mountpoint { $mount_points: mount_data => $mountit }
}
define site::mountpoint($mount_data) {
# Declare one Mount
$my_mount_data = { $name => $mount_data[$name] }
create_resources('mount', $my_mount_data)
# Declare its mount point
file { $name:
ensure => 'directory',
owner => 'root',
group => 'root',
mode => '0755',
# declare the relationship here
before => Mount[$name]
}
}
I don't particularly like using create_resources() there, but it helps
highlight both the similarities with and the differences from your starting
point, and it simplifies the code for dealing with the parameters. If you
don't like the details then I'm sure you can come up with several
variations on the same theme.
John
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/cf04a684-fce9-4a8f-8311-38445b105693%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
