puppet 6.0.5-x64-mingw32 → 8.8.1-x64-mingw32

data/COMMITTERS.md

@@ -1,244 +0,0 @@
-Committing changes to Puppet
-====
-
-We would like to make it easier for community members to contribute to Puppet
-using pull requests, even if it makes the task of reviewing and committing
-these changes a little harder.  Pull requests are only ever based on a single
-branch, however, we maintain more than one active branch.  As a result
-contributors should target their changes at the master branch. This makes the
-process of contributing a little easier for the contributor since they don't
-need to concern themselves with the question, "What branch do I base my changes
-on?"  This is already called out in the [CONTRIBUTING.md](https://goo.gl/XRH2J).
-
-Therefore, it is the responsibility of the committer to re-base the change set
-on the appropriate branch which should receive the contribution.
-
-It is also the responsibility of the committer to review the change set in an
-effort to make sure the end users must opt-in to new behavior that is
-incompatible with previous behavior.  We employ the use of [feature
-flags](https://stackoverflow.com/questions/7707383/what-is-a-feature-flag) as
-the primary way to achieve this user opt-in behavior.  Finally, it is the
-responsibility of the committer to make sure the `master` and `stable` branches
-are both clean and working at all times.  Clean means that dead code is not
-allowed, everything needs to be usable in some manner at all points in time.
-Stable is not an indication of the build status, but rather an expression of
-our intent that the `stable` branch does not receive new functionality.
-
-The rest of this document addresses the concerns of the committer.  This
-document will help guide the committer decide which branch to base, or re-base
-a contribution on top of.  This document also describes our branch management
-strategy, which is closely related to the decision of what branch to commit
-changes into.
-
-Terminology
-====
-
-Many of these terms have more than one meaning.  For the purposes of this
-document, the following terms refer to specific things.
-
-**contributor** - A person who makes a change to Puppet and submits a change
-set in the form of a pull request.
-
-**change set** - A set of discrete patches which combined together form a
-contribution.  A change set takes the form of Git commits and is submitted to
-Puppet in the form of a pull request.
-
-**committer** - A person responsible for reviewing a pull request and then
-making the decision what base branch to merge the change set into.
-
-**base branch** - A branch in Git that contains an active history of changes
-and will eventually be released using semantic version guidelines.  The branch
-named `master` will always exist as a base branch.  The other base branches are
-`stable`, and `security` described below.
-
-**master branch** - The branch where new functionality that are not bug fixes
-is merged.
-
-**stable branch** - The branch where bug fixes against the latest release or
-release candidate are merged.
-
-**security** - Where critical security fixes are merged.  These change sets
-will then be merged into release branches independently from one another. (i.e.
-no merging up).  Please do not submit pull requests against the security branch
-and instead report all security related issues to security@puppetlabs.com as
-per our security policy published at
-[https://puppetlabs.com/security/](https://puppetlabs.com/security/).
-
-Committer Guide
-====
-
-This section provides a guide to follow while committing change sets to Puppet
-base branches.
-
-How to decide what release(s) should be patched
----
-
-This section provides a guide to help a committer decide the specific base
-branch that a change set should be merged into.
-
-The latest minor release of a major release is the only base branch that should
-be patched.  These patches will be merged into `master` if they contain new
-functionality.  They will be merged into `stable` and `master` if they fix a
-critical bug.  Older minor releases in a major release do not get patched.
-
-Before the switch to [semantic versions](http://semver.org/) committers did not
-have to think about the difference between minor and major releases.
-Committing to the latest minor release of a major release is a policy intended
-to limit the number of active base branches that must be managed.
-
-Security patches are handled as a special case.  Security patches may be
-applied to earlier minor releases of a major release, but the patches should
-first be merged into the `security` branch.  Security patches should be merged
-by Puppet Labs staff members.  Pull requests should not be submitted with the
-security branch as the base branch.  Please send all security related
-information or patches to security@puppetlabs.com as per our [Security
-Policy](https://puppetlabs.com/security/).
-
-The CI systems are configured to run against `master` and `stable`.  Over time,
-these branches will refer to different versions, but their name will remain
-fixed to avoid having to update CI jobs and tasks as new versions are released.
-
-How to commit a change set to multiple base branches
----
-
-A change set may apply to multiple branches, for example a bug fix should be
-applied to the stable release and the development branch.  In this situation
-the change set needs to be committed to multiple base branches.  This section
-provides a guide for how to merge patches into these branches, e.g.
-`stable` is patched, how should the changes be applied to `master`?
-
-First, rebase the change set onto the `stable` branch.  Next, merge the change
-set into the `stable` branch using a merge commit.  Once merged into `stable`,
-merge the same change set into `master` without doing a rebase as to preserve
-the commit identifiers.  This merge strategy follows the [git
-flow](http://nvie.com/posts/a-successful-git-branching-model/) model.  Both of
-these change set merges should have a merge commit which makes it much easier
-to track a set of commits as a logical change set through the history of a
-branch.  Merge commits should be created using the `--no-ff --log` git merge
-options.
-
-Any merge conflicts should be resolved using the merge commit in order to
-preserve the commit identifiers for each individual change.  This ensures `git
-branch --contains` will accurately report all of the base branches which
-contain a specific patch.
-
-Using this strategy, the stable branch need not be reset.  Both `master` and
-`stable` have infinite lifetimes.  Patch versions, also known as bug fix
-releases, will be tagged and released directly from the `stable` branch.  Major
-and minor versions, also known as feature releases, will be tagged and released
-directly from the `master` branch.  Upon release of a new major or minor
-version all of the changes in the `master` branch will be merged into the
-`stable` branch.
-
-Code review checklist
----
-
-This section aims to provide a checklist of things to look for when reviewing a
-pull request and determining if the change set should be merged into a base
-branch:
-
- * All tests pass
- * Are there any platform gotchas? (Does a change make an assumption about
-   platform specific behavior that is incompatible with other platforms?  e.g.
-   Windows paths vs. POSIX paths.)
- * Is the change backwards compatible? (It should be)
- * Are there YARD docs for API changes?
- * Does the change set also require documentation changes? If so is the
-   documentation being kept up to date?
- * Does the change set include clean code?  (software code that is formatted
-   correctly and in an organized manner so that another coder can easily read
-   or modify it.)  HINT: `git diff master --check`
- * Does the change set conform to the contributing guide?
-
-Commit citizen guidelines:
----
-
-This section aims to provide guidelines for being a good commit citizen by
-paying attention to our automated build tools.
-
- * Don’t push on a broken build.  (A broken build is defined as a failing job
-   in the [Puppet FOSS](https://jenkins.puppetlabs.com/view/Puppet%20FOSS/)
-   page.)
- * Watch the build until your changes have gone through green
- * Update the ticket status and target version.  The target version field in
-   our issue tracker should be updated to be the next release of Puppet.  For
-   example, if the most recent release of Puppet is 3.1.1 and you merge a
-   backwards compatible change set into master, then the target version should
-   be 3.2.0 in the issue tracker.)
- * Ensure the pull request is closed (Hint: amend your merge commit to contain
-   the string `closes #123` where 123 is the pull request number and github
-   will automatically close the pull request when the branch is pushed.)
-
-Example Procedure
-====
-
-This section helps a committer rebase a contribution onto an earlier base
-branch, then merge into the base branch and up through all active base
-branches.
-
-Suppose a contributor submits a pull request based on master.  The change set
-fixes a bug reported against Puppet 3.1.1 which is the most recently released
-version of Puppet.
-
-In this example the committer should rebase the change set onto the `stable`
-branch since this is a bug rather than new functionality.
-
-First, the committer pulls down the branch using the `hub` gem.  This tool
-automates the process of adding the remote repository and creating a local
-branch to track the remote branch.
-
-    $ hub checkout https://github.com/puppetlabs/puppet/pull/1234
-    Branch jeffmccune-fix_foo_error set up to track remote branch fix_foo_error from jeffmccune.
-    Switched to a new branch 'jeffmccune-fix_foo_error'
-
-At this point the topic branch is a descendant of master, but we want it to
-descend from `stable`.  The committer rebases the change set onto `stable`.
-
-    $ git branch bug/stable/fix_foo_error
-    $ git rebase --onto stable master bug/stable/fix_foo_error
-    First, rewinding head to replay your work on top of it...
-    Applying: (#23456) Fix FooError that always bites users in 3.1.1
-
-The `git rebase` command may be interpreted as, "First, check out the branch
-named `bug/stable/fix_foo_error`, then take the changes that were previously
-based on `master` and re-base them onto `stable`.
-
-Now that we have a topic branch containing the change set based on the `stable`
-release branch, the committer merges in:
-
-    $ git checkout stable
-    Switched to branch 'stable'
-    $ git merge --no-ff --log bug/stable/fix_foo_error
-    Merge made by the 'recursive' strategy.
-     foo | 0
-     1 file changed, 0 insertions(+), 0 deletions(-)
-     create mode 100644 foo
-
-Once merged into the first base branch, the committer merges the `stable`
-branch into `master`, being careful to preserve the same commit identifiers.
-
-    $ git checkout master
-    Switched to branch 'master'
-    $ git merge --no-ff --log stable
-    Merge made by the 'recursive' strategy.
-     foo | 0
-     1 file changed, 0 insertions(+), 0 deletions(-)
-     create mode 100644 foo
-
-Once the change set has been merged into one base branch, the change set should
-not be modified in order to keep the history clean, avoid "double" commits, and
-preserve the usefulness of `git branch --contains`.  If there are any merge
-conflicts, they are to be resolved in the merge commit itself and not by
-re-writing (rebasing) the patches for one base branch, but not another.
-
-Once the change set has been merged into `stable` and into `master`, the
-committer pushes.  Please note, the checklist should be complete at this point.
-It's helpful to make sure your local branches are up to date to avoid one of
-the branches failing to fast forward while the other succeeds.  Both the
-`stable` and `master` branches are being pushed at the same time.
-
-    $ git push puppetlabs master:master stable:stable
-
-That's it!  The committer then updates the pull request, updates the issue in
-our issue tracker, and keeps an eye on the [build
-status](http://jenkins.puppetlabs.com).

data/CONTRIBUTING.md

@@ -1,167 +0,0 @@
-# How to contribute
-
-Third-party patches are essential for keeping Puppet great. We simply can't
-access the huge number of platforms and myriad configurations for running
-Puppet. We want to keep it as easy as possible to contribute changes that
-get things working in your environment. There are a few guidelines that we
-need contributors to follow so that we can have a chance of keeping on
-top of things.
-
-## Puppet Core vs Modules
-
-New functionality is typically directed toward modules to provide a slimmer
-Puppet Core, reducing its surface area, and to allow greater freedom for
-module maintainers to ship releases at their own cadence, rather than
-being held to the cadence of Puppet releases. With Puppet 4's "all in one"
-packaging, a list of modules at specific versions will be packaged with the
-core so that popular types and providers will still be available as part of
-the "out of the box" experience.
-
-Generally, new types and new OS-specific providers for existing types should
-be added in modules. Exceptions would be things like new cross-OS providers
-and updates to existing core types.
-
-If you are unsure of whether your contribution should be implemented as a
-module or part of Puppet Core, you may visit [#puppet-dev on slack](https://puppetcommunity.slack.com/), or ask on
-the [puppet-dev mailing list](https://groups.google.com/forum/#!forum/puppet-dev) for advice.
-
-## Getting Started
-
-* Make sure you have a [Jira account](https://tickets.puppetlabs.com).
-* Make sure you have a [GitHub account](https://github.com/signup/free).
-* Submit a Jira ticket for your issue if one does not already exist.
-  * Clearly describe the issue including steps to reproduce when it is a bug.
-  * Make sure you fill in the earliest version that you know has the issue.
-  * A ticket is not necessary for [trivial changes](https://puppet.com/community/trivial-patch-exemption-policy)
-* Fork the repository on GitHub.
-
-## Making Changes
-
-* Create a topic branch from where you want to base your work.
-  * This is usually the master branch.
-  * Only target release branches if you are certain your fix must be on that
-    branch.
-  * To quickly create a topic branch based on master, run `git checkout -b
-    fix/master/my_contribution master`. Please avoid working directly on the
-    `master` branch.
-* Make commits of logical and atomic units.
-* Check for unnecessary whitespace with `git diff --check` before committing.
-* Make sure your commit messages are in the proper format. If the commit
-  addresses an issue filed in the
-  [Puppet Jira project](https://tickets.puppetlabs.com/browse/PUP), start
-  the first line of the commit with the issue number in parentheses.
-
-  ```
-      (PUP-1234) Make the example in CONTRIBUTING imperative and concrete
-
-      Without this patch applied the example commit message in the CONTRIBUTING
-      document is not a concrete example. This is a problem because the
-      contributor is left to imagine what the commit message should look like
-      based on a description rather than an example. This patch fixes the
-      problem by making the example concrete and imperative.
-
-      The first line is a real-life imperative statement with a ticket number
-      from our issue tracker. The body describes the behavior without the patch,
-      why this is a problem, and how the patch fixes the problem when applied.
-  ```
-* Make sure you have added the necessary tests for your changes.
-* For details on how to run tests, please see [the quickstart guide](https://github.com/puppetlabs/puppet/blob/master/docs/quickstart.md)
-
-## Writing Translatable Code
-
-We use [gettext tooling](https://github.com/puppetlabs/gettext-setup-gem) to
-extract user-facing strings and pull in translations based on the user's locale
-at runtime. In order for this tooling to work, all user-facing strings must be
-wrapped in the `_()` translation function, so they can be extracted into files
-for the translators.
-
-When adding user-facing strings to your work, follow these guidelines:
-
-* Use full sentences. Strings built up out of concatenated bits are hard to translate.
-* Use string formatting instead of interpolation. Use the hash format and give good names to the placeholder values that can be used by translators to understand the meaning of the formatted values.
-  For example: `_('Creating new user %{name}.') % { name: user.name }`
-* Use `n_()` for pluralization. (see gettext gem docs linked above for details)
-
-It is the responsibility of contributors and code reviewers to ensure that all
-user-facing strings are marked in new PRs before merging.
-
-## Making Trivial Changes
-
-For [changes of a trivial nature](https://puppet.com/community/trivial-patch-exemption-policy), it is not always necessary to create a new
-ticket in Jira. In this case, it is appropriate to start the first line of a
-commit with one of  `(docs)`, `(maint)`, or `(packaging)` instead of a ticket
-number.
-
-If a Jira ticket exists for the documentation commit, you can include it
-after the `(docs)` token.
-
-```
-    (docs)(DOCUMENT-000) Add docs commit example to CONTRIBUTING
-
-    There is no example for contributing a documentation commit
-    to the Puppet repository. This is a problem because the contributor
-    is left to assume how a commit of this nature may appear.
-
-    The first line is a real-life imperative statement with '(docs)' in
-    place of what would have been the PUP project ticket number in a
-    non-documentation related commit. The body describes the nature of
-    the new documentation or comments added.
-```
-
-For commits that address trivial repository maintenance tasks or packaging
-issues, start the first line of the commit with `(maint)` or `(packaging)`,
-respectively.
-
-## Submitting Changes
-
-* Sign the [Contributor License Agreement](http://links.puppet.com/cla).
-* Push your changes to a topic branch in your fork of the repository.
-* Submit a pull request to the repository in the puppetlabs organization.
-* Update your Jira ticket to mark that you have submitted code and are ready
-  for it to be reviewed (Status: Ready for Merge).
-  * Include a link to the pull request in the ticket.
-* The core team looks at Pull Requests on a regular basis in a weekly triage
-  meeting that we hold in a public Google Hangout. The hangout is announced in
-  the weekly status updates that are sent to the puppet-dev list. Notes are
-  posted to the [Puppet Community community-triage
-  repo](https://github.com/puppet-community/community-triage/tree/master/core/notes)
-  and include a link to a YouTube recording of the hangout.
-* After feedback has been given we expect responses within two weeks. After two
-  weeks we may close the pull request if it isn't showing any activity.
-
-## Revert Policy
-
-By running tests in advance and by engaging with peer review for prospective
-changes, your contributions have a high probability of becoming long lived
-parts of the the project. After being merged, the code will run through a
-series of testing pipelines on a large number of operating system
-environments. These pipelines can reveal incompatibilities that are difficult
-to detect in advance.
-
-If the code change results in a test failure, we will make our best effort to
-correct the error. If a fix cannot be determined and committed within 24 hours
-of its discovery, the commit(s) responsible _may_ be reverted, at the
-discretion of the committer and Puppet maintainers. This action would be taken
-to help maintain passing states in our testing pipelines.
-
-The original contributor will be notified of the revert in the Jira ticket
-associated with the change. A reference to the test(s) and operating system(s)
-that failed as a result of the code change will also be added to the Jira
-ticket. This test(s) should be used to check future submissions of the code to
-ensure the issue has been resolved.
-
-### Summary
-
-* Changes resulting in test pipeline failures will be reverted if they cannot
-  be resolved within one business day.
-
-## Additional Resources
-
-* [Puppet community guidelines](https://puppet.com/community/community-guidelines)
-* [Bug tracker (Jira)](https://tickets.puppetlabs.com)
-* [Contributor License Agreement](http://links.puppet.com/cla)
-* [General GitHub documentation](https://help.github.com/)
-* [GitHub pull request documentation](https://help.github.com/articles/creating-a-pull-request/)
-* #puppet-dev IRC channel on freenode.org ([Archive](https://botbot.me/freenode/puppet-dev/))
-* [puppet-dev mailing list](https://groups.google.com/forum/#!forum/puppet-dev)
-* [Community PR Triage notes](https://github.com/puppet-community/community-triage/tree/master/core/notes)

data/MAINTAINERS

@@ -1,47 +0,0 @@
-{
-  "version": 1,
-  "file_format": "This MAINTAINERS file format is described at https://github.com/puppetlabs/maintainers",
-  "issues": "https://tickets.puppet.com/browse/PUP",
-  "internal_list": "https://groups.google.com/a/puppet.com/forum/?hl=en#!forum/discuss-puppet-maintainers",
-  "people": [
-    {
-      "github": "hlindberg",
-      "email": "henrik.lindberg@puppet.com",
-      "name": "Henrik Lindberg"
-    },
-    {
-      "github": "joshcooper",
-      "email": "josh@puppet.com",
-      "name": "Josh Cooper"
-    },
-    {
-      "github": "MikaelSmith",
-      "email": "michael.smith@puppet.com",
-      "name": "Michael Smith"
-    },
-    {
-      "github": "thallgren",
-      "email": "thomas.hallgren@puppet.com",
-      "name": "Thomas Hallgren"
-    },
-    {
-      "github": "branan",
-      "email": "branan@puppet.com",
-      "name": "Branan Riley"
-    },
-    {
-      "github": "Iristyle",
-      "name": "Ethan J. Brown"
-    },
-    {
-      "github": "er0ck",
-      "email": "eric.thompson@puppet.com",
-      "name": "Eric Thompson"
-    },
-    {
-      "github": "jtappa",
-      "email": "jorie@puppet.com",
-      "name": "Jorie Tappa"
-    }
-  ]
-}

data/conf/auth.conf

@@ -1,150 +0,0 @@
-# This is the default auth.conf file, which implements the default rules
-# used by the puppet master. (That is, the rules below will still apply
-# even if this file is deleted.)
-#
-# The ACLs are evaluated in top-down order. More specific stanzas should
-# be towards the top of the file and more general ones at the bottom;
-# otherwise, the general rules may "steal" requests that should be
-# governed by the specific rules.
-#
-# See https://puppet.com/docs/puppet/latest/config_file_auth.html
-# for a more complete description of auth.conf's behavior.
-#
-# Supported syntax:
-# Each stanza in auth.conf starts with a path to match, followed
-# by optional modifiers, and finally, a series of allow or deny
-# directives.
-#
-# Example Stanza
-# ---------------------------------
-# path /path/to/resource     # simple prefix match
-# # path ~ regex             # alternately, regex match
-# [environment envlist]
-# [method methodlist]
-# [auth[enthicated] {yes|no|on|off|any}]
-# allow [host|backreference|*|regex]
-# deny [host|backreference|*|regex]
-# allow_ip [ip|cidr|ip_wildcard|*]
-# deny_ip [ip|cidr|ip_wildcard|*]
-#
-# The path match can either be a simple prefix match or a regular
-# expression. `path /file` would match both `/file_metadata` and
-# `/file_content`. Regex matches allow the use of backreferences
-# in the allow/deny directives.
-#
-# The regex syntax is the same as for Ruby regex, and captures backreferences
-# for use in the `allow` and `deny` lines of that stanza
-#
-# Examples:
-#
-# path ~ ^/puppet/v3/path/to/resource    # Equivalent to `path /puppet/v3/path/to/resource`.
-# allow *                                # Allow all authenticated nodes (since auth
-#                                        # defaults to `yes`).
-#
-# path ~ ^/puppet/v3/catalog/([^/]+)$    # Permit nodes to access their own catalog (by
-# allow $1                               # certname), but not any other node's catalog.
-#
-# path ~ ^/puppet/v3/file_(metadata|content)/extra_files/  # Only allow certain nodes to
-# auth yes                                                 # access the "extra_files"
-# allow /^(.+)\.example\.com$/                             # mount point; note this must
-# allow_ip 192.168.100.0/24                                # go ABOVE the "/file" rule,
-#                                                          # since it is more specific.
-#
-# environment:: restrict an ACL to a comma-separated list of environments
-# method:: restrict an ACL to a comma-separated list of HTTP methods
-# auth:: restrict an ACL to an authenticated or unauthenticated request
-# the default when unspecified is to restrict the ACL to authenticated requests
-# (ie exactly as if auth yes was present).
-#
-
-# CONTROLLING FILE ACCESS (previously in fileserver.conf)
-
-# In previous versions of Puppet, you controlled file access by adding
-# rules to fileserver.conf. In Puppet 5 with Puppet Server, you can control
-# file access in auth.conf by controlling the /file_metadata(s)/<mount point>,
-# /file_content(s)/<mount point>, and /static_file_content/<file> paths. See the
-# Puppet Server documentation at
-# https://puppet.com/docs/puppetserver/latest/config_file_auth.html.
-#
-# If you are not using Puppet Server, or are using Puppet Server but with the
-# "jruby-puppet.use-legacy-auth-conf" setting set to "true", you could set the
-# desired file access in a new rule in this file. For example:
-#
-# path ~ ^/file_(metadata|content)s?/extra_files/
-# auth yes
-# allow /^(.+)\.example\.com$/
-# allow_ip 192.168.100.0/24
-#
-# If added to auth.conf BEFORE the default "path /file" rule, this rule
-# will add stricter restrictions to the extra_files mount point.
-
-### Authenticated ACLs - these rules apply only when the client
-### has a valid certificate and is thus authenticated
-
-path /puppet/v3/environments
-method find
-allow *
-
-# allow nodes to retrieve their own catalog
-path ~ ^/puppet/v3/catalog/([^/]+)$
-method find
-allow $1
-
-# allow nodes to retrieve their own node definition
-path ~ ^/puppet/v3/node/([^/]+)$
-method find
-allow $1
-
-# allow all nodes to store their own reports
-path ~ ^/puppet/v3/report/([^/]+)$
-method save
-allow $1
-
-# allow all nodes to update their own facts
-path ~ ^/puppet/v3/facts/([^/]+)$
-method save
-allow $1
-
-# Allow all nodes to access all file services; this is necessary for
-# pluginsync, file serving from modules, and file serving from custom
-# mount points (see fileserver.conf). Note that the `/file` prefix matches
-# requests to both the file_metadata and file_content paths. See "Examples"
-# above if you need more granular access control for custom mount points.
-path /puppet/v3/file
-allow *
-
-path /puppet/v3/status
-method find
-allow *
-
-# allow all nodes to access the certificates services
-path /puppet-ca/v1/certificate_revocation_list/ca
-method find
-allow *
-
-### Unauthenticated ACLs, for clients without valid certificates; authenticated
-### clients can also access these paths, though they rarely need to.
-
-# allow access to the CA certificate; unauthenticated nodes need this
-# in order to validate the puppet master's certificate
-path /puppet-ca/v1/certificate/ca
-auth any
-method find
-allow *
-
-# allow nodes to retrieve the certificate they requested earlier
-path /puppet-ca/v1/certificate/
-auth any
-method find
-allow *
-
-# allow nodes to request a new certificate
-path /puppet-ca/v1/certificate_request
-auth any
-method find, save
-allow *
-
-# deny everything else; this ACL is not strictly necessary, but
-# illustrates the default policy.
-path /
-auth any

data/examples/hiera/etc/hiera.yaml

@@ -1,15 +0,0 @@
----
-:backends:
-  - yaml
-  - puppet
-
-:hierarchy:
-  - "%{location}"
-  - "%{environment}"
-  - common
-
-:yaml:
-  :datadir: etc/hieradb
-
-:puppet:
-  :datasource: data

data/examples/hiera/etc/hieradb/common.yaml

@@ -1,3 +0,0 @@
-classes:
-  - users::common
-  - ntp::config

data/examples/hiera/etc/hieradb/dc1.yaml

@@ -1,6 +0,0 @@
----
-ntpservers:
-  - ntp1.dc1.example.com
-  - ntp2.dc1.example.com
-classes:
-  - users::dc1

data/examples/hiera/etc/hieradb/development.yaml

@@ -1,2 +0,0 @@
----
-classes: users::development

data/examples/hiera/etc/puppet.conf

@@ -1,3 +0,0 @@
-[main]
-  modulepath = modules
-

data/examples/hiera/modules/data/manifests/common.pp

@@ -1,4 +0,0 @@
-# sets the common (across all puppet conf) ntp servers.
-class data::common {
-  $ntpservers = ['ntp1.example.com', 'ntp2.example.com']
-}

data/examples/hiera/modules/ntp/manifests/data.pp

@@ -1,4 +0,0 @@
-# this class will be loaded using hiera's 'puppet' backend
-class ntp::data {
-  $ntpservers = ['1.pool.ntp.org', '2.pool.ntp.org']
-}

data/examples/hiera/modules/ntp/templates/ntp.conf.erb

@@ -1,3 +0,0 @@
-<% [ntpservers].flatten.each do |server| -%>
-server <%= server %>
-<% end -%>

data/examples/hiera/modules/users/manifests/development.pp

@@ -1,4 +0,0 @@
-# notifies
-class users::development {
-  notify{'Adding users::development': }
-}