Revision: Temporary deployment scenarios

New here? Sign up!

Sort of a ghost town here
Active specification development is now at Automation TC

Want to contribute?

Mailing list

Workgroup information

History View Links to this page Revision from: 2014 January 29 | 07:00 am

This is the revision from 2014 January 29 at 07:00 am View 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

Temporary deployment scenarios (tear-down and multiple use)
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

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.
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).
The Client observes that the resources will need tearing down once completed, and asks the user to confirm that this is what they intend.
The User confirms that they do.
The Client stores the information about which automated deployment to use and the teardown requirement against its operation that will use it.
When the Client’s operation is to be executed, the Client requests a deployment of a resource of this type.
The Provider accepts the requests and starts the deployment.
When the deployment has completed the Client becomes aware of that, and triggers the intended usage of that deployment (e.g. automated tests).
When the usage of that deployment has finished, the Client notifies the Provider that the deployed resource is no longer required.
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):

Example

This is a worked example using the OSLC Actions 2.0 and OSLC Automation 2.1 specifications.

Configuration phase

The user creates an empty automated process definition in the consumer. The user opts to add a deployment plan to the process.

The consumer allows the user to select a deployment plan in the usual way: The consumer shows the user a list of the automation providers that it is configured with, and the user selects an oslc:ServiceProvider from one of these. The consumer looks for the service(s) in that service provider that identify themselves as the “deployment” sub-domain (oslc:usage oslc_auto:Deploy) and displays to the user a list of all Automation Plan selection dialogs it finds in those services. The user selects one based on its name. The consumer displays this dialog, and the user selects an Automation Plan and submits the dialog.

The consumer looks for an oslc_auto:TemplateDialog that would be appropriate for creating a template AutomationRequest for this plan, looking in the service provider already selected. It finds one, so displays this dialog to the user. (If it did not find one, it would construct an AutomationRequest programmatically.) The user fills in and submits the dialog. The provider returns the URI of the Automation Request to the consumer as the return value of the dialog. (This Automation Request resource itself will never executed, as it was created from an oslc_auto:TemplateDialog. It may or may not be persisted for long. The semantics of this request will only get executed when a new Automation Request resource is created by POSTing a copy of this resource’s representation to a standard Creation Factory in the execution phase.)

The consumer performs an HTTP GET on the URI it received:

@base <http://example.com/> .
@prefix oslc_auto <http://open-services.net/ns/auto#> .
@prefix oslc <...> .
@prefix dcterms <...> .

<plans/1/requests/nonexec/12345>
   a oslc_auto:AutomationRequest ;
   dcterms:title     "Deploy pattern 1" ;
   dcterms:identifier "1:nonexec/12345" ;
   oslc_auto:state   oslc_auto:new ;
   oslc_auto:executesAutomationPlan <plans/1> ;
.

The consumer stores this Automation Request representation (as a byte array, along with the value of the Content-Type HTTP header) in the automated process definition step that the user is currently authoring. The consumer performs an HTTP GET on the Automation Plan:

@base <http://example.com/> .
@prefix oslc_auto <http://open-services.net/ns/auto#> .
@prefix oslc <...> .
@prefix dcterms <...> .

<plans/1>
    a oslc_auto:AutomationPlan ;
    dcterms:title "Deploy pattern 1" ;
    dcterms:identifier "1" ;
    oslc_auto:futureAction <plans/1/future-stop> ;
.

<plans/1/future-stop>
    a oslc:Action, oslc:TeardownAction ;
    dcterms:title "Tear down pattern 1" ;
.

In this scenario the consumer is familiar with future actions (this was taken as a design decision when it was implemented - should this be in a specification profile?), so it recognises that results that are generated by executing this deployment plan will have an action called “Tear down pattern 1”, and it knows this is a teardown plan as it is of type oslc:TeardownAction.

The consumer asks the user if it wants the resource that will be deployed when this deployment plan is executed to be torn down once the automated process that the user is currently authoring completes its execution. The user indicates “yes”.

The consumer stores the URI of the oslc:TeardownAction future action resource in a new “teardown step” at the end of the automated process description that the user is authoring. It also stores a link from this step to the deployment step that it was created from.

The user continues to define other steps in this automated process definition, between the deployment plan and the teardown step. For example, they may add steps to execute automated test plans. Some of these steps may have their own teardown steps.

Once they have finished, the user saves the automated process definition. The user schedules this to be executed at a later date (e.g. on a timer, or triggered by a build completing).

Execution phase

At that later time, when the user is no longer present, the consumer starts to execute the automated process definition. It starts by loading the Automation Request representation that it has stored and submitting it to the appropriate creation factory. (The request body is exactly as in the Automation Request example above). The consumer finds and polls the generated Automation Result to determine when the deployment has completed. It locally stores a link to the Automation Result.

The consumer continues to execute the rest of the automated process definition (e.g. executing the configured test cases).

When everything else in the process definition has been completed, the consumer comes to the teardown step it created earlier. Using the links it has stored locally, it finds the URI for the Automation Result for the deployment step earlier. It performs an HTTP GET on this URI: (this GET could have been performed earlier, but it does not have to have been)

@base <http://example.com/> .
@prefix oslc_auto <http://open-services.net/ns/auto#> .
@prefix oslc <...> .
@prefix dcterms <...> .
@prefix methods <...> ;

<plans/1/results/67890>
    a oslc_auto:AutomationResult ;
    dcterms:title      "Deploy pattern 1" ;
    dcterms:identifier "1:67890" ;
    oslc_auto:state    oslc_auto:complete ;
    oslc_auto:verdict  oslc_auto:passed ;
    # This could include an oslc_auto:contribution entry here, but not all providers may model the deployed resources
    oslc_auto:reportsOnAutomationPlan <plans/1> ;
    oslc_auto:producedByAutomationRequest <plans/1/requests/56789> ;
    oslc:action [
        a oslc:Action, oslc:StopAction ;
        oslc:binding <plans/1/future-stop/creation?targetId=1:67890> ;
        oslc_auto:executes <plans/1/future-stop> ;
    ]
.

<plans/1/future-stop/creation?targetId=1:67890>
    a http:Request ;
    http:httpVersion "1.1" ;
    http:mthd methods:POST;
    http:requestURI <plans/1/future-stop/creation?targetId=1:67890> ;
    http:body [
       a oslc:ContentFromRepresentation ;
       rdf:value <plans/1/future-stop/request-template?targetId=1:67890> ;
    ] ;
.

<plans/1/future-stop/request-template?targetId=1:67890>
    a oslc_auto:AutomationRequest ;
    # Other properties available by requesting this URI directly
.

The consumer finds the action on the Automation Result that has oslc_auto:executes <plans/1/future-stop> set. It knows this is the executable action for this specific Automation Result that will execute the generic future action that the user selected and configured earlier. The binding on this action is of type http:Request. (The context in which the action is to be executed - that is, the ID of the resource to be torn down - is encoded in the http:Request resource URI, and in turn in that resource’s http:requestURI value.) The consumer does not yet have an Automation Request created for this plan, nor can it use a dialog to create it (if any were available) as the user is not present. However, as it has been implemented against the Automation Request specification profile of the Actions specification, it recognises this as the Automation Request interaction pattern, and therefore know that it can use the oslc:ContentFromRepresentation resource to get an Automation Request representation that it can use for the default execution.

The consumer performs an HTTP GET on the URI that is the value of rdf:value on the oslc:ContentFromRepresentation resource:

@base <http://example.com/> .
@prefix oslc_auto <http://open-services.net/ns/auto#> .
@prefix oslc <...> .
@prefix dcterms <...> .

<plans/1/future-stop/request-template?targetId=1:67890>
   a oslc_auto:AutomationRequest ;
   dcterms:title     "Tear down pattern 1 (deployment 67890)" ;
   dcterms:identifier "1:future-stop/request-template:67890" ;
   oslc_auto:state   oslc_auto:new ;
   oslc_auto:executesAutomationPlan <plans/1/future-stop?targetId=1:67890> ;
.

The consumer takes the representation received from that request and uses it as the request body (also setting Content-Type to the value it observed along with that body) of an HTTP POST to the value of the http:requestURI property. (The data identifying the context can either be in the Automation Request (plans/1/future-stop/request-template?targetId=1:67890) or in the http:requestURI. In this example it is in both, but in practice it need only be in one. If in the Automation Request, then it can be an input parameter value, but this is not shown in the example.) As a result of this POST, the provider creates a new Automation Request (e.g. plans/1/future-stop/requests/98765, no example shown), and executes it to tear down the deployed resource. The consumer finds and polls the Automation Result for this new request (e.g. plans/1/future-stop/results/98765 oslc_auto producedByAutomationRequest plans/1/future-stop/requests/98765, no example shown) to determine when the teardown has completed. When this new Automation Result reaches completion, it marks its own automation process execution as complete.

(Note: the specification contains a note referring to using the bindings of actions on the result as “template dialog execution bindings” for template dialog bindings in the future actions. If this is the case, the context - that is, the resource to be torn down - must be encoded in the creation URI, as the Automation Request template generated from the template dialog binding of the future action does not contain the context, as it would have been generated as configuration time, when no ID for the deployed resource exists as it has not been deployed yet.)

Variants and extensions

If the provider models the deployed resource as a separate RDF resource, then it should update that resources’ state model when this tear down plan was completed. It should have also exposed an oslc:StopAction on that RDF resource, providing a binding that could be executed from other processes to tear down the resource (e.g. an action dialog, or an automation request, and possibly the same binding that is here in the Automation Result). While it is good to link to the action from the resource that directly represents it, it is also good to link to it from the Automation Result, to make it easier for loosely-coupled consumers to easily find the oslc:StopAction that stops/tears down the entire deployment.

Both the Automation Result and that other resource directly modelling the deployed resource (if any) could also contain actions for other operations that could be performed on the deployed system, e.g. “restart” or “reset” while it is running, and “redeploy” after it has been torn down.

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.