Mailing-List: contact dev-help@cloudstack.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cloudstack.apache.org
Received-SPF: pass (athena.apache.org: domain of ng.tuna@gmail.com designates
 209.85.192.169 as permitted sender)
From: tuna <ng.tuna@gmail.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Subject: [Discuss] AutoScaling.next in CloudStack
Message-Id: <4FA200AA-B51C-410C-8EA5-A846E7AE4828@gmail.com>
Date: Mon, 25 Nov 2013 23:57:56 +0700
To: dev@cloudstack.apache.org
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\))

Hi guys,

At CCCEU13 I talked about the AutoScale without NetScaler feature =
working with XenServer & XCP. For anyone don=92t know about this =
feature, take a look into my slide here: =
http://www.slideshare.net/tuna20073882/autoscale-without-netscalerccceu13.=


Chiradeep and I had a short talk after the presentation about how to =
improve the AutoScale feature in future. We agreed that:

+ Need to remove Load Balancing feature from AutoScaling. That=92s very =
simple to do.
+ Need to use SNMP for monitoring not only instance-level but also =
application-level.
+ Also, supporting well KVM hypervisor

So, I blow up this thread for all of you guys to discuss the way we =
design that feature, such as:
+ technical side, how to integrate effectively SNMP into CLoudStack. =
Where do we put SNMP monitor components into infrastructure? etc
+ user experience, how user configure that feature with SNMP monitoring. =
I image that user can figure out they need AutoScale for which of =
following items: application, protocol (tcp, udp), port, bandwidth, =
disk, cpu and memory also, etc
+ How about autoscale action, not just only deploy or destroy VM, we =
need maybe dynamically increase-decrease memory/cpu, nic bandwidth, =
disk,=85

Personally, we should think about a completely autoscaling feature.

Cheers,

=97Tuna=