HistoryViewLinks to this page Revision from: 2013 June 6 | 06:27 am
This is the revision from 2013 June 6 at 06:27 amView the current live version of the article.

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


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

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:

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.