cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Nalley <da...@gnsa.us>
Subject Re: AutoScale feature....
Date Wed, 04 Jul 2012 01:10:03 GMT
On Tue, Jul 3, 2012 at 8:23 PM, Youcef Laribi
<Youcef.Laribi@eu.citrix.com> wrote:
>>I see where you are coming from. The point is not about treating one LB preferentially
over another. It is the LB-centric nature of the proposal.
>>Surely it should be possible to have an implementation that does not involve any LB
at all (like the AWS auto scaling groups). The proposed API is very much like the AWS auto-scaling
>API, but is useless without the Netscaler. Historically CloudStack almost always has had
defaults that work without any external devices. I think if you propose a generic UI and a
generic >API then it becomes important to follow this precedent.
>>
>>I also submit that it doesn't have to be "months". I wager that some level of re-factoring
of your proposal / code should get us to this state.
>
> This is not about code re-factoring. We are leveraging *existing* features on NetScaler
(like monitoring, policy-based triggering, aggregating stats, etc.) that we thankfully don't
have to code. In any case, we don't have the resources, time or interest in (re)implementing
this inside CloudStack so that it can be used without a NetScaler.
>
> Our goal is to surface an "LB" autoscale capability that NetScaler provides, so that
CS users can take advantage of it when they are deploying with a NetScaler. We have gone to
great lengths to make the API LoadBalancer-agnostic, to leave the door open for other loadbalancers
who have a similar capability.
>
> Youcef
>


So I am hoping that there is some disconnect here.

I don't think that Chiradeep was asking for you to implement this
feature in CloudStack itself, but rather to make the framework that
you already are going to have to build a bit more generic. This allows
others to build on your work.

That said, two different committers have suggested a more generic move
(albeit Chiradeep has done a far more eloquent and pragmatic job than
I) and this email suggests an unwillingness to consider those
comments.

--David

Mime
View raw message