(inline)
On Thu, Jan 09, 2014 at 06:49:35AM -0800, Stephan wrote:
> 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"
> }
Could you maybe use "mgmtnfs-${environment}-${fqdn}" (or add more unique-ish
suffix strings) in the resource title? If I recall correctly giving each
resource a unique title will ensure that each server+environment's mount is a
uniquely named resource.
(I just just be rhubarbing on, haven't used exported resources.)
> 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
>
> If I would use local resources in the mgmt server manifest I would have to
> set up 10 mount resources individually, since that's how many environments
> I have. Actually 30, since every environment has not 1 but 3 separate NFS
> mounts. Since that would be a manual step for every new environment, and
> duplication of code, I consider it bad practice.
>
> In my head the most elegant solution to this would be to have a resource
> which is both virtual and exported, so that it can be requested to be
> "realized" by every environment server, but is collected only once. I
> don't think that is currently possible (or is it?). My questions are:
> Would it be worth a feature request? And are there other ways to get this
> done in a tidy manner?
>
> Thanks
> Stephan
>
> --
> 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
>
> [1]https://groups.google.com/d/msgid/puppet-users/2fcaa251-714b-4c41-b995-c48e87cb1520%40googlegroups.com.
> For more options, visit [2]https://groups.google.com/groups/opt_out.
>
> References
>
> Visible links
> 1.
> https://groups.google.com/d/msgid/puppet-users/2fcaa251-714b-4c41-b995-c48e87cb1520%40googlegroups.com
> 2. https://groups.google.com/groups/opt_out
--
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/20140109145915.GA12075%40iniquitous.heresiarch.ca.
For more options, visit https://groups.google.com/groups/opt_out.
