Symptoms Automation Framework (SAF) Cloud Profile ... - Oasis

jockeyropeInternet and Web Development

Feb 2, 2013 (4 years and 6 months ago)

316 views




Symptoms Automation Framework
(SAF) Cloud Profile

Version

1
.
0

Working

Draft
1
1

01 June

201
2

Technical Committee:

OASIS Symptoms Automation Framework (SAF) TC

Chairs:

Jeffrey Vaught (
Jeffrey.Vaught@ca.com
),
CA Technologies

Stavros Isaiadis (
stavros.isaiadis@baml.com
),
Bank of
America Merrill Lynch

Editors:

Jeffrey Vaught (
Jeffrey.Vaught@ca.com
),
CA Technologies

Stavros Isaiadis (
stavros.isaiadis@baml
.com
),
Bank of America Merrill Lynch

Related work:

This
document

is related to:



Symptoms Automation Framework (SAF) Version 1.0
. Latest version.
http://docs.oasis
-
open.org/saf/saf/v1.0/saf
-
v1.0.html

Abstract:

SAF Primer containing non
-
normative examples of SAF symptoms,
syndromes, protocols, and prescriptions; the latter two referencing DMTF
Cloud Infrastructure Management Interface (CIMI).

Status:

This
Working Draft

(WD) has been produced by one or more TC Members;
it has not yet been voted on by the TC or
approved

as a Committee Note
Draft. The OASIS document
Approval Process

begins officially with a TC
vote to approve a WD as a Commi
ttee Note Draft. A TC may approve a
Working Draft, revise it, and re
-
approve it any number of times as a
Committee Note Draft.




Copyright © OASIS Open

201
2
.

All Rights Reserved.

All capitalized terms in the following text have the meanings assigned to t
hem in
the OASIS Intellectual Property Rights Policy (the "OASIS IPR Policy"). The full
Policy

may be found at the OASIS website.

This is

intended as
a Non
-
Standards Track Work Product.

The patent provisions of the OASIS IPR Policy

do not apply
.

SAF
-
CloudProfile
-
v1.0
-
wd01

Working Draft 01

02 May

201
2

Non
-
Standards Track

Copyright © OASIS

Open

201
2
.

All Rights Reserved.

Pag
e
2

of
33

[Type the document title]


This document and translations of it may be copied and

furnished to others, and derivative
works that comment on or otherwise explain it or assist in its implementation may be prepared,
copied, published, and distributed, in whole or in part, without restriction of any kind, provided
that the above copyright
notice and this section are included on all such copies and derivative
works. However, this document itself may not be modified in any way, including by removing
the copyright notice or references to OASIS, except as needed for the purpose of developing an
y
document or deliverable produced by an OASIS Technical Committee (in which case the rules
applicable to copyrights, as set forth in the OASIS IPR Policy, must be followed) or as required to
translate it into languages other than English.

The limited perm
issions granted above are perpetual and will not be revoked by OASIS or its
successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and OASIS
DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT
LIMITED TO ANY
WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY OWNERSHIP
RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR
PURPOSE.



This is

intended as
a Non
-
Standards Track Work Product.

The patent provisions of the OASIS IPR Policy

do not apply
.

SAF
-
CloudProfile
-
v1.0
-
wd01

Working Draft 01

02 May

201
2

Non
-
Standards Track

Copyright © OASIS

Open

201
2
.

All Rights Reserved.

Pag
e
3

of
33

[Type the document title]


Table of Contents

1

Introduction

................................
................................
................................
.............................

5

1.1 References (non
-
normative)
................................
................................
................................
..

5

1.2 Purpose

................................
................................
................................
................................
..

6

1.3 Notations and Terminology

................................
................................
................................
...

6

1.3.1 Syndrome

................................
................................
................................
........................

6

1.3.2 Protocol

................................
................................
................................
...........................

6

1.3.3 Prescription

................................
................................
................................
.....................

6

1.3.4 Symptom

................................
................................
................................
.........................

6

1.4 Namespaces

................................
................................
................................
...........................

7

2

Definitions

................................
................................
................................
................................

8

3.

Use Cases

................................
................................
................................
...............................

10

2.1 Consumer driven decision support for Elasticity

................................
................................
.

10

2.1.1 Provider Contributed Protocol: Provision
-
10
-
Percent

................................
..................

11

2.1.2 Provider Contributed Protocol: Provision
-
5
-
Percent

................................
....................

14

2.1.3 Provider contributed Syndrome: CPUExtremes
-
LowSensitivity

................................
...

17

2.1.4 Provider contributed Syndrome: CPUExtremes
-
HighSensitivity

................................
..

18

2.1.5 Consumer Contributed Syndrome: AssociatedProtocols

................................
.............

19

2.1.6 Runtime Elements: Symptom

................................
................................
.......................

20

2.1.7 Runtim
e Elements: Prescription

................................
................................
...................

21

2.2 Consumer driven decision support for Elasticity, with consideration of Consumer Business
Activity

................................
................................
................................
................................
.......

25

2.2.1 Consumer contributed Syndrome: CPUExtremes
-
SalesIncrease
................................
..

25

2.2.2 Runtime Elements: Symptom for High Cpu Utilization

................................
.................

27

2.2.3 Runtime Elements: Symptom for High Projected Sales Increase

................................
.

28

2.2.4 Runtime Elements: Prescription

................................
................................
...................

29

Appendix A.

Ackn
owledgments

................................
................................
................................
.

32

Appendix B.

Revision History

................................
................................
................................
.....

33

This is

intended as
a Non
-
Standards Track Work Product.

The patent provisions of the OASIS IPR Policy

do not apply
.

SAF
-
CloudProfile
-
v1.0
-
wd01

Working Draft 01

02 May

201
2

Non
-
Standards Track

Copyright © OASIS

Open

201
2
.

All Rights Reserved.

Pag
e
4

of
33

[Type the document title]





This is

intended as
a Non
-
Standards Track Work Product.

The patent provisions of the OASIS IPR Policy

do not apply
.

SAF
-
CloudProfile
-
v1.0
-
wd01

Working Draft 01

02 May

201
2

Non
-
Standards Track

Copyright © OASIS

Open

201
2
.

All Rights Reserved.

Pag
e
5

of
33

[Type the document title]


1

Introduction

The Symptoms
Automation

Framework (SAF) is a generic framework for the analysis, diagnosis,
and
prevention or treatment of conditions that can arise within a system. Due to the generic
nature of the framework, certain communities will want to further standardize/ constraint the
framework to suit the specific needs of the domain. This document specifi
es such constraints
and guidelines for the application of SAF to the domain of cloud management

and business
alignment between cloud consumers and providers.

1.1

References

(non
-
normative)

[RFC2119]

S. Bradner,
Key words for use in RFCs to Indicate Requirement

Levels
,
http://www.ietf.org/rfc/rfc2119.txt
, IETF RFC 2119, March 1997


[CMWG]

Cloud Management Working Group
,
http://dmtf.org/standards/cloud


[
CIMI
]

Clo
ud Infrastructure Management Interface,
http://dmtf.org/sites/default/files/standards/documents/DSP0263_1.0.
0a.pdf


This is

intended as
a Non
-
Standards Track Work Product.

The patent provisions of the OASIS IPR Policy

do not apply
.

SAF
-
CloudProfile
-
v1.0
-
wd01

Working Draft 01

02 May

201
2

Non
-
Standards Track

Copyright © OASIS

Open

201
2
.

All Rights Reserved.

Pag
e
6

of
33

[Type the document title]



1.2

Purpose

This document specifies guidelines for
the application of the Symptoms Automation Framework
(SAF) to the domain of cloud management and specifically utilizing the Distributed Management
Task Force (DMTF) Cloud Infrastructure Management Interface [CIMI]. It serves as a primer for
anyone wishing

to use SAF to facilitate collaboration between cloud consumers and cloud
providers, and automate cloud management operations. As a primer, it has been kept
intentionally simple in terms of the use cases demonstrated.


Similar profiles may be developed to
serve different domains/communities wishing to utilize SAF
for management, diagnosis and/or treatment purposes. In such cases, it is expected that the
profiles follow the same format and outline for consistency and readability purposes.


1.3

Notations and Term
inology

The key words
must
,
must not
,
required
,
shall
,
shall not
,
should
,
should not
,
recommended
,
may
,
and
optional

in this document are to be interpreted as described in
[RFC2119]

1.3.1

Syndrome

A Syndrome is a
n identifiable collection of
z
ero or more
related Symptoms (as identified by a
signature).

Since a Syndrome describes a Symptom (see below) a Syndrome can be thought of as
describing a class of Symptom Instances.

1.3.2

Protocol

A Protocol is a

process for confirming a potential Syndrome diag
nosis via the creation of
validating Symptoms, for remediating a Syndrome,
optimizing the system,
and/or preventing a
Syndrome from occurring.

It provides the template necessary to create a Prescription.

1.3.3

Prescription

A Prescription is an instance of a proc
ess, which MAY correspond to a Protocol. It is used to
provide remediation, diagnostics, preventative measures, or optimization to be performed.
Prescriptions MAY represent automated or Manual steps. A Prescription includes arguments
specific to the subje
ct or component that is the target of the prescription.

1.3.4

Symptom

A Symptom is the

instance
, possibly
corresponding to a Syndrome

and described by a Signature,

indicating that the condition
or situation
is present in the system.

There SHOULD be a Syndrome
co
rresponding to each type of Symptom or a combination of Symptoms as identified by the
Syndrome signature. Unlike Syndromes and Protocols, which may be relatively static and
This is

intended as
a Non
-
Standards Track Work Product.

The patent provisions of the OASIS IPR Policy

do not apply
.

SAF
-
CloudProfile
-
v1.0
-
wd01

Working Draft 01

02 May

201
2

Non
-
Standards Track

Copyright © OASIS

Open

201
2
.

All Rights Reserved.

Pag
e
7

of
33

[Type the document title]


represent the knowledge within the framework, Symptoms represent the dynamic state
of the
system and are therefore expected to be emitted frequently. Once emitted, Symptoms are
immutable, and they can be safely used for audit trails and historical record keeping.

1.4

Namespaces

The following namespaces are used in this document:

Prefix

Names
pace

xsd

http://www.w3.org/2001/XMLSchema

sym

http://docs.oasis
-
open.org/saf/ns/symptoms/2009/10





This is

intended as
a Non
-
Standards Track Work Product.

The patent provisions of the OASIS IPR Policy

do not apply
.

SAF
-
CloudProfile
-
v1.0
-
wd01

Working Draft 01

02 May

201
2

Non
-
Standards Track

Copyright © OASIS

Open

201
2
.

All Rights Reserved.

Pag
e
8

of
33

[Type the document title]


2

Definitions

The
re

are two main roles in this profile: the Cloud consumer and the Cloud provider. A
Cloud
provider

is an Infrastructure as a Service (Iaa
S) solution provider that further exposes
management interfaces adhering to the DMTF
CIMI [CIMI]

standard.


A
Cloud consumer

is any individual or company wishing to host one or more applications into a
cloud solution provided by a Cloud provider. The cons
umer will use the
[CIMI]

interface to
manage the virtual instances allocated to his application(s), e.g. add more storage, request a
new or update an existing machine, etc.


In addition, both the Cloud consumer and provider will adopt the SAF role of Catal
ogue Author
for the purposes of this profile, i.e. they will both contribute Syndrome and Protocol definitions
to a common Catalogue instance,
typically to be

provided by the Cloud Provider
, e.g. as part of a
more complete Cloud solution

(although systems
with more than one Catalogues are certainly
an option).


Both of them will also adopt the roles of Symptom Sources, since Symptoms originating from
both the Provider’s infrastructure monitoring components, and in response to the Consumer’s
business indicat
ors, will
typically
flow through the system.

This flow of Symptoms from different
sources is what enables SAF to act as a collaboration facilitator between the consumer and
provider.

This is

intended as
a Non
-
Standards Track Work Product.

The patent provisions of the OASIS IPR Policy

do not apply
.

SAF
-
CloudProfile
-
v1.0
-
wd01

Working Draft 01

02 May

201
2

Non
-
Standards Track

Copyright © OASIS

Open

201
2
.

All Rights Reserved.

Pag
e
9

of
33

[Type the document title]



This is

intended as
a Non
-
Standards Track Work Product.

The patent provisions of the OASIS IPR Policy

do not apply
.

SAF
-
CloudProfile
-
v1.0
-
wd01

Working Draft 01

02 May

201
2

Non
-
Standards Track

Copyright © OASIS

Open

201
2
.

All Rights Reserved.

Pag
e
10

of
33

[Type the document title]


3.

Use Cases

The significant migration to the Cloud that has taken place f
or a large number of businesses over
the last few years, has resulted in a disconnect between providers and consumers. Where these
would typically have a strong relationship and a good understanding of business requirements
and technical challenges, in the

Cloud this is no longer the case, owing to the on demand and
contract
-
less patterns of usage and billing. Providers do not know their customer’s businesses,
and consumers do not necessarily know the technicalities of how providers operate and manage
their

services.

It has therefore become imperative to provide a means for allowing the mutual
understanding and collaboration between consumers and providers towards a much improved
level of collaboration and the extension of the Cloud delivery model to domains

and business
functions that do not lend themselves very well to the current model. SAF can be used to better
align the high level business requirements to lower
-
level provider operations, in a collaborative
environment.


We envision Cloud providers suppl
ying Protocols that can be used by the consumers in order to
link their requirements to cloud operations such as the provisioning/deprovisioning of cloud
resources via CIMI
[
CIMI]
. In addition, both providers and consumers would typically contribute
syndr
omes that define the criteria for invoking such protocols: consumers providing the
syndromes related to their specific business activities, and providers supplying the syndromes
related to the systems they manage. Together, these contributions will form
the basis for
cooperative decision making within the SAF framework


In the sections below, we outline two use cases for consumer driven decision support. The first
is almost exclusively provider supplied, with the SAF elements of syndrome and protocol bei
ng
contributed by the cloud provider. The second use case expands on the first, including a
syndrome contributed by the consumer.



2.1

Consumer driven decision support for Elasticity

Abstract
: Today, Cloud providers supply rules & actions for elastically
pro
visioning
/deprovisioning

machines.


Our first use case mimics those rules/actions but allows
the Consumer to pick the
most appropriate
combinati
on of rules/actions for their business
.

SAF
, as
an ecosystem where Consumer and Provider knowledge contributio
ns are combined
into a

single decision support system, facilitates those Consumer choices.


This is

intended as
a Non
-
Standards Track Work Product.

The patent provisions of the OASIS IPR Policy

do not apply
.

SAF
-
CloudProfile
-
v1.0
-
wd01

Working Draft 01

02 May

201
2

Non
-
Standards Track

Copyright © OASIS

Open

201
2
.

All Rights Reserved.

Pag
e
11

of
33

[Type the document title]


Description
: An online store hosts its application on Cloud provided, load
-
balanced machines.


SAF uses a combination

of

Syndromes (supplied by Provider) to detect
high/low cpu load,
invoking Protocols (also supplied by the
Provider
) to provision machines accordingly.


The provider will contribute two Syndromes which detect symptoms reporting cpu load of
greater than 90% and 95% respectively. The provider will also

contribute two preventative
Protocols which will provision additional hardware in an attempt to lessen the cpu burden on
existing machines. The two Protocols will provision an additional 10% and 5% respectively.


The provider will leave it to the consum
er to determine how these Syndromes and Protocols
are linked together. For example, the consumer may decide to associate a more conservative
protocol, provisioning only 5% additional resources, with a more sensitive syndrome, detecting
when cpu load excee
des 90%. Another possibility, not fully explored in this document, is to
associate both protocols to each syndrome, allowing the diagnostician to sort out the best
choice of protocol based upon guidance provided in the syndrome and protocol definitions.


2.1.1

Provider Contributed
Protocol
: Provision
-
10
-
Percent

Protocol represents the “action definition” portion of the rule/action equation. In our scenario,
the Provision
-
10
-
Percent protocol is a definition describing the process by which an additional 10
percen
t of machines are provisioned (or deprovisioned) and which elements of the triggering
symptoms are passed as parameters. In addition, the protocol provides guidance to the
diagnostician about the risk/reward of invoking such an action, such that it can ch
oose one
protocol over another.

<Protocol>

The first four elements uniquely identify the protocol and its constituent prescription
instances.

ProtocolType uniquely identifies the type of protocol

<ProtocolType>

<Uri>http://
example.com/saf
/types/protocols/c
ompute_provision_10</Uri>

</ProtocolType>


PrescriptionType uniquely identifies the type of the prescription instances generated,
typically by the Diagnostician, baring the ProtocolType

<PrescriptionType>

<Uri>http://
example.com/saf
/types/prescriptions/com
pute_provision_10</Uri>

</PrescriptionType>


ProtocolName is a descriptive name for the protocol

<ProtocolName>Provision
-
10
-
Percent</ProtocolName>


Description provides a more verbose explanation for the protocol

<Description>Provision or DeProvision virtu
al machines</Description>

This is

intended as
a Non
-
Standards Track Work Product.

The patent provisions of the OASIS IPR Policy

do not apply
.

SAF
-
CloudProfile
-
v1.0
-
wd01

Working Draft 01

02 May

201
2

Non
-
Standards Track

Copyright © OASIS

Open

201
2
.

All Rights Reserved.

Pag
e
12

of
33

[Type the document title]



The next four elements relate to guidance that can be used by the diagnostician to best
choose the most appropriate protocol. For example, if the diagnostician understands the
triggering conditions to be of high urgency, it can
select a protocol with the appropriate
duration such that the situation is attended to sooner rather than later.


Effectiveness is a measure of the expected success of the protocol.

<Effectiveness>Effective</Effectiveness>


Risk is a measure of the expec
ted or unexpected side effects of invoking this protocol.

<Risk>Moderate</Risk>


Duration is a measure of the length of time to complete the protocol.

<Duration>Moderate</Duration>


Function describes whether the protocol is diagnostic, preventative, or re
medial in
nature.

<Function>Preventative</Function>


The final two elements in this example define the process instructions and a means to
extract parameters to that process from the set of triggering symptoms.


Directive is an xquery expression used to se
t/derive/extract parameters from the set of
triggering symptoms. The triggering symptoms are the set which match our syndrome
signature (see section 3.1.3).

In our scenario, we do all three


set, derive, and extract. We directly set the change
percent
age parameter to 10. We derive a “provision” parameter by asserting to true if
cpu load is greater than 50 percent, and asserting to false if cpu load is less/equal than
50 percent. And finally, we extract the client id parameter from the subject element

of
the triggering symptom(s).

The expression ultimately returns an xml document containing the parameters within a
single enclosing element. The diagnostician will extract these parameters from the
resulting xml document and provide them as parameters
to the process of the
prescription.

<Directive>

let $client_id := /Symptoms/Symptom/Subject

let $change_percentage := 10

let $provision := true

if (/Symptoms/Symptom/Content/AggregateCpu/AverageLoad >
50
) then (


$provision := true

)

else (


$prov
ision := false

This is

intended as
a Non
-
Standards Track Work Product.

The patent provisions of the OASIS IPR Policy

do not apply
.

SAF
-
CloudProfile
-
v1.0
-
wd01

Working Draft 01

02 May

201
2

Non
-
Standards Track

Copyright © OASIS

Open

201
2
.

All Rights Reserved.

Pag
e
13

of
33

[Type the document title]


)

return

<Details>


<ClientID>$client_id</ClientID>


<ChangePercentage>$change_percentage</ChangePercentage>


<Provision>$provision</Provision>

</Details>

</Directive>


Process is an implementation specific set of workflow ins
tructions that are executed by
the prescriptive instance of the protocol. The values extracted via the directive are
supplied as parameters to the process.

In our scenario we use the Ruby language as the means for defining process instructions
that leverag
e the [CIMI] standard. The arguments for ClientID, ChangePercentage, and
Provision are passed as parameters to the Ruby script.

<Process>


Using Ruby scripting language below, and passing arguments for:

$ClientID, $ChangePercentage, and $Provision


First
, we get the list of current machines by calling CIMI “get” against
clientid/machines url.

get_response = RestClient.get(“
http://
example.com/saf
/cimi/” + $ClientID +
“/machines
”)


The http r
esponse resembles the xml below:

<MachineCollection>



<uri>
http://
example.com/saf
/cimi/12345/machines</uri
>





<name>mymachines</name>



<description>my machin
es</description>



<created>2011
-
10
-
04T11:28:00</created>



<machine
href=”
http://
example.com/saf
/cimi/12345/machine/mymachine1
” />





<machine
href=”
http://
example.com/saf
/cimi/12345/machine/mymachine2
” />





<machine
href=”
http://
example.com/saf
/cimi/12345/machine/mymachine3
” />






<machine
href=”
http://
example.com/saf
/cimi/12345/machine/mymachine4
” />





<operation rel=”add”
href=”
http://
example.com/saf
/cimi/123
45/machines
” />

</MachineCollection>


This is

intended as
a Non
-
Standards Track Work Product.

The patent provisions of the OASIS IPR Policy

do not apply
.

SAF
-
CloudProfile
-
v1.0
-
wd01

Working Draft 01

02 May

201
2

Non
-
Standards Track

Copyright © OASIS

Open

201
2
.

All Rights Reserved.

Pag
e
14

of
33

[Type the document title]


Next, we get a count of those current machines by running an xpath “count”
function against the response. The count is then increased by the
$ChangePercentage parameter.

$client_uri = “
http://
example.com/saf
/cimi/
” + $ClientID + “
/
machines”

$machine_count =
XPath(count(
$get_
response/MachineCollection[$client_uri]/machine

$new_machine_count = $machine_count * (1 + $ChangePercentage)


For each new machine…

do


begin


We form th
e CIMI request for MachineCreate, using a template.


body = {


<MachineCreate>


<name>mymachineXXXXXX</name>


<machineTemplate href=”
http://
example.com/saf
/cimi/” + $ClientID +
“/machineTemplates/LinuxTemp
late
” />


</MachineCreate>


}




And then invoke the CIMI MachineCollection “add” operation to provision the
machine.


if ($Provision == true)


RestClient.post(get_response/MachineCollection/operation[@rel=’add’]/@href,
body)


else


(


Deprovisioning is beyond the scope of this document.


)



end


$new_machine_count = $new_machine_count
-

1

while $new_machine_count >= 0



</Process>


</Protocol>


2.1.2

Provider Contributed
Protocol
: Provision
-
5
-
Percent

This protocol

is very similar to the former, except we will provision an additional 5 percent rather
than 10 percent.

This is

intended as
a Non
-
Standards Track Work Product.

The patent provisions of the OASIS IPR Policy

do not apply
.

SAF
-
CloudProfile
-
v1.0
-
wd01

Working Draft 01

02 May

201
2

Non
-
Standards Track

Copyright © OASIS

Open

201
2
.

All Rights Reserved.

Pag
e
15

of
33

[Type the document title]



<Protocol>


The first four elements uniquely identify the protocol and its constituent prescription
instances.


ProtocolType uniquely identifies the
type of protocol

<ProtocolType>

<Uri>http://
example.com/saf
/types/protocols/compute_provision_
5
</Uri>

</ProtocolType>


PrescriptionType uniquely identifies the type of the prescription instances generated,
typically by the Diagnostician, baring the Protoco
lType

<PrescriptionType>

<Uri>http://
example.com/saf
/types/prescriptions/compute_provision_
5
</Uri>

</PrescriptionType>


ProtocolName is a descriptive name for the protocol

<ProtocolName>Provision
-
5
-
Percent</ProtocolName>


Description provides a more verbos
e explanation for the protocol

<Description>Provision or DeProvision virtual machines</Description>


The next four elements relate to guidance that can be used by the diagnostician to best
choose the most appropriate protocol. For example, if the diagnost
ician understands the
triggering conditions to be of high urgency, it can select a protocol with the appropriate
duration such that the situation is attended to sooner rather than later.


Effectiveness is a measure of the expected success of the protocol.


<Effectiveness>Effective</Effectiveness>


Risk is a measure of the expected or unexpected side effects of invoking this protocol.

<Risk>Moderate</Risk>


Duration is a measure of the length of time to complete the protocol.

<Duration>Moderate</Duration>


Function describes whether the protocol is diagnostic, preventative, or remedial in
nature.

<Function>Preventative</Function>


The final two elements in this example define the process instructions and a means to
extract parameters to that process from the

set of triggering symptoms.

This is

intended as
a Non
-
Standards Track Work Product.

The patent provisions of the OASIS IPR Policy

do not apply
.

SAF
-
CloudProfile
-
v1.0
-
wd01

Working Draft 01

02 May

201
2

Non
-
Standards Track

Copyright © OASIS

Open

201
2
.

All Rights Reserved.

Pag
e
16

of
33

[Type the document title]



Directive is an xquery expression used to set/derive/extract parameters from the set of
triggering symptoms. The triggering symptoms are the set which match our syndrome
signature (see section x.x.x.x).

In our scenario, we
do all three


set, derive, and extract. We directly set the change
percentage parameter to 5. We derive a “provision” parameter by asserting to true if
cpu load is greater than 50 percent, and asserting to false if cpu load is less/equal than
50 percent
. And finally, we extract the client id parameter from the subject element of
the triggering symptom(s).

The expression ultimately returns an xml document containing the parameters within a
single enclosing element. The diagnostician will extract these

parameters from the
resulting xml document and provide them as parameters to the process of the
prescription.

<Directive>

let $client_id := /Symptoms/Symptom/Subject

let $change_percentage :=
5

let $provision := true

if (/Symptoms/Symptom/Content/Aggregat
eCpu/AverageLoad >
50
) then (


$provision := true

)

else (


$provision := false

)

return

<Details>


<ClientID>$client_id</ClientID>


<ChangePercentage>$change_percentage</ChangePercentage>


<Provision>$provision</Provision>

</Detail
s>

</Directive>


Process is an implementation specific set of workflow instructions that are executed by
the prescriptive instance of the protocol. The values extracted via the directive are
supplied as parameters to the process.

In our scenario we use the

Ruby language as the means for defining process instructions
that leverage the CIMI standard. The arguments for ClientID, ChangePercentage, and
Provision are passed as parameters to the Ruby script.

<Process>

This element is identical to the prior proto
col’s process element and is not
repeated here.

</Process>


</Protocol>

This is

intended as
a Non
-
Standards Track Work Product.

The patent provisions of the OASIS IPR Policy

do not apply
.

SAF
-
CloudProfile
-
v1.0
-
wd01

Working Draft 01

02 May

201
2

Non
-
Standards Track

Copyright © OASIS

Open

201
2
.

All Rights Reserved.

Pag
e
17

of
33

[Type the document title]



2.1.3

Provider contributed
Syndrome
: CPUExtremes
-
LowSensitivity

Syndrome represents the “rule definition” portion of the rule/action equation. In our scenario,
the CPUExtremes
-
L
owSensitivity syndrome describes the pattern of symptoms where cpu load
exceeds 95 percent of maximum.


<Syndrome>


The first three elements uniquely identify the syndrome.


SyndromeType uniquely identifies the type of syndrome.

<SyndromeType>


<Uri>h
ttp://
example.com/saf
/types/syndrome/cpuload</Uri>

</SyndromeType>


SyndromeName is a descriptive name for the syndrome.

<SyndromeName>CPUExtremes
-
LowSensitivity</SyndromeName>


Description is a verbose explanation of the syndrome.

<Description>


Detect

when cpu load has exceeded a threshold and provision additional servers

</Description>


The next three elements relate to guidance that can be used by the diagnostician to best
choose the most appropriate protocol. For example, the diagnostician could fa
vor less
“risky” protocols when the syndrome Impact is VeryLow. Similarly, a syndrome
Likelihood of Rare may not illicit enough confidence to invoke a “risky” protocol.


Likelihood is a measure of typicality of the syndrome.

<Likelihood>Common</Likelihood
>

Impact is a measure of the consequences of this syndrome if not treated.

<Impact>Moderate</Impact>


Urgency is a measure of the speed and tenacity with which this syndrome should receive
attention.

<Urgency>Moderate</Urgency>


Signature is an xquery expr
ession specifying the criteria for recognizing a pattern of
symptoms defined by this syndrome. The resulting document is the set of matching
symptoms.

In our scenario, the xquery enumerates through all of the symptoms in the store,
matching those with a pa
rticular symptom type (eg. aggregate_cpu) and an average cpu
load of greater/equal than 95 percent.

This is

intended as
a Non
-
Standards Track Work Product.

The patent provisions of the OASIS IPR Policy

do not apply
.

SAF
-
CloudProfile
-
v1.0
-
wd01

Working Draft 01

02 May

201
2

Non
-
Standards Track

Copyright © OASIS

Open

201
2
.

All Rights Reserved.

Pag
e
18

of
33

[Type the document title]


<Signature>


for $x in /Symptoms/Symptom


where


$x[SymptomType=” http://
example.com/saf
/types/symptom/aggregate_cpu”


and


$x/Conte
nt/AggregateCPU/AverageLoad >= 9
5
]

</Signature>


AssociatedProtocols references a list of protocols that can potentially be invoked as a
result of this syndrome being activated. The diagnostician will choose the most
appropriate protocol from this list ba
sed upon the guidance included in both the
syndrome and protocol definitions. In our scenario, the provider has purposely left this
element blank, leaving it up to the consumer to identify the protocols that could be
potentially invoked.

<AssociatedProtoc
ols />


</Syndrome>


2.1.4

Provider contributed
Syndrome
: CPUExtremes
-
HighSensitivity

This HighSensitivity syndrome is quite similar to the prior LowSensitivity syndrome, only it adjusts
the signature to detect symptoms where the cpu load exceeds 90% of maximum
rather than 95%
of maximum. In this way, the syndrome is more sensitive to the changes in cpu.


<Syndrome>


The first three elements uniquely identify the syndrome.


SyndromeType uniquely identifies the type of syndrome.

<SyndromeType>


<Uri>http://
exa
mple.com/saf
/types/syndrome/cpuload</Uri>

</SyndromeType>


SyndromeName is a descriptive name for the syndrome.

<SyndromeName>CPUExtremes
-
High
Sensitivity</SyndromeName>


Description is a verbose explanation of the syndrome.

<Description>


Detect when cp
u load has exceeded a threshold and provision additional servers

</Description>


The next three elements relate to guidance that can be used by the diagnostician to best
choose the most appropriate protocol. For example, the diagnostician could favor less

This is

intended as
a Non
-
Standards Track Work Product.

The patent provisions of the OASIS IPR Policy

do not apply
.

SAF
-
CloudProfile
-
v1.0
-
wd01

Working Draft 01

02 May

201
2

Non
-
Standards Track

Copyright © OASIS

Open

201
2
.

All Rights Reserved.

Pag
e
19

of
33

[Type the document title]


“risky” protocols when the syndrome Impact is VeryLow. Similarly, a syndrome
Likelihood of Rare may not illicit enough confidence to invoke a “risky” protocol.


Likelihood is a measure of typicality of the syndrome.

<Likelihood>Common</Likelihood>

Impact

is a measure of the consequences of this syndrome if not treated.

<Impact>Moderate</Impact>


Urgency is a measure of the speed and tenacity with which this syndrome should receive
attention.

<Urgency>Moderate</Urgency>


Signature is an xquery expression s
pecifying the criteria for recognizing a pattern of
symptoms defined by this syndrome. The resulting document is the set of matching
symptoms.

In our scenario, the xquery enumerates through all of the symptoms in the store,
matching those with a particular

symptom type (eg. aggregate_cpu) and an average cpu
load of greater/equal than 90 percent.

<Signature>


for $x in /Symptoms/Symptom


where


$x[SymptomType=” http://
example.com/saf
/types/symptom/aggregate_cpu”


and


$x/Content/Aggre
gateCPU/AverageLoad >= 90]

</Signature>


AssociatedProtocols references a list of protocols that can potentially be invoked as a
result of this syndrome being activated. The diagnostician will choose the most
appropriate protocol from this list based upon

the guidance included in both the
syndrome and protocol definitions. In our scenario, the provider has purposely left this
element blank, leaving it up to the consumer to identify the protocols that could be
potentially invoked.

<AssociatedProtocols />


</Syndrome>


2.1.5

Consumer Contributed
Syndrome
: AssociatedProtocols

In our case, the consumer won’t actually contribute a new syndrome, but rather modify one of
the provider supplied syndromes


the CPUExtremes
-
LowSensitivity syndrome. We won’t
replicate the
entire syndrome again, only displaying the relevant changes to the
AssociatedProtocols element.


This is

intended as
a Non
-
Standards Track Work Product.

The patent provisions of the OASIS IPR Policy

do not apply
.

SAF
-
CloudProfile
-
v1.0
-
wd01

Working Draft 01

02 May

201
2

Non
-
Standards Track

Copyright © OASIS

Open

201
2
.

All Rights Reserved.

Pag
e
20

of
33

[Type the document title]


<Syndrome>

This syndrome has already been defined above
--

the CPUExtremes
-
LowSensitivity
syndrome contributed by the provider.




AssociatedProtocols referen
ces a list of protocols that can potentially be invoked as a
result of this syndrome being activated. The diagnostician will choose the most
appropriate protocol from this list based upon the guidance included in both the
syndrome and protocol definitions
. In our scenario, the consumer will populate this
element with a single protocol, admittedly making the decision trivial for the
diagnostician.

<AssociatedProtocols>


<ProtocolReference>


<Uri>http://example.com/saf/types/protocols/compute_prov
ision_10</Uri>


</ProtocolReference>

</AssociatedProtocols>


</Syndrome>


2.1.6

Runtime Elements:
Symptom

Symptoms are typically emitted by some domain manager such as system, network, application,
or other. In our scenario, the symptoms originate from a sys
tems manager which detects cpu
utilization on servers. The xml below is one such example of a symptom.


<Symptom>


SymptomId uniquely defines the symptom in time.

.
<SymptomId>http://
example.com/saf
/symptoms/aggregate_cpu/12345/machines/1</
SymptomId>


Symp
tomType defines the semantics of the symptom. In our scenario, the systems
manager symptom emitter could emit several symptoms related to cpu utilization, each
with a different SymptomId and variations in the AggregateCpu numbers. All would still
maintai
n the same SymptomType.

<SymptomType>


<Uri>http://
example.com/saf
/types/symptom/aggregate_cpu</Uri>

</SymptomType>


CreationDate is the date/time in xml schema xs:dateTime format when the symptom
was created.

<CreationDate>2011
-
10
-
24T13:10:05</Creation
Date>


This is

intended as
a Non
-
Standards Track Work Product.

The patent provisions of the OASIS IPR Policy

do not apply
.

SAF
-
CloudProfile
-
v1.0
-
wd01

Working Draft 01

02 May

201
2

Non
-
Standards Track

Copyright © OASIS

Open

201
2
.

All Rights Reserved.

Pag
e
21

of
33

[Type the document title]


Confidence is a measure of how assured the symptom emitter is with respect to the
accuracy of this symptom.

<Confidence>High</Confidence>


Reported is the identity of the symptom emitter.

<Reporter>http://
example.com/saf
/reporters/systems_monitor
-
12
3</Reporter>


Subject is the identity of resource exhibiting the symptom. In our scenario, this is the
reference to the IT service supporting our online sales.

<Subject>http://
example.com/saf
/subjects/

service
-
12345
</Subject>


Content contains any embedde
d xml specific to the symptom type. In our scenario, the
Content contains information about the aggregate cpu utilization at a point in time.
Note that our syndrome signature and protocol directive both consider the AverageLoad
value embedded within the
Content of these symptom types.

<Content>


<AggregateCpu >


<MachineCollectionID>12345/machines</MachineCollectionID>


<AverageLoad>85</AverageLoad>


<MaxLoad>98</MaxLoad>


<MinLoad>05</MinLoad>


<InstantaneousLoad>72</Ins
tantaneousLoad>


</AggregateCpu>

</Content>


</Symptom>



2.1.7

Runtime Elements:
Prescription

Prescriptions are runtime elements which define the instructions and workflow necessary for the
Practitioner to remediate, prevent, or diagnose a condition. Presc
riptions are usually derived
from Protocols. The xml below is one such example of a prescription.


<Prescription>



PrescriptionId uniquely defines the prescription in time.

<PrescriptionId>http://
example.com/saf
/prescriptions/001</PrescriptionId>



This is

intended as
a Non
-
Standards Track Work Product.

The patent provisions of the OASIS IPR Policy

do not apply
.

SAF
-
CloudProfile
-
v1.0
-
wd01

Working Draft 01

02 May

201
2

Non
-
Standards Track

Copyright © OASIS

Open

201
2
.

All Rights Reserved.

Pag
e
22

of
33

[Type the document title]


Prescr
iptionType defines the semantics of the prescription, and is usually defined in a
corresponding Protocol. In our scenario, multiple prescriptions, each with a unique
PrescriptionId, to provision additional resources could be instantiated by the
diagnostic
ian in cases where the demand for compute resources massively spiked. All
would still maintain the same PrescriptionType.

<PrescriptionType>


http://
example.com/saf
/types/prescriptions/ compute_provision_10

</PrescriptionType>



ExpirationDate is the

date beyond which the prescription is obsolete. The diagnostician
could derive this value from some of the protocol guidance, such as “duration”.

<ExpirationDate>2010
-
03
-
25T13:45</ExpirationDate>



Arguments consist of embedded xml which defines the param
eters required by the
Process script. The diagnostician derives the arguments by applying the protocol
directive against matching symptoms (which, in turn, are the result of the syndrome
signature applied against all possible symptoms in the symptom store
).

<Arguments>




<Details>




<ClientID>http://
example.com/saf
/subjects/
service
-
12345</ClientID>


<ChangePercentage>10</ChangePercentage>


<Provision>true</Provision>


</Details>

</Arguments>



Process is a direct copy of the process in
the corresponding protocol, and supplies the
execution instructions/workflow necessary to remediate, prevent, or diagnose a
condition.

<Process>


Same as defined in our corresponding
Protocol
.

</Process>



This is

intended as
a Non
-
Standards Track Work Product.

The patent provisions of the OASIS IPR Policy

do not apply
.

SAF
-
CloudProfile
-
v1.0
-
wd01

Working Draft 01

02 May

201
2

Non
-
Standards Track

Copyright © OASIS

Open

201
2
.

All Rights Reserved.

Pag
e
23

of
33

[Type the document title]


</Prescription>


This is

intended as
a Non
-
Standards Track Work Product.

The patent provisions of the OASIS IPR Policy

do not apply
.

SAF
-
CloudProfile
-
v1.0
-
wd01

Working Draft 01

02 May

201
2

Non
-
Standards Track

Copyright © OASIS

Open

201
2
.

All Rights Reserved.

Pag
e
24

of
33

[Type the document title]





This is

intended as
a Non
-
Standards Track Work Product.

The patent provisions of the OASIS IPR Policy

do not apply
.

SAF
-
CloudProfile
-
v1.0
-
wd01

Working Draft 01

02 May

201
2

Non
-
Standards Track

Copyright © OASIS

Open

201
2
.

All Rights Reserved.

Pag
e
25

of
33

[Type the document title]


2.2

Consumer driven decisi
on support for Elasticity
, with consideration
of Consumer Business Activity

Abstract
:

Extending
our first u
se
c
ase, we extend support to include more complex rules which
adjust capacity based upon consumer leading indicators for sales trends.


SAF allows t
he
Consumer to contribute their decision nuances and combine with knowledge from the Provider
into a single catalog.


Description
: An online store hosts its application on Cloud provided, load
-
balanced machines.


SAF uses a combination of Syndromes supplie
d by both Consumer and Provider to detect
combinations of high/low cpu load
and sales trends
, invoking Protocols to provision or
deprovision machines accordingly.


The provider contributions are identical to the first use case. The consumer additionally
contributes a modified copy of the provider “CPUExtremes
-
LowSensitivity” syndrome which, in
addition to detecting cpu load on machines, will also detect leading online sales indicators.


2.2.1

Consumer contributed
Syndrome
: CPUExtremes
-
SalesIncrease

Syndrome rep
resents the “rule definition” portion of the rule/action equation. In our scenario,
the CPUExtremes
-
SalesIncrease syndrome describes the pattern of symptoms where cpu load
equals or exceeds 95 percent of maximum
and

sales projections equal or exceed 10 pe
rcent.


This syndrome is nearly identical to the provider contributed CPUExtremes
-
LowSensitivity, but
with a few minor modifications to account for sales increases. We’ve bolded those modifications
for easier visibility.


<Syndrome>


The first three elem
ents uniquely identify the syndrome.


SyndromeType uniquely identifies the type of syndrome.

<SyndromeType>


<Uri>http://
example.com/saf
/types/syndrome/
combination/cpuload
-
salesincrease
</Uri>

</SyndromeType>


SyndromeName is a descriptive name for the s
yndrome.

<SyndromeName>CPUExtremes
-
SalesIncrease
</SyndromeName>


Description is a verbose explanation of the syndrome.

<Description>

This is

intended as
a Non
-
Standards Track Work Product.

The patent provisions of the OASIS IPR Policy

do not apply
.

SAF
-
CloudProfile
-
v1.0
-
wd01

Working Draft 01

02 May

201
2

Non
-
Standards Track

Copyright © OASIS

Open

201
2
.

All Rights Reserved.

Pag
e
26

of
33

[Type the document title]



Detect when cpu load has exceeded a threshold

and sales projections have increased
beyond a threshold,

and provision ad
ditional servers

</Description>


The next three elements relate to guidance that can be used by the diagnostician to best
choose the most appropriate protocol. For example, the diagnostician could favor less
“risky” protocols when the syndrome Impact is V
eryLow. Similarly, a syndrome
Likelihood of Rare may not illicit enough confidence to invoke a “risky” protocol.


Likelihood is a measure of typicality of the syndrome.

<Likelihood>Common</Likelihood>

Impact is a measure of the consequences of this syndro
me if not treated.

<Impact>Moderate</Impact>


Urgency is a measure of the speed and tenacity with which this syndrome should receive
attention.

<Urgency>Moderate</Urgency>


Signature is an xquery expression specifying the criteria for recognizing a pattern

of
symptoms defined by this syndrome. The resulting document is the set of matching
symptoms.

In our scenario, the xquery enumerates through all
“pair combinations” of symptoms in
the store, matching those combinations consisting of high cpu load symptom
and an
increased sales projection symptom. Typically, a time proximity between the pairs of
symptoms would also be defined, but for the purposes of xquery simplification we
have left that out.

<Signature>

for $x in /Symptoms/Symptom

for $y in /Symptoms/Sy
mptom

where

$x[SymptomType=” http://
example.com/saf
/types/symptom/aggregate_cpu”

and

$x/Content/AggregateCPU/AverageLoad >= 9
0
]




and



$y[SymptomType=
http://example.com/saf/types/symptom/salesprojection

and

$y/Content/SalesProjection/PercentIncrease >= 10]

</Signature>


AssociatedProtocols references a list of protocols that can potentially be invoked as a
result of this syndrome being activated. The

diagnostician will choose the most
This is

intended as
a Non
-
Standards Track Work Product.

The patent provisions of the OASIS IPR Policy

do not apply
.

SAF
-
CloudProfile
-
v1.0
-
wd01

Working Draft 01

02 May

201
2

Non
-
Standards Track

Copyright © OASIS

Open

201
2
.

All Rights Reserved.

Pag
e
27

of
33

[Type the document title]


appropriate protocol from this list based upon the guidance included in both the
syndrome and protocol definitions. In our scenario, the consumer will populate this
element with a single protocol, admittedly making the
decision trivial for the
diagnostician.

<AssociatedProtocols>


<ProtocolReference>


<Uri>http://example.com/saf/types/protocols/compute_provision
_5
</Uri>


</ProtocolReference>

</AssociatedProtocols>


</Syndrome>


2.2.2

Runtime Elements:
Symptom

for
High Cpu Utilization

Symptoms are typically emitted by some domain manager such as system, network, application,
or other. In our scenario, oneo of the symptoms originate from a systems manager which
detects cpu utilization on servers and sales projection

increases. The xml below is one such
example of a symptom.


<Symptom>


SymptomId uniquely defines the symptom in time.

.
<SymptomId>http://
example.com/saf
/symptoms/aggregate_cpu/12345/machines/1</
SymptomId>


SymptomType defines the semantics of the sympto
m. In our scenario, the systems
manager symptom emitter could emit several symptoms related to cpu utilization, each
with a different SymptomId and variations in the AggregateCpu numbers. All would still
maintain the same SymptomType.

<SymptomType>


<
Uri>http://
example.com/saf
/types/symptom/aggregate_cpu</Uri>

</SymptomType>


CreationDate is the date/time in xml schema xs:dateTime format when the symptom
was created.

<CreationDate>2011
-
10
-
24T13:10:05</CreationDate>


Confidence is a measure of how assur
ed the symptom emitter is with respect to the
accuracy of this symptom.

<Confidence>High</Confidence>


Reported is the identity of the symptom emitter.

This is

intended as
a Non
-
Standards Track Work Product.

The patent provisions of the OASIS IPR Policy

do not apply
.

SAF
-
CloudProfile
-
v1.0
-
wd01

Working Draft 01

02 May

201
2

Non
-
Standards Track

Copyright © OASIS

Open

201
2
.

All Rights Reserved.

Pag
e
28

of
33

[Type the document title]


<Reporter>http://
example.com/saf
/reporters/systems_monitor
-
123</Reporter>


Subject is the identity of re
source exhibiting the symptom. In our scenario, this is the
reference to the IT service supporting our online sales.

<Subject>http://
example.com/saf
/subjects/

service
-
12345
</Subject>


Content contains any embedded xml specific to the symptom type. In our

scenario, the
Content contains information about the aggregate cpu utilization at a point in time.
Note that our syndrome signature and protocol directive both consider the AverageLoad
value embedded within the Content of these symptom types.

<Content>



<AggregateCpu >


<MachineCollectionID>12345/machines</MachineCollectionID>


<AverageLoad>85</AverageLoad>


<MaxLoad>98</MaxLoad>


<MinLoad>05</MinLoad>


<InstantaneousLoad>72</InstantaneousLoad>


</AggregateCpu>

</Cont
ent>


</Symptom>



2.2.3

Runtime Elements:
Symptom

for High Projected Sales Increase

Symptoms are typically emitted by some domain manager such as system, network, application,
or other. In our scenario, one of the symptoms originate from a sales and marketing
application
which alerts on high projected sales increases. The xml below is one such example of a symptom.


<Symptom>


SymptomId uniquely defines the symptom in time.

.
<SymptomId>http://
example.com/saf
/symptoms/
salesprojection
/1</SymptomId>


SymptomType d
efines the semantics of the symptom. In our scenario, the
sales/marketing application symptom emitter could emit several symptoms related to
sales projections, each with a different SymptomId and variations in the projection
numbers. All would still main
tain the same SymptomType.

<SymptomType>


<Uri>http://
example.com/saf
/types/symptom/
salesprojection
</Uri>

</SymptomType>


This is

intended as
a Non
-
Standards Track Work Product.

The patent provisions of the OASIS IPR Policy

do not apply
.

SAF
-
CloudProfile
-
v1.0
-
wd01

Working Draft 01

02 May

201
2

Non
-
Standards Track

Copyright © OASIS

Open

201
2
.

All Rights Reserved.

Pag
e
29

of
33

[Type the document title]


CreationDate is the date/time in xml schema xs:dateTime format when the symptom
was created.

<CreationDate>2011
-
10
-
24T13:10:05</Cre
ationDate>


Confidence is a measure of how assured the symptom emitter is with respect to the
accuracy of this symptom.

<Confidence>High</Confidence>


Reported is the identity of the symptom emitter.

<Reporter>http://
example.com/saf
/reporters/
sales
-
sensor
-
123

</Reporter>


Subject is the identity of resource exhibiting the symptom. In our scenario, this is the
reference to the IT service supporting our online sales.

<Subject>http://
example.com/saf
/subjects/

service
-
12345
</Subject>


Content contains any embe
dded xml specific to the symptom type. In our scenario, the
Content contains information about the aggregate cpu utilization at a point in time.
Note that our syndrome signature and protocol directive both consider the AverageLoad
value embedded within t
he Content of these symptom types.

<Content>


<SalesProjection>


<Region>Global</Region>


<PercentageIncrease>10</PercentageIncrease>


</SalesProjection>

</Content>


</Symptom>


2.2.4

Runtime Elements:
Prescription

Prescriptions are runtime e
lements which define the instructions and workflow necessary for the
Practitioner to remediate, prevent, or diagnose a condition. Prescriptions are usually derived
from Protocols. The xml below is one such example of a prescription.


<Prescription>



Pres
criptionId uniquely defines the prescription in time.

<PrescriptionId>http://
example.com/saf
/prescriptions/00
2
</PrescriptionId>



PrescriptionType defines the semantics of the prescription, and is usually defined in a
corresponding Protocol. In our scenar
io, multiple prescriptions, each with a unique
PrescriptionId, to provision additional resources could be instantiated by the
This is

intended as
a Non
-
Standards Track Work Product.

The patent provisions of the OASIS IPR Policy

do not apply
.

SAF
-
CloudProfile
-
v1.0
-
wd01

Working Draft 01

02 May

201
2

Non
-
Standards Track

Copyright © OASIS

Open

201
2
.

All Rights Reserved.

Pag
e
30

of
33

[Type the document title]


diagnostician in cases where the demand for compute resources massively spiked. All
would still maintain the same PrescriptionTyp
e.

<PrescriptionType>


http://
example.com/saf
/types/prescriptions/ compute_provision_
5

</PrescriptionType>



ExpirationDate is the date beyond which the prescription is obsolete. The diagnostician
could derive this value from some of the protocol guid
ance, such as “duration”.

<ExpirationDate>2010
-
03
-
25T13:45</ExpirationDate>



Arguments consist of embedded xml which defines the parameters required by the
Process script. The diagnostician derives the arguments by applying the protocol
directive against

matching symptoms (which, in turn, are the result of the syndrome
signature applied against all possible symptoms in the symptom store).

<Arguments>




<Details>




<ClientID>http://
example.com/saf
/subjects/
service
-
12345</ClientID>


<ChangePerce
ntage>
5
</ChangePercentage>


<Provision>true</Provision>


</Details>

</Arguments>



Process is a direct copy of the process in the corresponding protocol, and supplies the
execution instructions/workflow necessary to remediate, prevent, or diagnose
a
condition.

<Process>


Same as defined in our corresponding
Protocol
.

</Process>



</Prescription>


This is

intended as
a Non
-
Standards Track Work Product.

The patent provisions of the OASIS IPR Policy

do not apply
.

SAF
-
CloudProfile
-
v1.0
-
wd01

Working Draft 01

02 May

201
2

Non
-
Standards Track

Copyright © OASIS

Open

201
2
.

All Rights Reserved.

Pag
e
31

of
33

[Type the document title]




This is

intended as
a Non
-
Standards Track Work Product.

The patent provisions of the OASIS IPR Policy

do not apply
.

SAF
-
CloudProfile
-
v1.0
-
wd01

Working Draft 01

02 May

201
2

Non
-
Standards Track

Copyright © OASIS

Open

201
2
.

All Rights Reserved.

Pag
e
32

of
33

[Type the document title]


Appendix A.

Acknowledgments

The following individuals have participated in the creation of this specification and are gratefully
acknowledged:

Participants:

Al
vin Black, CA

Stavros Isaiadis, Bank of America Merrill Lynch

Vivian Lee, Fujitsu Limited

Paul Lipton, CA

David Snelling, Fujitsu Limited

Jeffrey Vaught, CA

This is

intended as
a Non
-
Standards Track Work Product.

The patent provisions of the OASIS IPR Policy

do not apply
.

SAF
-
CloudProfile
-
v1.0
-
wd01

Working Draft 01

02 May

201
2

Non
-
Standards Track

Copyright © OASIS

Open

201
2
.

All Rights Reserved.

Pag
e
33

of
33

[Type the document title]


Appendix B.

Revision History

Revision

Date

Editor

Changes

01

11/01/2010

Stavros Isaiadis

Initial draft, outlin
e, abstract text, some initial
text

02

08/05/2010

Stavros Isaiadis

Added the introductory OASIS stuff and
disclaimer.

Modifications to the text (and comments) to
reflect the focus towards business alignment,
the new use cases we have, and the new
structur
e.

Added text in Section 4 and an OCCi
Prescription!

03

06/05/2010

Stavros Isaiadis

Added more protocols and sanitized / refined
text throughout the document

04

11/28/2011

Jeff Vaught

Added a single DMTF CIMI protocol (and
associated elements).

05

12/15
/2011

Stavros Isaiadis

Cleaned up a bit and re
-
structured as per our
latest discussions. Added some text in the
definitions sections.

06

12/20/2011

Jeff Vaught

Modified two use cases extensively for
simplification and clarity.

07

02/06/2012

Jeff Vaught

C
omments on Section 3 for review by TC.

08

03/12/2012

Stavros Isaiadis

Added references; small improvements to the
main text

09

04/01/2012

Stavros Isaiadis

Applied comments pertaining to XML
namespaces and use of saf.com/example.com
for examples

10

04/03
/2012

Jeff Vaught

Added visual diagrams and changed CMWG
references to CIMI.

11

06/01/2012

Jeff Vaught

Ported to OASIS WD template.