This section contains the glossary for the Senlin service.
An action is an operation that can be performed on a Cluster or a Node etc. Different types of objects support different set of actions. An action is executed by a Worker thread when the action becomes READY. Most Senlin APIs create actions in database for worker threads to execute asynchronously. An action, when executed, will check and enforce Policy associated with the cluster. An action can be triggered via Receiver.
- API server¶
HTTP REST API service for Senlin.
A cluster is a group of homogeneous objects (i.e. Node). A cluster consists of 0 or more nodes and it can be associated with 0 or more Policy objects. It is associated with a Profile Type when created.
The Action objects are stored into database for execution. These actions may have dependencies among them.
A dispatcher is a processor that takes a Senlin Action as input and then converts it into a desired format for storage or further processing.
A driver is a Senlin internal module that enables Senlin Engine to interact with other OpenStack services. The interactions here are usually used to create, destroy, update the objects exposed by those services.
The daemon that actually perform the operations requested by users. It provides RPC interfaces to RPC clients.
An event is a record left in Senlin database when something matters to users happened. An event can be of different criticality levels.
A node is an object that belongs to at most one Cluster. A node can become an ‘orphaned node’ when it is not a member of any clusters. All nodes in a cluster must be of the same Profile Type of the owning cluster. In general, a node represents a physical object exposed by other OpenStack services. A node has a unique Index value scoped to the cluster that owns it.
Open source software for building private and public clouds.
A plugin is an implementation of a Policy Type or Profile Type that can be dynamically loaded and registered to Senlin engine. Senlin engine comes with a set of builtin plugins. Users can add their own plugins by customizing the Environment configuration.
A policy is a set of rules that can be checked and/or enforced when an Action is performed on a Cluster. A policy is an instance of a particular Policy Type. Users can specify the enforcement level when creating a policy object. Such a policy object can be attached to and detached from a cluster.
- Policy Type¶
A policy type is an abstraction of Policy objects. The implementation of a policy type specifies when the policy should be checked and/or enforce, what profile types are supported, what operations are to be done before, during and after each Action. All policy types are provided as Senlin plugins.
A profile is a mould used for creating objects (i.e. Node). A profile is an instance of a Profile Type with all required information specified. Each profile has a unique ID. As a guideline, a profile cannot be updated once created. To change a profile, you have to create a new instance.
- Profile Type¶
A profile type is an abstraction of objects that are backed by some Driver. The implementation of a profile type calls the driver(s) to create objects that are managed by Senlin. The implementation also serves a factory that can “produce” objects given a profile. All profile types are provided as Senlin plugins.
A receiver is an abstract resource created at the senlin engine that can be used to hook the engine to some external event/alarm sources. A receiver can be of different types. The most common type is a Webhook.
A role is a string property that can be assigned to a Node. Nodes in the same cluster may assume a role for certain reason such as application configuration. The default role for a node is empty.
A webhook is an encoded URI (Uniform Resource Identifier) that for triggering some operations (e.g. Senlin actions) on some resources. Such a webhook URL is the only thing one needs to know to trigger an action on a cluster.
A worker is the thread created and managed by Senlin engine to execute an Action that becomes ready. When the current action completes (with a success or failure), a worker will check the database to find another action for execution.