solar/doc/source/glossary.rst
Łukasz Oleś d965a988c1 Refactor VirtualResources
- rename VirtualResource to Composer
- rename event parameter depend_action to child_action
- rename values parameter to input

Closes-bug: #1526780

Change-Id: Ib974e14ff4bda44c2d7d991f62aa4a06dea160ea
2015-12-29 16:50:46 +01:00

3.7 KiB

Solar Glossary

Resource

Resource is an abstraction of item in system managed by Solar. It's a basic building block used to assemble your system. Almost every entity in Solar is a resource.

You can learn more about it in resource details <resource_details>

Input

Resource configuration that will be used in actions, handlers and orchestration. All known inputs for a resource should be defined in meta.yaml

Connection

Allows to build hierarchy between inputs of several resources, parent value will be always used in child while connection is created. If connection is removed - original value of child will be preserved.

Action

Solar wraps deployment code into actions with specific names. Actions are executed from the resource.

Tag

Used to create arbitrary groups of resources, later this groups will be used for different user operations.

Resource Repository

It is a named location where different resource-term are located.

Handler

Layer responsible for action execution and tracking results.

Transport

Used in handlers to communicate with hosts managed by Solar.

More details about transports <transports_details>

location_id

Used in transport layer to find ip address of a node. :

'location_id': '96bc779540d832284680785ecd948a2d'

transports_id

Used to find transports array that will be used for transport selection. :

'transports_id': '3889e1790e68b80b4f255cf0e13494b1'

BAT transport

According to preferences solar will choose best available transport for file uploading and command execution.

Event

Used in solar to describe all possible transitions between resources changes. Each event allows to specify two points of transitions, condition of this transition and type of event.

Right now we are supporting 2 types of events:

  1. Dependency - inserts edge between 2 changes into the deployment plan.
  2. Reaction - inserts change specified in reaction and makes edge between parent and child.

Example :

type: depends_on
parent: nova-db
parent_action: run
child: nova-api
child_action: run
state: success // condition

Composer

Composition layer that allows user to:

  • group resources
  • specify connections between inputs
  • add list of events

System log component

Component responsible for tracking changes and keeping ordered history of them.

Staged log

Based on user changes - solar will create log of staged changes. This log will be used later to build deployment plan.

History

After action that is related to change will be executed - it will be moved to history with same uuid.

Committed resource data

After each successful change committed copy of resource data will be updated with diff of that change.

Orchestration component

Deployment plan

Based on changes tracked by system log and configured events - solar build deployment plan. In general deployment plan is built with :

solar ch process

And can be viewed with :

solar or dg last

Deployment plan operations

Solar cli provides several commands to work with deployment plan.

  • run-once
  • report
  • stop
  • resume/restart/retry

See also orchestration