On Tue, Jul 3, 2012 at 8:23 PM, Youcef Laribi <youcef.lar...@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
