[Oslc-Automation] Execution environment scenario for deploy subdomain

Xin Peng Liu xinpengl at cn.ibm.com
Thu May 2 23:08:03 EDT 2013


Hi, Martin,

That sounds interesting. But I think in execution environment scenario, 
still one point important missing here which needs to be considered - 
environment matching. You can see from automation consumer side, it may 
use some catalogs (e.g., in RQM, we define catalogs to describe 
disciplines and criterions in planning phase for test coverage) to define 
the requirements for an environment from provider neutral perspective. 
When coming to the execution (in the deployment sub domain, when coming to 
deployment), these env requirements need to be matched to the provider 
available options you described, and finally the matched one may add the 
URI to the env requesting it. The matching could be done manually most of 
the time, but seems delegation UI is not suitable to achieve it, since it 
includes consumer side resources.

This more sounds like a hybrid version of scenario 1 and scenario 2 Paul M 
proposed, but we frequently come to it in reality usage - In planning 
phase, from automation consumer side we define the contract for execution 
environment, and in execution phase, we link to some concrete provider, 
and needs to match to available environments they publish, or just 
requesting a new one based on the contract.


Your sincerely,

XIN PENG LIU (David, 刘昕鹏)
ADVISORY SOFTWARE ENGINEER
Rational Quality Manager Development, IBM China Development Lab


Phone: 86-010-82452825 | Phone: 86-13520163713
E-mail: xinpengl at cn.ibm.com
Chat: David_Box524 at hotmail.com David_Box davidbox.524 at gmail.com 
"No pains, no gains."


8 Dongbeiwang Westen Road
Beijing, Haidian District 100193
China




From:   Martin P Pain <martinpain at uk.ibm.com>
To:     oslc-automation at open-services.net
Date:   2013-05-03 00:32
Subject:        [Oslc-Automation] Execution environment scenario for 
deploy  subdomain
Sent by:        "Oslc-Automation" 
<oslc-automation-bounces at open-services.net>



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
_______________________________________________
Oslc-Automation mailing list
Oslc-Automation at open-services.net
http://open-services.net/mailman/listinfo/oslc-automation_open-services.net



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-automation_open-services.net/attachments/20130503/67ec488f/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 6419 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-automation_open-services.net/attachments/20130503/67ec488f/attachment.jpe>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 543 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-automation_open-services.net/attachments/20130503/67ec488f/attachment-0001.jpe>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 525 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-automation_open-services.net/attachments/20130503/67ec488f/attachment-0002.jpe>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 550 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-automation_open-services.net/attachments/20130503/67ec488f/attachment-0003.jpe>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 360 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-automation_open-services.net/attachments/20130503/67ec488f/attachment.gif>


More information about the Oslc-Automation mailing list