framework: Resource Manager #29
Conversation
|
Is the idea that all shared resources that are created during a deployment, like the docker network and ecs cluster/execution role, will not implement destroy logic so that they don’t get torn down during a failed deployment? |
https://docs.google.com/document/d/14wq7f0NsbrA7wOAk5znE0iKN16lfx8hRRswkyVjcH8E/edit# 😄 |
| r := m.Resource(cs.Order[i]) | ||
| if r == nil { | ||
| // We are missing a resource that we should be destroying. | ||
| return fmt.Errorf( |
There was a problem hiding this comment.
Should we destroy the resources that we can, and then return the final error at the end saying what was missed? Or is the assumption that once we hit a missing resource, the rest are also probably in a weird state?
There was a problem hiding this comment.
Ah nevermind, I see this relates to the Rollback section in the RFC.
There was a problem hiding this comment.
Yeah honestly this is a weird edge case in this whole thing... I think some experience implementing and iterating on plugins will better inform what our behavior should be here. I could see arguments either way.
This introduces the resource manager framework to the Waypoint plugin SDK. The resource manager is a higher level package that allows plugins to compose operations using a set of "resources" (i.e. individual security groups, load balancers, etc.). The resource manager creates/destroys these as a unit and performs rollbacks as necessary.
The Waypoint server is unaware of resources. This framework eventually just serializes all the state down to the single operation. In the future, we want to make the Waypoint server aware of resources directly. This will be a building block towards that.
An example of the usage can be seen here: https://github.com/hashicorp/waypoint/compare/docker-resources