Stop instance workflow to conductor
Begin transfer of conductor workflow for stopping a instance which is done inside the compute manager to being managed by the conductor task management layer. To start moving this workflow to be 'conducted' vs locally applied we need to begin the transfer (and likely refactor) of logic from where it is now to the conductor (with a light-weight task-receiver that will still exist in the compute manager to fulfill conductor requests).
Blueprint information
- Status:
- Complete
- Approver:
- Russell Bryant
- Priority:
- Undefined
- Drafter:
- Joshua Harlow
- Direction:
- Needs approval
- Assignee:
- None
- Definition:
- Obsolete
- Series goal:
- None
- Implementation:
-
Unknown
- Milestone target:
- None
- Started by
- Completed by
- Russell Bryant
Related branches
Related bugs
Sprints
Whiteboard
Deferred to icehouse-3 as the blueprint was not approved by the icehouse-2 blueprint approval deadline. --russellb
RB: stopping an instance is incredibly light compared to the other things that we have been moving to conductor. . What do you envision as the split of what is done in conductor vs compute? --russellb
JH: so this really depends on the desired 'vision' of conductor, there is error handling that is being done in compute around the stop_instance call, if the conductor is going to be a place where actions are conducted then the initial call and most of the error handling would likely be moved there. It is very light, but that's good in that its an easy one to tackle (especially for someone new) and it can serve as a light example to others looking on helping move logic to conductor. The only existing example, LiveMigrationTask, is a heavy-weight example (and is also unfinished) so it seems like a bad example for others to follow (this may change once it is finished). Having at least 1 task that is simple and understandable (even if incredibly light) would make it easier for others to follow in the examples footsteps.
I'm still not convinced there's value in using the conductor for this. We can discuss more on the -dev list, though. --russellb
Work Items
Dependency tree
* Blueprints in grey have been implemented.
