On Nov 15, 2012, at 5:44 PM, Ram Ganesh <ram.gan...@citrix.com> wrote:
> Any thoughts? Unless we hear otherwise would like to push the patches. This > feature had been code complete for a very long time. If there are still > concerns/opinions let us know and we can take steps to correct them. > Ram, any thoughts on how this could work without Netscaler ? Any alternative open source load balancer we could use to implement this ? -Sebastien > Thanks, > Ram > > >> -----Original Message----- >> From: Ram Ganesh [mailto:ram.gan...@citrix.com] >> Sent: 15 November 2012 07:09 >> To: cloudstack-dev@incubator.apache.org >> Subject: RE: Integrating autoscale branch to master? >> >> David, >> >> Can we go ahead with merge of AutoScale code into master? Are there any >> more open questions? >> >> Thanks, >> Ram >> >>> -----Original Message----- >>> From: Vijay Venkatachalam [mailto:vijay.venkatacha...@citrix.com] >>> Sent: 13 November 2012 12:34 >>> To: cloudstack-dev@incubator.apache.org >>> Subject: RE: Integrating autoscale branch to master? >>> >>> >>> My replies inline >>> >>> Thanks, >>> Vijay V. >>> >>>> -----Original Message----- >>>> From: David Nalley [mailto:da...@gnsa.us] >>>> Sent: Monday, October 15, 2012 7:42 PM >>>> To: cloudstack-dev@incubator.apache.org >>>> Subject: Re: Integrating autoscale branch to master? >>>> >>>> On Fri, Oct 12, 2012 at 11:54 AM, Vijay Venkatachalam >>>> <vijay.venkatacha...@citrix.com> wrote: >>>>> Ok I will keep changes ready, and will merge once 4.0's news is >>> declared. >>>>> >>>>> -Vijay V. >>>>> >>>> >>>> Vijay, >>>> >>>> I haven't kept up with this recently so a couple of >>> questions/assumptions: >>>> >>>> 1. Autoscale code will require NetScaler libraries right? >>> >>> There are 2 parts to autoscale code. >>> A. AutoScale Manager and its services, >>> This is part of the core. And has no No Netscaler jar dependency; >>> This part is coded like any other NetworkServiceManager, meaning >> any >>> network >>> element can provide autoscale service. So this part does not have >>> compile time >>> dependency with NetScaler jar. >>> >>> If an autoscale provider (which is most likely already an LB >>> provider) does not exist >>> in that network an error is thrown at run time. >>> So for all oss builds (where Netscaler is not packaged and cannot >> be >>> added >>> to the infrastructure) we should get a run-time error when >>> configuring autoscale. >>> >>> B. NetScaler Element and Netscaler Resource (which is part of non-oss >>> build today) >>> has been enhanced to provide autoscale capability. Today only >>> NetScaler does this, in future any network element can he >> enhanced >>> to provide autoscale. This part already has NetScaler jar >>> dependency >>> (and is considered non-oss today) and will continue to have >>> NetScaler >>> jar dependency. >>> >>> >>>> 2. Is autoscale functionality modular enough that we can turn >>> building it >>>> on/off at will? >>> >>> >>> Short Answer, No. >>> Since AutoScale is like an addon to LB there are touch- points. For >>> example, >>> when a LoadBalancerRule is deleted the AutoScale entities created for >>> it >>> also should be deleted, hence the dependency. >>> Basically there is code in LB core to delete autoscale entities on >> the >>> loadbalancer >>> rule's delete path. Hence Part (A.) could not be modularized. Is >> there >>> an alternative here? >>> >>> Also, in the UI autoscale will appear as part of LB to the user and >> if >>> he attempts to configure >>> AutoScale in a network which does not have NetScaler; he will get a >>> run-time error. >>> >>>> 3. Has there been any change to the netscaler java library >> licensing? >>>> I know there was work underway, but I never heard about a >> conclusion. >>>> >>> >>> I am still chasing the legal team on this, but for the moment, we >>> should continue >>> to treat NetScaler as non-oss. >>> >>>> --David
