Object Transformation

Every orchestrator has its own set of abstractions – thus, an independent framework must provide a mechanism for transforming objects between its own structure and the native structure of each supported orchestrator. To this end, SLO Script provides a transformation service that allows each orchestrator-specific connector library to register transformers for those object types that require transformation, while directly copying those objects that do not require any transformation. The transformation is not limited to the type of the root object, instead the appropriate transformer is applied to every nested object recursively.

The transformation service does not serialize to the data format required by the orchestrator (e.g., JSON or YAML). It transforms the instances of the orchestrator-independent SLOC classes into plain JavaScript objects, which can subsequently be serialized by the orchestrator-specific connector library. The deserialization of objects received from the orchestrator is also left to the connector library. It needs to supply plain JavaScript objects to the transformation service, which transforms the objects and creates instances of SLO Script classes.

The SLO Script object model is heavily influenced by that of Kubernetes, but the two are not equal. For example, in Kubernetes there is no objectKind property on an object returned from the API. Instead, a Kubernetes API object contains an apiVersion and a kind property, with the former being a combination of the SLO Script group and version attributes of ObjectKind and the latter being equal to ObjectKind.kind.

To transform an SLO Script ObjectKind into its corresponding Kubernetes version, the SLO Script Kubernetes connector library registers a transformer for ObjectKind, which returns a plain JavaScript object with the group and version attributes combined into a single apiVersion attribute and a copy of the kind attribute.

This alone is not enough because Kubernetes objects do not contain an ObjectKind property. Thus, the SLOC Kubernetes connector library also registers a transformer for the ApiObject class, which uses the transformation service to first transform the ObjectKind object and then embeds the contents of the result into a new object, which is going to become the final transformed ApiObject. The objects stored in the metadata and spec attributes are also first transformed and then stored in the result object.

The Figure above, shows an example of how a CostEfficiencySloMapping looks before and after being transformed to a Kubernetes object. The transformation techniques used for the SLO Script framework classes also apply to custom classes written by service providers for their SLOs. The next Section will explore the runtime facilities, which are responsible for executing the defined SLOs.