Temporary deployment scenarios (tear-down and multiple use)

The results of some automated deployment is temporary, and requires a tear down or clean up stage once it is no longer required. The behaviour of this usage differs depending on whether it is one client or multiple clients who are using the deployed resource.

Contents

• Temporary deployment scenarios (tear-down and multiple use)
  • Scenario
  • Suggested solutions
  • Additional scenarios
  • Issues

Scenario

(The wording of this scenario intentionally avoids suggestion a particular solution, or even linking concepts from the scenario to existing concepts in the v2 spec.)

1. A Provider exposes the capability of automated deployment for a particular type of resource. Once deployed, these resources are required to be torn down once they are no longer needed.
2. The Client (such as an automation orchestrator, or a more basic client exposing automation controls) requests a deployment of a resource of this type.
3. The Provider accepts the requests and starts the deployment.
4. When the deployment has completed the Client becomes aware of that, and triggers the intended usage of that deployment (e.g. automated tests).
5. When the usage of that deployment has finished, the Client notifies the Provider that the deployed resource is no longer required.
6. The Provider tears down the deployed resource, at its convenience, to free up resources.

Example: One of the Amazon EC2 charging models is to charge per hour of uptime, so the longer the VM is deployed the more it costs. This is a strong reason for wanting to tear down at the end of use, compared to the traditional deploy of a build or similar which can sit on the machine until the next deploy occurs.

Suggested solutions

• State model
  • Temporary deployment: Automation Result state
    • (This was part of the original suggestions, but has been superseded by the concept of a separate property for teardown state, below)
  • Temporary deployment: State property on Automation Result contribution
  • Temporary deployment: Separate state vocabulary, but used as a property on the Automation Result
• Actions on resources
  • Temporary deployment: “Teardown plan” property on Automation Result

Additional scenarios

There are additional scenarios that would require additional thought, or would only be useful, given the introduction of a well-defined means of tearing down deployed resources:

• Multiple clients using one deployed resource
• Teardown of an orchestratedcomposed deployment

Issues

• Distinguishing which results must be torn down when finished, which can be torn down but don’t need to be, and which can’t.
  • Suggestions: Property to indicate this, or a subtype of automation plan?
• [Informative] If the Provider is charging the Client based on its usage of the deployed resource, then the charging should probably stop at the point the teardown is requested, not the point at which it is torn down. i.e. generic providers should probably record when the clients no longer require the deployed resource, in case other components are calculating cost.
• Expiration of deployed resources
• Determining when a set of deployed resources can be safely torn down

There are also issues on the additional scenarios pages for those scenarios.