Apache ARIA Service Proxy Plugin

Introduction

The Apache ARIA project, is an OASIS TOSCA Simple YAML 1.0 reference implementation that includes a CLI and orchestration/execution engine. With it, TOSCA YAML service templates can be parsed and validated, instantiated, and have workflows run against them. Like Cloudify, the orchestration engine is extensible via plugins. This post is about the implementation and features of one such plugin which has a similar counterpart in Cloudify, the ARIA Service Proxy Plugin.

Rationale

TOSCA concerns itself with defining service templates, which contain a model of a given deployment structure or stack. TOSCA also defines normative operations (e.g. create, configure, start..) for template components (nodes) which an orchestrator can call to produce desired effects (e.g. install, uninstall). TOSCA also define a form of template composition known as substitution mapping. Substitution mapping permits the construction of service templates that can expose a simple interface for reference by other service templates. For example, a database service template, including compute and networking configuration, can be consumed by another template as a single TOSCA node.

TOSCA provides no means for composing services with independent life cycles. In the substitution mapping discussion above, the inclusion of the database template in the consuming template means that when the consuming template is realized, the database will also be realized. Conversely, when the consuming template is unrealized, the database will be destroyed. It is desirable to have a convenient means of orchestrating services with independent lifecycles so, for example, stacks that are clients can be created, destroyed, scaled, and updated at will without impacting an associated running service. One obvious approach to this problem is to define custom TOSCA types for each target service. A more convenient approach is to exploit the outputs feature of template services. Outputs are optionally exposed data that a service can provide (for example a public IP or URL). Outputs can be used as a means to allow the construction of templates that have proxy references to independent, TOSCA managed, running services.

Features

The service proxy needs to identify a target service, gather the outputs from the service, and expose them for use by the enclosing service. Since a service's existence doesn't mean it is realized (or installed), the proxy needs to be able to detect the status of the target service. Also, since the target service is completely independent, and outputs are dynamic, the proxy needs to be flexible regarding gathering of the service outputs. Given these requirements, the service proxy plugin provides following features:

• A service_name property to identify the target service. This is the name of the service given when instantiated.
• A property defining a list of output names, to constrain what is retrieved from the target service.
• A wait_config complex property, that defines whether to wait, what to wait for, and how long to wait for the service and/or outputs to become available.
• A last_updated attribute, which indicates the time the outputs were retrieved.
• A service_outputs attribute, which contains the list of retrieved outputs.

Detailed Comments

Output Names