x/solar
Code Issues Proposed changes

Docs: commit-log update

Browse Source
This commit is contained in:
Przemyslaw Kaminski 2015-05-22 13:52:15 +02:00
parent 558b6684ae
commit bbb856e4ad
1 changed files with 12 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

13
docs/commit-log.md
View File

@ -28,7 +28,10 @@ if previous state is some `A` and new state is `None` the action will be `remove
The 'appropriate order' taken by orchestrator can be just like the data flow graph initially. We The 'appropriate order' taken by orchestrator can be just like the data flow graph initially. We
see possibility of optimizing the number of actions taken by orchestrator so that moving Keystone see possibility of optimizing the number of actions taken by orchestrator so that moving Keystone
service to another node can be simplified from 4 actions taken to 3 actions. service to another node can be simplified from 4 actions (update HAProxy without removed Keystone,
install Keystone on new node, update HAProxy with new Keystone, remove Keystone from old node)
taken to 3 actions (add Keystone to new node, update HAProxy removing old Keystone and adding
new one, remove Keystone from old node).
After resource action is finished the new state is saved to the commit log and data is updated in After resource action is finished the new state is saved to the commit log and data is updated in
the DB. the DB.
@ -42,6 +45,14 @@ So in other words -- we change the data in one resource according to what is in
back and then we trigger changes in other connected resources. Then we run orchestrator actions like back and then we trigger changes in other connected resources. Then we run orchestrator actions like
described above. described above.
In case of single commit log for all resources -- is it sufficient to just rollback a commit? Or
do we need to trigger changes in connected resources too? In global commit log we have ordering
of commits like they were run by orchestrator.
From analysis of resource removal we think that we need to save connection data in each commit -- From analysis of resource removal we think that we need to save connection data in each commit --
otherwise when we rollback that resource removal we wouldn't know how to restore its connections otherwise when we rollback that resource removal we wouldn't know how to restore its connections
to other resources. to other resources.
Single commits after every action finished on a resource causes many commits per one user 'apply'
action. In order to allow user to revert the whole action and not just single commits we have some
idea of 'tagging' group of commits by some action id.