Re: Review Request 23605: CLOUDSTACK-7107: Disabling failed test cases
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/23605/#review48203 --- Commit 43dffaad5fd197c87a8dab087066f677a095dee7 in cloudstack's branch refs/heads/master from Koushik Das [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=43dffaa ] Revert CLOUDSTACK-7107: Disabling failed test case This reverts commit 186606a0bf82402e7755cd7998f133023cc96c6c. - ASF Subversion and Git Services On July 17, 2014, 7:47 a.m., Gaurav Aradhye wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/23605/ --- (Updated July 17, 2014, 7:47 a.m.) Review request for cloudstack and Girish Shilamkar. Bugs: CLOUDSTACK-7074 and CLOUDSTACK-7107 https://issues.apache.org/jira/browse/CLOUDSTACK-7074 https://issues.apache.org/jira/browse/CLOUDSTACK-7107 Repository: cloudstack-git Description --- Disabling failed test cases on master. Diffs - test/integration/smoke/test_primary_storage.py 66aec59 test/integration/smoke/test_vm_life_cycle.py 240ab68 Diff: https://reviews.apache.org/r/23605/diff/ Testing --- Thanks, Gaurav Aradhye
Re: Review Request 22799: Golden (Base) Primary Storage feature
Thank you, Sudha and Mike, So I will implement some regression test on Marvin to ensure this feature. BRs. On Mon, Jul 21, 2014 at 11:30 AM, Mike Tutkowski mike.tutkow...@solidfire.com wrote: Thanks for the note, Sudha. I was not aware we were treating Marvin tests are a requirement. That is interesting to know as I've not seen that rule followed all the time (as you say, perhaps people have been backing off on that informally). I agree, though, that automated tests are critical and going to become more so as additional features continue to be added to CloudStack. On Sun, Jul 20, 2014 at 10:23 PM, Sudha Ponnaganti sudha.ponnaga...@citrix.com wrote: Mike / Hieu, Thank you for your consideration. Even if it is not needed at the review time, can Marvin tests ( if applicable, simulator tests) can be added before you close on the feature. That would help to run regression tests on this feature for all releases. Some sort of automated tests ( unit tests or Marvin tests in place of unit tests) must be checked in for feature to be accepted. This was followed closely in the earlier releases and slowly this is being ignored. Can reviewers be more stringent regarding this merge criteria. Thanks /Sudha -Original Message- From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com] Sent: Sunday, July 20, 2014 9:16 PM To: dev@cloudstack.apache.org; Hieu LE Cc: Tim Mackey Subject: Re: Review Request 22799: Golden (Base) Primary Storage feature Thanks! Adding Marvin tests is not a prerequisite to your code being committed. I just strongly recommend you consider such tests. Essentially it is ideal to have Marvin tests, but not required. I'm glad to see the list of tests you've performed manually. Thanks for adding that to Review Board. On Sun, Jul 20, 2014 at 9:59 PM, Hieu LE hieul...@gmail.com wrote: On July 18, 2014, 4:16 a.m., Mike Tutkowski wrote: Hi, It's been a while since we've had any activity review wise on this feature. Can you guys tell me where we're currently at? Thanks! Mike Sorry Mike, There are some troubles with my machines last week. I have updated new diff and adding integration tests. Fooling around with marvin is great but may be I need more times with it. Thanks! Hieu LE - Hieu --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/22799/#review48109 --- On July 21, 2014, 3:56 a.m., Hieu LE wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/22799/ --- (Updated July 21, 2014, 3:56 a.m.) Review request for cloudstack, Mike Tutkowski and Tim Mackey. Repository: cloudstack-git Description --- As discussed in mailing list, this patch is applied for golden primary storage in [1]. I have changed the term from golden to base because there are some functions and variables in CloudStack also use base for base image. This patch only apply for Xen Server. [1]: https://cwiki.apache.org/confluence/display/CLOUDSTACK/Golden+Primary+ Storage Diffs - api/src/com/cloud/deploy/DeployDestination.java 4ded5ebe7a18252da471ee25019856f2b2f772e0 api/src/com/cloud/storage/StoragePool.java 8e03c3348f3a6dd3156ab9e440126ea317957dc0 api/src/com/cloud/template/VirtualMachineTemplate.java 599212bb039fdbb78511019e8f0a6ea4b4a84440 api/src/org/apache/cloudstack/api/ApiConstants.java ae5d6f05b6b52f60b151369a641cb11fcbb558af api/src/org/apache/cloudstack/api/BaseUpdateTemplateOrIsoCmd.java 2350f6b389203e2c6cc2182fe03fe9a95e936b81 api/src/org/apache/cloudstack/api/command/admin/storage/CreateStorageP oolCmd.java ae44bc9373232d242e4ebdcf76844969f0fe69fc api/src/org/apache/cloudstack/api/command/admin/storage/ListStoragePoo lsCmd.java ed123db api/src/org/apache/cloudstack/api/command/admin/storage/UpdateStorageP oolCmd.java 3d1a77353257c814efaf60875ffdf99603bc414e api/src/org/apache/cloudstack/api/command/user/template/RegisterTempla teCmd.java f478c9bc8eebf867a03deb4add1bf695ac3ec0ad api/src/org/apache/cloudstack/api/response/StoragePoolResponse.java 3571866fe74dca9aa5fe0d11373313eab97e94ac api/src/org/apache/cloudstack/api/response/TemplateResponse.java 3e21043e339103c021d3c9e767acac8b3837f760 core/src/com/cloud/agent/api/CheckPoolBelongToHostAnswer.java PRE-CREATION core/src/com/cloud/agent/api/CheckPoolBelongToHostCommand.java PRE-CREATION core/src/org/apache/cloudstack/storage/to/PrimaryDataStoreTO.java 29e53b0d9581f764a17ea285606213d2c045b029
Re: Review Request 23605: CLOUDSTACK-7107: Disabling failed test cases
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/23605/#review48204 --- Why would we want to disable test cases that fail? Doesn't this mean we need to fix something else so they don't fail anymore? - Hugo Trippaers On July 17, 2014, 7:47 a.m., Gaurav Aradhye wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/23605/ --- (Updated July 17, 2014, 7:47 a.m.) Review request for cloudstack and Girish Shilamkar. Bugs: CLOUDSTACK-7074 and CLOUDSTACK-7107 https://issues.apache.org/jira/browse/CLOUDSTACK-7074 https://issues.apache.org/jira/browse/CLOUDSTACK-7107 Repository: cloudstack-git Description --- Disabling failed test cases on master. Diffs - test/integration/smoke/test_primary_storage.py 66aec59 test/integration/smoke/test_vm_life_cycle.py 240ab68 Diff: https://reviews.apache.org/r/23605/diff/ Testing --- Thanks, Gaurav Aradhye
Replace primary secondary storage
Hi, I have production vms running on ACS 4.3 with xen 6.2 SP1. I have requirement to change primary Secondary storage. I am planning live storage migration for all running vms, after adding new storage as primary storage storage in same cluster. ( correct me if i am missing anything)..but how can i replace secondary storage? Regards, Tejas
Re: Review Request 23282: CLOUDSTACK-6845 : First Code drop for NuageVsp Network plugin
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/23282/#review48208 --- Ship it! commit 03de9cc33507400e0e06ccd84a36334a4660ef4e Author: Suresh Ramamurthy suresh.ramamur...@nuagenetworks.net Date: Mon Jul 21 09:40:45 2014 +0200 CLOUDSTACK-6845 : NuageVsp Network plugin Signed-off-by: Hugo Trippaers htrippa...@schubergphilis.com - Hugo Trippaers On July 19, 2014, 12:49 a.m., Suresh Ramamurthy wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/23282/ --- (Updated July 19, 2014, 12:49 a.m.) Review request for cloudstack, Alena Prokharchyk, Hugo Trippaers, and Sheng Yang. Bugs: CLOUDSTACK-6845 https://issues.apache.org/jira/browse/CLOUDSTACK-6845 Repository: cloudstack-git Description --- This is first code drop for NuageVsp Network plugin support that will bring the Nuage VSP network virtualization technology to CloudStack. We need a new branch to checkin the fixes once the review is done. Please create a new branch for NuageVsp plugin. Diffs - api/src/com/cloud/event/EventTypes.java 71bfdb6 api/src/com/cloud/network/Network.java 885bffe api/src/com/cloud/network/Networks.java 1e4d229 api/src/com/cloud/network/PhysicalNetwork.java 8cc214e client/WEB-INF/classes/resources/messages.properties b192cb0 client/WEB-INF/classes/resources/messages_zh_CN.properties 1ec4e95 client/pom.xml 46933d9 client/tomcatconf/commands.properties.in b9ac27b plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/OvsVifDriver.java 8e4c710 plugins/hypervisors/vmware/src/com/cloud/hypervisor/vmware/resource/VmwareResource.java 0922765 plugins/hypervisors/xenserver/src/com/cloud/hypervisor/xenserver/resource/CitrixResourceBase.java a2b9625 plugins/network-elements/nuage-vsp/pom.xml PRE-CREATION plugins/network-elements/nuage-vsp/resources/META-INF/cloudstack/vsp/module.properties PRE-CREATION plugins/network-elements/nuage-vsp/resources/META-INF/cloudstack/vsp/spring-vsp-context.xml PRE-CREATION plugins/network-elements/nuage-vsp/src/com/cloud/agent/api/StartupVspCommand.java PRE-CREATION plugins/network-elements/nuage-vsp/src/com/cloud/agent/api/VspResourceAnswer.java PRE-CREATION plugins/network-elements/nuage-vsp/src/com/cloud/agent/api/VspResourceCommand.java PRE-CREATION plugins/network-elements/nuage-vsp/src/com/cloud/agent/api/element/ApplyAclRuleVspAnswer.java PRE-CREATION plugins/network-elements/nuage-vsp/src/com/cloud/agent/api/element/ApplyAclRuleVspCommand.java PRE-CREATION plugins/network-elements/nuage-vsp/src/com/cloud/agent/api/element/ApplyStaticNatVspAnswer.java PRE-CREATION plugins/network-elements/nuage-vsp/src/com/cloud/agent/api/element/ApplyStaticNatVspCommand.java PRE-CREATION plugins/network-elements/nuage-vsp/src/com/cloud/agent/api/element/ShutDownVpcVspAnswer.java PRE-CREATION plugins/network-elements/nuage-vsp/src/com/cloud/agent/api/element/ShutDownVpcVspCommand.java PRE-CREATION plugins/network-elements/nuage-vsp/src/com/cloud/agent/api/guru/DeallocateVmVspAnswer.java PRE-CREATION plugins/network-elements/nuage-vsp/src/com/cloud/agent/api/guru/DeallocateVmVspCommand.java PRE-CREATION plugins/network-elements/nuage-vsp/src/com/cloud/agent/api/guru/ImplementNetworkVspAnswer.java PRE-CREATION plugins/network-elements/nuage-vsp/src/com/cloud/agent/api/guru/ImplementNetworkVspCommand.java PRE-CREATION plugins/network-elements/nuage-vsp/src/com/cloud/agent/api/guru/ReleaseVmVspAnswer.java PRE-CREATION plugins/network-elements/nuage-vsp/src/com/cloud/agent/api/guru/ReleaseVmVspCommand.java PRE-CREATION plugins/network-elements/nuage-vsp/src/com/cloud/agent/api/guru/ReserveVmInterfaceVspAnswer.java PRE-CREATION plugins/network-elements/nuage-vsp/src/com/cloud/agent/api/guru/ReserveVmInterfaceVspCommand.java PRE-CREATION plugins/network-elements/nuage-vsp/src/com/cloud/agent/api/guru/TrashNetworkVspAnswer.java PRE-CREATION plugins/network-elements/nuage-vsp/src/com/cloud/agent/api/guru/TrashNetworkVspCommand.java PRE-CREATION plugins/network-elements/nuage-vsp/src/com/cloud/agent/api/sync/SyncVspAnswer.java PRE-CREATION plugins/network-elements/nuage-vsp/src/com/cloud/agent/api/sync/SyncVspCommand.java PRE-CREATION plugins/network-elements/nuage-vsp/src/com/cloud/api/commands/AddNuageVspDeviceCmd.java PRE-CREATION plugins/network-elements/nuage-vsp/src/com/cloud/api/commands/DeleteNuageVspDeviceCmd.java PRE-CREATION
Re: Review Request 23282: CLOUDSTACK-6845 : First Code drop for NuageVsp Network plugin
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/23282/#review48207 --- Commit 03de9cc33507400e0e06ccd84a36334a4660ef4e in cloudstack's branch refs/heads/master from Suresh Ramamurthy [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=03de9cc ] CLOUDSTACK-6845 : NuageVsp Network plugin Signed-off-by: Hugo Trippaers htrippa...@schubergphilis.com - ASF Subversion and Git Services On July 19, 2014, 12:49 a.m., Suresh Ramamurthy wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/23282/ --- (Updated July 19, 2014, 12:49 a.m.) Review request for cloudstack, Alena Prokharchyk, Hugo Trippaers, and Sheng Yang. Bugs: CLOUDSTACK-6845 https://issues.apache.org/jira/browse/CLOUDSTACK-6845 Repository: cloudstack-git Description --- This is first code drop for NuageVsp Network plugin support that will bring the Nuage VSP network virtualization technology to CloudStack. We need a new branch to checkin the fixes once the review is done. Please create a new branch for NuageVsp plugin. Diffs - api/src/com/cloud/event/EventTypes.java 71bfdb6 api/src/com/cloud/network/Network.java 885bffe api/src/com/cloud/network/Networks.java 1e4d229 api/src/com/cloud/network/PhysicalNetwork.java 8cc214e client/WEB-INF/classes/resources/messages.properties b192cb0 client/WEB-INF/classes/resources/messages_zh_CN.properties 1ec4e95 client/pom.xml 46933d9 client/tomcatconf/commands.properties.in b9ac27b plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/OvsVifDriver.java 8e4c710 plugins/hypervisors/vmware/src/com/cloud/hypervisor/vmware/resource/VmwareResource.java 0922765 plugins/hypervisors/xenserver/src/com/cloud/hypervisor/xenserver/resource/CitrixResourceBase.java a2b9625 plugins/network-elements/nuage-vsp/pom.xml PRE-CREATION plugins/network-elements/nuage-vsp/resources/META-INF/cloudstack/vsp/module.properties PRE-CREATION plugins/network-elements/nuage-vsp/resources/META-INF/cloudstack/vsp/spring-vsp-context.xml PRE-CREATION plugins/network-elements/nuage-vsp/src/com/cloud/agent/api/StartupVspCommand.java PRE-CREATION plugins/network-elements/nuage-vsp/src/com/cloud/agent/api/VspResourceAnswer.java PRE-CREATION plugins/network-elements/nuage-vsp/src/com/cloud/agent/api/VspResourceCommand.java PRE-CREATION plugins/network-elements/nuage-vsp/src/com/cloud/agent/api/element/ApplyAclRuleVspAnswer.java PRE-CREATION plugins/network-elements/nuage-vsp/src/com/cloud/agent/api/element/ApplyAclRuleVspCommand.java PRE-CREATION plugins/network-elements/nuage-vsp/src/com/cloud/agent/api/element/ApplyStaticNatVspAnswer.java PRE-CREATION plugins/network-elements/nuage-vsp/src/com/cloud/agent/api/element/ApplyStaticNatVspCommand.java PRE-CREATION plugins/network-elements/nuage-vsp/src/com/cloud/agent/api/element/ShutDownVpcVspAnswer.java PRE-CREATION plugins/network-elements/nuage-vsp/src/com/cloud/agent/api/element/ShutDownVpcVspCommand.java PRE-CREATION plugins/network-elements/nuage-vsp/src/com/cloud/agent/api/guru/DeallocateVmVspAnswer.java PRE-CREATION plugins/network-elements/nuage-vsp/src/com/cloud/agent/api/guru/DeallocateVmVspCommand.java PRE-CREATION plugins/network-elements/nuage-vsp/src/com/cloud/agent/api/guru/ImplementNetworkVspAnswer.java PRE-CREATION plugins/network-elements/nuage-vsp/src/com/cloud/agent/api/guru/ImplementNetworkVspCommand.java PRE-CREATION plugins/network-elements/nuage-vsp/src/com/cloud/agent/api/guru/ReleaseVmVspAnswer.java PRE-CREATION plugins/network-elements/nuage-vsp/src/com/cloud/agent/api/guru/ReleaseVmVspCommand.java PRE-CREATION plugins/network-elements/nuage-vsp/src/com/cloud/agent/api/guru/ReserveVmInterfaceVspAnswer.java PRE-CREATION plugins/network-elements/nuage-vsp/src/com/cloud/agent/api/guru/ReserveVmInterfaceVspCommand.java PRE-CREATION plugins/network-elements/nuage-vsp/src/com/cloud/agent/api/guru/TrashNetworkVspAnswer.java PRE-CREATION plugins/network-elements/nuage-vsp/src/com/cloud/agent/api/guru/TrashNetworkVspCommand.java PRE-CREATION plugins/network-elements/nuage-vsp/src/com/cloud/agent/api/sync/SyncVspAnswer.java PRE-CREATION plugins/network-elements/nuage-vsp/src/com/cloud/agent/api/sync/SyncVspCommand.java PRE-CREATION plugins/network-elements/nuage-vsp/src/com/cloud/api/commands/AddNuageVspDeviceCmd.java PRE-CREATION plugins/network-elements/nuage-vsp/src/com/cloud/api/commands/DeleteNuageVspDeviceCmd.java PRE-CREATION
Re: Review Request 23282: CLOUDSTACK-6845 : First Code drop for NuageVsp Network plugin
Heya all, I’ve pushed support for the NuageVSP feature just now. Technically two days after the intended feature freeze for 4.6, but i think i can get away with it for the following reasons: * The feature was submitted on the review board before the feature freeze * The feature includes extensive unit tests and an integration test * Minor changes to core (just the minimum to enable the plugin), most real functionality is in a plugin * Review was approved by me before the feature freeze, just didn’t have time to run final checks and push it over the weekend. Does anyone have any objections to this? Cheers, Hugo On 21 jul. 2014, at 10:50, Hugo Trippaers htrippa...@schubergphilis.com wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/23282/#review48208 --- Ship it! commit 03de9cc33507400e0e06ccd84a36334a4660ef4e Author: Suresh Ramamurthy suresh.ramamur...@nuagenetworks.net Date: Mon Jul 21 09:40:45 2014 +0200 CLOUDSTACK-6845 : NuageVsp Network plugin Signed-off-by: Hugo Trippaers htrippa...@schubergphilis.com - Hugo Trippaers On July 19, 2014, 12:49 a.m., Suresh Ramamurthy wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/23282/ --- (Updated July 19, 2014, 12:49 a.m.) Review request for cloudstack, Alena Prokharchyk, Hugo Trippaers, and Sheng Yang. Bugs: CLOUDSTACK-6845 https://issues.apache.org/jira/browse/CLOUDSTACK-6845 Repository: cloudstack-git Description --- This is first code drop for NuageVsp Network plugin support that will bring the Nuage VSP network virtualization technology to CloudStack. We need a new branch to checkin the fixes once the review is done. Please create a new branch for NuageVsp plugin. Diffs - api/src/com/cloud/event/EventTypes.java 71bfdb6 api/src/com/cloud/network/Network.java 885bffe api/src/com/cloud/network/Networks.java 1e4d229 api/src/com/cloud/network/PhysicalNetwork.java 8cc214e client/WEB-INF/classes/resources/messages.properties b192cb0 client/WEB-INF/classes/resources/messages_zh_CN.properties 1ec4e95 client/pom.xml 46933d9 client/tomcatconf/commands.properties.in b9ac27b plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/OvsVifDriver.java 8e4c710 plugins/hypervisors/vmware/src/com/cloud/hypervisor/vmware/resource/VmwareResource.java 0922765 plugins/hypervisors/xenserver/src/com/cloud/hypervisor/xenserver/resource/CitrixResourceBase.java a2b9625 plugins/network-elements/nuage-vsp/pom.xml PRE-CREATION plugins/network-elements/nuage-vsp/resources/META-INF/cloudstack/vsp/module.properties PRE-CREATION plugins/network-elements/nuage-vsp/resources/META-INF/cloudstack/vsp/spring-vsp-context.xml PRE-CREATION plugins/network-elements/nuage-vsp/src/com/cloud/agent/api/StartupVspCommand.java PRE-CREATION plugins/network-elements/nuage-vsp/src/com/cloud/agent/api/VspResourceAnswer.java PRE-CREATION plugins/network-elements/nuage-vsp/src/com/cloud/agent/api/VspResourceCommand.java PRE-CREATION plugins/network-elements/nuage-vsp/src/com/cloud/agent/api/element/ApplyAclRuleVspAnswer.java PRE-CREATION plugins/network-elements/nuage-vsp/src/com/cloud/agent/api/element/ApplyAclRuleVspCommand.java PRE-CREATION plugins/network-elements/nuage-vsp/src/com/cloud/agent/api/element/ApplyStaticNatVspAnswer.java PRE-CREATION plugins/network-elements/nuage-vsp/src/com/cloud/agent/api/element/ApplyStaticNatVspCommand.java PRE-CREATION plugins/network-elements/nuage-vsp/src/com/cloud/agent/api/element/ShutDownVpcVspAnswer.java PRE-CREATION plugins/network-elements/nuage-vsp/src/com/cloud/agent/api/element/ShutDownVpcVspCommand.java PRE-CREATION plugins/network-elements/nuage-vsp/src/com/cloud/agent/api/guru/DeallocateVmVspAnswer.java PRE-CREATION plugins/network-elements/nuage-vsp/src/com/cloud/agent/api/guru/DeallocateVmVspCommand.java PRE-CREATION plugins/network-elements/nuage-vsp/src/com/cloud/agent/api/guru/ImplementNetworkVspAnswer.java PRE-CREATION plugins/network-elements/nuage-vsp/src/com/cloud/agent/api/guru/ImplementNetworkVspCommand.java PRE-CREATION plugins/network-elements/nuage-vsp/src/com/cloud/agent/api/guru/ReleaseVmVspAnswer.java PRE-CREATION plugins/network-elements/nuage-vsp/src/com/cloud/agent/api/guru/ReleaseVmVspCommand.java PRE-CREATION plugins/network-elements/nuage-vsp/src/com/cloud/agent/api/guru/ReserveVmInterfaceVspAnswer.java PRE-CREATION plugins/network-elements/nuage-vsp/src/com/cloud/agent/api/guru/ReserveVmInterfaceVspCommand.java PRE-CREATION
Re: Review Request 23605: CLOUDSTACK-7107: Disabling failed test cases
On July 21, 2014, 1:03 p.m., Hugo Trippaers wrote: Why would we want to disable test cases that fail? Doesn't this mean we need to fix something else so they don't fail anymore? Hi Hugo, Whenever we found a test case failing, we create bug for that, may it be a test script issue or product bug, so that the test case gets associated with a particular bug and it's easy to track in future why it is failing. Addition of this decorator BugId to test case skips the test in the run. Whenever the bug gets fixed, then the person who has fixed the bug removes the BugId decorator from test case so that the test case gets picked up in the next run. - Gaurav --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/23605/#review48204 --- On July 17, 2014, 1:17 p.m., Gaurav Aradhye wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/23605/ --- (Updated July 17, 2014, 1:17 p.m.) Review request for cloudstack and Girish Shilamkar. Bugs: CLOUDSTACK-7074 and CLOUDSTACK-7107 https://issues.apache.org/jira/browse/CLOUDSTACK-7074 https://issues.apache.org/jira/browse/CLOUDSTACK-7107 Repository: cloudstack-git Description --- Disabling failed test cases on master. Diffs - test/integration/smoke/test_primary_storage.py 66aec59 test/integration/smoke/test_vm_life_cycle.py 240ab68 Diff: https://reviews.apache.org/r/23605/diff/ Testing --- Thanks, Gaurav Aradhye
Build failed in Jenkins: build-master #1171
See http://jenkins.buildacloud.org/job/build-master/1171/changes Changes: [htrippaers] CLOUDSTACK-6845 : NuageVsp Network plugin -- [...truncated 4511 lines...] [INFO] Compiling 146 source files to http://jenkins.buildacloud.org/job/build-master/ws/services/console-proxy-rdp/rdpconsole/target/classes [INFO] [INFO] --- maven-resources-plugin:2.5:testResources (default-testResources) @ cloudstack-service-console-proxy-rdpclient --- [debug] execute contextualize [INFO] Using 'UTF-8' encoding to copy filtered resources. [INFO] skip non existing resourceDirectory http://jenkins.buildacloud.org/job/build-master/ws/services/console-proxy-rdp/rdpconsole/src/test/resources [INFO] Copying 3 resources [INFO] [INFO] --- maven-compiler-plugin:2.5.1:testCompile (default-testCompile) @ cloudstack-service-console-proxy-rdpclient --- [INFO] Compiling 3 source files to http://jenkins.buildacloud.org/job/build-master/ws/services/console-proxy-rdp/rdpconsole/target/test-classes [INFO] [INFO] --- maven-surefire-plugin:2.12:test (default-test) @ cloudstack-service-console-proxy-rdpclient --- [INFO] Surefire report directory: http://jenkins.buildacloud.org/job/build-master/ws/services/console-proxy-rdp/rdpconsole/target/surefire-reports --- T E S T S --- Running streamer.ByteBufferTest Tests run: 400, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.337 sec Running common.ClientTest Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.273 sec Running rdpclient.MockServerTest Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.362 sec Results : Tests run: 403, Failures: 0, Errors: 0, Skipped: 0 [INFO] [INFO] [INFO] Building Apache CloudStack Console Proxy 4.5.0-SNAPSHOT [INFO] [INFO] [INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ cloudstack-service-console-proxy --- [INFO] Deleting http://jenkins.buildacloud.org/job/build-master/ws/services/console-proxy/target (includes = [**/*], excludes = []) [INFO] Deleting http://jenkins.buildacloud.org/job/build-master/ws/services/console-proxy (includes = [target, dist], excludes = []) [INFO] [INFO] --- maven-checkstyle-plugin:2.11:check (cloudstack-checkstyle) @ cloudstack-service-console-proxy --- [INFO] Starting audit... Audit done. [INFO] [INFO] --- maven-remote-resources-plugin:1.3:process (default) @ cloudstack-service-console-proxy --- [INFO] [INFO] [INFO] Building Apache CloudStack Console Proxy - Server 4.5.0-SNAPSHOT [INFO] [INFO] [INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ cloud-console-proxy --- [INFO] Deleting http://jenkins.buildacloud.org/job/build-master/ws/services/console-proxy/server/target (includes = [**/*], excludes = []) [INFO] Deleting http://jenkins.buildacloud.org/job/build-master/ws/services/console-proxy/server (includes = [target, dist], excludes = []) [INFO] [INFO] --- maven-checkstyle-plugin:2.11:check (cloudstack-checkstyle) @ cloud-console-proxy --- [INFO] Starting audit... Audit done. [INFO] [INFO] --- maven-remote-resources-plugin:1.3:process (default) @ cloud-console-proxy --- [INFO] [INFO] --- maven-resources-plugin:2.5:resources (default-resources) @ cloud-console-proxy --- [debug] execute contextualize [INFO] Using 'UTF-8' encoding to copy filtered resources. [INFO] skip non existing resourceDirectory http://jenkins.buildacloud.org/job/build-master/ws/services/console-proxy/server/certs [INFO] Copying 3 resources [INFO] [INFO] --- maven-compiler-plugin:2.5.1:compile (default-compile) @ cloud-console-proxy --- [INFO] Compiling 58 source files to http://jenkins.buildacloud.org/job/build-master/ws/services/console-proxy/server/target/classes [INFO] [INFO] --- maven-resources-plugin:2.5:testResources (default-testResources) @ cloud-console-proxy --- [debug] execute contextualize [INFO] Using 'UTF-8' encoding to copy filtered resources. [INFO] skip non existing resourceDirectory http://jenkins.buildacloud.org/job/build-master/ws/services/console-proxy/server/test/resources [INFO] Copying 3 resources [INFO] [INFO] --- maven-compiler-plugin:2.5.1:testCompile (default-testCompile) @ cloud-console-proxy --- [INFO] Compiling 1 source file to http://jenkins.buildacloud.org/job/build-master/ws/services/console-proxy/server/target/test-classes [INFO] [INFO] --- maven-surefire-plugin:2.12:test (default-test) @ cloud-console-proxy --- [INFO] Surefire report directory:
Re: Review Request 23605: CLOUDSTACK-7107: Disabling failed test cases
Hey Gaurav, That doesn’t make a lot of sense to me. If the test sequence fails because of a bug it should keep failing until the bug is resolved, otherwise the tests will report that the situation is OK while in all reality it is not. These test should be in indication that Apache CloudStack is ready to release and if we hide tests that are failing we will never know the real status of the tests and give false information to people depending on the tests. Cheers, Hugo On 21 jul. 2014, at 10:58, Gaurav Aradhye gaurav.arad...@clogeny.com wrote: On July 21, 2014, 1:03 p.m., Hugo Trippaers wrote: Why would we want to disable test cases that fail? Doesn't this mean we need to fix something else so they don't fail anymore? Hi Hugo, Whenever we found a test case failing, we create bug for that, may it be a test script issue or product bug, so that the test case gets associated with a particular bug and it's easy to track in future why it is failing. Addition of this decorator BugId to test case skips the test in the run. Whenever the bug gets fixed, then the person who has fixed the bug removes the BugId decorator from test case so that the test case gets picked up in the next run. - Gaurav --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/23605/#review48204 --- On July 17, 2014, 1:17 p.m., Gaurav Aradhye wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/23605/ --- (Updated July 17, 2014, 1:17 p.m.) Review request for cloudstack and Girish Shilamkar. Bugs: CLOUDSTACK-7074 and CLOUDSTACK-7107 https://issues.apache.org/jira/browse/CLOUDSTACK-7074 https://issues.apache.org/jira/browse/CLOUDSTACK-7107 Repository: cloudstack-git Description --- Disabling failed test cases on master. Diffs - test/integration/smoke/test_primary_storage.py 66aec59 test/integration/smoke/test_vm_life_cycle.py 240ab68 Diff: https://reviews.apache.org/r/23605/diff/ Testing --- Thanks, Gaurav Aradhye
RE: Disabling failed test cases (was RE: Review Request 23605: CLOUDSTACK-7107: Disabling failed test cases)
In the case that it's a product bug, wouldn't it be better to keep running the test even if you know it's going to fail? That way, you get a consistent view of the overall pass rate from build to build. If you disable all the tests that are failing, you're going to get a 100% pass rate, but you can't see whether your quality is going up or down. -- Stephen Turner -Original Message- From: Gaurav Aradhye [mailto:nore...@reviews.apache.org] On Behalf Of Gaurav Aradhye Sent: 21 July 2014 09:58 To: Girish Shilamkar Cc: Gaurav Aradhye; Hugo Trippaers; cloudstack Subject: Re: Review Request 23605: CLOUDSTACK-7107: Disabling failed test cases On July 21, 2014, 1:03 p.m., Hugo Trippaers wrote: Why would we want to disable test cases that fail? Doesn't this mean we need to fix something else so they don't fail anymore? Hi Hugo, Whenever we found a test case failing, we create bug for that, may it be a test script issue or product bug, so that the test case gets associated with a particular bug and it's easy to track in future why it is failing. Addition of this decorator BugId to test case skips the test in the run. Whenever the bug gets fixed, then the person who has fixed the bug removes the BugId decorator from test case so that the test case gets picked up in the next run. - Gaurav --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/23605/#review48204 --- On July 17, 2014, 1:17 p.m., Gaurav Aradhye wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/23605/ --- (Updated July 17, 2014, 1:17 p.m.) Review request for cloudstack and Girish Shilamkar. Bugs: CLOUDSTACK-7074 and CLOUDSTACK-7107 https://issues.apache.org/jira/browse/CLOUDSTACK-7074 https://issues.apache.org/jira/browse/CLOUDSTACK-7107 Repository: cloudstack-git Description --- Disabling failed test cases on master. Diffs - test/integration/smoke/test_primary_storage.py 66aec59 test/integration/smoke/test_vm_life_cycle.py 240ab68 Diff: https://reviews.apache.org/r/23605/diff/ Testing --- Thanks, Gaurav Aradhye
Re: Build failed in Jenkins: build-master #1171
Should be fixed by commit 40d133dd7358be1940edd8e2a776e035c230c226 I didn’t see the error on my dev system as the proper jar file was present in my local maven cache so it could be found by mvm during the regular compile. Good find by Jenkins. Cheers, Hugo On 21 jul. 2014, at 11:01, jenk...@cloudstack.org wrote: See http://jenkins.buildacloud.org/job/build-master/1171/changes Changes: [htrippaers] CLOUDSTACK-6845 : NuageVsp Network plugin -- [...truncated 4511 lines...] [INFO] Compiling 146 source files to http://jenkins.buildacloud.org/job/build-master/ws/services/console-proxy-rdp/rdpconsole/target/classes [INFO] [INFO] --- maven-resources-plugin:2.5:testResources (default-testResources) @ cloudstack-service-console-proxy-rdpclient --- [debug] execute contextualize [INFO] Using 'UTF-8' encoding to copy filtered resources. [INFO] skip non existing resourceDirectory http://jenkins.buildacloud.org/job/build-master/ws/services/console-proxy-rdp/rdpconsole/src/test/resources [INFO] Copying 3 resources [INFO] [INFO] --- maven-compiler-plugin:2.5.1:testCompile (default-testCompile) @ cloudstack-service-console-proxy-rdpclient --- [INFO] Compiling 3 source files to http://jenkins.buildacloud.org/job/build-master/ws/services/console-proxy-rdp/rdpconsole/target/test-classes [INFO] [INFO] --- maven-surefire-plugin:2.12:test (default-test) @ cloudstack-service-console-proxy-rdpclient --- [INFO] Surefire report directory: http://jenkins.buildacloud.org/job/build-master/ws/services/console-proxy-rdp/rdpconsole/target/surefire-reports --- T E S T S --- Running streamer.ByteBufferTest Tests run: 400, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.337 sec Running common.ClientTest Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.273 sec Running rdpclient.MockServerTest Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.362 sec Results : Tests run: 403, Failures: 0, Errors: 0, Skipped: 0 [INFO] [INFO] [INFO] Building Apache CloudStack Console Proxy 4.5.0-SNAPSHOT [INFO] [INFO] [INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ cloudstack-service-console-proxy --- [INFO] Deleting http://jenkins.buildacloud.org/job/build-master/ws/services/console-proxy/target (includes = [**/*], excludes = []) [INFO] Deleting http://jenkins.buildacloud.org/job/build-master/ws/services/console-proxy (includes = [target, dist], excludes = []) [INFO] [INFO] --- maven-checkstyle-plugin:2.11:check (cloudstack-checkstyle) @ cloudstack-service-console-proxy --- [INFO] Starting audit... Audit done. [INFO] [INFO] --- maven-remote-resources-plugin:1.3:process (default) @ cloudstack-service-console-proxy --- [INFO] [INFO] [INFO] Building Apache CloudStack Console Proxy - Server 4.5.0-SNAPSHOT [INFO] [INFO] [INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ cloud-console-proxy --- [INFO] Deleting http://jenkins.buildacloud.org/job/build-master/ws/services/console-proxy/server/target (includes = [**/*], excludes = []) [INFO] Deleting http://jenkins.buildacloud.org/job/build-master/ws/services/console-proxy/server (includes = [target, dist], excludes = []) [INFO] [INFO] --- maven-checkstyle-plugin:2.11:check (cloudstack-checkstyle) @ cloud-console-proxy --- [INFO] Starting audit... Audit done. [INFO] [INFO] --- maven-remote-resources-plugin:1.3:process (default) @ cloud-console-proxy --- [INFO] [INFO] --- maven-resources-plugin:2.5:resources (default-resources) @ cloud-console-proxy --- [debug] execute contextualize [INFO] Using 'UTF-8' encoding to copy filtered resources. [INFO] skip non existing resourceDirectory http://jenkins.buildacloud.org/job/build-master/ws/services/console-proxy/server/certs [INFO] Copying 3 resources [INFO] [INFO] --- maven-compiler-plugin:2.5.1:compile (default-compile) @ cloud-console-proxy --- [INFO] Compiling 58 source files to http://jenkins.buildacloud.org/job/build-master/ws/services/console-proxy/server/target/classes [INFO] [INFO] --- maven-resources-plugin:2.5:testResources (default-testResources) @ cloud-console-proxy --- [debug] execute contextualize [INFO] Using 'UTF-8' encoding to copy filtered resources. [INFO] skip non existing resourceDirectory
Build failed in Jenkins: build-master #1172
See http://jenkins.buildacloud.org/job/build-master/1172/changes Changes: [htrippaers] NuageVSP is a noredist component -- Started by user Hugo [EnvInject] - Loading node environment variables. Building remotely on cloudstack-buildslave-centos6-a84 (cloudstack-buildslave-centos6) in workspace http://jenkins.buildacloud.org/job/build-master/ws/ Fetching changes from the remote Git repository Fetching upstream changes from https://git-wip-us.apache.org/repos/asf/cloudstack.git Checking out Revision 40d133dd7358be1940edd8e2a776e035c230c226 (origin/master) [copy-to-slave] Copying 'settings.xml', excluding nothing, from 'file:/var/lib/jenkins/userContent/' on the master to 'http://jenkins.buildacloud.org/job/build-master/ws/' on 'cloudstack-buildslave-centos6-a84'. [build-master] $ /jenkins/tools/hudson.tasks.Maven_MavenInstallation/maven-3.1.1/bin/mvn -s http://jenkins.buildacloud.org/job/build-master/ws/settings.xml -Psystemvm,awsapi clean test [INFO] Scanning for projects... [ERROR] The build could not read 1 project - [Help 1] [ERROR] [ERROR] The project org.apache.cloudstack:cloud-client-ui:4.5.0-SNAPSHOT (http://jenkins.buildacloud.org/job/build-master/ws/client/pom.xml) has 1 error [ERROR] 'profiles.profile.id' must be unique but found duplicate profile with id nuagevsp @ line 1032, column 11 [ERROR] [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch. [ERROR] Re-run Maven using the -X switch to enable full debug logging. [ERROR] [ERROR] For more information about the errors and possible solutions, please read the following articles: [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/ProjectBuildingException Build step 'Invoke top-level Maven targets' marked build as failure Recording test results
Re: [DISCUSS] Acquire New Ip from a different range on shared networks
On 15/07/14 3:29 AM, Silvano Nogueira Buback silv...@corp.globo.com wrote: Hi guys, At Globo.com we are working in a load balancer plugin for Cloudstack with a network api developed internally. This api manages shared networks and is working with cloudstack 4.3 (as a network guru implementation). Our load balancers are in a different network, so to implement a network element of load balancer, first I need to acquire an IP from the load balancers network. What is the best way to do this? Silvano, So you have bunch of public IP's that are accessible only in the network that has load balancers? You want to use only those public IP's for load balancing, any other public IP from zone public IP range is not usable for LB? Currently there is no way/API to mention from which range of Public IP's you want to acquire an IP. Not sure if this can help but there is more restrictive way you can achieve this. You can dedicated public IP range to an account, any attempt to acquire an IP by the account will result to allocation of IP from the dedicated public IP range. You can use that account to provision LB services. I looked at portable IPs and that makes sense to me, but I would prefer a solution where my guru can give this IP to the network. Is there any other way? Thanks in advance, Silvano Buback
Jenkins build is back to normal : build-master #1173
See http://jenkins.buildacloud.org/job/build-master/1173/changes
Re: Disabling failed test cases (was RE: Review Request 23605: CLOUDSTACK-7107: Disabling failed test cases)
Hugo, Stephen, We have been following this practice as part of Continuous Integration changes as defined in doc [1]. I personally think that tagging test case with BugId is good idea to map the test cases with bugs, but the test case should not be skipped when tagged. We can have discussion on this, and change the process if majority agree. Adding Santhosh. [1]: https://cwiki.apache.org/confluence/display/CLOUDSTACK/Cloudstack+-+Continuous+Integration Regards, Gaurav On Mon, Jul 21, 2014 at 2:37 PM, Stephen Turner stephen.tur...@citrix.com wrote: In the case that it's a product bug, wouldn't it be better to keep running the test even if you know it's going to fail? That way, you get a consistent view of the overall pass rate from build to build. If you disable all the tests that are failing, you're going to get a 100% pass rate, but you can't see whether your quality is going up or down. -- Stephen Turner -Original Message- From: Gaurav Aradhye [mailto:nore...@reviews.apache.org] On Behalf Of Gaurav Aradhye Sent: 21 July 2014 09:58 To: Girish Shilamkar Cc: Gaurav Aradhye; Hugo Trippaers; cloudstack Subject: Re: Review Request 23605: CLOUDSTACK-7107: Disabling failed test cases On July 21, 2014, 1:03 p.m., Hugo Trippaers wrote: Why would we want to disable test cases that fail? Doesn't this mean we need to fix something else so they don't fail anymore? Hi Hugo, Whenever we found a test case failing, we create bug for that, may it be a test script issue or product bug, so that the test case gets associated with a particular bug and it's easy to track in future why it is failing. Addition of this decorator BugId to test case skips the test in the run. Whenever the bug gets fixed, then the person who has fixed the bug removes the BugId decorator from test case so that the test case gets picked up in the next run. - Gaurav --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/23605/#review48204 --- On July 17, 2014, 1:17 p.m., Gaurav Aradhye wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/23605/ --- (Updated July 17, 2014, 1:17 p.m.) Review request for cloudstack and Girish Shilamkar. Bugs: CLOUDSTACK-7074 and CLOUDSTACK-7107 https://issues.apache.org/jira/browse/CLOUDSTACK-7074 https://issues.apache.org/jira/browse/CLOUDSTACK-7107 Repository: cloudstack-git Description --- Disabling failed test cases on master. Diffs - test/integration/smoke/test_primary_storage.py 66aec59 test/integration/smoke/test_vm_life_cycle.py 240ab68 Diff: https://reviews.apache.org/r/23605/diff/ Testing --- Thanks, Gaurav Aradhye
Re: Review Request 23282: CLOUDSTACK-6845 : First Code drop for NuageVsp Network plugin
On 19 jul. 2014, at 02:49, Suresh Ramamurthy suresh.ramamur...@nuagenetworks.net wrote: snip I had following questions regarding compiling only nuagevsp plugin a) To build only nuagevsp, is below command correct. mvn clean install -P developer,nuagevsp Correct b) To run client with nuagevsp in development setup, is the below correct: mvn -pl :cloud-client-ui jetty:run -P nuagevsp Correct c) To create rpm using package.sh, we need to pass NOREDIST option. But, this requires all the dependent jar file to be copied. Please correct me if my understanding is wrong. How do we build rpm with only nuagevsp plugin? At the moment we do not build an RPM with only the a single plugin enabled. People in the community distribute two sets of RPMs, the regular version and the version with all optional components. If you want to build a version of CloudStack with just the Nuage plugin you can modify the cloud.spec file yourself and add nuagevsp to the profiles manually. snip
Re: Review Request 23603: Fixed CLOUDSTACK-6983: unable to register lxc template
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/23603/ --- (Updated July 21, 2014, 9:53 a.m.) Review request for cloudstack, Kishan Kavala and Marcus Sorensen. Changes --- updated the patch Bugs: CLOUDSTACK-6983 https://issues.apache.org/jira/browse/CLOUDSTACK-6983 Repository: cloudstack-git Description --- added a check for tar.gz format in checktemplate Diffs (updated) - utils/src/org/apache/cloudstack/utils/template/TemplateUtils.java bad94de Diff: https://reviews.apache.org/r/23603/diff/ Testing --- manually tested register template on lxc Thanks, Rajani Karuturi
Re: DNS service on VR not responding
Hi Vihar, Are you referring to /etc/resolv.conf on the VR itself or on the guest VM? On the VR itself, there are only two entries on /etc/resolv.conf pointing to both Google public DNS servers. On the guest VM, there are 3 entries, one to the VR and two to the Google public DNS servers. If I commented out both Google DNS servers and only leaving the VR IP there, I cannot resolve anything. If the VR IP is commented out and leaving both Google DNS servers there, then I can resolve. So the issue is confirmed due to DNS service on the VR. But I am not too sure why it doesn't respond even though the dnsmasq service is running. Thank you. On Mon, Jul 21, 2014 at 1:00 PM, Vihar vih1...@gmail.com wrote: Hi , I would like you to comment second and third IP address I.e 4.2.2.2 and 8.8.8.8 and uncomment the first IP which is allocated to DNS and try to resolve the internet. It might be resolving the queries from external DNS server. If you are not able to resolve the names from VR, check if the DNS service is running properly for the IP which act as a DNS server. Regards Vihar On Jul 21, 2014 10:19 AM, Indra Pramana in...@sg.or.id wrote: Hi Sanjeev, Good day to you, and thank you for your reply. Yes, I can resolve domains without any issues from within the VR itself. root@r-2606-VM:/etc# ping yahoo.com PING yahoo.com (98.139.183.24): 56 data bytes 64 bytes from 98.139.183.24: icmp_seq=0 ttl=47 time=250.473 ms 64 bytes from 98.139.183.24: icmp_seq=1 ttl=47 time=239.240 ms 64 bytes from 98.139.183.24: icmp_seq=2 ttl=45 time=247.605 ms 64 bytes from 98.139.183.24: icmp_seq=3 ttl=45 time=244.913 ms ^C--- yahoo.com ping statistics --- 4 packets transmitted, 4 packets received, 0% packet loss round-trip min/avg/max/stddev = 239.240/245.558/250.473/4.144 ms root@r-2606-VM:/etc# ping google.com PING google.com (74.125.68.102): 56 data bytes 64 bytes from 74.125.68.102: icmp_seq=0 ttl=52 time=1.353 ms 64 bytes from 74.125.68.102: icmp_seq=1 ttl=52 time=1.199 ms 64 bytes from 74.125.68.102: icmp_seq=2 ttl=52 time=1.268 ms 64 bytes from 74.125.68.102: icmp_seq=3 ttl=52 time=1.287 ms ^C--- google.com ping statistics --- 4 packets transmitted, 4 packets received, 0% packet loss round-trip min/avg/max/stddev = 1.199/1.277/1.353/0.055 ms The VR uses 8.8.8.8 and 8.8.4.4 to resolve domains. root@r-2606-VM:/etc# cat /etc/resolv.conf nameserver 8.8.8.8 nameserver 8.8.4.4 I can ping both name servers without any issues. root@r-2606-VM:/etc# ping 8.8.8.8 PING 8.8.8.8 (8.8.8.8): 56 data bytes 64 bytes from 8.8.8.8: icmp_seq=0 ttl=52 time=4.693 ms 64 bytes from 8.8.8.8: icmp_seq=1 ttl=52 time=2.390 ms 64 bytes from 8.8.8.8: icmp_seq=2 ttl=52 time=2.523 ms 64 bytes from 8.8.8.8: icmp_seq=3 ttl=52 time=2.458 ms ^C--- 8.8.8.8 ping statistics --- 4 packets transmitted, 4 packets received, 0% packet loss round-trip min/avg/max/stddev = 2.390/3.016/4.693/0.969 ms root@r-2606-VM:/etc# ping 8.8.4.4 PING 8.8.4.4 (8.8.4.4): 56 data bytes 64 bytes from 8.8.4.4: icmp_seq=0 ttl=52 time=2.649 ms 64 bytes from 8.8.4.4: icmp_seq=1 ttl=52 time=2.458 ms 64 bytes from 8.8.4.4: icmp_seq=2 ttl=52 time=2.436 ms 64 bytes from 8.8.4.4: icmp_seq=3 ttl=52 time=2.393 ms ^C--- 8.8.4.4 ping statistics --- 4 packets transmitted, 4 packets received, 0% packet loss round-trip min/avg/max/stddev = 2.393/2.484/2.649/0.098 ms Looking forward to your reply, thank you. Cheers. On Mon, Jul 21, 2014 at 12:18 PM, Sanjeev Neelarapu sanjeev.neelar...@citrix.com wrote: Hi, Can you check if the VR is able to resolve the domain names by pinging from VR ? -Sanjeev -Original Message- From: Vihar [mailto:vih1...@gmail.com] Sent: Monday, July 21, 2014 5:43 AM To: us...@cloudstack.apache.org Cc: dev@cloudstack.apache.org Subject: RE: DNS service on VR not responding Hi, Yes, if I remove or comment out the first nameserver entry for the VR's IP, and only leaving 8.8.8.8 and 8.8.4.4, guest VMs will be running fine and will be able to resolve domains properly. Are you able to ping the first DNS server IP address that you commented out? Regards Vihar K On Jul 20, 2014 11:29 PM, Santhosh Edukulla santhosh.eduku...@citrix.com wrote: Do a traceroute to an external domain say google.com from guest vm, as you mentioned below, both by commenting out vr ip and not, in resolv.conf, you may see the difference. Yes, if I remove or comment out the first nameserver entry for the VR's IP, and only leaving 8.8.8.8 and 8.8.4.4, guest VMs will be running fine and will be able to resolve domains properly. Santhosh From: Indra Pramana [in...@sg.or.id] Sent: Sunday, July 20, 2014 1:48 PM To: us...@cloudstack.apache.org Cc: dev@cloudstack.apache.org Subject:
Wiki page https://cwiki.apache.org/confluence/display/CLOUDSTACK/Cloudstack+-+Continuous+Integration
Hey Santosh, On the wiki page there are two URLs in the paragraph of the Log Upload Job that i (and presumably a majority of the community can’t access) can you fix this? This is bit: Log Uploader Job: This job post the CI run uploads all logs to nfs share. All logs post the run are available under designated nfs share at nfs1.ex.com/var/www/4.4 version etc. The logs uploaded here, will have test case run log, product logs etc available here for analysis for failures\run information. Once logs are uploaded, people can see logs in web UI and browse them from UI available at by clicking on and selecting individual versions and hypervisors.EX: Http://10.147.38.151/LogAnalyzer Cheers, Hugo
RE: Wiki page https://cwiki.apache.org/confluence/display/CLOUDSTACK/Cloudstack+-+Continuous+Integration
sure. Those are example ref links, anyways, i just updated some thing like below, please let me know if its ok. Log Uploader Job: This job post the CI run uploads all logs to nfs share. All logs post the run are available under designated nfs share at configured location in CI, EX: //example-nfs.ex.com/var/www/4.4 version etc. The logs uploaded here, will have test case run log, product logs etc available here for analysis for failures\run information. Once logs are uploaded, people can see logs in web UI and browse them from UI available at by clicking on and selecting individual versions and hypervisors.EX: Http://Ip-address/LogAnalyzer Santhosh From: Trippie [trip...@gmail.com] on behalf of Hugo Trippaers [h...@apache.org] Sent: Monday, July 21, 2014 5:59 AM To: Santhosh Edukulla; dev@cloudstack.apache.org Subject: Wiki page https://cwiki.apache.org/confluence/display/CLOUDSTACK/Cloudstack+-+Continuous+Integration Hey Santosh, On the wiki page there are two URLs in the paragraph of the Log Upload Job that i (and presumably a majority of the community can’t access) can you fix this? This is bit: Log Uploader Job: This job post the CI run uploads all logs to nfs share. All logs post the run are available under designated nfs share at nfs1.ex.com/var/www/4.4 version etc. The logs uploaded here, will have test case run log, product logs etc available here for analysis for failures\run information. Once logs are uploaded, people can see logs in web UI and browse them from UI available at by clicking on and selecting individual versions and hypervisors.EX: Http://10.147.38.151/LogAnalyzer Cheers, Hugo
Re: Guidelines on Functional Test for plugins
Santosh, Talluri, Can you guys make sure the functional tests created by Suresh are integrated in the CI runs? test/integration//component/test_nuage_vsp.py Cheers, Hugo On 15 jul. 2014, at 14:07, Suresh Ramamurthy suresh.ramamur...@nuagenetworks.net wrote: Hi All, Can any one please point me to any document or example for sample FT for plugins. Testing plugin needs some setup tp be available. Is there any way in ACS framework where we can bypass the setup and still test the functionality? In some cases where the client library can not be redistributed, how do we test it? Please let me know so that I can write some FT for plugin that we are developing. Thanks, Suresh
RE: Disabling failed test cases (was RE: Review Request 23605: CLOUDSTACK-7107: Disabling failed test cases)
All, Alex, wanted to disable test cases in between CI( continuous integration) runs for the below reason for failures. I only, provided a way to achieve the same using tags, so that it will work for dual purpose, one not to effect community and can be used in CI as well, it will not effect if some body wanted to run all test cases immaterial of tags. Reason: In CI,automation auto kick starts every 3 hours( configurable) and picks up those delta changes and runs few checks, including sanity. Now, the idea was to keep baseline of testcases running as always pass. Now between two CI runs say T1 and T2, if there are new failures introduced, it will be automatically detected with new git changes and bugs are logged automatically against those check-ins. Now, till those bugs gets fixed, those were disabled keeping the baseline as always pass again. The window to fix those failures( either product or test case), through triage was almost constant and it need to be done soon, test cases are then enabled back once fixed, available in next available CI run again. It was to decide the failures between T1 and T2, as baseline is always clean and pass, otherwise CI runs may accumulate failures, and confuse over runs that which commits introduced failures. But, its not hard and fixed rule, we can discuss a better way as well, this was followed in 4.4 release in phase1 for CI, in another phase 2( WIP ), if we agree to some other better solution, then definitely it should be adopted. Santhosh From: Gaurav Aradhye [gaurav.arad...@clogeny.com] Sent: Monday, July 21, 2014 5:40 AM To: Stephen Turner; Hugo Trippaers; dev@cloudstack.apache.org; Santhosh Edukulla Cc: Girish Shilamkar Subject: Re: Disabling failed test cases (was RE: Review Request 23605: CLOUDSTACK-7107: Disabling failed test cases) Hugo, Stephen, We have been following this practice as part of Continuous Integration changes as defined in doc [1]. I personally think that tagging test case with BugId is good idea to map the test cases with bugs, but the test case should not be skipped when tagged. We can have discussion on this, and change the process if majority agree. Adding Santhosh. [1]: https://cwiki.apache.org/confluence/display/CLOUDSTACK/Cloudstack+-+Continuous+Integration Regards, Gaurav On Mon, Jul 21, 2014 at 2:37 PM, Stephen Turner stephen.tur...@citrix.commailto:stephen.tur...@citrix.com wrote: In the case that it's a product bug, wouldn't it be better to keep running the test even if you know it's going to fail? That way, you get a consistent view of the overall pass rate from build to build. If you disable all the tests that are failing, you're going to get a 100% pass rate, but you can't see whether your quality is going up or down. -- Stephen Turner -Original Message- From: Gaurav Aradhye [mailto:nore...@reviews.apache.orgmailto:nore...@reviews.apache.org] On Behalf Of Gaurav Aradhye Sent: 21 July 2014 09:58 To: Girish Shilamkar Cc: Gaurav Aradhye; Hugo Trippaers; cloudstack Subject: Re: Review Request 23605: CLOUDSTACK-7107: Disabling failed test cases On July 21, 2014, 1:03 p.m., Hugo Trippaers wrote: Why would we want to disable test cases that fail? Doesn't this mean we need to fix something else so they don't fail anymore? Hi Hugo, Whenever we found a test case failing, we create bug for that, may it be a test script issue or product bug, so that the test case gets associated with a particular bug and it's easy to track in future why it is failing. Addition of this decorator BugId to test case skips the test in the run. Whenever the bug gets fixed, then the person who has fixed the bug removes the BugId decorator from test case so that the test case gets picked up in the next run. - Gaurav --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/23605/#review48204 --- On July 17, 2014, 1:17 p.m., Gaurav Aradhye wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/23605/ --- (Updated July 17, 2014, 1:17 p.m.) Review request for cloudstack and Girish Shilamkar. Bugs: CLOUDSTACK-7074 and CLOUDSTACK-7107 https://issues.apache.org/jira/browse/CLOUDSTACK-7074 https://issues.apache.org/jira/browse/CLOUDSTACK-7107 Repository: cloudstack-git Description --- Disabling failed test cases on master. Diffs - test/integration/smoke/test_primary_storage.py 66aec59 test/integration/smoke/test_vm_life_cycle.py 240ab68 Diff: https://reviews.apache.org/r/23605/diff/ Testing --- Thanks, Gaurav Aradhye
Re: Disabling failed test cases (was RE: Review Request 23605: CLOUDSTACK-7107: Disabling failed test cases)
Hey Santosh, For keeping track of which component fails its generally better to let jenkins figure it out. As we use nosetest (i think) we can store all the test reports and jenkins can determine which component failed in which test run without having to disable tests. Especially if en/disabling tests is a manual action we can be sure that sooner or later we will start forgetting tests or keeping tests disabled because they fail often. Do we have a job that aggregates all the test reports at the moment? Cheers, Hugo On 21 jul. 2014, at 12:21, Santhosh Edukulla santhosh.eduku...@citrix.com wrote: All, Alex, wanted to disable test cases in between CI( continuous integration) runs for the below reason for failures. I only, provided a way to achieve the same using tags, so that it will work for dual purpose, one not to effect community and can be used in CI as well, it will not effect if some body wanted to run all test cases immaterial of tags. Reason: In CI,automation auto kick starts every 3 hours( configurable) and picks up those delta changes and runs few checks, including sanity. Now, the idea was to keep baseline of testcases running as always pass. Now between two CI runs say T1 and T2, if there are new failures introduced, it will be automatically detected with new git changes and bugs are logged automatically against those check-ins. Now, till those bugs gets fixed, those were disabled keeping the baseline as always pass again. The window to fix those failures( either product or test case), through triage was almost constant and it need to be done soon, test cases are then enabled back once fixed, available in next available CI run again. It was to decide the failures between T1 and T2, as baseline is always clean and pass, otherwise CI runs may accumulate failures, and confuse over runs that which commits introduced failures. But, its not hard and fixed rule, we can discuss a better way as well, this was followed in 4.4 release in phase1 for CI, in another phase 2( WIP ), if we agree to some other better solution, then definitely it should be adopted. Santhosh From: Gaurav Aradhye [gaurav.arad...@clogeny.com] Sent: Monday, July 21, 2014 5:40 AM To: Stephen Turner; Hugo Trippaers; dev@cloudstack.apache.org; Santhosh Edukulla Cc: Girish Shilamkar Subject: Re: Disabling failed test cases (was RE: Review Request 23605: CLOUDSTACK-7107: Disabling failed test cases) Hugo, Stephen, We have been following this practice as part of Continuous Integration changes as defined in doc [1]. I personally think that tagging test case with BugId is good idea to map the test cases with bugs, but the test case should not be skipped when tagged. We can have discussion on this, and change the process if majority agree. Adding Santhosh. [1]: https://cwiki.apache.org/confluence/display/CLOUDSTACK/Cloudstack+-+Continuous+Integration Regards, Gaurav On Mon, Jul 21, 2014 at 2:37 PM, Stephen Turner stephen.tur...@citrix.commailto:stephen.tur...@citrix.com wrote: In the case that it's a product bug, wouldn't it be better to keep running the test even if you know it's going to fail? That way, you get a consistent view of the overall pass rate from build to build. If you disable all the tests that are failing, you're going to get a 100% pass rate, but you can't see whether your quality is going up or down. -- Stephen Turner -Original Message- From: Gaurav Aradhye [mailto:nore...@reviews.apache.orgmailto:nore...@reviews.apache.org] On Behalf Of Gaurav Aradhye Sent: 21 July 2014 09:58 To: Girish Shilamkar Cc: Gaurav Aradhye; Hugo Trippaers; cloudstack Subject: Re: Review Request 23605: CLOUDSTACK-7107: Disabling failed test cases On July 21, 2014, 1:03 p.m., Hugo Trippaers wrote: Why would we want to disable test cases that fail? Doesn't this mean we need to fix something else so they don't fail anymore? Hi Hugo, Whenever we found a test case failing, we create bug for that, may it be a test script issue or product bug, so that the test case gets associated with a particular bug and it's easy to track in future why it is failing. Addition of this decorator BugId to test case skips the test in the run. Whenever the bug gets fixed, then the person who has fixed the bug removes the BugId decorator from test case so that the test case gets picked up in the next run. - Gaurav --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/23605/#review48204 --- On July 17, 2014, 1:17 p.m., Gaurav Aradhye wrote: --- This is an automatically generated e-mail. To reply, visit:
RE: Disabling failed test cases (was RE: Review Request 23605: CLOUDSTACK-7107: Disabling failed test cases)
In the beginning to get CI up and running, it would be ok to disable these handful of tests while getting fixes in, to achieve 100% pass rates. When CI runs in production, code changes need to be reverted if there are any new failures to keep CI pass rates at 100% (a known state to make CI effective). But should not just disable a test and move forward in long run. This should not be automated and make it as part of production CI process. Thanks /Sudha -Original Message- From: Santhosh Edukulla [mailto:santhosh.eduku...@citrix.com] Sent: Monday, July 21, 2014 3:22 AM To: Gaurav Aradhye; Stephen Turner; Hugo Trippaers; dev@cloudstack.apache.org Cc: Girish Shilamkar Subject: RE: Disabling failed test cases (was RE: Review Request 23605: CLOUDSTACK-7107: Disabling failed test cases) All, Alex, wanted to disable test cases in between CI( continuous integration) runs for the below reason for failures. I only, provided a way to achieve the same using tags, so that it will work for dual purpose, one not to effect community and can be used in CI as well, it will not effect if some body wanted to run all test cases immaterial of tags. Reason: In CI,automation auto kick starts every 3 hours( configurable) and picks up those delta changes and runs few checks, including sanity. Now, the idea was to keep baseline of testcases running as always pass. Now between two CI runs say T1 and T2, if there are new failures introduced, it will be automatically detected with new git changes and bugs are logged automatically against those check-ins. Now, till those bugs gets fixed, those were disabled keeping the baseline as always pass again. The window to fix those failures( either product or test case), through triage was almost constant and it need to be done soon, test cases are then enabled back once fixed, available in next available CI run again. It was to decide the failures between T1 and T2, as baseline is always clean and pass, otherwise CI runs may accumulate failures, and confuse over runs that which commits introduced failures. But, its not hard and fixed rule, we can discuss a better way as well, this was followed in 4.4 release in phase1 for CI, in another phase 2( WIP ), if we agree to some other better solution, then definitely it should be adopted. Santhosh From: Gaurav Aradhye [gaurav.arad...@clogeny.com] Sent: Monday, July 21, 2014 5:40 AM To: Stephen Turner; Hugo Trippaers; dev@cloudstack.apache.org; Santhosh Edukulla Cc: Girish Shilamkar Subject: Re: Disabling failed test cases (was RE: Review Request 23605: CLOUDSTACK-7107: Disabling failed test cases) Hugo, Stephen, We have been following this practice as part of Continuous Integration changes as defined in doc [1]. I personally think that tagging test case with BugId is good idea to map the test cases with bugs, but the test case should not be skipped when tagged. We can have discussion on this, and change the process if majority agree. Adding Santhosh. [1]: https://cwiki.apache.org/confluence/display/CLOUDSTACK/Cloudstack+-+Continuous+Integration Regards, Gaurav On Mon, Jul 21, 2014 at 2:37 PM, Stephen Turner stephen.tur...@citrix.commailto:stephen.tur...@citrix.com wrote: In the case that it's a product bug, wouldn't it be better to keep running the test even if you know it's going to fail? That way, you get a consistent view of the overall pass rate from build to build. If you disable all the tests that are failing, you're going to get a 100% pass rate, but you can't see whether your quality is going up or down. -- Stephen Turner -Original Message- From: Gaurav Aradhye [mailto:nore...@reviews.apache.orgmailto:nore...@reviews.apache.org] On Behalf Of Gaurav Aradhye Sent: 21 July 2014 09:58 To: Girish Shilamkar Cc: Gaurav Aradhye; Hugo Trippaers; cloudstack Subject: Re: Review Request 23605: CLOUDSTACK-7107: Disabling failed test cases On July 21, 2014, 1:03 p.m., Hugo Trippaers wrote: Why would we want to disable test cases that fail? Doesn't this mean we need to fix something else so they don't fail anymore? Hi Hugo, Whenever we found a test case failing, we create bug for that, may it be a test script issue or product bug, so that the test case gets associated with a particular bug and it's easy to track in future why it is failing. Addition of this decorator BugId to test case skips the test in the run. Whenever the bug gets fixed, then the person who has fixed the bug removes the BugId decorator from test case so that the test case gets picked up in the next run. - Gaurav --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/23605/#review48204 --- On July 17, 2014, 1:17 p.m., Gaurav Aradhye wrote:
Re: Wiki page https://cwiki.apache.org/confluence/display/CLOUDSTACK/Cloudstack+-+Continuous+Integration
Ok, I didn’t realize they were samples, isn’t the CI system running somewhere already? So the logs should be available somewhere right? Cheers, Hugo On 21 jul. 2014, at 12:09, Santhosh Edukulla santhosh.eduku...@citrix.com wrote: sure. Those are example ref links, anyways, i just updated some thing like below, please let me know if its ok. Log Uploader Job: This job post the CI run uploads all logs to nfs share. All logs post the run are available under designated nfs share at configured location in CI, EX: //example-nfs.ex.com/var/www/4.4 version etc. The logs uploaded here, will have test case run log, product logs etc available here for analysis for failures\run information. Once logs are uploaded, people can see logs in web UI and browse them from UI available at by clicking on and selecting individual versions and hypervisors.EX: Http://Ip-address/LogAnalyzer Santhosh From: Trippie [trip...@gmail.com] on behalf of Hugo Trippaers [h...@apache.org] Sent: Monday, July 21, 2014 5:59 AM To: Santhosh Edukulla; dev@cloudstack.apache.org Subject: Wiki page https://cwiki.apache.org/confluence/display/CLOUDSTACK/Cloudstack+-+Continuous+Integration Hey Santosh, On the wiki page there are two URLs in the paragraph of the Log Upload Job that i (and presumably a majority of the community can’t access) can you fix this? This is bit: Log Uploader Job: This job post the CI run uploads all logs to nfs share. All logs post the run are available under designated nfs share at nfs1.ex.com/var/www/4.4 version etc. The logs uploaded here, will have test case run log, product logs etc available here for analysis for failures\run information. Once logs are uploaded, people can see logs in web UI and browse them from UI available at by clicking on and selecting individual versions and hypervisors.EX: Http://10.147.38.151/LogAnalyzer Cheers, Hugo
Re: Disabling failed test cases (was RE: Review Request 23605: CLOUDSTACK-7107: Disabling failed test cases)
Hey Sudha, Sorry, but i disagree. The purpose of tests should not be to get a 100% pass rate. The tests should show an accurate state of the how the tests are doing versus the current state of the branch being tested. If tests fail we should fix why the tests fails and the system should not report an OK in the meantime. Doing so is too confusing, we need to be able to rely on the fact that if the tests report OK everything is actually OK. Cheers, Hugo On 21 jul. 2014, at 12:28, Sudha Ponnaganti sudha.ponnaga...@citrix.com wrote: In the beginning to get CI up and running, it would be ok to disable these handful of tests while getting fixes in, to achieve 100% pass rates. When CI runs in production, code changes need to be reverted if there are any new failures to keep CI pass rates at 100% (a known state to make CI effective). But should not just disable a test and move forward in long run. This should not be automated and make it as part of production CI process. Thanks /Sudha -Original Message- From: Santhosh Edukulla [mailto:santhosh.eduku...@citrix.com] Sent: Monday, July 21, 2014 3:22 AM To: Gaurav Aradhye; Stephen Turner; Hugo Trippaers; dev@cloudstack.apache.org Cc: Girish Shilamkar Subject: RE: Disabling failed test cases (was RE: Review Request 23605: CLOUDSTACK-7107: Disabling failed test cases) All, Alex, wanted to disable test cases in between CI( continuous integration) runs for the below reason for failures. I only, provided a way to achieve the same using tags, so that it will work for dual purpose, one not to effect community and can be used in CI as well, it will not effect if some body wanted to run all test cases immaterial of tags. Reason: In CI,automation auto kick starts every 3 hours( configurable) and picks up those delta changes and runs few checks, including sanity. Now, the idea was to keep baseline of testcases running as always pass. Now between two CI runs say T1 and T2, if there are new failures introduced, it will be automatically detected with new git changes and bugs are logged automatically against those check-ins. Now, till those bugs gets fixed, those were disabled keeping the baseline as always pass again. The window to fix those failures( either product or test case), through triage was almost constant and it need to be done soon, test cases are then enabled back once fixed, available in next available CI run again. It was to decide the failures between T1 and T2, as baseline is always clean and pass, otherwise CI runs may accumulate failures, and confuse over runs that which commits introduced failures. But, its not hard and fixed rule, we can discuss a better way as well, this was followed in 4.4 release in phase1 for CI, in another phase 2( WIP ), if we agree to some other better solution, then definitely it should be adopted. Santhosh From: Gaurav Aradhye [gaurav.arad...@clogeny.com] Sent: Monday, July 21, 2014 5:40 AM To: Stephen Turner; Hugo Trippaers; dev@cloudstack.apache.org; Santhosh Edukulla Cc: Girish Shilamkar Subject: Re: Disabling failed test cases (was RE: Review Request 23605: CLOUDSTACK-7107: Disabling failed test cases) Hugo, Stephen, We have been following this practice as part of Continuous Integration changes as defined in doc [1]. I personally think that tagging test case with BugId is good idea to map the test cases with bugs, but the test case should not be skipped when tagged. We can have discussion on this, and change the process if majority agree. Adding Santhosh. [1]: https://cwiki.apache.org/confluence/display/CLOUDSTACK/Cloudstack+-+Continuous+Integration Regards, Gaurav On Mon, Jul 21, 2014 at 2:37 PM, Stephen Turner stephen.tur...@citrix.commailto:stephen.tur...@citrix.com wrote: In the case that it's a product bug, wouldn't it be better to keep running the test even if you know it's going to fail? That way, you get a consistent view of the overall pass rate from build to build. If you disable all the tests that are failing, you're going to get a 100% pass rate, but you can't see whether your quality is going up or down. -- Stephen Turner -Original Message- From: Gaurav Aradhye [mailto:nore...@reviews.apache.orgmailto:nore...@reviews.apache.org] On Behalf Of Gaurav Aradhye Sent: 21 July 2014 09:58 To: Girish Shilamkar Cc: Gaurav Aradhye; Hugo Trippaers; cloudstack Subject: Re: Review Request 23605: CLOUDSTACK-7107: Disabling failed test cases On July 21, 2014, 1:03 p.m., Hugo Trippaers wrote: Why would we want to disable test cases that fail? Doesn't this mean we need to fix something else so they don't fail anymore? Hi Hugo, Whenever we found a test case failing, we create bug for that, may it be a test script issue or product bug, so that the test case gets associated with a
RE: Wiki page https://cwiki.apache.org/confluence/display/CLOUDSTACK/Cloudstack+-+Continuous+Integration
Yes, its running inside now and so logs are available only to internal users, but there was a discussion on dev list to make it public, which was not concluded( i believe ). Once it will be made public, we can adopt the similar approach to facilitate others for viewing\other action. Regards, Santhosh From: Trippie [trip...@gmail.com] on behalf of Hugo Trippaers [h...@apache.org] Sent: Monday, July 21, 2014 6:29 AM To: dev@cloudstack.apache.org Subject: Re: Wiki page https://cwiki.apache.org/confluence/display/CLOUDSTACK/Cloudstack+-+Continuous+Integration Ok, I didn’t realize they were samples, isn’t the CI system running somewhere already? So the logs should be available somewhere right? Cheers, Hugo On 21 jul. 2014, at 12:09, Santhosh Edukulla santhosh.eduku...@citrix.com wrote: sure. Those are example ref links, anyways, i just updated some thing like below, please let me know if its ok. Log Uploader Job: This job post the CI run uploads all logs to nfs share. All logs post the run are available under designated nfs share at configured location in CI, EX: //example-nfs.ex.com/var/www/4.4 version etc. The logs uploaded here, will have test case run log, product logs etc available here for analysis for failures\run information. Once logs are uploaded, people can see logs in web UI and browse them from UI available at by clicking on and selecting individual versions and hypervisors.EX: Http://Ip-address/LogAnalyzer Santhosh From: Trippie [trip...@gmail.com] on behalf of Hugo Trippaers [h...@apache.org] Sent: Monday, July 21, 2014 5:59 AM To: Santhosh Edukulla; dev@cloudstack.apache.org Subject: Wiki page https://cwiki.apache.org/confluence/display/CLOUDSTACK/Cloudstack+-+Continuous+Integration Hey Santosh, On the wiki page there are two URLs in the paragraph of the Log Upload Job that i (and presumably a majority of the community can’t access) can you fix this? This is bit: Log Uploader Job: This job post the CI run uploads all logs to nfs share. All logs post the run are available under designated nfs share at nfs1.ex.com/var/www/4.4 version etc. The logs uploaded here, will have test case run log, product logs etc available here for analysis for failures\run information. Once logs are uploaded, people can see logs in web UI and browse them from UI available at by clicking on and selecting individual versions and hypervisors.EX: Http://10.147.38.151/LogAnalyzer Cheers, Hugo
Re: Replace primary secondary storage
Hi, I found this article http://support.citrix.com/article/CTX135229 I was just going through this but could not get some of the points. Currently I have no snapshots and all templates are public another secondary storage is not added yet. 1) In above article 2nd point says Copy the snapshots and templates from Secondary Storage host S2 to S1. 6th point in article says You must copy only private templates on Secondary storage host S2 to S1. Here I got confused a little. 2) currently both tables are showing empty as shown below. Am I doing anything wrong or it is normal? mysql select sechost_id from snapshots; Empty set (0.00 sec) mysql select host_id from template_host_ref; Empty set (0.00 sec) Regards, Tejas On Mon, Jul 21, 2014 at 1:02 PM, Tejas Gadaria refond.g...@gmail.com wrote: Hi, I have production vms running on ACS 4.3 with xen 6.2 SP1. I have requirement to change primary Secondary storage. I am planning live storage migration for all running vms, after adding new storage as primary storage storage in same cluster. ( correct me if i am missing anything)..but how can i replace secondary storage? Regards, Tejas
Re: [PROPOSAL] Adding a plugin to check the password strength of all users
For the first part I am planning to add parameters to global settings. But for the 2nd part I think it depends on where we are integrating this plugin. To start with I will integrate it with abstract layer of Authenticator implementations and we can override in the corresponding authenticator on need basis. Thanks Damoder/ On 18-Jul-2014, at 10:28 pm, Demetrius Tsitrelis demetrius.tsitre...@citrix.com wrote: So the plugin will show the strength AND it will enforce the strength when a user is created or updates his password. Will it be possible for an administrator to disable either of these? For both of those capabilities is the plugin's behavior configurable for different authentication encoders? That is, could I have one set of rules for the SHA256 authenticator and a different set of rules for the MD5 authenticator? -Original Message- From: Damoder Reddy [mailto:damoder.re...@citrix.com] Sent: Friday, July 18, 2014 9:13 AM To: dev@cloudstack.apache.org Subject: Re: [PROPOSAL] Adding a plugin to check the password strength of all users Will show the strength of the password as well. On 18-Jul-2014, at 6:53 pm, Demetrius Tsitrelis demetrius.tsitre...@citrix.com wrote: Will the plugin merely show the strength of the password or will the plugin prevent the use of weak passwords? From: Damoder Reddy [damoder.re...@citrix.com] Sent: Thursday, July 17, 2014 11:02 PM To: dev@cloudstack.apache.org Subject: [PROPOSAL] Adding a plugin to check the password strength of all users Hi all, I am thinking to add a plugin which enables to check the password strength of a user while setting/resetting the password for that user. why as a plugin because different companies may have a different rule sets to check the password strength. The default implementation will have the password strength calculation based on the following parameters 1. Length of the password 2. Number of Character Sets involved in the password defined. For ex, Upper Case Letter, Lower Case letter, Digits and special character set. Ay suggestions/Comments? Thanks Damoder
RE: Disabling failed test cases (was RE: Review Request 23605: CLOUDSTACK-7107: Disabling failed test cases)
Tagging is good: that will allow you to see whether a failure is new or known about. Maybe the tag could even contain a date when it was added, to spot failures which are not receiving attention. But I don’t like to see tests skipped whenever we have a bug that is causing them to fail. -- Stephen Turner From: Gaurav Aradhye [mailto:gaurav.arad...@clogeny.com] Sent: 21 July 2014 10:41 To: Stephen Turner; Hugo Trippaers; dev@cloudstack.apache.org; Santhosh Edukulla Cc: Girish Shilamkar Subject: Re: Disabling failed test cases (was RE: Review Request 23605: CLOUDSTACK-7107: Disabling failed test cases) Hugo, Stephen, We have been following this practice as part of Continuous Integration changes as defined in doc [1]. I personally think that tagging test case with BugId is good idea to map the test cases with bugs, but the test case should not be skipped when tagged. We can have discussion on this, and change the process if majority agree. Adding Santhosh. [1]: https://cwiki.apache.org/confluence/display/CLOUDSTACK/Cloudstack+-+Continuous+Integration Regards, Gaurav On Mon, Jul 21, 2014 at 2:37 PM, Stephen Turner stephen.tur...@citrix.commailto:stephen.tur...@citrix.com wrote: In the case that it's a product bug, wouldn't it be better to keep running the test even if you know it's going to fail? That way, you get a consistent view of the overall pass rate from build to build. If you disable all the tests that are failing, you're going to get a 100% pass rate, but you can't see whether your quality is going up or down. -- Stephen Turner -Original Message- From: Gaurav Aradhye [mailto:nore...@reviews.apache.orgmailto:nore...@reviews.apache.org] On Behalf Of Gaurav Aradhye Sent: 21 July 2014 09:58 To: Girish Shilamkar Cc: Gaurav Aradhye; Hugo Trippaers; cloudstack Subject: Re: Review Request 23605: CLOUDSTACK-7107: Disabling failed test cases On July 21, 2014, 1:03 p.m., Hugo Trippaers wrote: Why would we want to disable test cases that fail? Doesn't this mean we need to fix something else so they don't fail anymore? Hi Hugo, Whenever we found a test case failing, we create bug for that, may it be a test script issue or product bug, so that the test case gets associated with a particular bug and it's easy to track in future why it is failing. Addition of this decorator BugId to test case skips the test in the run. Whenever the bug gets fixed, then the person who has fixed the bug removes the BugId decorator from test case so that the test case gets picked up in the next run. - Gaurav --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/23605/#review48204 --- On July 17, 2014, 1:17 p.m., Gaurav Aradhye wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/23605/ --- (Updated July 17, 2014, 1:17 p.m.) Review request for cloudstack and Girish Shilamkar. Bugs: CLOUDSTACK-7074 and CLOUDSTACK-7107 https://issues.apache.org/jira/browse/CLOUDSTACK-7074 https://issues.apache.org/jira/browse/CLOUDSTACK-7107 Repository: cloudstack-git Description --- Disabling failed test cases on master. Diffs - test/integration/smoke/test_primary_storage.py 66aec59 test/integration/smoke/test_vm_life_cycle.py 240ab68 Diff: https://reviews.apache.org/r/23605/diff/ Testing --- Thanks, Gaurav Aradhye
Re: [VOTE][ACS44]Apache CloudStack 4.4.0 RC 2 in branch 4.4-RC20140716T1409
abandoning vote due to bad quorum :( On Sat, Jul 19, 2014 at 5:28 PM, Pierre-Luc Dion pd...@cloudops.com wrote: Ran into issue when trying to upgrade from 4.2.1. Got the following database upgrade failure: http://pastebin.com/wkkAVYu0 Jira: https://issues.apache.org/jira/browse/CLOUDSTACK-7140 *Pierre-Luc DION* Architecte de Solution Cloud | Cloud Solutions Architect t 855.652.5683 *CloudOps* Votre partenaire infonuagique* | *Cloud Solutions Experts 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6 w cloudops.com *|* tw @CloudOps_ On Wed, Jul 16, 2014 at 8:24 AM, Daan Hoogland daan.hoogl...@gmail.com wrote: Hi All, I've created a 4.4.0 release, with the following artifacts up for a vote: Git Branch and Commit SH: https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=shortlog;h=refs/heads/4.4-RC20140716T1409 Commit: c9672d8b5710e597bca3a81a7b06dc90c7f5b1f7 List of changes: http://docs.cloudstack.apache.org/projects/cloudstack-release-notes/en/latest/ Source release (checksums and signatures are available at the same location): https://dist.apache.org/repos/dist/dev/cloudstack/4.4.0/ PGP release keys (signed using 4096R/AA4736F3): https://dist.apache.org/repos/dist/release/cloudstack/KEYS Vote will be open for 72 hours. For sanity in tallying the vote, can PMC members please be sure to indicate (binding) with their vote? [ ] +1 approve [ ] +0 no opinion [ ] -1 disapprove (and reason why) -- Daan -- Daan
RE: Disabling failed test cases (was RE: Review Request 23605: CLOUDSTACK-7107: Disabling failed test cases)
Hugo, I absolutely agree with you that tests should not be disabled and fixes should be made before check in. As per what Alex has mentioned in his CI enablement mail [1], premise of CI is that it runs at 100% pass rates and if any check in causes failure in CI Run, the bad check-in is easily identified that check-in gets reverted, so rest of the check-ins would move forward so this failure would not block rest of the community and health of branch is maintained. To enable CI in to production, it is absolutely necessary to get 100% pass rate before turning on CI otherwise all master check-ins will halt because of these legacy issues which require some investigation and fixing. If the commit is known then it can be reverted and no need to disable test but this seem to be an old issue but not a current check-in. To me it looks like this is a one off type of thing just to get CI up and running very first time. Once this is fixed and tests are enabled, there should not be any such test disabling in future. Alternatively, If this is too confusing , CI can be stopped now before making in to production and fixes can be done and then enable CI - we have waited long enough and we can wait some more to get these last couple of issues to be fixed before turning on CI. But running CI with arbitrary pass rate is not desirable. It defeats the purpose and hard to manage. Thanks /Sudha [1] https://cwiki.apache.org/confluence/display/CLOUDSTACK/Development+Process -Original Message- From: Trippie [mailto:trip...@gmail.com] On Behalf Of Hugo Trippaers Sent: Monday, July 21, 2014 3:32 AM To: dev@cloudstack.apache.org Subject: Re: Disabling failed test cases (was RE: Review Request 23605: CLOUDSTACK-7107: Disabling failed test cases) Hey Sudha, Sorry, but i disagree. The purpose of tests should not be to get a 100% pass rate. The tests should show an accurate state of the how the tests are doing versus the current state of the branch being tested. If tests fail we should fix why the tests fails and the system should not report an OK in the meantime. Doing so is too confusing, we need to be able to rely on the fact that if the tests report OK everything is actually OK. Cheers, Hugo On 21 jul. 2014, at 12:28, Sudha Ponnaganti sudha.ponnaga...@citrix.com wrote: In the beginning to get CI up and running, it would be ok to disable these handful of tests while getting fixes in, to achieve 100% pass rates. When CI runs in production, code changes need to be reverted if there are any new failures to keep CI pass rates at 100% (a known state to make CI effective). But should not just disable a test and move forward in long run. This should not be automated and make it as part of production CI process. Thanks /Sudha -Original Message- From: Santhosh Edukulla [mailto:santhosh.eduku...@citrix.com] Sent: Monday, July 21, 2014 3:22 AM To: Gaurav Aradhye; Stephen Turner; Hugo Trippaers; dev@cloudstack.apache.org Cc: Girish Shilamkar Subject: RE: Disabling failed test cases (was RE: Review Request 23605: CLOUDSTACK-7107: Disabling failed test cases) All, Alex, wanted to disable test cases in between CI( continuous integration) runs for the below reason for failures. I only, provided a way to achieve the same using tags, so that it will work for dual purpose, one not to effect community and can be used in CI as well, it will not effect if some body wanted to run all test cases immaterial of tags. Reason: In CI,automation auto kick starts every 3 hours( configurable) and picks up those delta changes and runs few checks, including sanity. Now, the idea was to keep baseline of testcases running as always pass. Now between two CI runs say T1 and T2, if there are new failures introduced, it will be automatically detected with new git changes and bugs are logged automatically against those check-ins. Now, till those bugs gets fixed, those were disabled keeping the baseline as always pass again. The window to fix those failures( either product or test case), through triage was almost constant and it need to be done soon, test cases are then enabled back once fixed, available in next available CI run again. It was to decide the failures between T1 and T2, as baseline is always clean and pass, otherwise CI runs may accumulate failures, and confuse over runs that which commits introduced failures. But, its not hard and fixed rule, we can discuss a better way as well, this was followed in 4.4 release in phase1 for CI, in another phase 2( WIP ), if we agree to some other better solution, then definitely it should be adopted. Santhosh From: Gaurav Aradhye [gaurav.arad...@clogeny.com] Sent: Monday, July 21, 2014 5:40 AM To: Stephen Turner; Hugo Trippaers; dev@cloudstack.apache.org; Santhosh Edukulla Cc: Girish Shilamkar Subject: Re: Disabling failed
Re: Review Request 23603: Fixed CLOUDSTACK-6983: unable to register lxc template
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/23603/#review48211 --- Commit 58bad41910970fb3b08aa4d21875af6d04c8bf2e in cloudstack's branch refs/heads/master from Rajani Karuturi [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=58bad41 ] Fixed CLOUDSTACK-6983: unable to register lxc template added a check for tar.gz format in checktemplate - ASF Subversion and Git Services On July 21, 2014, 9:53 a.m., Rajani Karuturi wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/23603/ --- (Updated July 21, 2014, 9:53 a.m.) Review request for cloudstack, Kishan Kavala and Marcus Sorensen. Bugs: CLOUDSTACK-6983 https://issues.apache.org/jira/browse/CLOUDSTACK-6983 Repository: cloudstack-git Description --- added a check for tar.gz format in checktemplate Diffs - utils/src/org/apache/cloudstack/utils/template/TemplateUtils.java bad94de Diff: https://reviews.apache.org/r/23603/diff/ Testing --- manually tested register template on lxc Thanks, Rajani Karuturi
Re: Review Request 23603: Fixed CLOUDSTACK-6983: unable to register lxc template
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/23603/#review48212 --- Ship it! Ship It! - Kishan Kavala On July 21, 2014, 3:23 p.m., Rajani Karuturi wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/23603/ --- (Updated July 21, 2014, 3:23 p.m.) Review request for cloudstack, Kishan Kavala and Marcus Sorensen. Bugs: CLOUDSTACK-6983 https://issues.apache.org/jira/browse/CLOUDSTACK-6983 Repository: cloudstack-git Description --- added a check for tar.gz format in checktemplate Diffs - utils/src/org/apache/cloudstack/utils/template/TemplateUtils.java bad94de Diff: https://reviews.apache.org/r/23603/diff/ Testing --- manually tested register template on lxc Thanks, Rajani Karuturi
RE: Disabling failed test cases (was RE: Review Request 23605: CLOUDSTACK-7107: Disabling failed test cases)
Is there not a way we could have the best of both worlds? Tag them, but leave them running, and reject a check-in if it triggers a failure in an untagged test only? -- Stephen Turner -Original Message- From: Sudha Ponnaganti [mailto:sudha.ponnaga...@citrix.com] Sent: 21 July 2014 12:43 To: dev@cloudstack.apache.org Subject: RE: Disabling failed test cases (was RE: Review Request 23605: CLOUDSTACK-7107: Disabling failed test cases) Hugo, I absolutely agree with you that tests should not be disabled and fixes should be made before check in. As per what Alex has mentioned in his CI enablement mail [1], premise of CI is that it runs at 100% pass rates and if any check in causes failure in CI Run, the bad check-in is easily identified that check-in gets reverted, so rest of the check-ins would move forward so this failure would not block rest of the community and health of branch is maintained. To enable CI in to production, it is absolutely necessary to get 100% pass rate before turning on CI otherwise all master check-ins will halt because of these legacy issues which require some investigation and fixing. If the commit is known then it can be reverted and no need to disable test but this seem to be an old issue but not a current check-in. To me it looks like this is a one off type of thing just to get CI up and running very first time. Once this is fixed and tests are enabled, there should not be any such test disabling in future. Alternatively, If this is too confusing , CI can be stopped now before making in to production and fixes can be done and then enable CI - we have waited long enough and we can wait some more to get these last couple of issues to be fixed before turning on CI. But running CI with arbitrary pass rate is not desirable. It defeats the purpose and hard to manage. Thanks /Sudha [1] https://cwiki.apache.org/confluence/display/CLOUDSTACK/Development+Process -Original Message- From: Trippie [mailto:trip...@gmail.com] On Behalf Of Hugo Trippaers Sent: Monday, July 21, 2014 3:32 AM To: dev@cloudstack.apache.org Subject: Re: Disabling failed test cases (was RE: Review Request 23605: CLOUDSTACK-7107: Disabling failed test cases) Hey Sudha, Sorry, but i disagree. The purpose of tests should not be to get a 100% pass rate. The tests should show an accurate state of the how the tests are doing versus the current state of the branch being tested. If tests fail we should fix why the tests fails and the system should not report an OK in the meantime. Doing so is too confusing, we need to be able to rely on the fact that if the tests report OK everything is actually OK. Cheers, Hugo On 21 jul. 2014, at 12:28, Sudha Ponnaganti sudha.ponnaga...@citrix.com wrote: In the beginning to get CI up and running, it would be ok to disable these handful of tests while getting fixes in, to achieve 100% pass rates. When CI runs in production, code changes need to be reverted if there are any new failures to keep CI pass rates at 100% (a known state to make CI effective). But should not just disable a test and move forward in long run. This should not be automated and make it as part of production CI process. Thanks /Sudha -Original Message- From: Santhosh Edukulla [mailto:santhosh.eduku...@citrix.com] Sent: Monday, July 21, 2014 3:22 AM To: Gaurav Aradhye; Stephen Turner; Hugo Trippaers; dev@cloudstack.apache.org Cc: Girish Shilamkar Subject: RE: Disabling failed test cases (was RE: Review Request 23605: CLOUDSTACK-7107: Disabling failed test cases) All, Alex, wanted to disable test cases in between CI( continuous integration) runs for the below reason for failures. I only, provided a way to achieve the same using tags, so that it will work for dual purpose, one not to effect community and can be used in CI as well, it will not effect if some body wanted to run all test cases immaterial of tags. Reason: In CI,automation auto kick starts every 3 hours( configurable) and picks up those delta changes and runs few checks, including sanity. Now, the idea was to keep baseline of testcases running as always pass. Now between two CI runs say T1 and T2, if there are new failures introduced, it will be automatically detected with new git changes and bugs are logged automatically against those check-ins. Now, till those bugs gets fixed, those were disabled keeping the baseline as always pass again. The window to fix those failures( either product or test case), through triage was almost constant and it need to be done soon, test cases are then enabled back once fixed, available in next available CI run again. It was to decide the failures between T1 and T2, as baseline is always clean and pass, otherwise CI runs may accumulate failures, and confuse over runs that which commits introduced failures. But, its not hard and fixed rule, we can discuss a better way as
Re: Disabling failed test cases (was RE: Review Request 23605: CLOUDSTACK-7107: Disabling failed test cases)
Hey Sudha, OK, clear. I agree the CI system should be running as soon as possible. However the automated revert bit, i don’t agree with and will give a -1 on that. Cheers, Hugo On 21 jul. 2014, at 13:42, Sudha Ponnaganti sudha.ponnaga...@citrix.com wrote: Hugo, I absolutely agree with you that tests should not be disabled and fixes should be made before check in. As per what Alex has mentioned in his CI enablement mail [1], premise of CI is that it runs at 100% pass rates and if any check in causes failure in CI Run, the bad check-in is easily identified that check-in gets reverted, so rest of the check-ins would move forward so this failure would not block rest of the community and health of branch is maintained. To enable CI in to production, it is absolutely necessary to get 100% pass rate before turning on CI otherwise all master check-ins will halt because of these legacy issues which require some investigation and fixing. If the commit is known then it can be reverted and no need to disable test but this seem to be an old issue but not a current check-in. To me it looks like this is a one off type of thing just to get CI up and running very first time. Once this is fixed and tests are enabled, there should not be any such test disabling in future. Alternatively, If this is too confusing , CI can be stopped now before making in to production and fixes can be done and then enable CI - we have waited long enough and we can wait some more to get these last couple of issues to be fixed before turning on CI. But running CI with arbitrary pass rate is not desirable. It defeats the purpose and hard to manage. Thanks /Sudha [1] https://cwiki.apache.org/confluence/display/CLOUDSTACK/Development+Process -Original Message- From: Trippie [mailto:trip...@gmail.com] On Behalf Of Hugo Trippaers Sent: Monday, July 21, 2014 3:32 AM To: dev@cloudstack.apache.org Subject: Re: Disabling failed test cases (was RE: Review Request 23605: CLOUDSTACK-7107: Disabling failed test cases) Hey Sudha, Sorry, but i disagree. The purpose of tests should not be to get a 100% pass rate. The tests should show an accurate state of the how the tests are doing versus the current state of the branch being tested. If tests fail we should fix why the tests fails and the system should not report an OK in the meantime. Doing so is too confusing, we need to be able to rely on the fact that if the tests report OK everything is actually OK. Cheers, Hugo On 21 jul. 2014, at 12:28, Sudha Ponnaganti sudha.ponnaga...@citrix.com wrote: In the beginning to get CI up and running, it would be ok to disable these handful of tests while getting fixes in, to achieve 100% pass rates. When CI runs in production, code changes need to be reverted if there are any new failures to keep CI pass rates at 100% (a known state to make CI effective). But should not just disable a test and move forward in long run. This should not be automated and make it as part of production CI process. Thanks /Sudha -Original Message- From: Santhosh Edukulla [mailto:santhosh.eduku...@citrix.com] Sent: Monday, July 21, 2014 3:22 AM To: Gaurav Aradhye; Stephen Turner; Hugo Trippaers; dev@cloudstack.apache.org Cc: Girish Shilamkar Subject: RE: Disabling failed test cases (was RE: Review Request 23605: CLOUDSTACK-7107: Disabling failed test cases) All, Alex, wanted to disable test cases in between CI( continuous integration) runs for the below reason for failures. I only, provided a way to achieve the same using tags, so that it will work for dual purpose, one not to effect community and can be used in CI as well, it will not effect if some body wanted to run all test cases immaterial of tags. Reason: In CI,automation auto kick starts every 3 hours( configurable) and picks up those delta changes and runs few checks, including sanity. Now, the idea was to keep baseline of testcases running as always pass. Now between two CI runs say T1 and T2, if there are new failures introduced, it will be automatically detected with new git changes and bugs are logged automatically against those check-ins. Now, till those bugs gets fixed, those were disabled keeping the baseline as always pass again. The window to fix those failures( either product or test case), through triage was almost constant and it need to be done soon, test cases are then enabled back once fixed, available in next available CI run again. It was to decide the failures between T1 and T2, as baseline is always clean and pass, otherwise CI runs may accumulate failures, and confuse over runs that which commits introduced failures. But, its not hard and fixed rule, we can discuss a better way as well, this was followed in 4.4 release in phase1 for CI, in another phase 2( WIP ), if we agree to some other better
Review Request 23735: Fix deployment of data center with marvin
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/23735/ --- Review request for cloudstack, daan Hoogland, John Dilley, Santhosh Edukulla, and Hugo Trippaers. Repository: cloudstack-git Description --- The DevCloud wiki page [1] instructs developers to deploy a DC with basic networking with the following command: $ python tools/marvin/marvin/deployDataCenter.py -i tools/devcloud/devcloud-advanced.cfg However, that produces the error message bellow: Exception Occurred Under createLogs :['Traceback (most recent call last):\n', ' File /Users/mferreira/development/git/cloudstack-sbp/tools/marvin/marvin/marvinLog.py, line 157, in createLogs\n(\'LogFolderPath\' in log_cfg.__dict__.keys()) and\n', AttributeError: 'list' object has no attribute '__dict__'\n] ===Log Creation Failed. Please Check=== The cause of the error is the unexpected format of the logger element in tools/devcloud/devcloud-advanced.cfg The patch I'm submitting add support for lists in the logger element of the configuration. In addition the patch also provides small fixes for the deployment configuration of basic and advanced zones. [1] - https://cwiki.apache.org/confluence/display/CLOUDSTACK/DevCloud Diffs - tools/devcloud/devcloud-advanced.cfg 74b6366 tools/devcloud/devcloud.cfg 5232e3a tools/marvin/marvin/deployDataCenter.py ae48839 tools/marvin/marvin/marvinLog.py ea8eaee Diff: https://reviews.apache.org/r/23735/diff/ Testing --- With the patch I was able to deploy a zone in cloudstack. Thanks, Miguel Ferreira
Review Request 23737: Improve usability of deployDataCenter.py and advanced zone config
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/23737/ --- Review request for cloudstack, daan Hoogland, Hugo Trippaers, and Wei Zhou. Repository: cloudstack-git Description --- Added step-wise log messages during deploy data center. Also reordered some parameters in the advanced zone config for better readability. Diffs - tools/devcloud/devcloud-advanced.cfg 74b6366 tools/marvin/marvin/deployDataCenter.py ae48839 Diff: https://reviews.apache.org/r/23737/diff/ Testing --- Used deployDataCenter.py together with advanced zone config to deploy a zone in my development environment Thanks, Miguel Ferreira
Re: Review Request 23735: Fix deployment of data center with marvin
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/23735/#review48216 --- tools/devcloud/devcloud-advanced.cfg https://reviews.apache.org/r/23735/#comment84571 Is this change required, compared to earlier devcloud cfg, it was a working cfg for devcloud. tools/marvin/marvin/deployDataCenter.py https://reviews.apache.org/r/23735/#comment84569 Instead of this, can we make logger node under devcloud.cfg as similar to setup/dev/advanced.cfg. We never see a case of for loop to create multiple loggers and logs? tools/marvin/marvin/marvinLog.py https://reviews.apache.org/r/23735/#comment84570 Make it more abstract and see if is not aware of cfg(log_cfg), i mean pass the logfile path, as similar to create log from directory, where we pass log folder dir. tools/marvin/marvin/marvinLog.py https://reviews.apache.org/r/23735/#comment84572 As well, not related to this line though, can we please test using the simulator and advanced.cfg to launch management server and deploy a datacenter. - Santhosh Edukulla On July 21, 2014, 1:35 p.m., Miguel Ferreira wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/23735/ --- (Updated July 21, 2014, 1:35 p.m.) Review request for cloudstack, daan Hoogland, John Dilley, Santhosh Edukulla, and Hugo Trippaers. Repository: cloudstack-git Description --- The DevCloud wiki page [1] instructs developers to deploy a DC with basic networking with the following command: $ python tools/marvin/marvin/deployDataCenter.py -i tools/devcloud/devcloud-advanced.cfg However, that produces the error message bellow: Exception Occurred Under createLogs :['Traceback (most recent call last):\n', ' File /Users/mferreira/development/git/cloudstack-sbp/tools/marvin/marvin/marvinLog.py, line 157, in createLogs\n(\'LogFolderPath\' in log_cfg.__dict__.keys()) and\n', AttributeError: 'list' object has no attribute '__dict__'\n] ===Log Creation Failed. Please Check=== The cause of the error is the unexpected format of the logger element in tools/devcloud/devcloud-advanced.cfg The patch I'm submitting add support for lists in the logger element of the configuration. In addition the patch also provides small fixes for the deployment configuration of basic and advanced zones. [1] - https://cwiki.apache.org/confluence/display/CLOUDSTACK/DevCloud Diffs - tools/devcloud/devcloud-advanced.cfg 74b6366 tools/devcloud/devcloud.cfg 5232e3a tools/marvin/marvin/deployDataCenter.py ae48839 tools/marvin/marvin/marvinLog.py ea8eaee Diff: https://reviews.apache.org/r/23735/diff/ Testing --- With the patch I was able to deploy a zone in cloudstack. Thanks, Miguel Ferreira
Re: Review Request 23735: Fix deployment of data center with marvin
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/23735/#review48217 --- tools/devcloud/devcloud-advanced.cfg https://reviews.apache.org/r/23735/#comment84573 For devcloud deployments the mgtSvrIp should be .10 as the management server is running on the devcloud itself. - Hugo Trippaers On July 21, 2014, 1:35 p.m., Miguel Ferreira wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/23735/ --- (Updated July 21, 2014, 1:35 p.m.) Review request for cloudstack, daan Hoogland, John Dilley, Santhosh Edukulla, and Hugo Trippaers. Repository: cloudstack-git Description --- The DevCloud wiki page [1] instructs developers to deploy a DC with basic networking with the following command: $ python tools/marvin/marvin/deployDataCenter.py -i tools/devcloud/devcloud-advanced.cfg However, that produces the error message bellow: Exception Occurred Under createLogs :['Traceback (most recent call last):\n', ' File /Users/mferreira/development/git/cloudstack-sbp/tools/marvin/marvin/marvinLog.py, line 157, in createLogs\n(\'LogFolderPath\' in log_cfg.__dict__.keys()) and\n', AttributeError: 'list' object has no attribute '__dict__'\n] ===Log Creation Failed. Please Check=== The cause of the error is the unexpected format of the logger element in tools/devcloud/devcloud-advanced.cfg The patch I'm submitting add support for lists in the logger element of the configuration. In addition the patch also provides small fixes for the deployment configuration of basic and advanced zones. [1] - https://cwiki.apache.org/confluence/display/CLOUDSTACK/DevCloud Diffs - tools/devcloud/devcloud-advanced.cfg 74b6366 tools/devcloud/devcloud.cfg 5232e3a tools/marvin/marvin/deployDataCenter.py ae48839 tools/marvin/marvin/marvinLog.py ea8eaee Diff: https://reviews.apache.org/r/23735/diff/ Testing --- With the patch I was able to deploy a zone in cloudstack. Thanks, Miguel Ferreira
Re: Review Request 22863: CLOUDSTACK-6823 : First code drop for Brocade Network plugin to orchestrate Brocade VDX switches for L2 connectivity.
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/22863/#review48220 --- Can you rebase on latest master as the patch currently fails to apply. Cheers, Hugo patching file api/src/com/cloud/network/Network.java Hunk #1 FAILED at 132. Hunk #2 succeeded at 224 (offset 3 lines). 1 out of 2 hunks FAILED -- saving rejects to file api/src/com/cloud/network/Network.java.rej patching file api/src/com/cloud/network/Networks.java patching file api/src/com/cloud/network/PhysicalNetwork.java Hunk #1 FAILED at 33. 1 out of 1 hunk FAILED -- saving rejects to file api/src/com/cloud/network/PhysicalNetwork.java.rej patching file api/src/org/apache/cloudstack/network/ExternalNetworkDeviceManager.java patching file client/WEB-INF/classes/resources/messages.properties Hunk #1 FAILED at 327. Hunk #2 FAILED at 500. Hunk #3 succeeded at 880 (offset 6 lines). Hunk #4 succeeded at 1426 (offset 7 lines). Hunk #5 succeeded at 1639 with fuzz 2 (offset 7 lines). 2 out of 5 hunks FAILED -- saving rejects to file client/WEB-INF/classes/resources/messages.properties.rej patching file client/WEB-INF/classes/resources/messages_zh_CN.properties Hunk #1 FAILED at 297. Hunk #2 FAILED at 509. Hunk #3 succeeded at 1612 with fuzz 2 (offset 4 lines). 2 out of 3 hunks FAILED -- saving rejects to file client/WEB-INF/classes/resources/messages_zh_CN.properties.rej patching file client/pom.xml patching file client/tomcatconf/commands.properties.in Hunk #1 succeeded at 607 (offset 1 line). patching file plugins/pom.xml Hunk #1 succeeded at 64 (offset 1 line). patching file setup/db/db/schema-440to450.sql Hunk #1 succeeded at 244 with fuzz 2 (offset 20 lines). patching file test/integration/component/test_brocade_vcs.py patching file tools/apidoc/gen_toc.py Hunk #1 succeeded at 132 with fuzz 2. patching file ui/dictionary.jsp Hunk #1 FAILED at 349. Hunk #2 FAILED at 505. Hunk #3 succeeded at 870 (offset 7 lines). Hunk #4 succeeded at 1436 with fuzz 2 (offset 8 lines). Hunk #5 succeeded at 1742 (offset 9 lines). 2 out of 5 hunks FAILED -- saving rejects to file ui/dictionary.jsp.rej patching file ui/scripts/system.js Hunk #2 succeeded at 12240 (offset 243 lines). Hunk #3 succeeded at 19564 (offset 584 lines). Hunk #4 succeeded at 20343 (offset 615 lines). Hunk #5 succeeded at 20379 (offset 618 lines). patching file ui/scripts/ui-custom/zoneWizard.js Hunk #1 FAILED at 726. 1 out of 1 hunk FAILED -- saving rejects to file ui/scripts/ui-custom/zoneWizard.js.rej - Hugo Trippaers On July 17, 2014, 11:52 p.m., Ritu Sabharwal wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/22863/ --- (Updated July 17, 2014, 11:52 p.m.) Review request for cloudstack and Hugo Trippaers. Bugs: CLOUDSTACK-6823 https://issues.apache.org/jira/browse/CLOUDSTACK-6823 Repository: cloudstack-git Description --- First code drop for Brocade Network plugin to orchestrate Brocade VDX switches for L2 connectivity. Please create a new branch for Brocade plugin. Diffs - api/src/com/cloud/network/Network.java 885bffe api/src/com/cloud/network/Networks.java 1e4d229 api/src/com/cloud/network/PhysicalNetwork.java 8cc214e api/src/org/apache/cloudstack/network/ExternalNetworkDeviceManager.java e73f526 client/WEB-INF/classes/resources/messages.properties b504a18 client/WEB-INF/classes/resources/messages_zh_CN.properties 1ec4e95 client/pom.xml 29fef4f client/tomcatconf/commands.properties.in d247aa0 plugins/pom.xml b5e6a61 setup/db/db/schema-440to450.sql 77445a9 test/integration/component/test_brocade_vcs.py PRE-CREATION tools/apidoc/gen_toc.py 827d6bf ui/dictionary.jsp 9026a36 ui/scripts/system.js 9a98a5c ui/scripts/ui-custom/zoneWizard.js 4091c03 Diff: https://reviews.apache.org/r/22863/diff/ Testing --- • Create an isolated network; verify that the port-profile is created on the Brocade switch. • Attach a VM to the network; verify that the VMs MAC address is associated with the port profile of the network on the Brocade switch. • Delete VMs for an isolated network; verify that the VMs MAC address is disassociated with the port profile of the network on the Brocade switch. • Delete the isolated network; verify that the port-profile is deleted from the Brocade switch. Integration test result: Test Brocade Network and VM Creation ... === TestName: test_network_vcs | Status : SUCCESS === ok -- Ran 1 test in 297.497s OK File Attachments Diff for the existing cloudstack code
Re: Review Request 23737: Improve usability of deployDataCenter.py and advanced zone config
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/23737/#review48219 --- tools/devcloud/devcloud-advanced.cfg https://reviews.apache.org/r/23737/#comment84577 whats the significance of this change? tools/devcloud/devcloud-advanced.cfg https://reviews.apache.org/r/23737/#comment84575 Instead of these elements, please use advanced.cfg for reference and use logger element in similar, now marvin and test cases as such do not worry about testclient.log or testcase.log. Instead, logging was simplified to dump failed exception logs, run log and result log for each test suite, these elements can be removed, but log path can still be used. - Santhosh Edukulla On July 21, 2014, 1:42 p.m., Miguel Ferreira wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/23737/ --- (Updated July 21, 2014, 1:42 p.m.) Review request for cloudstack, daan Hoogland, Hugo Trippaers, and Wei Zhou. Repository: cloudstack-git Description --- Added step-wise log messages during deploy data center. Also reordered some parameters in the advanced zone config for better readability. Diffs - tools/devcloud/devcloud-advanced.cfg 74b6366 tools/marvin/marvin/deployDataCenter.py ae48839 Diff: https://reviews.apache.org/r/23737/diff/ Testing --- Used deployDataCenter.py together with advanced zone config to deploy a zone in my development environment Thanks, Miguel Ferreira
Re: rfc: newsystemvm
Hey Chiradeep,
Thanks for taking a look. I’ve now re-done this work, but carefully and cleanly
and on top of current master, in 37 small commits instead of 2 scary ones.
Please take a look at
https://github.com/schubergphilis/cloudstack/compare/systemvm-refactor
Summarizing this kind of thing is always hard...it’s many little things...the
interesting stuff is at the end/bottom, in particular the two main improvements
https://github.com/schubergphilis/cloudstack/commit/142d087f6a97f6ac70a858a35d2fe8b638c58cbb
When working on the systemvm in isolation, or using vagrant or similar
tools,
it can be useful to inject a custom SSH key before merging a management
server
systemvm.iso into it. This option allows that. It should _not_ have
effect
on management-server-managed vms which always get their SSH keys
injected.
https://github.com/schubergphilis/cloudstack/commit/e2240eaed18000d4d94dbf6a6e40612db1aeda34
The current build downloads its script from master by fetching a
cloudstack
tarball. Besides being an unneeded load on the apache git server, this
is a
problem when working on a branch and wanting to inject a different set
of
scripts. It also makes it pretty likely that the injected copy of the
script
will not match what a production release wants, so there is very little
chance of not needing to overwrite the scripts.
Ideally we would just rsync over some files. However, veewee does not
provide
an option to do that. In order to keep a 'cleanly veewee-only' build
possible,
and work with any recent veewee version, in this change we restor to
using
shar (http://en.wikipedia.org/wiki/Shar) to produce an archive which can
execute as a script, which we feed to veewee to execute.
In order to avoid having to re-do this cleanup twice, I also ended up merging
the systemvm and systemvm64 template definitions, factoring out their small
differences by inspecting the os architecture.
https://github.com/schubergphilis/cloudstack/commit/f570b3921cd52672f841fc5f99cdd96f9737d629
https://github.com/schubergphilis/cloudstack/commit/50e91217f90fc952182dccac02a5af06ac33fb45
Everything else…well it pretty much falls into two categories:
* general code cleanup without functional changes
* general code defensiveness to survive various jenkins build scenarios
All in all it should help with ongoing maintenance, I think.
Note I still have some work to do (testing, merging this version back into our
redundant vpc branch, moar testing, ...) before submitting a merge-able
patchset. But since it’s such a big change and since the testing is a bit slow
(what with creating and destroying VMs) any early comments would be quite
useful so I don’t have to re-re-do lots of testing.
Thanks!
Leo
On Jul 18, 2014, at 7:35 PM, Chiradeep Vittal chiradeep.vit...@citrix.com
wrote:
Thanks Leo. Can you summarize the changes (it is a lot of changes)
From: Leo Simons lsim...@schubergphilis.com
Reply-To: dev@cloudstack.apache.org dev@cloudstack.apache.org
Date: Friday, July 18, 2014 at 7:42 AM
To: int-toolkit int-tool...@schubergphilis.com, dev@cloudstack.apache.org
dev@cloudstack.apache.org
Subject: rfc: newsystemvm
Hey folks,
https://github.com/schubergphilis/cloudstack/commit/f125f1564e8921def00dc0235ecca51470a2a22e
https://github.com/schubergphilis/cloudstack/tree/f125f1564e8921def00dc0235ecca51470a2a22e/tools/appliance
This started out as wanting the systemvm build to take
systemvm/patches/debian/{debian,vpn} from the local machine/branch, rather
than downloading from the apache git master [1]. In working out how on earth
to get veewee to do that cleanly (hint: you can’t, hence resorting to shar
usage) I got quite frustrated with the image rebuild times.
It so happens that veewee has a --skip-to-postinstall instruction which is
_quite_ useful while debugging these scripts. To get that working requires
the post install steps to be retryable/convergent. Of course, our existing
scripts weren’t set up for that. So I had to add a bunch of tests whether
changes had applied already. Which implied a pretty significant refactor.
I think I was careful enough and I expect this new template will work just as
well as the old one. This is a change that we can (and probably should?)
merge to master independently of the redundant VPC work (though the `apt-get
install chef` would need to be taken out). But, given how big of a chunk of
code has changed here, before upstreaming (a version of) this to apache we
(I) need to do more testing. So for now I’ve put this change next to the
existing definitions rather than replace ‘em, to not block anything else.
Comments/thoughts?
cheers,
Leo
[1]
https://github.com/schubergphilis/cloudstack/blob/master/tools/appliance/definitions/systemvmtemplate/postinstall.sh#L228
Begin forwarded
Re: Review Request 23609: Signature changes to delete method in VirtualMachine class in base.py
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/23609/#review48224 --- Ship it! Ship It! - Santhosh Edukulla On July 17, 2014, 9:22 a.m., sanjeev n wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/23609/ --- (Updated July 17, 2014, 9:22 a.m.) Review request for cloudstack, Santhosh Edukulla and SrikanteswaraRao Talluri. Repository: cloudstack-git Description --- destroyVirtualMachine API takes only one parameter (id-virtualmachine id) till CS 4.2. In 4.3 we have added expunge parameter to expunge the vm at the destroy time instead of waiting for expunge interval. Made changes to delete method to accept additional parameters. Diffs - tools/marvin/marvin/lib/base.py e9d5bb4 Diff: https://reviews.apache.org/r/23609/diff/ Testing --- yes Thanks, sanjeev n
Re: Replace primary secondary storage
That article only applied to ACS 4.1 and older versions. In ACS 4.2 storage refactor, db tables are changed. template_host_ref has been deprecated and replaced with template_store_ref. Thanks -min On 7/21/14 3:47 AM, Tejas Gadaria refond.g...@gmail.com wrote: Hi, I found this article http://support.citrix.com/article/CTX135229 I was just going through this but could not get some of the points. Currently I have no snapshots and all templates are public another secondary storage is not added yet. 1) In above article 2nd point says Copy the snapshots and templates from Secondary Storage host S2 to S1. 6th point in article says You must copy only private templates on Secondary storage host S2 to S1. Here I got confused a little. 2) currently both tables are showing empty as shown below. Am I doing anything wrong or it is normal? mysql select sechost_id from snapshots; Empty set (0.00 sec) mysql select host_id from template_host_ref; Empty set (0.00 sec) Regards, Tejas On Mon, Jul 21, 2014 at 1:02 PM, Tejas Gadaria refond.g...@gmail.com wrote: Hi, I have production vms running on ACS 4.3 with xen 6.2 SP1. I have requirement to change primary Secondary storage. I am planning live storage migration for all running vms, after adding new storage as primary storage storage in same cluster. ( correct me if i am missing anything)..but how can i replace secondary storage? Regards, Tejas
Re: Review Request 23617: Add Nic UUID to the context so that we can read the same in event bus after create a nic
On July 17, 2014, 4:55 p.m., Nitin Mehta wrote: server/src/com/cloud/vm/UserVmManagerImpl.java, line 960 https://reviews.apache.org/r/23617/diff/1/?file=634289#file634289line960 Why is it made create=true when it is not a BaseAyncCreate cmd ? create=true should be added only when its invoked through the create() method of a BaseAyncCreate cmd Damodar Reddy Talakanti wrote: We can not extend AddNicToVMCmd by BaseAsyncCreate cmd as it is doing many checks before creating the entry NIC. As it is creating entity did made create=true there. Nitin Mehta wrote: Many checks is not a problem as long as they are DB checks. Do note we make a command async generally because it is contacting the resource and can take time. If it is just DB checks I would think we can make the command BaseAsyncCreate. Also best that you review with Kishan if create=true will generate all the events (scheduled, started, completed) an async command generates Damodar Reddy Talakanti wrote: I already verified, it is generating all the above events (scheduled,started and created in the DB). It is not only issue of DB checks it is creating the entity some where deep in the flow. To bring that up we need to pull all that business logic into API create method which I though not a good idea. So just made it create=true. I understand but I guess we should do that. Giving a half baked solution will be a problem in the future. Dont you agree ? - Nitin --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/23617/#review48016 --- On July 17, 2014, 4:43 p.m., Damodar Reddy Talakanti wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/23617/ --- (Updated July 17, 2014, 4:43 p.m.) Review request for cloudstack and Nitin Mehta. Repository: cloudstack-git Description --- Putting the create event into event bus for addNicToVirutalMachine command explicitly as we can not use BaseAsyncCreateCommand.We can not extend this with BaseAsyncCreateCmd due to the checks we do before creating the nic. Diffs - api/src/com/cloud/event/EventTypes.java 71bfdb6 server/src/com/cloud/vm/UserVmManagerImpl.java d0bc186 Diff: https://reviews.apache.org/r/23617/diff/ Testing --- Tested against the following setup: 1. XenServer 6.2 2. Master Branch Thanks, Damodar Reddy Talakanti
Re: [DISCUSS] [PROPOSAL] SAML2 plugin for SSO/SLO in CloudStack
+1. Very well-written FS and email, Rohit. Those open questions are very valid, I added a little comment in your FS regarding the flow. Thanks -min On 7/20/14 8:35 AM, Rohit Yadav rohit.ya...@shapeblue.com wrote: Hi, I'm assuming no one objects the proposal and the spec, I'll move forward with the first implementation starting next week but will be mostly offline till 28th July. Regards. Rohit Yadav wrote: Hi guys, There has been a lot of interest [4] around auth related problems in CloudStach such as -- SSO/SLO (single sign on / log out), 2-factor authentication, role based network/IP/CIDR checking etc. A lot of challenge in implementing them in CloudStack is because of two divergent authentication mechanisms (one that is username/password/cookie based, other which is api/secret keys or hmac/signature based). This thread tries to kickstart a project in that direction which will in short term try to implement a SAML2 plugin and in long term have a much better authentication framework. Let me start by briefly explaining what SAML2 [1] is -- it's an XML based authentication and authorization protocol widely used to implement single sign on service. Having a SAML plugin in ACS will give users and organization a new mode of authentication who already have such an infrastructure in place. A SAML based SSO infrastructure consists of three entities - user-agent (UA), service provider (SP) and identity provider (IdP). The UA is the user/browser, the SP is the application that the UA is accessing (i.e. Apache CloudStack UI) and the IdP is the identity service and does authentication and authorization, management of users among other things. IdP could be backed by LDAP, AD etc. For the scope of this feature, we only need to implement SAML SP plugin in CloudStack and use any free SAML 2.0 compliant IdP server [5] for testing. For this I researched and explored ways of implementing that and have a first draft which needs to be discussed and iterated in the ACS dev community. After comparing many opensource SAML 2.0 implementations, their security and stability, we'll use OpenSAML [2] which is the most stable and widely used Java implementation. Since within CloudStack, we've been using Spring (for DI etc.) I explored and found Spring security SAML extension [3] which fits perfectly and it too uses OpenSAML. I also have a working proof-of-concept general implementation using the above based on which I've put together a design document draft on this feature for your review: https://cwiki.apache.org/confluence/display/CLOUDSTACK/SAML+2.0+Plugin There are some complex stories/cases around security and user management in CloudStack, some of which are listed under 'open ended questions' in the draft above most of which I'm not sure how to address. After first round of discussion, I'll go ahead with a basic implementation of this feature. The second phase will address broader use cases. Comments, questions, suggestions? References: [1] http://en.wikipedia.org/wiki/SAML_2.0 [2] https://wiki.shibboleth.net/confluence/display/OpenSAML/Home [3] http://projects.spring.io/spring-security-saml [4] John Burwell's talk on SSO in CloudStack: https://www.youtube.com/watch?v=kCR0TzrfCOM [5] https://idp.ssocircle.com/sso/UI/Login Regards, Rohit Yadav Software Architect, ShapeBlue M. +91 88 262 30892 | rohit.ya...@shapeblue.com Blog: bhaisaab.org | Twitter: @_bhaisaab Find out more about ShapeBlue and our range of CloudStack related services IaaS Cloud Design Buildhttp://shapeblue.com/iaas-cloud-design-and-build// CSForge rapid IaaS deployment frameworkhttp://shapeblue.com/csforge/ CloudStack Consultinghttp://shapeblue.com/cloudstack-consultancy/ CloudStack Infrastructure Supporthttp://shapeblue.com/cloudstack-infrastructure-support/ CloudStack Bootcamp Training Courseshttp://shapeblue.com/cloudstack-training/ This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Shape Blue Ltd or related companies. If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error. Shape Blue Ltd is a company incorporated in England Wales. ShapeBlue Services India LLP is a company incorporated in India and is operated under license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is a company registered by The Republic of South Africa and is traded under license from Shape Blue Ltd. ShapeBlue is a registered trademark. -- Rohit Yadav Software Architect, ShapeBlue M. +41 779015219 |
Re: [DISCUSS] [PROPOSAL] SAML2 plugin for SSO/SLO in CloudStack
Rohit, definite +1 Thanks, ilya On 7/20/14, 8:35 AM, Rohit Yadav wrote: Hi, I'm assuming no one objects the proposal and the spec, I'll move forward with the first implementation starting next week but will be mostly offline till 28th July. Regards. Rohit Yadav wrote: Hi guys, There has been a lot of interest [4] around auth related problems in CloudStach such as -- SSO/SLO (single sign on / log out), 2-factor authentication, role based network/IP/CIDR checking etc. A lot of challenge in implementing them in CloudStack is because of two divergent authentication mechanisms (one that is username/password/cookie based, other which is api/secret keys or hmac/signature based). This thread tries to kickstart a project in that direction which will in short term try to implement a SAML2 plugin and in long term have a much better authentication framework. Let me start by briefly explaining what SAML2 [1] is -- it's an XML based authentication and authorization protocol widely used to implement single sign on service. Having a SAML plugin in ACS will give users and organization a new mode of authentication who already have such an infrastructure in place. A SAML based SSO infrastructure consists of three entities - user-agent (UA), service provider (SP) and identity provider (IdP). The UA is the user/browser, the SP is the application that the UA is accessing (i.e. Apache CloudStack UI) and the IdP is the identity service and does authentication and authorization, management of users among other things. IdP could be backed by LDAP, AD etc. For the scope of this feature, we only need to implement SAML SP plugin in CloudStack and use any free SAML 2.0 compliant IdP server [5] for testing. For this I researched and explored ways of implementing that and have a first draft which needs to be discussed and iterated in the ACS dev community. After comparing many opensource SAML 2.0 implementations, their security and stability, we'll use OpenSAML [2] which is the most stable and widely used Java implementation. Since within CloudStack, we've been using Spring (for DI etc.) I explored and found Spring security SAML extension [3] which fits perfectly and it too uses OpenSAML. I also have a working proof-of-concept general implementation using the above based on which I've put together a design document draft on this feature for your review: https://cwiki.apache.org/confluence/display/CLOUDSTACK/SAML+2.0+Plugin There are some complex stories/cases around security and user management in CloudStack, some of which are listed under 'open ended questions' in the draft above most of which I'm not sure how to address. After first round of discussion, I'll go ahead with a basic implementation of this feature. The second phase will address broader use cases. Comments, questions, suggestions? References: [1] http://en.wikipedia.org/wiki/SAML_2.0 [2] https://wiki.shibboleth.net/confluence/display/OpenSAML/Home [3] http://projects.spring.io/spring-security-saml [4] John Burwell's talk on SSO in CloudStack: https://www.youtube.com/watch?v=kCR0TzrfCOM [5] https://idp.ssocircle.com/sso/UI/Login Regards, Rohit Yadav Software Architect, ShapeBlue M. +91 88 262 30892 | rohit.ya...@shapeblue.com Blog: bhaisaab.org | Twitter: @_bhaisaab Find out more about ShapeBlue and our range of CloudStack related services IaaS Cloud Design Buildhttp://shapeblue.com/iaas-cloud-design-and-build// CSForge – rapid IaaS deployment frameworkhttp://shapeblue.com/csforge/ CloudStack Consultinghttp://shapeblue.com/cloudstack-consultancy/ CloudStack Infrastructure Supporthttp://shapeblue.com/cloudstack-infrastructure-support/ CloudStack Bootcamp Training Courseshttp://shapeblue.com/cloudstack-training/ This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Shape Blue Ltd or related companies. If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error. Shape Blue Ltd is a company incorporated in England Wales. ShapeBlue Services India LLP is a company incorporated in India and is operated under license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is a company registered by The Republic of South Africa and is traded under license from Shape Blue Ltd. ShapeBlue is a registered trademark. -- Rohit Yadav Software Architect, ShapeBlue M. +41 779015219 | rohit.ya...@shapeblue.com Blog: bhaisaab.org | Twitter: @_bhaisaab Find out more about ShapeBlue and our range of CloudStack related services IaaS Cloud Design Buildhttp://shapeblue.com/iaas-cloud-design-and-build// CSForge
[QUESTION] Baremetal DHCP Server - Abstracting Router VM
We are trying to abstract router vm completely from our environment as it has dual nics which is big no no in hardened security environments. This is for shared (non-vpc) advanced security zone. CloudStack already has a support for Baremetal DHCP Server under Network Service Providers. Would anyone provide the context on how one go about using it? I assume we would need to write a support of some sort on our end. Examples and documentation would be appreciated. Thank you ilya
RE: Tomcat version issue while building cloudstack on RHEL7 RPMS
Hi Hugo, Do you have any ETA for this ? Regards, Rayees -Original Message- From: Rayees Namathponnan Sent: Tuesday, July 15, 2014 9:27 AM To: dev@cloudstack.apache.org Subject: RE: Tomcat version issue while building cloudstack on RHEL7 RPMS Thanks Hugo, defect https://issues.apache.org/jira/browse/CLOUDSTACK-7106 created to track this -Original Message- From: Trippie [mailto:trip...@gmail.com] On Behalf Of Hugo Trippaers Sent: Sunday, July 13, 2014 11:52 PM To: dev@cloudstack.apache.org Subject: Re: Tomcat version issue while building cloudstack on RHEL7 RPMS Hey Rayees, We should make a second set of scripts for the new redhat and cents releases. It's not only tomcat that has changes, for example we also need systemd scripts for cloudstack. I've been working on it, but it's not finished. Cheers. Hugo On 13 jul. 2014, at 19:19, Rayees Namathponnan rayees.namathpon...@citrix.com wrote: Hi All, I am trying to build 4.5/master RPM package in RHEL 7 box, in cloud.spec file there are dependency with tomcat6 which is not available in RHEL 7 repo. RHEL 7 repo comes with tomcat7, and I cannot create RPM package due tomcat6 missing package. Any suggestion on this ? we should modify cloud.spec to remove hard dependency on tomcat6 ? Regards, Rayees
Re: Review Request 23282: CLOUDSTACK-6845 : First Code drop for NuageVsp Network plugin
Hi Hugo, Thanks for reviewing NuageVsp plugin on time and making it part for CloudStack's virtual networking solution. Thanks, Suresh On Mon, Jul 21, 2014 at 1:56 AM, Hugo Trippaers h...@trippaers.nl wrote: Heya all, I’ve pushed support for the NuageVSP feature just now. Technically two days after the intended feature freeze for 4.6, but i think i can get away with it for the following reasons: * The feature was submitted on the review board before the feature freeze * The feature includes extensive unit tests and an integration test * Minor changes to core (just the minimum to enable the plugin), most real functionality is in a plugin * Review was approved by me before the feature freeze, just didn’t have time to run final checks and push it over the weekend. Does anyone have any objections to this? Cheers, Hugo On 21 jul. 2014, at 10:50, Hugo Trippaers htrippa...@schubergphilis.com wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/23282/#review48208 --- Ship it! commit 03de9cc33507400e0e06ccd84a36334a4660ef4e Author: Suresh Ramamurthy suresh.ramamur...@nuagenetworks.net Date: Mon Jul 21 09:40:45 2014 +0200 CLOUDSTACK-6845 : NuageVsp Network plugin Signed-off-by: Hugo Trippaers htrippa...@schubergphilis.com - Hugo Trippaers On July 19, 2014, 12:49 a.m., Suresh Ramamurthy wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/23282/ --- (Updated July 19, 2014, 12:49 a.m.) Review request for cloudstack, Alena Prokharchyk, Hugo Trippaers, and Sheng Yang. Bugs: CLOUDSTACK-6845 https://issues.apache.org/jira/browse/CLOUDSTACK-6845 Repository: cloudstack-git Description --- This is first code drop for NuageVsp Network plugin support that will bring the Nuage VSP network virtualization technology to CloudStack. We need a new branch to checkin the fixes once the review is done. Please create a new branch for NuageVsp plugin. Diffs - api/src/com/cloud/event/EventTypes.java 71bfdb6 api/src/com/cloud/network/Network.java 885bffe api/src/com/cloud/network/Networks.java 1e4d229 api/src/com/cloud/network/PhysicalNetwork.java 8cc214e client/WEB-INF/classes/resources/messages.properties b192cb0 client/WEB-INF/classes/resources/messages_zh_CN.properties 1ec4e95 client/pom.xml 46933d9 client/tomcatconf/commands.properties.in b9ac27b plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/OvsVifDriver.java 8e4c710 plugins/hypervisors/vmware/src/com/cloud/hypervisor/vmware/resource/VmwareResource.java 0922765 plugins/hypervisors/xenserver/src/com/cloud/hypervisor/xenserver/resource/CitrixResourceBase.java a2b9625 plugins/network-elements/nuage-vsp/pom.xml PRE-CREATION plugins/network-elements/nuage-vsp/resources/META-INF/cloudstack/vsp/module.properties PRE-CREATION plugins/network-elements/nuage-vsp/resources/META-INF/cloudstack/vsp/spring-vsp-context.xml PRE-CREATION plugins/network-elements/nuage-vsp/src/com/cloud/agent/api/StartupVspCommand.java PRE-CREATION plugins/network-elements/nuage-vsp/src/com/cloud/agent/api/VspResourceAnswer.java PRE-CREATION plugins/network-elements/nuage-vsp/src/com/cloud/agent/api/VspResourceCommand.java PRE-CREATION plugins/network-elements/nuage-vsp/src/com/cloud/agent/api/element/ApplyAclRuleVspAnswer.java PRE-CREATION plugins/network-elements/nuage-vsp/src/com/cloud/agent/api/element/ApplyAclRuleVspCommand.java PRE-CREATION plugins/network-elements/nuage-vsp/src/com/cloud/agent/api/element/ApplyStaticNatVspAnswer.java PRE-CREATION plugins/network-elements/nuage-vsp/src/com/cloud/agent/api/element/ApplyStaticNatVspCommand.java PRE-CREATION plugins/network-elements/nuage-vsp/src/com/cloud/agent/api/element/ShutDownVpcVspAnswer.java PRE-CREATION plugins/network-elements/nuage-vsp/src/com/cloud/agent/api/element/ShutDownVpcVspCommand.java PRE-CREATION plugins/network-elements/nuage-vsp/src/com/cloud/agent/api/guru/DeallocateVmVspAnswer.java PRE-CREATION plugins/network-elements/nuage-vsp/src/com/cloud/agent/api/guru/DeallocateVmVspCommand.java PRE-CREATION plugins/network-elements/nuage-vsp/src/com/cloud/agent/api/guru/ImplementNetworkVspAnswer.java PRE-CREATION plugins/network-elements/nuage-vsp/src/com/cloud/agent/api/guru/ImplementNetworkVspCommand.java PRE-CREATION plugins/network-elements/nuage-vsp/src/com/cloud/agent/api/guru/ReleaseVmVspAnswer.java PRE-CREATION plugins/network-elements/nuage-vsp/src/com/cloud/agent/api/guru/ReleaseVmVspCommand.java
Re: Review Request 22863: CLOUDSTACK-6823 : First code drop for Brocade Network plugin to orchestrate Brocade VDX switches for L2 connectivity.
On July 21, 2014, 2:02 p.m., Hugo Trippaers wrote: Can you rebase on latest master as the patch currently fails to apply. Cheers, Hugo patching file api/src/com/cloud/network/Network.java Hunk #1 FAILED at 132. Hunk #2 succeeded at 224 (offset 3 lines). 1 out of 2 hunks FAILED -- saving rejects to file api/src/com/cloud/network/Network.java.rej patching file api/src/com/cloud/network/Networks.java patching file api/src/com/cloud/network/PhysicalNetwork.java Hunk #1 FAILED at 33. 1 out of 1 hunk FAILED -- saving rejects to file api/src/com/cloud/network/PhysicalNetwork.java.rej patching file api/src/org/apache/cloudstack/network/ExternalNetworkDeviceManager.java patching file client/WEB-INF/classes/resources/messages.properties Hunk #1 FAILED at 327. Hunk #2 FAILED at 500. Hunk #3 succeeded at 880 (offset 6 lines). Hunk #4 succeeded at 1426 (offset 7 lines). Hunk #5 succeeded at 1639 with fuzz 2 (offset 7 lines). 2 out of 5 hunks FAILED -- saving rejects to file client/WEB-INF/classes/resources/messages.properties.rej patching file client/WEB-INF/classes/resources/messages_zh_CN.properties Hunk #1 FAILED at 297. Hunk #2 FAILED at 509. Hunk #3 succeeded at 1612 with fuzz 2 (offset 4 lines). 2 out of 3 hunks FAILED -- saving rejects to file client/WEB-INF/classes/resources/messages_zh_CN.properties.rej patching file client/pom.xml patching file client/tomcatconf/commands.properties.in Hunk #1 succeeded at 607 (offset 1 line). patching file plugins/pom.xml Hunk #1 succeeded at 64 (offset 1 line). patching file setup/db/db/schema-440to450.sql Hunk #1 succeeded at 244 with fuzz 2 (offset 20 lines). patching file test/integration/component/test_brocade_vcs.py patching file tools/apidoc/gen_toc.py Hunk #1 succeeded at 132 with fuzz 2. patching file ui/dictionary.jsp Hunk #1 FAILED at 349. Hunk #2 FAILED at 505. Hunk #3 succeeded at 870 (offset 7 lines). Hunk #4 succeeded at 1436 with fuzz 2 (offset 8 lines). Hunk #5 succeeded at 1742 (offset 9 lines). 2 out of 5 hunks FAILED -- saving rejects to file ui/dictionary.jsp.rej patching file ui/scripts/system.js Hunk #2 succeeded at 12240 (offset 243 lines). Hunk #3 succeeded at 19564 (offset 584 lines). Hunk #4 succeeded at 20343 (offset 615 lines). Hunk #5 succeeded at 20379 (offset 618 lines). patching file ui/scripts/ui-custom/zoneWizard.js Hunk #1 FAILED at 726. 1 out of 1 hunk FAILED -- saving rejects to file ui/scripts/ui-custom/zoneWizard.js.rej Hi Hugo, I have rebased to latest master and uploaded the patch. The patch now has both the changes: existing cloudstack code changes and plugin specific code. Please review it and let me know if anything else is needed from my side. Thanks Regards, Ritu Sabharwal. - Ritu --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/22863/#review48220 --- On July 17, 2014, 11:52 p.m., Ritu Sabharwal wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/22863/ --- (Updated July 17, 2014, 11:52 p.m.) Review request for cloudstack and Hugo Trippaers. Bugs: CLOUDSTACK-6823 https://issues.apache.org/jira/browse/CLOUDSTACK-6823 Repository: cloudstack-git Description --- First code drop for Brocade Network plugin to orchestrate Brocade VDX switches for L2 connectivity. Please create a new branch for Brocade plugin. Diffs - api/src/com/cloud/network/Network.java 885bffe api/src/com/cloud/network/Networks.java 1e4d229 api/src/com/cloud/network/PhysicalNetwork.java 8cc214e api/src/org/apache/cloudstack/network/ExternalNetworkDeviceManager.java e73f526 client/WEB-INF/classes/resources/messages.properties b504a18 client/WEB-INF/classes/resources/messages_zh_CN.properties 1ec4e95 client/pom.xml 29fef4f client/tomcatconf/commands.properties.in d247aa0 plugins/pom.xml b5e6a61 setup/db/db/schema-440to450.sql 77445a9 test/integration/component/test_brocade_vcs.py PRE-CREATION tools/apidoc/gen_toc.py 827d6bf ui/dictionary.jsp 9026a36 ui/scripts/system.js 9a98a5c ui/scripts/ui-custom/zoneWizard.js 4091c03 Diff: https://reviews.apache.org/r/22863/diff/ Testing --- • Create an isolated network; verify that the port-profile is created on the Brocade switch. • Attach a VM to the network; verify that the VMs MAC address is associated with the port profile of the network on the Brocade switch. • Delete VMs for an isolated network; verify that the VMs MAC address is disassociated with the port profile of the network on the Brocade switch. • Delete the
Re: Review Request 22863: CLOUDSTACK-6823 : First code drop for Brocade Network plugin to orchestrate Brocade VDX switches for L2 connectivity.
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/22863/ --- (Updated July 21, 2014, 7:25 p.m.) Review request for cloudstack and Hugo Trippaers. Changes --- Rebased to latest master. Bugs: CLOUDSTACK-6823 https://issues.apache.org/jira/browse/CLOUDSTACK-6823 Repository: cloudstack-git Description --- First code drop for Brocade Network plugin to orchestrate Brocade VDX switches for L2 connectivity. Please create a new branch for Brocade plugin. Diffs (updated) - api/src/com/cloud/network/Network.java 0a08f28 api/src/com/cloud/network/Networks.java 1ad3350 api/src/com/cloud/network/PhysicalNetwork.java 024b3ce api/src/org/apache/cloudstack/network/ExternalNetworkDeviceManager.java e73f526 client/WEB-INF/classes/resources/messages.properties bb75b08 client/WEB-INF/classes/resources/messages_zh_CN.properties d7a0ca9 client/pom.xml 410cb19 client/tomcatconf/commands.properties.in aa03949 plugins/network-elements/brocade-vcs/pom.xml PRE-CREATION plugins/network-elements/brocade-vcs/resources/BrocadeInterfaceSchema.xsd PRE-CREATION plugins/network-elements/brocade-vcs/resources/BrocadePortProfileSchema.xsd PRE-CREATION plugins/network-elements/brocade-vcs/resources/BrocadeShowVcsSchema.xsd PRE-CREATION plugins/network-elements/brocade-vcs/resources/META-INF/cloudstack/vcs/module.properties PRE-CREATION plugins/network-elements/brocade-vcs/resources/META-INF/cloudstack/vcs/spring-vcs-context.xml PRE-CREATION plugins/network-elements/brocade-vcs/src/com/cloud/agent/api/AssociateMacToNetworkAnswer.java PRE-CREATION plugins/network-elements/brocade-vcs/src/com/cloud/agent/api/AssociateMacToNetworkCommand.java PRE-CREATION plugins/network-elements/brocade-vcs/src/com/cloud/agent/api/CreateNetworkAnswer.java PRE-CREATION plugins/network-elements/brocade-vcs/src/com/cloud/agent/api/CreateNetworkCommand.java PRE-CREATION plugins/network-elements/brocade-vcs/src/com/cloud/agent/api/DeleteNetworkAnswer.java PRE-CREATION plugins/network-elements/brocade-vcs/src/com/cloud/agent/api/DeleteNetworkCommand.java PRE-CREATION plugins/network-elements/brocade-vcs/src/com/cloud/agent/api/DisassociateMacFromNetworkAnswer.java PRE-CREATION plugins/network-elements/brocade-vcs/src/com/cloud/agent/api/DisassociateMacFromNetworkCommand.java PRE-CREATION plugins/network-elements/brocade-vcs/src/com/cloud/agent/api/StartupBrocadeVcsCommand.java PRE-CREATION plugins/network-elements/brocade-vcs/src/com/cloud/api/commands/AddBrocadeVcsDeviceCmd.java PRE-CREATION plugins/network-elements/brocade-vcs/src/com/cloud/api/commands/DeleteBrocadeVcsDeviceCmd.java PRE-CREATION plugins/network-elements/brocade-vcs/src/com/cloud/api/commands/ListBrocadeVcsDeviceNetworksCmd.java PRE-CREATION plugins/network-elements/brocade-vcs/src/com/cloud/api/commands/ListBrocadeVcsDevicesCmd.java PRE-CREATION plugins/network-elements/brocade-vcs/src/com/cloud/api/response/BrocadeVcsDeviceResponse.java PRE-CREATION plugins/network-elements/brocade-vcs/src/com/cloud/network/BrocadeVcsDeviceVO.java PRE-CREATION plugins/network-elements/brocade-vcs/src/com/cloud/network/BrocadeVcsNetworkVlanMappingVO.java PRE-CREATION plugins/network-elements/brocade-vcs/src/com/cloud/network/brocade/BrocadeVcsApi.java PRE-CREATION plugins/network-elements/brocade-vcs/src/com/cloud/network/brocade/BrocadeVcsApiException.java PRE-CREATION plugins/network-elements/brocade-vcs/src/com/cloud/network/brocade/Constants.java PRE-CREATION plugins/network-elements/brocade-vcs/src/com/cloud/network/dao/BrocadeVcsDao.java PRE-CREATION plugins/network-elements/brocade-vcs/src/com/cloud/network/dao/BrocadeVcsDaoImpl.java PRE-CREATION plugins/network-elements/brocade-vcs/src/com/cloud/network/dao/BrocadeVcsNetworkVlanMappingDao.java PRE-CREATION plugins/network-elements/brocade-vcs/src/com/cloud/network/dao/BrocadeVcsNetworkVlanMappingDaoImpl.java PRE-CREATION plugins/network-elements/brocade-vcs/src/com/cloud/network/element/BrocadeVcsElement.java PRE-CREATION plugins/network-elements/brocade-vcs/src/com/cloud/network/element/BrocadeVcsElementService.java PRE-CREATION plugins/network-elements/brocade-vcs/src/com/cloud/network/guru/BrocadeVcsGuestNetworkGuru.java PRE-CREATION plugins/network-elements/brocade-vcs/src/com/cloud/network/resource/BrocadeVcsResource.java PRE-CREATION plugins/network-elements/brocade-vcs/test/com/cloud/network/brocade/BrocadeVcsApiTest.java PRE-CREATION plugins/network-elements/brocade-vcs/test/com/cloud/network/guru/BrocadeVcsGuestNetworkGuruTest.java PRE-CREATION plugins/network-elements/brocade-vcs/test/com/cloud/network/resource/BrocadeVcsResourceTest.java PRE-CREATION
Re: [DISCUSS] Acquire New Ip from a different range on shared networks
Silvano, This is not exactly a help you've asked about. But something along the similar concept, we've requested a feature known as IP POOL. As an example, you have several networks either guest or public that can be put into 1 large pool. In case network x runs out of IP space, you would get an IP from another alike network. Example: Guest Net 1 - has 20 IPs Guest Net 2 - has 20 IPs If we can aggregate both Guest Networks into 1 pool, the request is executed against a pool ip network and not specific network. If Guest Net 2 runs out of IP, you would get an IP from Guest Net 1. Another possibility would be to balance the ip pools requests through round robin or consecutive allocation algorithms. On the low level, there must be an API implementation to show number of IPs available per Guest Network. Is that similar to what you are trying to do? Thanks ilya On 7/14/14, 2:59 PM, Silvano Nogueira Buback wrote: Hi guys, At Globo.com we are working in a load balancer plugin for Cloudstack with a network api developed internally. This api manages shared networks and is working with cloudstack 4.3 (as a network guru implementation). Our load balancers are in a different network, so to implement a network element of load balancer, first I need to acquire an IP from the load balancers network. What is the best way to do this? I looked at portable IPs and that makes sense to me, but I would prefer a solution where my guru can give this IP to the network. Is there any other way? Thanks in advance, Silvano Buback
Re: [DISCUSS] Acquire New Ip from a different range on shared networks
Do you want to acquire IPs for the VIP (front-end)? From: Silvano Nogueira Buback silv...@corp.globo.commailto:silv...@corp.globo.com Reply-To: dev@cloudstack.apache.orgmailto:dev@cloudstack.apache.org dev@cloudstack.apache.orgmailto:dev@cloudstack.apache.org Date: Monday, July 14, 2014 at 2:59 PM To: dev@cloudstack.apache.orgmailto:dev@cloudstack.apache.org dev@cloudstack.apache.orgmailto:dev@cloudstack.apache.org Subject: [DISCUSS] Acquire New Ip from a different range on shared networks Hi guys, At Globo.com we are working in a load balancer plugin for Cloudstack with a network api developed internally. This api manages shared networks and is working with cloudstack 4.3 (as a network guru implementation). Our load balancers are in a different network, so to implement a network element of load balancer, first I need to acquire an IP from the load balancers network. What is the best way to do this? I looked at portable IPs and that makes sense to me, but I would prefer a solution where my guru can give this IP to the network. Is there any other way? Thanks in advance, Silvano Buback
Re: [QUESTION] Baremetal DHCP Server - Abstracting Router VM
Are you trying to get rid of the virtual router? Have you looked at the DNSAPI implementation discussed earlier? From: ilya musayev ilya.mailing.li...@gmail.commailto:ilya.mailing.li...@gmail.com Reply-To: dev@cloudstack.apache.orgmailto:dev@cloudstack.apache.org dev@cloudstack.apache.orgmailto:dev@cloudstack.apache.org Date: Monday, July 21, 2014 at 11:35 AM To: dev@cloudstack.apache.orgmailto:dev@cloudstack.apache.org dev@cloudstack.apache.orgmailto:dev@cloudstack.apache.org Subject: [QUESTION] Baremetal DHCP Server - Abstracting Router VM We are trying to abstract router vm completely from our environment as it has dual nics which is big no no in hardened security environments. This is for shared (non-vpc) advanced security zone. CloudStack already has a support for Baremetal DHCP Server under Network Service Providers. Would anyone provide the context on how one go about using it? I assume we would need to write a support of some sort on our end. Examples and documentation would be appreciated. Thank you ilya
Re: [VOTE][ACS44]Apache CloudStack 4.4.0 RC 2 in branch 4.4-RC20140716T1409
Pierre-Luc, I¹ve closed the bug as invalid. Here is the explanation why: The first attempt to upgrade failed because the new system template wasn't pre-downloaded prior to upgrade (the requirement reflected in Release notes, for the cases when template is changed between CS versions) What should have been done to fix the problem: 1) manually roll back your DB to the pre-upgraded version (we always recommend to take mysql cloud/cloud_usage db dumps prior to upgrade in case rollback is needed). Currently CS doesn't support automatic rollback in case of failure 2) while being on prev version, download the template 3) start management server If you attempt to start MS for the second time when the first start failed due to upgrade problem, w/o rolling back, the MS will try to run upgrade one more time on the partially upgraded DB. And it will fail. Please follow the steps 1-3 above to fix the problem on your system. -Alena. On 7/19/14, 8:28 AM, Pierre-Luc Dion pd...@cloudops.com wrote: Ran into issue when trying to upgrade from 4.2.1. Got the following database upgrade failure: http://pastebin.com/wkkAVYu0 Jira: https://issues.apache.org/jira/browse/CLOUDSTACK-7140 *Pierre-Luc DION* Architecte de Solution Cloud | Cloud Solutions Architect t 855.652.5683 *CloudOps* Votre partenaire infonuagique* | *Cloud Solutions Experts 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6 w cloudops.com *|* tw @CloudOps_ On Wed, Jul 16, 2014 at 8:24 AM, Daan Hoogland daan.hoogl...@gmail.com wrote: Hi All, I've created a 4.4.0 release, with the following artifacts up for a vote: Git Branch and Commit SH: https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=shortlog;h=ref s/heads/4.4-RC20140716T1409 Commit: c9672d8b5710e597bca3a81a7b06dc90c7f5b1f7 List of changes: http://docs.cloudstack.apache.org/projects/cloudstack-release-notes/en/la test/ Source release (checksums and signatures are available at the same location): https://dist.apache.org/repos/dist/dev/cloudstack/4.4.0/ PGP release keys (signed using 4096R/AA4736F3): https://dist.apache.org/repos/dist/release/cloudstack/KEYS Vote will be open for 72 hours. For sanity in tallying the vote, can PMC members please be sure to indicate (binding) with their vote? [ ] +1 approve [ ] +0 no opinion [ ] -1 disapprove (and reason why) -- Daan
Re: Tomcat version issue while building cloudstack on RHEL7 RPMS
Hey Rayees, Not really, but at least before the 4.6 feature freeze. By that time centos 7 will be stable and we will some time to properly test will all the new versions of the components. Cheers, Hugo Sent from my iPhone On 21 jul. 2014, at 20:47, Rayees Namathponnan rayees.namathpon...@citrix.com wrote: Hi Hugo, Do you have any ETA for this ? Regards, Rayees -Original Message- From: Rayees Namathponnan Sent: Tuesday, July 15, 2014 9:27 AM To: dev@cloudstack.apache.org Subject: RE: Tomcat version issue while building cloudstack on RHEL7 RPMS Thanks Hugo, defect https://issues.apache.org/jira/browse/CLOUDSTACK-7106 created to track this -Original Message- From: Trippie [mailto:trip...@gmail.com] On Behalf Of Hugo Trippaers Sent: Sunday, July 13, 2014 11:52 PM To: dev@cloudstack.apache.org Subject: Re: Tomcat version issue while building cloudstack on RHEL7 RPMS Hey Rayees, We should make a second set of scripts for the new redhat and cents releases. It's not only tomcat that has changes, for example we also need systemd scripts for cloudstack. I've been working on it, but it's not finished. Cheers. Hugo On 13 jul. 2014, at 19:19, Rayees Namathponnan rayees.namathpon...@citrix.com wrote: Hi All, I am trying to build 4.5/master RPM package in RHEL 7 box, in cloud.spec file there are dependency with tomcat6 which is not available in RHEL 7 repo. RHEL 7 repo comes with tomcat7, and I cannot create RPM package due tomcat6 missing package. Any suggestion on this ? we should modify cloud.spec to remove hard dependency on tomcat6 ? Regards, Rayees
Need help clearing out the Async Queue
Folks, Looks like I have a job stuck in the async queue that I need to clear. How do you clear out the async queue please? Thanks Matt
Daily CI test summary 07/21/14
Hi All, You can see the current master builds automation status at https://cwiki.apache.org/confluence/x/RAGTAg Simulator 100% pass KVM 4 failures Xen 2 failures There is no new issue reported with latest build Regards, Rayees
RE: [DISCUSS]CLOUDSTACK-6191
Its not a false positive though, the complain is about possible null de-reference, the calling method declaration and definition provides that scope, i now made a change to accommodate null checks for vnetid and protocol values, only inside few cases where it is locally applicable, submitted a patch. I believe all other changes are still available in branch, only for this file, it was reverted earlier. Santhosh From: Daan Hoogland [daan.hoogl...@gmail.com] Sent: Thursday, July 17, 2014 3:33 AM To: Edison Su Cc: dev; Santhosh Edukulla Subject: Re: [DISCUSS]CLOUDSTACK-6191 Seems like it could have been fixed with a smaller code replace but I guess you are right. @Santosh, Can you split your commit and reapply. At least chipping off the BridgeVifDriver bit, but preferably all chopped up as other issues will probably come up. thanks, On Wed, Jul 16, 2014 at 6:57 PM, Edison Su edison...@citrix.com wrote: The commit: a600d8408ea86782318139c17cf346c8497943d0, only fixes the issues reported by coverity. Sometimes, coverity may report false alarm, that's what happened in the code I reverted. If we want to make coverity happy, we'd better refactor the code in BridgeVifDriver-Plug -Original Message- From: Daan Hoogland [mailto:daan.hoogl...@gmail.com] Sent: Tuesday, July 15, 2014 4:43 AM To: dev; Edison Su; Santhosh Edukulla Subject: Re: [DISCUSS]CLOUDSTACK-6191 Edison, You reverted a600d8408ea86782318139c17cf346c8497943d0 in the end. The code in there is solving a lot of resource problems. Did you pinpoint the exact problem? I can not imagine that there is not a side effect that Santhosh didn't know about and is undesirable that is really the really the root case. We should find that and not just revert because an existing bug was uncovered. On Mon, Jul 14, 2014 at 11:18 PM, Edison Su edison...@citrix.com wrote: Yoshikazu fixed the issue related to qemu-img which introduced by his patch in cloudstack-6191. But there is another issue introduced by commit: a600d8408ea86782318139c17cf346c8497943d0, which causes starting vm failure. So I checked in a commit: e1095b0110f08fb0c7965f9cf293a6073bbce511, to fix CLOUDSTACK-7051. So I think, both CLOUDSTACK-6191 and CLOUDSTACK-7051 should be fixed now, no need to revert or change CLOUDSTACK-6191. -Original Message- From: Daan Hoogland [mailto:daan.hoogl...@gmail.com] Sent: Saturday, July 12, 2014 11:02 AM To: dev Subject: Re: [DISCUSS]CLOUDSTACK-6191 -0 What does it fix and is the solution bonifide. We should fix the test suite if it is. The test suite not working is not enough reason to revert a commit, it should block the test-suite because the system is broken, not because of the way the test suite works. Disclaimer: I do not know enough of KVM to make a judgement call. I just got triggered by the motivation in the mail thread. On Sat, Jul 12, 2014 at 12:21 AM, Rayees Namathponnan rayees.namathpon...@citrix.com wrote: +1 Revert now and enable after complete full test in KVM KVM automation blocked more than 7 days due to this defect https://issues.apache.org/jira/browse/CLOUDSTACK-7051 Regards, Rayees -Original Message- From: Edison Su [mailto:edison...@citrix.com] Sent: Friday, July 11, 2014 2:49 PM To: dev@cloudstack.apache.org Subject: [DISCUSS]CLOUDSTACK-6191 Move the discussion to the list about CloudStack-6191: Automation test is blocked by this bug, we need to find a solution. My suggestion is sort-of-revert-the-patch, but still give admin the opportunity to specify the way to optimize KVM volume creation. The reasons: 1. End user shouldn't care about how the volume is created, is it sparse,flat/thin-provisoned or whatever technology used by hypervisor. So we'd better not expose this option in disk offering. 2.It's true that admin does care about how the volume is created, so we can add a global configuration just for the kvm volume creation. For vmware, the option is already there(vmware.create.full.clone to control whether link clone or full clone is used to create volume). We can add an option, something like kvm.qcow2.volume.create.options. Comments? -- Daan -- Daan -- Daan
Review Request 23750: Fixed Coverity Reported Issues
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/23750/ --- Review request for cloudstack, daan Hoogland, Koushik Das, and Hugo Trippaers. Bugs: coverity https://issues.apache.org/jira/browse/coverity Repository: cloudstack-git Description --- Fixed Coverity Reported issues under various categories. Diffs - api/src/org/apache/cloudstack/api/command/user/vm/DeployVMCmd.java 1beb595 engine/schema/src/com/cloud/storage/dao/VMTemplatePoolDaoImpl.java 12a0921 engine/schema/src/com/cloud/upgrade/dao/Upgrade440to450.java caf3b42 engine/storage/src/org/apache/cloudstack/storage/endpoint/DefaultEndPointSelector.java f06b43e engine/storage/volume/src/org/apache/cloudstack/storage/volume/VolumeServiceImpl.java 3fc43ea plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/BridgeVifDriver.java e684b8d server/src/com/cloud/api/ApiResponseHelper.java 51122e0 server/src/com/cloud/api/doc/ApiXmlDocWriter.java fe07056 server/src/com/cloud/resource/ResourceManagerImpl.java 68c9286 server/src/com/cloud/server/ConfigurationServerImpl.java 7c3b5a5 utils/src/com/cloud/utils/nio/NioClient.java 34d03c2 Diff: https://reviews.apache.org/r/23750/diff/ Testing --- Built the Management Server, deployed a Data Center using Simulator. Thanks, Santhosh Edukulla
Resource [DataCenter:6] is unreachable: Unable to apply userdata and password entry on router
Dear all, Suddenly I am not able to create new VMs on my zone. The error message I found on management-server.log: 2014-07-22 11:25:51,632 INFO [cloud.vm.VirtualMachineManagerImpl] (Job-Executor-3:job-17146 = [ b780cd9c-2d0b-499f-b396-269064995e30 ]) Unable to contact resource. com.cloud.exception.ResourceUnavailableException: Resource [DataCenter:6] is unreachable: Unable to apply userdata and password entry on router Looks like another issue with the VR? I have tried to stop and start dnsmasq service on the VR but problem still persists. Any advice is greatly appreciated. Thank you.
Ceph Question (Wido?)
Hi, I'm thinking Wido knows the answer to this, but - of course - anyone feel free to chime in. :) I was looking at this video of Wido's from CCCEU13 in Amsterdam: https://www.youtube.com/watch?v=57voBP_zdf8feature=youtu.be In it, Wido talks about cloning a template on the Ceph cluster, then deploying multiple VMs from the clones. I was wondering if we have documentation that would show me how this actually works in CloudStack (first from a user's standpoint and then from a developer's standpoint). Thanks! -- *Mike Tutkowski* *Senior CloudStack Developer, SolidFire Inc.* e: mike.tutkow...@solidfire.com o: 303.746.7302 Advancing the way the world uses the cloud http://solidfire.com/solution/overview/?video=play*™*
Re: Replace primary secondary storage
Hi Min, Thanks for clarification, template_store_ref provided me install_path secondary storage id information. it was quite helpful. I found this blog http://stankirdey.com/content/cloudstack-merging-secondary-storages but he is using `template_host_ref`for ACS 4.2. Is there any documented procedure to replace secondary storage for ACS 4.3 ? Regards, Tejas On Mon, Jul 21, 2014 at 10:18 PM, Min Chen min.c...@citrix.com wrote: That article only applied to ACS 4.1 and older versions. In ACS 4.2 storage refactor, db tables are changed. template_host_ref has been deprecated and replaced with template_store_ref. Thanks -min On 7/21/14 3:47 AM, Tejas Gadaria refond.g...@gmail.com wrote: Hi, I found this article http://support.citrix.com/article/CTX135229 I was just going through this but could not get some of the points. Currently I have no snapshots and all templates are public another secondary storage is not added yet. 1) In above article 2nd point says Copy the snapshots and templates from Secondary Storage host S2 to S1. 6th point in article says You must copy only private templates on Secondary storage host S2 to S1. Here I got confused a little. 2) currently both tables are showing empty as shown below. Am I doing anything wrong or it is normal? mysql select sechost_id from snapshots; Empty set (0.00 sec) mysql select host_id from template_host_ref; Empty set (0.00 sec) Regards, Tejas On Mon, Jul 21, 2014 at 1:02 PM, Tejas Gadaria refond.g...@gmail.com wrote: Hi, I have production vms running on ACS 4.3 with xen 6.2 SP1. I have requirement to change primary Secondary storage. I am planning live storage migration for all running vms, after adding new storage as primary storage storage in same cluster. ( correct me if i am missing anything)..but how can i replace secondary storage? Regards, Tejas
Re: Review Request 23679: CLOUDSTACK-7130: Tagging failed test cases with product bug Id
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/23679/#review48342 --- Commit 88f35179ef90dc4f7696b6fe2e8ee7ca4d00586c in cloudstack's branch refs/heads/master from Girish Shilamkar [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=88f3517 ] Revert CLOUDSTACK-7130: Adding BugId to failed test cases This reverts commit 24da72f37395a6bb612ea1d073db0155289cf000. - ASF Subversion and Git Services On July 18, 2014, 1:52 p.m., Gaurav Aradhye wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/23679/ --- (Updated July 18, 2014, 1:52 p.m.) Review request for cloudstack and Girish Shilamkar. Bugs: CLOUDSTACK-7130 https://issues.apache.org/jira/browse/CLOUDSTACK-7130 Repository: cloudstack-git Description --- Tagging failed test cases with product bug Id. Diffs - test/integration/smoke/test_volumes.py 7fbcc21 Diff: https://reviews.apache.org/r/23679/diff/ Testing --- Thanks, Gaurav Aradhye
