profile_metadata

• Description
• Usage
• Reference
• Changelog
• Development

Description

profile_metadata allows you to define information about a service within the profile that configures it. The information resulting from all the services included in a role are combined and presented as a structured fact on the host. The service's title and what profile it came from are also added the the message of the day (MOTD).

This module is used extensively inside Puppet to provide information directly on each host and to put data into PuppetDB that is then consumed by other services.

Usage

This module provides a defined type named profile_metadata::service that you can include like any other resource in each profile.

Reference

This module is documented via pdk bundle exec puppet strings generate --format markdown. Please see Reference on the Puppet Forge or REFERENCE.md on GitHub for more info.

Changelog

CHANGELOG.md is generated prior to each release via pdk bundle exec rake changelog. This process relies on labels that are applied to each pull request.

Development

Pull requests are welcome!

Reference

Table of Contents

Classes

Public Classes

Private Classes

• profile_metadata: Support defining metadata for a node (e.g profile_metadata::service)
• profile_metadata::service::motd_blank: Add the blank line after the services in the MOTD

Defined types

• profile_metadata::service: Define information about a service

Classes

Defined types

profile_metadata::service

Define information about a service. The service's title is automatically added to the MOTD and all the information is added to a structured fact named profile_metadata.

$title: This should always be the name of the enclosing class, which will be available in $title. The only case where this will be different is within defined types.

Examples

A service definition on a Puppet Master included in profile::pe::master

profile_metadata::service { $title:
  human_name        => 'Puppet Master',
  owner_uid         => 'john.doe',
  team              => infracore,
  end_users         => ['notify-infracore@example.com'],
  escalation_period => 'global-workhours',
  downtime_impact   => "Can't make changes to infrastructure",
  doc_urls          => [
    'https://example.com/our-pe-docs',
  ],
}

The resulting fact from the definition above as shown by sudo facter -p profile_metadata on the master

{
  services => [
    {
      class_name => "profile::pe::master",
      doc_urls => [
        "https://example.com/our-pe-docs"
      ],
      downtime_impact => "Can't make changes to infrastructure",
      end_users => [
        "notify-infracore@example.com"
      ],
      escalation_period => "global-workhours",
      human_name => "Puppet Master",
      other_fqdns => [],
      owned => true,
      owner_uid => "john.doe",
      team => "infracore"
    }
  ]
}

The two lines this definition adds to the bottom of the MOTD

Puppet Master
  profile::pe::master owned by team infracore

Parameters

The following parameters are available in the profile_metadata::service defined type:

• owner_uid
• team
• end_users
• escalation_period
• downtime_impact
• notes
• doc_urls
• class_name
• human_name
• other_fqdns

owner_uid

Data type: Optional[String[1]]

The LDAP uid of the owner of the service. If there are multiple owners, pick one. This may only be set to undef temporarily as all services need to have an owner... even when nobody want it.

Default value: undef

team

Data type: Optional[String[1]]

The team that owns the service. At Puppet, this should generally be infracore, re, qe, or itops. This may only be set to undef temporarily as all services need to owned by a team... even when nobody want it.

Default value: undef

end_users

Data type: Optional[Array[Pattern[/@/], 1]]

An array of email addresses to notify when there are changes to the service that will be visible outside of $team. For example, all@puppet.com is appropriate for JIRA. This may only be set to undef temporarily. If only $team will see the changes then $team's email should be used.

Default value: undef

escalation_period

Data type: String[1]

A description of when we should escalate to $team if the service goes down and the on call person cannot fix it. For example:

• pdx-workhours
• 24/7
• workdays

Default value: 'pdx-workhours'

downtime_impact

Data type: Optional[String[1]]

A description of the impact of downtime, e.g. "Development work will be blocked because their changes cannot be tested and thus cannot be merged." Use multiple lines and markdown as appropriate.

Default value: undef

notes

Data type: Optional[String[1]]

General notes for things not covered elsewhere. Use multiple lines and markdown as appropriate.

Default value: undef

doc_urls

Data type: Array[String[1]]

An array of URLs to documentation (e.g. Confluence).

Default value: []

class_name

Data type: Pattern[/\A([a-z][a-z0-9_]*)?(::[a-z][a-z0-9_]*)*\Z/]

The Puppet class the metadata is associated with

Default value: $title

human_name

Data type: String[1]

a human friendly name for the service. For example, "Internal InfraCore CI".

Default value: $title

other_fqdns

Data type: Array[String[1]]

Other FQDNs that resolve to this host that are used by the service. For example, the $site_alias of a Jenkins master.

Default value: []

Change log

All notable changes to this project will be documented in this file. The format is based on Keep a Changelog and this project adheres to Semantic Versioning.

1.1.0 (2023-09-06)

Full Changelog

Added

• PDK 3 teamplates and standards update #4 (yachub)

Fixed

• Fix macOS compatibility #5 (yachub)

1.0.0 (2021-09-18)

Full Changelog

Changed

• Dropped old Puppet versions, added new ones, sync to current standards #1 (genebean)

* This Changelog was automatically generated by github_changelog_generator