Solum/FeatureBlueprints/Definitions



Assembly: An application at runtime. This is a collection of all the  of an application. Think of this as the running application including all the stuff it relies on (databases, load balancer setup, etc.). Every Assembly has at least one.

Component: A part of your application that you want to be able to manage through Solum (start, pause, resume, delete, etc.). These are grouped into an.

Service: Something offered by the platform which can be referenced as part of the deployment plan. These often become  when the application is deployed. Some services will run / host / be configured by artifacts supplied by the user (e.g. a database initialised with a SQL script, or a web container hosting a WAR file), whereas some will not require any such artifact (e.g. an object store). Services may run in a single OS container, or they might run in multiple OS containers (elastic or otherwise), or they might be completely external.

Sensor: The  resource represents dynamic data that can be collected from a resource through the API. For example, statistics about the access rate of a resource (usually a ). Sensors can be added to,  , or   resources.

Operation: The  resource represents an action that can be taken on a resource through the API. Operations can be added to,  , or   resources.

Deployment Unit: (or OS container ?): A deployment unit (DU) is a unit of deployment for the application being deployed into an. For example, if Solum is configured to use containers for deploying application code, then the a DU would refer to a container instance. A deployment unit could be a Docker container, an LXC container, a VM, or something else. (NOTE: I've suggested "OS Containers" instead, as that means something to me in a way that "DU" does not. BTW my reading of the word "container" is a web container, not an OS container!)

Plan: A description of how to generate an  to run an application. (Sometimes called a deployment plan.)

Build: A Solum service that builds/tests the  in accordance with the instructions in the   to produce an   for deployment. The  generated will normally be a container image to be used within the.

Repo: A hosted location where the source code for an application is stored. It may be internal to Solum, or externally hosted through a supported SCM API.

Application (proposed): An application represents the raw ingredients of an application, i.e. the things which become an Assembly. It consists of a Deployment  plus a set of artifacts or a code repository and build instructions. It may also link to the assemblies generated from it (which may be more than one in different environments -- e.g. dev/staging/prod -- when we get in to lifecycle management).

Common actions
 * Register: registers a new application in Solum and associates it with the user ( no application code is copied; no deployment is performed, yet).
 * Deploy: deploys the application bits and generates a running application in an . Associates dependent services as needed. Builds the application bits from code if required.
 * Build: builds the application, but does not create an  to run it in. This is used for build-once-deploy-many use cases.