[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [saf] Possible Agenda - July 12
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] 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.
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]