OnyxPoint

Onyx Point Privacy Policy

Your privacy is very important to us. Our Privacy Policy describes how we use our website to collect, use, communicate and make use of personal information.

Onyx Point uses Google Analytics to assess website health and functionality. Google Analytics utilizes a standard technology called “cookies,” to collect information and report on how our website is being used. When accessing www.onyxpoint.com, we will be collecting non-personally identifiable information that may include the date and time of your site visit, the number of pages visited during your session, and/or your session duration. We will also collect information pertaining to the browser or device used, the operating system used, the domain name of your internet service provider and your IP address. Google Inc. may transfer the information it collects on to third parties when required to do so by law or where such third parties process the information on Google’s behalf. By using this website you have granted your consent to the processing of data about you by Google in the manners outlined above.

We will not collect personally identifiable information about you such as your name, address, telephone number or email address, unless you choose submit it via the “Contact Us” form, or a Newsletter Subscription form found on numerous pages throughout our site.

Cookies
Cookies are unique text files that are placed on your computer to help our website identify how users interact with it. Information gathered from these cookies about your interactions with our website, including your IP address, is transmitted and stored by Google in the United States. Google uses this information to evaluate and report on the interaction you have on our website. This practice helps us provide you with a positive website experience.

Email Information
Onyx Point will collect and store your email information only if you willingly fill out a “Contact Us” form. You have the right to remove your email address from any of our mailing lists.

Collection of Information by Third-Party Sites and Sponsors
Our site contains links to other parties’ sites whose privacy policies may differ from ours. We advertise events and publications with links to their website for content review and event registration. If you are concerned with how these sites treat your privacy, please review the policies on the applicable websites.

Policy Changes
We reserve the right to change or update this Privacy Policy at any time without prior notice. We are committed to conducting business in accordance with these guiding principles in order to ensure the confidentiality of your personal information is protected and maintained.

Contact
If you have any questions regarding this policy or your interactions with our website, please contact us by email at: info@onyxpoint.com or by mail:

Onyx Point Inc.
7050 Hi Tech Dr, Suit3 102
Hanover, MD 21076

(This is part 1 of a multi part series of posts about cool things you can do with Hiera v5 on modern Puppet versions)

Introduction

In this blog post, I’m going to talk about a new feature added in Hiera v5, which is yaml file globbing.

Hiera is the data access layer for Puppet, and it is organized into hierarchies. When Puppet calls lookup(), it looks through each layer in the hierarchy, in order, and attempts to retrieve the value for a key from the layer. When it can’t find a key in the current layer, it continues on to the next one down, one at a time, until it finds a match.

Explicit Files

Here is an example of a common hierarchy setup. We have a layer for per-node data, we have a layer for hostgroups, a layer for osfamily (eg ‘Windows’ vs ‘RedHat’), and a common layer.

hierarchy:.
  - name: "Per-node data (yaml version)"
    path: "nodes/%{trusted.certname}.yaml"
  - name: "Other YAML hierarchy levels"
    paths:
      - "hostgroup/%{::hostgroup}.yaml"
      - "os/%{facts.os.family}.yaml"
      - "common.yaml"

Each file is explicitly specified in the hierarchy. But this leads to a problem with organization. What if we want to keep all of the GitLab settings in common.yaml together? or the Nginx settings? We could separate them in the yaml files with headers and whitespace. We could also try to use separate files, but because each file in each layer is specified in the file, we have to explicitly add a new layer for each file.

A Better Way

This is where globbing comes in.

hierarchy:.
  - name: "Per-node data (yaml version)"
    path: "nodes/%{trusted.certname}.yaml"
  - name: "Other YAML hierarchy levels"
    paths:
      - "hostgroup/%{::hostgroup}.yaml"
      - "os/%{facts.os.family}.yaml"
  - name: "Common Settings"
    globs:
      - "common/*.yaml"

If we replace paths with globs, we can use * and ? as wildcards to the filename. Puppet will automatically expand that into a real file when lookup runs. Now we can have a set of Hiera data files like this:

helio@helio-laptop scratch1> tree data
data
├── common
│   ├── gitlab.yaml
│   ├── nginx.yaml
│   └── ntp.yaml
├── hostgroup
│   └── masters.yaml
└── nodes
    └── mom.test.yaml

3 directories, 5 files

And all of our GitLab settings, Nginx settings, and NTP settings are neatly organized into their own files. We can do this on any hierarchy layer we want, so we can even change the per-node data to match this scheme. In this way data can be stored in nodes/mom.test/gitlab.yaml or nodes/mom.test/nginx.yaml instead of all sharing nodes/mom.test.yaml

← View all posts