OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

saf-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: SAF Primer feedback

Posted on behalf of Jacques Durand…


Here is my quick review below.

Overall I think you get a good IaaS use case, with automatic support for adjusting Cloud resources dynamically.

The business benefits of this U.C. should be stressed: it is recognized that having the capability to monitor one’s consumption and adjust provisioned resources accordingly, will become important in order to optimize the amount of service (IaaS here) you “buy”. Overall, the use cases are still a little rough to read. More below:


1. The Syndromes: CPUExtremes-LowSensitivity : unclear why >95% is "Low sensitivity" while

>90% is High sensitivity ? (need more explanation)


2. Give the signature of these 2 syndromes, is it expected that whenever

CPUExtremes-LowSensitivity is occurring, CPUExtremes-HighSensitivity is also occurring, given that its signature is implied by the signature of CPUExtremes-LowSensitivity ?


3. The signature of above Syndromes could be more explicit of the time factor:

Shouldn't the query only react to the symptoms that appear within a time window?

E.g. if more than five symptoms ($x/Content/AggregateCPU/AverageLoad >= 95 ) are selected over the last 24h, then the syndrome occurs.

We could assume that the AverageLoad  symptoms are reflecting the CPU usage at periodic times (say every hour)?

I think the example should be more precise - the goal should be to make it more credible as a good way to adjust Cloud capacity, rather than dumbing it down.

4. 1.1.1    Provider Contributed Protocol: Provision-10-Percent

What is unclear to the reder, is how such Protocol relates to Syndromes.


5. More generally, a general picture (an overview) showing how the described Symptoms, Syndromes, Protocols relate to each other, woudl be useful in the Intro of each use case (3.1, 3.2).

A comment for this picture could describe at high level the scenarios supposed to take place, and for which more detailed material is described afterward.

The lengthy intro material just under section 3 and before section 3.1, could be at least cut in half, and details about who is contributing Protocols and Syndromes, be better illustrated on each use case "overview".






From: Vaught, Jeffrey A
Sent: Saturday, July 14, 2012 10:41 PM
To: 'saf-comment@lists.oasis-open.org'
Subject: SAF Primer feedback


Posted on behalf of Doug Davis…


 I looked over the SAF/CIMI doc and have just a few comments:

- change <<CIMI "get">> to <<CIMI "GET">>

- uses old version of CIMI but I'm assuming that will be automatically fixed

- no need for xpath.count() we now have a count property in each collection (sec 3.1.1)

- I think the loop in 3.1.1 (starts with: For each new machine…) is off.  If $new_machine_count is zero it'll still add a new machine.  And, when the count hits zero it still adds one more since it says >= 0  and not > 0 in the while statement.  So, if $new_machine_count starts at 1, this will actually add 2 machines. But I don't know Ruby so I could be wrong.

-Doug Davis
STSM |  Standards Architect  |  IBM Software Group

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]