Re: Review Request 23605: CLOUDSTACK-7107: Disabling failed test cases

[Hugo Trippaers]

---
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

[Tejas Gadaria]

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

[Hugo Trippaers]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/23282/#review48208
---

Ship it!


commit 03de9cc33507400e0e06ccd84a36334a4660ef4e
Author: Suresh Ramamurthy 
Date:   Mon Jul 21 09:40:45 2014 +0200

CLOUDSTACK-6845 : NuageVsp Network plugin

Signed-off-by: Hugo Trippaers 


- 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.

Re: Review Request 23282: CLOUDSTACK-6845 : First Code drop for NuageVsp Network plugin

[ASF Subversion and Git Services]

---
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 


- 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-eleme

Re: Review Request 23282: CLOUDSTACK-6845 : First Code drop for NuageVsp Network plugin

[Hugo Trippaers]

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  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 
> Date:   Mon Jul 21 09:40:45 2014 +0200
> 
>CLOUDSTACK-6845 : NuageVsp Network plugin
> 
>Signed-off-by: Hugo Trippaers 
> 
> 
> - 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

Re: Review Request 23605: CLOUDSTACK-7107: Disabling failed test cases

[Gaurav Aradhye]

> 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

[jenkins]

See 

Changes:

[htrippaers] CLOUDSTACK-6845 : NuageVsp Network plugin

--
[...truncated 4511 lines...]
[INFO] Compiling 146 source files to 

[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 

[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 

[INFO] 
[INFO] --- maven-surefire-plugin:2.12:test (default-test) @ 
cloudstack-service-console-proxy-rdpclient ---
[INFO] Surefire report directory: 


---
 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 

 (includes = [**/*], excludes = [])
[INFO] Deleting 
 
(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 

 (includes = [**/*], excludes = [])
[INFO] Deleting 

 (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 

[INFO] Copying 3 resources
[INFO] 
[INFO] --- maven-compiler-plugin:2.5.1:compile (default-compile) @ 
cloud-console-proxy ---
[INFO] Compiling 58 source files to 

[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 

[INFO] Copying 3 resources
[INFO] 
[INFO] --- maven-compiler-plugin:2.5.1:testCompile (default-testCompile) @ 
cloud-console-proxy ---
[INFO] Compiling 1 source file to 

[INFO] 
[INFO] --- maven-surefire-plugin:2.12:test (default-test) @ cloud-console-proxy 
---
[INFO] Surefire report direc

Re: Review Request 23605: CLOUDSTACK-7107: Disabling failed test cases

[Hugo Trippaers]

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  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)

[Stephen Turner]

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

[Hugo Trippaers]

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 
> 
> Changes:
> 
> [htrippaers] CLOUDSTACK-6845 : NuageVsp Network plugin
> 
> --
> [...truncated 4511 lines...]
> [INFO] Compiling 146 source files to 
> 
> [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 
> 
> [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 
> 
> [INFO] 
> [INFO] --- maven-surefire-plugin:2.12:test (default-test) @ 
> cloudstack-service-console-proxy-rdpclient ---
> [INFO] Surefire report directory: 
> 
> 
> ---
> 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 
> 
>  (includes = [**/*], excludes = [])
> [INFO] Deleting 
>  
> (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 
> 
>  (includes = [**/*], excludes = [])
> [INFO] Deleting 
> 
>  (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 
> 
> [INFO] Copying 3 resources
> [INFO] 
> [INFO] --- maven-compiler-plugin:2.5.1:compile (default-compile) @ 
> cloud-console-proxy ---
> [INFO] Compiling 58 source files to 
> 
> [INFO] 
> [INFO] --- maven-resources-plugin:2.5:testResources (default-testResources) @ 
> cloud-console-proxy ---
> [debug] execute contextualize
> [INFO] Using 'UTF-8' encoding to copy filtere

Build failed in Jenkins: build-master #1172

[jenkins]

See 

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 

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 
' on 
'cloudstack-buildslave-centos6-a84'.
[build-master] $ 
/jenkins/tools/hudson.tasks.Maven_MavenInstallation/maven-3.1.1/bin/mvn -s 
 
-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 
( 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

[Murali Reddy]

On 15/07/14 3:29 AM, "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?

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

[jenkins]

See 

Re: Disabling failed test cases (was RE: Review Request 23605: CLOUDSTACK-7107: Disabling failed test cases)

[Gaurav Aradhye]

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 
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

[Hugo Trippaers]

On 19 jul. 2014, at 02:49, Suresh Ramamurthy 
 wrote:

> 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.

Re: Review Request 23603: Fixed CLOUDSTACK-6983: unable to register lxc template

[Rajani Karuturi]

---
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

[Indra Pramana]

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  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"  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 pro

Wiki page https://cwiki.apache.org/confluence/display/CLOUDSTACK/Cloudstack+-+Continuous+Integration

[Hugo Trippaers]

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

[Santhosh Edukulla]

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:///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; 
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

[Hugo Trippaers]

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 
 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)

[Santhosh Edukulla]

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 
mailto: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: Disabling failed test cases (was RE: Review Request 23605: CLOUDSTACK-7107: Disabling failed test cases)

[Hugo Trippaers]

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  
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 
> mailto: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 

RE: Disabling failed test cases (was RE: Review Request 23605: CLOUDSTACK-7107: Disabling failed test cases)

[Sudha Ponnaganti]

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 
mailto: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:
>
> ---

Re: Wiki page https://cwiki.apache.org/confluence/display/CLOUDSTACK/Cloudstack+-+Continuous+Integration

[Hugo Trippaers]

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  
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:///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; 
> 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)

[Hugo Trippaers]

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  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 
> mailto: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 issu

RE: Wiki page https://cwiki.apache.org/confluence/display/CLOUDSTACK/Cloudstack+-+Continuous+Integration

[Santhosh Edukulla]

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  
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:///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; 
> 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

[Tejas Gadaria]

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 
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

[Damoder Reddy]

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 
 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 
>  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)

[Stephen Turner]

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 
mailto: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: [VOTE][ACS44]Apache CloudStack 4.4.0 RC 2 in branch 4.4-RC20140716T1409

[Daan Hoogland]

abandoning vote due to bad quorum :(

On Sat, Jul 19, 2014 at 5:28 PM, Pierre-Luc Dion  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 
> 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)

[Sudha Ponnaganti]

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  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 Shilamk

Re: Review Request 23603: Fixed CLOUDSTACK-6983: unable to register lxc template

[ASF Subversion and Git Services]

---
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

[Kishan Kavala]

---
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)

[Stephen Turner]

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  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 disc

Re: Disabling failed test cases (was RE: Review Request 23605: CLOUDSTACK-7107: Disabling failed test cases)

[Hugo Trippaers]

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  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  
> 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 foll

Review Request 23735: Fix deployment of data center with marvin

[Miguel Ferreira]

---
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

[Miguel Ferreira]

---
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

[Santhosh Edukulla]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/23735/#review48216
---



tools/devcloud/devcloud-advanced.cfg


Is this change required, compared to earlier devcloud cfg, it was a working 
cfg for devcloud.



tools/marvin/marvin/deployDataCenter.py


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


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


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

[Hugo Trippaers]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/23735/#review48217
---



tools/devcloud/devcloud-advanced.cfg


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.

[Hugo Trippaers]

---
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
> 

Re: Review Request 23737: Improve usability of deployDataCenter.py and advanced zone config

[Santhosh Edukulla]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/23737/#review48219
---



tools/devcloud/devcloud-advanced.cfg


whats the significance of this change?



tools/devcloud/devcloud-advanced.cfg


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

[Leo Simons]

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  
wrote:

> Thanks Leo. Can you summarize the changes (it is a lot of changes)
> 
> From: Leo Simons 
> Reply-To: "dev@cloudstack.apache.org" 
> Date: Friday, July 18, 2014 at 7:42 AM
> To: int-toolkit , "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 message:
> ...
>> M tools/appliance/build.sh
> ...
>> A tools/appliance/defi

Re: Review Request 23609: Signature changes to delete method in VirtualMachine class in base.py

[Santhosh Edukulla]

---
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

[Min Chen]

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"  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 
>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

[Nitin Mehta]

> On July 17, 2014, 4:55 p.m., Nitin Mehta wrote:
> > server/src/com/cloud/vm/UserVmManagerImpl.java, line 960
> > 
> >
> > 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

[Min Chen]

+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"  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 &
>> Build
>> CSForge ­ rapid IaaS deployment framework
>> CloudStack Consulting
>> CloudStack Infrastructure
>> Support
>> CloudStack Bootcamp Training
>> Courses
>>
>> 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 Repu

Re: [DISCUSS] [PROPOSAL] SAML2 plugin for SSO/SLO in CloudStack

[ilya musayev]

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 &
Build
CSForge – rapid IaaS deployment framework
CloudStack Consulting
CloudStack Infrastructure
Support
CloudStack Bootcamp Training
Courses

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 & 
Build

[QUESTION] Baremetal DHCP Server - Abstracting Router VM

[ilya musayev]

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

[Rayees Namathponnan]

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  
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

[Suresh Ramamurthy]

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  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 
> 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 
> > Date:   Mon Jul 21 09:40:45 2014 +0200
> >
> >CLOUDSTACK-6845 : NuageVsp Network plugin
> >
> >Signed-off-by: Hugo Trippaers 
> >
> >
> > - 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/net

Re: Review Request 22863: CLOUDSTACK-6823 : First code drop for Brocade Network plugin to orchestrate Brocade VDX switches for L2 connectivity.

[Ritu Sabharwal]

> 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 sw

Re: Review Request 22863: CLOUDSTACK-6823 : First code drop for Brocade Network plugin to orchestrate Brocade VDX switches for L2 connectivity.

[Ritu Sabharwal]

---
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 
  plugins/pom.x

Re: [DISCUSS] Acquire New Ip from a different range on shared networks

[ilya musayev]

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

[Chiradeep Vittal]

Do you want to acquire IPs for the VIP (front-end)?

From: Silvano Nogueira Buback 
mailto:silv...@corp.globo.com>>
Reply-To: "dev@cloudstack.apache.org" 
mailto:dev@cloudstack.apache.org>>
Date: Monday, July 14, 2014 at 2:59 PM
To: "dev@cloudstack.apache.org" 
mailto: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

[Chiradeep Vittal]

Are you trying to get rid of the virtual router? Have you looked at the DNSAPI 
implementation discussed earlier?

From: ilya musayev 
mailto:ilya.mailing.li...@gmail.com>>
Reply-To: "dev@cloudstack.apache.org" 
mailto:dev@cloudstack.apache.org>>
Date: Monday, July 21, 2014 at 11:35 AM
To: "dev@cloudstack.apache.org" 
mailto: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

[Alena Prokharchyk]

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"  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 
>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

[Hugo Trippaers]

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 
>  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 
>>  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

[Mathias Mullins]

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

[Rayees Namathponnan]

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

[Santhosh Edukulla]

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  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  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
>> >>  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

[Santhosh Edukulla]

---
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

Re: Re: Why is the I/O speed of VM so terrible when using CloudStack4.2 + KVM deployment

[Pierre-Luc Dion]

could it be possible it is the Global settings: network.throttling.rate and
vm.network.throttling.rate ?
what if you set them to 0 and restart systemvms,vr and Instances?


Pierre-Luc


On Mon, Jul 21, 2014 at 9:20 PM, evanitsharp  wrote:

> Hi, David:
> Thanks for your suggest.
> But I had tested CloudStack4.1.1 + KVM(with rhel6.3)，the I/O speed was
> normal.
>
>
> Does anyone has any other advice?
> Please tell me the details of step on how to solve the problem if possible
> Thank you
>
>
>
>
> Evan
>
> Mail:evanitsh...@gmail.com
>
> From: David Nalley
> Date: 2014-07-21 12:43
> To: us...@cloudstack.apache.org
> CC: dev@cloudstack
> Subject: Re: Why is the I/O speed of VM so terrible when using
> CloudStack4.2 + KVM deployment
> IIRC, virtio wasn't the default until EL6.4.
>
> --David
>
> On Sun, Jul 20, 2014 at 10:12 PM, evanitsharp 
> wrote:
> > Dear all:
> >  I/O speed of our guest VMs are so slow when uploading or
> downloading file from them.
> >  I have tried Basic and Advanced network, but I got the same result.
> >
> > Our environment is :
> >  CloudStack 4.2.1 + KVM Host(with rhel6.3 running on it).
> >
> > But if I use CentOS 6.4 instead of rhel 6.3 as operating system of KVM
> host, The I/O speed is normal.
> > Also, CloudStack 4.1.1 doesn't have this problem.The problem only
> occuring on CloudStack 4.2 or later version
> >
> > Here are my test data around different version of CloudStack deployment:
> > PS: Target VM are virtual machines on KVM Host with WEB or FTP service
> > CloudStack versionNetwork type of CloudStackKVM software
> versionOperating system of KVMStorage type of VMOperating system of
> VMread/write speed of VM's diskAverage speed when downloading file to PC of
> LAN from target VMAverage speed when downloading file to target  VM from
> server of LAN
> >
> > 4.1.1BasicQEMU PC emulator version 0.12.1 (qemu-kvm-0.12.1.2)；qemu-img
> version 0.12.1rhel6.3sharedrhel6.349.8 MB/sWEB:38.9 MB/s  FTP:42.2
> MB/sWEB:41.0 MB/s  FTP:31.7 MB/s
> > 4.1.1BasicQEMU PC emulator version 0.12.1 (qemu-kvm-0.12.1.2)；qemu-img
> version 0.12.1rhel6.3localrhel6.3116 MB/sWEB:80.6 MB/s  FTP:80.2
> MB/sWEB:103 MB/s  FTP:64.1 MB/s
> >
> >
> > 4.2.1BasicQEMU PC emulator version 0.12.1 (qemu-kvm-0.12.1.2)；qemu-img
> version 0.12.1rhel6.346.0 MB/sWEB:1.05 MB/s  FTP:1 MB/sWEB:700 KB/s  FTP:14
> MB/s
> > 4.2.1AdvancedQEMU PC emulator version 0.12.1
> (qemu-kvm-0.12.1.2)；qemu-img version 0.12.1CentOS release 6.4
> (Final)sharedrhel6.340.6 MB/sWEB:23.8 MB/sWEB:22.6 KB/s
> > 4.2.1AdvancedQEMU PC emulator version 0.12.1
> (qemu-kvm-0.12.1.2)；qemu-img version 0.12.1CentOS release 6.4
> (Final)localrhel6.348.7 MB/sWEB:24.2 MB/s  FTP:24.5MB/sWEB:24.2 MB/s
>  FTP:24.8MB/s
> >
> > 4.3BasicQEMU PC emulator version 0.12.1 (qemu-kvm-0.12.1.2)；qemu-img
> version 0.12.1rhel6.3sharedrhel6.335.9 MB/sWEB:218 KB/s  FTP:211.9
> KB/sWEB:811 KB/s  FTP:3.1 MB/s
> > 4.3BasicQEMU PC emulator version 0.12.1 (qemu-kvm-0.12.1.2)；qemu-img
> version 0.12.2rhel6.3localrhel6.348.5 MB/sWEB:217 KB/s  FTP:212.5
> KB/sWEB:708 KB/s  FTP:3.0 MB/s
> >
> >
> >
> > Any advice on how can I resolve the problem?
> > Looking forward to your reply, thank you.
> >
> > Evan
> >
> >
> >
> >
> > Evan
> >
> > Mail:evanitsh...@gmail.com
>

Resource [DataCenter:6] is unreachable: Unable to apply userdata and password entry on router

[Indra Pramana]

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?)

[Mike Tutkowski]

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_zdf8&feature=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
*™*

Re: Replace primary & secondary storage

[Tejas Gadaria]

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  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"  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 
> >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

[ASF Subversion and Git Services]

---
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
> 
>

FUEL-CLOUD : Frequently used entries for Localization of cloud technologies

[chandan kumar]

Hello,

We are pleased to release the first draft version of FUEL-CLOUD.
FUEL-CLOUD is a collection of commonly used entries for localization of
cloud computing related software and docs.
Today, Cloud is very new to this world and is an emerging technology to the
future. Lots of companies are switching their application to cloud. To
understand and reach to various corner of world, it is necessary to made it
available in different languages.

To make the life of translators and localizer easier, it is necessary to
provide a list of commonly used entries from cloud computing with its
context. fuel-cloud module is prepared from different cloud technologies so
that the module can be used across platform.

This module will help to use a particular word precisely in cloud computing.

Here is the link of FUEL-CLOUD module.

https://docs.google.com/spreadsheets/d/1UYbFoANH7pFdjaEJ3aGFZcYaE22-Ierf4iB6EcbBjuk/edit#gid=0

We request everybody to take a look at the module and suggest changes in
the module.

FUEL Project (http://fuelproject.org/) is the largest and fastest growing
open source based language resource repository that works to create
standard terminology, style guide, assessment methodology etc with the help
of community and different organizations. Currently it works with c.60
languages community.


Thanks,

Chandan Kumar

Re: Review Request 23609: Signature changes to delete method in VirtualMachine class in base.py

[Santhosh Edukulla]

> On July 21, 2014, 2:36 p.m., Santhosh Edukulla wrote:
> > Ship It!

please add bugid.


- Santhosh


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/23609/#review48224
---


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: Review Request 23609: Signature changes to delete method in VirtualMachine class in base.py

[Santhosh Edukulla]

> On July 21, 2014, 2:36 p.m., Santhosh Edukulla wrote:
> > Ship It!
> 
> Santhosh Edukulla wrote:
> please add bugid.

88f3517..4596ae9  master -> master


- Santhosh


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/23609/#review48224
---


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
> 
>

[ANNOUNCE] Rajani Karuturi as committer

[Prasanna Santhanam]

The Project Management Committee (PMC) for Apache CloudStack has asked
Rajani Karuturi to become a committer and we are pleased to announce that she
has accepted. Being a committer allows many contributors to contribute more
autonomously. For developers, it makes it easier to submit changes and
eliminates the need to have contributions reviewed via the patch submission
process. Whether contributions are development-related or otherwise, it is a
recognition of a contributor's participation in the project and commitment to
the project and the Apache Way.

Please join me in congratulating Rajani

-- 
Prasanna., on behalf of the CloudStack PMC


Powered by BigRock.com

RE: [ANNOUNCE] Rajani Karuturi as committer

[Shweta Agarwal]

Congrats Rajani .. well Deserved ..

-Original Message-
From: Prasanna Santhanam [mailto:t...@apache.org] 
Sent: Tuesday, July 22, 2014 11:53 AM
To: CloudStack Dev
Subject: [ANNOUNCE] Rajani Karuturi as committer

The Project Management Committee (PMC) for Apache CloudStack has asked Rajani 
Karuturi to become a committer and we are pleased to announce that she has 
accepted. Being a committer allows many contributors to contribute more 
autonomously. For developers, it makes it easier to submit changes and 
eliminates the need to have contributions reviewed via the patch submission 
process. Whether contributions are development-related or otherwise, it is a 
recognition of a contributor's participation in the project and commitment to 
the project and the Apache Way.

Please join me in congratulating Rajani

--
Prasanna., on behalf of the CloudStack PMC


Powered by BigRock.com

Re: Review Request 20123: Fix for cloudstack-6328 to Prevent console proxy support scripts from spawning multiple java processes

[Santhosh Edukulla]

> On April 29, 2014, 12:29 p.m., Santhosh Edukulla wrote:
> > Ship It!
> 
> Santhosh Edukulla wrote:
> If we don't have any review issues pending, can some body with commit 
> rights push this patch?

Saurav,

Please update BugId and Branch fields. This review submission is pending since 
long. Please check.

Santhosh


- Santhosh


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/20123/#review41708
---


On April 23, 2014, 9:20 a.m., Saurav Lahiri wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/20123/
> ---
> 
> (Updated April 23, 2014, 9:20 a.m.)
> 
> 
> Review request for cloudstack, Jayapal Reddy, Rajani Karuturi, Rajesh 
> Battala, and Santhosh Edukulla.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> With multiple java processes writing to the same logfile, each is not aware 
> of the log4j's internal counter state, this needs to be prevented. So before 
> starting new java process via the _run.sh , a check is made to ensure that 
> there are no existing java processes running. This will prevent multiple java 
> process writing to the same log file namely cloud.out. 
> 
> 
> Diffs
> -
> 
>   systemvm/patches/debian/config/etc/init.d/cloud 83853bc 
>   systemvm/scripts/run.sh 146d96f 
>   systemvm/scripts/utils.sh PRE-CREATION 
> 
> Diff: https://reviews.apache.org/r/20123/diff/
> 
> 
> Testing
> ---
> 
> Tested the changes with console proxy vm and secondary storage vm. They start 
> and stop as expected.
> 
> 
> Thanks,
> 
> Saurav Lahiri
> 
>

[PROPOSAL] *LET'S ABANDON 4.4*

[Daan Hoogland]

I had no vote's on the last release candidate. I move we abandon
releasing 4.4 or stop releasing at all.

+1 if you are in favor of not releasing
0 if you are in favor of just not releasing 4.4
-1 if you are very sorry you didn't vote, will better your life and
volunteer to be the next RM

kind regards,
-- 
Daan

Re: [ANNOUNCE] Rajani Karuturi as committer

[Daan Hoogland]

welcome Rajani, have fun

On Tue, Jul 22, 2014 at 8:27 AM, Shweta Agarwal
 wrote:
> Congrats Rajani .. well Deserved ..
>
> -Original Message-
> From: Prasanna Santhanam [mailto:t...@apache.org]
> Sent: Tuesday, July 22, 2014 11:53 AM
> To: CloudStack Dev
> Subject: [ANNOUNCE] Rajani Karuturi as committer
>
> The Project Management Committee (PMC) for Apache CloudStack has asked Rajani 
> Karuturi to become a committer and we are pleased to announce that she has 
> accepted. Being a committer allows many contributors to contribute more 
> autonomously. For developers, it makes it easier to submit changes and 
> eliminates the need to have contributions reviewed via the patch submission 
> process. Whether contributions are development-related or otherwise, it is a 
> recognition of a contributor's participation in the project and commitment to 
> the project and the Apache Way.
>
> Please join me in congratulating Rajani
>
> --
> Prasanna., on behalf of the CloudStack PMC
>
> 
> Powered by BigRock.com
>



-- 
Daan

RE: [ANNOUNCE] Rajani Karuturi as committer

[Suresh Sadhu]

Congrats Rajani.

-Original Message-
From: Shweta Agarwal [mailto:shweta.agar...@citrix.com] 
Sent: 22 July 2014 11:57
To: dev@cloudstack.apache.org
Subject: RE: [ANNOUNCE] Rajani Karuturi as committer

Congrats Rajani .. well Deserved ..

-Original Message-
From: Prasanna Santhanam [mailto:t...@apache.org] 
Sent: Tuesday, July 22, 2014 11:53 AM
To: CloudStack Dev
Subject: [ANNOUNCE] Rajani Karuturi as committer

The Project Management Committee (PMC) for Apache CloudStack has asked Rajani 
Karuturi to become a committer and we are pleased to announce that she has 
accepted. Being a committer allows many contributors to contribute more 
autonomously. For developers, it makes it easier to submit changes and 
eliminates the need to have contributions reviewed via the patch submission 
process. Whether contributions are development-related or otherwise, it is a 
recognition of a contributor's participation in the project and commitment to 
the project and the Apache Way.

Please join me in congratulating Rajani

--
Prasanna., on behalf of the CloudStack PMC


Powered by BigRock.com

Re: [ANNOUNCE] Rajani Karuturi as committer

[Punith S]

Congrats Rajani :)

cheers!


On Tue, Jul 22, 2014 at 12:04 PM, Suresh Sadhu 
wrote:

> Congrats Rajani.
>
> -Original Message-
> From: Shweta Agarwal [mailto:shweta.agar...@citrix.com]
> Sent: 22 July 2014 11:57
> To: dev@cloudstack.apache.org
> Subject: RE: [ANNOUNCE] Rajani Karuturi as committer
>
> Congrats Rajani .. well Deserved ..
>
> -Original Message-
> From: Prasanna Santhanam [mailto:t...@apache.org]
> Sent: Tuesday, July 22, 2014 11:53 AM
> To: CloudStack Dev
> Subject: [ANNOUNCE] Rajani Karuturi as committer
>
> The Project Management Committee (PMC) for Apache CloudStack has asked
> Rajani Karuturi to become a committer and we are pleased to announce that
> she has accepted. Being a committer allows many contributors to contribute
> more autonomously. For developers, it makes it easier to submit changes and
> eliminates the need to have contributions reviewed via the patch submission
> process. Whether contributions are development-related or otherwise, it is
> a recognition of a contributor's participation in the project and
> commitment to the project and the Apache Way.
>
> Please join me in congratulating Rajani
>
> --
> Prasanna., on behalf of the CloudStack PMC
>
> 
> Powered by BigRock.com
>
>


-- 
regards,

punith s
cloudbyte.com

Re: [ANNOUNCE] Rajani Karuturi as committer

[Harikrishna Patnala]

Congratulations Rajani :)

-Harikrishna

On 22-Jul-2014, at 12:11 pm, Punith S  wrote:

> Congrats Rajani :)
> 
> cheers!
> 
> 
> On Tue, Jul 22, 2014 at 12:04 PM, Suresh Sadhu 
> wrote:
> 
>> Congrats Rajani.
>> 
>> -Original Message-
>> From: Shweta Agarwal [mailto:shweta.agar...@citrix.com]
>> Sent: 22 July 2014 11:57
>> To: dev@cloudstack.apache.org
>> Subject: RE: [ANNOUNCE] Rajani Karuturi as committer
>> 
>> Congrats Rajani .. well Deserved ..
>> 
>> -Original Message-
>> From: Prasanna Santhanam [mailto:t...@apache.org]
>> Sent: Tuesday, July 22, 2014 11:53 AM
>> To: CloudStack Dev
>> Subject: [ANNOUNCE] Rajani Karuturi as committer
>> 
>> The Project Management Committee (PMC) for Apache CloudStack has asked
>> Rajani Karuturi to become a committer and we are pleased to announce that
>> she has accepted. Being a committer allows many contributors to contribute
>> more autonomously. For developers, it makes it easier to submit changes and
>> eliminates the need to have contributions reviewed via the patch submission
>> process. Whether contributions are development-related or otherwise, it is
>> a recognition of a contributor's participation in the project and
>> commitment to the project and the Apache Way.
>> 
>> Please join me in congratulating Rajani
>> 
>> --
>> Prasanna., on behalf of the CloudStack PMC
>> 
>> 
>> Powered by BigRock.com
>> 
>> 
> 
> 
> -- 
> regards,
> 
> punith s
> cloudbyte.com