[Oslc-Automation] Execution environment scenario for deploy subdomain

[Martin P Pain]

I've had some thoughts about how the execution environment scenario might 
be applicable to the "deployment" subdomain. (I've written it in terms of 
using a parameter rather than a dedicated predicate, however there would 
need to be a dedicated way of detecting which property/ies are intended to 
point to execution environments, e.g. by oslc:range, 
oslc:propertyDefinition or oslc:valueShape - if I've understood these 
correctly.)


Scenario 1: Using delegated UI (i.e. shows the scenario without exposing
            anything new in RDF)
This scenario uses a generic ("dumb") client that is only used for
connecting to remote providers, and does not store anything itself
(e.g. a mobile app). The provider is the "manager" in this relationship.

1. Generic client displays an auto plan selection dialog from a provider
   that offers deployment of a number of apps to a cloud. Each auto plan
   represents one of the apps that the provider can deploy.
2. User selects an app to deploy.
3. Client displays an auto request creation dialog from the provider.
4. Provider includes an "environment" selection widget in the dialog,
   which gives the user the option of which cloud environments (e.g. OS,
   other software that must have been deployed on the same VM image).
   The environments that are available have been pre-configured on the
   provider.
5. User selects the environment that they require and submit the dialog.
6. Client finds the request/result resource(s) to provide the user access
   to their UI previews to track the progress of the deployment.
7. Provider finds a cloud VM image that matches the selected environment,
   or deploys a new one if needed.
8. Provider deploys the selected app (auto plan) to the appropriate VM.
9. Provider updates the request & result to show that the deployment has
   completed.



Scenario 2: Using API to provide envrionment-specific scheduled
            deployment
This scenario uses a smart client that has storage and scheduling
capabilities and is also aware of execution environments; and a provider
that is specialised to a particular type of deployment (also supporting
execution environments) but does not have scheduling capabilities. i.e.
the client is the "manager" in this relationship.

Setup phase (user present - uses delegated UI):
1. Client (which is aware of execution environments) displays an auto
   plan selection dialog as in scenario 1.
2. User selects an app to deploy.
3. Client inspects the selected auto plan's parameter definitions and
   discovers one that is for specifying an execution environment.
4. Client displays an execution environment selection dialog (either
   from its own storage of execution environments or from a separate
   execution environment provider).
5. User selects an execution environment to use.
6. Client displays its own UI for the user to select the scheduling or
   trigger details (may be on a timer, may be triggered by some other
   event that the client is aware of, e.g. a build completing).
7. Client creates an automation request RDF graph for the selected
   automation plan, specifying the selected execution environment in the
   appropriate parameter, and stores all this information for later.

Execution phase (user absent - no UI):
8. When the scheduled time arrives or the trigger occurs, the client
   POSTs the automation request RDF graph to the provider for execution.
9. The provider deploys the app.
10.The client stores a link to the auto result resource for inspection
   by the user at a later time.

(Note that IF the execution environments are known by the provider rather 
than the client, then this scenario could be achieved using the templates 
scenario to avoid the client needing to know about execution 
environments.)

To reduce the overhead/barriers to entry of generic implementations, we 
could define the profiles of capabilities that clients/providers _could_ 
have, and define which ones are the minimum on each side to work for each 
scenario with different profiles of capabilities on the other side.
e.g. for the scenario of immediate execution using a 
request-time-specified execution environment (scenario 1 in this email) 
then the client only needs to support the generic dialogs as described in 
order to work with a provider that understand execution environments and 
provides selection of execution environments.
I could come up with some interaction tables that show the possible 
combinations to see how complicated they would get if people think this 
may be useful - either to consider what scenarios to support, or to 
include in the spec to give guidance to implementors (perhaps in a 
simplified "minimum client capability profile for execution environments" 
form, rather than an exhaustive table). But this is digressing from my 
main point which is to provide some additional scenarios for consideration 
for the execution environment scenario...

Martin
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-automation_open-services.net/attachments/20130502/bc2edd79/attachment-0003.html>