Home / server / Questions / 549720
Accepted
quickshiftin
Asked: 2013-10-31 10:42:36 +0800 CST

hiera_include equivalent for resource types

  • 772

I'm using the yumrepo built-in type. I can get a basic integration to hiera working

  yumrepo { hiera('yumrepo::name') :
    metadata_expire => hiera('yumrepo::metadata_expire'),
    descr           => hiera('yumrepo::descr'),
    gpgcheck        => hiera('yumrepo::gpgcheck'),
    http_caching    => hiera('yumrepo::http_caching'),
    baseurl         => hiera('yumrepo::baseurl'),
    enabled         => hiera('yumrepo::enabled'),
  }

If I try to remove that definition and instead go for hiera_include('classes'), here's what I've got in the corresponding yaml backend

classes:
 - "yumrepo"

yumrepo::metadata_expire: 0
yumrepo::descr: "custom repository"
yumrepo::gpgcheck: 0
yumrepo::http_caching: none
yumrepo::baseurl: "http://myserver/custom-repo/$basearch"
yumrepo::enabled: 1

I get this error on an agent

Error 400 on SERVER: Could not find class yumrepo

I guess you can't get away from some sort of minimal node declaration w/ hiera and resource types? Maybe hiera_hash is the way to go?

I gave this a shot, but it produces a syntax error

  yumrepo { 'hnav-development':
    hiera_hash('yumrepo')
  }
puppet

4 Answers

  1. Best Answer

    I've ended up using create_resources. Essentially it provides the ability to map defined types to nodes with hiera, in much the same way hiera_include does with classes out of the box.

    With this setup I can declare any number of file resource types at any level of the hierarchy, plus the configuration is all in hiera datasources.

    /etc/hiera.yaml

    :hierarchy:
  - defaults
  - "%{environment}"

    /var/lib/hiera/defaults.yaml

    classes:
  - hiera_file_wrapper
hiera_file:
    hiera-two:
       path: /home/quickshiftin/hiera-two
       ensure: file
       content: 'Hiera two'

    /var/lib/hiera/production.yaml

    hiera_file:
    hiera-baby:
       path: /home/quickshiftin/hiera-baby
       ensure: file
       content: 'Hiera baby!

    modules/hiera_file_wrapper/manifestes/init.pp

    class hiera_file_wrapper()
{
    create_resources(file, hiera_hash('hiera_file'))
}

    manifestes/site.pp

    hiera_include('classes')
    • 4

  2. Since yumrepo is a resource type, not a class, that won't work.

    I'd say put a class in named yumrepo_myreponame and have it declare the yumrepo resource. You can put class parameters in Hiera for that if you need as well, then pass those through to the resource declaration.

    For instance, I have a module for turning EPEL on for a server, which can be put in its Hiera classes array to enable it. Its entire content is:

    class epel_yumrepo {
  yumrepo { "epel":
    descr          => 'Extra Packages for Enterprise Linux 6 - $basearch',
    enabled        => 1,
    gpgcheck       => 1,
    gpgkey         => 'http://download.fedoraproject.org/pub/epel/RPM-GPG-KEY-EPEL-6',
    mirrorlist     => 'https://mirrors.fedoraproject.org/metalink?repo=epel-6&arch=$basearch',
    failovermethod => "priority",
  }
}
    • 0

  3. Let's assume you had a yum repository named hnav and you needed it to have a different URL based on what version of the OS you're using, 5 or 6.

    You configured your hierarchy in /etc/puppet/hiera.yaml like

    :hierarchy:
- "%{::operatingsystemmajrelease}"
- common

    So that hiera will first look for a yaml file named after the OS version, 5.yaml or 6.yaml. If it doesn't find a value there, it will look in common.yaml.

    You wrote a parametrized class so that hiera could automatically supply the url.

    modules/hnav/manifests.init.pp

    class hnav ( $url ) {
  yumrepo { 'hnav':
    enabled => true,
    baseurl => $url
  }
}

    If for some reason you didn't like parametrized classes, you could have written the above as

    class hnav {
  yumrepo { 'hnav':
    enabled => true,
    baseurl => hiera('hnav::url')
  }
}

    Then your configured the classes you wanted applied on all your nodes

    common.yaml

    classes:
  - hnav

    And you set the values for the URL

    5.yaml

    hnav::url: http://example.com.yum/5/

    6.yaml

    hnav::url: http://example.com.yum/6/

    This is a really artificial example, but maybe it will help you understand where hiera is used.

    • 0

  4. I built a hiera_manifest functionality at my job. Essentially it allows you to call modules, classes and parameters and defined types all via hiera yaml.

    I just put it up on Github to share: https://github.com/mlbam/hiera_manifest

    This has slight advantages in that parameters are also put in place at the time of invocation of the module, class or type.

    One thing to note is the difference in some syntax for resource definitions when using metaparameters. Also, when troubleshooting, the errors stick to the manifest sometimes and you don't get a proper error message for the module that throws the error.

    • 0