cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Nalley <da...@gnsa.us>
Subject Re: Integrating autoscale branch to master?
Date Thu, 15 Nov 2012 19:27:33 GMT
On Tue, Nov 13, 2012 at 2:04 AM, Vijay Venkatachalam
<Vijay.Venkatachalam@citrix.com> wrote:
>
> My replies inline
>
> Thanks,
> Vijay V.
>
>> -----Original Message-----
>> From: David Nalley [mailto:david@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.Venkatachalam@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


Thanks for my reply. What I surmise from all of this is:
* When this merge happens, the default build will not require the the
Netscaler libraries to successfully complete.

If the above is indeed the case, I have no objections.

Thanks,

--David

Mime
View raw message