113 lines
3.3 KiB
ReStructuredText
113 lines
3.3 KiB
ReStructuredText
.. _deployment_plan:
|
|
|
|
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 :ref:`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
|
|
|