Ashok / All,
Good stuff. I like the three-step separation but I would suggest
characterising them slightly differently.
BTW can you upload your document to issue 11? I will then add my
comments below to that issue, for posterity.
(1) Re "metrics": we've previously discussed adding a notion of
sensors and the consensus seemed to be that attributes are
sufficient for this. (Issue 9 -- sensors and effectors -- at
[2].)
(2) Actions (operations) are discussed in the same issue. I'd
like to make some progress on that this week.
(2') Strong preference here to use a word such as "operation" /
"effector" / "action" -- in preference to "trigger" as that latter
suggests the cause of the operation. I think it is cleaner to
frame them as operations available e.g. so they could be invoked
through the API.
(3) "Alert / condition" feels too lightweight. I would like this
to support arbitrary logic/processing here, perhaps looking at
multiple attributes, attributes on other components, external
factors, and incorporating time delays (e.g. don't scale back
until the level has been sustained for 30 minutes). Additionally
I see this mechanism being used for many things other than
"scaling policies", e.g. failover, rolling upgrade / rollback,
restarting elements, etc. Not sure what the best term is.
Perhaps "Policy" ?
(3') I don't think we *need* any changes to the spec to support
this (beyond what is noted in (2)). All the use cases *could* be
accommodated by existing concepts of new AC's and PC's or
operations on AC's/PC's.. In time I think we will want to call
this out as a first class concept for increased portability but I
would suggest deferring this until the next version of the CAMP
spec, at which time we will have a better appreciation for best
practice and emerging conventions. (I can see multiple possible
implementations, e.g. relationships to new AC's / PC's, or a
"policies" attribute on AC's/PC's, etc.)
Finally - we definitely should include in the spec or primer an
illustration of at least one way that a scaling policy could be
expressed in CAMP.
Best
Alex
[1]
https://tools.oasis-open.org/issues/browse/CAMP-9
On 03/04/2013 08:03, Ashok Malhotra wrote: