>
> Hi All,
>
> So here's my use case:
>
> I've got an application with multiple environments, say live, qa and dev,
> and each environment has multiple servers. The actual application requires
> an NFS mount mounted on each of these servers. Each environment has it's
> own NFS drive.
> I also have a management server which needs to mount all these NFS drives
> of every environment.
>
> I use a mount resource included on each environment server to mount each
> NFS drive, with the help of an $environment variable, which points it to
> the right share on the NFS server, which is all working fine.
>
> Now I want to puppetize the mounts of all NFS shares on the management
> server as well, so I thought of using something like this in the actual
> environment server manifest:
>
> @@mount { mgmtnfs-$environment:
> name => "/$path-$environment"
> fstype => "nfs"
> }
>
> and I wanted to collect that in the management server manifest with
>
> Mount <<||>>
>
> Problem is that each exported resource must be globally unique across
> every single *node*, not for every *environment*. That means that if two
> servers export this resource to the same nfs mount I'll get an error. I
> don't want an individual nfs mount on the mgmt server per node, but per
> environment. So I can't use $host instead of $environment
>
>
I'm not sure I follow how many distinct shares are exported, by which NFS
servers, or by which machines any of those are mounted. Nevertheless, the
key is probably for the Mount resources to be exported by the nodes
*serving* the shares (which does not itself cause them to have the Mounts
in their own catalogs). That will allow you to ensure that each distinct
share is exported exactly once. You could and probably should then have
every node that wants any of those mounts collect the appropriate exported
ones instead of declaring them independently. More generally, a node
should export only resources that are in some way specific to themselves.
Also, I would recommend that you declare appropriate tags on your Mount
resources. That could facilitate distinguishing Mounts exported for the
present purpose from unrelated Mounts that might in the future be exported
for some entirely different purpose.
For example, the NFS servers might declare this:
@@mount { "myapp-nfs-$environment":
name => "${myapp::path}-$environment",
fstype => "nfs",
device => "${::fqdn}:/path/to/share",
options => 'defaults',
tag => 'myapp-nfs'
}
Your per-environment servers could then do this:
Mount <<| title == "myapp-nfs-$environment" |>>
file { '/local/alias/for/mount/point':
ensure => 'link',
target => "${myapp::path}-$environment"
}
And your management server would do this:
Mount <<| tag == 'myapp-nfs' |>>
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 puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/62da71a2-daae-49ef-90d2-378ff1b9f100%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
