On 16-Nov-2012, at 3:48 PM, Pranav Saxena <[email protected]> wrote:
> Hi ,
>
> I have helped Vijay in merging the AutoScale code with asf/master branch
> after David's approval . Vijay Venkatachalam , Jessica Wang , Brian Federle
> and myself have been involved in writing the AutoScale code . Please let us
> know in case there are any concerns.
>
> Vijay Venkatachalam will update the community more about merging of the
> autoscale code with asf/master.
Good work people! One issue: apidocs are failing (which is with the developer
profile; mvn clean install -P developer) with:
Traceback (most recent call last):
File "/Bhaisaab/Work/apache-cloudstack/tools/apidoc/gen_toc.py", line 159, in
<module>
category = choose_category(fn)
File "/Bhaisaab/Work/apache-cloudstack/tools/apidoc/gen_toc.py", line 139, in
choose_category
(fn, __file__))
Exception: Need to add a category for createAutoScalePolicy.xml to
/Bhaisaab/Work/apache-cloudstack/tools/apidoc/gen_toc.py:known_categories
It affects marvin and cloudmonkey.
Regards.
>
> Thanks & Regards,
> Pranav
>
> -----Original Message-----
> From: Vijay Venkatachalam [mailto:[email protected]]
> Sent: Friday, November 16, 2012 1:14 AM
> To: [email protected]
> Subject: RE: Integrating autoscale branch to master?
>
>> * 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.
>
> That is right, no NetScaler jars required for the default oss build!
> Final round of unit testing is getting done, will do the merge tomorrow.
>
> Thanks,
> Vijay V.
>
>> -----Original Message-----
>> From: David Nalley [mailto:[email protected]]
>> Sent: Friday, November 16, 2012 12:58 AM
>> To: [email protected]
>> Subject: Re: Integrating autoscale branch to master?
>>
>> On Tue, Nov 13, 2012 at 2:04 AM, Vijay Venkatachalam
>> <[email protected]> wrote:
>>>
>>> My replies inline
>>>
>>> Thanks,
>>> Vijay V.
>>>
>>>> -----Original Message-----
>>>> From: David Nalley [mailto:[email protected]]
>>>> Sent: Monday, October 15, 2012 7:42 PM
>>>> To: [email protected]
>>>> Subject: Re: Integrating autoscale branch to master?
>>>>
>>>> On Fri, Oct 12, 2012 at 11:54 AM, Vijay Venkatachalam
>>>> <[email protected]> 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
