date:20130528


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

(Updated May 28, 2013, 8:28 a.m.)


Review request for cloudstack, Likitha Shetty, Prasanna Santhanam, Parth 
Jagirdar, and Girish Shilamkar.


Changes
---

including QA owner of the test plan


Description
---

Testcases for changing account membership for vas


This addresses bug CLOUDSTACK-2273.


Diffs
-

  test/integration/component/test_assign_vm.py PRE-CREATION 
  tools/marvin/marvin/integration/lib/base.py f3a96bd 

Diff: https://reviews.apache.org/r/11307/diff/


Testing
---


Thanks,

Ashutosh Kelkar

Re: Review Request: CS-2273: Automation: Change account membership for VMs



> On May 28, 2013, 8:22 a.m., Likitha Shetty wrote:
> > test/integration/component/test_assign_vm.py, line 360
> > 
> >
> > create_vm with pf=true has been implemented?

Yes, VirtualMachine.create() checks for mode if mode is 'advance' it crate pf 
rule else it does not. 


> On May 28, 2013, 8:22 a.m., Likitha Shetty wrote:
> > test/integration/component/test_assign_vm.py, line 370
> > 
> >
> > If a VM with attached volumes is moved then the VM along with the 
> > volumes will be successfully moved to the new owner.

Sure I will add check for volume


> On May 28, 2013, 8:22 a.m., Likitha Shetty wrote:
> > test/integration/component/test_assign_vm.py, line 382
> > 
> >
> > When a VM is moved the snapshots of the attached volumes is deleted and 
> > the move is successful.

In this test case we are testing for VM ownership change for VM with root disk 
snapshot not volumes are attached.


> On May 28, 2013, 8:22 a.m., Likitha Shetty wrote:
> > test/integration/component/test_assign_vm.py, line 322
> > 
> >
> > How is this test different from test_07?

Yes target account should not have any default network and network should get 
crated once vm ownership is changed, I need to add assert for network created 
in target account.


> On May 28, 2013, 8:22 a.m., Likitha Shetty wrote:
> > test/integration/component/test_assign_vm.py, line 404
> > 
> >
> > In this test case we are setting the limit on the number of VM's that 
> > can be in subdomain1 to 1.
> > Haven't we already moved a number of VMs to subdomain1 that are yet to 
> > cleaned up?

for a test run only 1 vm is created and destroyed after test run is complete 
not test suite.  limit resource type is snapshot


> On May 28, 2013, 8:22 a.m., Likitha Shetty wrote:
> > test/integration/component/test_assign_vm.py, line 424
> > 
> >
> > Same concern as above.
> > Also, can you specify for what resource the account limit has been 
> > reached? If it is VM how is it different from test_16?

for this test run limit resource type is snapshot. pre conditions are volumes 
attached to a vm and limit is reached.


> On May 28, 2013, 8:22 a.m., Likitha Shetty wrote:
> > test/integration/component/test_assign_vm.py, line 322
> > 
> >
> > How is this test case different from test_07

here we only check for vm ownership change.


- Ashutosh


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


On May 28, 2013, 8:28 a.m., Ashutosh Kelkar wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/11307/
> ---
> 
> (Updated May 28, 2013, 8:28 a.m.)
> 
> 
> Review request for cloudstack, Likitha Shetty, Prasanna Santhanam, Parth 
> Jagirdar, and Girish Shilamkar.
> 
> 
> Description
> ---
> 
> Testcases for changing account membership for vas
> 
> 
> This addresses bug CLOUDSTACK-2273.
> 
> 
> Diffs
> -
> 
>   test/integration/component/test_assign_vm.py PRE-CREATION 
>   tools/marvin/marvin/integration/lib/base.py f3a96bd 
> 
> Diff: https://reviews.apache.org/r/11307/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Ashutosh Kelkar
> 
>

Re: Review Request: CLOUDSTACK-2620 [Multiple_IP_Ranges] Guest vm's nameserver is not set to VRs guest IP address in case of multiple subnets

2013-05-28 Thread Koushik Das


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



api/src/com/cloud/agent/api/to/DnsmasqTO.java


nit: variable name shouldn't start with caps. Change in other places as well



core/src/com/cloud/network/DnsMasqConfigurator.java


Can you format these text properly? What all is comment and what all 
actually gets replaced?



core/src/com/cloud/network/DnsMasqConfigurator.java


What is the correct formatting here, tag:net1,6,... (used in the code below)
OR
dhcp-option=6,dns1,dns2,...




server/src/com/cloud/network/router/VirtualNetworkApplianceManagerImpl.java


You have the cidr which can be used as well in dhcp-range parameter.


- Koushik Das


On May 27, 2013, 3:05 p.m., bharat kumar wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/11436/
> ---
> 
> (Updated May 27, 2013, 3:05 p.m.)
> 
> 
> Review request for cloudstack, Abhinandan Prateek and Koushik Das.
> 
> 
> Description
> ---
> 
> [Multiple_IP_Ranges] Guest vm's nameserver is not set to VRs guest IP address 
> in case of multiple subnets
> https://issues.apache.org/jira/browse/CLOUDSTACK-2620
> 
> 
> This addresses bug Cloudstack-2620.
> 
> 
> Diffs
> -
> 
>   api/src/com/cloud/agent/api/to/DnsmasqTO.java f99878c 
>   core/src/com/cloud/network/DnsMasqConfigurator.java ee8e5fc 
>   server/src/com/cloud/network/router/VirtualNetworkApplianceManagerImpl.java 
> b969be2 
> 
> Diff: https://reviews.apache.org/r/11436/diff/
> 
> 
> Testing
> ---
> 
> tested on master.
> 
> 
> Thanks,
> 
> bharat kumar
> 
>

Review Request: add zone wide primary storage tests

2013-05-28 Thread SrikanteswaraRao Talluri


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

Review request for cloudstack, Prasanna Santhanam and Sateesh Chodapuneedi.


Description
---

Added few basic zone wide primary storage tests.


This addresses bug CLOUDSTACK-2710.


Diffs
-

  test/integration/smoke/test_primary_storage.py 598654d 
  tools/marvin/marvin/integration/lib/base.py ec1c34e 

Diff: https://reviews.apache.org/r/11462/diff/


Testing
---

done.
teardown() fails as there is a bug while moving a storagepool into maintenance.


Thanks,

SrikanteswaraRao Talluri

FirewallRuleResponse vs FirewallResponse

When I createFirewallRule I recieve a FirewallResponse but when I
deleteFirewallRule I am expected to pass in an id I recieved as a
FirewallRuleResponse?

What are these two response types? They look very similar. Is this
legacy? Can we clean it up and standardize to a single
FirewallRuleResponse?

Thanks,

-- 
Prasanna.,

Re: Review Request: generalisation of network code (needed for CLOUDSTACK-1532)

2013-05-28 Thread daan Hoogland


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

(Updated May 28, 2013, 9:29 a.m.)


Review request for cloudstack, Murali Reddy and Hugo Trippaers.


Changes
---

enabled the lswitch variant


Description
---

converting vlan id to uri to support a broader range of networks in for 
instance vpc gateway connections


Diffs (updated)
-

  api/src/com/cloud/agent/api/to/IpAddressTO.java 82c7d99 
  api/src/com/cloud/agent/api/to/NetworkTO.java 3edd4c0 
  api/src/com/cloud/network/NetworkService.java 59702a2 
  api/src/com/cloud/network/Networks.java 5aede05 
  api/src/com/cloud/network/vpc/PrivateIp.java eb68433 
  api/src/com/cloud/network/vpc/StaticRouteProfile.java 54aa6e4 
  api/src/com/cloud/network/vpc/VpcGateway.java 5d278e9 
  api/src/com/cloud/network/vpc/VpcService.java 7a444c0 
  
api/src/org/apache/cloudstack/api/command/admin/vpc/CreatePrivateGatewayCmd.java
 22dfb9e 
  api/src/org/apache/cloudstack/api/response/PrivateGatewayResponse.java 
c5c7df5 
  core/src/com/cloud/agent/resource/virtualnetwork/VirtualRoutingResource.java 
8b996d1 
  engine/schema/src/com/cloud/network/vpc/VpcGatewayVO.java 7df2dfd 
  
plugins/hypervisors/baremetal/src/com/cloud/baremetal/networkservice/BaremetaNetworkGuru.java
 6d14e3f 
  
plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/BridgeVifDriver.java
 b897df2 
  
plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/LibvirtComputingResource.java
 f979cfe 
  
plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/OvsVifDriver.java 
eac3248 
  plugins/hypervisors/ovm/src/com/cloud/ovm/hypervisor/OvmResourceBase.java 
a626e31 
  
plugins/hypervisors/vmware/src/com/cloud/hypervisor/vmware/resource/VmwareResource.java
 630d1b4 
  
plugins/hypervisors/xen/src/com/cloud/hypervisor/xen/resource/CitrixResourceBase.java
 4680fde 
  
plugins/network-elements/cisco-vnmc/test/com/cloud/network/element/CiscoVnmcElementTest.java
 a16733b 
  
plugins/network-elements/f5/src/com/cloud/network/resource/F5BigIpResource.java 
1733712 
  
plugins/network-elements/juniper-srx/src/com/cloud/network/resource/JuniperSrxResource.java
 fd065d5 
  
plugins/network-elements/netscaler/src/com/cloud/network/resource/NetscalerResource.java
 c0d4599 
  
plugins/network-elements/ovs/src/com/cloud/network/ovs/OvsTunnelManagerImpl.java
 b1ecaac 
  server/src/com/cloud/api/ApiResponseHelper.java 89739cf 
  server/src/com/cloud/configuration/ConfigurationManagerImpl.java 214e292 
  server/src/com/cloud/network/ExternalFirewallDeviceManagerImpl.java 9d24e47 
  server/src/com/cloud/network/ExternalLoadBalancerDeviceManagerImpl.java 
f93bf7a 
  server/src/com/cloud/network/ExternalLoadBalancerUsageManagerImpl.java 
2c8031c 
  server/src/com/cloud/network/NetworkManager.java 05bc26e 
  server/src/com/cloud/network/NetworkManagerImpl.java 254510b 
  server/src/com/cloud/network/NetworkServiceImpl.java 1533ca9 
  server/src/com/cloud/network/guru/DirectPodBasedNetworkGuru.java cf27986 
  server/src/com/cloud/network/guru/PrivateNetworkGuru.java 2e266e7 
  server/src/com/cloud/network/guru/PublicNetworkGuru.java a83cdb3 
  
server/src/com/cloud/network/router/VpcVirtualNetworkApplianceManagerImpl.java 
9992b7c 
  server/src/com/cloud/network/vpc/PrivateGatewayProfile.java d6480cd 
  server/src/com/cloud/network/vpc/PrivateIpAddress.java 2f3cf53 
  server/src/com/cloud/network/vpc/VpcManagerImpl.java 1aab732 
  server/test/com/cloud/network/CreatePrivateNetworkTest.java PRE-CREATION 
  server/test/com/cloud/network/MockNetworkManagerImpl.java e5d34fb 
  server/test/com/cloud/vpc/MockNetworkManagerImpl.java 7129273 
  server/test/com/cloud/vpc/MockVpcManagerImpl.java 921321f 
  setup/db/db/schema-410to420.sql 1c9a8c1 

Diff: https://reviews.apache.org/r/10970/diff/


Testing (updated)
---

the NetworkTO is tested to accept uris with several initial states.
createPrivateNetwork in NetworkServiceImpl is tested (to accept only vlan or 
lswitch based networks for now)
test code that used to use 'vlan://#' now uses 'vlan:#'


Thanks,

daan Hoogland

Re: FirewallRuleResponse vs FirewallResponse

2013-05-28 Thread Nitin Mehta

But, this will break backward compatibility no ?
Maybe change it in the next big release.

On 28/05/13 2:50 PM, "Prasanna Santhanam" 
wrote:

>When I createFirewallRule I recieve a FirewallResponse but when I
>deleteFirewallRule I am expected to pass in an id I recieved as a
>FirewallRuleResponse?
>
>What are these two response types? They look very similar. Is this
>legacy? Can we clean it up and standardize to a single
>FirewallRuleResponse?
>
>Thanks,
>
>-- 
>Prasanna.,

Re: Review Request: generalisation of network code (needed for CLOUDSTACK-1532)

2013-05-28 Thread daan Hoogland


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

(Updated May 28, 2013, 9:43 a.m.)


Review request for cloudstack, Murali Reddy, Hugo Trippaers, and Chiradeep 
Vittal.


Changes
---

on request


Description
---

converting vlan id to uri to support a broader range of networks in for 
instance vpc gateway connections


Diffs
-

  api/src/com/cloud/agent/api/to/IpAddressTO.java 82c7d99 
  api/src/com/cloud/agent/api/to/NetworkTO.java 3edd4c0 
  api/src/com/cloud/network/NetworkService.java 59702a2 
  api/src/com/cloud/network/Networks.java 5aede05 
  api/src/com/cloud/network/vpc/PrivateIp.java eb68433 
  api/src/com/cloud/network/vpc/StaticRouteProfile.java 54aa6e4 
  api/src/com/cloud/network/vpc/VpcGateway.java 5d278e9 
  api/src/com/cloud/network/vpc/VpcService.java 7a444c0 
  
api/src/org/apache/cloudstack/api/command/admin/vpc/CreatePrivateGatewayCmd.java
 22dfb9e 
  api/src/org/apache/cloudstack/api/response/PrivateGatewayResponse.java 
c5c7df5 
  core/src/com/cloud/agent/resource/virtualnetwork/VirtualRoutingResource.java 
8b996d1 
  engine/schema/src/com/cloud/network/vpc/VpcGatewayVO.java 7df2dfd 
  
plugins/hypervisors/baremetal/src/com/cloud/baremetal/networkservice/BaremetaNetworkGuru.java
 6d14e3f 
  
plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/BridgeVifDriver.java
 b897df2 
  
plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/LibvirtComputingResource.java
 f979cfe 
  
plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/OvsVifDriver.java 
eac3248 
  plugins/hypervisors/ovm/src/com/cloud/ovm/hypervisor/OvmResourceBase.java 
a626e31 
  
plugins/hypervisors/vmware/src/com/cloud/hypervisor/vmware/resource/VmwareResource.java
 630d1b4 
  
plugins/hypervisors/xen/src/com/cloud/hypervisor/xen/resource/CitrixResourceBase.java
 4680fde 
  
plugins/network-elements/cisco-vnmc/test/com/cloud/network/element/CiscoVnmcElementTest.java
 a16733b 
  
plugins/network-elements/f5/src/com/cloud/network/resource/F5BigIpResource.java 
1733712 
  
plugins/network-elements/juniper-srx/src/com/cloud/network/resource/JuniperSrxResource.java
 fd065d5 
  
plugins/network-elements/netscaler/src/com/cloud/network/resource/NetscalerResource.java
 c0d4599 
  
plugins/network-elements/ovs/src/com/cloud/network/ovs/OvsTunnelManagerImpl.java
 b1ecaac 
  server/src/com/cloud/api/ApiResponseHelper.java 89739cf 
  server/src/com/cloud/configuration/ConfigurationManagerImpl.java 214e292 
  server/src/com/cloud/network/ExternalFirewallDeviceManagerImpl.java 9d24e47 
  server/src/com/cloud/network/ExternalLoadBalancerDeviceManagerImpl.java 
f93bf7a 
  server/src/com/cloud/network/ExternalLoadBalancerUsageManagerImpl.java 
2c8031c 
  server/src/com/cloud/network/NetworkManager.java 05bc26e 
  server/src/com/cloud/network/NetworkManagerImpl.java 254510b 
  server/src/com/cloud/network/NetworkServiceImpl.java 1533ca9 
  server/src/com/cloud/network/guru/DirectPodBasedNetworkGuru.java cf27986 
  server/src/com/cloud/network/guru/PrivateNetworkGuru.java 2e266e7 
  server/src/com/cloud/network/guru/PublicNetworkGuru.java a83cdb3 
  
server/src/com/cloud/network/router/VpcVirtualNetworkApplianceManagerImpl.java 
9992b7c 
  server/src/com/cloud/network/vpc/PrivateGatewayProfile.java d6480cd 
  server/src/com/cloud/network/vpc/PrivateIpAddress.java 2f3cf53 
  server/src/com/cloud/network/vpc/VpcManagerImpl.java 1aab732 
  server/test/com/cloud/network/CreatePrivateNetworkTest.java PRE-CREATION 
  server/test/com/cloud/network/MockNetworkManagerImpl.java e5d34fb 
  server/test/com/cloud/vpc/MockNetworkManagerImpl.java 7129273 
  server/test/com/cloud/vpc/MockVpcManagerImpl.java 921321f 
  setup/db/db/schema-410to420.sql 1c9a8c1 

Diff: https://reviews.apache.org/r/10970/diff/


Testing
---

the NetworkTO is tested to accept uris with several initial states.
createPrivateNetwork in NetworkServiceImpl is tested (to accept only vlan or 
lswitch based networks for now)
test code that used to use 'vlan://#' now uses 'vlan:#'


Thanks,

daan Hoogland

Re: Review Request: CS-2273: Automation: Change account membership for VMs


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

(Updated May 28, 2013, 9:45 a.m.)


Review request for cloudstack, Likitha Shetty, Prasanna Santhanam, Parth 
Jagirdar, and Girish Shilamkar.


Changes
---

Review changes: check for volume owner domain and default network in target 
domain 


Description
---

Testcases for changing account membership for vas


This addresses bug CLOUDSTACK-2273.


Diffs (updated)
-

  test/integration/component/test_assign_vm.py PRE-CREATION 
  tools/marvin/marvin/integration/lib/base.py f3a96bd 

Diff: https://reviews.apache.org/r/11307/diff/


Testing
---


Thanks,

Ashutosh Kelkar

Re: FirewallRuleResponse vs FirewallResponse

Sure, I'm looking for the rationale behind the two classes. That'll
help to determine how much of compatibility (if any) is broken because most of
them are similar. Also there are specific response types for the LoadBalancer
(ApplicationLoadBalancerResponse), GlobalLoadBalancerResponse which are
returned by the create APIs for the corresponding resources. So I'm guessing
there's a good reason to have the delete operation return a different response.

The FirewallRuleRespones seems to be the generic response returned by the 
following
APIs:

deleteLoadBalancer
deleteLoadBalancerRule 
deletePortForwardingRule
listIpForwardingRules
listPortForwardingRules
removeFromLoadBalancerRule
updatePortForwardingRule

-- 
Prasanna.,

On Tue, May 28, 2013 at 09:34:21AM +, Nitin Mehta wrote:
> But, this will break backward compatibility no ?
> Maybe change it in the next big release.
> 
> On 28/05/13 2:50 PM, "Prasanna Santhanam" 
> wrote:
> 
> >When I createFirewallRule I recieve a FirewallResponse but when I
> >deleteFirewallRule I am expected to pass in an id I recieved as a
> >FirewallRuleResponse?
> >
> >What are these two response types? They look very similar. Is this
> >legacy? Can we clean it up and standardize to a single
> >FirewallRuleResponse?
> >
> >Thanks,
> >
> >-- 
> >Prasanna.,

Powered by BigRock.com

Re: Review Request: CS-2273: Automation: Change account membership for VMs

2013-05-28 Thread Likitha Shetty

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

test/integration/component/test_assign_vm.py

Got it, thanks

test/integration/component/test_assign_vm.py

All snapshots(of both root and attached volumes)are deleted. And the since 
the VM will be successfully moved shouldn't test condition be different? 

test/integration/component/test_assign_vm.py

Even the root disk snapshots are deleted.
And since the VM will be successfully moved if both the domains are under 
the same domain admin shouldn't the test condition change?

test/integration/component/test_assign_vm.py

Oh that makes sense.

If the resource type is snapshot shouldn't the value of resourceType 
parameter be '3' for updateResourceLimit API?
I am a little confused. So the test case is that we reduce the snapshot 
resource limit of subdomain2 to 1 and try to move a VM with 1 snapshot to 
subdomain1?  

- Likitha Shetty

On May 28, 2013, 9:45 a.m., Ashutosh Kelkar wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/11307/
> ---
> 
> (Updated May 28, 2013, 9:45 a.m.)
> 
> 
> Review request for cloudstack, Likitha Shetty, Prasanna Santhanam, Parth 
> Jagirdar, and Girish Shilamkar.
> 
> 
> Description
> ---
> 
> Testcases for changing account membership for vas
> 
> 
> This addresses bug CLOUDSTACK-2273.
> 
> 
> Diffs
> -
> 
>   test/integration/component/test_assign_vm.py PRE-CREATION 
>   tools/marvin/marvin/integration/lib/base.py f3a96bd 
> 
> Diff: https://reviews.apache.org/r/11307/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Ashutosh Kelkar
> 
>

Unsupported System VM OS Debian 7.0 Wheezy on xenserver 6.1

2013-05-28 Thread Harikrishna Patnala

Hi all,

I tried installing xs-tools on system vm but I could not able to do that 
because we use Debain 7.0 Wheezy which is not supported by Xenserver 6.1

Detected `Debian 7.0' (debian version 7).

Unable to install guest packages for distribution
Debian 7.0 (debian).

Unknown Debian variant "7" ""

Why we are using Debian 7.0 for System VMs which does not have support on Xen ? 
This may result in stability issues of VM.
Is there any specific reason for Using Debian 7.0 why not Debian 6.0 Squeeze ? 
If yes is there any work around to install Xen-tools ?

Thank you

NicSecondaryIp

There is a ControlledEntity named NicSecondaryIp that is representing
a nic on the VM. The APIs that this entity is acted upon by are :

addIpToNic and removeIpFromNic.

Should this entity be more appropriately be renamed to just Nic? There
is also a NicIpAlias entity that seems to fit this too.

-- 
Prasanna.,


Powered by BigRock.com

Re: Review Request: CS-2273: Automation: Change account membership for VMs



> On May 28, 2013, 9:58 a.m., Likitha Shetty wrote:
> > test/integration/component/test_assign_vm.py, line 382
> > 
> >
> > Even the root disk snapshots are deleted.
> > And since the VM will be successfully moved if both the domains are 
> > under the same domain admin shouldn't the test condition change?

Yes as root disk snapshots are also deleted. I have added assert for snapshot 
check and removed the assertRaise


> On May 28, 2013, 9:58 a.m., Likitha Shetty wrote:
> > test/integration/component/test_assign_vm.py, line 404
> > 
> >
> > Oh that makes sense.
> > 
> > If the resource type is snapshot shouldn't the value of resourceType 
> > parameter be '3' for updateResourceLimit API?
> > I am a little confused. So the test case is that we reduce the snapshot 
> > resource limit of subdomain2 to 1 and try to move a VM with 1 snapshot to 
> > subdomain1?

Right, but now since as you have mentioned both ROOT and DATA_DISKS snapshots 
are deleted once VM owner is changed, this limit condition will not work.
I have updated the test to check for number of instances and max instance is 
set to 0.


- Ashutosh


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


On May 28, 2013, 9:45 a.m., Ashutosh Kelkar wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/11307/
> ---
> 
> (Updated May 28, 2013, 9:45 a.m.)
> 
> 
> Review request for cloudstack, Likitha Shetty, Prasanna Santhanam, Parth 
> Jagirdar, and Girish Shilamkar.
> 
> 
> Description
> ---
> 
> Testcases for changing account membership for vas
> 
> 
> This addresses bug CLOUDSTACK-2273.
> 
> 
> Diffs
> -
> 
>   test/integration/component/test_assign_vm.py PRE-CREATION 
>   tools/marvin/marvin/integration/lib/base.py f3a96bd 
> 
> Diff: https://reviews.apache.org/r/11307/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Ashutosh Kelkar
> 
>

Re: Review Request: CS-2273: Automation: Change account membership for VMs


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

(Updated May 28, 2013, 10:22 a.m.)


Review request for cloudstack, Likitha Shetty, Prasanna Santhanam, Parth 
Jagirdar, and Girish Shilamkar.


Changes
---

review changes: 1) Check snapshots are deleted when vm ownership is changed. 2) 
limit resource check on vm instances for target account.


Description
---

Testcases for changing account membership for vas


This addresses bug CLOUDSTACK-2273.


Diffs (updated)
-

  test/integration/component/test_assign_vm.py PRE-CREATION 
  tools/marvin/marvin/integration/lib/base.py f3a96bd 

Diff: https://reviews.apache.org/r/11307/diff/


Testing
---


Thanks,

Ashutosh Kelkar

Re: [MERGE]object_store branch into master

2013-05-28 Thread Wido den Hollander




On 05/23/2013 06:35 PM, Chip Childers wrote:

On Wed, May 22, 2013 at 09:25:10PM +, Edison Su wrote:




-Original Message-
From: Chip Childers [mailto:chip.child...@sungard.com]
Sent: Wednesday, May 22, 2013 1:26 PM
To: dev@cloudstack.apache.org
Subject: Re: [MERGE]object_store branch into master

On Wed, May 22, 2013 at 08:15:41PM +, Animesh Chaturvedi wrote:




-Original Message-
From: Chip Childers [mailto:chip.child...@sungard.com]
Sent: Wednesday, May 22, 2013 12:08 PM
To: dev@cloudstack.apache.org
Subject: Re: [MERGE]object_store branch into master

On Wed, May 22, 2013 at 07:00:51PM +, Animesh Chaturvedi wrote:




-Original Message-
From: John Burwell [mailto:jburw...@basho.com]
Sent: Tuesday, May 21, 2013 8:51 AM
To: dev@cloudstack.apache.org
Subject: Re: [MERGE]object_store branch into master

Edison,

Thanks, I will start going through it today.  Based on other
$dayjob responsibilities, it may take me a couple of days.

Thanks,
-John

[Animesh>] John we are just a few days away  from 4.2 feature
freeze, can

you provide your comments by Friday 5/24.   I would like all feature

threads

to be resolved sooner so that we don't have last minute rush.

I'm just going to comment on this, but not take it much further...
this type of change is an "architectural" change.  We had previously
discussed (on several
threads) that the appropriate time for this sort of thing to hit
master was
*early* in the release cycle.  Any reason that that consensus
doesn't apply here?

[Animesh>] Yes it is an architectural change and discussion on this started a

few weeks back already, Min and Edison wanted to get it in sooner by  4/30
but it took longer than anticipated in  preparing for merge and testing on
feature branch.





You're not following me I think.  See this thread on the Javelin merge:

http://markmail.org/message/e6peml5ddkqa6jp4

We have discussed that our preference is for architectural changes to hit
master shortly after a feature branch is cut.  Why are we not doing that here?


This kind of refactor takes time, a lot of time. I think I worked on the merge 
of primary storage refactor into master and bug fixes during 
March(http://comments.gmane.org/gmane.comp.apache.cloudstack.devel/14469), then 
started to work on the secondary storage refactor in 
April(http://markmail.org/message/cspb6xweeupfvpit). Min and I finished the 
coding at end of April, then tested for two weeks, send out the merge request 
at middle of May.
With the refactor, the  storage code will be much cleaner, and the performance 
of S3 will be improved, and integration with other storage vendor will be much 
easier, and the quality is ok(33 bugs fired, only 5 left: 
https://issues.apache.org/jira/issues/?jql=text%20~%20%22Object_Store_Refactor%22).
 Anyway, it's up to the community to decide, merge it or not, we already tried 
our best to get it done ASAP.




I'm absolutely not questioning the time and effort here.  I know that
you have been working hard, and that testing is happening!

I'm only asking if we, as a community, want to follow the practice of
bringing changes like this in early or late in a cycle.  I thought we
had agreed on doing it early.



So I tried reviewing the code, but I have to say that it is a lot of 
code. Reviewing such a large piece of code isn't easy.


Now, let me be honest, I'd love to see this in 4.2 since it would make 
the Ceph integration a lot better. We can get rid of NFS as Secondary 
Storage and use Ceph as the only storage for CS.


Yes, it might need some work after this branch has been merged, but I do 
agree that it's a lot of work to maintain a branch next to master. Even 
with smaller fixes you have to do a lot to keep up.


Imho a feature freeze is a feature freeze. It's set for May 31st and 
afterwards we start ironing the bugs out, but no new merges from other 
branches.


We will need the full support from Edison and Co to help iron out these 
bugs. Maybe something will be broken after the merge and that should be 
fixed asap then.


Again, my opinion in this is a bit coloured, but I think this will be a 
great addition to CloudStack, it would make 4.2 a killer release.


Wido

SystemVMInstanceResponse or SystemVmResponse

Just the migrateSystemVm command returns a response with
SystemVmInstanceResponse. The other systemVM operations return the
regular SystemVmResponse. What is the reason for this?

https://issues.apache.org/jira/browse/CLOUDSTACK-2715

A patch is attached in the bug report that fixes this. I'll apply it
if there are no objections because the SystemVMResponse returns all
the attributes of SystemVMInstance and more.

Thanks,

-- 
Prasanna.,


Powered by BigRock.com

Re: [GSOC] Five projects accepted for 2013 Google Summer of Code

2013-05-28 Thread Abhinandan Prateek

Awesome, looking forward to seeing some good work done this summer.

The students should register on Jira and review board.
A good resource to kick start has been but up by Sebastian and can be
accessed here : 
https://cwiki.apache.org/confluence/display/CLOUDSTACK/CloudStack+Universit
y
 

-abhi

On 28/05/13 12:53 AM, "Sebastien Goasguen"  wrote:

>Hi,
>
>I am pleased to report that the following projects have been accepted by
>the 2013 Google Summer of Code:
>
>"CloudStack: LDAP user provisioning", Ian Duffy
>
>"Improving CloudStack support in Apache Whirr and Apache Provisionr
>incubating", Meng Han
>
>"Integration project to deploy and use Apache Mesos on a CloudStack based
>Cloud" Dharmesh Kakadia
>
>"A New Modular UI for Apache CloudStack" Shiva Teja Reddy
>
>"Add Xen/XCP support for GRE SDN Controller" Nguyen Anh Tu
>
>Join me in congratulating all five and welcoming them to the Apache
>CloudStack community this summer.
>
>Abhi, Kelcey, Hugo and Myself will be their mentors but if you see
>questions from any of these five students feel free to jump in and help
>them out.
>
>Happy coding,
>
>Cheers,
>
>-Sebastien

Re: Review Request: Patch 2: CLOUDSTACK-681: Dedicated Resources - Explicit Dedication, Private zone, pod, cluster or host

2013-05-28 Thread Saksham Srivastava


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

(Updated May 28, 2013, 1:07 p.m.)


Review request for cloudstack, Devdeep Singh and Prachi Damle.


Changes
---

Updated Patch.


Description
---

Patch 2 for https://reviews.apache.org/r/11379/
Created for files 
server/src/com/cloud/deploy/DeploymentPlanningManagerImpl.java, 
server/test/com/cloud/vm/DeploymentPlanningManagerImplTest.java, 
server/test/org/apache/cloudstack/affinity/AffinityApiUnitTest.java


This addresses bug CLOUDSTACK-681.


Diffs (updated)
-

  server/src/com/cloud/deploy/DeploymentPlanningManagerImpl.java 795b526 
  server/test/com/cloud/vm/DeploymentPlanningManagerImplTest.java e3b7d31 
  server/test/org/apache/cloudstack/affinity/AffinityApiUnitTest.java 484b044 

Diff: https://reviews.apache.org/r/11380/diff/


Testing
---

Unittest: For the new APIs and Service, added unit tests under : 
plugins/dedicated-resources/test/org/apache/cloudstack/dedicated/DedicatedApiUnitTest.java
Marvin Test: To dedicate host, create affinity group, deploy-vm, check if vm is 
deployed on the dedicated host.
Rat Build Successful.


Thanks,

Saksham Srivastava

Re: Review Request: Update L10N strings for 4.1 (Italian and Chinese) from Transifex to repo


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

Ship it!


committed to 4.1 with 7f8b4773e5bb98c23f1a024a2a2a832c69c2ba0d

Please be sure to put this in master.

- Chip Childers


On May 27, 2013, 11:42 a.m., Milamber ASF wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/11433/
> ---
> 
> (Updated May 27, 2013, 11:42 a.m.)
> 
> 
> Review request for cloudstack and Chip Childers.
> 
> 
> Description
> ---
> 
> 
> @chipc 
> Before next RC, please apply this patch on 4.1 branch to update L10N strings 
> for 4.1 (Italian and Chinese) from Transifex
> 
> 
> Diffs
> -
> 
>   client/WEB-INF/classes/resources/messages_it_IT.properties 5f68d9a 
>   client/WEB-INF/classes/resources/messages_zh_CN.properties d6ce543 
> 
> Diff: https://reviews.apache.org/r/11433/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Milamber ASF
> 
>

Re: Review Request: CLOUDSTACK-681: Dedicated Resources - Explicit Dedication, Private zone, pod, cluster or host.

2013-05-28 Thread Saksham Srivastava

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

(Updated May 28, 2013, 1:05 p.m.)

Review request for cloudstack, Devdeep Singh and Prachi Damle.

Changes
---

Resolved latest merge conflicts and updating the patch.

Description
---

Review Request for "Dedicated Resources: Explicit Dedication"
=

Functional Spec for the above Private zone, pod, cluster or host, can be found
here:
https://cwiki.apache.org/CLOUDSTACK/dedicated-resources-private-zone-pod-cluster-host-functional-spec.html
This patch request is a part of this feature.

This feature allows a user to deploy VMs only in the resources dedicated to his
account or domain.

1. Resources(Zones, Pods, Clusters or hosts) can be dedicated to an account or
domain.
Implemented 12 new APIs to dedicate/list/release resources:
- dedicateZone, listDedicatedZones, releaseDedicatedZone for a Zone.
- dedicatePod, listDedicatedPods, releaseDedicatedPod for a Pod.
- dedicateCluster, listDedicatedClusters, releaseDedicatedCluster for a
Cluster
- dedicateHost, listDedicatedHosts, releaseDedicatedHost for a Host.
2. Once a resource(eg. pod) is dedicated to an account, other resources(eg.
clusters/hosts) inside that cannot be further dedicated.
3. Once a resource is dedicated to a domain, other resources inside that can be
further dedicated to its sub-domain or account.
4. If any resource (eg.cluster) is dedicated to a account/domain, then
resources(eg. Pod) above that cannot be dedicated to different accounts/domain
(not belonging to the same domain)
5. To use Explicit dedication, user needs to create an Affinity Group of type
'ExplicitDedication'
6. A VM can be deployed with the above affinity group parameter as an input.
7. A new ExplicitDedicationProcessor has been added which will process the
affinity group of type 'Explicit Dedication' for a deployment of a VM that
demands dedicated resources.
This processor implements the AffinityGroupProcessor adapter. This processor
will update the avoid list.
8. A VM requesting dedication will be deployed on dedicatd resources if
available with the user account.
9. A VM requesting dedication can also be deployed on the dedicated resources
available with the parent domains iff no dedicated resources are available with
the current user's account or
domain.
10. A VM (without dedication) can be deployed on shared host but not on
dedicated hosts.
11. To modify the dedication, the resource has to be released first.
12. Existing Private zone functionality has been redirected to Explicit
dedication of zones.
13. Updated the db upgrade schema script. A new table "dedicated_resources" has
been added.
14. Added the right permissions in commands.properties
15. Unit tests: For the new APIs and Service, added unit tests under :
plugins/dedicated-resources/test/org/apache/cloudstack/dedicated/DedicatedApiUnitTest.java
16. Marvin Test: To dedicate host, create affinity group, deploy-vm, check if
vm is deployed on the dedicated host.

Created 2 patches for the bug:
Patch 2 is for files that are modifying the files that have windows line
endings. git am will not work for such files in a single patch.

This addresses bug CLOUDSTACK-681.

Diffs (updated)
-

api/src/com/cloud/dc/DedicatedResources.java PRE-CREATION
api/src/com/cloud/event/EventTypes.java 6dfb1ab
client/pom.xml 0c38ecb
client/tomcatconf/applicationContext.xml.in edf83a9
client/tomcatconf/commands.properties.in fd5479f
client/tomcatconf/componentContext.xml.in e946f44

engine/orchestration/src/org/apache/cloudstack/platform/orchestration/CloudOrchestrator.java
963e4d7
engine/schema/src/com/cloud/dc/dao/ClusterDao.java 3ce0798
engine/schema/src/com/cloud/dc/dao/ClusterDaoImpl.java 86dc65e
engine/schema/src/com/cloud/domain/dao/DomainDaoImpl.java 9460a73
engine/schema/src/com/cloud/host/dao/HostDao.java 98bdcb4
engine/schema/src/com/cloud/host/dao/HostDaoImpl.java 07a4232
plugins/affinity-group-processors/explicit-dedication/pom.xml PRE-CREATION

plugins/affinity-group-processors/explicit-dedication/src/org/apache/cloudstack/affinity/ExplicitDedicationProcessor.java
PRE-CREATION
plugins/dedicated-resources/pom.xml PRE-CREATION

plugins/dedicated-resources/src/org/apache/cloudstack/dedicated/api/commands/DedicateClusterCmd.java
PRE-CREATION

plugins/dedicated-resources/src/org/apache/cloudstack/dedicated/api/commands/DedicateHostCmd.java
PRE-CREATION

plugins/dedicated-resources/src/org/apache/cloudstack/dedicated/api/commands/DedicatePodCmd.java
PRE-CREATION

plugins/dedicated-resources/src/org/apache/cloudstack/dedicated/api/commands/DedicateZoneCmd.java
PRE-CREATION

plugins/dedicated-resources/src/org/apache/cloudstack/dedicated

Re: Review Request: Config value has to be encrypted for Hidden category configs


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

Ship it!


committed to 4.1 as a65c36a39138308f95049a815fa99f4da0bbde1a

Please make sure this is in master

- Chip Childers


On May 24, 2013, 8:12 a.m., Kishan Kavala wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/11369/
> ---
> 
> (Updated May 24, 2013, 8:12 a.m.)
> 
> 
> Review request for cloudstack and Chip Childers.
> 
> 
> Description
> ---
> 
> As part of the fix for CLOUDSTACK-528, category of few configs is changed to 
> 'Hidden'. Hidded config vales are expected to be encrypted. So, the value has 
> to be encrypted before changing the category
> 
> 
> This addresses bug CLOUDSTACK-528.
> 
> 
> Diffs
> -
> 
>   server/src/com/cloud/upgrade/dao/Upgrade302to40.java ecda872 
>   setup/db/db/schema-302to40.sql 7fa7348 
> 
> Diff: https://reviews.apache.org/r/11369/diff/
> 
> 
> Testing
> ---
> 
> Tested upgrade from 302 and executed unit tests
> 
> 
> Thanks,
> 
> Kishan Kavala
> 
>

[VOTE][CANCELLED] Release Apache CloudStack 4.1.0 (fourth round)

Cancelling this vote officially.

On Sun, May 26, 2013 at 10:54:02AM -0400, Chip Childers wrote:
> Hi All,
> 
> I've created a 4.1.0 release, with the following artifacts up for a
> vote.
> 
> The changes from round 3 are two commits related to DEB packaging.
> 
> Git Branch and Commit SH:
> https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=shortlog;h=refs/heads/4.1
> Commit:  db007da15290970c842c3229a11051c20b512a65
> 
> List of changes:
> https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=blob_plain;f=CHANGES;hb=4.1
> 
> Source release (checksums and signatures are available at the same
> location):
> https://dist.apache.org/repos/dist/dev/cloudstack/4.1.0/
> 
> PGP release keys (signed using A99A5D58):
> https://dist.apache.org/repos/dist/release/cloudstack/KEYS
> 
> Testing instructions are here:
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Release+test+procedure
> 
> 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)

Re: [GSOC] Five projects accepted for 2013 Google Summer of Code

On Tue, May 28, 2013 at 10:53:47AM +0530, Rohit Yadav wrote:
> On Tue, May 28, 2013 at 12:53 AM, Sebastien Goasguen wrote:
> 
> > Hi,
> >
> > I am pleased to report that the following projects have been accepted by
> > the 2013 Google Summer of Code:
> >
> > "CloudStack: LDAP user provisioning", Ian Duffy
> >
> > "Improving CloudStack support in Apache Whirr and Apache Provisionr
> > incubating", Meng Han
> >
> > "Integration project to deploy and use Apache Mesos on a CloudStack based
> > Cloud" Dharmesh Kakadia
> >
> > "A New Modular UI for Apache CloudStack" Shiva Teja Reddy
> >
> > "Add Xen/XCP support for GRE SDN Controller" Nguyen Anh Tu
> >
> > Join me in congratulating all five and welcoming them to the Apache
> > CloudStack community this summer.
> >
> 
> Congrats everyone and welcome to the Apache CloudStack community once again.
> 
> 
> > Abhi, Kelcey, Hugo and Myself will be their mentors but if you see
> > questions from any of these five students feel free to jump in and help
> > them out.
> >
> 
> While these good folks may be officially your mentors, feel free to
> reachout to the community anytime. Your mentors, admin will guide you well,
> but one advise from my side is that you all develop your work in open from
> the beginning, for example start by forking the github branches and share
> your repos/branch on which you'll be working on with the community on
> dev@email. 

I think that the github mirror may still be behind due to our graduation
infra changes.  It's best to push to a new repo, from a local clone of
the canonical ASF repo.

Re: Review Request: (CLOUDSTACK-528) fix some mistakes in configuration table which cause addSecondaryStorage failed when upgrade from 3.0.* to 4.*

2013-05-28 Thread ASF Subversion and Git Services


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


Commit a65c36a39138308f95049a815fa99f4da0bbde1a in branch refs/heads/4.1 from 
Chip Childers 
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=a65c36a ]

CLOUDSTACK-528: Config value has to be encrypted for Hidden category configs


- ASF Subversion and Git Services


On May 13, 2013, 3:38 p.m., Wei Zhou wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/11088/
> ---
> 
> (Updated May 13, 2013, 3:38 p.m.)
> 
> 
> Review request for cloudstack and Chip Childers.
> 
> 
> Description
> ---
> 
> There are some mistakes in configuration table.
> fixed them by this patch.
> 
> 
> This addresses bug CLOUDSTACK-528.
> 
> 
> Diffs
> -
> 
>   setup/db/db/schema-302to40.sql a947ac1 
> 
> Diff: https://reviews.apache.org/r/11088/diff/
> 
> 
> Testing
> ---
> 
> Nicolas has tested it.
> We also need an additional patch for the following new issue (Advanced 
> Network with Security Groups).
> 
> 
> Thanks,
> 
> Wei Zhou
> 
>

Re: [ACS41][PATCH REQ]

On Tue, May 28, 2013 at 12:02:27PM +0900, Hiroaki KAWAI wrote:
> Chip, please cherry-pick to 4.1.
> # This was my bug, sorry.
> 
> Branch: master
> 
> commit e9a6d47316d8de90eb662e9938ea7fcbe0ee0596
> Author: Hiroaki KAWAI 
> Date:   Tue May 28 11:55:21 2013 +0900
> 
> agent: fix network.bridge.type to be optional
> 
> New network.bridge.type was introduced, but for
> buckward compatibility, the key should be optional.
> 
> Signed-off-by: Hiroaki KAWAI 
>

Done

Re: Review Request: (CLOUDSTACK-1644) INFRA-5977: Testing ASFBot updates to reviewboard

2013-05-28 Thread ASF Subversion and Git Services


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


Testing svngit2jira via python 2, please ignore

- ASF Subversion and Git Services


On March 12, 2013, 11:04 a.m., Prasanna Santhanam wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/9876/
> ---
> 
> (Updated March 12, 2013, 11:04 a.m.)
> 
> 
> Review request for cloudstack and Prasanna Santhanam.
> 
> 
> Description
> ---
> 
> (CLOUDSTACK-1644) INFRA-5977: Testing ASFBot updates to reviewboard
> 
> 
> This addresses bug CLOUDSTACK-1644.
> 
> 
> Diffs
> -
> 
>   README.md 7b4d973 
> 
> Diff: https://reviews.apache.org/r/9876/diff/
> 
> 
> Testing
> ---
> 
> Strange loop. This is a test
> 
> 
> Thanks,
> 
> Prasanna Santhanam
> 
>

Re: [MERGE]object_store branch into master

2013-05-28 Thread Abhinandan Prateek



On 28/05/13 4:23 PM, "Wido den Hollander"  wrote:

>
>
>On 05/23/2013 06:35 PM, Chip Childers wrote:
>> On Wed, May 22, 2013 at 09:25:10PM +, Edison Su wrote:
>>>
>>>
 -Original Message-
 From: Chip Childers [mailto:chip.child...@sungard.com]
 Sent: Wednesday, May 22, 2013 1:26 PM
 To: dev@cloudstack.apache.org
 Subject: Re: [MERGE]object_store branch into master

 On Wed, May 22, 2013 at 08:15:41PM +, Animesh Chaturvedi wrote:
>
>
>> -Original Message-
>> From: Chip Childers [mailto:chip.child...@sungard.com]
>> Sent: Wednesday, May 22, 2013 12:08 PM
>> To: dev@cloudstack.apache.org
>> Subject: Re: [MERGE]object_store branch into master
>>
>> On Wed, May 22, 2013 at 07:00:51PM +, Animesh Chaturvedi wrote:
>>>
>>>
 -Original Message-
 From: John Burwell [mailto:jburw...@basho.com]
 Sent: Tuesday, May 21, 2013 8:51 AM
 To: dev@cloudstack.apache.org
 Subject: Re: [MERGE]object_store branch into master

 Edison,

 Thanks, I will start going through it today.  Based on other
 $dayjob responsibilities, it may take me a couple of days.

 Thanks,
 -John
>>> [Animesh>] John we are just a few days away  from 4.2 feature
>>> freeze, can
>> you provide your comments by Friday 5/24.   I would like all feature
 threads
>> to be resolved sooner so that we don't have last minute rush.
>>
>> I'm just going to comment on this, but not take it much further...
>> this type of change is an "architectural" change.  We had previously
>> discussed (on several
>> threads) that the appropriate time for this sort of thing to hit
>> master was
>> *early* in the release cycle.  Any reason that that consensus
>> doesn't apply here?
> [Animesh>] Yes it is an architectural change and discussion on this
>started a
 few weeks back already, Min and Edison wanted to get it in sooner by
4/30
 but it took longer than anticipated in  preparing for merge and
testing on
 feature branch.
>
>

 You're not following me I think.  See this thread on the Javelin
merge:

 http://markmail.org/message/e6peml5ddkqa6jp4

 We have discussed that our preference is for architectural changes to
hit
 master shortly after a feature branch is cut.  Why are we not doing
that here?
>>>
>>> This kind of refactor takes time, a lot of time. I think I worked on
>>>the merge of primary storage refactor into master and bug fixes during
>>>March(http://comments.gmane.org/gmane.comp.apache.cloudstack.devel/14469
>>>), then started to work on the secondary storage refactor in
>>>April(http://markmail.org/message/cspb6xweeupfvpit). Min and I finished
>>>the coding at end of April, then tested for two weeks, send out the
>>>merge request at middle of May.
>>> With the refactor, the  storage code will be much cleaner, and the
>>>performance of S3 will be improved, and integration with other storage
>>>vendor will be much easier, and the quality is ok(33 bugs fired, only 5
>>>left: 
>>>https://issues.apache.org/jira/issues/?jql=text%20~%20%22Object_Store_Re
>>>factor%22). Anyway, it's up to the community to decide, merge it or
>>>not, we already tried our best to get it done ASAP.
>>>
>>>
>>
>> I'm absolutely not questioning the time and effort here.  I know that
>> you have been working hard, and that testing is happening!
>>
>> I'm only asking if we, as a community, want to follow the practice of
>> bringing changes like this in early or late in a cycle.  I thought we
>> had agreed on doing it early.
>>
>
>So I tried reviewing the code, but I have to say that it is a lot of
>code. Reviewing such a large piece of code isn't easy.
>
>Now, let me be honest, I'd love to see this in 4.2 since it would make
>the Ceph integration a lot better. We can get rid of NFS as Secondary
>Storage and use Ceph as the only storage for CS.
>
>Yes, it might need some work after this branch has been merged, but I do
>agree that it's a lot of work to maintain a branch next to master. Even
>with smaller fixes you have to do a lot to keep up.
>
>Imho a feature freeze is a feature freeze. It's set for May 31st and
>afterwards we start ironing the bugs out, but no new merges from other
>branches.
>
>We will need the full support from Edison and Co to help iron out these
>bugs. Maybe something will be broken after the merge and that should be
>fixed asap then.
>
>Again, my opinion in this is a bit coloured, but I think this will be a
>great addition to CloudStack, it would make 4.2 a killer release.
>
>Wido

I think I agree with Wido, this is a great feature and if it makes it to
4.2 that would be great.
With full support from Edison and others and having Animesh throwing his
weight around this feature I think the risks are minimal.

-abhi

>

Re: [GSOC] Five projects accepted for 2013 Google Summer of Code

On Mon, May 27, 2013, at 02:23 PM, Sebastien Goasguen wrote:
> Abhi, Kelcey, Hugo and Myself will be their mentors but if you see
> questions from any of these five students feel free to jump in and help
> them out.

Congrats to all! Glad we're participating. 

Best,

jzb
-- 
Joe Brockmeier
j...@zonker.net
Twitter: @jzb
http://www.dissociatedpress.net/

Re: 4.1 release manager

On Sat, May 25, 2013, at 09:52 AM, Outback Dingo wrote:
> In my opinion, an RM should have some autonomy in management. 

Is there some instance you've noticed the release manager not having
sufficient autonomy? I'd be curious to know where the RM needs more
autonomy than we've had so far. 

Best,

jzb
-- 
Joe Brockmeier
j...@zonker.net
Twitter: @jzb
http://www.dissociatedpress.net/

[VOTE] Release Apache CloudStack 4.1.0 (fifth round)

Hi All,

I've created a 4.1.0 release, with the following artifacts up for a
vote.

The changes from round 4 are related to DEB packaging, some 
translation strings, and a functional patch to make bridge type 
optional during the agent setup (for backward compatibility).

Git Branch and Commit SH:
https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=shortlog;h=refs/heads/4.1
Commit: a5214bee99f6c5582d755c9499f7d99fd7b5b701

List of changes:
https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=blob_plain;f=CHANGES;hb=4.1

Source release (checksums and signatures are available at the same
location):
https://dist.apache.org/repos/dist/dev/cloudstack/4.1.0/

PGP release keys (signed using A99A5D58):
https://dist.apache.org/repos/dist/release/cloudstack/KEYS

Testing instructions are here:
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Release+test+procedure

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)

Re: Renaming updateVMAffinityGroup -> updateAffinityGroup

On Wed, May 01, 2013 at 09:28:20AM +0530, Prasanna Santhanam wrote:
> On Tue, Apr 30, 2013 at 10:31:46AM -0700, Prachi Damle wrote:
> > Hi Prasanna,
> > 
> > The API is to update a VirtualMachine's affinity group associations
> > - it's not really an update operation on an affinity group - hence
> > the odd naming. The resource the API is acting on is a VM.
> 
> > Please suggest any other name that seems meaningful and fits the
> > conventions...
> 
> Yes I imagined it would be something to do with the VM. But
> deleteAffinityGroup&vmid= then got me wondering. If it is
> 'updateVmAffinity' then it should be 'deleteVmAffinity' as well? Or does
> the delete also remove the affinity group after dissociating the group
> from the VM? I think not - because the affinity group could be
> associated with multiple VMs?
> :wq
> 
Bump Prachi - looking for your thoughts on this one.

-- 
Prasanna.,


Powered by BigRock.com

[DISCUSS] portable IP vs public IP

2013-05-28 Thread Murali Reddy

In CloudStack, currently there are four distinct operations available with
public IP's at network service and manager layers.

1. Acquiring a public IP from zone level public IP pool
2. Associate acquired public IP with a guest network/VPC
3. Disassociate an associated public IP with a guest network/VPC
4. Release acquired public IP

But at API, #1, #2 are rolled in to 'associateIpAddress' so an acquired
public IP is always associated with a network. Similarly #3, #4 is rolled
into 'disassociateIpAddress' API. Operations #2, #3 are not exposed
through the API layer. So in effect,

  - Public IP are always need to be associated with a network/VPC
  - Network rules for LB/PF/NAT etc expects that public IP is already
associated with the network
  - On network/VPC delete CloudStack implicitly releases acquired public
IP's by the user.
  - There is no way to transfer association of a public IP from a guest
network/VPC to another guest network/VPC. This is commonly used pattern to
mask the failures in AWS [2].

As part of the portable IP feature [1], I have relaxed these
restriction for portable IP's. So an acquired portable IP need not be
associated with a guest network/VPC always and association can be
transferred across the networks. For e.g on acquired portable IP, when an
user enables static NAT for a portable IP to VM1 in network1, disables
static NAT to VM1 and then enables static NAT with VM2 in network2,
CloudStack will implicitly transfers the association of the portable IP
from network1 to network2.

What I want to bring to discussion is portability as characteristic of
public IP vs special pool of public IP's. I have made portable IP's to be
a region level resource, which enables portable IP's association be
transferable across the networks in different zones of a region. But
portability semantics can be implemented for zone level public IP as well,
with restriction that association can be transferred across guest networks
in same physical network of a zone. This seems to me an useful
functionality to have for zone level public IP. I have extended
'associateIpAddress' API to specify a boolean flag 'is_portable' that
indicates user is requesting a portable IP. In the current implementation
this flag is interpreted as request for allocating region level public IP
pool. If it make sense then I can relax this restriction with minimal
change to indicate 'is_portable' as portable characteristics of public IP.
So 'is_portable' flag can be used irrespective of region level or zone
level public IP. And then introduce another flag to 'associateIpAddress'
API, that explicitly requests that an IP  from region level pool should be
allocated which by default can be moved across the networks from different
zones in that region.

Effort I am proposing is to get API semantics right with minimal changes.
I am not proposing to enable portability for zone level public Ip's for
4.2 but can be done for later release. Please comment.

[1]https://cwiki.apache.org/confluence/display/CLOUDSTACK/portable+public+I
P
[2]http://en.clouddesignpattern.org/index.php/CDP:Floating_IP_Pattern

Re: [MERGE]object_store branch into master

2013-05-28 Thread Nitin Mehta

Agree with Wido. This would be a great feature to have in 4.2. Yes, its a
lot of change and probably needs more education from Edison and Min maybe
through code walkthroughs, documentation, IRC meetings but I am +1 for
this to make it to 4.2 and would go as far to say that I would even
volunteer for any bug fixes required.

I would say its not too bad to merge it now as most of the features for
4.2 are merged by now and not a lot of them would be blocked because of
this. Yes, the master would be unstable but it would be even if we merge
it post cutting 4.2 branch. I would rather see this coming in 4.2 than
wait for another 6 months or so for it. Yes, this is an architectural
change and we are learning as a community to time these kind of changes.
We should also try and raise alarms for these changes much early when the
FS was proposed rather than when its done, probably a learning for all of
us :)

Thanks,
-Nitin

On 28/05/13 4:23 PM, "Wido den Hollander"  wrote:

>
>
>On 05/23/2013 06:35 PM, Chip Childers wrote:
>> On Wed, May 22, 2013 at 09:25:10PM +, Edison Su wrote:
>>>
>>>
 -Original Message-
 From: Chip Childers [mailto:chip.child...@sungard.com]
 Sent: Wednesday, May 22, 2013 1:26 PM
 To: dev@cloudstack.apache.org
 Subject: Re: [MERGE]object_store branch into master

 On Wed, May 22, 2013 at 08:15:41PM +, Animesh Chaturvedi wrote:
>
>
>> -Original Message-
>> From: Chip Childers [mailto:chip.child...@sungard.com]
>> Sent: Wednesday, May 22, 2013 12:08 PM
>> To: dev@cloudstack.apache.org
>> Subject: Re: [MERGE]object_store branch into master
>>
>> On Wed, May 22, 2013 at 07:00:51PM +, Animesh Chaturvedi wrote:
>>>
>>>
 -Original Message-
 From: John Burwell [mailto:jburw...@basho.com]
 Sent: Tuesday, May 21, 2013 8:51 AM
 To: dev@cloudstack.apache.org
 Subject: Re: [MERGE]object_store branch into master

 Edison,

 Thanks, I will start going through it today.  Based on other
 $dayjob responsibilities, it may take me a couple of days.

 Thanks,
 -John
>>> [Animesh>] John we are just a few days away  from 4.2 feature
>>> freeze, can
>> you provide your comments by Friday 5/24.   I would like all feature
 threads
>> to be resolved sooner so that we don't have last minute rush.
>>
>> I'm just going to comment on this, but not take it much further...
>> this type of change is an "architectural" change.  We had previously
>> discussed (on several
>> threads) that the appropriate time for this sort of thing to hit
>> master was
>> *early* in the release cycle.  Any reason that that consensus
>> doesn't apply here?
> [Animesh>] Yes it is an architectural change and discussion on this
>started a
 few weeks back already, Min and Edison wanted to get it in sooner by
4/30
 but it took longer than anticipated in  preparing for merge and
testing on
 feature branch.
>
>

 You're not following me I think.  See this thread on the Javelin
merge:

 http://markmail.org/message/e6peml5ddkqa6jp4

 We have discussed that our preference is for architectural changes to
hit
 master shortly after a feature branch is cut.  Why are we not doing
that here?
>>>
>>> This kind of refactor takes time, a lot of time. I think I worked on
>>>the merge of primary storage refactor into master and bug fixes during
>>>March(http://comments.gmane.org/gmane.comp.apache.cloudstack.devel/14469
>>>), then started to work on the secondary storage refactor in
>>>April(http://markmail.org/message/cspb6xweeupfvpit). Min and I finished
>>>the coding at end of April, then tested for two weeks, send out the
>>>merge request at middle of May.
>>> With the refactor, the  storage code will be much cleaner, and the
>>>performance of S3 will be improved, and integration with other storage
>>>vendor will be much easier, and the quality is ok(33 bugs fired, only 5
>>>left: 
>>>https://issues.apache.org/jira/issues/?jql=text%20~%20%22Object_Store_Re
>>>factor%22). Anyway, it's up to the community to decide, merge it or
>>>not, we already tried our best to get it done ASAP.
>>>
>>>
>>
>> I'm absolutely not questioning the time and effort here.  I know that
>> you have been working hard, and that testing is happening!
>>
>> I'm only asking if we, as a community, want to follow the practice of
>> bringing changes like this in early or late in a cycle.  I thought we
>> had agreed on doing it early.
>>
>
>So I tried reviewing the code, but I have to say that it is a lot of
>code. Reviewing such a large piece of code isn't easy.
>
>Now, let me be honest, I'd love to see this in 4.2 since it would make
>the Ceph integration a lot better. We can get rid of NFS as Secondary
>Storage and use Ceph as the only storage for CS.
>
>Yes, it m

Re: LDAP auth broken?

2013-05-28 Thread Francois Gaudreault


Abhi,

I looked again at the query this morning, and you are right, the filter 
was incorrect.  There was a weird char in it. Fixing the filter 
corrected the issue.


Sorry for the spam :)

Francois

On 2013-05-28 12:46 AM, Abhinandan Prateek wrote:

Check if the query filter is going to get the valid identifier for the
particular user. If that looks fine then can you tell us what LDAP server
you are using and also specifiy the query filter that you have configured.

-abhi

On 27/05/13 10:25 PM, "Francois Gaudreault" 
wrote:


Hi,

I am using 4.1 commit "8a9206fd28872dd436b22b847e93466f06e043bc", and I
am getting this error when trying to authenticate using LDAP:

java.lang.NullPointerException
 at
com.sun.jndi.ldap.LdapNamingEnumeration.getNextBatch(LdapNamingEnumeration
.java:129)
 at
com.sun.jndi.ldap.LdapNamingEnumeration.nextAux(LdapNamingEnumeration.java
:263)
 at
com.sun.jndi.ldap.LdapNamingEnumeration.nextImpl(LdapNamingEnumeration.jav
a:254)
 at
com.sun.jndi.ldap.LdapNamingEnumeration.next(LdapNamingEnumeration.java:20
2)
 at
com.cloud.server.auth.LDAPUserAuthenticator.authenticate(LDAPUserAuthentic
ator.java:115)
 at
com.cloud.user.AccountManagerImpl.getUserAccount(AccountManagerImpl.java:1
912)
 at
com.cloud.user.AccountManagerImpl.authenticateUser(AccountManagerImpl.java
:1784)
 at com.cloud.api.ApiServer.loginUser(ApiServer.java:766)
 at com.cloud.api.ApiServlet.processRequest(ApiServlet.java:210)
 at com.cloud.api.ApiServlet.doPost(ApiServlet.java:71)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:637)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
 at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applicati
onFilterChain.java:290)
 at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilter
Chain.java:206)
 at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.
java:233)
 at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.
java:191)
 at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:1
27)
 at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:1
02)
 at
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:555)
 at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.ja
va:109)
 at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298
)
 at
org.apache.coyote.http11.Http11NioProcessor.process(Http11NioProcessor.jav
a:889)
 at
org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.process
(Http11NioProtocol.java:721)
 at
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.jav
a:2274)
 at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:
1146)
 at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java
:615)
 at java.lang.Thread.run(Thread.java:679)
WARN  [server.auth.LDAPUserAuthenticator] (catalina-exec-21:) Unknown
error encountered null

Any ideas?

I tested using ldapsearch and it works fine.

--
Francois Gaudreault
Architecte de Solution Cloud | Cloud Solutions Architect
fgaudrea...@cloudops.com
514-629-6775
- - -
CloudOps
420 rue Guy
Montréal QC  H3J 1S6
www.cloudops.com
@CloudOps_







--
Francois Gaudreault
Architecte de Solution Cloud | Cloud Solutions Architect
fgaudrea...@cloudops.com
514-629-6775
- - -
CloudOps
420 rue Guy
Montréal QC  H3J 1S6
www.cloudops.com
@CloudOps_

Re: [DISCUSS] portable IP vs public IP

2013-05-28 Thread Daan Hoogland

Hi Murali,

I have an internal issue, 'Cannot add additional network range to NVP
isolated network', meaning the user wants to expand a guest network. Is it
an idea to integrate this question into your design? I realize that you are
adressing the API mainly but the relation seems so close that I am bringing
it up anyway.

regards,
Daan Hoogland


On Tue, May 28, 2013 at 3:56 PM, Murali Reddy wrote:

> In CloudStack, currently there are four distinct operations available with
> public IP's at network service and manager layers.
>
> 1. Acquiring a public IP from zone level public IP pool
> 2. Associate acquired public IP with a guest network/VPC
> 3. Disassociate an associated public IP with a guest network/VPC
> 4. Release acquired public IP
>
> But at API, #1, #2 are rolled in to 'associateIpAddress' so an acquired
> public IP is always associated with a network. Similarly #3, #4 is rolled
> into 'disassociateIpAddress' API. Operations #2, #3 are not exposed
> through the API layer. So in effect,
>
>   - Public IP are always need to be associated with a network/VPC
>   - Network rules for LB/PF/NAT etc expects that public IP is already
> associated with the network
>   - On network/VPC delete CloudStack implicitly releases acquired public
> IP's by the user.
>   - There is no way to transfer association of a public IP from a guest
> network/VPC to another guest network/VPC. This is commonly used pattern to
> mask the failures in AWS [2].
>
> As part of the portable IP feature [1], I have relaxed these
> restriction for portable IP's. So an acquired portable IP need not be
> associated with a guest network/VPC always and association can be
> transferred across the networks. For e.g on acquired portable IP, when an
> user enables static NAT for a portable IP to VM1 in network1, disables
> static NAT to VM1 and then enables static NAT with VM2 in network2,
> CloudStack will implicitly transfers the association of the portable IP
> from network1 to network2.
>
> What I want to bring to discussion is portability as characteristic of
> public IP vs special pool of public IP's. I have made portable IP's to be
> a region level resource, which enables portable IP's association be
> transferable across the networks in different zones of a region. But
> portability semantics can be implemented for zone level public IP as well,
> with restriction that association can be transferred across guest networks
> in same physical network of a zone. This seems to me an useful
> functionality to have for zone level public IP. I have extended
> 'associateIpAddress' API to specify a boolean flag 'is_portable' that
> indicates user is requesting a portable IP. In the current implementation
> this flag is interpreted as request for allocating region level public IP
> pool. If it make sense then I can relax this restriction with minimal
> change to indicate 'is_portable' as portable characteristics of public IP.
> So 'is_portable' flag can be used irrespective of region level or zone
> level public IP. And then introduce another flag to 'associateIpAddress'
> API, that explicitly requests that an IP  from region level pool should be
> allocated which by default can be moved across the networks from different
> zones in that region.
>
> Effort I am proposing is to get API semantics right with minimal changes.
> I am not proposing to enable portability for zone level public Ip's for
> 4.2 but can be done for later release. Please comment.
>
> [1]
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/portable+public+I
> P
> [2]http://en.clouddesignpattern.org/index.php/CDP:Floating_IP_Pattern
>
>

Re: [GSOC] Five projects accepted for 2013 Google Summer of Code

2013-05-28 Thread Nitin Mehta

Yes, congrats all and welcome onboard.
While working on these projects please do not hesitate to ask questions.
Please add/correct documentation, ask questions on coding practices and
logic, fix/file bugs if you see any.
Hope you guys have a lot of fun :)

On 28/05/13 12:53 PM, "Venkata SwamyBabu Budumuru"
 wrote:

>Congrats all!
>
>On 28/05/13 12:53 AM, "Sebastien Goasguen"  wrote:
>
>>Hi,
>>
>>I am pleased to report that the following projects have been accepted by
>>the 2013 Google Summer of Code:
>>
>>"CloudStack: LDAP user provisioning", Ian Duffy
>>
>>"Improving CloudStack support in Apache Whirr and Apache Provisionr
>>incubating", Meng Han
>>
>>"Integration project to deploy and use Apache Mesos on a CloudStack based
>>Cloud" Dharmesh Kakadia
>>
>>"A New Modular UI for Apache CloudStack" Shiva Teja Reddy
>>
>>"Add Xen/XCP support for GRE SDN Controller" Nguyen Anh Tu
>>
>>Join me in congratulating all five and welcoming them to the Apache
>>CloudStack community this summer.
>>
>>Abhi, Kelcey, Hugo and Myself will be their mentors but if you see
>>questions from any of these five students feel free to jump in and help
>>them out.
>>
>>Happy coding,
>>
>>Cheers,
>>
>>-Sebastien
>

IRC Meeting Tomorrow? (Wednesday, May 29)

Hey all, 

The regular scheduled time for the weekly IRC meeting is 17:00 UTC
tomorrow. We've had really low turnouts for the last month or so.
Instead of sending a reminder, I wanted to ping the list and see whether
we had enough interest to sustain the meeting time. 

Thoughts, suggestions, comments, flames? 

Best,

jzb
-- 
Joe Brockmeier
j...@zonker.net
Twitter: @jzb
http://www.dissociatedpress.net/

Re: [ANNOUNCE] New committer: Venkata Swamy

On Thu, May 23, 2013, at 04:21 PM, Chip Childers wrote:
> Please join me in congratulating Venkata!

Congrats and welcome aboard!

Best,

jzb
-- 
Joe Brockmeier
j...@zonker.net
Twitter: @jzb
http://www.dissociatedpress.net/

Re: [ANNOUNCE] New committer: Sailaja Mada

On Thu, May 23, 2013, at 04:20 PM, Chip Childers wrote:
> Please join me in congratulating Sailaja!

Congrats! Welcome aboard!

Best,

jzb
-- 
Joe Brockmeier
j...@zonker.net
Twitter: @jzb
http://www.dissociatedpress.net/

Re: Review Request: Cloudstack-2621 [Multiple_IP_Ranges] Failed to delete guest IP range from a new subnet/C

2013-05-28 Thread bharat kumar


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



server/src/com/cloud/configuration/ConfigurationManagerImpl.java


this code was there earlier i just reused it.  But seems like a valid 
concern will put this in a transaction.



server/src/com/cloud/network/router/VirtualNetworkApplianceManagerImpl.java


This type of code can be found at other places in cloudstack . I dont know 
why was it done this way  
 and don't know what will be the implications if i change it. so i reused 
the same code.  




- bharat kumar


On May 27, 2013, 2:50 p.m., bharat kumar wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/11435/
> ---
> 
> (Updated May 27, 2013, 2:50 p.m.)
> 
> 
> Review request for cloudstack, Abhinandan Prateek and Koushik Das.
> 
> 
> Description
> ---
> 
> [Multiple_IP_Ranges] Failed to delete guest IP range from a new subnet/C
> https://issues.apache.org/jira/browse/CLOUDSTACK-2621
> 
> 
> This addresses bug Cloudstack-2621.
> 
> 
> Diffs
> -
> 
>   server/src/com/cloud/configuration/ConfigurationManagerImpl.java 214e292 
>   server/src/com/cloud/network/router/VirtualNetworkApplianceManagerImpl.java 
> b969be2 
> 
> Diff: https://reviews.apache.org/r/11435/diff/
> 
> 
> Testing
> ---
> 
> tested on master.
> 
> 
> Thanks,
> 
> bharat kumar
> 
>

Re: patchviasocket: Why in Perl and not native Java?

On Sun, May 26, 2013, at 11:41 AM, Marcus Sorensen wrote:
> Do we want to standardize and say that if it can't be in Java, and it
> can't be in Bash, it has to be in Python? 

This seems like it'd be a good discussion to have - but really ought to
be broken out into a separate thread so it's obvious to everyone that
it's being discussed. 

Best,

jzb
-- 
Joe Brockmeier
j...@zonker.net
Twitter: @jzb
http://www.dissociatedpress.net/

Re: IRC Meeting Tomorrow? (Wednesday, May 29)

On Tue, May 28, 2013 at 09:44:10AM -0500, Joe Brockmeier wrote:
> Hey all, 
> 
> The regular scheduled time for the weekly IRC meeting is 17:00 UTC
> tomorrow. We've had really low turnouts for the last month or so.
> Instead of sending a reminder, I wanted to ping the list and see whether
> we had enough interest to sustain the meeting time. 
> 
> Thoughts, suggestions, comments, flames? 

Joe - This week I'm not going to be able to make it.

Re: Review Request: add zone wide primary storage tests

2013-05-28 Thread SrikanteswaraRao Talluri


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

(Updated May 28, 2013, 3:24 p.m.)


Review request for cloudstack, Prasanna Santhanam and Sateesh Chodapuneedi.


Changes
---

updated the diff with some more tests


Description
---

Added few basic zone wide primary storage tests.


This addresses bug CLOUDSTACK-2710.


Diffs (updated)
-

  test/integration/smoke/test_primary_storage.py 598654d 
  test/integration/smoke/test_zwps.py PRE-CREATION 
  tools/marvin/marvin/integration/lib/base.py ec1c34e 

Diff: https://reviews.apache.org/r/11462/diff/


Testing
---

done.
teardown() fails as there is a bug while moving a storagepool into maintenance.


Thanks,

SrikanteswaraRao Talluri

RE: IRC Meeting Tomorrow? (Wednesday, May 29)

2013-05-28 Thread Sudha Ponnaganti

I will attend

-Original Message-
From: Joe Brockmeier [mailto:j...@zonker.net] 
Sent: Tuesday, May 28, 2013 7:44 AM
To: dev@cloudstack.apache.org
Subject: IRC Meeting Tomorrow? (Wednesday, May 29) 

Hey all, 

The regular scheduled time for the weekly IRC meeting is 17:00 UTC tomorrow. 
We've had really low turnouts for the last month or so.
Instead of sending a reminder, I wanted to ping the list and see whether we had 
enough interest to sustain the meeting time. 

Thoughts, suggestions, comments, flames? 

Best,

jzb
--
Joe Brockmeier
j...@zonker.net
Twitter: @jzb
http://www.dissociatedpress.net/

Re: [MERGE]object_store branch into master

2013-05-28 Thread John Burwell

All,

I have gone a through a large chunk of this patch, and published my review thus 
far (https://reviews.apache.org/r/11277/).   TL;DR is that this patch has a 
number of significant issues which can be summarized as follows:

1. While it appeas that the requirement of NFS for secondary storage has 
largely been removed, it has basically been if blocked out instead of pushed 
down as an detail choice in the physical layer.  Rather than exploiting 
polymorpish to vary behavior through a set of higher level abstracttions, the 
orchestration performs instanceof NFSTO checks. The concern is that future 
evolution of secondary storage layer will still have dependencies on NFS.

2. In some sceanrios, NFS is still a requirement for secondary storage.  In 
particular, Xen users will still have to maintain an "NFS cache".  Given the 
degradation of capability, I think it would be helpful to put a few more 
eyeballs on the Xen implementation to determine if we could avoid using an 
intermediate file system.

3. I have the following concerns regarding potential race conditions and 
resource exhaustion in the NFS cache implementation.  

- The current random allocator algorithm does not account for the amount 
space that will be required for the operation (i.e. checking to ensure that the 
cache it picks has enough space to transfer to hold the object being 
downloaded) nor does it reserve the space.Given the long (in compute time) 
running nature of these of processes, the available space in a cache could be 
exhausted by a number of concurrently transfering templates and/or snapshots.  
By reserving space before the transfer, the allocator would be able to account 
for both pending operations and the current contents of the cache.
- There appears no mechanism to age out contents of the cache.  Therefore, 
as implemented, it will grow unbounded.  The only workaround for this problem 
would be to have an NFS cache whose size equals that of the object store.  
- The mechanism lacks robust error handling or retry logic.  In particular, 
the behavior if/when a cache exhausts available space appears non-deterministic.
- Generally, I see little consideration for alternative/exception flows.  
For example, what happens if I attempt to use a template/iso/snapshot in 
transit to the object store to/from the cache?  Since these files can be very 
large (multiple GBs), we have assume some transfer latency in all interactions.

4. The Image Cache abstraction is too tightly coupled to the core orchestration 
mechanism.  I would recommend implementing it as a DataStore proxy that is 
applied as necessary.  For example, the current Xen hypervisor implementation 
must interact with a file system.  It seems most appropriate that the Xen 
hypervisor implementation would apply the proxy to its secondary storage 
DataStore instances.  Therefore, the storage engine should only provide the 
facility not attempt to determine when it is needed.  Additionally, a proxy 
model would greatly reduce the size and complexity of the various classes (e.g. 
AncientDataMotionStrategy).

5. While I have only reviewed roughly 50-60% of the patch thus far, I see 
little to no additional unit tests for the new code added.  Integration tests 
have been expanded, but many of the test simply execute the service methods and 
do not verify the form of the operation results. There are also a tremendous 
number of ignored exceptions that should likely fail these tests.  Therefore, 
we could have tests passing due to an ignored exception that should be failing.

While I recognize the tremendous effort that has been expended to implement 
this capability and value of the feature, I see significant design and 
operational issues that must be addressed before it can be accepted into 
master.  In my opinion, the object_store represents a good first step, but it 
needs a few more review/refinement iterations before it will be ready for a 
master merge.

Thanks,
-John

On May 28, 2013, at 10:12 AM, Nitin Mehta  wrote:

> Agree with Wido. This would be a great feature to have in 4.2. Yes, its a
> lot of change and probably needs more education from Edison and Min maybe
> through code walkthroughs, documentation, IRC meetings but I am +1 for
> this to make it to 4.2 and would go as far to say that I would even
> volunteer for any bug fixes required.
> 
> I would say its not too bad to merge it now as most of the features for
> 4.2 are merged by now and not a lot of them would be blocked because of
> this. Yes, the master would be unstable but it would be even if we merge
> it post cutting 4.2 branch. I would rather see this coming in 4.2 than
> wait for another 6 months or so for it. Yes, this is an architectural
> change and we are learning as a community to time these kind of changes.
> We should also try and raise alarms for these changes much early when the
> FS was proposed rather than when its done, probably a learning for all of
> us :)
> 
> Tha

RE: 4.1 release manager

2013-05-28 Thread Musayev, Ilya

I will tentatively say yes - pending my discussion with Chip on Thursday on the 
process.

Regards
ilya

> -Original Message-
> From: Joe Brockmeier [mailto:j...@zonker.net]
> Sent: Tuesday, May 28, 2013 9:40 AM
> To: dev@cloudstack.apache.org
> Subject: Re: 4.1 release manager
> 
> On Sat, May 25, 2013, at 09:52 AM, Outback Dingo wrote:
> > In my opinion, an RM should have some autonomy in management.
> 
> Is there some instance you've noticed the release manager not having
> sufficient autonomy? I'd be curious to know where the RM needs more
> autonomy than we've had so far.
> 
> Best,
> 
> jzb
> --
> Joe Brockmeier
> j...@zonker.net
> Twitter: @jzb
> http://www.dissociatedpress.net/

Re: [jira] [Commented] (CLOUDSTACK-2702) unable to install XenServer Support Package (CSP) on Xen cloud platform 1.6

On Tue, May 28, 2013 at 01:52:20PM +, Dean Kamali (JIRA) wrote:
> 
> [ 
> https://issues.apache.org/jira/browse/CLOUDSTACK-2702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13668307#comment-13668307
>  ] 
> 
> Dean Kamali commented on CLOUDSTACK-2702:
> -
> 
> According to  http://cloudstack.apache.org/  CloudStack currently
> supports the most popular hypervisors: VMware, KVM, XenServer and
> Xen Cloud Platform (XCP).
> 
> Is XCP is not fully supported?

The packages (ipset, ebtables etc) that come with the CSP are included
in XenServer since 6.1. Similar instructions should work for XCP
although I haven't tried it myself. The one step I do remember to
enable security groups was to switch network backend to bridge.

Rest of the functionality should be out of the box. If not there's
probably some sysctl settings that can be tweaked. 

-- 
Prasanna.,

Powered by BigRock.com

[MERGE] Storage migration support VMware into MASTER

2013-05-28 Thread Sateesh Chodapuneedi

Hi,



I would like to merge the storage migration support to VMware into master. This 
is incremental piece of work to extend storage migration support to VMware.

Earlier storage migration feature work was done & merged into master as part of 
JIRA ticket CLOUDSTACK-659. This work just extends the supports to VMware 
hypervisor by adding the required resource command implementation.



This feature uses the same framework that's laid out as part of storage 
migration support for XenServer. Code for this feature conforms to what was 
proposed in FS [1], which encompasses the framework support for storage 
migration in CloudStack as well as support for this feature in XenServer as 
well as VMware. Implementation is done in branch [2] up for review. It includes 
unit tests for verifying the functionality.

Please take a look at it and let me know your comments.



Merge check list :-



* Did you check the branch's RAT execution success?

Yes



* Are there new dependencies introduced?

No



* What automated testing (unit and integration) is included in the new feature?

Unit tests are added.

Marvin tests written as part of CLOUDSTACK-659 to test storage migration for 
XenServer would work for this feature too because from framework point of view 
the functionality is transparent across hypervisors VMware/XenServer.



* What testing has been done to check for potential regressions?

I've tested following cases manually,

1)  Migration of a root volume of a VM to another datastore back and forth 
multiple times while the VM is running & staying in intact on a host.

2)  Migration of a data volume of a VM to another datastore back and forth 
multiple times while the VM is running & staying in intact on a host.

3)  Migration of multiple data volume of a VM to another datastore back and 
forth multiple times while the VM is running & staying in intact on a host.

4)  Migration of multiple data volume of a VM to different datastores back 
and forth multiple times while the VM is running & staying in intact on a host.

5)  Migration of VM with no data disks to another datastore back and forth 
multiple times within cluster

6)  Migration of VM with multiple data disks to single target datastore 
back and forth multiple times within cluster

7)  Migration of VM with multiple data disks to multiple target datastores 
back and forth multiple times within cluster

8)  Migration of VM with no data disks to another datastore back and forth 
multiple times across clusters

9)  Migration of VM with multiple data disks to single target datastore 
back and forth multiple times across clusters

10)   Migration of VM with multiple data disks to multiple target datastores 
back and forth multiple times across clusters

11)   Deploy VM

12)   Destroy VM

13)   Create volume

14)   Destroy volume

15)   Attach volume

16)   Detach volume



If there is no objection, I would merge the branch in 72 hours.



Regards,

Sateesh



[1] 
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Enabling+Storage+XenMotion+for+XenServer#EnablingStorageXenMotionforXenServer-VMwareResourceSupport

[2] refs/heads/vmware-storage-motion

[3] https://issues.apache.org/jira/browse/CLOUDSTACK-2071 (CLOUDSTACK-2701 - 
Enable storage migration for VMware resources)

Re: master build breaks at com.cloud.vpc.NetworkACLServiceTest

On Mon, May 27, 2013 at 04:23:20PM +, Daan Hoogland wrote:
> And if not how do I manipulate the order of tests?

IMO, tests should *never* require that they execute in a specific order.
That's what the setup and teardown phases of test execution are for.

If you find this is the issue, let's fix it.

RE: master build breaks at com.cloud.vpc.NetworkACLServiceTest

2013-05-28 Thread Pranav Saxena

I deployed the latest master today , infact moments back , but build was a 
success ! 

-Original Message-
From: Chip Childers [mailto:chip.child...@sungard.com] 
Sent: Tuesday, May 28, 2013 10:09 PM
To: dev@cloudstack.apache.org
Subject: Re: master build breaks at com.cloud.vpc.NetworkACLServiceTest

On Mon, May 27, 2013 at 04:23:20PM +, Daan Hoogland wrote:
> And if not how do I manipulate the order of tests?

IMO, tests should *never* require that they execute in a specific order.
That's what the setup and teardown phases of test execution are for.

If you find this is the issue, let's fix it.

RE: [MERGE] security group advanced zone branch into master

2013-05-28 Thread Anthony Xu

I didn't hear any objection , I'll merge this today.

Thanks,
Anthony

From: Anthony Xu
Sent: Wednesday, May 22, 2013 4:25 PM
To: dev@cloudstack.apache.org
Cc: Alena Prokharchyk; Wei Zhou (w.z...@leaseweb.com); Anthony Xu
Subject: [MERGE] security group advanced zone branch into master

Hi all,
   CloudStack has this feature in 2.2.14, but drops it in 3.0.2 
somehow. In this branch, we add this feature back, below is brief description 
for this feature,

-  Introduce advanced zone with security group, in this zone, only one 
shared network with security group is allowed, no other network allowed.

-  Support both xenserver and kvm in this zone.

-  Security group rule in this zone is like that in basic zone.

Branch: 4-2-advanced-zone-security-group

-   Except for the feature code, there are upgrade code , thanks to 
Alena, and integration/devcloud test code, thanks a lot to wei zhou.

-  UI code is in master

Test:
 I did some basic manual tests, vm can boot up, security group works 
fine
 Wei zhou added devcloud tests and integration tests, devcloud test 
works fine.

You can find more information in below bug.

https://issues.apache.org/jira/browse/CLOUDSTACK-737

Best Regards,
Anthony

RE: [VOTE] List CloudStack related books on the website

2013-05-28 Thread Clayton Weise

+1

-Original Message-
From: Sebastien Goasguen [mailto:run...@gmail.com] 
Sent: Monday, May 27, 2013 1:27 AM
To: market...@cloudstack.apache.org
Subject: [VOTE] List CloudStack related books on the website

Hi,

After a relatively long discussion on the marketing@ list about the "Packt 
Book" [1] I would like to call a vote.

Proposal:

I propose to list CloudStack related books on our website [2]. The page listing 
these books would contain the following disclaimer:

"This listing does not represent official endorsement by the Apache CloudStack 
project. The Apache CloudStack project does not recommend one book versus 
another nor does it guarantee the quality of the books."

Inclusion of a book in the listing would be done via a vote on the marketing@ 
list.

As a quick summary, alternatives to this proposal were to:
1-not do anything
2-list the books on the wiki

A few of us have already expressed their opinions and discussed the 
possibilities. Check [1]. 

Vote will be open for 96 hours (To accommodate Memorial day in the USA).

Reply with:

[ ] +1  approve
[ ] +0  no opinion
[ ] -1  disapprove (and reason why)

PS: If edits of the disclaimer are needed but that they do not change the 
meaning of it, the disclaimer will be modified but the vote will not be 
restarted.

[1] http://markmail.org/thread/r4qdmbonmx6yq2uv
[2] http://cloudstack.apache.org

-Sebastien

Re: [MERGE] security group advanced zone branch into master

On Tue, May 28, 2013 at 04:44:59PM +, Anthony Xu wrote:
> I didn't hear any objection , I'll merge this today.

+1

RE: IRC Meeting Tomorrow? (Wednesday, May 29)

2013-05-28 Thread Musayev, Ilya

Joe, 

Swamped with $dayjob, I will try to attend, but I have nothing to report.

Thanks
Ilya

> -Original Message-
> From: Chip Childers [mailto:chip.child...@sungard.com]
> Sent: Tuesday, May 28, 2013 10:52 AM
> To: dev@cloudstack.apache.org
> Subject: Re: IRC Meeting Tomorrow? (Wednesday, May 29)
> 
> On Tue, May 28, 2013 at 09:44:10AM -0500, Joe Brockmeier wrote:
> > Hey all,
> >
> > The regular scheduled time for the weekly IRC meeting is 17:00 UTC
> > tomorrow. We've had really low turnouts for the last month or so.
> > Instead of sending a reminder, I wanted to ping the list and see
> > whether we had enough interest to sustain the meeting time.
> >
> > Thoughts, suggestions, comments, flames?
> 
> Joe - This week I'm not going to be able to make it.

Re: [MERGE] security group advanced zone branch into master

2013-05-28 Thread Wei ZHOU

+1

Wei
2013/5/28 Anthony Xu 

> I didn't hear any objection , I'll merge this today.
>
>
> Thanks,
> Anthony
>
> From: Anthony Xu
> Sent: Wednesday, May 22, 2013 4:25 PM
> To: dev@cloudstack.apache.org
> Cc: Alena Prokharchyk; Wei Zhou (w.z...@leaseweb.com); Anthony Xu
> Subject: [MERGE] security group advanced zone branch into master
>
> Hi all,
>CloudStack has this feature in 2.2.14, but drops it in 3.0.2
> somehow. In this branch, we add this feature back, below is brief
> description for this feature,
>
> -  Introduce advanced zone with security group, in this zone, only
> one shared network with security group is allowed, no other network allowed.
>
> -  Support both xenserver and kvm in this zone.
>
> -  Security group rule in this zone is like that in basic zone.
>
>
> Branch: 4-2-advanced-zone-security-group
>
> -   Except for the feature code, there are upgrade code , thanks
> to Alena, and integration/devcloud test code, thanks a lot to wei zhou.
>
> -  UI code is in master
>
>
>
> Test:
>  I did some basic manual tests, vm can boot up, security group
> works fine
>  Wei zhou added devcloud tests and integration tests, devcloud
> test works fine.
>
>
>
> You can find more information in below bug.
>
>
> https://issues.apache.org/jira/browse/CLOUDSTACK-737
>
>
>
>
> Best Regards,
> Anthony
>
>

Re: [MERGE] security group advanced zone branch into master

2013-05-28 Thread Wei ZHOU

Chip,

It is ok. Hope 4.1 will be released soon.


2013/5/23 Chip Childers 

> On Thu, May 23, 2013 at 08:25:37AM +0200, Wei ZHOU wrote:
> > Guys,
> >
> > Is it possible to merge this branch to 4.1?
> >
> > Wei
>
> Wei - IMO we need to wait for 4.2 for that feature to come back into the
> product.  Re-testing is going to take too long, and we should kick out
> 4.1 as soon as possible.  Are you good with that?
>
> >
> >
> > 2013/5/23 Animesh Chaturvedi 
> >
> > >
> > >
> > > > -Original Message-
> > > > From: Anthony Xu [mailto:xuefei...@citrix.com]
> > > > Sent: Wednesday, May 22, 2013 4:25 PM
> > > > To: dev@cloudstack.apache.org
> > > > Cc: Alena Prokharchyk; Wei Zhou (w.z...@leaseweb.com); Anthony Xu
> > > > Subject: [MERGE] security group advanced zone branch into master
> > > >
> > > > Hi all,
> > > >CloudStack has this feature in 2.2.14, but drops it in
> 3.0.2
> > > > somehow. In this branch, we add this feature back, below is brief
> > > > description for this feature,
> > > >
> > > > -  Introduce advanced zone with security group, in this zone,
> > > > only one shared network with security group is allowed, no other
> network
> > > > allowed.
> > > >
> > > > -  Support both xenserver and kvm in this zone.
> > > >
> > > > -  Security group rule in this zone is like that in basic
> zone.
> > > >
> > > >
> > > > Branch: 4-2-advanced-zone-security-group
> > > >
> > > > -   Except for the feature code, there are upgrade code ,
> thanks
> > > > to Alena, and integration/devcloud test code, thanks a lot to wei
> zhou.
> > > >
> > > > -  UI code is in master
> > > >
> > > >
> > > >
> > > > Test:
> > > >  I did some basic manual tests, vm can boot up, security
> group
> > > > works fine
> > > >  Wei zhou added devcloud tests and integration tests,
> devcloud
> > > > test works fine.
> > > >
> > > >
> > > >
> > > > You can find more information in below bug.
> > > >
> > > >
> > > > https://issues.apache.org/jira/browse/CLOUDSTACK-737
> > > >
> > > >
> > > >
> > > > Best Regards,
> > > > Anthony
> > > [Animesh>] That's good collaborative effort, good job Anthony, Alena,
> Wei
> > >
> > >
>

Re: [MERGE] security group advanced zone branch into master

On Tue, May 28, 2013 at 07:10:47PM +0200, Wei ZHOU wrote:
> Chip,
> 
> It is ok. Hope 4.1 will be released soon.

Feel free to test the RC and vote!

-chip

Re: [VOTE] List CloudStack related books on the website

+1

While I appreciate the don't-play-favorites sentiments, I do feel that we
are over thinking this issue. If favoritism becomes an issue, we can
revisit. At that point, I'd imagine that there would be half-a-dozen books
on CloudStack and listing/not listing them won't make much difference --
so we could remove ALL books. We're not there yet.

At this point in time, it is appropriate to support such efforts.
--
Chiradeep

On 5/27/13 1:27 AM, "Sebastien Goasguen"  wrote:

>Hi,
>
>After a relatively long discussion on the marketing@ list about the
>"Packt Book" [1] I would like to call a vote.
>
>Proposal:
>
>I propose to list CloudStack related books on our website [2]. The page
>listing these books would contain the following disclaimer:
>
>"This listing does not represent official endorsement by the Apache
>CloudStack project. The Apache CloudStack project does not recommend one
>book versus another nor does it guarantee the quality of the books."
>
>Inclusion of a book in the listing would be done via a vote on the
>marketing@ list.
>
>
>As a quick summary, alternatives to this proposal were to:
>1-not do anything
>2-list the books on the wiki
>
>A few of us have already expressed their opinions and discussed the
>possibilities. Check [1].
>
>Vote will be open for 96 hours (To accommodate Memorial day in the USA).
>
>Reply with:
>
>[ ] +1  approve
>[ ] +0  no opinion
>[ ] -1  disapprove (and reason why)
>
>PS: If edits of the disclaimer are needed but that they do not change the
>meaning of it, the disclaimer will be modified but the vote will not be
>restarted.
>
>[1] http://markmail.org/thread/r4qdmbonmx6yq2uv
>[2] http://cloudstack.apache.org
>
>-Sebastien

Palo Alto Firewall Integration - Review Process

2013-05-28 Thread Will Stevens

Hey All,
I am getting close to finishing up this integration, so I want to make sure
I understand the process and what is required for submitting my code for
review.

I have read this and am comfortable with its content:
http://cloudstack.apache.org/develop/non-committer.html

You can check out more details regarding this integration here:
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Palo+Alto+Firewall+Integration

Please let me know if you feel I am missing anything on that page.  That is
still a work in progress, but it does cover the functionality being added
pretty well.  The screenshots are not complete yet, but they are at about
90% right now.

On that page I have linked a public repo which has a recent working version
of the code (not feature complete yet and still needs some clean up).

Here are the questions that I have about the process:
- Do I need to include tests for this code?  If so, is this documented
somewhere?  Since this is an integration with an external device, how would
tests be written to pass without actually connecting to a device?
- There is a small limitation in core which did not have any dependancies
which I have fixed (Sheng and I have discussed this briefly).  Basically, I
added support for multiple networks per account when the source nat type is
'per account' with an external device.  Question: Should I be submitting
two patches; one which only addresses this core fix (about 5 lines of code)
and one which addresses the addition of the palo_alto network plugin?  Or,
should I submit it all as one patch?
- Since this is an integration with a 3rd party product; should I setup
a publicly accessible system where the functionality can be reviewed, or
should I work with Palo Alto to get demo licenses for their VM firewall
appliances and provide the reviewers licences to test the functionality?  I
am not sure how this aspect should work, so let me know what the best
approach would be.

I think thats it.  Please let me know if something is not clear or if you
feel I need to flush out some of the details somewhere.

Thanks,

Will

Re: Regarding the RPS and RFS support in the virtual router.

The test is invalid -- it is only testing one core.
RPS steers the packet processing to a CPU core based on the hash of the
TCP/UDP 4-tuple in the header (src addr, dest addr, src port dst port).
With a single-stream test, the hash will send every packet to the same cpu

RFS is similarly based on the hash of the 4-tuple. The difference is that
the packets are steered to the CPU of the application thread that is
handling the flow.

Here's the guide on how to measure aggregate throughput:
 http://s.apache.org/EID


On 5/24/13 3:52 AM, "Bharat Kumar"  wrote:

>Hi All,
>
>I have enabled the RPS and RFS support in the router vm and performed
>some tests, but cloud not see any improvements.  If any one know about
>RPS (receive packet steering ) and RFS (receive flow steering ) please
>comment.  I am not sure if the RPS and RFS is working.
>
>The router has 4 cores and 4GB of ram.
>command used to enable rps
>echo f > /sys/class/net/eth0/queues/rx-0/rps_cpus
>commands used to enable rfs
>echo 1024 > /proc/sys/net/core/rps_sock_flow_entries
>echo 1024 > /sys/class/net/eth0/queues/rx-0/rps_flow_c
>
>kernel details
>Linux  3.2.0-4-686-pae #1 SMP Debian 3.2.35-2 i686 GNU/Linux
>
>The following are the test results
>Test Without rps
>--
>Testing with the following command line:
>/usr/bin/netperf -l 60  -H 10.147.28.149 -c -C   -t TCP_RR -i 700,3 -I
>99,5 -- -r 1,1 -s 0 -S 0
>
>TCP REQUEST/RESPONSE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to
>10.147.28.149 (10.147.28.149) port 0 AF_INET : +/-2.500% @ 99% conf.
>Local /Remote
>Socket Size   Request Resp.  Elapsed Trans.   CPUCPUS.dem   S.dem
>Send   Recv   SizeSize   TimeRate local  remote local   remote
>bytes  bytes  bytes   bytes  secs.   per sec  % S% Sus/Tr   us/Tr
>
>2048   2561   1  60.00   4280.98  16.30  4.06   38.081  37.977
>2048   2240
>
>Test With RPS
>--
>usr/bin/netperf -l 60  -H 10.147.28.149 -c -C   -t TCP_RR -i 700,3 -I
>99,5 -- -r 1,1 -s 0 -S 0
>TCP REQUEST/RESPONSE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to
>10.147.28.149 (10.147.28.149) port 0 AF_INET : +/-2.500% @ 99% conf.
>Local /Remote
>Socket Size   Request Resp.  Elapsed Trans.   CPUCPUS.dem   S.dem
>Send   Recv   SizeSize   TimeRate local  remote local   remote
>bytes  bytes  bytes   bytes  secs.   per sec  % S% Sus/Tr   us/Tr
>
>2048   2561   1  60.00   3926.40  14.47  3.68   37.093  37.561
>2048   2240
>
>Test with RPS and RFS
>--
>/usr/bin/netperf -l 60  -H 10.147.28.149 -c -C   -t TCP_RR -i 700,3 -I
>99,5 -- -r 1,1 -s 0 -S 0
>TCP REQUEST/RESPONSE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to
>10.147.28.149 (10.147.28.149) port 0 AF_INET : +/-2.500% @ 99% conf.
>Local /Remote
>Socket Size   Request Resp.  Elapsed Trans.   CPUCPUS.dem   S.dem
>Send   Recv   SizeSize   TimeRate local  remote local   remote
>bytes  bytes  bytes   bytes  secs.   per sec  % S% Sus/Tr   us/Tr
>
>2048   2561   1  60.00   3903.11  14.74  3.76   37.801  38.494
>2048   2240
>
>
>
>

Re: [VOTE] List CloudStack related books on the website

2013-05-28 Thread Noah Slater

Agree with the "we don't have to get this perfect right away" approach.


On 28 May 2013 18:17, Chiradeep Vittal  wrote:

> +1
>
> While I appreciate the don't-play-favorites sentiments, I do feel that we
> are over thinking this issue. If favoritism becomes an issue, we can
> revisit. At that point, I'd imagine that there would be half-a-dozen books
> on CloudStack and listing/not listing them won't make much difference --
> so we could remove ALL books. We're not there yet.
>
> At this point in time, it is appropriate to support such efforts.
> --
> Chiradeep
>
> On 5/27/13 1:27 AM, "Sebastien Goasguen"  wrote:
>
> >Hi,
> >
> >After a relatively long discussion on the marketing@ list about the
> >"Packt Book" [1] I would like to call a vote.
> >
> >Proposal:
> >
> >I propose to list CloudStack related books on our website [2]. The page
> >listing these books would contain the following disclaimer:
> >
> >"This listing does not represent official endorsement by the Apache
> >CloudStack project. The Apache CloudStack project does not recommend one
> >book versus another nor does it guarantee the quality of the books."
> >
> >Inclusion of a book in the listing would be done via a vote on the
> >marketing@ list.
> >
> >
> >As a quick summary, alternatives to this proposal were to:
> >1-not do anything
> >2-list the books on the wiki
> >
> >A few of us have already expressed their opinions and discussed the
> >possibilities. Check [1].
> >
> >Vote will be open for 96 hours (To accommodate Memorial day in the USA).
> >
> >Reply with:
> >
> >[ ] +1  approve
> >[ ] +0  no opinion
> >[ ] -1  disapprove (and reason why)
> >
> >PS: If edits of the disclaimer are needed but that they do not change the
> >meaning of it, the disclaimer will be modified but the vote will not be
> >restarted.
> >
> >[1] http://markmail.org/thread/r4qdmbonmx6yq2uv
> >[2] http://cloudstack.apache.org
> >
> >-Sebastien
>
>


-- 
NS

RE: [VOTE] Release Apache CloudStack 4.1.0 (fifth round)

2013-05-28 Thread Musayev, Ilya

+1 binding.

> -Original Message-
> From: Chip Childers [mailto:chip.child...@sungard.com]
> Sent: Tuesday, May 28, 2013 9:48 AM
> To: dev@cloudstack.apache.org
> Subject: [VOTE] Release Apache CloudStack 4.1.0 (fifth round)
> 
> Hi All,
> 
> I've created a 4.1.0 release, with the following artifacts up for a vote.
> 
> The changes from round 4 are related to DEB packaging, some translation
> strings, and a functional patch to make bridge type optional during the agent
> setup (for backward compatibility).
> 
> Git Branch and Commit SH:
> https://git-wip-
> us.apache.org/repos/asf?p=cloudstack.git;a=shortlog;h=refs/heads/4.1
> Commit: a5214bee99f6c5582d755c9499f7d99fd7b5b701
> 
> List of changes:
> https://git-wip-
> us.apache.org/repos/asf?p=cloudstack.git;a=blob_plain;f=CHANGES;hb=4.1
> 
> Source release (checksums and signatures are available at the same
> location):
> https://dist.apache.org/repos/dist/dev/cloudstack/4.1.0/
> 
> PGP release keys (signed using A99A5D58):
> https://dist.apache.org/repos/dist/release/cloudstack/KEYS
> 
> Testing instructions are here:
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Release+test+pr
> ocedure
> 
> 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)

Re: Question about Review Request

Mike - the problem is that you have two patches (2 commits) in the same
patch file.

Here's what to do (choose 1):

1) Squash down to 1 commit / patch and submit it.

OR

2) Create a review for the first patch, and then a follow up review for
the second patch.


On Mon, May 27, 2013 at 07:27:13PM -0600, Mike Tutkowski wrote:
> Yeah, I certainly agree with you, John.
> 
> Any thoughts on what I might do to make Review Board work in my situation?
> 
> I am new to Review Board and don't know why my patch file won't upload, but
> does apply to a new branch in my local repo.
> 
> Thanks!
> 
> 
> On Mon, May 27, 2013 at 7:24 PM, John Burwell  wrote:
> 
> > Mike,
> >
> > I would encourage Review Board as the first preference.  It provides a
> > good medium to review code and encourage other project members to
> > review patches, as well as, observe the review process.
> >
> > Thanks,
> > -John
> >
> >
> >
> >
> > On May 27, 2013, at 8:42 PM, Mike Tutkowski
> >  wrote:
> >
> > > Sounds good
> > >
> > > I have sent out an e-mail under the subject of "Patch File for Review
> > > (Storage Plug-in Related)".
> > >
> > > Thanks!
> > >
> > > I supposed we'll need to find out what wasn't working with Review Board
> > if
> > > my next patch has similar trouble. :)
> > >
> > >
> > > On Mon, May 27, 2013 at 6:24 PM, Chip Childers <
> > chip.child...@sungard.com>wrote:
> > >
> > >> Can you send the patch to the list as a txt attachment with a subject
> > >> line that indicates you want to have it reviewed and committed?
> > >> Perhaps we have to do this the old fashioned way.
> > >>
> > >> On May 27, 2013, at 7:46 PM, Mike Tutkowski
> > >>  wrote:
> > >>
> > >>> Regardless of those whitespace messages, it looks like my new branch
> > >>> (solidfire_plugin2) does have the changes in the patch file (they show
> > up
> > >>> as modified, but not staged files or - in the case of new files -
> > >> untracked
> > >>> files).
> > >>>
> > >>>
> > >>> On Mon, May 27, 2013 at 5:36 PM, Mike Tutkowski <
> > >>> mike.tutkow...@solidfire.com> wrote:
> > >>>
> >  Thanks for the reply, Sebastien!
> > 
> >  So, I went ahead and updated from upstream again and merged
> >  upstream/master to master, then merged master to solidfire_plugin.
> > 
> >  I created another patch file and tried to upload it to Review Board,
> > but
> >  received the same error message.
> > 
> >  I then tried to apply the patch file to a new branch, called
> >  solidfire_plugin2, that I created off of master.
> > 
> >  There was no error output when I did an apply --check, but when I
> > >> actually
> >  tried to apply the patch I received the following output (any
> > >> thoughts?):
> > 
> >  mtutkowski-LT:cloudstack mtutkowski$ git apply solidfire_plugin.patch
> >  solidfire_plugin.patch:66: trailing whitespace.
> > 
> >  solidfire_plugin.patch:68: trailing whitespace.
> > 
> >  solidfire_plugin.patch:70: trailing whitespace.
> > 
> >  solidfire_plugin.patch:72: trailing whitespace.
> > 
> >  solidfire_plugin.patch:74: trailing whitespace.
> > 
> >  warning: squelched 708 whitespace errors
> >  warning: 713 lines add whitespace errors.
> > 
> > 
> >  On Mon, May 27, 2013 at 1:45 AM, Sebastien Goasguen  > >>> wrote:
> > 
> > >
> > > On May 27, 2013, at 1:55 AM, Mike Tutkowski <
> > >> mike.tutkow...@solidfire.com>
> > > wrote:
> > >
> > >> Hi everyone,
> > >>
> > >> I'm trying to submit code for the first time.
> > >>
> > >> I'm following the instructions here:
> > >>
> > https://cwiki.apache.org/confluence/display/CLOUDSTACK/Review+Board+Guidelines
> > >>
> > >> When it says to upload my diff, I assume it means my .patch file. Is
> > > that
> > >> correct?
> > >>
> > >> I generate such a file this way:
> > >>
> > >> git format-patch upstream/master --stdout > solidfire_plugin.patch
> > >
> > > That should work. I usually just do:
> > > git format-patch master --stdout > my.patch
> > >
> > >> It works just fine, but when I try to upload it by clicking on the
> > > Create
> > >> Review Request button, I get the following error:
> > >>
> > >> The file
> > >>
> > 'plugins/hypervisors/xen/src/com/cloud/hypervisor/xen/resource/CitrixResourceBase.java'
> > >> (r5f45a62) could not be found in the repository
> > >> *
> > >> *
> > >
> > > Create a fresh branch out of your local master and try to see if your
> > > patch applies cleanly:
> > > git --check apply ( I think).
> > >
> > > Maybe it's a relative path issue (just a wild guess).
> > >
> > >
> > >> I'm not sure why it says this because this file is a part of the
> > >> current
> > >> repository.
> > >>
> > >> Would someone be able to explain what I might be doing wrong here?
> > >>
> > >> I did update from the ACS repo and merge i

Re: Question about Review Request

2013-05-28 Thread Mike Tutkowski

Thanks, Chip!

I didn't know that would be a problem.

If you know off hand, can you tell me how to do a squash?

Thanks again!


On Tue, May 28, 2013 at 11:51 AM, Chip Childers
wrote:

> Mike - the problem is that you have two patches (2 commits) in the same
> patch file.
>
> Here's what to do (choose 1):
>
> 1) Squash down to 1 commit / patch and submit it.
>
> OR
>
> 2) Create a review for the first patch, and then a follow up review for
> the second patch.
>
>
> On Mon, May 27, 2013 at 07:27:13PM -0600, Mike Tutkowski wrote:
> > Yeah, I certainly agree with you, John.
> >
> > Any thoughts on what I might do to make Review Board work in my
> situation?
> >
> > I am new to Review Board and don't know why my patch file won't upload,
> but
> > does apply to a new branch in my local repo.
> >
> > Thanks!
> >
> >
> > On Mon, May 27, 2013 at 7:24 PM, John Burwell 
> wrote:
> >
> > > Mike,
> > >
> > > I would encourage Review Board as the first preference.  It provides a
> > > good medium to review code and encourage other project members to
> > > review patches, as well as, observe the review process.
> > >
> > > Thanks,
> > > -John
> > >
> > >
> > >
> > >
> > > On May 27, 2013, at 8:42 PM, Mike Tutkowski
> > >  wrote:
> > >
> > > > Sounds good
> > > >
> > > > I have sent out an e-mail under the subject of "Patch File for Review
> > > > (Storage Plug-in Related)".
> > > >
> > > > Thanks!
> > > >
> > > > I supposed we'll need to find out what wasn't working with Review
> Board
> > > if
> > > > my next patch has similar trouble. :)
> > > >
> > > >
> > > > On Mon, May 27, 2013 at 6:24 PM, Chip Childers <
> > > chip.child...@sungard.com>wrote:
> > > >
> > > >> Can you send the patch to the list as a txt attachment with a
> subject
> > > >> line that indicates you want to have it reviewed and committed?
> > > >> Perhaps we have to do this the old fashioned way.
> > > >>
> > > >> On May 27, 2013, at 7:46 PM, Mike Tutkowski
> > > >>  wrote:
> > > >>
> > > >>> Regardless of those whitespace messages, it looks like my new
> branch
> > > >>> (solidfire_plugin2) does have the changes in the patch file (they
> show
> > > up
> > > >>> as modified, but not staged files or - in the case of new files -
> > > >> untracked
> > > >>> files).
> > > >>>
> > > >>>
> > > >>> On Mon, May 27, 2013 at 5:36 PM, Mike Tutkowski <
> > > >>> mike.tutkow...@solidfire.com> wrote:
> > > >>>
> > >  Thanks for the reply, Sebastien!
> > > 
> > >  So, I went ahead and updated from upstream again and merged
> > >  upstream/master to master, then merged master to solidfire_plugin.
> > > 
> > >  I created another patch file and tried to upload it to Review
> Board,
> > > but
> > >  received the same error message.
> > > 
> > >  I then tried to apply the patch file to a new branch, called
> > >  solidfire_plugin2, that I created off of master.
> > > 
> > >  There was no error output when I did an apply --check, but when I
> > > >> actually
> > >  tried to apply the patch I received the following output (any
> > > >> thoughts?):
> > > 
> > >  mtutkowski-LT:cloudstack mtutkowski$ git apply
> solidfire_plugin.patch
> > >  solidfire_plugin.patch:66: trailing whitespace.
> > > 
> > >  solidfire_plugin.patch:68: trailing whitespace.
> > > 
> > >  solidfire_plugin.patch:70: trailing whitespace.
> > > 
> > >  solidfire_plugin.patch:72: trailing whitespace.
> > > 
> > >  solidfire_plugin.patch:74: trailing whitespace.
> > > 
> > >  warning: squelched 708 whitespace errors
> > >  warning: 713 lines add whitespace errors.
> > > 
> > > 
> > >  On Mon, May 27, 2013 at 1:45 AM, Sebastien Goasguen <
> run...@gmail.com
> > > >>> wrote:
> > > 
> > > >
> > > > On May 27, 2013, at 1:55 AM, Mike Tutkowski <
> > > >> mike.tutkow...@solidfire.com>
> > > > wrote:
> > > >
> > > >> Hi everyone,
> > > >>
> > > >> I'm trying to submit code for the first time.
> > > >>
> > > >> I'm following the instructions here:
> > > >>
> > >
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Review+Board+Guidelines
> > > >>
> > > >> When it says to upload my diff, I assume it means my .patch
> file. Is
> > > > that
> > > >> correct?
> > > >>
> > > >> I generate such a file this way:
> > > >>
> > > >> git format-patch upstream/master --stdout >
> solidfire_plugin.patch
> > > >
> > > > That should work. I usually just do:
> > > > git format-patch master --stdout > my.patch
> > > >
> > > >> It works just fine, but when I try to upload it by clicking on
> the
> > > > Create
> > > >> Review Request button, I get the following error:
> > > >>
> > > >> The file
> > > >>
> > >
> 'plugins/hypervisors/xen/src/com/cloud/hypervisor/xen/resource/CitrixResourceBase.java'
> > > >> (r5f45a62) could not be found in the repository
> > > >> *
> > > >> *
> > > >
>

Re: Question about Review Request

On Tue, May 28, 2013 at 11:57:32AM -0600, Mike Tutkowski wrote:
> Thanks, Chip!
> 
> I didn't know that would be a problem.
> 
> If you know off hand, can you tell me how to do a squash?
> 
> Thanks again!

In your branch, do:

git rebase -i HEAD~2

You're editor will pull up something like the following:

pick 08c0f85 SolidFire plug-in and enhancements to the storage plug-in framework
pick 64a96fd Replaced hard-coded values with references to variable data

Change the second "pick" to "squash" if you want to combine commit
messages.  Change it to "fixup" if you just want to drop the second
commit's message.

Then do the format patch thing again and try to re-submit.

Re: Palo Alto Firewall Integration - Review Process

On Tue, May 28, 2013 at 01:32:48PM -0400, Will Stevens wrote:
> Hey All,
> I am getting close to finishing up this integration, so I want to make sure
> I understand the process and what is required for submitting my code for
> review.
> 
> I have read this and am comfortable with its content:
> http://cloudstack.apache.org/develop/non-committer.html
> 
> You can check out more details regarding this integration here:
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Palo+Alto+Firewall+Integration
> 
> Please let me know if you feel I am missing anything on that page.  That is
> still a work in progress, but it does cover the functionality being added
> pretty well.  The screenshots are not complete yet, but they are at about
> 90% right now.
> 
> On that page I have linked a public repo which has a recent working version
> of the code (not feature complete yet and still needs some clean up).

Thanks for doing that!

> 
> Here are the questions that I have about the process:
> - Do I need to include tests for this code?  If so, is this documented
> somewhere?  Since this is an integration with an external device, how would
> tests be written to pass without actually connecting to a device?

2 test types:

1 - unit tests using a mocking framework are needed for non-trivial
logic (complex methods)

2 - integration tests using the marvin framework are the best method of
providing automated testing of a specific integration.  However, you
might want to see if your functionality is *already* covered in the test
suite.  If you are only implementing a driver for a specific technology,
it might be easy to just play a set of tests against an environment with
that device enabled.

> - There is a small limitation in core which did not have any dependancies
> which I have fixed (Sheng and I have discussed this briefly).  Basically, I
> added support for multiple networks per account when the source nat type is
> 'per account' with an external device.  Question: Should I be submitting
> two patches; one which only addresses this core fix (about 5 lines of code)
> and one which addresses the addition of the palo_alto network plugin?  Or,
> should I submit it all as one patch?

Best to do it as 2.  Note in the new feature patch that it relies on the
"core" patch.

> - Since this is an integration with a 3rd party product; should I setup
> a publicly accessible system where the functionality can be reviewed, or
> should I work with Palo Alto to get demo licenses for their VM firewall
> appliances and provide the reviewers licences to test the functionality?  I
> am not sure how this aspect should work, so let me know what the best
> approach would be.

We don't have a good model for this.  Your demo license proposal sounds
interesting though.  Perhaps that's the model we *should* be using
whenever possible?

> 
> I think thats it.  Please let me know if something is not clear or if you
> feel I need to flush out some of the details somewhere.
> 
> Thanks,
> 
> Will

Re: [DISCUSS] portable IP vs public IP

On Tue, May 28, 2013 at 01:56:21PM +, Murali Reddy wrote:
> In CloudStack, currently there are four distinct operations available with
> public IP's at network service and manager layers.
> 
> 1. Acquiring a public IP from zone level public IP pool
> 2. Associate acquired public IP with a guest network/VPC
> 3. Disassociate an associated public IP with a guest network/VPC
> 4. Release acquired public IP
> 
> But at API, #1, #2 are rolled in to 'associateIpAddress' so an acquired
> public IP is always associated with a network. Similarly #3, #4 is rolled
> into 'disassociateIpAddress' API. Operations #2, #3 are not exposed
> through the API layer. So in effect,
> 
>   - Public IP are always need to be associated with a network/VPC
>   - Network rules for LB/PF/NAT etc expects that public IP is already
> associated with the network
>   - On network/VPC delete CloudStack implicitly releases acquired public
> IP's by the user.
>   - There is no way to transfer association of a public IP from a guest
> network/VPC to another guest network/VPC. This is commonly used pattern to
> mask the failures in AWS [2].
> 
> As part of the portable IP feature [1], I have relaxed these
> restriction for portable IP's. So an acquired portable IP need not be
> associated with a guest network/VPC always and association can be
> transferred across the networks. For e.g on acquired portable IP, when an
> user enables static NAT for a portable IP to VM1 in network1, disables
> static NAT to VM1 and then enables static NAT with VM2 in network2,
> CloudStack will implicitly transfers the association of the portable IP
> from network1 to network2.
> 
> What I want to bring to discussion is portability as characteristic of
> public IP vs special pool of public IP's. I have made portable IP's to be
> a region level resource, which enables portable IP's association be
> transferable across the networks in different zones of a region. But
> portability semantics can be implemented for zone level public IP as well,
> with restriction that association can be transferred across guest networks
> in same physical network of a zone. This seems to me an useful
> functionality to have for zone level public IP. I have extended
> 'associateIpAddress' API to specify a boolean flag 'is_portable' that
> indicates user is requesting a portable IP. In the current implementation
> this flag is interpreted as request for allocating region level public IP
> pool. If it make sense then I can relax this restriction with minimal
> change to indicate 'is_portable' as portable characteristics of public IP.
> So 'is_portable' flag can be used irrespective of region level or zone
> level public IP. And then introduce another flag to 'associateIpAddress'
> API, that explicitly requests that an IP  from region level pool should be
> allocated which by default can be moved across the networks from different
> zones in that region.

+1 to this proposal (with one concern noted below).

> 
> Effort I am proposing is to get API semantics right with minimal changes.
> I am not proposing to enable portability for zone level public Ip's for
> 4.2 but can be done for later release. Please comment.

Does it make sense to actually get the API for 4.2 to match this
proposal?  Once we release it, changing the meaning really means
breaking the contract, right?

> 
> [1]https://cwiki.apache.org/confluence/display/CLOUDSTACK/portable+public+I
> P
> [2]http://en.clouddesignpattern.org/index.php/CDP:Floating_IP_Pattern
> 
>

RE: master build breaks at com.cloud.vpc.NetworkACLServiceTest

2013-05-28 Thread Alex Huang

Unit tests are ran in random order because each unit test should be 
self-sufficient.  I'm saying I've seen cases where unit tests aren't written to 
be self-sufficient and that's why an unit test fails sometimes and passes 
sometimes.  

In those cases, we should fix the unit test and not the order.  A common 
problem is sharing the mocked classes.  For example, unit test A tests the set 
of a mock object and unit test B tests if the field is null but they shared the 
mock instance.  In this case, unit test B passes if it is ran before unit test 
A but fails if it was ran after.

But often times the randomness of how it's ran is actually pseudo-random so it 
works consistently on someone's laptop but as soon as it gets ran on another 
machine, the order changes and it fails.  So when you see the problem such as 
this, you should always let the unit test writer know the order in which the 
unit tests were executed so that the unit test writer can try it.

--Alex

> -Original Message-
> From: Daan Hoogland [mailto:dhoogl...@schubergphilis.com]
> Sent: Monday, May 27, 2013 9:23 AM
> To: dev@cloudstack.apache.org
> Subject: RE: master build breaks at com.cloud.vpc.NetworkACLServiceTest
> 
> And if not how do I manipulate the order of tests?
> 
> -Original Message-
> From: Daan Hoogland [mailto:dhoogl...@schubergphilis.com]
> Sent: maandag 27 mei 2013 17:02
> To: dev@cloudstack.apache.org
> Subject: RE: master build breaks at com.cloud.vpc.NetworkACLServiceTest
> 
> Alex,
> 
> Can this change out of the box? I had the problem on a clean checkout of
> master.
> 
> -Original Message-
> From: Alex Huang [mailto:alex.hu...@citrix.com]
> Sent: maandag 27 mei 2013 15:55
> To: dev@cloudstack.apache.org
> Subject: RE: master build breaks at com.cloud.vpc.NetworkACLServiceTest
> 
> Daan,
> 
> The other possibility is that the test is affected by another test so that it
> breaks when the tests are in a certain order.  Have you noticed what's the
> order of the tests ran when it breaks?
> 
> --Alex
> 
> > -Original Message-
> > From: Daan Hoogland [mailto:dhoogl...@schubergphilis.com]
> > Sent: Monday, May 27, 2013 2:37 AM
> > To: dev@cloudstack.apache.org
> > Subject: RE: master build breaks at
> > com.cloud.vpc.NetworkACLServiceTest
> >
> > Being in the habit of replying on my own mails as I seems to be on
> > this list;
> >
> > This seems to be related to eclipse refresh/build code. Does anybody
> > have a solution to it? The problem is not consistently present but all
> > the more irritating.
> >
> > Regards,
> >
> > -Original Message-
> > From: Daan Hoogland [mailto:dhoogl...@schubergphilis.com]
> > Sent: maandag 27 mei 2013 7:49
> > To: dev@cloudstack.apache.org
> > Subject: master build breaks at com.cloud.vpc.NetworkACLServiceTest
> >
> > LS,
> >
> > Lately I've been getting,
> > "com.cloud.exception.InvalidParameterValueException: ACL item with
> > number 1 already exists in ACL: null", while building cloudstack. I
> > first thought it was my own hack so I don't know when it was
> > introduced (it is in a clean master that it happens). The full surfire 
> > report
> follows:
> >
> > --
> > - Test set: com.cloud.vpc.NetworkACLServiceTest
> > --
> > - Tests run: 5, Failures: 0, Errors: 1, Skipped: 0, Time
> > elapsed: 0.219 sec <<< FAILURE!
> > testCreateACLItem(com.cloud.vpc.NetworkACLServiceTest)  Time elapsed:
> > 0.016 sec  <<< ERROR!
> > com.cloud.exception.InvalidParameterValueException: ACL item with
> > number 1 already exists in ACL: null
> > at
> >
> com.cloud.network.vpc.NetworkACLServiceImpl.createNetworkACLItem(Ne
> > tworkACLServiceImpl.java:270)
> > at
> >
> com.cloud.vpc.NetworkACLServiceTest.testCreateACLItem(NetworkACLServ
> > iceTest.java:141)
> > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> > at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
> > at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown
> > Source)
> > at java.lang.reflect.Method.invoke(Unknown Source)
> > at
> >
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(Framework
> > Method.java:45)
> > at
> > org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCall
> > able.jav
> > a:15)
> > at
> > org.junit.runners.model.FrameworkMethod.invokeExplosively(Framework
> > Method.java:42)
> > at
> >
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMeth
> > od.java:20)
> > at
> > org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.j
> > ava
> > :28)
> > at
> >
> org.springframework.test.context.junit4.statements.RunBeforeTestMethod
> > Callbacks.evaluate(RunBeforeTestMethodCallbacks.java:74)
> > at
> >
>

Re: [DISCUSS] Should we be releasing -beta releases?

2013-05-28 Thread Noah Slater

Sebastien,

Nope, we don't do votes on the users@ list. That list is just for user
support.

Decision making happens on dev@*, and if users want to take part in that,
they can subscribe.

* Or marketing@, private@, and security@


On 27 May 2013 08:53, Sebastien Goasguen  wrote:

>
> On May 24, 2013, at 12:26 PM, Chip Childers 
> wrote:
>
> > On Tue, May 14, 2013 at 10:41:30AM -0400, Chip Childers wrote:
> >> As a way to get more user feedback on our major feature releases, what
> >> does everyone think about releasing one or two -beta releases for each
> >> major feature release?
> >>
> >> This might fall in line with some of the stated concerns about our
> >> release schedule (see [1]).  I've stated a desire to be quicker about
> >> our releases (my vote was 4 months).  I've also been saying quite
> >> publicly that we should never release if we know about upgrade issues
> >> (that's the cost of having actual users of our project, which I'm more
> >> than willing for us to pay).
> >>
> >> Perhaps -betaX releases would be helpful to get attention from the users
> >> to test the release (including upgrade paths).  The stated assumption
> >> could be: -beta releases are not releases that can be upgraded *from*,
> >> but are intended to help support testing by end users that want to check
> >> the upcoming release against their expected feature set and upgrade
> >> path.
> >>
> >> I would see the first -beta-1 being released about 1 month after feature
> >> freeze.  For example, for 4.2.0, it would be on 2013-06-30.  I would
> >> only do a -beta-2 (or later) beta release if required due to testing
> >> results.  I would also suggest that the -beta-* releases would *not*
> >> have any particular quality criteria (well...  perhaps minimal, like
> >> blocking on issues that fundamentally make the software unstable).
> >>
> >> I'm not sure about my own proposal here, but I wanted to throw it out
> >> and see if any of you have feedback / thoughts.
> >>
> >> -chip
> >>
> >> [1] http://markmail.org/message/3ctdwor5hfbpa3vx
> >
> > To summarize the discussions of this thread:
> >
> > 1) The idea of ensuring that we get user testing of release candidates
> > is one that most agree with.
> >
> > 2) Concerns were raised about the overhead of "officially" releasing
> > beta releases, especially if there is any expectation that there would
> > be an upgrade path from a -beta to an official release.
> >
> > I'd like to simplify this by saying that we should actually plan on
> > announcing the start of each round of voting on RC's to the users@ list.
> > We can get feedback from them on each round.
>
> Why don't we include users@ in the voting thread in the first place ?
> The entire community can vote, correct ? committers and non-committers.
>
> Asking @users for feedback make it sound a little bit like feedback is
> welcome but not voting.
>
> > And while I don't really
> > love having a bunch of rounds of voting, 4.1.0 has basically proven that
> > user engagement testing the RC's is critical.  I think that we might
> > also consider (at a release manager's discretion) periodically
> > announcing a request for testing of the feature branch's code during the
> > QA part of our release cycles.
>
> +1
>
> >
> > Shout if you disagree.
>
>


-- 
NS

Re: [ACS42] Release Status Update - 9 days left to freeze

I would also like to close on the development of the systemvm. AFAIK, it
has been undergoing  some level of validation. It is desirable to 'freeze'
the bits of the system vm image as early as possible.
The only 'unfreeze' I anticipate is when HAProxy returns to wheezy. As of
today the system vm contains HAProxy from squeeze-oldstable[1]. I see that
the amd64 bits have been built for wheezy [2], but until the i386 packages
are built, I'll hold off on updating the build scripts.

[1] https://issues.apache.org/jira/browse/CLOUDSTACK-2324
[2] http://packages.debian.org/wheezy-backports/haproxy

On 5/22/13 3:24 PM, "Animesh Chaturvedi" 
wrote:

>Folks
>
>We are 9 days from ACS 42 feature freeze
>
>Out of 98 proposed features /improvements, the status is
>
>Closed: 5
>Resolved: 33
>In Progress: 15
>Reopened: 1:
>Ready to  review:  2
>Open: 42
>
>We have not made much progress in updating the tickets last week. Given
>that we are just a few days away from feature freeze and that there are
>large number of open items, please  take a moment to update your tickets.
>If you are not going to make to the feature freeze date please mark them
>out of 4.2 in JIRA and Wiki
>
>As for bugs here is a summary
>
>--
>--
>   This Week   ||  
> Last Week
>--
>--
>Incoming Defects   :   4 b |  8 c | 28 m   | 45 t  ||  
> 7 b |  19 c | 38
>m   | 74 t 
>--
>--
>Outgoing Defects   :   17 b|  26 c | 27 m   | 73 t ||  11 b|  
>18 c | 23 m
>| 55 t
>--
>--
>Open Unassigned:3b | 20 c | 82 m| 124 t||  2b | 19 
>c | 72 m|
>110 t
>--
>-
>Open Total :   12 b | 44 c | 149 m | 238 t ||  13 b | 
>53 c | 142 m | 237 t
>--
>-
>
>Legend : Blocker (b)  | Critical (c) | Major (m) | Total (t)
>
>There is good progress on fixing defects.
>
>We have a large number of unassigned and open defects, If you are
>interested in helping out on defects please check the release dashboard
>widget on issues by components  http://s.apache.org/M5k
>
>Animesh
>
>

Re: Unsupported System VM OS Debian 7.0 Wheezy on xenserver 6.1

I guess the question would be "why do you want xs-tools on the system vm"?
Other than xs tools, Debian wheezy should work just fine on XS 6.1

As a point of reference, Debian squeeze wasn't supported on XS 5.6 (the
first release on which the "old" system vm was deployed) either and worked
just fine.

Wheezy was GA just a month ago, XS 6.1 was GA over 6 months ago, so it
isn't surprising.

There's a tweak mentioned at the bottom of this blog post:
http://xenhelp.blogspot.com/2012/05/debian-wheezy-on-xenserverxcp.html

--
Chiradeep

On 5/28/13 3:12 AM, "Harikrishna Patnala" 
wrote:

>Hi all,
>
>I tried installing xs-tools on system vm but I could not able to do that
>because we use Debain 7.0 Wheezy which is not supported by Xenserver 6.1
>
>Detected `Debian 7.0' (debian version 7).
>
>Unable to install guest packages for distribution
>Debian 7.0 (debian).
>
>Unknown Debian variant "7" ""
>
>Why we are using Debian 7.0 for System VMs which does not have support on
>Xen ? This may result in stability issues of VM.
>Is there any specific reason for Using Debian 7.0 why not Debian 6.0
>Squeeze ? If yes is there any work around to install Xen-tools ?
>
>Thank you
>
>
>

Re: 4.1 release manager

On Tue, May 28, 2013 at 04:18:51PM +, Musayev, Ilya wrote:
> I will tentatively say yes - pending my discussion with Chip on Thursday on 
> the process.

Outback - if you want to help, that's still a possibility (see my note
about how you could help).

Ilya has the commit-bit, so he can be the "official" RM (assuming that I
can talk him into it).

And this brings up a good point about documentation...  we have the
formal "steps" documented for cutting a release on the wiki, but little
to no docs on how to do the softer side.

-chip

Re: [MERGE]object_store branch into master

On Tue, May 28, 2013 at 11:42:56AM -0400, John Burwell wrote:
> All,
> 
> I have gone a through a large chunk of this patch, and published my review 
> thus far (https://reviews.apache.org/r/11277/).   TL;DR is that this patch 
> has a number of significant issues which can be summarized as follows:
> 
> 1. While it appeas that the requirement of NFS for secondary storage has 
> largely been removed, it has basically been if blocked out instead of pushed 
> down as an detail choice in the physical layer.  Rather than exploiting 
> polymorpish to vary behavior through a set of higher level abstracttions, the 
> orchestration performs instanceof NFSTO checks. The concern is that future 
> evolution of secondary storage layer will still have dependencies on NFS.
> 
> 2. In some sceanrios, NFS is still a requirement for secondary storage.  In 
> particular, Xen users will still have to maintain an "NFS cache".  Given the 
> degradation of capability, I think it would be helpful to put a few more 
> eyeballs on the Xen implementation to determine if we could avoid using an 
> intermediate file system.
> 
> 3. I have the following concerns regarding potential race conditions and 
> resource exhaustion in the NFS cache implementation.  
> 
> - The current random allocator algorithm does not account for the amount 
> space that will be required for the operation (i.e. checking to ensure that 
> the cache it picks has enough space to transfer to hold the object being 
> downloaded) nor does it reserve the space.Given the long (in compute time) 
> running nature of these of processes, the available space in a cache could be 
> exhausted by a number of concurrently transfering templates and/or snapshots. 
>  By reserving space before the transfer, the allocator would be able to 
> account for both pending operations and the current contents of the cache.
> - There appears no mechanism to age out contents of the cache.  
> Therefore, as implemented, it will grow unbounded.  The only workaround for 
> this problem would be to have an NFS cache whose size equals that of the 
> object store.  
> - The mechanism lacks robust error handling or retry logic.  In 
> particular, the behavior if/when a cache exhausts available space appears 
> non-deterministic.
> - Generally, I see little consideration for alternative/exception flows.  
> For example, what happens if I attempt to use a template/iso/snapshot in 
> transit to the object store to/from the cache?  Since these files can be very 
> large (multiple GBs), we have assume some transfer latency in all 
> interactions.
> 
> 4. The Image Cache abstraction is too tightly coupled to the core 
> orchestration mechanism.  I would recommend implementing it as a DataStore 
> proxy that is applied as necessary.  For example, the current Xen hypervisor 
> implementation must interact with a file system.  It seems most appropriate 
> that the Xen hypervisor implementation would apply the proxy to its secondary 
> storage DataStore instances.  Therefore, the storage engine should only 
> provide the facility not attempt to determine when it is needed.  
> Additionally, a proxy model would greatly reduce the size and complexity of 
> the various classes (e.g. AncientDataMotionStrategy).
> 
> 5. While I have only reviewed roughly 50-60% of the patch thus far, I see 
> little to no additional unit tests for the new code added.  Integration tests 
> have been expanded, but many of the test simply execute the service methods 
> and do not verify the form of the operation results. There are also a 
> tremendous number of ignored exceptions that should likely fail these tests.  
> Therefore, we could have tests passing due to an ignored exception that 
> should be failing.
> 
> While I recognize the tremendous effort that has been expended to implement 
> this capability and value of the feature, I see significant design and 
> operational issues that must be addressed before it can be accepted into 
> master.  In my opinion, the object_store represents a good first step, but it 
> needs a few more review/refinement iterations before it will be ready for a 
> master merge.
> 
> Thanks,
> -John

IMO, at a minimum, John's comments above (and items noted in reviewboard) 
should be addressed / discussed before any merge occurs.

Re: [GSOC] Five projects accepted for 2013 Google Summer of Code

2013-05-28 Thread Rohit Yadav

On Tue, May 28, 2013 at 6:49 PM, Chip Childers wrote:

> On Tue, May 28, 2013 at 10:53:47AM +0530, Rohit Yadav wrote:
> > On Tue, May 28, 2013 at 12:53 AM, Sebastien Goasguen  >wrote:
> >
> > > Hi,
> > >
> > > I am pleased to report that the following projects have been accepted
> by
> > > the 2013 Google Summer of Code:
> > >
> > > "CloudStack: LDAP user provisioning", Ian Duffy
> > >
> > > "Improving CloudStack support in Apache Whirr and Apache Provisionr
> > > incubating", Meng Han
> > >
> > > "Integration project to deploy and use Apache Mesos on a CloudStack
> based
> > > Cloud" Dharmesh Kakadia
> > >
> > > "A New Modular UI for Apache CloudStack" Shiva Teja Reddy
> > >
> > > "Add Xen/XCP support for GRE SDN Controller" Nguyen Anh Tu
> > >
> > > Join me in congratulating all five and welcoming them to the Apache
> > > CloudStack community this summer.
> > >
> >
> > Congrats everyone and welcome to the Apache CloudStack community once
> again.
> >
> >
> > > Abhi, Kelcey, Hugo and Myself will be their mentors but if you see
> > > questions from any of these five students feel free to jump in and help
> > > them out.
> > >
> >
> > While these good folks may be officially your mentors, feel free to
> > reachout to the community anytime. Your mentors, admin will guide you
> well,
> > but one advise from my side is that you all develop your work in open
> from
> > the beginning, for example start by forking the github branches and share
> > your repos/branch on which you'll be working on with the community on
> > dev@email.
>
> I think that the github mirror may still be behind due to our graduation
> infra changes.  It's best to push to a new repo, from a local clone of
> the canonical ASF repo.
>

Hey Chip, we had created tickets on infra and now we've a new github mirror
which is up to date: https://github.com/apache/cloudstack
They somehow did not get rid of the incubator-cloudstack/ repo on github
which is very behind.

Cheers.

Re: [GSOC] Five projects accepted for 2013 Google Summer of Code

On Wed, May 29, 2013 at 12:58:07AM +0530, Rohit Yadav wrote:
> 
> Hey Chip, we had created tickets on infra and now we've a new github mirror
> which is up to date: https://github.com/apache/cloudstack
> They somehow did not get rid of the incubator-cloudstack/ repo on github
> which is very behind.
> 
> Cheers.

Woot!  I missed that.  Thanks Rohit!

Re: [VOTE] List CloudStack related books on the website

2013-05-28 Thread Rohit Yadav

Just my view: Lobbying is something we should avoid from what I understand
from the Apache culture. This is not to flame anybody or anything, I've
recognized may be the issue is in me; sorry but I've very strong sentiments
and emotions around opensource software development, I've decreased my
contributions, left my last job which was emotionally scaring me among
other things and threads like these just boils my blood, please just avoid
ugliness :)

And the argument that we don't have to get this perfect right away, meh,
just does not apply; should we be doing something that is fundamentally
wrong? I know a lot of people like lobbying and practice it, maybe no one
is wrong.

Just saying.
Peace.

On Tue, May 28, 2013 at 11:07 PM, Noah Slater  wrote:

> Agree with the "we don't have to get this perfect right away" approach.
>
>
> On 28 May 2013 18:17, Chiradeep Vittal 
> wrote:
>
> > +1
> >
> > While I appreciate the don't-play-favorites sentiments, I do feel that we
> > are over thinking this issue. If favoritism becomes an issue, we can
> > revisit. At that point, I'd imagine that there would be half-a-dozen
> books
> > on CloudStack and listing/not listing them won't make much difference --
> > so we could remove ALL books. We're not there yet.
> >
> > At this point in time, it is appropriate to support such efforts.
> > --
> > Chiradeep
> >
> > On 5/27/13 1:27 AM, "Sebastien Goasguen"  wrote:
> >
> > >Hi,
> > >
> > >After a relatively long discussion on the marketing@ list about the
> > >"Packt Book" [1] I would like to call a vote.
> > >
> > >Proposal:
> > >
> > >I propose to list CloudStack related books on our website [2]. The page
> > >listing these books would contain the following disclaimer:
> > >
> > >"This listing does not represent official endorsement by the Apache
> > >CloudStack project. The Apache CloudStack project does not recommend one
> > >book versus another nor does it guarantee the quality of the books."
> > >
> > >Inclusion of a book in the listing would be done via a vote on the
> > >marketing@ list.
> > >
> > >
> > >As a quick summary, alternatives to this proposal were to:
> > >1-not do anything
> > >2-list the books on the wiki
> > >
> > >A few of us have already expressed their opinions and discussed the
> > >possibilities. Check [1].
> > >
> > >Vote will be open for 96 hours (To accommodate Memorial day in the USA).
> > >
> > >Reply with:
> > >
> > >[ ] +1  approve
> > >[ ] +0  no opinion
> > >[ ] -1  disapprove (and reason why)
> > >
> > >PS: If edits of the disclaimer are needed but that they do not change
> the
> > >meaning of it, the disclaimer will be modified but the vote will not be
> > >restarted.
> > >
> > >[1] http://markmail.org/thread/r4qdmbonmx6yq2uv
> > >[2] http://cloudstack.apache.org
> > >
> > >-Sebastien
> >
> >
>
>
> --
> NS
>

Re: Update on Hyper-V plugin work

On Mon, May 27, 2013 at 04:38:23PM +, Donal Lafferty wrote:
>  Hi Chip,
> 
> Thanks for clarifying the IP info required.  I'll take a closer look ASAP.

Awesome, thanks!

> Citrix have provided some effort for a suitable console proxy, which needs to 
> be integrated into the System VM.  (Volunteers?)

Where is this effort available (so that folks know what it means to do
the integration)?

-chip

[MERGE] zone wide primary storage support for VMware into MASTER

2013-05-28 Thread Sateesh Chodapuneedi

Hi,

I would like to merge support for zone wide primary storage for VMware 
resources in CloudStack deployment. This is incremental piece of work to extend 
zone wide primary storage pool support to VMware. 
Earlier zone wide primary storage support was merged into master as part of 
JIRA ticket CLOUDSTACK-724. This is extended further to support VMware 
hypervisor as well.
 
This feature updates DatastoreLifeCycle to consider hypervisor type while 
attaching datastore to zone. This feature uses same framework that's laid out 
as part of zone wide primary storage pool support for KVM. Code for this 
feature conforms to what was proposed in FS [1]. Implementation is done in 
branch [2] up for review. ZoneWideStoragePoolAllocator would filter zone wide 
primary storage pools by hypervisor type along with tags in disk profile. 
Hypervisor type is mandatory parameter if scope is specified as ZONE while 
creating primary storage pool. KVM, VMware are enabled to use 
ZoneWideStoragePoolAllocator.
Please take a look at it and let me know your comments.

Merge check list :-

* Did you check the branch's RAT execution success?
Yes

* Are there new dependencies introduced?
No

* What automated testing (unit and integration) is included in the new feature?
Unit/integration tests are already merged into master as part of CLOUDSTACK-724 
to test zone wide primary resource pool functionality.
Marvin tests are submitted at review board by Talluri. Link - 
https://reviews.apache.org/r/11462/

* What testing has been done to check for potential regressions?
I've tested following cases manually,
1) Creation of zone wide primary storage where zone has multiple clusters
2) Add a cluster to existing zone which already have a zone wide primary storage
3) Deploy VM on zone wide primary storage by using storage pool tags.
4) Detach data disk from VM which was provisioned on zone wide primary storage
5) Attach data disk to a VM on another cluster
6) Delete volume which was provisioned on zone wide primary storage

If there is no objection, I would merge the branch in 72 hours.

Regards,
Sateesh

[1] 
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Zone-wide+primary+storage+target
[2] refs/heads/zone-primarystorage-vmware
[3] https://issues.apache.org/jira/browse/CLOUDSTACK-2029

vhd-util missing in 4.2 snapshot?

2013-05-28 Thread La Motta, David

Hey everybody, I downloaded a 4.2 snapshot today and have been trying to get it 
going without much luck.  I got an error about systemvm.iso not being found, so 
I manually copied it to the problem spot from a 4.1 tree I have laying around.  
However, vhd-util is not found, and I am getting a scopeundefined error as you 
can see.  The sequence of steps I am running to get CS going are:

mvn -e -Dmaven.test.skip=true -P developer clean install
mvn -e -Dmaven.test.skip=true -P developer -pl developer,tools/devcloud 
-Ddeploydb
mvn -e -pl :cloud-client-ui jetty:run

Any ideas off the cuff from anyone?


[cid:8C6EEF88-2DB6-48F7-8CBA-FC8214BAAD8A@hq.netapp.com]


David La Motta
Technical Marketing Engineer - Citrix

NetApp
919.476.5042
dlamo...@netapp.com

Re: Palo Alto Firewall Integration - Review Process

2013-05-28 Thread Will Stevens

Thanks for the reply Chip.  Are there any docs / guides for the test
functionality?


On Tue, May 28, 2013 at 2:07 PM, Chip Childers wrote:

> On Tue, May 28, 2013 at 01:32:48PM -0400, Will Stevens wrote:
> > Hey All,
> > I am getting close to finishing up this integration, so I want to make
> sure
> > I understand the process and what is required for submitting my code for
> > review.
> >
> > I have read this and am comfortable with its content:
> > http://cloudstack.apache.org/develop/non-committer.html
> >
> > You can check out more details regarding this integration here:
> >
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Palo+Alto+Firewall+Integration
> >
> > Please let me know if you feel I am missing anything on that page.  That
> is
> > still a work in progress, but it does cover the functionality being added
> > pretty well.  The screenshots are not complete yet, but they are at about
> > 90% right now.
> >
> > On that page I have linked a public repo which has a recent working
> version
> > of the code (not feature complete yet and still needs some clean up).
>
> Thanks for doing that!
>
> >
> > Here are the questions that I have about the process:
> > - Do I need to include tests for this code?  If so, is this documented
> > somewhere?  Since this is an integration with an external device, how
> would
> > tests be written to pass without actually connecting to a device?
>
> 2 test types:
>
> 1 - unit tests using a mocking framework are needed for non-trivial
> logic (complex methods)
>
> 2 - integration tests using the marvin framework are the best method of
> providing automated testing of a specific integration.  However, you
> might want to see if your functionality is *already* covered in the test
> suite.  If you are only implementing a driver for a specific technology,
> it might be easy to just play a set of tests against an environment with
> that device enabled.
>
> > - There is a small limitation in core which did not have any dependancies
> > which I have fixed (Sheng and I have discussed this briefly).
>  Basically, I
> > added support for multiple networks per account when the source nat type
> is
> > 'per account' with an external device.  Question: Should I be submitting
> > two patches; one which only addresses this core fix (about 5 lines of
> code)
> > and one which addresses the addition of the palo_alto network plugin?
>  Or,
> > should I submit it all as one patch?
>
> Best to do it as 2.  Note in the new feature patch that it relies on the
> "core" patch.
>
> > - Since this is an integration with a 3rd party product; should I setup
> > a publicly accessible system where the functionality can be reviewed, or
> > should I work with Palo Alto to get demo licenses for their VM firewall
> > appliances and provide the reviewers licences to test the functionality?
>  I
> > am not sure how this aspect should work, so let me know what the best
> > approach would be.
>
> We don't have a good model for this.  Your demo license proposal sounds
> interesting though.  Perhaps that's the model we *should* be using
> whenever possible?
>
> >
> > I think thats it.  Please let me know if something is not clear or if you
> > feel I need to flush out some of the details somewhere.
> >
> > Thanks,
> >
> > Will
>

Re: Palo Alto Firewall Integration - Review Process

On Tue, May 28, 2013 at 04:31:27PM -0400, Will Stevens wrote:
> Thanks for the reply Chip.  Are there any docs / guides for the test
> functionality?

Yup:
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Marvin+-+Testing+with+Python

4.0.2 nonoss , can't connect to vsphere

2013-05-28 Thread Andrew White

As suggested on the user@ forum, i'm posting here.

Hi,  I built 4.0.2 on centos 6.4, and worked my way through the issues.

I think I have correctly created the rpms required to integrate with
netscaler and vsphere.  However when I try to connect to vsphere I get an
error '431 Could not find corresponding resource manager for VMware'

I used this file to create the RPM's and notice it's missing the
vmware-vim.jar vmware-vim25 and vmware-apputils jar are also missing, I
just added them by hand
http://people.apache.org/~jzb/cloudstack/dist/releases/4.0.2/nonoss.cloud.spec

I get no build errors at all, specifically successes
[INFO] Apache CloudStack Plugin - Hypervisor VMware .. SUCCESS [0.406s]

I have seen threads such as
http://mail-archives.apache.org/mod_mbox/incubator-cloudstack-dev/201301.mbox/%3ccd25c55e.5994%25mdfsdfsdfsdfin.c...@citrix.com%3E

but can't see the mentioned files in WEB-INF or find the relevant
components-nonoss.xml.

my entire history of build commands are below from a minimal install of
centos6.4



/etc/init.d/iptables stop
yum groupinstall "Development Tools"
yum install unzip createrepo ws-commons-util wget
java-1.6.0-openjdk-devel.x86_64 ant ant-jdepend genisoimage mysql
mysql-server ws-common-utils MySQL-python tomcat6 httpd.x86_64

wget
http://ftp.heanet.ie/mirrors/www.apache.org/dist/maven/maven-3/3.0.5/binaries/apache-maven-3.0.5-bin.tar.gz
tar -zxvf apache-maven-3.0.5-bin.tar.gz
mv apache-maven-3.0.5 /usr/local/
export PATH=/usr/local/apache-maven-3.0.5/bin:$PATH

wget
http://www.us.apache.org/dist/cloudstack/4.0.2/apache-cloudstack-4.0.2-src.tar.bz2
bunzip2 apache-cloudstack-4.0.2-src.tar.bz2
tar -xvf apache-cloudstack-4.0.2-src.tar
cd apache-cloudstack-4.0.2-src/deps

wget http://zooi.widodh.nl/cloudstack/build-dep/cloud-iControl.jar
wget http://zooi.widodh.nl/cloudstack/build-dep/cloud-manageontap.jar
wget http://zooi.widodh.nl/cloudstack/build-dep/vmware-vim.jar
wget http://zooi.widodh.nl/cloudstack/build-dep/vmware-vim25.jar
wget http://zooi.widodh.nl/cloudstack/build-dep/vmware-apputils.jar
wget
http://community.citrix.com/download/attachments/37847122/cloud-netscaler-jars.zip
unzip cloud-netscaler-jars.zip

#now we are ready, lets build
./install-non-oss.sh
cd ../vmware-base/
mvn install
cd ..
mvn -D nonoss -P deps
wget
http://people.apache.org/~jzb/cloudstack/dist/releases/4.0.2/nonoss.cloud.spec
cp nonoss.cloud.spec cloud.spec

#Build RPM's and share as repo
./waf rpm
cd artifacts/rpmbuild/RPMS/x86_64
createrepo ./



The server is built using the above repo with;
yum install cloud-server cloud-client

Thanks

Andrew

Re: Palo Alto Firewall Integration - Review Process

2013-05-28 Thread Will Stevens

Thank you...


On Tue, May 28, 2013 at 4:33 PM, Chip Childers wrote:

> On Tue, May 28, 2013 at 04:31:27PM -0400, Will Stevens wrote:
> > Thanks for the reply Chip.  Are there any docs / guides for the test
> > functionality?
>
> Yup:
>
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Marvin+-+Testing+with+Python
>

Re: vhd-util missing in 4.2 snapshot?

2013-05-28 Thread La Motta, David

Here is the stack trace:


WARN  [xen.resource.CitrixResourceBase] (DirectAgent-1:) We cannot locate 
/home/dlamotta/Dev/cloudstack-4.2-cfd8056/client/target/cloud-client-ui-4.2.0-SNAPSHOT/WEB-INF/classes/scripts/vm/hypervisor/xenserver/xenserver60/../vhd-util
INFO  [network.security.SecurityGroupListener] (820276628@qtp-1418920064-7:) 
Received a host startup notification
INFO  [network.security.SecurityGroupListener] (820276628@qtp-1418920064-7:) 
Scheduled network rules cleanup, interval=1999
INFO  [network.security.SecurityGroupListener] (820276628@qtp-1418920064-7:) 
Received a host startup notification
WARN  [xen.resource.CitrixResourceBase] (DirectAgent-5:) Unable to create local 
link network
The server failed to handle your request, due to an internal error.  The given 
message may give details useful for debugging the problem.
at com.xensource.xenapi.Types.checkResponse(Types.java:1694)
at com.xensource.xenapi.Connection.dispatch(Connection.java:368)
at 
com.cloud.hypervisor.xen.resource.XenServerConnectionPool$XenServerConnection.dispatch(XenServerConnectionPool.java:909)
at com.xensource.xenapi.VIF.plug(VIF.java:846)
at 
com.cloud.hypervisor.xen.resource.CitrixResourceBase.setupLinkLocalNetwork(CitrixResourceBase.java:4825)
at 
com.cloud.hypervisor.xen.resource.CitrixResourceBase.execute(CitrixResourceBase.java:3321)
at 
com.cloud.hypervisor.xen.resource.CitrixResourceBase.executeRequest(CitrixResourceBase.java:480)
at 
com.cloud.hypervisor.xen.resource.XenServer56Resource.executeRequest(XenServer56Resource.java:73)
at 
com.cloud.hypervisor.xen.resource.XenServer610Resource.executeRequest(XenServer610Resource.java:102)
at 
com.cloud.agent.manager.DirectAgentAttache$Task.run(DirectAgentAttache.java:186)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at 
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178)
at 
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:722)
INFO  [cloud.resource.ResourceManagerImpl] (820276628@qtp-1418920064-7:) server 
resources successfully discovered by XCP Agent
INFO  [cloud.api.ApiServer] (820276628@qtp-1418920064-7:) invalid scopeundefined



David La Motta
Technical Marketing Engineer - Citrix

NetApp
919.476.5042
dlamo...@netapp.com



On May 28, 2013, at 4:20 PM, "La Motta, David" 
mailto:david.lamo...@netapp.com>>
 wrote:

Hey everybody, I downloaded a 4.2 snapshot today and have been trying to get it 
going without much luck.  I got an error about systemvm.iso not being found, so 
I manually copied it to the problem spot from a 4.1 tree I have laying around.  
However, vhd-util is not found, and I am getting a scopeundefined error as you 
can see.  The sequence of steps I am running to get CS going are:

mvn -e -Dmaven.test.skip=true -P developer clean install
mvn -e -Dmaven.test.skip=true -P developer -pl developer,tools/devcloud 
-Ddeploydb
mvn -e -pl :cloud-client-ui jetty:run

Any ideas off the cuff from anyone?




David La Motta
Technical Marketing Engineer - Citrix

NetApp
919.476.5042
dlamo...@netapp.com

Re: vhd-util missing in 4.2 snapshot?