DataModel_04Inheritance

The SOMA data model - 4. Inheritance

The principal UX misunderstanding we observed in previous systems was that if something was defined on for example a cluster, the implicit understanding was this would propagate down the tree.

For this reason, SOMA is to a large part mainly a tree based inheritance engine.

Overmodelling

SOMA trees are inheritance trees, not documentation trees. The goal is to have all properties available where they need to be. If they end up at a few additional locations where they make neither sense nor harm, not too much effort should be expended into optimizing this.

Inheritance-Tree vs. Dependency-Graph

Inheritance of monitoring data in a dependency graph is a problem, since that graph could potentially go from a customer service over multiple front-, middle- and backend system all the way to some data persistence layer.

A monitoring configuration attached to the frontend, expecting externally reachable IP address space will have a hard time producing meaningful results once it has propagated down to a deep internal database cluster.

Where a dependency graph system will have few deep graphs, an inheritance tree system will naturally converge to more graphs that are both broader and more shallow.

Regular Inheritance

Property inheritance is enabled by default. It has to be explicitly disabled when assigning the property:

somaadm nodes property add system dns_zone
  to foonode01
  view any
  value example.org
  inheritance false

Otherwise all children of the object, if it has any, inherit the property.

ChildrenOnly inheritance

ChildrenOnly inheritance is a special inheritance case, in which the property is attached to an object, but only active on the children that inherited it.

ChildrenOnly is disabled by default and has to be explicitly enabled.

The intended usecase for this is so that properties that make no sense on a cluster but are the same for all nodes of the cluster can be set once on the cluster.

somaadm clusters property add system dns_zone
  to FooService
  in common_master
  view any
  value domain.local
  childrenonly true

Overriding Inheritance

As previously mentioned, in the same view an object can only have a property once. This is to allow overriding inherited properties or allow stopping inheritance mid-tree.

If a property were allowed multiple times, the semantics if the new property is intended as addition or as replacement would get confusing.

If a property is set on an object that already has that property, if that existing property has been inherited, the inherited property will be removed from the object and all its children. The new property will instead be set and inherited down to all children.

By changing the value, the inheritance can be overwritten. By setting a property with the same value but disabled inheritance, the inheritance can be stopped.

If a property, while being inherited down the tree, encounters a child object that already has this property in the same view locally set, then the inheritance in that tree branch will stop. The result is that for override, the order of property assignments is not relevant.