SAF-CloudProfile-WD - Oasis

knifedamagingInternet and Web Development

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

238 views

This document is a working draft. It has not been approved by the OASIS SAF TC and does not
represent the views o
f OASIS or the OASIS SAF TC.


Symptoms Automation Framework
(SAF) Cloud Profile

Working Draft 0
3

6 May

2010

Specification URIs:

This Version:

-

Previous Version:


[NA]

Latest Version:

-

Technical Committee:

OASIS Symptoms Automati
on Framework (SAF)

TC

Chair(s):

Jeffrey Vaught, CA Inc

Stavros Isaiadis, Fujitsu Limited

Editor(s):


?


Declared XML Namespace(s):

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


Abst
ract:

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 specifies such constraints and guidelines for the application of SAF to the
domain of cloud management

and business alignment between cloud consumers and
provide
rs
.

Status:

This document was last revised or approved by the SAF TC on the above date. The level
of approval is also listed above. Check the “Latest Version” or “Latest Approved Version”
location noted above for possible later revisions of this document.

Technical Committee members should send comments on this specification to the
Technical Committee’s email list. Others should send comments to the Technical
Committee by using the “Send A Comment” button on the Technical Committee’s web
page at
http://www.oasis
-
open.org/committees/
saf
/
.

For information on whether any patents have been disclosed that may be essential to
implementing this specification, and any offers of patent
licensing terms, please refer to
This document is a working draft. It has not been approved by the OASIS SAF TC and does not
represent the views o
f OASIS or the OASIS SAF TC.

the Intellectual Property Rights section of the Technical Committee web page
(
http://www.oasis
-
open.org/committees/saf/ipr.php
.

The non
-
normative errata page

for this specification is located at
http://www.oasis
-
open.org/committees/
saf
/
.

This document is a working draft. It has not been approved by the OASIS SAF TC and does not
represent the views o
f OASIS or the OASIS SAF TC.

Notices

Copyright © OASIS® 2008
. All Rights Reserved.

All capitalized terms in the following
text have the meanings assigned to them in the OASIS
Intellectual Property Rights Policy (the "OASIS IPR Policy"). The full Policy may be found at the
OASIS website.

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 any
document or deliverable produced b
y 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 permissions 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.

OASIS requests that any OASIS Party or any other party that believes it has patent claims that
would necessa
rily be infringed by implementations of this OASIS Committee Specification or
OASIS Standard, to notify OASIS TC Administrator and provide an indication of its willingness to
grant patent licenses to such patent claims in a manner consistent with the IPR M
ode of the
OASIS Technical Committee that produced this specification.

OASIS invites any party to contact the OASIS TC Administrator if it is aware of a claim of
ownership of any patent claims that would necessarily be infringed by implementations of this
specification by a patent holder that is not willing to provide a license to such patent claims in a
manner consistent with the IPR Mode of the OASIS Technical Committee that produced this
specification. OASIS may include such claims on its website, but di
sclaims any obligation to do so.

OASIS takes no position regarding the validity or scope of any intellectual property or other rights
that might be claimed to pertain to the implementation or use of the technology described in this
document or the extent t
o which any license under such rights might or might not be available;
neither does it represent that it has made any effort to identify any such rights. Information on
OASIS' procedures with respect to rights in any document or deliverable produced by an
OASIS
Technical Committee can be found on the OASIS website. Copies of claims of rights made
available for publication and any assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the u
se of such proprietary rights by
implementers or users of this OASIS Committee Specification or OASIS Standard, can be
obtained from the OASIS TC Administrator. OASIS makes no representation that any information
or list of intellectual property rights will

at any time be complete, or that any claims in such list are,
in fact, Essential Claims.

The names "OASIS",
[insert specific trademarked names and abbreviations here]

are trademarks
of OASIS, the

owner and developer of this specif
ication, and should be used only to refer to the
organization and its official outputs. OASIS welcomes reference to, and implementation and use
of, specifications, while reserving the right to enforce its marks against misleading uses. Please
see
http://www.oasis
-
open.org/who/trademark.php

for above guidance.

This document is a working draft. It has not been approved by the OASIS SAF TC and does not
represent the views o
f OASIS or the OASIS SAF TC.

1.

Introduction

1.1

Purpose

This document specifies guidelines and best practices for the application of the Symptoms
Automation

Framework (SAF) t
o the domain of cloud management. The cloud profile defines
semantic extensions and constraints to the SAF specification, as well as domain specific XML
entities and schemas. A use case in the cloud management dom
ain is also provided separately
[RFC2119]
.


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.2

Notations and Terminology

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]


[Maybe we define the most important SAF terms here as well or reference the spec definitions]


1.3

Namespaces

The following namespaces are used in this document:

Prefix

Namespace

xsd

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

sym

http://docs.oasis
-
open.org/symptoms/symptoms_v1


sycl

http://docs.oasis
-
open.org/symptoms/cloud_profile_v1


2.

Cloud Taxonomy

[
unique SAF aspects, maybe some adopted from NIST?
]


[
concisely
define symptoms in this domain: a no
tification of either a status change, a new
condition in the system, new data on the same event channel, or ???
]


[
Define the role in the cloud that we are enabling with this profile, e.g. provider, developer,
user...
]

3.

Profile Overview

[This section should

define the general objectives, scope, and requirements of the cloud profile.
This info should be derived from the supporting use case(s) and should be from that (higher level)
application perspective

as oppo
sed to the details in the next
section which wi
ll be more technical
and centered on the symptoms spec]

3.1

Objectives

To extend the semantics of the original SAF specification; provide constraints; limit or provide
directions where options are available; and provide a set of

guidelines as to how to apply S
AF for
purposes of cloud
business alignment
.

This document is a working draft. It has not been approved by the OASIS SAF TC and does not
represent the views o
f OASIS or the OASIS SAF TC.

3.2

Requirements

[
Point to the interoperability boun
daries addressed by the profile
]

3.3

Scope

All levels of cloud computing but focusing on the interactions between entities in different levels,
e.g. between a consume
r and a PaaS provider, and how they can negotiate resources, contracts,
report issues and problems, etc.

3.4

Supported Use Cases

A number of use cases have been developed or adapted from relevant domains and SDOs, in an
effort to identify the key customer and
provider requirements regarding interactions and Cloud
management. These use cases have focused on a) the more generic mapping between the high
level customer business requirements to the lower level provider operations (one of the core
motivators for SAF)
, such as the Automated Provisioning of Resource use case
[ref]

and b) on
the interactions and requirements pertaining to a specific “business” function, such as Policy
management
[ref]
, contract management
[ref]
, energy and CO2 footprint management
[ref]
,

and
more.

4.

SAF

for
Cloud
Business Alignment

[
Some introductory text here???
]


In the Cloud domain, where outsourcing at least parts of a company’s infrastructure and/or
capabilities, it becomes imperative to provide a means for allowing the mutual understa
nding and
collaboration between consumers and providers. Providers do not know their customer’s
businesses, and consumers do not know how their providers operate and manage their services.
SAF can be used in order to better align the high level business re
quirements to lower level
provider operations, in a collaborative environment.
[more]

4.1

Protocols

We envision that the Cloud providers will provide generic Protocols that can be used by the
consumers in order to link their requirements to Cloud operations. S
uch Protocols can be
parameterized in nature, and could embed the means to “translate” from higher level
requirements to concrete infrastructure or service operations.


For example, an IaaS provider could contribute to the SAF Catalog a Protocol template f
or
increasing the capacity of a VM server instance. Such Protocol could have a parameter which the
consumer would then fill out, to denote the percentage of increase in relation to the baseline or
existing status, the consumer would like to enforce, e.g. “
20% increase in VM server capacity”.
This high level parameter, which the consumer can understand, can then be “translated” within
the Protocol mechanics to more concrete actions, e.g. “
200MHz more powerful CPU and 1GB
more memory” or similar.


Since such
Protocols (at least at this stage of this profile) permeate all domains and are relevant
to the Cloud Provider operations, we do not proceed to any further breakdowns, choosing instead
to describe such Protocols in the same section.

4.1.1

Server Instance Capacit
y Modification

The following is an example of a possible Protocol template, utilizing the OGF Open Cloud
Computing Interface
[ref]

API:


This document is a working draft. It has not been approved by the OASIS SAF TC and does not
represent the views o
f OASIS or the OASIS SAF TC.


<Prescription>



<PrescriptionId>http://saf.org/XXXX/prescriptions/001</PrescriptionId>



<PrescriptionType>http://s
af.org/XXXX/custom_compute_create</PrescriptionType>



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



<Arguments>



client.id=1234
-
5678
-
9



change.percentage=%C%



</Arguments>


<Process>

#ruby


headers = {}

headers['occi.compute.cores'] = %X
%


headers['occi.compute.memory'] = %Y%

RestClient.
put
("
http://example.com/compute/nod
e1
", headers) do |response|


begin


sleep 2



poll = RestClient.get(response.headers['Location'])

end while poll.s
tatus!=200

#TODO post a Symptom to denote modification of server capacity

end



</Process>


</Prescription>



In this case, the consumer would fill in the “change.percentage” parameter, which would then be
translated in more concrete terms by the Provide
r’s Practitioner in core and memory modification
for the relevant server instance
(
s
)
.

The request is PUT to the identified compute resource under
the compute collection.

4.1.2

Compute Scale
-
out

To increase/decrease the number of instan
ces available to an applica
tion

or Cloud consumer
.



<Prescription>



<PrescriptionId>http://saf.org/XXXX/prescriptions/001</PrescriptionId>



<PrescriptionType>http://saf.org/XXXX/custom_compute_create</PrescriptionType>



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



<Ar
guments>



client.id=1234
-
5678
-
9



instances.number
=%C%


compute.cores=%X%


compute.memory=%Y%



</Arguments>


<Process>

#ruby


headers = {}

headers['occi.compute.cores'] = %X%


headers['occi.compute.memory'] = %Y%

headers['Category'] = "compu
te; scheme='
http://purl.org/occi/kind#
"

headers['label']="Ubuntu Linux 9.10'"

RestClient.post("
http://example.com/compute
", headers) do |response|


begin


sleep 2




poll = RestClient.get(response.headers['Location'])

This document is a working draft. It has not been approved by the OASIS SAF TC and does not
represent the views o
f OASIS or the OASIS SAF TC.

end while poll.status!=202

#TODO post a Symptom to denote
creation of server instance

end



</Process>


</Prescription>



4.1.3

Compute Scale
-
down

To
delete an existing instance available to an application

o
r Cloud consumer
.



<Prescription>



<PrescriptionId>http://saf.org/XXXX/prescriptions/001</PrescriptionId>



<PrescriptionType>http://saf.org/XXXX/custom_compute_create</PrescriptionType>



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



<Argument
s>



client.id=1234
-
5678
-
9


</Arguments>


<Process>

#ruby


RestClient.delete
("
http://example.com/comput
e/node1
"
) do |response|


begin


sleep 2



poll = RestClient.get(response.headers['Location'])

end w
hile poll.status!=200

#TODO post a Symptom to denote
deletion

of server instance

end



</Process>


</Prescription>




4.1.4

Enable/Disable Cloud Resource Monitoring

To

start (if available) monitoring and Symptoms reporting of the resources usage available for
a
specific application or cloud consumer.



<Prescription>



<PrescriptionId>http://saf.org/XXXX/prescriptions/001</PrescriptionId>



<PrescriptionType>http://saf.org/XXXX/custom_compute_create</PrescriptionType>



<ExpirationDate>2010
-
03
-
25_13:45</Expi
rationDate>



<Arguments>



client.id=1234
-
5678
-
9


state=%X%


</Arguments>


<Process>

#ruby


RestClient.
put
("
http://example.com/monitoring/&state=
%X%
") do |response|


begin


sleep 2



p
oll = RestClient.get(response.headers['Location'])

end while poll.status!=200

This document is a working draft. It has not been approved by the OASIS SAF TC and does not
represent the views o
f OASIS or the OASIS SAF TC.

#TODO post a Symptom to denote activation/deactivation of resource monitoring.

#If enabled more Symptoms will start flowing to denote resource usage levels etc.

end



</Process>


</Prescription>



4.1.5

Network Interfaces

[???]

4.1.6

Application Deployment

[???]

4.1.7

Application Management

[
??
?]


4.2

Symptoms

Symptoms pertaining to Cloud management and business alignment, are split depending on the
functional domain they serve. For example, Cloud pr
oviders and consumers wishing to abide to
SAF to perform Service Contract Monitoring
and Management
MUST implement and support the
various Symptoms described in the relevant “Service Contract

Monitoring and

Management

section below.
[more]

4.2.1

Green / Energy
Monitoring and Management

4.2.2

Policy Management

4.2.3

Identity Reconciliation and Management

4.2.4

Billing and Accounting

4.2.5

Security/Auditing

4.2.6

Service Contract Monitoring and Management

5.

Interactions with other standards

[
thoughts:
eMIX? DMTF? OCCi? WS
-
Agreement? CEP stuff a
nyone?

]


In the domain of Protocol definition for Cloud management, we have explored and utilized the
OCCi
[ref]

and DMTF
[ref]

Cloud interfaces.




This document is a working draft. It has not been approved by the OASIS SAF TC and does not
represent the views o
f OASIS or the OASIS SAF TC.

6.

References

[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


[
XXX
]

??,

XXX

Use Case
, [???], ???

This document is a working draft. It has not been approved by the OASIS SAF TC and does not
represent the views o
f OASIS or the OASIS SAF TC.

A.

Revision History


Revision

Date

Editor

Changes

0
1

11/01/2010

Stavros

Isaiadis

Initial draft, outline, abstract text,
some
initial
text

02

08/05/2010

Stavros Isaiadis

Added the introductory OASIS stuff and
disclaimer.

M
odifications to the text (and comments) to
reflect the focus towards business alignment,
the new use cases we have, and the new
s
tructure
.

Added text in S
ection 4

and an OCCi
Prescription!

03

06/05/2010

Stavros Isaiadis

Added more
protocols

and sanitized / refined
text throughout the document