(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 [email protected].
> 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 [email protected].
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.
