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 27 | 12:12 pm

This is the revision from 2014 January 27 at 12:12 pm 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 adds this deployment plan to the automated process definition that the user is currently authoring. The consumer performs a HTTP GET on this 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:StopAction ;
    dcterms:title "Tear down pattern 1" ;
    oslc:binding [
        a oslc_action:TemplateDialog ;
        dcterms:title "Configure teardown for pattern 1" ;
        oslc:dialog <plans/1/future-stop.html> ;
   ];
.

In this scenario the consumer is familiar with future actions, 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:StopAction.

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 sees that there is a template dialog binding on the future action, and so knows that this action requires configuration, so displays this dialog to the user. The user provides any information to the provider that is needed to configure this action (e.g. delete logs when completed, force stop when executed, etc) and submits the dialog. The provider returns a URI to the consumer as the result of the dialog.

The consumer performs an HTTP GET on this URI:

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

<plans/1/future-stop/requests/nonexec/12345>
   a oslc_auto:AutomationRequest ;
   dcterms:title     "Tear down pattern 1" ;
   dcterms:identifier "1:nonexec/12345" ;
   oslc_auto:state   oslc_auto:new ;
   oslc_auto:executesAutomationPlan <plans/1/future-stop> ;
.

The consumer stores this AutoRequest representation (as a byte array, along with the value of the Content-Type HTTP header) as a “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. (In this case, the provider deletes this resource after 5 minutes, so the only representation is that which the consumer stored. The Automation Request was never created to be executed in this form by the provider - only to be downloaded to be submitted as a new Automation Request for executed later. However, the way in which other providers behave may vary.)

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 constructing an automation request for the deployment plan (in this case there are no parameters, so it is trivial to do that unattended) and submitting that to the appropriate creation factory. (Sample RDF omitted from this example). 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 <...> .

<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 oslc:CreationFactory ;
    dcterms:title "Create teardown requests for deployment 67890" ;
    oslc:creation <plans/1/future-stop/creation?targetId=1:67890> ;
.

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 oslc:CreationFactory. The consumer knows what this means as it was implemented against the “template dialog implementation profile” of the Actions specification specified by the Automation 2.1 specification. (TODO: define this). (Note that in this example it is linking to a creation factory by URI. This may be a creation factory that also exists in a service provider document, but it does not need to be. (NOTE: currently the core spec says that creation factories must be “local resources”). 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 creation factory URI, and in turn in that factory’s oslc:creation URI.)

The consumer takes the Automation Request byte array that it saved earlier, and uses it as the request body (also setting Content-Type to the value it observed earlier) of an HTTP POST to the value of the oslc:creation property. (As the Automation Request was created before the resource was deployed, the request does not contain any context information - that is all provided by the URI to which it is being POSTed). The provider creates a new Automation Request, and executes it to tear down the deployed resource. The consumer finds and polls the Automation Result for this new request 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

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.