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 Puppet native that defines a container of resources, such as

    File resources, Package resources, User resources, custom-defined

    resources (see also [[Glossary\_Of\_Terms#defined-type|Glossary Of

    Terms]] ), etc. A class can inherit from another class using the

    inherits keyword.

**client**

:   An operating system instance managed by Puppet. This can be an

    OS running on its own hardware or a virtual image.

**components**

:   See [[Glossary\_Of\_Terms#defined-type|Glossary Of Terms]] .

**declare**

:   a declaration is a term used to indicate where an resource is

    first defined. Not to be confused with terminology:definitions

**defined type**

:   a Puppet term for Puppet resources defined at the application

    level. Defined types are created in the Puppet language and are

    analogous to macros in some other languages. Also sometimes called

    *definitions* or *components*.

**definition**

:   See [[Glossary\_Of\_Terms#defined-type|Glossary Of Terms]] .

**distributable file**

:   distributable files are static configuration files that the

    Puppet client copies over in its entirety as needed. For instance,

    when using File with a specific source (as opposed to a template):

:       file { "/etc/somefile": source => "dist/blah/somefile" }

:   See also [[Glossary\_Of\_Terms#templates|Glossary Of Terms]]

    .

**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]] ).

**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

    docs 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.

**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"] }

        }

**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

    [[Glossary\_Of\_Terms#virtual-resource|Glossary Of Terms]] .

**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 config 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 node classifier](http://reductivelabs.com/trac/puppet/wiki/ExternalNodeClassification)

    and thus enables a easy transition.

**type**

:   abstract description of a type of resource. Can be implemented

    as a [[Glossary\_Of\_Terms#native-type|Glossary Of Terms]] ,

    [[Glossary\_Of\_Terms#plugin-type|Glossary Of Terms]] , or

    [[Glossary\_Of\_Terms#defined-type|Glossary Of Terms]] .

**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

    [[Glossary\_Of\_Terms#fact|Glossary Of Terms]] 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 [[Glossary\_Of\_Terms#realize|Glossary Of Terms]] .