Current trove/heat integration needs to be improved so that a stack reference gets an identity in trove ecosystem
Taking Trove and Heat integration to take a level further, the idea is to get heat-stack an identity in the trove ecosystem. If there are multiple nodes getting created based on a multi-node template provisioned for a particular service type in trove, the framework becomes slightly hazy with the following items still to be decided and worked upon:
1. Does the guest agent run on each of the nodes?
2. Do all the nodes get registered in trove db and if resin what structure/schema?
3. How does the hierarchy of instance->nodes get represented in trove and does having the heat stack-id inclusion there makes sense?
This is the second step in the heat integration which should lead to the third step of designing clustering/
Blueprint information
- Status:
- Complete
- Approver:
- None
- Priority:
- Not
- Drafter:
- None
- Direction:
- Approved
- Assignee:
- None
- Definition:
- Obsolete
- Series goal:
- None
- Implementation:
-
Unknown
- Milestone target:
-
next
- Started by
- Completed by
- Amrith Kumar
Whiteboard
I suppose that this part of heat integration relays on Trove clustering. -- dmakogon
Even for single instances we need to have heat stacks tracked somehow - hub_cap
This is decoupled from clustering/
[denis_makogon]
Task #0 - Save stack_id (High priority). https:/
Task #1 - Handle stack(resources) delete. [https:/
Task #2 - Update stack.
Task #2.1 - Resize instance via stack_update.
Task #2.2 - Resize volume via stack_update.
Task #2.3 - Update security group via stack_update.
Depends on:
- https:/
- https:/
[/denis_makogon]
Gerrit topic: https:/
Addressed by: https:/
Add stack_id for future usage
Addressed by: https:/
Update delete method for heat flow
