pg record

Overview

This resource allows you to manage a record in an Postgres database table.

Use pg_record to make sure a record with a specified primary key exists in the specified table. Here is an exaple:

pg_record{'set_external_service_name/db@instance':
  ensure     => 'present',
  table_name => 'CONFIG_DATA',
  key_name   => 'CONFIG_ID',
  key_value  => 10,
  role       => 'postgres_role',
  password   => 'verysecret',
  data       => {
    'CONFIG_NAME'  => 'service_name',
    'CONFIG_VALUE' => 'http://external.data-server.com',
    ...
  }
}

This Puppet code tells you that the table CONFIG_DATA from user postgres_user must contain a record where the primary key CONFIG_ID is 10`. If Puppet notices that this record doesn’t exist, It will create the record and fill its data with the data specified in the data property. If Puppet sees that the key already exists, it does nothing. This code will make sure your database contains the record, but it will not ALWAYS set the data. This code is useful for example in use cases where there is a set of management screens to manage these settings. Puppet makes sure the setting exists, but will leave the settings as they are after the system is running and applications managers might have changed the values.

If you always want to make sure the record contains the specified data, use updated for the ensure property.

pg_record{'set_external_service_name/db@instance':
  ensure     => 'updated',
  table_name => 'CONFIG_DATA',
  role       => 'postgres_USER',
  password   => 'verysecret',
  key_name   => 'CONFIG_ID',
  key_value  => 10,
  data       => {
    'CONFIG_NAME'  => 'service_name',
    'CONFIG_VALUE' => 'http://external.data-server.com',
    ...
  }
}

Now Puppet will not only check if the record exists, but it will also always make sure the specified columns contain the specified values. If there are columns you don’t want to manage, then just leave them blank.

Attributes

data

The data in the row specified as an hash.

Back to overview of pg_record

db

database to connect to.

Back to overview of pg_record

disable_corrective_change

Disable the modification of a resource when Puppet decides it is a corrective change.

(requires easy_type V2.11.0 or higher)

When using a Puppet Server, Puppet knows about adaptive and corrective changes. A corrective change is when Puppet notices that the resource has changed, but the catalog has not changed. This can occur for example, when a user, by accident or willingly, changed something on the system that Puppet is managing. The normal Puppet process then repairs this and puts the resource back in the state as defined in the catalog. This process is precisely what you want most of the time, but not always. This can sometimes also occur when a hardware or network error occurs. Then Puppet cannot correctly determine the current state of the system and thinks the resource is changed, while in fact, it is not. Letting Puppet recreate remove or change the resource in these cases, is NOT wat you want.

Using the disable_corrective_change parameter, you can disable corrective changes on the current resource.

Here is an example of this:

crucial_resource {'be_carefull':
  ...
  disable_corrective_change => true,
  ...
}

When a corrective ensure does happen on the resource Puppet will not modify the resource and signal an error:

    Error: Corrective change present requested by catalog, but disabled by parameter disable_corrective_change
    Error: /Stage[main]/Main/Crucial_resource[be_carefull]/parameter: change from '10' to '20' failed: Corrective change present requested by catalog, but disabled by parameter disable_corrective_change. (corrective)

Back to overview of pg_record

disable_corrective_ensure

Disable the creation or removal of a resource when Puppet decides is a corrective change.

(requires easy_type V2.11.0 or higher)

When using a Puppet Server, Puppet knows about adaptive and corrective changes. A corrective change is when Puppet notices that the resource has changed, but the catalog has not changed. This can occur for example, when a user, by accident or willingly, changed something on the system that Puppet is managing. The normal Puppet process then repairs this and puts the resource back in the state as defined in the catalog. This process is precisely what you want most of the time, but not always. This can sometimes also occur when a hardware or network error occurs. Then Puppet cannot correctly determine the current state of the system and thinks the resource is changed, while in fact, it is not. Letting Puppet recreate remove or change the resource in these cases, is NOT wat you want.

Using the disable_corrective_ensure parameter, you can disable corrective ensure present or ensure absent actions on the current resource.

Here is an example of this:

crucial_resource {'be_carefull':
  ensure                    => 'present',
  ...
  disable_corrective_ensure => true,
  ...
}

When a corrective ensure does happen on the resource Puppet will not create or remove the resource and signal an error:

    Error: Corrective ensure present requested by catalog, but disabled by parameter disable_corrective_ensure.
    Error: /Stage[main]/Main/Crucial_resource[be_carefull]/ensure: change from 'absent' to 'present' failed: Corrective ensure present requested by catalog, but disabled by parameter disable_corrective_ensure. (corrective)

Back to overview of pg_record

ensure

absent, present or updated.

when present is specified, it will just check if the primary key record is available. If it is, nothing will be done. When you specify ‘updated’, puppet will ensure the data is as specified in the data property of the puppet definition.

Valid values are present, updated, absent.

Back to overview of pg_record

instance

Postgres instance to connect to.

All types have a name like resource@instance.

Back to overview of pg_record

key_name

The column name of the primary key.

Back to overview of pg_record

key_value

The key value of the record to manage.

Back to overview of pg_record

name

A name for the record and the table to manage.

This can be any name you like.

Example:

pg_record { 'just_a_name':
  ...
}

Back to overview of pg_record

password

The user’s password.

Back to overview of pg_record

provider

The specific backend to use for this pg_record resource. You will seldom need to specify this — Puppet will usually discover the appropriate provider for your platform.Available providers are:

psql

Manage a record in an Postgres table via regular SQL

Back to overview of pg_record

role

The owner of the table.

If none is specified, it will connect as the user specified in pg_instance.

Back to overview of pg_record

table_name

The table name.

Back to overview of pg_record