Bug : Create Vmware Advance Zone , Public Network with vlan 509 specified, but portgroup created is cloud.public.untagged.0.1-vSwitch0 not cloud.public.509.0.1-vSwitch0
Hi all,
In lastest CS 4.2 code, I create advance zone with hypervisor vmware
esxi,
create public Network with vlan id 509 specified and label vSwitch0,
when cs create systemvm(cpvm,ssvm),
a new portgroup with name cloud.public.untagged.0.1-vSwitch0 was
created, not a portgroup cloud.public.509.0.1-vSwitch0 as expected.
in database table nics, the field broadcast_uri for new systemvm is
vlan:509 , and should be vlan://509
I debug the code , and found the problem in Networks.java
api/src/com/cloud/network/Networks.java line 222
188 public enum IsolationType {
..
212 public T URI toUri(T value) {
213 try {
214 // assert(this!=Vlan ||
215 // value.getClass().isAssignableFrom(Integer.class)) :
216 // do we need to check that value does not contain a
scheme
217 // part?
218 // Why are you putting non integer into vlan url;
219 if (value.toString().contains(:))
220 return new URI(value.toString());
221 else
222 return new URI(scheme, value.toString(), null);
223 } catch (URISyntaxException e) {
224 throw new CloudRuntimeException(
225 Unable to convert to isolation type URI:
+ value);
226 }
227 }
line 222 should be changed to :
return new URI(scheme,value.toString(),null,null);
or
return new URI(scheme + :// + value.toString());
same bug in the same file line 100, enum BroadcastDomainType .
anyone can test and fix it?
diff --git a/api/src/com/cloud/network/Networks.java
b/api/src/com/cloud/network/Networks.java
index c76c3d4..672b69b 100755
--- a/api/src/com/cloud/network/Networks.java
+++ b/api/src/com/cloud/network/Networks.java
@@ -97,7 +97,7 @@ public class Networks {
if (value.toString().contains(:))
return new URI(value.toString());
else
-return new URI(scheme, value.toString(), null);
+return new URI(scheme, value.toString(), null, null);
} catch (URISyntaxException e) {
throw new CloudRuntimeException(
Unable to convert to broadcast URI: + value);
@@ -219,7 +219,7 @@ public class Networks {
if (value.toString().contains(:))
return new URI(value.toString());
else
-return new URI(scheme, value.toString(), null);
+return new URI(scheme, value.toString(), null, null);
} catch (URISyntaxException e) {
throw new CloudRuntimeException(
Unable to convert to isolation type URI: +
value);
--
Thanks,
Jijun
Re: BuiltIn appliance for use in integration tests
On Fri, Jul 26, 2013 at 09:24:18AM -0400, Chip Childers wrote: On Fri, Jul 26, 2013 at 06:02:04PM +0530, Prasanna Santhanam wrote: Almost all the integration tests use the built-in CentOS template in the deployment for their test scenarios. Sometimes this is less desirable since the tests can verify functionality within cloudstack that requires certain services to be up within the guest. For instance the VPC tests ensure loadbalancing over the web port works correctly, for which it requires the httpd service to be running. Since we may have specific needs in tests for future, I've added an appliance definition built on top of a CentOS6.4-minimal +xs-tools in the tools/appliance/builtin directory. This change is pushed to master (26a0fd5). The automated test deployments will replace the regular built-in with this template to help verify such tests as described above. I've put in a job on jenkins as well for this - http://jenkins.buildacloud.org/view/master/job/build-test-centos-builtin/ I'm still testing the template at the moment but wanted to bring this up in case anyone sees problems with this approach? Great approach, and seems easy to add a new service when / if required for a new test scenario. This is ready to use. These are built on a weekly basis right now. It is a CentOS 6.4 minimal image but boots successfully after registering as CentOS 5.3 (64-bit) (builtin) within cloudstack. I added the KVM image, started a VM from it and it successfully gets hostname, ip from virtual router. The httpd service starts on bootup and a test page is placed as test.html which says Hello, World. Port 80 is open for connections. -- Prasanna., Powered by BigRock.com
Re: Dev Help: How to create scheduled tasks in ACS
On Sat, Jul 27, 2013 at 1:56 AM, Donal Lafferty donal.laffe...@citrix.comwrote: A CloudMonkey script in a cron task is a possibility. See http://dlafferty.blogspot.co.uk/2013/07/using-cloudmonkey-to-automate.htmlfor details on writing the CloudMonkey script. I'll try to follow up with a sample script next week. Nice. -Original Message- From: Musayev, Ilya [mailto:imusa...@webmd.net] Sent: 26 July 2013 6:22 PM To: dev@cloudstack.apache.org Subject: Dev Help: How to create scheduled tasks in ACS We would we have a doc or an example on how to create a scheduled task in ACS? Ian Duffy (from GSOC) is working on better LDAP integration and needs to create a scheduled task to look for deactivated users in LDAP and lock them in ACS. Any help is appreciated, Thanks ilya
Re: [DISCUSS][VOTE] Moving cloudmonkey to its own repository, have its own release process
Sorry, I did not have bandwidth to reply but now. Just to update people on this; in our next steps - Remove tools/cli from cloudstack's repo and fix README and link to the cloudmonkey repo, inform users, devs - Write a wiki on cloudmonkey's release process, which is around ship fast, break things - Release cloudmonkey whenever there are changes Regards. On Sun, Jul 7, 2013 at 10:19 PM, Rohit Yadav rohityada...@gmail.com wrote: Thanks David. Will start contributing those things in my free time (mostly weekends) and help with a release soon. Cheers. On Sun, Jul 7, 2013 at 8:47 PM, David Nalley da...@gnsa.us wrote: Sorry - I really meant to get to it before now. It's now writable. Enjoy. --David On Sun, Jul 7, 2013 at 7:06 AM, Rohit Yadav bhais...@apache.org wrote: Hey! Been sometime on this thread. David, can you confirm if the cloudmonkey repo is writable by CloudStack committers so I can populate the README file with more details, add some unit tests to enforce contract of interfaces and services and then eventually help with a release. Any suggestions, feedback? Cheers. On Sun, Jun 30, 2013 at 11:02 PM, Rohit Yadav bhais...@apache.org wrote: On Sat, Jun 29, 2013 at 9:47 PM, David Nalley da...@gnsa.us wrote: Rohit: Do you plan on generating a cloudmonkey release? (and acting as the RM?, should be comparatively simple, but we might need to document it.) Sure, why not. I can be the initial RM. We can document the process on wiki which should be fairly straight forward and put some (help) documentation or links to it on the README file. Setup.py will need to be fixed, but I have no other concerns than that. I plan to make this writable momentarily. Pl. go ahead and also fix setup.py, when I do diff -Naur with the latest it shows no differences for me. I'm not sure how to fix in history because when I do diff for all commits where setup.py was changed I see no differences in those commits. Regards. --David On Sat, Jun 29, 2013 at 9:27 AM, Rohit Yadav bhais...@apache.org wrote: More than 72 hours now. Let's make it writable and publish latest cloudmonkey on pypi. Cheers. On Wed, Jun 26, 2013 at 3:02 AM, David Nalley da...@gnsa.us wrote: Not sure about setup.py related failures. Me either - setup.py is pretty dramatically different between the two repos. --David
Re: Meet up on July 20th - Hyderabad, India
Hi Nitin, how did it go. Share presentation, videos, blogs if any. Cheers. On Thu, Jul 18, 2013 at 5:14 PM, Nitin Mehta nitin.me...@citrix.com wrote: There is an upcoming meet up on July 20th at Hyderabad, India There will be talks on CS architecture and hacking with devcloud. Detailed info @ http://www.meetup.com/CloudStack-Hyderabad-Group/events/125208462/ Thanks, -Nitin
Re: Review Request 12913: Fix map based APIs in CloudMonkey
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/12913/#review24057 --- Thanks, it was applied on the new cloudmonkey/master repo; commit 924554fa2507818b7d77144c70e6bf5387b33175 Author: Carson Anderson car...@betterservers.com AuthorDate: Thu Jul 25 15:50:14 2013 -0600 Commit: Rohit Yadav bhais...@apache.org CommitDate: Sun Jul 28 16:15:20 2013 +0530 - Rohit Yadav On July 25, 2013, 4:52 a.m., Carson Anderson wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/12913/ --- (Updated July 25, 2013, 4:52 a.m.) Review request for cloudstack and Rohit Yadav. Bugs: CLOUDSTACK-3787 Repository: cloudstack-git Description --- CM does not detect required tags if they are passed as a map. When creating resource tags for example. The tags[0].key and tags[0].value weren't counted for the tags parameter and CM would give a missing required parameter error. Diffs - tools/cli/cloudmonkey/cloudmonkey.py 13f54ad Diff: https://reviews.apache.org/r/12913/diff/ Testing --- Tested by adding/removing resourceTags Thanks, Carson Anderson
Re: Review Request 12913: Fix map based APIs in CloudMonkey
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/12913/#review24058
---
I've simplified the check in this way:
-missing = filter(lambda x: x not in args_dict.keys() +
[parm.split('[')[0] for parm in args_dict.keys()],
+missing = filter(lambda x: x not in [key.split('[')[0]
+ for key in args_dict],
self.apicache[verb][subject]['requiredparams'])
It's because splitting at [ and getting 0th element will be same as string if [
was not present, not need to duplicate list elements.
- Rohit Yadav
On July 25, 2013, 4:52 a.m., Carson Anderson wrote:
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/12913/
---
(Updated July 25, 2013, 4:52 a.m.)
Review request for cloudstack and Rohit Yadav.
Bugs: CLOUDSTACK-3787
Repository: cloudstack-git
Description
---
CM does not detect required tags if they are passed as a map. When creating
resource tags for example. The tags[0].key and tags[0].value weren't counted
for the tags parameter and CM would give a missing required parameter
error.
Diffs
-
tools/cli/cloudmonkey/cloudmonkey.py 13f54ad
Diff: https://reviews.apache.org/r/12913/diff/
Testing
---
Tested by adding/removing resourceTags
Thanks,
Carson Anderson
Re: Meet up on July 20th - Hyderabad, India
Hi Rohit - Good to hear from you ? It went well and was well received. Most of the folks were able to run dev cloud. We have a good setup built with IIITH university and will be holding it more often there now. Hoping to gain more traction and interest from students as well going forward. Slides can be found @ http://www.slideshare.net/nitinmehta5203/hacking-apache-cloud-stack-2448584 2 Pics @ http://www.meetup.com/CloudStack-Hyderabad-Group/photos/16245252/ Thanks, -Nitin On 28/07/13 4:05 PM, Rohit Yadav bhais...@apache.org wrote: Hi Nitin, how did it go. Share presentation, videos, blogs if any. Cheers. On Thu, Jul 18, 2013 at 5:14 PM, Nitin Mehta nitin.me...@citrix.com wrote: There is an upcoming meet up on July 20th at Hyderabad, India There will be talks on CS architecture and hacking with devcloud. Detailed info @ http://www.meetup.com/CloudStack-Hyderabad-Group/events/125208462/ Thanks, -Nitin
Re: Do we delete an account after all users are deleted?
I've removed the invalid tests from test_accounts when I noticed we don't have any tests for lock/disable accounts in there. Filed a bug for the missing tests: CLOUDSTACK-3884 On Sat, Jul 27, 2013 at 03:19:52PM +, Sowmya Krishnan wrote: That's the behavior right now - we don't delete the account if users are all deleted. So we just need the test script to be removed/altered which is testing the other way. -Original Message- From: Alex Huang [mailto:alex.hu...@citrix.com] Sent: Saturday, July 27, 2013 8:38 PM To: dev@cloudstack.apache.org Subject: RE: Do we delete an account after all users are deleted? The bug is scarce on details. Assuming I understand what is asked correctly, this should not be done at all. A deletion of an account triggers an expunge of the all resources. Suppose someone made a mistake and removed all users from an account and cs automatically deleted the account and automatically cleaned out the resources. Not a good idea. Better to specifically delete the account. --Alex -Original Message- From: Sowmya Krishnan [mailto:sowmya.krish...@citrix.com] Sent: Saturday, July 27, 2013 6:52 AM To: dev@cloudstack.apache.org Subject: RE: Do we delete an account after all users are deleted? -Original Message- From: Sowmya Krishnan [mailto:sowmya.krish...@citrix.com] Sent: Saturday, July 27, 2013 7:05 PM To: dev@cloudstack.apache.org Subject: RE: Do we delete an account after all users are deleted? -Original Message- From: Prasanna Santhanam [mailto:t...@apache.org] Sent: Saturday, July 27, 2013 6:55 PM To: dev@cloudstack.apache.org Subject: Re: Do we delete an account after all users are deleted? On Sat, Jul 27, 2013 at 12:19:31PM +, Sowmya Krishnan wrote: Do we perform any cleanup of an account if all users in that account are deleted? I don't find that is the current behavior. I was going through test_accounts.py and figured that's one of the tests. Here's the description of that test: # Validate the following # 1. Remove both the users from the account. # 2. Verify account is removed # 3. Verify all VMs associated with that account got removed I don't think we remove an account or its resources automatically if all users are removed in that account... Wondering if this is a valid test at all. Yes the test is invalid. It had been skipped earlier with (Open Questions) in the reason. Probably something that was in a test plan but didn't have clarity at the time it was written. I removed all skips in the tests so we'll find those invalid ones now. Ok. This one evidently failed cleanup and surfaced here: https://issues.apache.org/jira/browse/CLOUDSTACK-3746 It's this one in fact: https://issues.apache.org/jira/browse/CLOUDSTACK- 3745 We have a list of to-be-skipped tests? Just wondering how many more we have. -- Prasanna., Powered by BigRock.com -- Prasanna., Powered by BigRock.com
Review Request 13004: Bug:advance zone, create public Network with vlan id specified, but the portgroup is cloud.public.untagged.0.1-vSwitch0 not cloud.public.[vlanid].0.1-vSwitch0
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/13004/ --- Review request for cloudstack, edison su and Wei Zhou. Bugs: https://issues.apache.org/jira/browse/CLOUDSTACK-3883 Repository: cloudstack-git Description --- In lastest CS 4.2 code, I create advance zone with hypervisor vmware esxi, create public Network with vlan id 509 specified and label vSwitch0, when cs create systemvm(cpvm,ssvm), a new portgroup with name cloud.public.untagged.0.1-vSwitch0 was created, not a portgroup cloud.public.509.0.1-vSwitch0 as expected. in database table nics, the field broadcast_uri for new systemvm is vlan:509 , and should be vlan://509 debug the code and found it is a syntax error in Networks.java for new instance java.net.URI. Diffs - api/src/com/cloud/network/Networks.java c76c3d4 Diff: https://reviews.apache.org/r/13004/diff/ Testing --- recreate the system vm or create a new advance zone , public network with vlan Thanks, Jijun
Re: New Components on JIRA
On Wed, Jul 24, 2013 at 10:15:12AM +, Ram Ganesh wrote: Prasanna, How about - automation-product and automation-script components? Automation-product for all product bugs discovered by the automation engine and automation-script for all automation script issues? Right now - that distinction is not clear at least from the bug reports. We're reusing the same report for both script and product failure. So anything filed from an automated test failure should just be automation and on further analysis if it is found to be product failure, a clearer bug report would be necessary within the right component of the product - api, network, systemvm etc. Yes you are right. Component is not the right field. Maybe we could use Label. A JIRA report which reports product issues discovered out of automation will be very valuable. Maybe label is a field for that. So I noticed there is are a few issue types in JIRA - Bug, Improvement, Task and Test. We should use 'Test' for any thing related to automated tests. This will help the RMs filter out bugs that are not entirely product failures but may be missing/failing tests. Right now having automated tests show up in blocker and critical lists is a little confusing. I'm not really sure how we can track product issues caught by automated tests other than simple labelling may be? Would be a good report to have to reveal our coverage and strengthen the suites. The lifecycle of a bug as I see it is something like this Test fails on jenkins \ -- Test failure filed under issue type 'Test' \ -- If cloudstack issue, bug report filed with repro steps and logs | -- OR Test fixed appropriately, reviewed and pushed Similarly, for any bug filed, Bug found in product \ -- Identify if missing from tests and is automatable \ -- Add a 'Test' issue for addressing the missing test \ -- Push test to repo and add it to jenkins runs These may be [sic]'noble' goals, but it would be great if we collectively start the effort of identifying areas that can be covered using tests. -- Prasanna., Powered by BigRock.com
Re: Review Request 13004: Bug:advance zone, create public Network with vlan id specified, but the portgroup is cloud.public.untagged.0.1-vSwitch0 not cloud.public.[vlanid].0.1-vSwitch0
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/13004/#review24059 --- Review 13004 PASSED the build test The url of build cloudstack-master-with-patch #64 is : http://jenkins.cloudstack.org/job/cloudstack-master-with-patch/64/ - Jenkins Cloudstack.org On July 28, 2013, 11:49 a.m., Jijun wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/13004/ --- (Updated July 28, 2013, 11:49 a.m.) Review request for cloudstack, edison su and Wei Zhou. Bugs: https://issues.apache.org/jira/browse/CLOUDSTACK-3883 Repository: cloudstack-git Description --- In lastest CS 4.2 code, I create advance zone with hypervisor vmware esxi, create public Network with vlan id 509 specified and label vSwitch0, when cs create systemvm(cpvm,ssvm), a new portgroup with name cloud.public.untagged.0.1-vSwitch0 was created, not a portgroup cloud.public.509.0.1-vSwitch0 as expected. in database table nics, the field broadcast_uri for new systemvm is vlan:509 , and should be vlan://509 debug the code and found it is a syntax error in Networks.java for new instance java.net.URI. Diffs - api/src/com/cloud/network/Networks.java c76c3d4 Diff: https://reviews.apache.org/r/13004/diff/ Testing --- recreate the system vm or create a new advance zone , public network with vlan Thanks, Jijun
RE: New Components on JIRA
Agreed, test issues showing up in blockers/critical is confusing. I guess, for product issues found through automated tests, we could use Issue type = Bug and component = Automation in addition to the actual component where the bug is found. -Original Message- From: Prasanna Santhanam [mailto:t...@apache.org] Sent: Sunday, July 28, 2013 5:23 PM To: dev@cloudstack.apache.org Subject: Re: New Components on JIRA On Wed, Jul 24, 2013 at 10:15:12AM +, Ram Ganesh wrote: Prasanna, How about - automation-product and automation-script components? Automation-product for all product bugs discovered by the automation engine and automation-script for all automation script issues? Right now - that distinction is not clear at least from the bug reports. We're reusing the same report for both script and product failure. So anything filed from an automated test failure should just be automation and on further analysis if it is found to be product failure, a clearer bug report would be necessary within the right component of the product - api, network, systemvm etc. Yes you are right. Component is not the right field. Maybe we could use Label. A JIRA report which reports product issues discovered out of automation will be very valuable. Maybe label is a field for that. So I noticed there is are a few issue types in JIRA - Bug, Improvement, Task and Test. We should use 'Test' for any thing related to automated tests. This will help the RMs filter out bugs that are not entirely product failures but may be missing/failing tests. Right now having automated tests show up in blocker and critical lists is a little confusing. I'm not really sure how we can track product issues caught by automated tests other than simple labelling may be? Would be a good report to have to reveal our coverage and strengthen the suites. The lifecycle of a bug as I see it is something like this Test fails on jenkins \ -- Test failure filed under issue type 'Test' \ -- If cloudstack issue, bug report filed with repro steps and logs | -- OR Test fixed appropriately, reviewed and pushed Similarly, for any bug filed, Bug found in product \ -- Identify if missing from tests and is automatable \ -- Add a 'Test' issue for addressing the missing test \ -- Push test to repo and add it to jenkins runs These may be [sic]'noble' goals, but it would be great if we collectively start the effort of identifying areas that can be covered using tests. -- Prasanna., Powered by BigRock.com
Re: Meet up on July 20th - Hyderabad, India
Thanks for sharing them with us Nitin, good to discover interests and traction from students. Probably see you in next FOSS.in or any reachable conference. Cheers. On Sun, Jul 28, 2013 at 5:03 PM, Nitin Mehta nitin.me...@citrix.com wrote: Hi Rohit - Good to hear from you ? It went well and was well received. Most of the folks were able to run dev cloud. We have a good setup built with IIITH university and will be holding it more often there now. Hoping to gain more traction and interest from students as well going forward. Slides can be found @ http://www.slideshare.net/nitinmehta5203/hacking-apache-cloud-stack-2448584 2 Pics @ http://www.meetup.com/CloudStack-Hyderabad-Group/photos/16245252/ Thanks, -Nitin On 28/07/13 4:05 PM, Rohit Yadav bhais...@apache.org wrote: Hi Nitin, how did it go. Share presentation, videos, blogs if any. Cheers. On Thu, Jul 18, 2013 at 5:14 PM, Nitin Mehta nitin.me...@citrix.com wrote: There is an upcoming meet up on July 20th at Hyderabad, India There will be talks on CS architecture and hacking with devcloud. Detailed info @ http://www.meetup.com/CloudStack-Hyderabad-Group/events/125208462/ Thanks, -Nitin
CloudMonkey's new home
Based on our previous discussion thread[1], we've moved CloudMonkey out of ACS's repository to its new home [2]. Now, with 6f84e74a68d78705a06fe58f7927f42f61453a16 on master, we no longer have cloudmonkey in tools/cli. CloudMonkey will be within CloudStack project but now as an independent sub-project with its own repository and will have a faster need-basis release cycle. For doing that, please suggest on the release process or how it should work? If the present RM or someone wants to lead the release process? I just want to keep it simple with fast releases whenever we have a releasable candidate and semver[3] versioning. So, we ship things fast and don't worry if it breaks since we'll be shipping fast. We can after a fast lazy consensus/voting and publish via pypi and put the tarballs/zipballs under dists/ on ASF/CloudStack. Regards. [1] http://markmail.org/message/tjlr753xfhpw4uk4 [2] https://git-wip-us.apache.org/repos/asf?p=cloudstack-cloudmonkey.git [3] http://semver.org/
Re: Review Request 12999: [GSoC] Add mid-term report
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/12999/ --- (Updated July 28, 2013, 5:38 p.m.) Review request for cloudstack, Sebastien Goasguen and Hugo Trippaers. Changes --- I re-format sourcecodes inserted to report Repository: cloudstack-git Description --- I add the mid-term report for my GSoC project Diffs (updated) - docs/en-US/gsoc-midsummer-nguyen.xml 96c2de1 docs/en-US/images/l3_services.png PRE-CREATION docs/en-US/images/network_service.png PRE-CREATION docs/en-US/images/odl_structure.jpg PRE-CREATION Diff: https://reviews.apache.org/r/12999/diff/ Testing --- Built successfully with publican. Thanks, tuna
Re: Review Request 12654: Added logpath variable and replaced hardcoded path
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/12654/ --- (Updated July 28, 2013, 10:08 p.m.) Review request for cloudstack and Wido den Hollander. Changes --- just adding cloudstack group so this hits the mailing list. Repository: cloudstack-git Description --- Added logpath variable and replaced hardcoded path Diffs - scripts/vm/network/security_group.py 01e3660 Diff: https://reviews.apache.org/r/12654/diff/ Testing --- Tested if os.makedirs accepts a trailing slash. Thanks, Rene Diepstraten
Review Request 13008: Fix usage of vm.instancename.flag when generating VM names on ESX hypervisor
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/13008/ --- Review request for cloudstack, Alex Huang, Chip Childers, Kelven Yang, Sateesh Chodapuneedi, and William Chan. Bugs: CLOUDSTACK-3886 Repository: cloudstack-git Description --- The vminstancename flag has been incorrectly used to simply append the displayname to the internal VM name that shows up on vCenter in vmware deployments. It was intended to show the actual name supplied as hostname, on the hypervisor. This helps admins and deployers to quickly identify VMs and resolve issues related to those VMs. Its usage is very limited as it stands now. This fix corrects it to ensure that the name of the VM on the hypervisor matches the hostname if it is supplied, and if the vm.instancename.flag is set to true. Diffs - engine/orchestration/src/org/apache/cloudstack/platform/orchestration/CloudOrchestrator.java 96fb1d9 plugins/hypervisors/vmware/src/com/cloud/hypervisor/guru/VMwareGuru.java d1392c4 plugins/hypervisors/vmware/src/com/cloud/hypervisor/vmware/manager/VmwareStorageManagerImpl.java e5c33cc plugins/hypervisors/vmware/src/com/cloud/hypervisor/vmware/resource/VmwareResource.java 439163a plugins/hypervisors/vmware/src/com/cloud/storage/resource/VmwareStorageProcessor.java 02e4e64 server/src/com/cloud/ha/HighAvailabilityManagerImpl.java 25c5a04 server/src/com/cloud/hypervisor/HypervisorGuruBase.java ec68529 server/src/com/cloud/vm/UserVmManagerImpl.java 3831f88 server/src/com/cloud/vm/VirtualMachineManagerImpl.java a3187ba vmware-base/src/com/cloud/hypervisor/vmware/mo/ClusterMO.java 04ef0f8 vmware-base/src/com/cloud/hypervisor/vmware/mo/HostMO.java 2735fb0 vmware-base/src/com/cloud/hypervisor/vmware/mo/HypervisorHostHelper.java dd0f889 vmware-base/src/com/cloud/hypervisor/vmware/mo/VirtualMachineMO.java e2dd789 vmware-base/src/com/cloud/hypervisor/vmware/mo/VmwareHypervisorHost.java ac14328 Diff: https://reviews.apache.org/r/13008/diff/ Testing --- Post this change, all major VM operations, namely creation/destruction/expunging/start/stop/reboot of the VM have been tested and observed to work correctly. Part of this patch also puts in a fix for VMSync operations where the CS mgmt server doesn't detect that a guest VM is down, if the guest VM has been shut down/powered off in vCenter. Other operations such as VM snapshot, volume snapshots of disks belonging to the VM, volume migration across primaries, volume attach/detach have also been tested and they are working as expected. This is a functional change, and completely transparent to any of cloudstack's existing functionalities and all the test cases that cover the above code paths and APIs - all existing tests should and do pass - no new tests are necessary. Thanks, Venkata Siva Vijayendra Bhamidipati
Re: Review Request 13008: Fix usage of vm.instancename.flag when generating VM names on ESX hypervisor
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/13008/#review24078 --- Review 13008 failed the build test : FAILURE The url of build cloudstack-master-with-patch #65 is : http://jenkins.cloudstack.org/job/cloudstack-master-with-patch/65/ - Jenkins Cloudstack.org On July 29, 2013, 1:55 a.m., Venkata Siva Vijayendra Bhamidipati wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/13008/ --- (Updated July 29, 2013, 1:55 a.m.) Review request for cloudstack, Alex Huang, Chip Childers, Kelven Yang, Sateesh Chodapuneedi, and William Chan. Bugs: CLOUDSTACK-3886 Repository: cloudstack-git Description --- The vminstancename flag has been incorrectly used to simply append the displayname to the internal VM name that shows up on vCenter in vmware deployments. It was intended to show the actual name supplied as hostname, on the hypervisor. This helps admins and deployers to quickly identify VMs and resolve issues related to those VMs. Its usage is very limited as it stands now. This fix corrects it to ensure that the name of the VM on the hypervisor matches the hostname if it is supplied, and if the vm.instancename.flag is set to true. Diffs - engine/orchestration/src/org/apache/cloudstack/platform/orchestration/CloudOrchestrator.java 96fb1d9 plugins/hypervisors/vmware/src/com/cloud/hypervisor/guru/VMwareGuru.java d1392c4 plugins/hypervisors/vmware/src/com/cloud/hypervisor/vmware/manager/VmwareStorageManagerImpl.java e5c33cc plugins/hypervisors/vmware/src/com/cloud/hypervisor/vmware/resource/VmwareResource.java 439163a plugins/hypervisors/vmware/src/com/cloud/storage/resource/VmwareStorageProcessor.java 02e4e64 server/src/com/cloud/ha/HighAvailabilityManagerImpl.java 25c5a04 server/src/com/cloud/hypervisor/HypervisorGuruBase.java ec68529 server/src/com/cloud/vm/UserVmManagerImpl.java 3831f88 server/src/com/cloud/vm/VirtualMachineManagerImpl.java a3187ba vmware-base/src/com/cloud/hypervisor/vmware/mo/ClusterMO.java 04ef0f8 vmware-base/src/com/cloud/hypervisor/vmware/mo/HostMO.java 2735fb0 vmware-base/src/com/cloud/hypervisor/vmware/mo/HypervisorHostHelper.java dd0f889 vmware-base/src/com/cloud/hypervisor/vmware/mo/VirtualMachineMO.java e2dd789 vmware-base/src/com/cloud/hypervisor/vmware/mo/VmwareHypervisorHost.java ac14328 Diff: https://reviews.apache.org/r/13008/diff/ Testing --- Post this change, all major VM operations, namely creation/destruction/expunging/start/stop/reboot of the VM have been tested and observed to work correctly. Part of this patch also puts in a fix for VMSync operations where the CS mgmt server doesn't detect that a guest VM is down, if the guest VM has been shut down/powered off in vCenter. Other operations such as VM snapshot, volume snapshots of disks belonging to the VM, volume migration across primaries, volume attach/detach have also been tested and they are working as expected. This is a functional change, and completely transparent to any of cloudstack's existing functionalities and all the test cases that cover the above code paths and APIs - all existing tests should and do pass - no new tests are necessary. Thanks, Venkata Siva Vijayendra Bhamidipati
Re: Review Request 13008: Fix usage of vm.instancename.flag when generating VM names on ESX hypervisor
Hugo, My patch was intended for the 4.2 branch and not for master (it won't apply cleanly on master) – looks like jenkins is trying to patch this against the master branch and I'm seeing this failure – do I need to do something here? I can create a patch for master but I need this to go into 4.2 as well. Please advise. Also, I specified that the branch was 4.2 in the branch field of the review request – won't your scripts pick that up?? Regards, Vijay From: Jenkins Cloudstack.org h...@apache.orgmailto:h...@apache.org Reply-To: Jenkins Cloudstack.org h...@apache.orgmailto:h...@apache.org Date: Sunday, July 28, 2013 8:59 PM To: Kelven Yang kelven.y...@citrix.commailto:kelven.y...@citrix.com, Sateesh Chodapuneedi sateesh.chodapune...@citrix.commailto:sateesh.chodapune...@citrix.com, Will Chan will.c...@citrix.commailto:will.c...@citrix.com, Chip Childers chipchild...@apache.orgmailto:chipchild...@apache.org, Alex Huang alex.hu...@citrix.commailto:alex.hu...@citrix.com Cc: Vijayendra Bhamidipati vijayendra.bhamidip...@citrix.commailto:vijayendra.bhamidip...@citrix.com, cloudstack-...@incubator.apache.orgmailto:cloudstack-...@incubator.apache.org cloudstack-...@incubator.apache.orgmailto:cloudstack-...@incubator.apache.org, Jenkins Cloudstack.org h...@apache.orgmailto:h...@apache.org Subject: Re: Review Request 13008: Fix usage of vm.instancename.flag when generating VM names on ESX hypervisor This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/13008/ Review 13008 failed the build test : FAILURE The url of build cloudstack-master-with-patch #65 is : http://jenkins.cloudstack.org/job/cloudstack-master-with-patch/65/ - Jenkins Cloudstack.org On July 29th, 2013, 1:55 a.m. UTC, Venkata Siva Vijayendra Bhamidipati wrote: Review request for cloudstack, Alex Huang, Chip Childers, Kelven Yang, Sateesh Chodapuneedi, and William Chan. By Venkata Siva Vijayendra Bhamidipati. Updated July 29, 2013, 1:55 a.m. Bugs: CLOUDSTACK-3886 Repository: cloudstack-git Description The vminstancename flag has been incorrectly used to simply append the displayname to the internal VM name that shows up on vCenter in vmware deployments. It was intended to show the actual name supplied as hostname, on the hypervisor. This helps admins and deployers to quickly identify VMs and resolve issues related to those VMs. Its usage is very limited as it stands now. This fix corrects it to ensure that the name of the VM on the hypervisor matches the hostname if it is supplied, and if the vm.instancename.flag is set to true. Testing Post this change, all major VM operations, namely creation/destruction/expunging/start/stop/reboot of the VM have been tested and observed to work correctly. Part of this patch also puts in a fix for VMSync operations where the CS mgmt server doesn't detect that a guest VM is down, if the guest VM has been shut down/powered off in vCenter. Other operations such as VM snapshot, volume snapshots of disks belonging to the VM, volume migration across primaries, volume attach/detach have also been tested and they are working as expected. This is a functional change, and completely transparent to any of cloudstack's existing functionalities and all the test cases that cover the above code paths and APIs - all existing tests should and do pass - no new tests are necessary. Diffs * engine/orchestration/src/org/apache/cloudstack/platform/orchestration/CloudOrchestrator.java (96fb1d9) * plugins/hypervisors/vmware/src/com/cloud/hypervisor/guru/VMwareGuru.java (d1392c4) * plugins/hypervisors/vmware/src/com/cloud/hypervisor/vmware/manager/VmwareStorageManagerImpl.java (e5c33cc) * plugins/hypervisors/vmware/src/com/cloud/hypervisor/vmware/resource/VmwareResource.java (439163a) * plugins/hypervisors/vmware/src/com/cloud/storage/resource/VmwareStorageProcessor.java (02e4e64) * server/src/com/cloud/ha/HighAvailabilityManagerImpl.java (25c5a04) * server/src/com/cloud/hypervisor/HypervisorGuruBase.java (ec68529) * server/src/com/cloud/vm/UserVmManagerImpl.java (3831f88) * server/src/com/cloud/vm/VirtualMachineManagerImpl.java (a3187ba) * vmware-base/src/com/cloud/hypervisor/vmware/mo/ClusterMO.java (04ef0f8) * vmware-base/src/com/cloud/hypervisor/vmware/mo/HostMO.java (2735fb0) * vmware-base/src/com/cloud/hypervisor/vmware/mo/HypervisorHostHelper.java (dd0f889) * vmware-base/src/com/cloud/hypervisor/vmware/mo/VirtualMachineMO.java (e2dd789) * vmware-base/src/com/cloud/hypervisor/vmware/mo/VmwareHypervisorHost.java (ac14328) View Diffhttps://reviews.apache.org/r/13008/diff/
Review Request 13009: CLOUDSTACK-3744 - Accounts not cleaned up
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/13009/ --- Review request for cloudstack and Prasanna Santhanam. Bugs: CLOUDSTACK-3744 Repository: cloudstack-git Description --- Fix for CLOUDSTACK-3744. Order of cleanup of objects fixed. Diffs - test/integration/component/test_netscaler_nw_off.py 5fd2195 Diff: https://reviews.apache.org/r/13009/diff/ Testing --- Tested locally. Script is now passing and cleanup of all accounts done. Thanks, Sowmya Krishnan
Re: Review Request 12759: CLOUDSTACK-3669: Bringing down the dynamic scalable check (for VM whether it has xstools or vmware tools in it) to the management layer.
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/12759/#review24080 --- Ship it! Ship It! - Nitin Mehta On July 25, 2013, 6:05 a.m., Harikrishna Patnala wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/12759/ --- (Updated July 25, 2013, 6:05 a.m.) Review request for cloudstack, Abhinandan Prateek and Nitin Mehta. Bugs: CLOUDSTACK-3669 Repository: cloudstack-git Description --- CLOUDSTACK-3669: Bringing down the dynamic scalable check (for VM whether it has xstools or vmware tools in it) to the management layer. Diffs - core/src/com/cloud/agent/api/ScaleVmCommand.java 83cdcac plugins/hypervisors/xen/src/com/cloud/hypervisor/xen/resource/CitrixResourceBase.java 0fba0d9 server/src/com/cloud/vm/UserVmManagerImpl.java ae12523 server/src/com/cloud/vm/VirtualMachineManagerImpl.java 33dadf0 server/test/com/cloud/vm/VirtualMachineManagerImplTest.java 44a703d Diff: https://reviews.apache.org/r/12759/diff/ Testing --- Thanks, Harikrishna Patnala
RE: Review Request 13008: Fix usage of vm.instancename.flag when generating VM names on ESX hypervisor
+dev (the older dev@incubator mail id showed up in the previous mail - probably needs to be fixed in jenkins) From: Vijayendra Bhamidipati [vijayendra.bhamidip...@citrix.com] Sent: Sunday, July 28, 2013 9:11 PM To: Jenkins Cloudstack.org; Kelven Yang; Sateesh Chodapuneedi; Will Chan; Chip Childers; Alex Huang Cc: cloudstack; Hugo com Subject: Re: Review Request 13008: Fix usage of vm.instancename.flag when generating VM names on ESX hypervisor Hugo, My patch was intended for the 4.2 branch and not for master (it won't apply cleanly on master) – looks like jenkins is trying to patch this against the master branch and I'm seeing this failure – do I need to do something here? I can create a patch for master but I need this to go into 4.2 as well. Please advise. Also, I specified that the branch was 4.2 in the branch field of the review request – won't your scripts pick that up?? Regards, Vijay From: Jenkins Cloudstack.org h...@apache.orgmailto:h...@apache.org Reply-To: Jenkins Cloudstack.org h...@apache.orgmailto:h...@apache.org Date: Sunday, July 28, 2013 8:59 PM To: Kelven Yang kelven.y...@citrix.commailto:kelven.y...@citrix.com, Sateesh Chodapuneedi sateesh.chodapune...@citrix.commailto:sateesh.chodapune...@citrix.com, Will Chan will.c...@citrix.commailto:will.c...@citrix.com, Chip Childers chipchild...@apache.orgmailto:chipchild...@apache.org, Alex Huang alex.hu...@citrix.commailto:alex.hu...@citrix.com Cc: Vijayendra Bhamidipati vijayendra.bhamidip...@citrix.commailto:vijayendra.bhamidip...@citrix.com, cloudstack-...@incubator.apache.orgmailto:cloudstack-...@incubator.apache.org cloudstack-...@incubator.apache.orgmailto:cloudstack-...@incubator.apache.org, Jenkins Cloudstack.org h...@apache.orgmailto:h...@apache.org Subject: Re: Review Request 13008: Fix usage of vm.instancename.flag when generating VM names on ESX hypervisor This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/13008/ Review 13008 failed the build test : FAILURE The url of build cloudstack-master-with-patch #65 is : http://jenkins.cloudstack.org/job/cloudstack-master-with-patch/65/ - Jenkins Cloudstack.org On July 29th, 2013, 1:55 a.m. UTC, Venkata Siva Vijayendra Bhamidipati wrote: Review request for cloudstack, Alex Huang, Chip Childers, Kelven Yang, Sateesh Chodapuneedi, and William Chan. By Venkata Siva Vijayendra Bhamidipati. Updated July 29, 2013, 1:55 a.m. Bugs: CLOUDSTACK-3886 Repository: cloudstack-git Description The vminstancename flag has been incorrectly used to simply append the displayname to the internal VM name that shows up on vCenter in vmware deployments. It was intended to show the actual name supplied as hostname, on the hypervisor. This helps admins and deployers to quickly identify VMs and resolve issues related to those VMs. Its usage is very limited as it stands now. This fix corrects it to ensure that the name of the VM on the hypervisor matches the hostname if it is supplied, and if the vm.instancename.flag is set to true. Testing Post this change, all major VM operations, namely creation/destruction/expunging/start/stop/reboot of the VM have been tested and observed to work correctly. Part of this patch also puts in a fix for VMSync operations where the CS mgmt server doesn't detect that a guest VM is down, if the guest VM has been shut down/powered off in vCenter. Other operations such as VM snapshot, volume snapshots of disks belonging to the VM, volume migration across primaries, volume attach/detach have also been tested and they are working as expected. This is a functional change, and completely transparent to any of cloudstack's existing functionalities and all the test cases that cover the above code paths and APIs - all existing tests should and do pass - no new tests are necessary. Diffs * engine/orchestration/src/org/apache/cloudstack/platform/orchestration/CloudOrchestrator.java (96fb1d9) * plugins/hypervisors/vmware/src/com/cloud/hypervisor/guru/VMwareGuru.java (d1392c4) * plugins/hypervisors/vmware/src/com/cloud/hypervisor/vmware/manager/VmwareStorageManagerImpl.java (e5c33cc) * plugins/hypervisors/vmware/src/com/cloud/hypervisor/vmware/resource/VmwareResource.java (439163a) * plugins/hypervisors/vmware/src/com/cloud/storage/resource/VmwareStorageProcessor.java (02e4e64) * server/src/com/cloud/ha/HighAvailabilityManagerImpl.java (25c5a04) * server/src/com/cloud/hypervisor/HypervisorGuruBase.java (ec68529) * server/src/com/cloud/vm/UserVmManagerImpl.java (3831f88) * server/src/com/cloud/vm/VirtualMachineManagerImpl.java (a3187ba) * vmware-base/src/com/cloud/hypervisor/vmware/mo/ClusterMO.java (04ef0f8) * vmware-base/src/com/cloud/hypervisor/vmware/mo/HostMO.java (2735fb0) * vmware-base/src/com/cloud/hypervisor/vmware/mo/HypervisorHostHelper.java (dd0f889) *
Re: Review Request 13009: CLOUDSTACK-3744 - Accounts not cleaned up
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/13009/#review24082 --- test/integration/component/test_netscaler_nw_off.py https://reviews.apache.org/r/13009/#comment47926 I think you should remove the ntwk offering altogether from cleanup. Network offerings currently do not delete if the account's network deployed from that offering isn't shutdown in time. Since offerings are lightweight and do not consume physical/virtual resources, we should defer them from the cleanup process. - Prasanna Santhanam On July 29, 2013, 4:12 a.m., Sowmya Krishnan wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/13009/ --- (Updated July 29, 2013, 4:12 a.m.) Review request for cloudstack and Prasanna Santhanam. Bugs: CLOUDSTACK-3744 Repository: cloudstack-git Description --- Fix for CLOUDSTACK-3744. Order of cleanup of objects fixed. Diffs - test/integration/component/test_netscaler_nw_off.py 5fd2195 Diff: https://reviews.apache.org/r/13009/diff/ Testing --- Tested locally. Script is now passing and cleanup of all accounts done. Thanks, Sowmya Krishnan
Re: Review Request 12937: CLOUDSTACK-3779: Support System vm scaling on VMWare
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/12937/#review24081 --- engine/schema/src/com/cloud/upgrade/dao/Upgrade410to420.java https://reviews.apache.org/r/12937/#comment47925 Why do u need the java code for this ? This could be done by the sql query right server/src/com/cloud/server/ManagementServerImpl.java https://reviews.apache.org/r/12937/#comment47927 Why is this required ? - Nitin Mehta On July 26, 2013, 8:41 a.m., Harikrishna Patnala wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/12937/ --- (Updated July 26, 2013, 8:41 a.m.) Review request for cloudstack and Nitin Mehta. Bugs: CLOUDSTACK-3637 and CLOUDSTACK-3779 Repository: cloudstack-git Description --- CLOUDSTACK-3779: Support System vm scaling on VMWare Marked the system template new system template as dynamicallyScalable - handled upgrade case - moved dynamicallyScalable flag to vm_instance table from user_vm_details to support dynamic scaling of system vm This patch depends on previous review request https://reviews.apache.org/r/12759/ . please review and commit accordingly Diffs - engine/schema/src/com/cloud/upgrade/dao/Upgrade410to420.java d4b7b6d engine/schema/src/com/cloud/vm/VMInstanceVO.java e1d2892 engine/schema/src/com/cloud/vm/dao/UserVmDao.java b4f9991 engine/schema/src/com/cloud/vm/dao/UserVmDaoImpl.java 1c11563 plugins/hypervisors/xen/src/com/cloud/hypervisor/xen/resource/XenServer56FP1Resource.java 2cc592d server/src/com/cloud/hypervisor/HypervisorGuruBase.java 6d368bd server/src/com/cloud/server/ManagementServerImpl.java 7ac1254 server/src/com/cloud/vm/UserVmManagerImpl.java ae12523 server/test/com/cloud/vm/VirtualMachineManagerImplTest.java 44a703d setup/db/db/schema-410to420.sql 82ca403 Diff: https://reviews.apache.org/r/12937/diff/ Testing --- Thanks, Harikrishna Patnala
Re: Review Request 12934: Tests for egress firewall rules for advance zone
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/12934/ --- (Updated July 29, 2013, 4:57 a.m.) Review request for cloudstack, Girish Shilamkar, Jayapal Reddy, and Prasanna Santhanam. Changes --- code review changes. Repository: cloudstack-git Description --- Tests for egress firewall rules for advance zone. Diffs (updated) - test/integration/component/test_egress_fw_rules.py PRE-CREATION Diff: https://reviews.apache.org/r/12934/diff/ Testing --- Thanks, Ashutosh Kelkar
Re: Review Request 12934: Tests for egress firewall rules for advance zone
On July 26, 2013, 12:28 p.m., Jayapal Reddy wrote: test/integration/component/test_egress_fw_rules.py, line 370 https://reviews.apache.org/r/12934/diff/2/?file=328044#file328044line370 Please add network offering details also here. #1. deploy VM using network offering with egress policy true Done. On July 26, 2013, 12:28 p.m., Jayapal Reddy wrote: test/integration/component/test_egress_fw_rules.py, line 373 https://reviews.apache.org/r/12934/diff/2/?file=328044#file328044line373 Created network offering with egress policy True. That means by default all the guest traffic is allowed. If you create egress rules (ex: icmp) then the icmp traffic is blocked. So #4. Public Network should be reachable from the VM Done. On July 26, 2013, 12:28 p.m., Jayapal Reddy wrote: test/integration/component/test_egress_fw_rules.py, line 390 https://reviews.apache.org/r/12934/diff/2/?file=328044#file328044line390 I gone through the your test cases. I think you bit confused on the egress default policy and rules . Please update you test cases and test case comments as per below. 1. Network offering with egress_policy = true. - By default guest network traffic is allowed. - Egress rules traffic will be blocked and other traffic is allowed Ex: if you create egress rule for icmp traffic then except icmp other traffic is allowed. - Rules with DROP target added. -A FW_EGRESS_RULES -p icmp -j DROP 2. Network offering with egress_policy = false - By default the guest network traffic is blocked. - Egress rule traffic is allowed. If you create egress rule with icmp protocol then except icmp other traffic is blocked. -Rules added with target ACCEPT. -A FW_EGRESS_RULES -p icmp -j ACCPT The CIDR in the egress rules is guest network cidr. The traffic allowed/blocked for guest network CIDR. CIDR is not Public/destination network cidr. Added test scenario for guest network access check. On July 26, 2013, 12:28 p.m., Jayapal Reddy wrote: test/integration/component/test_egress_fw_rules.py, line 426 https://reviews.apache.org/r/12934/diff/2/?file=328044#file328044line426 In egress the CIDR is source CIDR (guest network CIDR). If you don't mention the CIDR it will take the default guest network CIDR. Egress compares the source CIDR. Done, added test scenario for guest network access check. - Ashutosh --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/12934/#review23939 --- On July 29, 2013, 4:57 a.m., Ashutosh Kelkar wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/12934/ --- (Updated July 29, 2013, 4:57 a.m.) Review request for cloudstack, Girish Shilamkar, Jayapal Reddy, and Prasanna Santhanam. Repository: cloudstack-git Description --- Tests for egress firewall rules for advance zone. Diffs - test/integration/component/test_egress_fw_rules.py PRE-CREATION Diff: https://reviews.apache.org/r/12934/diff/ Testing --- Thanks, Ashutosh Kelkar
Re: Review Request 13009: CLOUDSTACK-3744 - Accounts not cleaned up
On July 29, 2013, 4:35 a.m., Prasanna Santhanam wrote: test/integration/component/test_netscaler_nw_off.py, line 613 https://reviews.apache.org/r/13009/diff/1/?file=330048#file330048line613 I think you should remove the ntwk offering altogether from cleanup. Network offerings currently do not delete if the account's network deployed from that offering isn't shutdown in time. Since offerings are lightweight and do not consume physical/virtual resources, we should defer them from the cleanup process. Reason to wait on cleanup in this test is to remove the Netscaler devices added as part of the test. Those could be used for other tests. To remove the device, we need to wait on clean up of the networks as well. So we aren't really waiting on network offering cleanup. - Sowmya --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/13009/#review24082 --- On July 29, 2013, 4:12 a.m., Sowmya Krishnan wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/13009/ --- (Updated July 29, 2013, 4:12 a.m.) Review request for cloudstack and Prasanna Santhanam. Bugs: CLOUDSTACK-3744 Repository: cloudstack-git Description --- Fix for CLOUDSTACK-3744. Order of cleanup of objects fixed. Diffs - test/integration/component/test_netscaler_nw_off.py 5fd2195 Diff: https://reviews.apache.org/r/13009/diff/ Testing --- Tested locally. Script is now passing and cleanup of all accounts done. Thanks, Sowmya Krishnan
Re: Review Request 13009: CLOUDSTACK-3744 - Accounts not cleaned up
On July 29, 2013, 4:35 a.m., Prasanna Santhanam wrote: test/integration/component/test_netscaler_nw_off.py, line 613 https://reviews.apache.org/r/13009/diff/1/?file=330048#file330048line613 I think you should remove the ntwk offering altogether from cleanup. Network offerings currently do not delete if the account's network deployed from that offering isn't shutdown in time. Since offerings are lightweight and do not consume physical/virtual resources, we should defer them from the cleanup process. Sowmya Krishnan wrote: Reason to wait on cleanup in this test is to remove the Netscaler devices added as part of the test. Those could be used for other tests. To remove the device, we need to wait on clean up of the networks as well. So we aren't really waiting on network offering cleanup. Although, i could still remove the offering cleanup too... Will do that. - Sowmya --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/13009/#review24082 --- On July 29, 2013, 4:12 a.m., Sowmya Krishnan wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/13009/ --- (Updated July 29, 2013, 4:12 a.m.) Review request for cloudstack and Prasanna Santhanam. Bugs: CLOUDSTACK-3744 Repository: cloudstack-git Description --- Fix for CLOUDSTACK-3744. Order of cleanup of objects fixed. Diffs - test/integration/component/test_netscaler_nw_off.py 5fd2195 Diff: https://reviews.apache.org/r/13009/diff/ Testing --- Tested locally. Script is now passing and cleanup of all accounts done. Thanks, Sowmya Krishnan
