DataModel_02Properties

The SOMA data model - 2. Properties

When created, objects in SOMA are at the same time:

1. fully specified
2. contain only the bare minimum of information

This means for any given object, there are no optional unset fields that can be used to specify some additional piece of specific information. Which in turn means that it is not possible to specify additional fields.

To further specify objects SOMA provides properties that can be attached dynamically.

Properties

Properties are either key/value pairs or dictionaries of key/value pairs that can be attached to an object. The different types of properties provided are:

1. service
2. system
3. oncall
4. custom
5. native

Service Property

Service properties are dictionaries of key/value pairs called attribute. The available attribute keys that can be used to assemble a service are a global namespace, ie. are shared between all services.

Service definitions are per team. Every attribute has a cardinality that specifies if a service can have this attribute once or more than once.

Example services:

somaadm attributes create uid cardinality once
somaadm attributes create transport_protocol cardinality multi
...

somaadm property create service unbound
  transport_protocol tcp
  transport_protocol udp
  port 53
  process_comm unbound
  process_args '/usr/sbin/unbound'
  file_path '/etc/unbound/unbound.conf'
  team 'Generic Operations Engineering Team'

somaadm property create service OpenSSH
  transport_protocol tcp
  port 22
  process_comm sshd
  file_path '/etc/ssh/sshd_config'
  software_provider 'OpenBSD'
  uid 0
  application_protocol 'SSHv2'
  team 'Generic Operations Engineering Team'

System Property

System properties are key/value pairs with global, predefined keys.

For every defined system property key the system has a validity specification that further describes that property. It specifies if an object can have this property:

1. directly by setting it on the object
2. via inheritance

An unspecified validity defaults to false. For example, this is the validity specification for the system property cluster_state:

somaadm property create system cluster_state

somaadm validity create cluster_state on cluster
  direct true
  inherited false

somaadm validity create cluster_state on node
  direct false
  inherited true

This results in the following:

1. repositories can not have a cluster_state
2. buckets can not have a cluster_state
3. groups can not have a cluster_state
4. clusters can only have a cluster_state if the property is set on them
5. nodes can only have a cluster_state by being a member of a cluster and inheriting the value

Oncall Property

Oncall properties are used to assign oncall duty teams to the tree.

Custom Property

Custom properties are arbitrary, per-repository key/value pairs that can be freely defined. They do not have a validity specification and can be used anywhere in the tree.

Native Property

Native properties are introspection meta properties, ie. they can not be assigned but can be used to make inquiries about the tree itself. These are the most inflexible since they must be handled in code and can not be defined at runtime.