Temporary deployment scenarios

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

Want to contribute?

History View Links to this page 2015 April 1 | 11:26 am

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

Configuration of deployment

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 is not eligible for execution, 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. i.e. using it as a ‘template’. See OSLC Actions: Templates.) The consumer also looks at the oslc:binding properties on the template dialog, and finds one that points at a resource of type oslc:CreationFactory (as is required by the automation specification section on template dialogs). It sotres the oslc:creation URI of this creation factory along with the Automation Request template, for use later.

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

(As described in OSLC Actions: Templates, despite the fact that this Automation Request is not eligible for execution [it will only be used as a template], this is not visible in the RDF. This is the “form” to be copied, and is indistinguishable from a representation that is copied from it.)

The consumer stores this Automation Request representation in the automated process definition step that the user is currently authoring. It is stored as an octet stream/byte array, along with the value of the Content-Type HTTP header (as described in Resource template creation dialog). This stored value is the “template”, from which a later concrete Automation Request will be created.

Configuration of teardown

Next, the consumer follows the oslc_auto:executesAutomationPlan link on that request, by performing an HTTP GET on its target Automation Plan. This is because the consumer is an Automation 2.1 implementation that is compatible with future actions (this was taken as a design decision when the consumer was implemented - should this be in a specification profile?) and it wants to see if there are any future actions available so (if present) it can offer those to the user in the authoring process.

@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:futureAction <plans/1/future-stop> ;
.

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

The provider, through its understanding of future actions, 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_auto:TeardownAction, defined by the Automation 2.1 specification.

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 (http://example.com/plans/1/future-stop) 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).

Configuration conclusion

The consumer has stored:

A “deployment” step, containing:
- An octet stream of the Automation Request representation template
- The Content-type of the Automation Request representation template
- The oslc:creation URI to which to POST the Automation Request representation template
Other steps (e.g. running tests)
A “teardown” step, containing:
- The URI of the “future action” resource

Execution phase

At that later time, when the user is no longer present, the consumer starts to execute the automated process definition.

Execution of deployment

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

Execution of teardown

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). It receives this response:

@base <http://example.com/> .
@prefix oslc_auto <http://open-services.net/ns/auto#> .
@prefix oslc <...> .
@prefix dcterms <...> .
@prefix methods <http://www.w3.org/2011/http-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_auto:TeardownAction ;
        oslc:binding <plans/1/future-stop/binding?targetId=1:67890> ;
        oslc:executes <plans/1/future-stop> ;
    ]
.

<plans/1/future-stop/binding?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 <plans/1/future-stop/request-template?targetId=1:67890> ;
    oslc:finalStatusLocation oslc_auto:AutomationResult ;
.

<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: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 (as this is the definition of oslc:executes on an oslc:Action in the Automation specification 2.1).

As the client has been implemented against the Automation Request specification profile of the Actions specification, it recognises this as the Automation Request interaction pattern, and therefore knows that it can use the object of the binding’s http:body predicate to get an Automation Request representation that it can use to execute the action - that is, to request that the resource is torn down.

The consumer can not use a dialog to create an Automation Request at this time for the tear down (if any were available) as the user is not present. Instead, the consumer performs an HTTP GET on the Automation Request to be used as a template (plans/1/future-stop/request-template?targetId=1:67890):

@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 uses the action binding information combined with the response to that GET to form an Automation Request creation request message, as follows; it uses the binding’s http:requestURI property as the HTTP request-URI, it copies the GET response’s Content-Type header to the POST request, and it uses the GET’s response representation as the creation (POST) request body.

(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 (to plans/1/future-stop/creation?targetId=1:67890), 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.

Variants and extensions

State models

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.

Future action dialogs

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 at configuration time, when no ID for the deployed resource exists as it has not been deployed yet. However, this is not a normative part of the specification, nor is it used in this example.

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.