Possible Agenda - July 12

["Vaught, Jeffrey A" <Jeffrey.Vaught@ca.com>]

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.

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

-          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