+1 I will work on merging Query API patches to master.
Thanks, Prachi -----Original Message----- From: Chiradeep Vittal [mailto:chiradeep.vit...@citrix.com] Sent: Thursday, January 31, 2013 10:10 AM To: cloudstack-dev@incubator.apache.org Subject: Re: [DISCUSS] EC2 QUERY API Pending Merge +1 On 1/31/13 9:50 AM, "Animesh Chaturvedi" <animesh.chaturv...@citrix.com> wrote: >IMO Likitha you have done best given our current limitation and I think >it's ok to checkin your patches. When do you expect to finish the unit >test framework? > >> -----Original Message----- >> From: Likitha Shetty [mailto:likitha.she...@citrix.com] >> Sent: Wednesday, January 30, 2013 10:50 PM >> To: cloudstack-dev@incubator.apache.org >> Subject: RE: [DISCUSS] EC2 QUERY API Pending Merge >> >> I would like to add that all the patches that have been submitted for >>review (corresponding to the supported EC2 API's) have been >>extensively tested using boto scripts and the AWS Java SDK. For e.g. >>for patch https://reviews.apache.org/r/8480/ (EC2AttachVolume) the >>following manual tests were performed, >> >> 1. Attach volume to an existing instance >> >> 2. Attach volume to multiple instances >> >> 3. Attach volume using invalid values for each of the parameters >>- invalid >> instance id, invalid device id, instance id corresponding to a vm in >>the invalid state >> >> And for every test the response and behavior was verified against AWS >>EC2 >> document. >> >> I also see that some work has been going on to automate EC2 testing >>using ec2 test suite provided by jClouds [1]. I will let Anshul speak >>more on that. >> >> >> >> We don't currently have a unit test framework in place for AWSAPI. To >>write unit tests for the patches that were sent for EC2 Query API, an >>attempt was made at writing the framework. >> >> But I faced the following issues - for some of the internal classes >>there is no way to access the member variables so we can pass in a >>mock (for e.g. a setter method or a constructor which takes a >>parameter). And all of the internal classes of awsapi don't follow >>any CloudStack manager/dao design and hence cannot be injected using >>MockComponentLocator. So, we could instead try to mock CloudStack >>servlet and return dummy responses to awsapi http calls. But as >>Prachi mentioned this would need some more analysis and time to code. >> >> >> >> With the above in consideration, is it possible to commit these >>patches to master for 4.1 while we continue to work on writing a >>unit-test framework for AWSAPI? >> >> >> >> [1] http://mail-archives.apache.org/mod_mbox/incubator-cloudstack- >> dev/201210.mbox/%3C7914B38A4445B34AA16EB9F1352942F1012F109D6278% >> 40SJCPMAILBOX01.citrite.net%3E >> >> >> >> Thank you, >> >> Likitha >> >> >> >> -----Original Message----- >> From: Prachi Damle [mailto:prachi.da...@citrix.com] >> Sent: Thursday, January 31, 2013 8:29 AM >> To: cloudstack-dev@incubator.apache.org >> Subject: [DISCUSS] EC2 QUERY API Pending Merge >> >> >> >> Hi All, >> >> >> >> >> >> I have reviewed the patches for the [EC2 Query API] support in >>awsapi and they look good. However there are no unit tests added >>[like many other feature branches]. >> >> So the merge of these patches is pending. >> >> >> >> Should I merge them to master, since 4.1 release may miss out EC2 >>Query API support. >> >> Given that EC2 Soap API is being deprecated by AWS, this feature is >>definitely a value-add to apache 4.1 release IMHO. >> >> >> >> >> >> I understand that since awsapi holds most of its logic in a servlet >>and calls CloudStack over http, writing unit tests to mock up the >>servletcontainer and a mock CloudStack servlet is a bigger task. >> >> >> >> So Is it reasonable to commit these patches to master for 4.1 and >>develop a unit-test framework for awsapi in the coming bug fixing >>phase? >> >> Please comment. >> >> >> >> Thanks, >> >> Prachi >> >> >> >> >> >
