26.3. Data Models

Digital Rebar Provision uses several different data models to manage the task of discovering and provisioning machines in a data center.

26.3.1. Model Metadata

Virtually every model contains some embedded metadata, available under the Meta field. This data, which consists of a map of string -> string pairs, is ignored by the dr-provision server. The most common metadata fields you will see are:

The icon that the UX will use to display instances of this model. Users can choose icons from http://fontawesome.io/icons/.
The color the icon will be displayed as in the UX
The full name that the UX will use.
A comma-seperated list of strings that indicate which features are available for a model. Provision uses feature flags to help the various components and content layers to converge on a supported set of avaiable features.

26.3.2. Params.Meta has extra special behaviors in the UX

There are several meta fields that can be used to adjust on screen display for params

  • icon: [icon name] - sets the icon
  • color: [color name] - set the color
  • password: [anyvalue] - renders as password (NOT encrypted, just obfuscated)
  • clipboard: [anyvalue] - provides a copy button so user can copy the param contents to clipboard.
  • readonly: [anyvalue] - does not allow UX editing
  • render: raw - presents textarea to user instead of regular edit, does not reformat
  • render: link - adds an https://[value] link field that opens in a new tab.
  • render: machines-map - provides links and icons for machines in a UUID map.
  • downloadable: [file name] - provides download link so user can download the param contents as a file. Name of the file is the value of the Meta.downloadable.

26.3.3. Model Validation

Models also contain common fields that track the validity and availability of individual objects. These fields are:

  • Validated: a boolean value that indicates whether a given object is semantically valid or not. Semantically invalid objects will never be saved, and if one is returned via the API the Errors field will be populated with a list of messages indicating what is invalid.
  • Available: a boolean value that indicates whether the object is available to be used, not whether it is semantically valid – an object that is invaild can never be available, while an object that is not available can be semantically valid.
  • Errors: a list of strings that contain any error messages that occurred in the process of checking whether a given object is valid and available. Error messages are designed to be human readable.

Objects are checked for validity and availability on initial startup of dr-provision (when they are all loaded into memory), and thereafter every time they are updated. You must check each object returned from an API interaction to ensure that it is valid and available before using it.

26.3.4. Other Common Model Fields

Models can contain other common fields that may be present for user edification and API tracking purposes, but that do not affect how dr-provision will use or interpret changes to the objects. These extra fields are:

  • ReadOnly: a boolean value that indicates whether the object can be modified via the API. This field is set to True if the object was loaded from a read-only content layer.
  • Description: A brief description of what the object is for, how it should be used, etc. Descriptions should be one line long.
  • Documentation: A longer description of what the object is for and how it should be used, generally a few lines to a few paragraphs long. For now, only Params and Tasks have a Documentation field, but other models may add them as situations demand.