Hello guys,

I am working on similar task.

Trying to find the way to define all NFS shares somewhere in the high level
of hierarchy and then just add/remove them on the node level just by name.

So I am using the class which accepts mountpoint names, then I want to do
hiera lookup for each name to expand all the options of the mountpoint and
create resources based on that.
This scenario works well if on the class input I just supply single
mountpoint -> then I do hiera("mountpointname") and create_resources()
But if I want to have multiple Mountpoints defined per host I need to
supply an Array to the class and then iterate it and fetch details for each
mountpoint. I can probably do this by using new 3.2 syntax with "each", but
I would like to avoid this.

Do you have any better way to implement this?

My target is to define Mountpoints in single place in Hiera and then use it
for different hosts using Hiera.

Andrey


On Thursday, January 9, 2014 9:49:35 AM UTC-5, 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"
> }
>
> 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
>

Hi,

I handle NFS mounts by declaring them as a hash in Hiera. Through the power
of Hiera, you could specify mounts at any level of the hierarchy including
per host and/or per environment. The mount itself is done with the types[1]
module and handling the nfs client portion is handled by the nfs[2] module.

Example Hiera entry using the YAML backend

  types::mounts:
    /srv/nfs/home:
      device: nfsserver:/export/home
      fstype: nfs
      options: rw,rsize=8192,wsize=8192


[1] - https://github.com/ghoneycutt/puppet-module-types
[2] - https://github.com/ghoneycutt/puppet-module-nfs

BR,
-g

-- 
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/1bbdf73d-5b5e-40f3-b6d4-b8e60f89511b%40googlegroups.com
.
For more options, visit 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/CACzr%3DFfw_MGcXQXA956GAg3fCHwEWjv9-%3DxkDtRYEYHSj_W%3DDQ%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Reply via email to