Re: [camp] Scaling Policy

[Alex Heneveld <alex.heneveld@cloudsoftcorp.com>]

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:

Foils for Scaling Policy discussion tomorrow.

---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that 
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php