How to create different types from the same hiera data

[Vadym Chepkov]

Hi,

I would like to have mounts entries and mount points created using create_resources from the same hiera data.

I am thinking to describe directories like this:

---

my::mounts:

  /dir1:

    device: server1:/share1

    options: rw,soft,noatime

    owner: user1

    mode:  0644

  /dir2:

    device: server2:/share2

    options: rw,soft,noatime

    owner: user2

    group: somegroup

    mode:  0664

and then using puppet 'magic' I want to create two set of resources 

File[ensure=>directory] -> Mount[type=nfs,ensure=>mounted]

Is this possible or I have to maintain two sets of data?

Thanks,

Vadym

[Felix Frank]

Hi,

On 06/04/2014 03:32 PM, Vadym Chepkov wrote:
> File[ensure=>directory] -> Mount[type=nfs,ensure=>mounted]
>
> Is this possible or I have to maintain two sets of data?

no, that is fine. The 'puppet magic' you are looking for is a defined
type that accepts all the parameters you want to declare in your data.
The implementation of the define should then "translate" them into the
file and mount resources you want.

See
http://docs.puppetlabs.com/puppet/latest/reference/lang_defined_types.html

HTH,
Felix

[Vadym Chepkov]

Thank you, that is indeed what I need.

I have one more related question though. Is it possible to create the whole path, similar to mkdir -p for the mount points using File resource?

i.e. I will use /apps/oracle as a mount point. I want puppet to create /apps for me. since /apps is not going to be a mount point, I would have to track it separately and I would like to avoid it.

I suppose I can create yet another attribute, like "is_mount: false", but I wonder if there is a better way to accomplish it?

Thanks,

Vadym

 

[Trevor Vaughan]

Vadym,

This is not currently possible (but is a VERY wanted feature going back years). Most of us just use an Exec.

Trevor

--
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...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/73bb5099-05e2-49a2-8dc2-2bf60ec36fdb%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
Trevor Vaughan
Vice President, Onyx Point, Inc
(410) 541-6699
tvau...@onyxpoint.com

-- This account not approved for unencrypted proprietary information --

[jcbollinger]

Puppet does not directly support automatic declaration of parent directories, but it should not be too hard to implement using (again) a defined type.  Something along these lines could probably be made to work:

define mymodule::recursive_file ($ensure => 'directory') {
  $parent = regsubst($title, '^(.*)/[^/]+$', '\1')

  file { $title: ensure => $ensure }

  if $parent {
    mymodule::recursive_file { $parent: }
  }
}

You then use it in any class or definition, like so:

mymodule::recursive_file { '/grandparent/parent/file':
  ensure => 'file'
}

That could be gussied up with additional attributes (mode, owner, etc.).  The problem with that is it easily lends itself to creating duplicate declarations.  Consider:

file { '/etc': ensure => 'directory' }
mymodule::recursive_file { '/etc/somepackage/somepackage.conf':
  ensure => 'file'
}

You end up with File['/etc'] being declared twice, which Puppet will not accept.

Using an Exec to run 'mkdir -p' is in some ways better, but in other ways worse.  It reduces your exposure to duplicate declaration issues, but at the price of exposing you to the possibility of an inconsistent catalog.  Consider this, for example:

exec { 'mkdir -p /etc/somepackage':
  creates => '/etc/somepackage'
}
->
file { '/etc/somepackage/somepackage.conf':
  ensure => file
}

[... somewhere else ...]

file { '/etc/somepackage':
  ensure => 'absent'
}

That still suffers from the problem that you are attempting to manage the same physical resource (directory /etc/somepackage) via two different Puppet resources, but Puppet can no longer recognize the problem because you have disguised it.  Your catalog will be compiled, but Puppet cannot reliably apply it because it is internally inconsistent.

If you are careful to avoid inconsistencies then you can nevertheless make something like that work for you, but in that case you are on your own.

The alternative, and in many respects the true Puppet way, is to explicitly manage those files and directories you intend to manage, and only those.  Remember always that building Puppet manifests is an exercise in modeling, not in scripting.


John