cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Youcef Laribi <>
Subject RE: AutoScale feature....
Date Fri, 06 Jul 2012 02:56:18 GMT
Thanks for the review Chiradeep and glad this cleared us earlier misunderstandings about this


-----Original Message-----
From: Chiradeep Vittal [] 
Sent: Thursday, July 05, 2012 5:34 PM
To: CloudStack DeveloperList
Subject: Re: AutoScale feature....

Thanks. I have attempted to elide the NS pieces below to get a better understanding. I also
looked at the updated spec

On 7/5/12 4:04 AM, "Ram Ganesh" <> wrote:

>I have updated the functional specs with more details around the 
>various components that come into play plus answers for various 
>questions as required by the functional spec template. Talking briefly 
>about modules - Collector/Monitor, Aggregator, Trigger/Alarm generator 
>and Trigger/Alarm handler
>Collector/Monitor: This module is responsible for gathering metrics 
>from various guest VMs. Timers wakes up a collector/monitor 
>periodically for metric collection purpose. [etc]
>Aggregator: This module aggregates the collected metric values based  
>on various algorithms such as average, minimum, maximum etc. [etc]
>Trigger/Alarm Generator: Timer based triggers monitor the output of 
>aggregators, evaluates autoscale conditions and generates a 
>trigger/alarm if the condition is evaluated to true. [etc]
>Trigger/Alarm Handler: Trigger/Alarm Handler acts on trigger/alarm and 
>initiates a scale up/scale down action working in unison with Cloud 
>orchestration products such as CloudStack. [etc]
>AutoScale configuration done on an LB rule using the CloudStack APIs 
>configures the management plane of NetScaler system. In the current 
>implementation all the above 4 modules reside inside NetScaler system.

To me, these are the generic interfaces that should exist in the auto scaling framework inside
CloudStack. If you define the API nicely in these
(java) interfaces, then you can write Netscaler classes that implement these interfaces. Then
you can tell CloudStack that the specific classes that implement the interfaces in components.xml
. The APIs would be broadly those that handle the auto scaling configuration from the end-user
The Netscaler implementations would merely act as proxies to the actual modules that run on
the Netscaler. Now someone else can come in and provide their own implementation to replace
these classes and configure CloudStack to use theirs instead. This is what I meant by a "re-factoring".
But until that other implementation is done, the Netscaler implementation is the only one

>The interaction between Trigger Generator and Handler is based on 
>standard json payload over HTTP. We could look at implementing a 
>generic Trigger/Alarm Handler in CloudStack and then rest of the 
>modules in a phased manner.

This is a good idea, but the minimum ask is to define the interface / API.

>For the trigger handler support in CloudStack we need to
>	- Discuss/debate the protocol to use : HTTP/HTTPS vs alert based 
>protocols like SNMP,UDP

Note this does not have to be generic: this could be custom for the Netscaler realization,
but generic is nice. HTTP/json is nice, but some kind of authentication is required.

>But as mentioned earlier there is lot of value in leveraging richer 
>monitoring capabilities offered by load balancer devices and thereby 
>taking far intelligent scaling actions

Nobody ever said anything to the contrary. I am certain that this is going to be a fantastic
The only thing we are trying to achieve here is a clean architecture that other contributors
feel they can enhance or implement rather than doing yet another rewrite.

>Also around the placement of SNMP community and SNMP port I am open to 
>better ideas.

As I mentioned before, they can be passed in as generic key value pairs.
The Netscaler classes implementing the configuration API would interpret they key value pairs
(and reject the API call if they are not there).


View raw message