Part of: Automation Scenarios V3.

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
  • Example specific scenarios
  • Additional scenarios
• History
  • Issues
  • Suggested solutions

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.)

Actors: The User (human) interacts with the Client (OSLC consumer) which consumes the services of the Provider (OSLC provider).

• As the user
• I want the Provider to deploy an entity when the Client needs it (and only as long as it needs it)
• In order to temporarily satisfy a dependency of an operation of the Client

1. The 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 User configures the Client (such as an automation orchestrator, or a more basic client exposing automation controls) to use that automated deployment, when needed, to deploy a dependency for one of its operations (e.g. some function it performs, or another user-specified automation plan, etc).
3. The Client observes that the resources will need tearing down once completed, and asks the user to confirm that this is what they intend.
4. The User confirms that they do.
5. The Client stores the information about which automated deployment to use and the teardown requirement against its operation that will use it.
6. When the Client’s operation is to be executed, the Client requests a deployment of a resource of this type.
7. The Provider accepts the requests and starts the deployment.
8. When the deployment has completed the Client becomes aware of that, and triggers the intended usage of that deployment (e.g. automated tests).
9. When the usage of that deployment has finished, the Client notifies the Provider that the deployed resource is no longer required.
10. The Provider tears down the deployed resource, at its convenience, to free up resources.

Example specific scenarios

Here are some specific cases where this scenario would apply:

• Temporary deployment: Service virtualization example
• VM 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.

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):

• Action dialog scenarios
• Multiple clients using one deployed resource
• Teardown of an orchestrated or composed deployment

History

These sections were created when discussing this scenario for inclusion in the Automation specification, and are included here for record, but do not provide much information on implementing this scenario.

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 if a resource has already been torn down (e.g. by expiration, or by another client)
  • If the teardown is achieved via an Automation Plan, then this can be determined by looking for an Automation Result - if the provider has chosen to persist them.
• Determining when a set of deployed resources can be safely torn down

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

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; can plug the teardown plan into existing infrastructure for execution
    • 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)
    • Proposal: Automation Additional Relationships Proposal
    • Proposal: Proposal for linking to teardown plan from Result
  • 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
• Separate representations/types
  • Have a separate vocabulary or sub-domain for “long-running executions” (or “long-running services”), rather than modelling their “start” and “stop” actions using the “deployment” subdomain (which is designed for tasks that run and finish).
    • Pros include: The representation is designed for this scenario, rather than trying to retrofit it into the deployment sub-domain; we can guarantee that clients will know how to perform teardown, as they would not be able to consume the resources if they did not know the semantics of these “long-running” resource types.
    • Cons include: Lack of re-use of existing types, which means existing clients would not be able to consume it.