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
    • Pros include: Allows for advanced/correct resource modelling; allows separate resources to have their state controlled separately
    • Cons include: Difficult to find for simple clients; mixing vocabularies/imposing OSLC vocab on non-OSLC types
  • Temporary deployment: Separate state vocabulary, but used as a property on the Automation Result
    • Pros include: Easy to find
    • Cons include: Wrong place for advanced models; would need complicated/flexible OSLC-defined state model
• Actions on resources
  • Temporary deployment: “Teardown plan” property on Automation Result
    • Pros include: Easy to find; could expose arbitrary actions
    • Cons include: Wrong place for advanced models; and might cause many more resources than would otherwise be needed (could be addressed via synchronous execution or suggestion below)
  • Exposing arbitrary actions on RDF resources (generalisation of the previous suggestion)
    • Pros include: Can expose arbitrary number of arbitrary actions on any RDF resource
    • Cons include: Could make it hard for simple clients to find the teardown plan/action; and still might cause many more resources than would otherwise be needed
  • Using HTTP’s asynchronous 202 ACCEPTED status code with an autoResult response body for lightweight action execution

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 (as in the scenario above):

• Multiple clients using one deployed resource
• Teardown of an orchestrated or composed 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.