Puppet

# Glossary of Terms

As developers have found time and time again, terminology is

critical to successful projects. The Puppet community has begun to

coalesce around certain terms found to be useful in working with

Puppet:

**catalog**

:   A catalog is the totality of resources, files, properties, etc, for a given system.

**class**

:   A native Puppet construct that defines a container of resources, such as File resources, Package resources, User resources, custom-defined resources (see also defined type), etc. A class can inherit from another class using the `inherits` keyword, and can also declare other classes.

**agent** or **agent node**

:   An operating system instance managed by Puppet. This can be an operating system running on its own hardware or a virtual image.

**declare** (v.)

:   To state that a class or a resource should be included in a given configuration. Classes are declared with the `include` keyword or with the `class {"foo":}` syntax; resources are declared with the lowercase `file {"/tmp/bar":}` syntax.

**define** (v.)

:   To specify the contents and behavior of a class or defined resource type. 

**defined resource type** or **defined type** (older usage: **definition**)

:   A Puppet resource type defined at the application level. Defined types are created in the Puppet language and are analogous to macros in some other languages. Contrast with **native type.**

**fact**

:   A detail or property returned by Facter. Facter has many built-in details that it reports about the machine it runs on, such as hostname. Additional facts can easily be returned by Facter (see [[Adding Facts]]). Facts are exposed to your Puppet manifests as global variables. 

**manifest**

:   A configuration file written in the Puppet language. These files should have the .pp extension.

**module**

:   modules are logically separate composites of resources that are then included by nodes as part of their catalog. A module may contain one or more related classes. For instance, the ssh module defines the basic ssh class that configures the ssh daemon and opens the ssh port to all Stanford IPs, and a subclass called ssh\_global that overrides the iptables settings to allow connections from any IP. See also [[Module Organisation]] .

**native type**

:   A type written purely in Ruby and distributed with Puppet. See the documentation for list of native types.

**node**

:   a node is any individual server, uniquely identified by their cn from the certificate, which is usually, but does not have to be, the hostname. Nodes generally inherit a template node and include additional modules as needed, generally their associate client or service class. Currently, nodes are defined in the site.pp file.

**parameter**

:   Parameters are just data that is made available to the providers when they synchronize properties.

**pattern**

:   colloquial community expression for a collection of manifests designed to solve an issue or manage a particular configuration item, for example an Apache pattern.

**plugin, plugin types**

:   a Puppet term for custom types created for Puppet at the Ruby level. These types are written entirely in Ruby and must correspond to the Puppet standards for custom-types.

**plusignment operator**

:   An operator that allows you to add values to resource parameters using the +> ('plusignment') syntax. Available since version 0.23.1:

    class apache {

        service { "apache": require => Package["httpd"] }

    }

    class apache-ssl inherits apache {

        # host certificate is required for SSL to function

        Service[apache] { require +> File["apache.pem"] }

    }

**property**

:   Properties model the desired state of a system.  They can be queried from the underlying system, compared, and synchronized with the desired state.

**provider**

:   A simple implementation of a type; examples of package providers are dpkg and rpm, and examples of user providers are useradd and netinfo. Most often, providers are just Ruby wrappers around shell commands, and they are usually very short and thus easy to create.

**realize**

:   a Puppet term meaning to declare a virtual resource should be part of a system's catalog. See also virtual resources.

**resource**

:   an instantiation of a native type, plugin type, or definition such as a user, file, or package. Resources do not always directly map to simple details on the client -- they might sometimes involve spreading information across multiple files, or even involve modifying devices.

**resource object**

:   A Puppet object in memory meant to manage a resource on disk. Resource specifications get converted to these, and then they are used to perform any necessary work.

**resource specification**

:   The details of how to manage a resource as specified in Puppet code. When speaking about resources, it is sometimes important to differentiate between the literal resource on disk and the specification for how to manage that resource; most often, these are just referred to as resources.

**subclass**

:   a class that inherits from another class. Subclasses are useful for expanding one logical group of resources into another similar or related group of resources. Subclasses are also useful to override values of resources. For instance, a base class might specify a particular file as the source of a configuration file to be placed on the server, but a subclass might override that source file parameter to specify an alternate file to be used. A subclass is created by using the keyword inherits:

    class ClassB inherits ClassA { ... }

**templates**

:   templates are ERB files used to generate configuration files for systems and are used in cases where the configuration file is not static but only requires minor changes based on variables that Puppet can provide (such as hostname). See also distributable file.

**template class**

:   template classes define commonly used server types which individual nodes inherit. A well designed Puppet implementation would likely define a baseclass, which includes only the most basic of modules required on all servers at the organization. One might also have a genericwebserver template, which would include modules for apache and locally manageable apache configurations for web administrators:

    node mywebserver {

        include genericwebserver

    }

Template classes can take parameters by setting them in the node or main scope. This has the advantage, that the values are already available, regardless of the number of times and places where a class is included:

    node mywebserver {

        $web_fqdn = 'www.example.com'

        include singledomainwebserver

    }

This structure maps directly to a [[External Nodes|external node classifier]] and thus enables a easy transition.

**type**

:   abstract description of a type of resource. Can be implemented as a native type, plug-in type, or defined type.

**variable**

:   variables in Puppet are similar to variables in other programming languages. Once assigned, variables cannot be reassigned within the same scope. However, within a sub-scope a new assignment can be made for a variable name for that sub-scope and any further scopes created within it:

    $myvariable = "something"

Note that there are certain seemingly built-in variables, such as $hostname. These variables are actually created by Facter. Any fact presented by Facter is automatically available as a variable for use in Puppet.

**virtual resource**

:   a Puppet term for an resource that is defined but will not be made part of a system's catalog unless it is explicitly realized. See also realize.