21.3. Data Models

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

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

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

Meta fields that can be used to adjust on screen display for params in the Portal. See Object.Meta for details.

Additional meta fields can be used to alter cluster and resouce broker operations

  • no-cluster: "true" - tells the cluster and resource broker create that this parameter or profile should NOT be added to the special profile during create.

21.3.3. Machines.Meta has extra special behaviors

Additional meta fields can be used to alter context operations on Machines, Clusters, and ResourceBrokers.

  • BaseContext: context - lets DRP know what the base context is for the machine when going back to a known context

  • machine-role - lets DRP know what the type of machine this object is. Values can be: self, machine, cluster, or resource-broker.

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

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