HistoryViewLinks to this page Revision from: 2014 January 27 | 10:32 am
This is the revision from 2014 January 27 at 10:32 amView the current live version of the article.

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


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

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
  • Actions on resources
  • 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.