Package assignment anomaly: above

[mike1813]

The relationship 'above' is used during the construction sequence to relate two hosts that are in the same virtualisation stack. This is used initially to trace through their provisioning relationships to find their physical host, so that subsequent construction patterns (and threats) can find the physical host and location for a virtual host.

Later in the construction sequence, the 'above' relationship is used to determine whether two hosts are 'inside' the same physical host or data centre. Depending on the outcome, this may trigger construction of services or reverse proxies to access data or services on one of these hosts from the other.

This relationship models an aspect of virtualisation, and should be part of package#Virtualisation.

The problem is that the 'above' relationship is used in this way to determine whether a serialised copy of data should be created on a host that stores the data. The idea is that if two hosts one of which is 'above' the other both store the same data, one will store the data which will be served to processes running on the other. This was introduced originally to handle the 'stateless' nature of K8S/Docker Containers, which is achieved by them having persistent file systems mounted via a service from a lower-level host in the virtualisation stack.

Storing a copy of data is a basic feature of package#Network, so cannot be assigned to package#Virtualisation. This forced assignment of the 'above' relationship to package#Network, which seems confusing and inappropriate.

To fix this, some rearrangement of the construction patterns for data persistence and access is needed. The simplest solution would be to introduce a self-referential 'stateless' relationship for Hosts which inhibits construction of serialised copies of data. A process running on a stateless Host would then get the data from a service (or generate a modelling error if this is not possible). Existing patterns create such a service in cases where the data should be served from below (as with data accessed from K8S/Docker Containers).