Refactor process of staging changes

Registered by Dima Shulyak

This document describes improvements related to - solar ch stage, workflow that precede's it and related data structures.

Current implementation of staging procedure has at least 2 problems:
1. No way to stage part of your changes (ex. changes that are related to named environment (tag))
2. Limited to staging changes only to next action - run/update/remove (ex. stage restart/test/any_other action)
1 item is not simple inconvenience, but a blocker to provide multi-environment support.

Instead of keeping updated flag on resource and filter resources based on this flag - move this state to separate bucket, resource tags should be copied each time when resource is added to this new bucket.

1. Create model - StagedResources with fields actions, tags (IndexedField)
2. After following actions we should insert row in StagedResources
- resource create
- resource update
- resource removal
Optionally:
- add new command to stage any other actions
3. For create/update/removal we should take into account all possible updates in childs
4. Based on list of staged resources + affected childs - generate graph of changes (solar ch process)

Blueprint information

Status:
Not started
Approver:
Dima Shulyak
Priority:
Undefined
Drafter:
Dima Shulyak
Direction:
Needs approval
Assignee:
Dima Shulyak
Definition:
New
Series goal:
None
Implementation:
Unknown
Milestone target:
milestone icon 0.3.0

Related branches

Sprints

Whiteboard

Gerrit topic: https://review.openstack.org/#q,topic:squash_rework,n,z

Addressed by: https://review.openstack.org/291675
    Rework staging procedure to support both implicit and explicit stages

Gerrit topic: https://review.openstack.org/#q,topic:add_update_action,n,z

Addressed by: https://review.openstack.org/301575
    Execute update action in case resource was already created

(?)

Work Items

This blueprint contains Public information 
Everyone can see this information.

Subscribers

No subscribers.