RE: [saf] Possible Agenda - July 12

["Lipton, Paul C" <Paul.Lipton@ca.com>]

Hi,

 

Responses below. Can we please talk about the later two items a bit?

 

Thanks,

Paul

 

Paul Lipton

VP, Industry Standards and Open Source

Member, CA Council for Technical Excellence

Phone (preferred number!): +1 215 867-9231

Mobile: +1 267 987-6887

Email: paul.lipton@ca.com

 

THIS MESSAGE MAY CONTAIN CONFIDENTIAL, PRIVILEGED OR OTHER LEGALLY PROTECTED INFORMATION. IT IS INTENDED FOR THE ADDRESSEE ONLY. IF YOU ARE NOT THE ADDRESSEE (OR SOMEONE THE ADDRESSEE AUTHORIZED TO RECEIVE THIS MESSAGE), YOU ARE PROHIBITED FROM COPYING, DISTRIBUTING OR OTHERWISE USING IT. PLEASE NOTIFY THE SENDER AND RETURN IT AT OUR COST. THANK YOU.

 

From: Vaught, Jeffrey A [mailto:Jeffrey.Vaught@ca.com]
Sent: Monday, July 12, 2010 9:59 AM
To: saf@lists.oasis-open.org
Subject: [saf] Possible Agenda - July 12

 

Possible agenda…

-      Educational ppt approval

-      Main spec updates (see below)

-      Symptoms/Prescriptions for Cloud profile (see way below)

 

 

 

-          CatalogueSource -> CatalogueEditor (or something that denotes the more fine grained control)  Jeff – makes sense.

[[Paul]] +1, but how did we get these long and awkward spellings of Catalog! :-)

-          Case Manager -> remove? We have no real use for a Case Manager in the spec and certainly not in our implementation. I think this is redundant unless we consider adding "Case" as well as a concept –which might complicate things.  Jeff – Case Manager is an Orchestrator, and seems to be implementation specific.

[[Paul]] +1. I was never comfortable with this, if you remember.

 

-          Add TypeRegistry –maybe with a better name? Also, this by no means mandates the actual existence of a registry in the system, but simply a point where users can find existing types. How this is to be implemented is a detail out of the spec (e.g. could be implemented as an actual registry/store, or as a query mechanism that collects this information from the various places in the framework).  Jeff – Why wouldn’t the Catalog be a good place to store the Type information?  Answering my own question: Architecturally, it is probably best to separate Practitioner/SymptomEmitter registered information from CatalogEditor supplied information.  In an implementation, a single data store could be used for both (simplifying administration, maintenance, etc).  Does that sound about right?

-          I have some issues with the interfaces as set out in the spec. "Interfaces" imply specific interaction semantics, and the way they are currently spelled out makes me uncomfortable. In a sense, what we have there are not interfaces, but Roles! But we already have the term role for the active roles in the framework, so this makes things tricky (imagine: "The role of SymptomHandler can be taken by the role of Diagnostician" :-\ ) And these roles have some operations which we should spell out not in the common format ("getPrescriptionTypes" etc) but in a more loose way ("get/list prescription types"). Then in the relevant appendix we make it more concrete with specificities, e.g. REST.  Jeff – I think the first column in our Interface table is just the ‘name’ of the Interface, not a role.  For example, SymptomHandler is not a role, but just the name of an interface.  Agree that the operations should be defined in a loose way.

 

 

------------------------------------------------------------------------------------

 

Below is a list of possible Symptom types for Cloud management.

Two concerns were mentioned on the call today:

1.   Lack of taxonomy – Is there an existing taxonomy that could be used for the symptom type (and/or prescription type)?

2.   Symptom boundary – How do we decide what should be a symptom and what shouldn’t be a symptom?  For example, resource performance notifications (ie: cpu1 on server xyz is 39% utilized) doesn’t seem like a good candidate for a symptom.  Can we articulate a ‘rule’ for what should be a symptom?

 

Please offer your thoughts.

 

 

 

SymptomType	Description	Possible Content elements
urn:servicemanagement:quota-threshold	A quota for a resource has been breached, or is about to be breached.  Example: Provider emitted symptom triggers consumer syndrome/protocol to revise quota.	xs:anyURI – serviceid xs:int – remaining-quota-percent
urn:servicemanagement:planned-outage	A planned service outage is imminent.  Example: Provider emitted symptom triggers consumer syndrome/protocol to mitigate outage.	xs:anyURI – serviceid xs:int – expected-duration
urn:servicemanagement:unplanned-outage	A service is suddenly unavailable. Example: Provider emitted symptom triggers consumer syndrome/protocol to mitigate outage.	xs:anyURI – serviceid xs:int – expected-duration
urn:servicemanagement:cost-threshold	A service cost threshold has been breached, or is about to be breached. Example: Provider emitted symptom triggers consumer syndrome/protocol to reduce consumption or renegotiate service agreement.	xs:anyURI – serviceid xs:int – remaining-percent xs:boolean – is-above-threshold
urn:servicemanagement:sla-violation	An SLA violation has occurred or is about to occur. Example: Consumer emitted symptom triggers provider syndrome/protocol to notify/escalate service owner.	xs:anyURI – serviceid xs:string – violation-metric