[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