Preparing deployment plan

Solar allows you to make transitions between different versions of infrastructure based on changes found by solar control plane and events configured between this changes.

Required information

Inputs TODO link to the page with inputs

Orchestration TODO link to the page with orchestration API details

Changes

By changes in solar we understand everything that is explicitly made by user (human/program). Examples of changes are: - create resource - remove resource - update value manually - update value using hierarchy

Staged changes

On demand solar runs procedure that will find all resources changed from last deployment and will determine list of actions using transitions from solar state machine .

This procedure is performed by :

solar changes stage -d

It prints information like :

log task=openrc_file.run uid=e852455d-49d9-41f1-b49c-4640e2e19944
    ++ ip: 10.0.0.3
    ++ location_id: 694b35afa622da857f95e14a21599d81
    ++ keystone_port: 35357
    ++ transports_id: abc7745f2ad63709b5845cecfa759ff5
    ++ keystone_host: 10.0.0.3
    ++ password: admin
    ++ user_name: admin
    ++ tenant: admin
log task=neutron_db.run uid=95cac02b-01d0-4e2f-adb9-4205a2cf6dfb
    ++ login_port: 3306
    ++ encoding: utf8
    ++ login_user: root
    ++ login_password: mariadb
    ++ transports_id: abc7745f2ad63709b5845cecfa759ff5
    ++ db_name: neutron_db
    ++ db_host: 10.0.0.3
    ++ ip: 10.0.0.3
    ++ collation: utf8_general_ci
    ++ location_id: 694b35afa622da857f95e14a21599d81

At this point information is stored as a list, and user doesn't know anything about dependencies between found changes.

Events usage

For events definition see res-event-term.

Events are used during this procedure to insert dependencies between found changes, and to add new actions that are reactions for changes.

Example of dependency between changes would be nova service that depends on successful creation of database.

For removal we might add dependencies that will allow reverse order, e.g. when removing nova service and database, database will be removed only after successful nova service removal.

This can be specified as :

Dependency database1.run -> nova1.run
Dependency nova1.remove -> database1.remove

Reaction allows to construct more advanced workflows that will take into account not only changes, but also arbitrary actions for resources in solar.

Good example of usage is provisioning procedure, where reboot must be done only after node is provisioned, and dnsmasq configuration changes to reflect that that node is now using statically allocated address. We can specify such ordering as :

React node1.run -> node1.reboot
React node1.run -> dnsmasq1.change_ip
Dependency dnsmasq1.change_ip -> node1.reboot

Deployment plan construction

Using list of staged changes and graph events we can proceed with construction of deployment plan for current version of infrastructure :

solar changes process

After this deployment command plan can be viewed by :

# graphviz representation
solar orch dg last

# text report
solar orch report last

3.3 KiB Raw Blame History