Re: Review Request 15323: CLOUDSTACK-5080: Hypervisor Capabilities table missing entry for Simulator

2013-11-11 Thread ASF Subversion and Git Services

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


Commit dfb81ac1274d8ebe4a47223d10f3de44aa9091bf in branch refs/heads/master 
from David Grizzanti
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=dfb81ac ]

CLOUDSTACK-5080: Hypervisor Capabilities table missing entry for Simulator

Signed-off-by: Prasanna Santhanam 


- ASF Subversion and Git Services


On Nov. 7, 2013, 8:31 p.m., David Grizzanti wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/15323/
> ---
> 
> (Updated Nov. 7, 2013, 8:31 p.m.)
> 
> 
> Review request for cloudstack.
> 
> 
> Bugs: CLOUDSTACK-5080
> https://issues.apache.org/jira/browse/CLOUDSTACK-5080
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> CLOUDSTACK-5080: Hypervisor Capabilities table missing entry for Simulator
> - Added new SQL file to db/setup so that a row gets inserted during simulator 
> DB setup for a 'Simulator' hypervisor (in hypervisor_capabilities).
> - Updated developer/pom.xml to include this new file
> 
> 
> Diffs
> -
> 
>   developer/pom.xml 0eb18bf 
>   setup/db/hypervisor_capabilities.simulator.sql PRE-CREATION 
> 
> Diff: https://reviews.apache.org/r/15323/diff/
> 
> 
> Testing
> ---
> 
> Tested on master and 4.2
> 
> 
> Thanks,
> 
> David Grizzanti
> 
>



RE: Regarding the ssl key store change

2013-11-11 Thread Wei Zhou
Hi Sheng,

Yes.

AFAIU, client/tomcatconf/cloudmanagementserver.keystore.in should be installed 
by default, right?

If we do not need install cloudmanagementserver.keystore.in in the 
installation, the following patch can solve it.



diff --git a/debian/cloudstack-management.install 
b/debian/cloudstack-management.install
index f06ab86..ea3f93b 100644
--- a/debian/cloudstack-management.install
+++ b/debian/cloudstack-management.install
@@ -17,7 +17,6 @@

/etc/cloudstack/management/catalina.policy
/etc/cloudstack/management/catalina.properties
-/etc/cloudstack/management/cloudmanagementserver.keystore
/etc/cloudstack/management/logging.properties
/etc/cloudstack/management/commands.properties
/etc/cloudstack/management/ehcache.xml
diff --git a/packaging/centos63/cloud.spec b/packaging/centos63/cloud.spec
index cd6ff4b..893628d 100644
--- a/packaging/centos63/cloud.spec
+++ b/packaging/centos63/cloud.spec
@@ -252,7 +252,7 @@ rm -rf 
${RPM_BUILD_ROOT}%{_datadir}/%{name}-management/webapps/client/WEB-INF/cl
rm -rf 
${RPM_BUILD_ROOT}%{_datadir}/%{name}-management/webapps/client/WEB-INF/classes/vms

for name in db.properties log4j-cloud.xml tomcat6-nonssl.conf tomcat6-ssl.conf 
server-ssl.xml server-nonssl.xml \
-catalina.policy catalina.properties classpath.conf 
tomcat-users.xml web.xml environment.properties cloudmanagementserver.keystore 
; do
+catalina.policy catalina.properties classpath.conf 
tomcat-users.xml web.xml environment.properties ; do
   mv 
${RPM_BUILD_ROOT}%{_datadir}/%{name}-management/webapps/client/WEB-INF/classes/$name
 \
 ${RPM_BUILD_ROOT}%{_sysconfdir}/%{name}/management/$name
done
@@ -451,7 +451,6 @@ else
fi

if [ -f "%{_sysconfdir}/cloud.rpmsave/management/cloud.keystore" ]; then
-mv %{_sysconfdir}/%{name}/management/cloudmanagementserver.keystore 
%{_sysconfdir}/%{name}/management/cloudmanagementserver.keystore.rpmnew
 cp -p %{_sysconfdir}/cloud.rpmsave/management/cloud.keystore 
%{_sysconfdir}/%{name}/management/cloudmanagementserver.keystore
 # make sure we only do this on the first install of this RPM, don't want 
to overwrite on a reinstall
 mv %{_sysconfdir}/cloud.rpmsave/management/cloud.keystore 
%{_sysconfdir}/cloud.rpmsave/management/cloud.keystore.rpmsave
@@ -546,7 +545,6 @@ fi
%config(noreplace) %{_sysconfdir}/%{name}/management/cloud-bridge.properties
%config(noreplace) %{_sysconfdir}/%{name}/management/commons-logging.properties
%config(noreplace) %{_sysconfdir}/%{name}/management/ec2-service.properties
-%config(noreplace) 
%{_sysconfdir}/%{name}/management/cloudmanagementserver.keystore
%attr(0755,root,root) %{_initrddir}/%{name}-management
%attr(0755,root,root) %{_bindir}/%{name}-setup-management
%attr(0755,root,root) %{_bindir}/%{name}-update-xenserver-licenses


Kind Regards,

Wei ZHOU
Innovation Engineer Cloud, LeaseWeb B.V.
w.z...@leaseweb.com

From: Sheng Yang [mailto:sh...@yasker.org]
Sent: 09 November 2013 01:27
To: Wei Zhou; 
Subject: Regarding the ssl key store change

Hi Wei,

I found this change in the MASTER.

commit 57ba367f3c985e80ea1b34267e298b481a353298
Author: Wei Zhou mailto:w.z...@leaseweb.com>>
Date:   Thu Nov 7 11:09:06 2013 +0100

CLOUDSTACK-5042: change cloud.keystore to cloudmanagementserver.keystore 
and install it (cherry picked from commit 
de448ec4792eda5b47d79b26e9cb8ce96a2b22f4)

IIUC, this would means there is no SSL keystore generation for the new 
management servers? That doesn't sound right...

--Sheng


Re: [PROPOSAL] Liaison with ETSI NFV ISG

2013-11-11 Thread Sebastien Goasguen
How about Chiradeep makes the contact and proposal for CloudStack to join/be 
represented ?

Then we can decide who is the representative. Daan could do it and Nguyen could 
be the substitute ?


On Nov 9, 2013, at 8:38 AM, Daan Hoogland  wrote:

> I don't mind being involved if needed.
> 
> On Fri, Nov 8, 2013 at 6:07 PM, Chip Childers  wrote:
>> On Fri, Nov 08, 2013 at 08:58:17AM +0700, Nguyen Anh Tu wrote:
>>> 2013/11/7 Chiradeep Vittal 
>>> 
 While I appreciate the confidence, there are weekly calls to attend.
 The particularly interesting one (MANO WG) happens on Wednesdays at 6am
 PST.
 I've tried but there's very little chance that I can attend these
 meetings.
 Anybody in a more agreeable timezone?
 
>>> 
>>> Not sure if I have permitted to join, I'm in agreeable timezone (9pm at
>>> local time). It's great and I'm willing to join to liaison team.
>> 
>> I'd say you are...  you're a committer on the project.  Perhaps you and
>> Chiradeep can discuss how to get involved?



bug - incorrect provisioning on vswitches instead of dvswitches

2013-11-11 Thread Octavian Popescu
Hi,

I would like to submit a bug for discussion - 
https://issues.apache.org/jira/browse/CLOUDSTACK-5059 Do let me know if 
additional details are needed to understand & replicate it.

Thanks,
Octavian


--
Octavian Popescu
Manager, Hosting Solution Design
+420-225-352673



[ACS4.2.1] request for QA update

2013-11-11 Thread Abhinandan Prateek
Sudha/Raja,

   You guys have been doing a QA on 4.2.1 for quite some time now.
It would be good for community to know in general how the 4.2.1 branch is 
coming off in terms of quality.

-abhi


Re: Review Request 15349: Overprivisoning changes needed

2013-11-11 Thread bharat kumar


> On Nov. 9, 2013, 12:36 a.m., Nitin Mehta wrote:
> > server/src/com/cloud/configuration/Config.java, line 302
> > 
> >
> > This needs to have corresponding upgrade fix as well.

This is the same as in 3.0.7, i think we need not have this in the upgrade.


> On Nov. 9, 2013, 12:36 a.m., Nitin Mehta wrote:
> > engine/schema/src/com/cloud/upgrade/dao/Upgrade410to420.java, line 940
> > 
> >
> > Do we have a way to correct it for folks already on 4.2 ?
> >

we will edit the fix_cpuovercommit script with these changes.


- bharat


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


On Nov. 9, 2013, 12:11 a.m., bharat kumar wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/15349/
> ---
> 
> (Updated Nov. 9, 2013, 12:11 a.m.)
> 
> 
> Review request for cloudstack and Nitin Mehta.
> 
> 
> Bugs: Cloudstack-5077.
> https://issues.apache.org/jira/browse/Cloudstack-5077.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> 
> 1.) This includes the change to reserve cpu and memory only when 
> vmware.reserve.cpu/mem is true, regardless of overcommit. 
> 2.) populate the default value of the cpu overcommit at cluster level form 
> the global setting when up grading. 
> 
> 
> Diffs
> -
> 
>   engine/schema/src/com/cloud/upgrade/dao/Upgrade410to420.java 646b406 
>   
> plugins/hypervisors/vmware/src/com/cloud/hypervisor/vmware/resource/VmwareResource.java
>  4921925 
>   server/src/com/cloud/configuration/Config.java f3cb919 
> 
> Diff: https://reviews.apache.org/r/15349/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> bharat kumar
> 
>



Re: Review Request 15349: Overprivisoning changes needed

2013-11-11 Thread bharat kumar

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

(Updated Nov. 11, 2013, 10:03 a.m.)


Review request for cloudstack and Nitin Mehta.


Changes
---

added changes to update the memory overcommit in user_vm_details only in case 
of VMs running on VMware hypervisor.


Bugs: Cloudstack-5077.
https://issues.apache.org/jira/browse/Cloudstack-5077.


Repository: cloudstack-git


Description
---


1.) This includes the change to reserve cpu and memory only when 
vmware.reserve.cpu/mem is true, regardless of overcommit. 
2.) populate the default value of the cpu overcommit at cluster level form the 
global setting when up grading. 


Diffs (updated)
-

  engine/schema/src/com/cloud/upgrade/dao/Upgrade410to420.java 646b406 
  engine/schema/src/com/cloud/upgrade/dao/Upgrade420to421.java d37c0a1 
  server/src/com/cloud/configuration/Config.java f06b463 

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


Testing
---


Thanks,

bharat kumar



Review Request 15394: Added fix for CLOUDSTACK-5134

2013-11-11 Thread Santhosh Edukulla

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

Review request for cloudstack and Girish Shilamkar.


Bugs: CLOUDSTACK-5134
https://issues.apache.org/jira/browse/CLOUDSTACK-5134


Repository: cloudstack-git


Description
---

Added fix for CLOUDSTACK-5134. Detailed description is there in the bug.


Diffs
-

  test/integration/component/test_network_offering.py 04777b0 
  test/integration/component/test_portable_ip.py a532b36 
  test/integration/component/test_security_groups.py c90ccf6 
  test/integration/component/test_snapshot_limits.py e52a893 
  test/integration/component/test_stopped_vm.py 5a5c298 
  test/integration/component/test_storage_motion.py bae5acf 
  test/integration/component/test_templates.py af86d32 
  test/integration/component/test_vpc_network.py 9f5e6f6 
  test/integration/component/test_vpc_routers.py 8ed99ca 
  test/integration/component/test_vpc_vm_life_cycle.py cc65eed 
  test/integration/component/test_vpc_vms_deployment.py ebf3b31 

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


Testing
---


Thanks,

Santhosh Edukulla



Review Request 15392: Added fix for CLOUDSTACK-5134

2013-11-11 Thread Santhosh Edukulla

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

Review request for cloudstack and Girish Shilamkar.


Summary (updated)
-

Added fix for CLOUDSTACK-5134


Bugs: CLOUDSTACK-5134
https://issues.apache.org/jira/browse/CLOUDSTACK-5134


Repository: cloudstack-git


Description (updated)
---

Fixed a connection issue under asyncmgr. 
 Added __init__.py files to directory to make it 
 a package.This file was missing under few directories and 
 so not appearing as packages while refactoring. 
Adding one None Check 


Diffs
-

  tools/marvin/marvin/cloudstackConnection.py 2c027c3 
  tools/marvin/marvin/cloudstackTestClient.py 3e833c7 
  tools/marvin/marvin/integration/lib/utils.py 0fe3c26 
  tools/marvin/marvin/sandbox/demo/simulator/testcase/libs/utils.py f26d2c0 

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


Testing
---


Thanks,

Santhosh Edukulla



Re: Review Request 15392: Added fix for CLOUDSTACK-5134

2013-11-11 Thread Santhosh Edukulla

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

(Updated Nov. 11, 2013, 11:22 a.m.)


Review request for cloudstack and Girish Shilamkar.


Bugs: CLOUDSTACK-5134
https://issues.apache.org/jira/browse/CLOUDSTACK-5134


Repository: cloudstack-git


Description
---

Fixed a connection issue under asyncmgr. 
 Added __init__.py files to directory to make it 
 a package.This file was missing under few directories and 
 so not appearing as packages while refactoring. 
Adding one None Check 


Diffs
-

  tools/marvin/marvin/cloudstackConnection.py 2c027c3 
  tools/marvin/marvin/cloudstackTestClient.py 3e833c7 
  tools/marvin/marvin/integration/lib/utils.py 0fe3c26 
  tools/marvin/marvin/sandbox/demo/simulator/testcase/libs/utils.py f26d2c0 

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


Testing
---


File Attachments (updated)


Right patch attached
  
https://reviews.apache.org/media/uploaded/files/2013/11/11/e1149b21-00fd-46ea-bb19-26ddd11afa65__0001-Fixed-a-connection-issue-under-asyncmgr.patch


Thanks,

Santhosh Edukulla



Re: Review Request 14199: Adding missing test cases: Snapshots Improvement

2013-11-11 Thread Gaurav Aradhye


> On Nov. 4, 2013, 2:43 p.m., SrikanteswaraRao Talluri wrote:
> > is_snapshot_on_nfs method is returning error. NFS export path is wrongly 
> > framed in utils.py
> > 
> > Cmd: mount -t nfs 10.147.28.7/export/home/talluri/vmware.campo/secondary 
> > /mnt/tmp via Host: 10.147.38.207} {returns: ["mount.nfs: remote share not 
> > in 'host:dir' format"]}

Hi Talluri,

This issue arises when the Image url is not in proper format. As you can see, 
in above URL, colon is missing after the ip address. I had already logged this 
issue here: https://issues.apache.org/jira/browse/CLOUDSTACK-4741

This issue is inconsistent and now even I am not able to reproduce it on any 
setup. As you have encountered this, can you reopen it and please share the 
details of the setup?


- Gaurav


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


On Oct. 31, 2013, 10:34 a.m., Gaurav Aradhye wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/14199/
> ---
> 
> (Updated Oct. 31, 2013, 10:34 a.m.)
> 
> 
> Review request for cloudstack, Girish Shilamkar, suresh sadhu, and 
> SrikanteswaraRao Talluri.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Adding 5 missing test cases.
> Change in asyncJobMgr.py >> the method "make_request" in cloudstackConnection 
> does not exist now. Replaced it by "marvin_request". Checked running async 
> jobs with this change. Works correctly.
> 
> 
> Diffs
> -
> 
>   test/integration/component/test_snapshots_improvement.py PRE-CREATION 
>   tools/marvin/marvin/asyncJobMgr.py 25818a6 
> 
> Diff: https://reviews.apache.org/r/14199/diff/
> 
> 
> Testing
> ---
> 
> Tested locally on KVM Advanced setup.
> 
> test_01_concurrent_snapshots_live_migrate 
> (test_snapshots_improvement.TestCreateSnapshot)
> Test perform concurrent snapshots and migrate the vm from one host ... ok
> test_02_stop_vm_concurrent_snapshots 
> (test_snapshots_improvement.TestCreateSnapshot)
> Test stop running VM while performing concurrent snapshot on volume ... ok
> test_03_concurrent_snapshots_create_template 
> (test_snapshots_improvement.TestCreateSnapshot)
> Test while parent concurrent snapshot job in progress,create ... ok
> test_04_concurrent_snapshots_create_volume 
> (test_snapshots_improvement.TestCreateSnapshot)
> Test while parent concurrent snapshot job in progress,create volume ... ok
> test_01_snapshot_on_rootVolume 
> (test_snapshots_improvement.TestSnapshotOnRootVolume)
> Test create VM with default cent os template and create snapshot ... ok
> 
> --
> Ran 5 tests in 1420.575s
> 
> OK
> 
> 
> Thanks,
> 
> Gaurav Aradhye
> 
>



Snapshot file extension on nfs

2013-11-11 Thread Gaurav Aradhye
Hi all,

Observed this while debugging an issue related to snapshots.
The snapshot files on secondary storage server have .ovf entension when
created through XenServer and .vhd when created through Vmware. But these
files don't have any extension when they are created through KVM.

Has anyone encountered this before?

Regards,
Gaurav


Review Request 15412: Fixing coverity issue 1125364

2013-11-11 Thread Antonio Fornie

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

Review request for cloudstack and daan Hoogland.


Repository: cloudstack-git


Description
---

There was a resource leak issue. Now the FileInputStream is always close 
actively, instead of waiting for GC to pick the object.


Diffs
-

  
plugins/network-elements/juniper-contrail/src/org/apache/cloudstack/network/contrail/management/ManagementNetworkGuru.java
 e457023 

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


Testing
---

Maven build lifecycle running without any problem


Thanks,

Antonio Fornie



Re: Review Request 15412: Fixing coverity issue 1125364

2013-11-11 Thread Antonio Fornie

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

(Updated Nov. 11, 2013, 12:07 p.m.)


Review request for cloudstack, daan Hoogland and Hugo Trippaers.


Repository: cloudstack-git


Description
---

There was a resource leak issue. Now the FileInputStream is always close 
actively, instead of waiting for GC to pick the object.


Diffs
-

  
plugins/network-elements/juniper-contrail/src/org/apache/cloudstack/network/contrail/management/ManagementNetworkGuru.java
 e457023 

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


Testing
---

Maven build lifecycle running without any problem


Thanks,

Antonio Fornie



Review Request 15418: Fixes about: Code quality, checkstyle and cloudstack conventions

2013-11-11 Thread Antonio Fornie

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

Review request for cloudstack, daan Hoogland and Hugo Trippaers.


Repository: cloudstack-git


Description
---

Fixes about: Code quality, checkstyle and cloudstack conventions. Tabs replaced 
by 4 spaces, proper instance variable names, removing trailing spaces...


Diffs
-

  parents/checkstyle/src/main/resources/tooling/checkstyle.xml 83493d6 
  plugins/network-elements/nicira-nvp/pom.xml 9341c93 
  
plugins/network-elements/nicira-nvp/src/com/cloud/agent/api/ConfigurePortForwardingRulesOnLogicalRouterAnswer.java
 94931a0 
  
plugins/network-elements/nicira-nvp/src/com/cloud/agent/api/ConfigurePortForwardingRulesOnLogicalRouterCommand.java
 16ef2c4 
  
plugins/network-elements/nicira-nvp/src/com/cloud/agent/api/ConfigurePublicIpsOnLogicalRouterAnswer.java
 09a3e7e 
  
plugins/network-elements/nicira-nvp/src/com/cloud/agent/api/ConfigurePublicIpsOnLogicalRouterCommand.java
 c08f540 
  
plugins/network-elements/nicira-nvp/src/com/cloud/agent/api/ConfigureStaticNatRulesOnLogicalRouterAnswer.java
 caab316 
  
plugins/network-elements/nicira-nvp/src/com/cloud/agent/api/ConfigureStaticNatRulesOnLogicalRouterCommand.java
 5f79ffc 
  
plugins/network-elements/nicira-nvp/src/com/cloud/agent/api/CreateLogicalRouterAnswer.java
 72a275b 
  
plugins/network-elements/nicira-nvp/src/com/cloud/agent/api/CreateLogicalRouterCommand.java
 1f3f24e 
  
plugins/network-elements/nicira-nvp/src/com/cloud/agent/api/CreateLogicalSwitchAnswer.java
 753edec 
  
plugins/network-elements/nicira-nvp/src/com/cloud/agent/api/CreateLogicalSwitchCommand.java
 b2a5aaf 
  
plugins/network-elements/nicira-nvp/src/com/cloud/agent/api/CreateLogicalSwitchPortAnswer.java
 8fa7927 
  
plugins/network-elements/nicira-nvp/src/com/cloud/agent/api/CreateLogicalSwitchPortCommand.java
 fe3f683 
  
plugins/network-elements/nicira-nvp/src/com/cloud/agent/api/DeleteLogicalRouterAnswer.java
 db07547 
  
plugins/network-elements/nicira-nvp/src/com/cloud/agent/api/DeleteLogicalRouterCommand.java
 96e2cb9 
  
plugins/network-elements/nicira-nvp/src/com/cloud/agent/api/DeleteLogicalSwitchAnswer.java
 e9cfbc4 
  
plugins/network-elements/nicira-nvp/src/com/cloud/agent/api/DeleteLogicalSwitchCommand.java
 25aa339 
  
plugins/network-elements/nicira-nvp/src/com/cloud/agent/api/DeleteLogicalSwitchPortAnswer.java
 f779677 
  
plugins/network-elements/nicira-nvp/src/com/cloud/agent/api/DeleteLogicalSwitchPortCommand.java
 e91a032 
  
plugins/network-elements/nicira-nvp/src/com/cloud/agent/api/FindLogicalSwitchPortAnswer.java
 edc0c5f 
  
plugins/network-elements/nicira-nvp/src/com/cloud/agent/api/FindLogicalSwitchPortCommand.java
 b737c50 
  
plugins/network-elements/nicira-nvp/src/com/cloud/agent/api/UpdateLogicalSwitchPortAnswer.java
 f4c4130 
  
plugins/network-elements/nicira-nvp/src/com/cloud/agent/api/UpdateLogicalSwitchPortCommand.java
 1b8b590 
  
plugins/network-elements/nicira-nvp/src/com/cloud/api/commands/AddNiciraNvpDeviceCmd.java
 937b665 
  
plugins/network-elements/nicira-nvp/src/com/cloud/api/commands/DeleteNiciraNvpDeviceCmd.java
 6eb6764 
  
plugins/network-elements/nicira-nvp/src/com/cloud/api/commands/ListNiciraNvpDeviceNetworksCmd.java
 53203a7 
  
plugins/network-elements/nicira-nvp/src/com/cloud/api/commands/ListNiciraNvpDevicesCmd.java
 3e02e19 
  
plugins/network-elements/nicira-nvp/src/com/cloud/api/response/NiciraNvpDeviceResponse.java
 d6085e2 
  
plugins/network-elements/nicira-nvp/src/com/cloud/network/NiciraNvpDeviceVO.java
 3832123 
  
plugins/network-elements/nicira-nvp/src/com/cloud/network/NiciraNvpNicMappingVO.java
 d9dbb02 
  
plugins/network-elements/nicira-nvp/src/com/cloud/network/NiciraNvpRouterMappingVO.java
 1e2a831 
  
plugins/network-elements/nicira-nvp/src/com/cloud/network/dao/NiciraNvpDaoImpl.java
 5e07246 
  
plugins/network-elements/nicira-nvp/src/com/cloud/network/dao/NiciraNvpNicMappingDao.java
 f693dcb 
  
plugins/network-elements/nicira-nvp/src/com/cloud/network/dao/NiciraNvpNicMappingDaoImpl.java
 1a0fcd1 
  
plugins/network-elements/nicira-nvp/src/com/cloud/network/dao/NiciraNvpRouterMappingDaoImpl.java
 dc41f57 
  
plugins/network-elements/nicira-nvp/src/com/cloud/network/element/NiciraNvpElement.java
 3e9e16a 
  
plugins/network-elements/nicira-nvp/src/com/cloud/network/guru/NiciraNvpGuestNetworkGuru.java
 7057915 
  
plugins/network-elements/nicira-nvp/src/com/cloud/network/nicira/ControlClusterStatus.java
 2914d35 
  
plugins/network-elements/nicira-nvp/src/com/cloud/network/nicira/DestinationNatRule.java
 d149c4b 
  
plugins/network-elements/nicira-nvp/src/com/cloud/network/nicira/L3GatewayAttachment.java
 96d1991 
  
plugins/network-elements/nicira-nvp/src/com/cloud/network/nicira/LogicalRouterConfig.java
 088cefc 
  
plugins/network-elements/nicira-nvp/src/com/cloud/network/nicir

Re: Question: Error when creating templates from ROOT volumes in the Simulator

2013-11-11 Thread Prasanna Santhanam
David,

I took a little closer look today. I think that the way CloudStack
chooses the motion service to detect that the simulator should copy over a
mock template to a mock location needs intercepting. I'm not fully
privy of the changes to storage code (both in master and 4.2) but will
troubleshoot further tomorrow. Meanwhile if anyone more familiar with
storage code can point us in the right direction, it would be great to
get over this issue.

Thanks,

On Thu, Nov 07, 2013 at 03:02:09PM -0500, David Grizzanti wrote:
> Prasanna,
> 
> I took a look at the SimulatorImageStoreDriverImpl, but it seems like it's
> setting size correctly in that case.  Also, in trying to step through the
> code, that section doesn't appear to be called when creating a template
> from a ROOT volume (I could be doing something wrong though when stepping
> through the code in debug mode).  You mentioned that it may have been
> something you missed when updating aft erhte 4.2 storage refactor - is
> there some other plugin code that I can look at for one of the other
> hypervisors that might shed some light on the correct way to do this?
> 
> Thanks!
> 
> 
> On Tue, Nov 5, 2013 at 9:09 AM, David Grizzanti  > wrote:
> 
> > Ok, thanks Prasanna. Will have a look and let you know what I find.
> >
> >
> > On Tuesday, November 5, 2013, Prasanna Santhanam wrote:
> >
> >> This is a bug. Likely something I missed when adopting the simulator
> >> to the storage refactor in 4.2. You'd want to look at the
> >> SimulatorImageStoreDriverImpl.java#createTemplate() and see how the
> >> template gets registered with 0 size.
> >>
> >> On Tue, Nov 05, 2013 at 02:54:00AM -0500, Sebastien Goasguen wrote:
> >> > Pinging Prasanna on this,
> >> >
> >> >
> >> > On Oct 31, 2013, at 5:07 PM, David Grizzanti <
> >> david.grizza...@sungard.com> wrote:
> >> >
> >> > > Hi All,
> >> > >
> >> > > I have been seeing an issue with the Simulator that I was hoping
> >> someone
> >> > > could provide some insight into.
> >> > >
> >> > > Some background. I'm running from the 4.2.0 tag on rhel 6.3, building
> >> from
> >> > > source/enabling the simulator.
> >> > >
> >> > > Overall, most operations seem to work fine, however, I noticed that
> >> when
> >> > > creating a template from the ROOT volume on a VM, the template can't
> >> then
> >> > > be used to create a subsequent VM.  The reason for this seems to be
> >> that
> >> > > the "size" of the template is set to 0.  After digging through the
> >> database
> >> > > a bit, I discovered that the size and physical_size columns in
> >> > > the template_store_ref table are set to 0 for these templates.  If I
> >> > > correct those values for my entry after the fact, everything appears
> >> to
> >> > > work.
> >> > >
> >> > > I dug around in the code a bit as well, but nothing obvious was
> >> jumping out
> >> > > at me as to why this was happening.
> >> > >
> >> > > Any thoughts?
> >> > >
> >> > > Thanks!
> >> > >
> >> > > --
> >> > > David Grizzanti
> >> > > Software Engineer
> >> > > Sungard Availability Services
> >> > >
> >> > > e: david.grizza...@sungard.com
> >> > > w: 215.446.1431
> >> > > c: 570.575.0315
> >>
> >> --
> >> Prasanna.,
> >>
> >> 
> >> Powered by BigRock.com
> >>
> >>
> >>
> >
> > --
> > David Grizzanti
> > Software Engineer
> > Sungard Availability Services
> >
> > e: david.grizza...@sungard.com
> > w: 215.446.1431
> > c: 570.575.0315
> >
> >
> 
> 
> -- 
> David Grizzanti
> Software Engineer
> Sungard Availability Services
> 
> e: david.grizza...@sungard.com
> w: 215.446.1431
> c: 570.575.0315

-- 
Prasanna.,


Powered by BigRock.com



upgrade question

2013-11-11 Thread Daan Hoogland
H,

I started doing some upgrade testing and got an exception during startup:

INFO  [cloud.upgrade.DatabaseUpgradeChecker] (Timer-2:) Database
upgrade must be performed from 4.1.1 to 4.2.1-SNAPSHOT
ERROR [utils.db.ScriptRunner] (Timer-2:) Error executing: CREATE VIEW
`cloud`.`event_view` AS select event.id,
event.uuid, event.type, event.state,
event.description, event.created, event.level,
event.parameters, event.start_id, eve.uuid start_uuid,
event.user_id, event.archived, user.username
user_name, account.id account_id, account.uuid
account_uuid, account.account_name account_name,
account.type account_type, domain.id domain_id,
domain.uuid domain_uuid, domain.name domain_name,
domain.path domain_path, projects.id project_id,
projects.uuid project_uuid, projects.name project_name
from `cloud`.`event` inner join
`cloud`.`account` ON event.account_id = account.id inner
join `cloud`.`domain` ON event.domain_id = domain.id
  inner join `cloud`.`user` ON event.user_id = user.id
left join `cloud`.`projects` ON
projects.project_account_id = event.account_id left join
  `cloud`.`event` eve ON event.start_id = eve.id
ERROR [utils.db.ScriptRunner] (Timer-2:)
com.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException: Table
'event_view' already exists
ERROR [cloud.upgrade.DatabaseUpgradeChecker] (Timer-2:) Unable to
execute upgrade script:
C:\Users\dhoogland\cloudstack\cloudstack\client\target\utilities\scripts\db\db\schema-410to420.sql
com.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException: Table
'event_view' already exists
at com.cloud.utils.db.ScriptRunner.runScript(ScriptRunner.java:193)
at com.cloud.utils.db.ScriptRunner.runScript(ScriptRunner.java:87)

etcetera.

I checked the upgrade script which says,


DROP VIEW IF EXISTS `cloud`.`event_view`;
CREATE VIEW `cloud`.`event_view` AS
select
event.id,
...

So in theory it should delete the table and not complain about it
already existing. Am I missing something or did I hit a bug? (auto
commit issue maybe?)

regards,
Daan


[DISCUSS] (CLOUDSTACK-1889)

2013-11-11 Thread Saurav Lahiri
All,
I have a query with respect to this defect. With a build off the  master it
looks like the updateResourceCount api is returning the count of resources
a user can use or create and that appears to be the documented behaviour
for this api. Furthermore it appears that the UI is correctly displaying
that.

With respect to issue raised in the defect the expected behaviour is that
instead of the count of resources that can be created or used it should
display the actual usage count.

Could someone please clarify whats the correct expected behaviour with
respect to the
updateResourceCount api and if this a valid bug?

Thanks
Saurav


Re: [jira] [Updated] (CLOUDSTACK-4982) Top of dialogs cut off

2013-11-11 Thread sebgoa
looks like this has been fixed in 4.3

On Nov 7, 2013, at 11:58 PM, Luis  wrote:

> Hi
> 
> I will appreciate your help to fix this problem
> 
> 
> CloudStack 4.2
> Ubuntu 12.04
> single machine
> 
> The errors
> 
> 
> 10.0.0.20:/export/primary/ 684G  2.5G  646G   1% 
> /mnt/primary
> 10.0.0.20:/export/secondary/   684G  2.5G  646G   1% 
> /mnt/secondary
> 10.0.0.20:/export/primary  684G  2.5G  646G   1%
> /mnt/0b89f7ac-67a7-3790-9f49-ad66af4319c5
> 10.0.0.20:/export/secondary/template/tmpl/1/3  684G  2.5G  646G   1% 
> /mnt/96340021-0249-366b-b4b7-f271271634a2
> 
> 
> 2013-11-06 21:55:04,386 INFO  [cloud.vm.VirtualMachineManagerImpl] 
> (secstorage-1:null) Unable to contact resource.
> com.cloud.exception.StorageUnavailableException:
> Resource [StoragePool:1] is unreachable: Unable to create 
> Vol[6|vm=6|ROOT]:Failed to get volumes from pool: 
> 96340021-0249-366b-b4b7-f271271634a2
> 
> 
> 2013-11-06 21:55:34,178 INFO  [cloud.vm.VirtualMachineManagerImpl] 
> (secstorage-1:null) Unable to contact resource.
> com.cloud.exception.StorageUnavailableException:
> Resource [StoragePool:1] is unreachable: Unable to create 
> Vol[6|vm=6|ROOT]:Failed to get volumes from pool: 
> 96340021-0249-366b-b4b7-f271271634a2
> 
> 
> 2013-11-06 21:55:34,558 WARN  [storage.secondary.SecondaryStorageManagerImpl] 
> (secstorage-1:null) Exception while trying to start secondary storage vm
> com.cloud.exception.InsufficientServerCapacityException:
> Unable to create a deployment for 
> VM[SecondaryStorageVm|s-6-VM]Scope=interface com.cloud.dc.DataCenter; 
> id=1
> at 
> com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManagerImpl.java:842)
> 
> 2013-11-06 21:55:34,666 INFO  [cloud.vm.VirtualMachineManagerImpl] 
> (consoleproxy-1:null) Unable to contact resource.
> com.cloud.exception.StorageUnavailableException:
> Resource [StoragePool:1] is unreachable: Unable to create 
> Vol[2|vm=2|ROOT]:Failed to get volumes from pool: 
> 96340021-0249-366b-b4b7-f271271634a2
> 
> 2013-11-06 21:55:35,049 WARN  [cloud.consoleproxy.ConsoleProxyManagerImpl] 
> (consoleproxy-1:null) Exception while trying to start console proxy
> com.cloud.exception.InsufficientServerCapacityException:
> Unable to create a deployment for 
> VM[ConsoleProxy|v-2-VM]Scope=interface com.cloud.dc.DataCenter; id=1
> 
> 
> 
> 
> On Thursday, November 7, 2013 5:30 PM, Animesh Chaturvedi (JIRA) 
>  wrote:
> 
> 
>  [ 
> https://issues.apache.org/jira/browse/CLOUDSTACK-4982?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
>  ]
> 
> Animesh Chaturvedi updated CLOUDSTACK-4982:
> ---
> 
> 
> BULK EDIT> These issues are open to be picked up. Help in resolution is 
> appreciated.
> 
>> Top of dialogs cut off
>> --
>> 
>>  Key: CLOUDSTACK-4982
>>  URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4982
>>  Project: CloudStack
>>   Issue Type: Bug
>>   Security Level: Public(Anyone can view this level - this is the 
>> default.) 
>>   Components: UI
>> Affects Versions: 4.3.0
>>  Environment: Chrome Version 30.0.1599.101 on Mac OS X 10.8.3
>> Reporter: Mike Tutkowski
>> Priority: Minor
>>  Fix For: 4.3.0
>> 
>>  Attachments: Top of Dialog.png
>> 
>> 
>> Please see the attached screen shot.
> 
> 
> 
> --
> This message was sent by Atlassian JIRA
> (v6.1#6144)



RE: [ACS4.2.1] request for QA update

2013-11-11 Thread Sudha Ponnaganti
Hi All,

Scope Status [1]

-  Rayees has posted automation results earlier BVTs and regressions 
were done in citrix lab on 4.2.1 branch

-  Tested a few regressions around VMWare as there are couple of issues 
got fixed in last phases of 4.2

-  250 issues got fixed for 4.2.1


Blockers for RC

-  We still have 7 Criticals/blockers that need to be fixed in JIRA ( 
Use query Fixed version 4.2.1)

-  Upgrade paths need to be closed

o   4,2 ( citrix is trying this out - will report back Wednesday)

o   4.1.1 ( Daan will report back by Friday)

o   2.2.14 > ( Lucian has been trying this path)

Good to have for RC

-  There are 80 Resolved defects. Would help if community can close 
these ( you can use query fix version 4.2.1, Status Resolved )

[1] 
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Cloudstack+4.2.1+Maintenance+Release
[2] 
https://cwiki.apache.org/confluence/display/CLOUDSTACK/4.2.1+Automation+Result

From: Abhinandan Prateek
Sent: Monday, November 11, 2013 1:56 AM
To: CloudStack Dev
Cc: Raja Pullela; Sudha Ponnaganti
Subject: [ACS4.2.1] request for QA update

Sudha/Raja,

   You guys have been doing a QA on 4.2.1 for quite some time now.
It would be good for community to know in general how the 4.2.1 branch is 
coming off in terms of quality.

-abhi


Re: [ACS 421] Upgrade testing

2013-11-11 Thread Daan Hoogland
the 4.1.1 to 4.2.1 upgrade works fine in a lab env using a production database.

@Wei, how are you coming along?

rgards,
Daan

On Mon, Nov 11, 2013 at 7:13 AM, Abhinandan Prateek
 wrote:
>
>>On Fri, Nov 08, 2013 at 12:52:13PM +, Abhinandan Prateek wrote:
>>> Sudha,
>>>   We can still cut RC but will wait for GA till Daan and others have
>>>done
>>> their testing.
>>
>>Abhi,
>>
>>An "RC" here is really a release artifact that's being voted on, so
>>no...  please don't do that until you are satisfied that we are ready to
>>start voting.  Unlike past releases, it looks like we *as a community*
>>are actually testing a bug-fix release before voting starts.  Let's
>>continue to engender this approach!
>
> Yes, I think there are still some critical tickets in Jira, will wait till
> all of them are resolved.
> Also I am following up with Sudha it appears that things are stable, but
> still will wait for a green signal from her and a clean Jira as min
> condition to cut an RC.
>
> -abhi
>>
>


RE: [ACS 421] Upgrade testing

2013-11-11 Thread Wei Zhou
Hi Daan,

Bugs (CLOUDSTACK-5042/5076/4923) are fixed. 

The only problem is what Sheng mentioned 
(http://cloudstack.markmail.org/message/t7ntzxn43fawknqi)
I will fix it soon.


Kind Regards,

Wei ZHOU
Innovation Engineer Cloud, LeaseWeb B.V.
w.z...@leaseweb.com

-Original Message-
From: Daan Hoogland [mailto:daan.hoogl...@gmail.com] 
Sent: 11 November 2013 17:23
To: dev; Wei Zhou
Subject: Re: [ACS 421] Upgrade testing

the 4.1.1 to 4.2.1 upgrade works fine in a lab env using a production database.

@Wei, how are you coming along?

rgards,
Daan

On Mon, Nov 11, 2013 at 7:13 AM, Abhinandan Prateek 
 wrote:
>
>>On Fri, Nov 08, 2013 at 12:52:13PM +, Abhinandan Prateek wrote:
>>> Sudha,
>>>   We can still cut RC but will wait for GA till Daan and others have 
>>>done  their testing.
>>
>>Abhi,
>>
>>An "RC" here is really a release artifact that's being voted on, so 
>>no...  please don't do that until you are satisfied that we are ready 
>>to start voting.  Unlike past releases, it looks like we *as a 
>>community* are actually testing a bug-fix release before voting 
>>starts.  Let's continue to engender this approach!
>
> Yes, I think there are still some critical tickets in Jira, will wait 
> till all of them are resolved.
> Also I am following up with Sudha it appears that things are stable, 
> but still will wait for a green signal from her and a clean Jira as 
> min condition to cut an RC.
>
> -abhi
>>
>


Re: Review Request 15418: Fixes about: Code quality, checkstyle and cloudstack conventions

2013-11-11 Thread daan Hoogland

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



plugins/network-elements/nicira-nvp/src/com/cloud/network/element/NiciraNvpElement.java


use a better name (MAX_PORT for instance)



plugins/network-elements/nicira-nvp/src/com/cloud/network/element/NiciraNvpElement.java


no code in comment



plugins/network-elements/nicira-nvp/src/com/cloud/network/element/NiciraNvpElement.java


why use the var PORT in one place and not in the other



plugins/network-elements/nicira-nvp/src/com/cloud/network/nicira/NiciraNvpApi.java


there are more path-parts to put in static-finals
also some places these are not used


- daan Hoogland


On Nov. 11, 2013, 12:09 p.m., Antonio Fornie wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/15418/
> ---
> 
> (Updated Nov. 11, 2013, 12:09 p.m.)
> 
> 
> Review request for cloudstack, daan Hoogland and Hugo Trippaers.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Fixes about: Code quality, checkstyle and cloudstack conventions. Tabs 
> replaced by 4 spaces, proper instance variable names, removing trailing 
> spaces...
> 
> 
> Diffs
> -
> 
>   parents/checkstyle/src/main/resources/tooling/checkstyle.xml 83493d6 
>   plugins/network-elements/nicira-nvp/pom.xml 9341c93 
>   
> plugins/network-elements/nicira-nvp/src/com/cloud/agent/api/ConfigurePortForwardingRulesOnLogicalRouterAnswer.java
>  94931a0 
>   
> plugins/network-elements/nicira-nvp/src/com/cloud/agent/api/ConfigurePortForwardingRulesOnLogicalRouterCommand.java
>  16ef2c4 
>   
> plugins/network-elements/nicira-nvp/src/com/cloud/agent/api/ConfigurePublicIpsOnLogicalRouterAnswer.java
>  09a3e7e 
>   
> plugins/network-elements/nicira-nvp/src/com/cloud/agent/api/ConfigurePublicIpsOnLogicalRouterCommand.java
>  c08f540 
>   
> plugins/network-elements/nicira-nvp/src/com/cloud/agent/api/ConfigureStaticNatRulesOnLogicalRouterAnswer.java
>  caab316 
>   
> plugins/network-elements/nicira-nvp/src/com/cloud/agent/api/ConfigureStaticNatRulesOnLogicalRouterCommand.java
>  5f79ffc 
>   
> plugins/network-elements/nicira-nvp/src/com/cloud/agent/api/CreateLogicalRouterAnswer.java
>  72a275b 
>   
> plugins/network-elements/nicira-nvp/src/com/cloud/agent/api/CreateLogicalRouterCommand.java
>  1f3f24e 
>   
> plugins/network-elements/nicira-nvp/src/com/cloud/agent/api/CreateLogicalSwitchAnswer.java
>  753edec 
>   
> plugins/network-elements/nicira-nvp/src/com/cloud/agent/api/CreateLogicalSwitchCommand.java
>  b2a5aaf 
>   
> plugins/network-elements/nicira-nvp/src/com/cloud/agent/api/CreateLogicalSwitchPortAnswer.java
>  8fa7927 
>   
> plugins/network-elements/nicira-nvp/src/com/cloud/agent/api/CreateLogicalSwitchPortCommand.java
>  fe3f683 
>   
> plugins/network-elements/nicira-nvp/src/com/cloud/agent/api/DeleteLogicalRouterAnswer.java
>  db07547 
>   
> plugins/network-elements/nicira-nvp/src/com/cloud/agent/api/DeleteLogicalRouterCommand.java
>  96e2cb9 
>   
> plugins/network-elements/nicira-nvp/src/com/cloud/agent/api/DeleteLogicalSwitchAnswer.java
>  e9cfbc4 
>   
> plugins/network-elements/nicira-nvp/src/com/cloud/agent/api/DeleteLogicalSwitchCommand.java
>  25aa339 
>   
> plugins/network-elements/nicira-nvp/src/com/cloud/agent/api/DeleteLogicalSwitchPortAnswer.java
>  f779677 
>   
> plugins/network-elements/nicira-nvp/src/com/cloud/agent/api/DeleteLogicalSwitchPortCommand.java
>  e91a032 
>   
> plugins/network-elements/nicira-nvp/src/com/cloud/agent/api/FindLogicalSwitchPortAnswer.java
>  edc0c5f 
>   
> plugins/network-elements/nicira-nvp/src/com/cloud/agent/api/FindLogicalSwitchPortCommand.java
>  b737c50 
>   
> plugins/network-elements/nicira-nvp/src/com/cloud/agent/api/UpdateLogicalSwitchPortAnswer.java
>  f4c4130 
>   
> plugins/network-elements/nicira-nvp/src/com/cloud/agent/api/UpdateLogicalSwitchPortCommand.java
>  1b8b590 
>   
> plugins/network-elements/nicira-nvp/src/com/cloud/api/commands/AddNiciraNvpDeviceCmd.java
>  937b665 
>   
> plugins/network-elements/nicira-nvp/src/com/cloud/api/commands/DeleteNiciraNvpDeviceCmd.java
>  6eb6764 
>   
> plugins/network-elements/nicira-nvp/src/com/cloud/api/commands/ListNiciraNvpDeviceNetworksCmd.java
>  53203a7 
>   
> plugins/network-elements/nicira-nvp/src/com/cloud/api/commands/ListNiciraNvpDevicesCmd.java
>  3e02e19 
>   
> plugins/network-elements/nicira-nvp/src/com/cloud/api/response/NiciraNvpDeviceResponse.java
>  d6085e2 
>   
> plugins/network-elements/nicira-nvp/src/co

Secondary Storage - migrating from NFS to S3 for

2013-11-11 Thread Andrei Mikhailovsky
Hello guys, 

What is the best way to migrate from NFS secondary storage to S3 (ceph) 
secondary storage? 

I understand that I can't simply add S3 and wait for it to populate with 
snapshots and templates and after that remove the NFS storage. ACS doesn't 
allow me to add S3 if I already have NFS. 

Should I delete the NFS storage and add S3? Would this work? I don't really 
care about the templates and snapshots as I don't have that many and I can 
manually create them. I am more worried about systemvm and virtual routers 
being able to get created and started. 

Thanks 

Andrei 


Re: [ACS 421] Upgrade testing

2013-11-11 Thread Wei ZHOU
fixed.

2013/11/11 Wei Zhou 

> Hi Daan,
>
> Bugs (CLOUDSTACK-5042/5076/4923) are fixed.
>
> The only problem is what Sheng mentioned (
> http://cloudstack.markmail.org/message/t7ntzxn43fawknqi)
> I will fix it soon.
>
>
> Kind Regards,
>
> Wei ZHOU
> Innovation Engineer Cloud, LeaseWeb B.V.
> w.z...@leaseweb.com
>
> -Original Message-
> From: Daan Hoogland [mailto:daan.hoogl...@gmail.com]
> Sent: 11 November 2013 17:23
> To: dev; Wei Zhou
> Subject: Re: [ACS 421] Upgrade testing
>
> the 4.1.1 to 4.2.1 upgrade works fine in a lab env using a production
> database.
>
> @Wei, how are you coming along?
>
> rgards,
> Daan
>
> On Mon, Nov 11, 2013 at 7:13 AM, Abhinandan Prateek <
> abhinandan.prat...@citrix.com> wrote:
> >
> >>On Fri, Nov 08, 2013 at 12:52:13PM +, Abhinandan Prateek wrote:
> >>> Sudha,
> >>>   We can still cut RC but will wait for GA till Daan and others have
> >>>done  their testing.
> >>
> >>Abhi,
> >>
> >>An "RC" here is really a release artifact that's being voted on, so
> >>no...  please don't do that until you are satisfied that we are ready
> >>to start voting.  Unlike past releases, it looks like we *as a
> >>community* are actually testing a bug-fix release before voting
> >>starts.  Let's continue to engender this approach!
> >
> > Yes, I think there are still some critical tickets in Jira, will wait
> > till all of them are resolved.
> > Also I am following up with Sudha it appears that things are stable,
> > but still will wait for a green signal from her and a clean Jira as
> > min condition to cut an RC.
> >
> > -abhi
> >>
> >
>


RE: Regarding the ssl key store change

2013-11-11 Thread Wei Zhou
Hi Sheng,

As the cloudmanagementserver.keystore is not valid after RPM installation, I 
remove the file from cloudstack installations (including DEBs and RPMs).
For someone who use server-ssl.xml, as cloudmanagementserver.keystore is not 
installed by default,  they need to start with server-nonssl.xml at first so 
that CloudStack will generate the keystore.

Thanks for your Email!

Kind Regards,

Wei ZHOU
Innovation Engineer Cloud, LeaseWeb B.V.
w.z...@leaseweb.com

From: Sheng Yang [mailto:sh...@yasker.org]
Sent: 09 November 2013 01:27
To: Wei Zhou; 
Subject: Regarding the ssl key store change

Hi Wei,

I found this change in the MASTER.

commit 57ba367f3c985e80ea1b34267e298b481a353298
Author: Wei Zhou mailto:w.z...@leaseweb.com>>
Date:   Thu Nov 7 11:09:06 2013 +0100

CLOUDSTACK-5042: change cloud.keystore to cloudmanagementserver.keystore 
and install it (cherry picked from commit 
de448ec4792eda5b47d79b26e9cb8ce96a2b22f4)

IIUC, this would means there is no SSL keystore generation for the new 
management servers? That doesn't sound right...

--Sheng


Re: upgrade question

2013-11-11 Thread Alena Prokharchyk
Daan,

If you execute the line "DROP VIEW IF EXISTS `cloud`.`event_view`;" manually, 
does it drop the view? Also can you check if your management server was started 
twice (unlikely)? I can't think of anything else.

In the future we should use "CREATE OR REPLACE VIEW" syntax instead of 
dropping/recreating the view

-Alena.

From: Daan Hoogland mailto:daan.hoogl...@gmail.com>>
Reply-To: "dev@cloudstack.apache.org" 
mailto:dev@cloudstack.apache.org>>
Date: Monday, November 11, 2013 5:09 AM
To: dev mailto:dev@cloudstack.apache.org>>
Subject: upgrade question

H,

I started doing some upgrade testing and got an exception during startup:

INFO  [cloud.upgrade.DatabaseUpgradeChecker] (Timer-2:) Database
upgrade must be performed from 4.1.1 to 4.2.1-SNAPSHOT
ERROR [utils.db.ScriptRunner] (Timer-2:) Error executing: CREATE VIEW
`cloud`.`event_view` AS select event.id,
event.uuid, event.type, event.state,
event.description, event.created, event.level,
event.parameters, event.start_id, eve.uuid start_uuid,
event.user_id, event.archived, user.username
user_name, account.id account_id, account.uuid
account_uuid, account.account_name account_name,
account.type account_type, domain.id domain_id,
domain.uuid domain_uuid, domain.name domain_name,
domain.path domain_path, projects.id project_id,
projects.uuid project_uuid, projects.name project_name
from `cloud`.`event` inner join
`cloud`.`account` ON event.account_id = account.id inner
join `cloud`.`domain` ON event.domain_id = domain.id
  inner join `cloud`.`user` ON event.user_id = user.id
left join `cloud`.`projects` ON
projects.project_account_id = event.account_id left join
  `cloud`.`event` eve ON event.start_id = eve.id
ERROR [utils.db.ScriptRunner] (Timer-2:)
com.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException: Table
'event_view' already exists
ERROR [cloud.upgrade.DatabaseUpgradeChecker] (Timer-2:) Unable to
execute upgrade script:
C:\Users\dhoogland\cloudstack\cloudstack\client\target\utilities\scripts\db\db\schema-410to420.sql
com.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException: Table
'event_view' already exists
at com.cloud.utils.db.ScriptRunner.runScript(ScriptRunner.java:193)
at com.cloud.utils.db.ScriptRunner.runScript(ScriptRunner.java:87)

etcetera.

I checked the upgrade script which says,


DROP VIEW IF EXISTS `cloud`.`event_view`;
CREATE VIEW `cloud`.`event_view` AS
select
event.id,
...

So in theory it should delete the table and not complain about it
already existing. Am I missing something or did I hit a bug? (auto
commit issue maybe?)

regards,
Daan



RE: [ACS4.2.1] request for QA update

2013-11-11 Thread Raja Pullela
Minor update on the ACS 4.2 to 4.2.1 upgrade.
From: Sudha Ponnaganti
Sent: Monday, November 11, 2013 9:18 PM
To: Abhinandan Prateek; CloudStack Dev
Cc: Raja Pullela
Subject: RE: [ACS4.2.1] request for QA update

Hi All,

Scope Status [1]

-  Rayees has posted automation results earlier BVTs and regressions 
were done in citrix lab on 4.2.1 branch

-  Tested a few regressions around VMWare as there are couple of issues 
got fixed in last phases of 4.2

-  250 issues got fixed for 4.2.1


Blockers for RC

-  We still have 7 Criticals/blockers that need to be fixed in JIRA ( 
Use query Fixed version 4.2.1)

-  Upgrade paths need to be closed

o   4,2 ( citrix is trying this out - will report back Wednesday) Update: ACS 
4.2 to 4.2.1 upgrade path testing is complete.

o   4.1.1 ( Daan will report back by Friday)

o   2.2.14 > ( Lucian has been trying this path)

Good to have for RC

-  There are 80 Resolved defects. Would help if community can close 
these ( you can use query fix version 4.2.1, Status Resolved )

[1] 
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Cloudstack+4.2.1+Maintenance+Release
[2] 
https://cwiki.apache.org/confluence/display/CLOUDSTACK/4.2.1+Automation+Result

From: Abhinandan Prateek
Sent: Monday, November 11, 2013 1:56 AM
To: CloudStack Dev
Cc: Raja Pullela; Sudha Ponnaganti
Subject: [ACS4.2.1] request for QA update

Sudha/Raja,

   You guys have been doing a QA on 4.2.1 for quite some time now.
It would be good for community to know in general how the 4.2.1 branch is 
coming off in terms of quality.

-abhi


Re: Secondary Storage - migrating from NFS to S3 for

2013-11-11 Thread Min Chen
Hi Andrei,

This support is added in CloudStack 4.2.1, not released yet. See
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Migration+of+NFS+Sec
ondary+Storage+to+Object+Store for details.

Thanks  
-min

On 11/11/13 8:50 AM, "Andrei Mikhailovsky"  wrote:

>Hello guys, 
>
>What is the best way to migrate from NFS secondary storage to S3 (ceph)
>secondary storage?
>
>I understand that I can't simply add S3 and wait for it to populate with
>snapshots and templates and after that remove the NFS storage. ACS
>doesn't allow me to add S3 if I already have NFS.
>
>Should I delete the NFS storage and add S3? Would this work? I don't
>really care about the templates and snapshots as I don't have that many
>and I can manually create them. I am more worried about systemvm and
>virtual routers being able to get created and started.
>
>Thanks 
>
>Andrei 



RE: SRX inline with VR

2013-11-11 Thread Geoff Higginbottom
Hi Sheng,

Thanks for the replies, but I have to admit I'm not 100% sure what your answer 
is - sorry.

I think you are saying - "No, I can't use the VR for LB when using an SRX 
Firewall"

I hope you are not saying that "we cannot use the VR for LB" on its own"

Regards

Geoff Higginbottom

D: +44 20 3603 0542 | S: +44 20 3603 0540 | M: +447968161581

geoff.higginbot...@shapeblue.com

-Original Message-
From: Sheng Yang [mailto:sh...@yasker.org]
Sent: 08 November 2013 18:38
To: 
Subject: Re: SRX inline with VR

Sorry, I meant the CloudStack major release after 4.3... Got mixed up a little 
bit...

--Sheng


On Fri, Nov 8, 2013 at 9:57 AM, Sheng Yang  wrote:

> Hi Geoff,
>
> Currently we don't support VR as load balancing alone, there are some
> VR limitations need to be solved. I think the current plan is to fix
> it in Felton.
>
> --Sheng
>
>
> On Fri, Nov 8, 2013 at 6:19 AM, Geoff Higginbottom <
> geoff.higginbot...@shapeblue.com> wrote:
>
>>  All,
>>
>>
>>
>> Is it possible to use a Juniper SRX Firewall for firewall features,
>> and a VR for Load Balancing, or do you need to use an F5 to get 'in
>> line' mode
>>
>>
>>
>> If you can use a SRX, what IP gets load balanced, public or private
>> etc
>>
>>
>>
>> Regards
>>
>>
>>
>> Geoff Higginbottom
>>
>> *CTO / Cloud Architect*
>>
>>
>>
>> [image: Description: Mail Logo Bottom Align]
>>
>>
>>
>> D: +44 20 3603 0542 <+442036030542> | S: +44 20 3603 0540 <+442036030540>| M:
>> +447968161581
>>
>>
>>
>> geoff.higginbot...@shapeblue.com | www.shapeblue.com |
>> Twitter:@shapeblue
>>
>>
>>
>> ShapeBlue Ltd, 53 Chandos Place, Covent Garden, London, WC2N 4HS
>>
>>
>>
>> *ShapeBlue are proud to be sponsoring CloudStack Collab EU 2013*
>>
>> [image:
>> cid:image004.jpg@01CED4C8.C686BDF0]
>>
>> Apache CloudStack Bootcamp training courses
>>
>> **NEW!** CloudStack 4.2
>> training> />
>>
>> 13/14 November,
>> London
>>
>> *09-13 December, GLOBAL. Instructor led, On-line
>>  *
>>
>> 27/28 November,
>> Bangalore> e/>
>>
>> 08/09 January 2014,
>> London
>>
>>
>>  This email and any attachments to it may be confidential and are
>> intended solely for the use of the individual to whom it is
>> addressed. Any views or opinions expressed are solely those of the
>> author and do not necessarily represent those of Shape Blue Ltd or
>> related companies. If you are not the intended recipient of this
>> email, you must neither take any action based upon its contents, nor
>> copy or show it to anyone. Please contact the sender if you believe you have 
>> received this email in error.
>> Shape Blue Ltd is a company incorporated in England & Wales.
>> ShapeBlue Services India LLP is a company incorporated in India and
>> is operated under license from Shape Blue Ltd. Shape Blue Brasil
>> Consultoria Ltda is a company incorporated in Brasil and is operated
>> under license from Shape Blue Ltd. ShapeBlue is a registered trademark.
>>
>
>
This email and any attachments to it may be confidential and are intended 
solely for the use of the individual to whom it is addressed. Any views or 
opinions expressed are solely those of the author and do not necessarily 
represent those of Shape Blue Ltd or related companies. If you are not the 
intended recipient of this email, you must neither take any action based upon 
its contents, nor copy or show it to anyone. Please contact the sender if you 
believe you have received this email in error. Shape Blue Ltd is a company 
incorporated in England & Wales. ShapeBlue Services India LLP is a company 
incorporated in India and is operated under license from Shape Blue Ltd. Shape 
Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is 
operated under license from Shape Blue Ltd. ShapeBlue is a registered trademark.


Re: Review Request 15349: Overprivisoning changes needed

2013-11-11 Thread Nitin Mehta

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



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


4.2 --> 4.2.1 upgrading folks will not see this text change


- Nitin Mehta


On Nov. 11, 2013, 10:03 a.m., bharat kumar wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/15349/
> ---
> 
> (Updated Nov. 11, 2013, 10:03 a.m.)
> 
> 
> Review request for cloudstack and Nitin Mehta.
> 
> 
> Bugs: Cloudstack-5077.
> https://issues.apache.org/jira/browse/Cloudstack-5077.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> 
> 1.) This includes the change to reserve cpu and memory only when 
> vmware.reserve.cpu/mem is true, regardless of overcommit. 
> 2.) populate the default value of the cpu overcommit at cluster level form 
> the global setting when up grading. 
> 
> 
> Diffs
> -
> 
>   engine/schema/src/com/cloud/upgrade/dao/Upgrade410to420.java 646b406 
>   engine/schema/src/com/cloud/upgrade/dao/Upgrade420to421.java d37c0a1 
>   server/src/com/cloud/configuration/Config.java f06b463 
> 
> Diff: https://reviews.apache.org/r/15349/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> bharat kumar
> 
>



persistence layer

2013-11-11 Thread Laszlo Hornyak
Hi,

What are the general directions with the persistence system?
What I know about it is:
- It works with JPA (javax.persistence) annotations
- But rather than integrating a general JPA implementation such us
hibernate, eclipselink or OpenJPA it uses its own query generator and DAO
classes to generate SQL statements.

Questions:
- Are you planing to use JPA? What is the motivation behind the custom DAO
system?
- There are some capabilities in the DAO system that are not used. Should
these capabilities be maintained or is it ok to remove the support for
unused features in small steps?

-- 

EOF


Re: upgrade question

2013-11-11 Thread Daan Hoogland
Alena,

Sorry for not reporting earlier. The error was due to an incomplete import
by a mysql version different from the one doing the export. No cloudstack
issue there

Thanks,

mobile biligual spell checker used
Op 11 nov. 2013 18:24 schreef "Alena Prokharchyk" <
alena.prokharc...@citrix.com>:

>  Daan,
>
>  If you execute the line "DROP VIEW IF EXISTS `cloud`.`event_view`;"
> manually, does it drop the view? Also can you check if your management
> server was started twice (unlikely)? I can't think of anything else.
>
>  In the future we should use "CREATE OR REPLACE VIEW" syntax instead of
> dropping/recreating the view
>
>  -Alena.
>
>   From: Daan Hoogland 
> Reply-To: "dev@cloudstack.apache.org" 
> Date: Monday, November 11, 2013 5:09 AM
> To: dev 
> Subject: upgrade question
>
>   H,
>
>  I started doing some upgrade testing and got an exception during startup:
>
>  INFO  [cloud.upgrade.DatabaseUpgradeChecker] (Timer-2:) Database
> upgrade must be performed from 4.1.1 to 4.2.1-SNAPSHOT
> ERROR [utils.db.ScriptRunner] (Timer-2:) Error executing: CREATE VIEW
> `cloud`.`event_view` AS select event.id,
> event.uuid, event.type, event.state,
> event.description, event.created, event.level,
> event.parameters, event.start_id, eve.uuid start_uuid,
> event.user_id, event.archived, user.username
> user_name, account.id account_id, account.uuid
> account_uuid, account.account_name account_name,
> account.type account_type, domain.id domain_id,
> domain.uuid domain_uuid, domain.name domain_name,
> domain.path domain_path, projects.id project_id,
> projects.uuid project_uuid, projects.name project_name
> from `cloud`.`event` inner join
> `cloud`.`account` ON event.account_id = account.id inner
> join `cloud`.`domain` ON event.domain_id = domain.id
>   inner join `cloud`.`user` ON event.user_id = user.id
> left join `cloud`.`projects` ON
> projects.project_account_id = event.account_id left join
>   `cloud`.`event` eve ON event.start_id = eve.id
> ERROR [utils.db.ScriptRunner] (Timer-2:)
> com.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException: Table
> 'event_view' already exists
> ERROR [cloud.upgrade.DatabaseUpgradeChecker] (Timer-2:) Unable to
> execute upgrade script:
>
> C:\Users\dhoogland\cloudstack\cloudstack\client\target\utilities\scripts\db\db\schema-410to420.sql
> com.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException: Table
> 'event_view' already exists
> at com.cloud.utils.db.ScriptRunner.runScript(ScriptRunner.java:193)
> at com.cloud.utils.db.ScriptRunner.runScript(ScriptRunner.java:87)
>
>  etcetera.
>
>  I checked the upgrade script which says,
>
>
>  DROP VIEW IF EXISTS `cloud`.`event_view`;
> CREATE VIEW `cloud`.`event_view` AS
> select
> event.id,
> ...
>
>  So in theory it should delete the table and not complain about it
> already existing. Am I missing something or did I hit a bug? (auto
> commit issue maybe?)
>
>  regards,
> Daan
>
>


Re: Review Request 15391: few cleanups in CertServiceTest and CertService

2013-11-11 Thread Syed Ahmed

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

Ship it!


Ship It!

- Syed Ahmed


On Nov. 10, 2013, 6:26 p.m., Laszlo Hornyak wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/15391/
> ---
> 
> (Updated Nov. 10, 2013, 6:26 p.m.)
> 
> 
> Review request for cloudstack and Syed Ahmed.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Tests:
> - all tests are @Test rather than having one test to call them, so they 
> can be run one by one
> - tests that expect exception from a method fail if there is none
> - no longer extends TestCase so that the original method names could be 
> kept as test
> 
> Implementation:
> - include root cause in exceptions when possible - helps at troubleshuting
> - close readers
> 
> 
> Diffs
> -
> 
>   server/src/org/apache/cloudstack/network/lb/CertServiceImpl.java 53dae50 
>   server/test/org/apache/cloudstack/network/lb/CertServiceTest.java e47fc01 
> 
> Diff: https://reviews.apache.org/r/15391/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Laszlo Hornyak
> 
>



4.3 Not Building (Test Failure)

2013-11-11 Thread Mike Tutkowski
Anyone know anything about this issue?

Thanks!

[INFO] Apache CloudStack Server .. FAILURE [36.923s]
[INFO] Apache CloudStack Usage Server  SKIPPED
[INFO] Apache XenSource XAPI . SKIPPED
[INFO] Apache CloudStack Cloud Engine Orchestration Component  SKIPPED
[INFO] Apache CloudStack Cloud Services .. SKIPPED
[INFO] Apache CloudStack Secondary Storage Service ... SKIPPED
[INFO] Apache CloudStack Engine Storage Component  SKIPPED
[INFO] Apache CloudStack Engine Storage Volume Component . SKIPPED
[INFO] Apache CloudStack Engine Storage Image Component .. SKIPPED
[INFO] Apache CloudStack Engine Storage Data Motion Component  SKIPPED
[INFO] Apache CloudStack Engine Storage Cache Component .. SKIPPED
[INFO] Apache CloudStack Engine Storage Snapshot Component  SKIPPED
[INFO] Apache CloudStack Cloud Engine API  SKIPPED
[INFO] Apache CloudStack Cloud Engine Service  SKIPPED
[INFO] Apache CloudStack Plugin POM .. SKIPPED
[INFO] Apache CloudStack Plugin - API Rate Limit . SKIPPED
[INFO] Apache CloudStack Plugin - API Discovery .. SKIPPED
[INFO] Apache CloudStack Plugin - ACL Static Role Based .. SKIPPED
[INFO] Apache CloudStack Plugin - Host Anti-Affinity Processor  SKIPPED
[INFO] Apache CloudStack Plugin - Explicit Dedication Processor  SKIPPED
[INFO] Apache CloudStack Plugin - User Concentrated Pod Deployment Planner
 SKIPPED
[INFO] Apache CloudStack Plugin - User Dispersing Deployment Planner
 SKIPPED
[INFO] Apache CloudStack Plugin - Implicit Dedication Planner  SKIPPED
[INFO] Apache CloudStack Plugin - Host Allocator Random .. SKIPPED
[INFO] Apache CloudStack Plugin - Dedicated Resources  SKIPPED
[INFO] Apache CloudStack Plugin - Hypervisor OracleVM  SKIPPED
[INFO] Apache CloudStack Plugin - Open vSwitch ... SKIPPED
[INFO] Apache CloudStack Plugin - Hypervisor Xen . SKIPPED
[INFO] Apache CloudStack Plugin - Hypervisor KVM . SKIPPED
[INFO] Apache CloudStack Plugin - RabbitMQ Event Bus . SKIPPED
[INFO] Apache CloudStack Plugin - Hypervisor Baremetal ... SKIPPED
[INFO] Apache CloudStack Plugin - Hypervisor UCS . SKIPPED
[INFO] Apache CloudStack Plugin - Hypervisor Hyper-V . SKIPPED
[INFO] Apache CloudStack Plugin - Network Elastic Load Balancer  SKIPPED
[INFO] Apache CloudStack Plugin - Network Internal Load Balancer  SKIPPED
[INFO] Apache CloudStack Plugin - Network Juniper Contrail  SKIPPED
[INFO] Apache CloudStack Plugin - Palo Alto .. SKIPPED
[INFO] Apache CloudStack Checkstyle Configuration  SKIPPED
[INFO] Apache CloudStack Plugin - Network Nicira NVP . SKIPPED
[INFO] Apache CloudStack Plugin - BigSwitch Virtual Network Segment  SKIPPED
[INFO] Apache CloudStack Plugin - Midokura Midonet ... SKIPPED
[INFO] Apache Cloudstack Plugin - Stratosphere SSP ... SKIPPED
[INFO] Apache CloudStack Plugin - Storage Allocator Random  SKIPPED
[INFO] Apache CloudStack Plugin - User Authenticator LDAP  SKIPPED
[INFO] Apache CloudStack Plugin - User Authenticator MD5 . SKIPPED
[INFO] Apache CloudStack Plugin - User Authenticator Plain Text  SKIPPED
[INFO] Apache CloudStack Plugin - User Authenticator SHA256 Salted  SKIPPED
[INFO] Apache CloudStack Plugin - Dns Notifier Example ... SKIPPED
[INFO] Apache CloudStack Plugin - Storage Image S3 ... SKIPPED
[INFO] Apache CloudStack Plugin - Storage Image Swift provider  SKIPPED
[INFO] Apache CloudStack Plugin - Storage Image default provider  SKIPPED
[INFO] Apache CloudStack Plugin - Storage Image sample provider  SKIPPED
[INFO] Apache CloudStack Plugin - Storage Volume SolidFire Provider  SKIPPED
[INFO] Apache CloudStack Plugin - Storage Volume default provider  SKIPPED
[INFO] Apache CloudStack Plugin - Storage Volume sample provider  SKIPPED
[INFO] Apache CloudStack Plugin - SNMP Alerts  SKIPPED
[INFO] Apache CloudStack Plugin - Syslog Alerts .. SKIPPED
[INFO] Apache CloudStack Plugin - Network VXLAN .. SKIPPED
[INFO] Apache CloudStack Framework - Spring Life Cycle ... SKIPPED
[INFO] cloud-framework-spring-module . SKIPPED
[INFO] Apache CloudStack Test  SKIPPED
[INFO] Apache CloudStack Console Proxy ... SKIPPED
[INFO] Apache CloudStack Console Proxy - Server .. SKIPPED
[INFO] Apache CloudStack System VM ... SKIPPED
[INFO] Apache CloudStack Client UI ... SKIPPED
[INFO] Apache CloudStack Console Proxy - RDP Client .. SKIPPED
[INFO] Apache CloudStack Framework - QuickCloud .. SKIPPED
[INFO] Apache CloudStack Developer Mode .. SKIPPED
[INFO] Apache CloudStack Developer Tools . SKIPPED
[INFO] Apache CloudStack apidocs . SKIPPED
[INFO] Apache CloudStack marvin .. SKIPPED
[INFO] Apache CloudStack DevCloud ..

Re: 4.3 Not Building (Test Failure)

2013-11-11 Thread Laszlo Hornyak
Hi Mike,

I do not see the failing unit test in the output but the CertServiceTest
was failing all weekend till I installed the JCE extension into my jdk6.
http://www.oracle.com/technetwork/java/javase/downloads/jce-6-download-429243.html

If it does not help. could you share the name of the problematic test? It
should be a few lines over the error message.

Thx,
Laszlo


On Mon, Nov 11, 2013 at 9:53 PM, Mike Tutkowski <
mike.tutkow...@solidfire.com> wrote:

> Anyone know anything about this issue?
>
> Thanks!
>
> [INFO] Apache CloudStack Server .. FAILURE
> [36.923s]
> [INFO] Apache CloudStack Usage Server  SKIPPED
> [INFO] Apache XenSource XAPI . SKIPPED
> [INFO] Apache CloudStack Cloud Engine Orchestration Component  SKIPPED
> [INFO] Apache CloudStack Cloud Services .. SKIPPED
> [INFO] Apache CloudStack Secondary Storage Service ... SKIPPED
> [INFO] Apache CloudStack Engine Storage Component  SKIPPED
> [INFO] Apache CloudStack Engine Storage Volume Component . SKIPPED
> [INFO] Apache CloudStack Engine Storage Image Component .. SKIPPED
> [INFO] Apache CloudStack Engine Storage Data Motion Component  SKIPPED
> [INFO] Apache CloudStack Engine Storage Cache Component .. SKIPPED
> [INFO] Apache CloudStack Engine Storage Snapshot Component  SKIPPED
> [INFO] Apache CloudStack Cloud Engine API  SKIPPED
> [INFO] Apache CloudStack Cloud Engine Service  SKIPPED
> [INFO] Apache CloudStack Plugin POM .. SKIPPED
> [INFO] Apache CloudStack Plugin - API Rate Limit . SKIPPED
> [INFO] Apache CloudStack Plugin - API Discovery .. SKIPPED
> [INFO] Apache CloudStack Plugin - ACL Static Role Based .. SKIPPED
> [INFO] Apache CloudStack Plugin - Host Anti-Affinity Processor  SKIPPED
> [INFO] Apache CloudStack Plugin - Explicit Dedication Processor  SKIPPED
> [INFO] Apache CloudStack Plugin - User Concentrated Pod Deployment Planner
>  SKIPPED
> [INFO] Apache CloudStack Plugin - User Dispersing Deployment Planner
>  SKIPPED
> [INFO] Apache CloudStack Plugin - Implicit Dedication Planner  SKIPPED
> [INFO] Apache CloudStack Plugin - Host Allocator Random .. SKIPPED
> [INFO] Apache CloudStack Plugin - Dedicated Resources  SKIPPED
> [INFO] Apache CloudStack Plugin - Hypervisor OracleVM  SKIPPED
> [INFO] Apache CloudStack Plugin - Open vSwitch ... SKIPPED
> [INFO] Apache CloudStack Plugin - Hypervisor Xen . SKIPPED
> [INFO] Apache CloudStack Plugin - Hypervisor KVM . SKIPPED
> [INFO] Apache CloudStack Plugin - RabbitMQ Event Bus . SKIPPED
> [INFO] Apache CloudStack Plugin - Hypervisor Baremetal ... SKIPPED
> [INFO] Apache CloudStack Plugin - Hypervisor UCS . SKIPPED
> [INFO] Apache CloudStack Plugin - Hypervisor Hyper-V . SKIPPED
> [INFO] Apache CloudStack Plugin - Network Elastic Load Balancer  SKIPPED
> [INFO] Apache CloudStack Plugin - Network Internal Load Balancer  SKIPPED
> [INFO] Apache CloudStack Plugin - Network Juniper Contrail  SKIPPED
> [INFO] Apache CloudStack Plugin - Palo Alto .. SKIPPED
> [INFO] Apache CloudStack Checkstyle Configuration  SKIPPED
> [INFO] Apache CloudStack Plugin - Network Nicira NVP . SKIPPED
> [INFO] Apache CloudStack Plugin - BigSwitch Virtual Network Segment
>  SKIPPED
> [INFO] Apache CloudStack Plugin - Midokura Midonet ... SKIPPED
> [INFO] Apache Cloudstack Plugin - Stratosphere SSP ... SKIPPED
> [INFO] Apache CloudStack Plugin - Storage Allocator Random  SKIPPED
> [INFO] Apache CloudStack Plugin - User Authenticator LDAP  SKIPPED
> [INFO] Apache CloudStack Plugin - User Authenticator MD5 . SKIPPED
> [INFO] Apache CloudStack Plugin - User Authenticator Plain Text  SKIPPED
> [INFO] Apache CloudStack Plugin - User Authenticator SHA256 Salted  SKIPPED
> [INFO] Apache CloudStack Plugin - Dns Notifier Example ... SKIPPED
> [INFO] Apache CloudStack Plugin - Storage Image S3 ... SKIPPED
> [INFO] Apache CloudStack Plugin - Storage Image Swift provider  SKIPPED
> [INFO] Apache CloudStack Plugin - Storage Image default provider  SKIPPED
> [INFO] Apache CloudStack Plugin - Storage Image sample provider  SKIPPED
> [INFO] Apache CloudStack Plugin - Storage Volume SolidFire Provider
>  SKIPPED
> [INFO] Apache CloudStack Plugin - Storage Volume default provider  SKIPPED
> [INFO] Apache CloudStack Plugin - Storage Volume sample provider  SKIPPED
> [INFO] Apache CloudStack Plugin - SNMP Alerts  SKIPPED
> [INFO] Apache CloudStack Plugin - Syslog Alerts .. SKIPPED
> [INFO] Apache CloudStack Plugin - Network VXLAN .. SKIPPED
> [INFO] Apache CloudStack Framework - Spring Life Cycle ... SKIPPED
> [INFO] cloud-framework-spring-module . SKIPPED
> [INFO] Apache CloudStack Test  SKIPPED
> [INFO] Apache CloudStack Console Proxy ... SKIPPED
> [INFO] Apache CloudStack Console Proxy - Serve

Re: [DISCUSS] Domain/Account/User Sync Up Among Multiple Regions

2013-11-11 Thread Alex Ough
All,

I'm new to the cloudstack project, so there can be something I missed for
consideration,
but the current region support seems to be inadequate (I hope this does not
offend anyone...)
because even if a customer can have multiple regions,
the resources in each region are totally separated like resources of
different customers.
So my personal opinion is that it looks like this functionality is
must-have not good-to-have to support the actual multiple regions.
Once again, I can be wrong, and please correct me if so.

Anyway, I've added more design specs in wiki including the consideration of
the support as a plug-in in resolving the #1 restriction.
Please review them and let me know what you think.

Thanks
Alex Ough

On Sat, Nov 9, 2013 at 8:20 AM, Daan Hoogland wrote:

> H Guys,
>
> Can you shoot at my claims below, please?
>
> syncing being optional does not conflict with the code being in the
> core server. It seems that making a plugin for this is misuse of the
> plugin mechanism. To me it is more of an option to switch on or of
> with a global setting, having some extra configuration.
>
> Also, cloudstack being a slave to the real user db is a separate issue
> from cloudstack syncing its copy.
>
> As for answerring the cap; this is a security answer as well as an
> operational answer.
>
> thanks,
> Daan
>
> On Sat, Nov 9, 2013 at 1:53 AM, Chip Childers 
> wrote:
> > We are already (generally) AP for most infra changes really. I'd use
> that model. Eventual consistency is better in this scenario.
> >
> >> On Nov 8, 2013, at 6:49 PM, Chiradeep Vittal <
> chiradeep.vit...@citrix.com> wrote:
> >>
> >> I'd also like to highlight that it isn't a trivial problem.
> >> Let's say there's 3 regions: this means there are 3 copies of the user
> >> database that are geographically separated by network links that fail
> >> quite often (orders of magnitude more than intra-DC networks).
> >>
> >> Here we run into the consequences of the CAP theorem [1].
> >> We can either have a CP or AP system: either approach makes some
> tradeoffs:
> >> 1. If we run a AP system, then the challenge is to resolve conflicting
> >> updates
> >> 2. If we run a CP system, then the challenge is to detect partitions
> >> reliably and disallow updates during partitions.
> >>
> >> [1] http://en.wikipedia.org/wiki/CAP_theorem
> >>
> >>> On 11/7/13 11:58 AM, "Chip Childers"  wrote:
> >>>
> >>> On Thu, Nov 7, 2013 at 2:37 PM, Chiradeep Vittal
> >>>  wrote:
>  It may be an admin burden, but it has to be optional. There are other
>  ways
>  to achieve global sync (e.g., LDAP/AD/Oauth).
>  A lot of service providers who run cloudstack have their own user
>  database
>  / portal. In their implementations the CloudStack database is not the
>  master source of user records, but a slave.
> >>>
> >>> +1 to it being optional.
> >>
>
>


Re: 4.3 Not Building (Test Failure)

2013-11-11 Thread Mike Tutkowski
Looks like I'm running (1.7...I believe this was for a Libvirt change):

mtutkowski-LT:cloudstack mtutkowski$ java -version
java version "1.7.0_40"
Java(TM) SE Runtime Environment (build 1.7.0_40-b43)
Java HotSpot(TM) 64-Bit Server VM (build 24.0-b56, mixed mode)

You think this might be the problem?


On Mon, Nov 11, 2013 at 2:02 PM, Laszlo Hornyak wrote:

> Hi Mike,
>
> I do not see the failing unit test in the output but the CertServiceTest
> was failing all weekend till I installed the JCE extension into my jdk6.
>
> http://www.oracle.com/technetwork/java/javase/downloads/jce-6-download-429243.html
>
> If it does not help. could you share the name of the problematic test? It
> should be a few lines over the error message.
>
> Thx,
> Laszlo
>
>
> On Mon, Nov 11, 2013 at 9:53 PM, Mike Tutkowski <
> mike.tutkow...@solidfire.com> wrote:
>
> > Anyone know anything about this issue?
> >
> > Thanks!
> >
> > [INFO] Apache CloudStack Server .. FAILURE
> > [36.923s]
> > [INFO] Apache CloudStack Usage Server  SKIPPED
> > [INFO] Apache XenSource XAPI . SKIPPED
> > [INFO] Apache CloudStack Cloud Engine Orchestration Component  SKIPPED
> > [INFO] Apache CloudStack Cloud Services .. SKIPPED
> > [INFO] Apache CloudStack Secondary Storage Service ... SKIPPED
> > [INFO] Apache CloudStack Engine Storage Component  SKIPPED
> > [INFO] Apache CloudStack Engine Storage Volume Component . SKIPPED
> > [INFO] Apache CloudStack Engine Storage Image Component .. SKIPPED
> > [INFO] Apache CloudStack Engine Storage Data Motion Component  SKIPPED
> > [INFO] Apache CloudStack Engine Storage Cache Component .. SKIPPED
> > [INFO] Apache CloudStack Engine Storage Snapshot Component  SKIPPED
> > [INFO] Apache CloudStack Cloud Engine API  SKIPPED
> > [INFO] Apache CloudStack Cloud Engine Service  SKIPPED
> > [INFO] Apache CloudStack Plugin POM .. SKIPPED
> > [INFO] Apache CloudStack Plugin - API Rate Limit . SKIPPED
> > [INFO] Apache CloudStack Plugin - API Discovery .. SKIPPED
> > [INFO] Apache CloudStack Plugin - ACL Static Role Based .. SKIPPED
> > [INFO] Apache CloudStack Plugin - Host Anti-Affinity Processor  SKIPPED
> > [INFO] Apache CloudStack Plugin - Explicit Dedication Processor  SKIPPED
> > [INFO] Apache CloudStack Plugin - User Concentrated Pod Deployment
> Planner
> >  SKIPPED
> > [INFO] Apache CloudStack Plugin - User Dispersing Deployment Planner
> >  SKIPPED
> > [INFO] Apache CloudStack Plugin - Implicit Dedication Planner  SKIPPED
> > [INFO] Apache CloudStack Plugin - Host Allocator Random .. SKIPPED
> > [INFO] Apache CloudStack Plugin - Dedicated Resources  SKIPPED
> > [INFO] Apache CloudStack Plugin - Hypervisor OracleVM  SKIPPED
> > [INFO] Apache CloudStack Plugin - Open vSwitch ... SKIPPED
> > [INFO] Apache CloudStack Plugin - Hypervisor Xen . SKIPPED
> > [INFO] Apache CloudStack Plugin - Hypervisor KVM . SKIPPED
> > [INFO] Apache CloudStack Plugin - RabbitMQ Event Bus . SKIPPED
> > [INFO] Apache CloudStack Plugin - Hypervisor Baremetal ... SKIPPED
> > [INFO] Apache CloudStack Plugin - Hypervisor UCS . SKIPPED
> > [INFO] Apache CloudStack Plugin - Hypervisor Hyper-V . SKIPPED
> > [INFO] Apache CloudStack Plugin - Network Elastic Load Balancer  SKIPPED
> > [INFO] Apache CloudStack Plugin - Network Internal Load Balancer  SKIPPED
> > [INFO] Apache CloudStack Plugin - Network Juniper Contrail  SKIPPED
> > [INFO] Apache CloudStack Plugin - Palo Alto .. SKIPPED
> > [INFO] Apache CloudStack Checkstyle Configuration  SKIPPED
> > [INFO] Apache CloudStack Plugin - Network Nicira NVP . SKIPPED
> > [INFO] Apache CloudStack Plugin - BigSwitch Virtual Network Segment
> >  SKIPPED
> > [INFO] Apache CloudStack Plugin - Midokura Midonet ... SKIPPED
> > [INFO] Apache Cloudstack Plugin - Stratosphere SSP ... SKIPPED
> > [INFO] Apache CloudStack Plugin - Storage Allocator Random  SKIPPED
> > [INFO] Apache CloudStack Plugin - User Authenticator LDAP  SKIPPED
> > [INFO] Apache CloudStack Plugin - User Authenticator MD5 . SKIPPED
> > [INFO] Apache CloudStack Plugin - User Authenticator Plain Text  SKIPPED
> > [INFO] Apache CloudStack Plugin - User Authenticator SHA256 Salted
>  SKIPPED
> > [INFO] Apache CloudStack Plugin - Dns Notifier Example ... SKIPPED
> > [INFO] Apache CloudStack Plugin - Storage Image S3 ... SKIPPED
> > [INFO] Apache CloudStack Plugin - Storage Image Swift provider  SKIPPED
> > [INFO] Apache CloudStack Plugin - Storage Image default provider  SKIPPED
> > [INFO] Apache CloudStack Plugin - Storage Image sample provider  SKIPPED
> > [INFO] Apache CloudStack Plugin - Storage Volume SolidFire Provider
> >  SKIPPED
> > [INFO] Apache CloudStack Plugin - Storage Volume default provider
>  SKIPPED
> > [INFO] Apache CloudStack Plugin - Storage Volume sample provider  SKIPPED
> > [INFO

Re: api incompatibility between 4.1 and 4.2 in ACLs

2013-11-11 Thread Marcus Sorensen
Ok, I'll dig deeper into it. Our api's ACL tests are breaking against 4.2.

On Sun, Nov 10, 2013 at 11:13 PM, Kishan Kavala
 wrote:
> Marcus,
>  aclid is optional when creating a networlACL. In 4.1, networkId is mandatory 
> for creating ACL. So, when networkId is specified instead of aclid in 4.2, CS 
> gets the aclList associated with the network and adds acl to it.
> So, API doesn't break if the aclid is not specified.
>
>> -Original Message-
>> From: Marcus Sorensen [mailto:shadow...@gmail.com]
>> Sent: Saturday, 9 November 2013 1:13 AM
>> To: dev@cloudstack.apache.org
>> Cc: Kishan Kavala
>> Subject: Re: api incompatibility between 4.1 and 4.2 in ACLs
>>
>> Yes, that would certainly maintain api compatibility if one creates an ACL
>> without specifying aclid, it creates a new list and applies it to the given 
>> network.
>>
>> On Fri, Nov 8, 2013 at 12:28 PM, Animesh Chaturvedi
>>  wrote:
>> > Actually use this link to the message in that thread
>> > http://s.apache.org/QKI
>> >
>> >
>> >
>> >> -Original Message-
>> >> From: Animesh Chaturvedi [mailto:animesh.chaturv...@citrix.com]
>> >> Sent: Friday, November 08, 2013 11:24 AM
>> >> To: dev@cloudstack.apache.org
>> >> Cc: Kishan Kavala
>> >> Subject: RE: api incompatibility between 4.1 and 4.2 in ACLs
>> >>
>> >>
>> >> I will let Kishan comment but found this thread
>> >> http://markmail.org/thread/fxzki6ftqacyrylk
>> >>
>> >>
>> >> > -Original Message-
>> >> > From: Marcus Sorensen [mailto:shadow...@gmail.com]
>> >> > Sent: Friday, November 08, 2013 9:13 AM
>> >> > To: dev@cloudstack.apache.org
>> >> > Subject: Re: api incompatibility between 4.1 and 4.2 in ACLs
>> >> >
>> >> > So I take the silence to simply be a collective "oops".  I guess
>> >> > this just should serve as a reminder to not break API compatibility
>> >> > without a discussion. Perhaps our tests will surface this better in
>> >> > the future (although I need to look, I wonder if any ACL tests were
>> >> > also simply changed to accomodate the new behavior).
>> >> >
>> >> > On Thu, Nov 7, 2013 at 2:23 PM, Marcus Sorensen
>> >> > 
>> >> > wrote:
>> >> > > Maybe this has been discussed already, but we seem to have run
>> >> > > into an api incompatibility. In 4.1, you could create ad-hoc ACL
>> >> > > rules that applied to a network. In 4.2, you have to first create
>> >> > > an 'ACL list', then add those rules to the list, then apply the
>> >> > > list to a network. Or so it seems.  This means that applications
>> >> > > that are coded to the cloudstack API and utilize createNetworkACL
>> >> > > will break, because the flow has changed.
>> >> > >
>> >> > > Am I correct on this? And if so, shouldn't we have deployed 4.2
>> >> > > as 5.0, since the stated versioning is based on API compatibility?


Re: SSL and JCE

2013-11-11 Thread Syed Ahmed

Hi Laszlo,

The CertService uses BouncyCastle for certificate parsing and 
validation. The JCE extension provides the API for using BouncyCastle as 
the provider. So, JCE is required. I know that BouncyCastle is added in 
CS. Would it be possible to add JCE as a dependency too?


Thanks,
-Syed

On 13-11-10 09:55 AM, Laszlo Hornyak wrote:

Hi Sahmed and list,

I ran into some failing tests this weekend related to the patch 
0076307863e9155273d9e4c14282de429388c9e9 apparently jenkins fails for 
the same reason. I did a short investigation and it turned out that in 
order to run the tests correctly, one has to download the sun jce 
policy files and put it in the jdk replacing the original policies.


Questions:
- Is there a more convenient deployment process? :-) It would be very 
useful for the jenkins environment as well.
- I gave it a try and patched the oracle jdk 1.7 with the same plugin, 
it did not work. Do you know a way to make it work again with jdk 1.7?


Thank you,
Laszlo

--

EOF




Re: api incompatibility between 4.1 and 4.2 in ACLs

2013-11-11 Thread Alena Prokharchyk
Marcus, if any of the CS API command(s) return the error for 
parameter/parameter combination that used to work before, then it means APIs 
are incompatible, and it has to be fixed.
Thank you for looking into it.

-Alena.

From: Marcus Sorensen mailto:shadow...@gmail.com>>
Reply-To: "dev@cloudstack.apache.org" 
mailto:dev@cloudstack.apache.org>>
Date: Monday, November 11, 2013 1:10 PM
To: "dev@cloudstack.apache.org" 
mailto:dev@cloudstack.apache.org>>
Subject: Re: api incompatibility between 4.1 and 4.2 in ACLs

Ok, I'll dig deeper into it. Our api's ACL tests are breaking against 4.2.

On Sun, Nov 10, 2013 at 11:13 PM, Kishan Kavala
mailto:kishan.kav...@citrix.com>> wrote:
Marcus,
  aclid is optional when creating a networlACL. In 4.1, networkId is mandatory 
for creating ACL. So, when networkId is specified instead of aclid in 4.2, CS 
gets the aclList associated with the network and adds acl to it.
So, API doesn't break if the aclid is not specified.

-Original Message-
From: Marcus Sorensen [mailto:shadow...@gmail.com]
Sent: Saturday, 9 November 2013 1:13 AM
To: dev@cloudstack.apache.org
Cc: Kishan Kavala
Subject: Re: api incompatibility between 4.1 and 4.2 in ACLs

Yes, that would certainly maintain api compatibility if one creates an ACL
without specifying aclid, it creates a new list and applies it to the given 
network.

On Fri, Nov 8, 2013 at 12:28 PM, Animesh Chaturvedi
mailto:animesh.chaturv...@citrix.com>> wrote:
> Actually use this link to the message in that thread
> http://s.apache.org/QKI
>
>
>
>> -Original Message-
>> From: Animesh Chaturvedi [mailto:animesh.chaturv...@citrix.com]
>> Sent: Friday, November 08, 2013 11:24 AM
>> To: dev@cloudstack.apache.org
>> Cc: Kishan Kavala
>> Subject: RE: api incompatibility between 4.1 and 4.2 in ACLs
>>
>>
>> I will let Kishan comment but found this thread
>> http://markmail.org/thread/fxzki6ftqacyrylk
>>
>>
>> > -Original Message-
>> > From: Marcus Sorensen [mailto:shadow...@gmail.com]
>> > Sent: Friday, November 08, 2013 9:13 AM
>> > To: dev@cloudstack.apache.org
>> > Subject: Re: api incompatibility between 4.1 and 4.2 in ACLs
>> >
>> > So I take the silence to simply be a collective "oops".  I guess
>> > this just should serve as a reminder to not break API compatibility
>> > without a discussion. Perhaps our tests will surface this better in
>> > the future (although I need to look, I wonder if any ACL tests were
>> > also simply changed to accomodate the new behavior).
>> >
>> > On Thu, Nov 7, 2013 at 2:23 PM, Marcus Sorensen
>> > mailto:shadow...@gmail.com>>
>> > wrote:
>> > > Maybe this has been discussed already, but we seem to have run
>> > > into an api incompatibility. In 4.1, you could create ad-hoc ACL
>> > > rules that applied to a network. In 4.2, you have to first create
>> > > an 'ACL list', then add those rules to the list, then apply the
>> > > list to a network. Or so it seems.  This means that applications
>> > > that are coded to the cloudstack API and utilize createNetworkACL
>> > > will break, because the flow has changed.
>> > >
>> > > Am I correct on this? And if so, shouldn't we have deployed 4.2
>> > > as 5.0, since the stated versioning is based on API compatibility?



Re: 4.3 Not Building (Test Failure)

2013-11-11 Thread Wei ZHOU
I built succeed with jdk 1.6 and jdk 1.7

Maybe some packages are missing in your environment.
You can get some information
from 
/Users/mtutkowski/Documents/CloudStack/src/CloudStack/server/target/surefire-reports

2013/11/11 Mike Tutkowski 

> Looks like I'm running (1.7...I believe this was for a Libvirt change):
>
> mtutkowski-LT:cloudstack mtutkowski$ java -version
> java version "1.7.0_40"
> Java(TM) SE Runtime Environment (build 1.7.0_40-b43)
> Java HotSpot(TM) 64-Bit Server VM (build 24.0-b56, mixed mode)
>
> You think this might be the problem?
>
>
> On Mon, Nov 11, 2013 at 2:02 PM, Laszlo Hornyak  >wrote:
>
> > Hi Mike,
> >
> > I do not see the failing unit test in the output but the CertServiceTest
> > was failing all weekend till I installed the JCE extension into my jdk6.
> >
> >
> http://www.oracle.com/technetwork/java/javase/downloads/jce-6-download-429243.html
> >
> > If it does not help. could you share the name of the problematic test? It
> > should be a few lines over the error message.
> >
> > Thx,
> > Laszlo
> >
> >
> > On Mon, Nov 11, 2013 at 9:53 PM, Mike Tutkowski <
> > mike.tutkow...@solidfire.com> wrote:
> >
> > > Anyone know anything about this issue?
> > >
> > > Thanks!
> > >
> > > [INFO] Apache CloudStack Server .. FAILURE
> > > [36.923s]
> > > [INFO] Apache CloudStack Usage Server  SKIPPED
> > > [INFO] Apache XenSource XAPI . SKIPPED
> > > [INFO] Apache CloudStack Cloud Engine Orchestration Component  SKIPPED
> > > [INFO] Apache CloudStack Cloud Services .. SKIPPED
> > > [INFO] Apache CloudStack Secondary Storage Service ... SKIPPED
> > > [INFO] Apache CloudStack Engine Storage Component  SKIPPED
> > > [INFO] Apache CloudStack Engine Storage Volume Component . SKIPPED
> > > [INFO] Apache CloudStack Engine Storage Image Component .. SKIPPED
> > > [INFO] Apache CloudStack Engine Storage Data Motion Component  SKIPPED
> > > [INFO] Apache CloudStack Engine Storage Cache Component .. SKIPPED
> > > [INFO] Apache CloudStack Engine Storage Snapshot Component  SKIPPED
> > > [INFO] Apache CloudStack Cloud Engine API  SKIPPED
> > > [INFO] Apache CloudStack Cloud Engine Service  SKIPPED
> > > [INFO] Apache CloudStack Plugin POM .. SKIPPED
> > > [INFO] Apache CloudStack Plugin - API Rate Limit . SKIPPED
> > > [INFO] Apache CloudStack Plugin - API Discovery .. SKIPPED
> > > [INFO] Apache CloudStack Plugin - ACL Static Role Based .. SKIPPED
> > > [INFO] Apache CloudStack Plugin - Host Anti-Affinity Processor  SKIPPED
> > > [INFO] Apache CloudStack Plugin - Explicit Dedication Processor
>  SKIPPED
> > > [INFO] Apache CloudStack Plugin - User Concentrated Pod Deployment
> > Planner
> > >  SKIPPED
> > > [INFO] Apache CloudStack Plugin - User Dispersing Deployment Planner
> > >  SKIPPED
> > > [INFO] Apache CloudStack Plugin - Implicit Dedication Planner  SKIPPED
> > > [INFO] Apache CloudStack Plugin - Host Allocator Random .. SKIPPED
> > > [INFO] Apache CloudStack Plugin - Dedicated Resources  SKIPPED
> > > [INFO] Apache CloudStack Plugin - Hypervisor OracleVM  SKIPPED
> > > [INFO] Apache CloudStack Plugin - Open vSwitch ... SKIPPED
> > > [INFO] Apache CloudStack Plugin - Hypervisor Xen . SKIPPED
> > > [INFO] Apache CloudStack Plugin - Hypervisor KVM . SKIPPED
> > > [INFO] Apache CloudStack Plugin - RabbitMQ Event Bus . SKIPPED
> > > [INFO] Apache CloudStack Plugin - Hypervisor Baremetal ... SKIPPED
> > > [INFO] Apache CloudStack Plugin - Hypervisor UCS . SKIPPED
> > > [INFO] Apache CloudStack Plugin - Hypervisor Hyper-V . SKIPPED
> > > [INFO] Apache CloudStack Plugin - Network Elastic Load Balancer
>  SKIPPED
> > > [INFO] Apache CloudStack Plugin - Network Internal Load Balancer
>  SKIPPED
> > > [INFO] Apache CloudStack Plugin - Network Juniper Contrail  SKIPPED
> > > [INFO] Apache CloudStack Plugin - Palo Alto .. SKIPPED
> > > [INFO] Apache CloudStack Checkstyle Configuration  SKIPPED
> > > [INFO] Apache CloudStack Plugin - Network Nicira NVP . SKIPPED
> > > [INFO] Apache CloudStack Plugin - BigSwitch Virtual Network Segment
> > >  SKIPPED
> > > [INFO] Apache CloudStack Plugin - Midokura Midonet ... SKIPPED
> > > [INFO] Apache Cloudstack Plugin - Stratosphere SSP ... SKIPPED
> > > [INFO] Apache CloudStack Plugin - Storage Allocator Random  SKIPPED
> > > [INFO] Apache CloudStack Plugin - User Authenticator LDAP  SKIPPED
> > > [INFO] Apache CloudStack Plugin - User Authenticator MD5 . SKIPPED
> > > [INFO] Apache CloudStack Plugin - User Authenticator Plain Text
>  SKIPPED
> > > [INFO] Apache CloudStack Plugin - User Authenticator SHA256 Salted
> >  SKIPPED
> > > [INFO] Apache CloudStack Plugin - Dns Notifier Example ... SKIPPED
> > > [INFO] Apache CloudStack Plugin - Storage Image S3 ... SKIPPED
> > > [INFO] Apache CloudStack Plugin - Storage Image Swi

Re: 4.3 Not Building (Test Failure)

2013-11-11 Thread Mike Tutkowski
Thanks, Wei.

Does this assert failure look familiar to you?

---

Test set: org.apache.cloudstack.network.lb.CertServiceTest

---

Tests run: 2, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.817 sec
<<< FAILURE!

testUploadSslCert(org.apache.cloudstack.network.lb.CertServiceTest)  Time
elapsed: 0.806 sec  <<< FAILURE!

junit.framework.AssertionFailedError

at junit.framework.Assert.fail(Assert.java:48)

at junit.framework.Assert.assertTrue(Assert.java:20)

at junit.framework.Assert.assertTrue(Assert.java:27)

at
org.apache.cloudstack.network.lb.CertServiceTest.runUploadSslCertNoChain(CertServiceTest.java:401)

at
org.apache.cloudstack.network.lb.CertServiceTest.testUploadSslCert(CertServiceTest.java:95)

at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)

at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

at java.lang.reflect.Method.invoke(Method.java:606)

at junit.framework.TestCase.runTest(TestCase.java:168)

at junit.framework.TestCase.runBare(TestCase.java:134)

at junit.framework.TestResult$1.protect(TestResult.java:110)

at junit.framework.TestResult.runProtected(TestResult.java:128)

at junit.framework.TestResult.run(TestResult.java:113)

at junit.framework.TestCase.run(TestCase.java:124)

at junit.framework.TestSuite.runTest(TestSuite.java:243)

at junit.framework.TestSuite.run(TestSuite.java:238)

at
org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:83)

at
org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:236)

at
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:134)

at
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:113)

at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)

at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

at java.lang.reflect.Method.invoke(Method.java:606)

at
org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)

at
org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)

at
org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)

at
org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:103)

at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:74)


On Mon, Nov 11, 2013 at 2:28 PM, Wei ZHOU  wrote:

> I built succeed with jdk 1.6 and jdk 1.7
>
> Maybe some packages are missing in your environment.
> You can get some information
> from
> /Users/mtutkowski/Documents/CloudStack/src/CloudStack/server/target/surefire-reports
>
> 2013/11/11 Mike Tutkowski 
>
> > Looks like I'm running (1.7...I believe this was for a Libvirt change):
> >
> > mtutkowski-LT:cloudstack mtutkowski$ java -version
> > java version "1.7.0_40"
> > Java(TM) SE Runtime Environment (build 1.7.0_40-b43)
> > Java HotSpot(TM) 64-Bit Server VM (build 24.0-b56, mixed mode)
> >
> > You think this might be the problem?
> >
> >
> > On Mon, Nov 11, 2013 at 2:02 PM, Laszlo Hornyak <
> laszlo.horn...@gmail.com
> > >wrote:
> >
> > > Hi Mike,
> > >
> > > I do not see the failing unit test in the output but the
> CertServiceTest
> > > was failing all weekend till I installed the JCE extension into my
> jdk6.
> > >
> > >
> >
> http://www.oracle.com/technetwork/java/javase/downloads/jce-6-download-429243.html
> > >
> > > If it does not help. could you share the name of the problematic test?
> It
> > > should be a few lines over the error message.
> > >
> > > Thx,
> > > Laszlo
> > >
> > >
> > > On Mon, Nov 11, 2013 at 9:53 PM, Mike Tutkowski <
> > > mike.tutkow...@solidfire.com> wrote:
> > >
> > > > Anyone know anything about this issue?
> > > >
> > > > Thanks!
> > > >
> > > > [INFO] Apache CloudStack Server .. FAILURE
> > > > [36.923s]
> > > > [INFO] Apache CloudStack Usage Server  SKIPPED
> > > > [INFO] Apache XenSource XAPI . SKIPPED
> > > > [INFO] Apache CloudStack Cloud Engine Orchestration Component
>  SKIPPED
> > > > [INFO] Apache CloudStack Cloud Services .. SKIPPED
> > > > [INFO] Apache CloudStack Secondary Storage Service ... SKIPPED
> > > > [INFO] Apache CloudStack Engine Storage Component  SKIPPED
> > > > [INFO] Apache CloudStack Engine Storage Volume Component . SKIPPED
> > > > [INFO] Apache CloudStack Engine Storage Image Component .. SKIPPED
> > > > [INFO] Apache CloudStack Engine Storage Data Motion Component
>  SKIPPED
> > > > [INFO] Apache CloudStack Engine Storage Cache Component .. SKIPPED
> > > > [INFO] Apache CloudStack 

Re: 4.3 Not Building (Test Failure)

2013-11-11 Thread Syed Ahmed

Hi Mike,

Can you try and install the JCE extensions suggested by Laszlo?

Thanks,
-Syed

On 13-11-11 04:34 PM, Mike Tutkowski wrote:

Thanks, Wei.

Does this assert failure look familiar to you?

---

Test set: org.apache.cloudstack.network.lb.CertServiceTest

---

Tests run: 2, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.817 sec
<<< FAILURE!

testUploadSslCert(org.apache.cloudstack.network.lb.CertServiceTest)  Time
elapsed: 0.806 sec  <<< FAILURE!

junit.framework.AssertionFailedError

at junit.framework.Assert.fail(Assert.java:48)

at junit.framework.Assert.assertTrue(Assert.java:20)

at junit.framework.Assert.assertTrue(Assert.java:27)

at
org.apache.cloudstack.network.lb.CertServiceTest.runUploadSslCertNoChain(CertServiceTest.java:401)

at
org.apache.cloudstack.network.lb.CertServiceTest.testUploadSslCert(CertServiceTest.java:95)

at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)

at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

at java.lang.reflect.Method.invoke(Method.java:606)

at junit.framework.TestCase.runTest(TestCase.java:168)

at junit.framework.TestCase.runBare(TestCase.java:134)

at junit.framework.TestResult$1.protect(TestResult.java:110)

at junit.framework.TestResult.runProtected(TestResult.java:128)

at junit.framework.TestResult.run(TestResult.java:113)

at junit.framework.TestCase.run(TestCase.java:124)

at junit.framework.TestSuite.runTest(TestSuite.java:243)

at junit.framework.TestSuite.run(TestSuite.java:238)

at
org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:83)

at
org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:236)

at
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:134)

at
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:113)

at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)

at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

at java.lang.reflect.Method.invoke(Method.java:606)

at
org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)

at
org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)

at
org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)

at
org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:103)

at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:74)


On Mon, Nov 11, 2013 at 2:28 PM, Wei ZHOU  wrote:


I built succeed with jdk 1.6 and jdk 1.7

Maybe some packages are missing in your environment.
You can get some information
from
/Users/mtutkowski/Documents/CloudStack/src/CloudStack/server/target/surefire-reports

2013/11/11 Mike Tutkowski 


Looks like I'm running (1.7...I believe this was for a Libvirt change):

mtutkowski-LT:cloudstack mtutkowski$ java -version
java version "1.7.0_40"
Java(TM) SE Runtime Environment (build 1.7.0_40-b43)
Java HotSpot(TM) 64-Bit Server VM (build 24.0-b56, mixed mode)

You think this might be the problem?


On Mon, Nov 11, 2013 at 2:02 PM, Laszlo Hornyak <

laszlo.horn...@gmail.com

wrote:
Hi Mike,

I do not see the failing unit test in the output but the

CertServiceTest

was failing all weekend till I installed the JCE extension into my

jdk6.



http://www.oracle.com/technetwork/java/javase/downloads/jce-6-download-429243.html

If it does not help. could you share the name of the problematic test?

It

should be a few lines over the error message.

Thx,
Laszlo


On Mon, Nov 11, 2013 at 9:53 PM, Mike Tutkowski <
mike.tutkow...@solidfire.com> wrote:


Anyone know anything about this issue?

Thanks!

[INFO] Apache CloudStack Server .. FAILURE
[36.923s]
[INFO] Apache CloudStack Usage Server  SKIPPED
[INFO] Apache XenSource XAPI . SKIPPED
[INFO] Apache CloudStack Cloud Engine Orchestration Component

  SKIPPED

[INFO] Apache CloudStack Cloud Services .. SKIPPED
[INFO] Apache CloudStack Secondary Storage Service ... SKIPPED
[INFO] Apache CloudStack Engine Storage Component  SKIPPED
[INFO] Apache CloudStack Engine Storage Volume Component . SKIPPED
[INFO] Apache CloudStack Engine Storage Image Component .. SKIPPED
[INFO] Apache CloudStack Engine Storage Data Motion Component

  SKIPPED

[INFO] Apache CloudStack Engine Storage Cache Component .. SKIPPED
[INFO] Apache CloudStack Engine Storage Snapshot Component  SKIPPED
[INFO] Apache CloudStack Cloud Engine API  SKIPPED
[INFO] Apache CloudStack Cloud Engine Service .

Re: SSL and JCE

2013-11-11 Thread Laszlo Hornyak
Hi,

That is a good question, I do not know for sure, but this package needs to
be signed by oracle, it is not redistributable and has teritorial import
restrictions, so it could be problematic :-( I hope it is not. Guys, can
someone help us here?


On Mon, Nov 11, 2013 at 10:21 PM, Syed Ahmed  wrote:

> Hi Laszlo,
>
> The CertService uses BouncyCastle for certificate parsing and validation.
> The JCE extension provides the API for using BouncyCastle as the provider.
> So, JCE is required. I know that BouncyCastle is added in CS. Would it be
> possible to add JCE as a dependency too?
>
> Thanks,
> -Syed
>
>
> On 13-11-10 09:55 AM, Laszlo Hornyak wrote:
>
>> Hi Sahmed and list,
>>
>> I ran into some failing tests this weekend related to the patch
>> 0076307863e9155273d9e4c14282de429388c9e9 apparently jenkins fails for
>> the same reason. I did a short investigation and it turned out that in
>> order to run the tests correctly, one has to download the sun jce policy
>> files and put it in the jdk replacing the original policies.
>>
>> Questions:
>> - Is there a more convenient deployment process? :-) It would be very
>> useful for the jenkins environment as well.
>> - I gave it a try and patched the oracle jdk 1.7 with the same plugin, it
>> did not work. Do you know a way to make it work again with jdk 1.7?
>>
>> Thank you,
>> Laszlo
>>
>> --
>>
>> EOF
>>
>
>


-- 

EOF


Re: 4.3 Not Building (Test Failure)

2013-11-11 Thread Mike Tutkowski
Per the install directions, I placed local_policy.jar and
US_export_policy.jar in /lib/security.

My build failed at the same test.

I also get 61 compile errors in Eclipse.


On Mon, Nov 11, 2013 at 2:40 PM, Syed Ahmed  wrote:

> Hi Mike,
>
> Can you try and install the JCE extensions suggested by Laszlo?
>
> Thanks,
> -Syed
>
>
> On 13-11-11 04:34 PM, Mike Tutkowski wrote:
>
>> Thanks, Wei.
>>
>> Does this assert failure look familiar to you?
>>
>> 
>> ---
>>
>> Test set: org.apache.cloudstack.network.lb.CertServiceTest
>>
>> 
>> ---
>>
>> Tests run: 2, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.817 sec
>> <<< FAILURE!
>>
>> testUploadSslCert(org.apache.cloudstack.network.lb.CertServiceTest)  Time
>> elapsed: 0.806 sec  <<< FAILURE!
>>
>> junit.framework.AssertionFailedError
>>
>> at junit.framework.Assert.fail(Assert.java:48)
>>
>> at junit.framework.Assert.assertTrue(Assert.java:20)
>>
>> at junit.framework.Assert.assertTrue(Assert.java:27)
>>
>> at
>> org.apache.cloudstack.network.lb.CertServiceTest.runUploadSslCertNoChain(
>> CertServiceTest.java:401)
>>
>> at
>> org.apache.cloudstack.network.lb.CertServiceTest.testUploadSslCert(
>> CertServiceTest.java:95)
>>
>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>
>> at
>> sun.reflect.NativeMethodAccessorImpl.invoke(
>> NativeMethodAccessorImpl.java:57)
>>
>> at
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(
>> DelegatingMethodAccessorImpl.java:43)
>>
>> at java.lang.reflect.Method.invoke(Method.java:606)
>>
>> at junit.framework.TestCase.runTest(TestCase.java:168)
>>
>> at junit.framework.TestCase.runBare(TestCase.java:134)
>>
>> at junit.framework.TestResult$1.protect(TestResult.java:110)
>>
>> at junit.framework.TestResult.runProtected(TestResult.java:128)
>>
>> at junit.framework.TestResult.run(TestResult.java:113)
>>
>> at junit.framework.TestCase.run(TestCase.java:124)
>>
>> at junit.framework.TestSuite.runTest(TestSuite.java:243)
>>
>> at junit.framework.TestSuite.run(TestSuite.java:238)
>>
>> at
>> org.junit.internal.runners.JUnit38ClassRunner.run(
>> JUnit38ClassRunner.java:83)
>>
>> at
>> org.apache.maven.surefire.junit4.JUnit4Provider.execute(
>> JUnit4Provider.java:236)
>>
>> at
>> org.apache.maven.surefire.junit4.JUnit4Provider.
>> executeTestSet(JUnit4Provider.java:134)
>>
>> at
>> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(
>> JUnit4Provider.java:113)
>>
>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>
>> at
>> sun.reflect.NativeMethodAccessorImpl.invoke(
>> NativeMethodAccessorImpl.java:57)
>>
>> at
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(
>> DelegatingMethodAccessorImpl.java:43)
>>
>> at java.lang.reflect.Method.invoke(Method.java:606)
>>
>> at
>> org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(
>> ReflectionUtils.java:189)
>>
>> at
>> org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(
>> ProviderFactory.java:165)
>>
>> at
>> org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(
>> ProviderFactory.java:85)
>>
>> at
>> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(
>> ForkedBooter.java:103)
>>
>> at org.apache.maven.surefire.booter.ForkedBooter.main(
>> ForkedBooter.java:74)
>>
>>
>> On Mon, Nov 11, 2013 at 2:28 PM, Wei ZHOU  wrote:
>>
>>  I built succeed with jdk 1.6 and jdk 1.7
>>>
>>> Maybe some packages are missing in your environment.
>>> You can get some information
>>> from
>>> /Users/mtutkowski/Documents/CloudStack/src/CloudStack/
>>> server/target/surefire-reports
>>>
>>> 2013/11/11 Mike Tutkowski 
>>>
>>>  Looks like I'm running (1.7...I believe this was for a Libvirt change):

 mtutkowski-LT:cloudstack mtutkowski$ java -version
 java version "1.7.0_40"
 Java(TM) SE Runtime Environment (build 1.7.0_40-b43)
 Java HotSpot(TM) 64-Bit Server VM (build 24.0-b56, mixed mode)

 You think this might be the problem?


 On Mon, Nov 11, 2013 at 2:02 PM, Laszlo Hornyak <

>>> laszlo.horn...@gmail.com
>>>
 wrote:
> Hi Mike,
>
> I do not see the failing unit test in the output but the
>
 CertServiceTest
>>>
 was failing all weekend till I installed the JCE extension into my
>
 jdk6.
>>>

>  http://www.oracle.com/technetwork/java/javase/
>>> downloads/jce-6-download-429243.html
>>>
 If it does not help. could you share the name of the problematic test?
>
 It
>>>
 should be a few lines over the error message.
>
> Thx,
> Laszlo
>
>
> On Mon, Nov 11, 2013 at 9:53 PM, Mike Tutkowski <
> mike.tutkow...@solidfire.com> wrote:
>
>  Anyone know anything about this issue?
>>
>> Thanks!
>>
>> [INFO] Apache CloudStack Server .. FAILURE
>> [36.923s]
>> [INFO] Apache CloudStack Us

Re: 4.3 Not Building (Test Failure)

2013-11-11 Thread Laszlo Hornyak
I believe it must be /jre/lib/security


On Mon, Nov 11, 2013 at 11:02 PM, Mike Tutkowski <
mike.tutkow...@solidfire.com> wrote:

> Per the install directions, I placed local_policy.jar and
> US_export_policy.jar in /lib/security.
>
> My build failed at the same test.
>
> I also get 61 compile errors in Eclipse.
>
>
> On Mon, Nov 11, 2013 at 2:40 PM, Syed Ahmed  wrote:
>
> > Hi Mike,
> >
> > Can you try and install the JCE extensions suggested by Laszlo?
> >
> > Thanks,
> > -Syed
> >
> >
> > On 13-11-11 04:34 PM, Mike Tutkowski wrote:
> >
> >> Thanks, Wei.
> >>
> >> Does this assert failure look familiar to you?
> >>
> >> 
> >> ---
> >>
> >> Test set: org.apache.cloudstack.network.lb.CertServiceTest
> >>
> >> 
> >> ---
> >>
> >> Tests run: 2, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.817
> sec
> >> <<< FAILURE!
> >>
> >> testUploadSslCert(org.apache.cloudstack.network.lb.CertServiceTest)
>  Time
> >> elapsed: 0.806 sec  <<< FAILURE!
> >>
> >> junit.framework.AssertionFailedError
> >>
> >> at junit.framework.Assert.fail(Assert.java:48)
> >>
> >> at junit.framework.Assert.assertTrue(Assert.java:20)
> >>
> >> at junit.framework.Assert.assertTrue(Assert.java:27)
> >>
> >> at
> >>
> org.apache.cloudstack.network.lb.CertServiceTest.runUploadSslCertNoChain(
> >> CertServiceTest.java:401)
> >>
> >> at
> >> org.apache.cloudstack.network.lb.CertServiceTest.testUploadSslCert(
> >> CertServiceTest.java:95)
> >>
> >> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> >>
> >> at
> >> sun.reflect.NativeMethodAccessorImpl.invoke(
> >> NativeMethodAccessorImpl.java:57)
> >>
> >> at
> >> sun.reflect.DelegatingMethodAccessorImpl.invoke(
> >> DelegatingMethodAccessorImpl.java:43)
> >>
> >> at java.lang.reflect.Method.invoke(Method.java:606)
> >>
> >> at junit.framework.TestCase.runTest(TestCase.java:168)
> >>
> >> at junit.framework.TestCase.runBare(TestCase.java:134)
> >>
> >> at junit.framework.TestResult$1.protect(TestResult.java:110)
> >>
> >> at junit.framework.TestResult.runProtected(TestResult.java:128)
> >>
> >> at junit.framework.TestResult.run(TestResult.java:113)
> >>
> >> at junit.framework.TestCase.run(TestCase.java:124)
> >>
> >> at junit.framework.TestSuite.runTest(TestSuite.java:243)
> >>
> >> at junit.framework.TestSuite.run(TestSuite.java:238)
> >>
> >> at
> >> org.junit.internal.runners.JUnit38ClassRunner.run(
> >> JUnit38ClassRunner.java:83)
> >>
> >> at
> >> org.apache.maven.surefire.junit4.JUnit4Provider.execute(
> >> JUnit4Provider.java:236)
> >>
> >> at
> >> org.apache.maven.surefire.junit4.JUnit4Provider.
> >> executeTestSet(JUnit4Provider.java:134)
> >>
> >> at
> >> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(
> >> JUnit4Provider.java:113)
> >>
> >> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> >>
> >> at
> >> sun.reflect.NativeMethodAccessorImpl.invoke(
> >> NativeMethodAccessorImpl.java:57)
> >>
> >> at
> >> sun.reflect.DelegatingMethodAccessorImpl.invoke(
> >> DelegatingMethodAccessorImpl.java:43)
> >>
> >> at java.lang.reflect.Method.invoke(Method.java:606)
> >>
> >> at
> >> org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(
> >> ReflectionUtils.java:189)
> >>
> >> at
> >> org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(
> >> ProviderFactory.java:165)
> >>
> >> at
> >> org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(
> >> ProviderFactory.java:85)
> >>
> >> at
> >> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(
> >> ForkedBooter.java:103)
> >>
> >> at org.apache.maven.surefire.booter.ForkedBooter.main(
> >> ForkedBooter.java:74)
> >>
> >>
> >> On Mon, Nov 11, 2013 at 2:28 PM, Wei ZHOU 
> wrote:
> >>
> >>  I built succeed with jdk 1.6 and jdk 1.7
> >>>
> >>> Maybe some packages are missing in your environment.
> >>> You can get some information
> >>> from
> >>> /Users/mtutkowski/Documents/CloudStack/src/CloudStack/
> >>> server/target/surefire-reports
> >>>
> >>> 2013/11/11 Mike Tutkowski 
> >>>
> >>>  Looks like I'm running (1.7...I believe this was for a Libvirt
> change):
> 
>  mtutkowski-LT:cloudstack mtutkowski$ java -version
>  java version "1.7.0_40"
>  Java(TM) SE Runtime Environment (build 1.7.0_40-b43)
>  Java HotSpot(TM) 64-Bit Server VM (build 24.0-b56, mixed mode)
> 
>  You think this might be the problem?
> 
> 
>  On Mon, Nov 11, 2013 at 2:02 PM, Laszlo Hornyak <
> 
> >>> laszlo.horn...@gmail.com
> >>>
>  wrote:
> > Hi Mike,
> >
> > I do not see the failing unit test in the output but the
> >
>  CertServiceTest
> >>>
>  was failing all weekend till I installed the JCE extension into my
> >
>  jdk6.
> >>>
> 
> >  http://www.oracle.com/technetwork/java/javase/
> >>> downloads/jce-6-download-429243.html
> >>>
>  If it do

Re: 4.3 Not Building (Test Failure)

2013-11-11 Thread Mike Tutkowski
Ah, you are correct - thanks!

I can now get the system to build and the tests to run again. :)


On Mon, Nov 11, 2013 at 3:04 PM, Laszlo Hornyak wrote:

> I believe it must be /jre/lib/security
>
>
> On Mon, Nov 11, 2013 at 11:02 PM, Mike Tutkowski <
> mike.tutkow...@solidfire.com> wrote:
>
> > Per the install directions, I placed local_policy.jar and
> > US_export_policy.jar in /lib/security.
> >
> > My build failed at the same test.
> >
> > I also get 61 compile errors in Eclipse.
> >
> >
> > On Mon, Nov 11, 2013 at 2:40 PM, Syed Ahmed  wrote:
> >
> > > Hi Mike,
> > >
> > > Can you try and install the JCE extensions suggested by Laszlo?
> > >
> > > Thanks,
> > > -Syed
> > >
> > >
> > > On 13-11-11 04:34 PM, Mike Tutkowski wrote:
> > >
> > >> Thanks, Wei.
> > >>
> > >> Does this assert failure look familiar to you?
> > >>
> > >> 
> > >> ---
> > >>
> > >> Test set: org.apache.cloudstack.network.lb.CertServiceTest
> > >>
> > >> 
> > >> ---
> > >>
> > >> Tests run: 2, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.817
> > sec
> > >> <<< FAILURE!
> > >>
> > >> testUploadSslCert(org.apache.cloudstack.network.lb.CertServiceTest)
> >  Time
> > >> elapsed: 0.806 sec  <<< FAILURE!
> > >>
> > >> junit.framework.AssertionFailedError
> > >>
> > >> at junit.framework.Assert.fail(Assert.java:48)
> > >>
> > >> at junit.framework.Assert.assertTrue(Assert.java:20)
> > >>
> > >> at junit.framework.Assert.assertTrue(Assert.java:27)
> > >>
> > >> at
> > >>
> > org.apache.cloudstack.network.lb.CertServiceTest.runUploadSslCertNoChain(
> > >> CertServiceTest.java:401)
> > >>
> > >> at
> > >> org.apache.cloudstack.network.lb.CertServiceTest.testUploadSslCert(
> > >> CertServiceTest.java:95)
> > >>
> > >> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> > >>
> > >> at
> > >> sun.reflect.NativeMethodAccessorImpl.invoke(
> > >> NativeMethodAccessorImpl.java:57)
> > >>
> > >> at
> > >> sun.reflect.DelegatingMethodAccessorImpl.invoke(
> > >> DelegatingMethodAccessorImpl.java:43)
> > >>
> > >> at java.lang.reflect.Method.invoke(Method.java:606)
> > >>
> > >> at junit.framework.TestCase.runTest(TestCase.java:168)
> > >>
> > >> at junit.framework.TestCase.runBare(TestCase.java:134)
> > >>
> > >> at junit.framework.TestResult$1.protect(TestResult.java:110)
> > >>
> > >> at junit.framework.TestResult.runProtected(TestResult.java:128)
> > >>
> > >> at junit.framework.TestResult.run(TestResult.java:113)
> > >>
> > >> at junit.framework.TestCase.run(TestCase.java:124)
> > >>
> > >> at junit.framework.TestSuite.runTest(TestSuite.java:243)
> > >>
> > >> at junit.framework.TestSuite.run(TestSuite.java:238)
> > >>
> > >> at
> > >> org.junit.internal.runners.JUnit38ClassRunner.run(
> > >> JUnit38ClassRunner.java:83)
> > >>
> > >> at
> > >> org.apache.maven.surefire.junit4.JUnit4Provider.execute(
> > >> JUnit4Provider.java:236)
> > >>
> > >> at
> > >> org.apache.maven.surefire.junit4.JUnit4Provider.
> > >> executeTestSet(JUnit4Provider.java:134)
> > >>
> > >> at
> > >> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(
> > >> JUnit4Provider.java:113)
> > >>
> > >> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> > >>
> > >> at
> > >> sun.reflect.NativeMethodAccessorImpl.invoke(
> > >> NativeMethodAccessorImpl.java:57)
> > >>
> > >> at
> > >> sun.reflect.DelegatingMethodAccessorImpl.invoke(
> > >> DelegatingMethodAccessorImpl.java:43)
> > >>
> > >> at java.lang.reflect.Method.invoke(Method.java:606)
> > >>
> > >> at
> > >> org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(
> > >> ReflectionUtils.java:189)
> > >>
> > >> at
> > >> org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(
> > >> ProviderFactory.java:165)
> > >>
> > >> at
> > >> org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(
> > >> ProviderFactory.java:85)
> > >>
> > >> at
> > >> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(
> > >> ForkedBooter.java:103)
> > >>
> > >> at org.apache.maven.surefire.booter.ForkedBooter.main(
> > >> ForkedBooter.java:74)
> > >>
> > >>
> > >> On Mon, Nov 11, 2013 at 2:28 PM, Wei ZHOU 
> > wrote:
> > >>
> > >>  I built succeed with jdk 1.6 and jdk 1.7
> > >>>
> > >>> Maybe some packages are missing in your environment.
> > >>> You can get some information
> > >>> from
> > >>> /Users/mtutkowski/Documents/CloudStack/src/CloudStack/
> > >>> server/target/surefire-reports
> > >>>
> > >>> 2013/11/11 Mike Tutkowski 
> > >>>
> > >>>  Looks like I'm running (1.7...I believe this was for a Libvirt
> > change):
> > 
> >  mtutkowski-LT:cloudstack mtutkowski$ java -version
> >  java version "1.7.0_40"
> >  Java(TM) SE Runtime Environment (build 1.7.0_40-b43)
> >  Java HotSpot(TM) 64-Bit Server VM (build 24.0-b56, mixed mode)
> > 
> >  You think this might be the problem?
> > 
> 

Re: api incompatibility between 4.1 and 4.2 in ACLs

2013-11-11 Thread Marcus Sorensen
Sorry for the back and forth,  I'm interfacing with individuals who
consume our CloudStack environment. I'm being told that the issues
actually aren't related to API parameters, but behavior of the API
calls:

1) As a user, listing network ACLs now shows ALL ACLs, not just the
ones you own. An example test that was shown to me created a new user,
listed ACLs, then created two ACLs and listed again.  Previously, the
result would be 0, then 2 ACLs. Now, we get 24 and 26, as the brand
new user sees all ACLs.

2) Test case used to succeed by failing when duplicate or overlapping
ACLs were created. Now, they're allowed.  I have yet to duplicate this
and see if it causes problems for virtual routers.

I'll try to confirm/duplicate and create JIRA issues for these if I
don't get a response back from someone explaining/validating the new
behavior.

On Mon, Nov 11, 2013 at 2:22 PM, Alena Prokharchyk
 wrote:
> Marcus, if any of the CS API command(s) return the error for
> parameter/parameter combination that used to work before, then it means APIs
> are incompatible, and it has to be fixed.
> Thank you for looking into it.
>
> -Alena.
>
> From: Marcus Sorensen 
> Reply-To: "dev@cloudstack.apache.org" 
> Date: Monday, November 11, 2013 1:10 PM
> To: "dev@cloudstack.apache.org" 
>
> Subject: Re: api incompatibility between 4.1 and 4.2 in ACLs
>
> Ok, I'll dig deeper into it. Our api's ACL tests are breaking against 4.2.
>
> On Sun, Nov 10, 2013 at 11:13 PM, Kishan Kavala
>  wrote:
>
> Marcus,
>   aclid is optional when creating a networlACL. In 4.1, networkId is
> mandatory for creating ACL. So, when networkId is specified instead of aclid
> in 4.2, CS gets the aclList associated with the network and adds acl to it.
> So, API doesn't break if the aclid is not specified.
>
> -Original Message-
> From: Marcus Sorensen [mailto:shadow...@gmail.com]
> Sent: Saturday, 9 November 2013 1:13 AM
> To: dev@cloudstack.apache.org
> Cc: Kishan Kavala
> Subject: Re: api incompatibility between 4.1 and 4.2 in ACLs
>
> Yes, that would certainly maintain api compatibility if one creates an ACL
> without specifying aclid, it creates a new list and applies it to the given
> network.
>
> On Fri, Nov 8, 2013 at 12:28 PM, Animesh Chaturvedi
>  wrote:
>> Actually use this link to the message in that thread
>> http://s.apache.org/QKI
>>
>>
>>
>>> -Original Message-
>>> From: Animesh Chaturvedi [mailto:animesh.chaturv...@citrix.com]
>>> Sent: Friday, November 08, 2013 11:24 AM
>>> To: dev@cloudstack.apache.org
>>> Cc: Kishan Kavala
>>> Subject: RE: api incompatibility between 4.1 and 4.2 in ACLs
>>>
>>>
>>> I will let Kishan comment but found this thread
>>> http://markmail.org/thread/fxzki6ftqacyrylk
>>>
>>>
>>> > -Original Message-
>>> > From: Marcus Sorensen [mailto:shadow...@gmail.com]
>>> > Sent: Friday, November 08, 2013 9:13 AM
>>> > To: dev@cloudstack.apache.org
>>> > Subject: Re: api incompatibility between 4.1 and 4.2 in ACLs
>>> >
>>> > So I take the silence to simply be a collective "oops".  I guess
>>> > this just should serve as a reminder to not break API compatibility
>>> > without a discussion. Perhaps our tests will surface this better in
>>> > the future (although I need to look, I wonder if any ACL tests were
>>> > also simply changed to accomodate the new behavior).
>>> >
>>> > On Thu, Nov 7, 2013 at 2:23 PM, Marcus Sorensen
>>> > 
>>> > wrote:
>>> > > Maybe this has been discussed already, but we seem to have run
>>> > > into an api incompatibility. In 4.1, you could create ad-hoc ACL
>>> > > rules that applied to a network. In 4.2, you have to first create
>>> > > an 'ACL list', then add those rules to the list, then apply the
>>> > > list to a network. Or so it seems.  This means that applications
>>> > > that are coded to the cloudstack API and utilize createNetworkACL
>>> > > will break, because the flow has changed.
>>> > >
>>> > > Am I correct on this? And if so, shouldn't we have deployed 4.2
>>> > > as 5.0, since the stated versioning is based on API compatibility?
>
>


Re: 4.3 Not Building (Test Failure)

2013-11-11 Thread David Nalley
That's still concerning.

The deps should be handled automagically by maven, and new
dependencies should be discussed on list. Especially because this
potentially triggers legal compliance issues.

--David

On Mon, Nov 11, 2013 at 5:55 PM, Mike Tutkowski
 wrote:
> Ah, you are correct - thanks!
>
> I can now get the system to build and the tests to run again. :)
>
>
> On Mon, Nov 11, 2013 at 3:04 PM, Laszlo Hornyak 
> wrote:
>
>> I believe it must be /jre/lib/security
>>
>>
>> On Mon, Nov 11, 2013 at 11:02 PM, Mike Tutkowski <
>> mike.tutkow...@solidfire.com> wrote:
>>
>> > Per the install directions, I placed local_policy.jar and
>> > US_export_policy.jar in /lib/security.
>> >
>> > My build failed at the same test.
>> >
>> > I also get 61 compile errors in Eclipse.
>> >
>> >
>> > On Mon, Nov 11, 2013 at 2:40 PM, Syed Ahmed  wrote:
>> >
>> > > Hi Mike,
>> > >
>> > > Can you try and install the JCE extensions suggested by Laszlo?
>> > >
>> > > Thanks,
>> > > -Syed
>> > >
>> > >
>> > > On 13-11-11 04:34 PM, Mike Tutkowski wrote:
>> > >
>> > >> Thanks, Wei.
>> > >>
>> > >> Does this assert failure look familiar to you?
>> > >>
>> > >> 
>> > >> ---
>> > >>
>> > >> Test set: org.apache.cloudstack.network.lb.CertServiceTest
>> > >>
>> > >> 
>> > >> ---
>> > >>
>> > >> Tests run: 2, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.817
>> > sec
>> > >> <<< FAILURE!
>> > >>
>> > >> testUploadSslCert(org.apache.cloudstack.network.lb.CertServiceTest)
>> >  Time
>> > >> elapsed: 0.806 sec  <<< FAILURE!
>> > >>
>> > >> junit.framework.AssertionFailedError
>> > >>
>> > >> at junit.framework.Assert.fail(Assert.java:48)
>> > >>
>> > >> at junit.framework.Assert.assertTrue(Assert.java:20)
>> > >>
>> > >> at junit.framework.Assert.assertTrue(Assert.java:27)
>> > >>
>> > >> at
>> > >>
>> > org.apache.cloudstack.network.lb.CertServiceTest.runUploadSslCertNoChain(
>> > >> CertServiceTest.java:401)
>> > >>
>> > >> at
>> > >> org.apache.cloudstack.network.lb.CertServiceTest.testUploadSslCert(
>> > >> CertServiceTest.java:95)
>> > >>
>> > >> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> > >>
>> > >> at
>> > >> sun.reflect.NativeMethodAccessorImpl.invoke(
>> > >> NativeMethodAccessorImpl.java:57)
>> > >>
>> > >> at
>> > >> sun.reflect.DelegatingMethodAccessorImpl.invoke(
>> > >> DelegatingMethodAccessorImpl.java:43)
>> > >>
>> > >> at java.lang.reflect.Method.invoke(Method.java:606)
>> > >>
>> > >> at junit.framework.TestCase.runTest(TestCase.java:168)
>> > >>
>> > >> at junit.framework.TestCase.runBare(TestCase.java:134)
>> > >>
>> > >> at junit.framework.TestResult$1.protect(TestResult.java:110)
>> > >>
>> > >> at junit.framework.TestResult.runProtected(TestResult.java:128)
>> > >>
>> > >> at junit.framework.TestResult.run(TestResult.java:113)
>> > >>
>> > >> at junit.framework.TestCase.run(TestCase.java:124)
>> > >>
>> > >> at junit.framework.TestSuite.runTest(TestSuite.java:243)
>> > >>
>> > >> at junit.framework.TestSuite.run(TestSuite.java:238)
>> > >>
>> > >> at
>> > >> org.junit.internal.runners.JUnit38ClassRunner.run(
>> > >> JUnit38ClassRunner.java:83)
>> > >>
>> > >> at
>> > >> org.apache.maven.surefire.junit4.JUnit4Provider.execute(
>> > >> JUnit4Provider.java:236)
>> > >>
>> > >> at
>> > >> org.apache.maven.surefire.junit4.JUnit4Provider.
>> > >> executeTestSet(JUnit4Provider.java:134)
>> > >>
>> > >> at
>> > >> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(
>> > >> JUnit4Provider.java:113)
>> > >>
>> > >> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> > >>
>> > >> at
>> > >> sun.reflect.NativeMethodAccessorImpl.invoke(
>> > >> NativeMethodAccessorImpl.java:57)
>> > >>
>> > >> at
>> > >> sun.reflect.DelegatingMethodAccessorImpl.invoke(
>> > >> DelegatingMethodAccessorImpl.java:43)
>> > >>
>> > >> at java.lang.reflect.Method.invoke(Method.java:606)
>> > >>
>> > >> at
>> > >> org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(
>> > >> ReflectionUtils.java:189)
>> > >>
>> > >> at
>> > >> org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(
>> > >> ProviderFactory.java:165)
>> > >>
>> > >> at
>> > >> org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(
>> > >> ProviderFactory.java:85)
>> > >>
>> > >> at
>> > >> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(
>> > >> ForkedBooter.java:103)
>> > >>
>> > >> at org.apache.maven.surefire.booter.ForkedBooter.main(
>> > >> ForkedBooter.java:74)
>> > >>
>> > >>
>> > >> On Mon, Nov 11, 2013 at 2:28 PM, Wei ZHOU 
>> > wrote:
>> > >>
>> > >>  I built succeed with jdk 1.6 and jdk 1.7
>> > >>>
>> > >>> Maybe some packages are missing in your environment.
>> > >>> You can get some information
>> > >>> from
>> > >>> /Users/mtutkowski/Documents/CloudStack/src/CloudStack/
>> > >>> server/target/surefire-reports
>> > >>>
>> >

Re: api incompatibility between 4.1 and 4.2 in ACLs

2013-11-11 Thread Alena Prokharchyk
On 11/11/13 2:59 PM, "Marcus Sorensen"  wrote:

>Sorry for the back and forth,  I'm interfacing with individuals who
>consume our CloudStack environment. I'm being told that the issues
>actually aren't related to API parameters, but behavior of the API
>calls:
>
>1) As a user, listing network ACLs now shows ALL ACLs, not just the
>ones you own. An example test that was shown to me created a new user,
>listed ACLs, then created two ACLs and listed again.  Previously, the
>result would be 0, then 2 ACLs. Now, we get 24 and 26, as the brand
>new user sees all ACLs.

Its a bug if the ACLs belong to some other user in the domain as the
regular user can see only his own resources. Can you please elaborate who
owns 24 and 26 ACLs, and who makes the call (the type of the user - domain
admin, root admin, regular user)

>
>2) Test case used to succeed by failing when duplicate or overlapping
>ACLs were created. Now, they're allowed.  I have yet to duplicate this
>and see if it causes problems for virtual routers.


Not a bug. If it was the other way around - duplicated rules were allowed,
and now we block it - then it would have been a bug because your DB might
already have duplicated records prior to update.
With the new way ACLs are implemented, you can set the priority for the
rule. Once the rule with the highest priority is hit, the rest of the
rules are not being processed. You can read the FS to understand how the
feature works. Kishan, can you point Marcus to the spec.


>
>I'll try to confirm/duplicate and create JIRA issues for these if I
>don't get a response back from someone explaining/validating the new
>behavior.
>
>On Mon, Nov 11, 2013 at 2:22 PM, Alena Prokharchyk
> wrote:
>> Marcus, if any of the CS API command(s) return the error for
>> parameter/parameter combination that used to work before, then it means
>>APIs
>> are incompatible, and it has to be fixed.
>> Thank you for looking into it.
>>
>> -Alena.
>>
>> From: Marcus Sorensen 
>> Reply-To: "dev@cloudstack.apache.org" 
>> Date: Monday, November 11, 2013 1:10 PM
>> To: "dev@cloudstack.apache.org" 
>>
>> Subject: Re: api incompatibility between 4.1 and 4.2 in ACLs
>>
>> Ok, I'll dig deeper into it. Our api's ACL tests are breaking against
>>4.2.
>>
>> On Sun, Nov 10, 2013 at 11:13 PM, Kishan Kavala
>>  wrote:
>>
>> Marcus,
>>   aclid is optional when creating a networlACL. In 4.1, networkId is
>> mandatory for creating ACL. So, when networkId is specified instead of
>>aclid
>> in 4.2, CS gets the aclList associated with the network and adds acl to
>>it.
>> So, API doesn't break if the aclid is not specified.
>>
>> -Original Message-
>> From: Marcus Sorensen [mailto:shadow...@gmail.com]
>> Sent: Saturday, 9 November 2013 1:13 AM
>> To: dev@cloudstack.apache.org
>> Cc: Kishan Kavala
>> Subject: Re: api incompatibility between 4.1 and 4.2 in ACLs
>>
>> Yes, that would certainly maintain api compatibility if one creates an
>>ACL
>> without specifying aclid, it creates a new list and applies it to the
>>given
>> network.
>>
>> On Fri, Nov 8, 2013 at 12:28 PM, Animesh Chaturvedi
>>  wrote:
>>> Actually use this link to the message in that thread
>>> http://s.apache.org/QKI
>>>
>>>
>>>
 -Original Message-
 From: Animesh Chaturvedi [mailto:animesh.chaturv...@citrix.com]
 Sent: Friday, November 08, 2013 11:24 AM
 To: dev@cloudstack.apache.org
 Cc: Kishan Kavala
 Subject: RE: api incompatibility between 4.1 and 4.2 in ACLs


 I will let Kishan comment but found this thread
 http://markmail.org/thread/fxzki6ftqacyrylk


 > -Original Message-
 > From: Marcus Sorensen [mailto:shadow...@gmail.com]
 > Sent: Friday, November 08, 2013 9:13 AM
 > To: dev@cloudstack.apache.org
 > Subject: Re: api incompatibility between 4.1 and 4.2 in ACLs
 >
 > So I take the silence to simply be a collective "oops".  I guess
 > this just should serve as a reminder to not break API compatibility
 > without a discussion. Perhaps our tests will surface this better in
 > the future (although I need to look, I wonder if any ACL tests were
 > also simply changed to accomodate the new behavior).
 >
 > On Thu, Nov 7, 2013 at 2:23 PM, Marcus Sorensen
 > 
 > wrote:
 > > Maybe this has been discussed already, but we seem to have run
 > > into an api incompatibility. In 4.1, you could create ad-hoc ACL
 > > rules that applied to a network. In 4.2, you have to first create
 > > an 'ACL list', then add those rules to the list, then apply the
 > > list to a network. Or so it seems.  This means that applications
 > > that are coded to the cloudstack API and utilize createNetworkACL
 > > will break, because the flow has changed.
 > >
 > > Am I correct on this? And if so, shouldn't we have deployed 4.2
 > > as 5.0, since the stated versioning is based on API compatibility?
>>
>>
>




Re: 4.3 Not Building (Test Failure)

2013-11-11 Thread Mike Tutkowski
Yeah...I was going to say we need to document this in the
how-to-set-up-CloudStack Wiki or make this a standard dependency that just
works.

Also, if there are legalities involved, we need to work that out, as well.


On Mon, Nov 11, 2013 at 4:08 PM, David Nalley  wrote:

> That's still concerning.
>
> The deps should be handled automagically by maven, and new
> dependencies should be discussed on list. Especially because this
> potentially triggers legal compliance issues.
>
> --David
>
> On Mon, Nov 11, 2013 at 5:55 PM, Mike Tutkowski
>  wrote:
> > Ah, you are correct - thanks!
> >
> > I can now get the system to build and the tests to run again. :)
> >
> >
> > On Mon, Nov 11, 2013 at 3:04 PM, Laszlo Hornyak <
> laszlo.horn...@gmail.com>wrote:
> >
> >> I believe it must be /jre/lib/security
> >>
> >>
> >> On Mon, Nov 11, 2013 at 11:02 PM, Mike Tutkowski <
> >> mike.tutkow...@solidfire.com> wrote:
> >>
> >> > Per the install directions, I placed local_policy.jar and
> >> > US_export_policy.jar in /lib/security.
> >> >
> >> > My build failed at the same test.
> >> >
> >> > I also get 61 compile errors in Eclipse.
> >> >
> >> >
> >> > On Mon, Nov 11, 2013 at 2:40 PM, Syed Ahmed 
> wrote:
> >> >
> >> > > Hi Mike,
> >> > >
> >> > > Can you try and install the JCE extensions suggested by Laszlo?
> >> > >
> >> > > Thanks,
> >> > > -Syed
> >> > >
> >> > >
> >> > > On 13-11-11 04:34 PM, Mike Tutkowski wrote:
> >> > >
> >> > >> Thanks, Wei.
> >> > >>
> >> > >> Does this assert failure look familiar to you?
> >> > >>
> >> > >> 
> >> > >> ---
> >> > >>
> >> > >> Test set: org.apache.cloudstack.network.lb.CertServiceTest
> >> > >>
> >> > >> 
> >> > >> ---
> >> > >>
> >> > >> Tests run: 2, Failures: 1, Errors: 0, Skipped: 0, Time elapsed:
> 0.817
> >> > sec
> >> > >> <<< FAILURE!
> >> > >>
> >> > >> testUploadSslCert(org.apache.cloudstack.network.lb.CertServiceTest)
> >> >  Time
> >> > >> elapsed: 0.806 sec  <<< FAILURE!
> >> > >>
> >> > >> junit.framework.AssertionFailedError
> >> > >>
> >> > >> at junit.framework.Assert.fail(Assert.java:48)
> >> > >>
> >> > >> at junit.framework.Assert.assertTrue(Assert.java:20)
> >> > >>
> >> > >> at junit.framework.Assert.assertTrue(Assert.java:27)
> >> > >>
> >> > >> at
> >> > >>
> >> >
> org.apache.cloudstack.network.lb.CertServiceTest.runUploadSslCertNoChain(
> >> > >> CertServiceTest.java:401)
> >> > >>
> >> > >> at
> >> > >> org.apache.cloudstack.network.lb.CertServiceTest.testUploadSslCert(
> >> > >> CertServiceTest.java:95)
> >> > >>
> >> > >> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> >> > >>
> >> > >> at
> >> > >> sun.reflect.NativeMethodAccessorImpl.invoke(
> >> > >> NativeMethodAccessorImpl.java:57)
> >> > >>
> >> > >> at
> >> > >> sun.reflect.DelegatingMethodAccessorImpl.invoke(
> >> > >> DelegatingMethodAccessorImpl.java:43)
> >> > >>
> >> > >> at java.lang.reflect.Method.invoke(Method.java:606)
> >> > >>
> >> > >> at junit.framework.TestCase.runTest(TestCase.java:168)
> >> > >>
> >> > >> at junit.framework.TestCase.runBare(TestCase.java:134)
> >> > >>
> >> > >> at junit.framework.TestResult$1.protect(TestResult.java:110)
> >> > >>
> >> > >> at junit.framework.TestResult.runProtected(TestResult.java:128)
> >> > >>
> >> > >> at junit.framework.TestResult.run(TestResult.java:113)
> >> > >>
> >> > >> at junit.framework.TestCase.run(TestCase.java:124)
> >> > >>
> >> > >> at junit.framework.TestSuite.runTest(TestSuite.java:243)
> >> > >>
> >> > >> at junit.framework.TestSuite.run(TestSuite.java:238)
> >> > >>
> >> > >> at
> >> > >> org.junit.internal.runners.JUnit38ClassRunner.run(
> >> > >> JUnit38ClassRunner.java:83)
> >> > >>
> >> > >> at
> >> > >> org.apache.maven.surefire.junit4.JUnit4Provider.execute(
> >> > >> JUnit4Provider.java:236)
> >> > >>
> >> > >> at
> >> > >> org.apache.maven.surefire.junit4.JUnit4Provider.
> >> > >> executeTestSet(JUnit4Provider.java:134)
> >> > >>
> >> > >> at
> >> > >> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(
> >> > >> JUnit4Provider.java:113)
> >> > >>
> >> > >> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> >> > >>
> >> > >> at
> >> > >> sun.reflect.NativeMethodAccessorImpl.invoke(
> >> > >> NativeMethodAccessorImpl.java:57)
> >> > >>
> >> > >> at
> >> > >> sun.reflect.DelegatingMethodAccessorImpl.invoke(
> >> > >> DelegatingMethodAccessorImpl.java:43)
> >> > >>
> >> > >> at java.lang.reflect.Method.invoke(Method.java:606)
> >> > >>
> >> > >> at
> >> > >>
> org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(
> >> > >> ReflectionUtils.java:189)
> >> > >>
> >> > >> at
> >> > >>
> org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(
> >> > >> ProviderFactory.java:165)
> >> > >>
> >> > >> at
> >> > >> org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(
> >> > >> ProviderFactory.java:85)
> 

Re: api incompatibility between 4.1 and 4.2 in ACLs

2013-11-11 Thread Marcus Sorensen
On Mon, Nov 11, 2013 at 4:09 PM, Alena Prokharchyk
 wrote:
> On 11/11/13 2:59 PM, "Marcus Sorensen"  wrote:
>
>>Sorry for the back and forth,  I'm interfacing with individuals who
>>consume our CloudStack environment. I'm being told that the issues
>>actually aren't related to API parameters, but behavior of the API
>>calls:
>>
>>1) As a user, listing network ACLs now shows ALL ACLs, not just the
>>ones you own. An example test that was shown to me created a new user,
>>listed ACLs, then created two ACLs and listed again.  Previously, the
>>result would be 0, then 2 ACLs. Now, we get 24 and 26, as the brand
>>new user sees all ACLs.
>
> Its a bug if the ACLs belong to some other user in the domain as the
> regular user can see only his own resources. Can you please elaborate who
> owns 24 and 26 ACLs, and who makes the call (the type of the user - domain
> admin, root admin, regular user)

Test creates a domain, creates a new user in the domain, lists ACLs as
that user.  ACLs from other domains and accounts are seen (all ACLs,
as far as I can tell).

>
>>
>>2) Test case used to succeed by failing when duplicate or overlapping
>>ACLs were created. Now, they're allowed.  I have yet to duplicate this
>>and see if it causes problems for virtual routers.
>
>
> Not a bug. If it was the other way around - duplicated rules were allowed,
> and now we block it - then it would have been a bug because your DB might
> already have duplicated records prior to update.
> With the new way ACLs are implemented, you can set the priority for the
> rule. Once the rule with the highest priority is hit, the rest of the
> rules are not being processed. You can read the FS to understand how the
> feature works. Kishan, can you point Marcus to the spec.

Yes, please. This sounds as though someone may create a rule for
22-80, and another for 80-443, and only one of the rules will work
(the one with priority). That would cause confusion as far as
understanding why a rule isn't working. I'll see if I can dig it up on
my own as well.

>
>
>>
>>I'll try to confirm/duplicate and create JIRA issues for these if I
>>don't get a response back from someone explaining/validating the new
>>behavior.
>>
>>On Mon, Nov 11, 2013 at 2:22 PM, Alena Prokharchyk
>> wrote:
>>> Marcus, if any of the CS API command(s) return the error for
>>> parameter/parameter combination that used to work before, then it means
>>>APIs
>>> are incompatible, and it has to be fixed.
>>> Thank you for looking into it.
>>>
>>> -Alena.
>>>
>>> From: Marcus Sorensen 
>>> Reply-To: "dev@cloudstack.apache.org" 
>>> Date: Monday, November 11, 2013 1:10 PM
>>> To: "dev@cloudstack.apache.org" 
>>>
>>> Subject: Re: api incompatibility between 4.1 and 4.2 in ACLs
>>>
>>> Ok, I'll dig deeper into it. Our api's ACL tests are breaking against
>>>4.2.
>>>
>>> On Sun, Nov 10, 2013 at 11:13 PM, Kishan Kavala
>>>  wrote:
>>>
>>> Marcus,
>>>   aclid is optional when creating a networlACL. In 4.1, networkId is
>>> mandatory for creating ACL. So, when networkId is specified instead of
>>>aclid
>>> in 4.2, CS gets the aclList associated with the network and adds acl to
>>>it.
>>> So, API doesn't break if the aclid is not specified.
>>>
>>> -Original Message-
>>> From: Marcus Sorensen [mailto:shadow...@gmail.com]
>>> Sent: Saturday, 9 November 2013 1:13 AM
>>> To: dev@cloudstack.apache.org
>>> Cc: Kishan Kavala
>>> Subject: Re: api incompatibility between 4.1 and 4.2 in ACLs
>>>
>>> Yes, that would certainly maintain api compatibility if one creates an
>>>ACL
>>> without specifying aclid, it creates a new list and applies it to the
>>>given
>>> network.
>>>
>>> On Fri, Nov 8, 2013 at 12:28 PM, Animesh Chaturvedi
>>>  wrote:
 Actually use this link to the message in that thread
 http://s.apache.org/QKI



> -Original Message-
> From: Animesh Chaturvedi [mailto:animesh.chaturv...@citrix.com]
> Sent: Friday, November 08, 2013 11:24 AM
> To: dev@cloudstack.apache.org
> Cc: Kishan Kavala
> Subject: RE: api incompatibility between 4.1 and 4.2 in ACLs
>
>
> I will let Kishan comment but found this thread
> http://markmail.org/thread/fxzki6ftqacyrylk
>
>
> > -Original Message-
> > From: Marcus Sorensen [mailto:shadow...@gmail.com]
> > Sent: Friday, November 08, 2013 9:13 AM
> > To: dev@cloudstack.apache.org
> > Subject: Re: api incompatibility between 4.1 and 4.2 in ACLs
> >
> > So I take the silence to simply be a collective "oops".  I guess
> > this just should serve as a reminder to not break API compatibility
> > without a discussion. Perhaps our tests will surface this better in
> > the future (although I need to look, I wonder if any ACL tests were
> > also simply changed to accomodate the new behavior).
> >
> > On Thu, Nov 7, 2013 at 2:23 PM, Marcus Sorensen
> > 
> > wrote:
> > > Maybe this has been discussed already, but we seem to have run

Re: api incompatibility between 4.1 and 4.2 in ACLs

2013-11-11 Thread Alena Prokharchyk
On 11/11/13 3:34 PM, "Marcus Sorensen"  wrote:

>On Mon, Nov 11, 2013 at 4:09 PM, Alena Prokharchyk
> wrote:
>> On 11/11/13 2:59 PM, "Marcus Sorensen"  wrote:
>>
>>>Sorry for the back and forth,  I'm interfacing with individuals who
>>>consume our CloudStack environment. I'm being told that the issues
>>>actually aren't related to API parameters, but behavior of the API
>>>calls:
>>>
>>>1) As a user, listing network ACLs now shows ALL ACLs, not just the
>>>ones you own. An example test that was shown to me created a new user,
>>>listed ACLs, then created two ACLs and listed again.  Previously, the
>>>result would be 0, then 2 ACLs. Now, we get 24 and 26, as the brand
>>>new user sees all ACLs.
>>
>> Its a bug if the ACLs belong to some other user in the domain as the
>> regular user can see only his own resources. Can you please elaborate
>>who
>> owns 24 and 26 ACLs, and who makes the call (the type of the user -
>>domain
>> admin, root admin, regular user)
>
>Test creates a domain, creates a new user in the domain, lists ACLs as
>that user.  ACLs from other domains and accounts are seen (all ACLs,
>as far as I can tell).


Sounds like a security bug to me. Kishan, can you take a look pls?


>
>>
>>>
>>>2) Test case used to succeed by failing when duplicate or overlapping
>>>ACLs were created. Now, they're allowed.  I have yet to duplicate this
>>>and see if it causes problems for virtual routers.
>>
>>
>> Not a bug. If it was the other way around - duplicated rules were
>>allowed,
>> and now we block it - then it would have been a bug because your DB
>>might
>> already have duplicated records prior to update.
>> With the new way ACLs are implemented, you can set the priority for the
>> rule. Once the rule with the highest priority is hit, the rest of the
>> rules are not being processed. You can read the FS to understand how the
>> feature works. Kishan, can you point Marcus to the spec.
>
>Yes, please. This sounds as though someone may create a rule for
>22-80, and another for 80-443, and only one of the rules will work
>(the one with priority). That would cause confusion as far as
>understanding why a rule isn't working. I'll see if I can dig it up on
>my own as well.
>
>>
>>
>>>
>>>I'll try to confirm/duplicate and create JIRA issues for these if I
>>>don't get a response back from someone explaining/validating the new
>>>behavior.
>>>
>>>On Mon, Nov 11, 2013 at 2:22 PM, Alena Prokharchyk
>>> wrote:
 Marcus, if any of the CS API command(s) return the error for
 parameter/parameter combination that used to work before, then it
means
APIs
 are incompatible, and it has to be fixed.
 Thank you for looking into it.

 -Alena.

 From: Marcus Sorensen 
 Reply-To: "dev@cloudstack.apache.org" 
 Date: Monday, November 11, 2013 1:10 PM
 To: "dev@cloudstack.apache.org" 

 Subject: Re: api incompatibility between 4.1 and 4.2 in ACLs

 Ok, I'll dig deeper into it. Our api's ACL tests are breaking against
4.2.

 On Sun, Nov 10, 2013 at 11:13 PM, Kishan Kavala
  wrote:

 Marcus,
   aclid is optional when creating a networlACL. In 4.1, networkId is
 mandatory for creating ACL. So, when networkId is specified instead of
aclid
 in 4.2, CS gets the aclList associated with the network and adds acl
to
it.
 So, API doesn't break if the aclid is not specified.

 -Original Message-
 From: Marcus Sorensen [mailto:shadow...@gmail.com]
 Sent: Saturday, 9 November 2013 1:13 AM
 To: dev@cloudstack.apache.org
 Cc: Kishan Kavala
 Subject: Re: api incompatibility between 4.1 and 4.2 in ACLs

 Yes, that would certainly maintain api compatibility if one creates an
ACL
 without specifying aclid, it creates a new list and applies it to the
given
 network.

 On Fri, Nov 8, 2013 at 12:28 PM, Animesh Chaturvedi
  wrote:
> Actually use this link to the message in that thread
> http://s.apache.org/QKI
>
>
>
>> -Original Message-
>> From: Animesh Chaturvedi [mailto:animesh.chaturv...@citrix.com]
>> Sent: Friday, November 08, 2013 11:24 AM
>> To: dev@cloudstack.apache.org
>> Cc: Kishan Kavala
>> Subject: RE: api incompatibility between 4.1 and 4.2 in ACLs
>>
>>
>> I will let Kishan comment but found this thread
>> http://markmail.org/thread/fxzki6ftqacyrylk
>>
>>
>> > -Original Message-
>> > From: Marcus Sorensen [mailto:shadow...@gmail.com]
>> > Sent: Friday, November 08, 2013 9:13 AM
>> > To: dev@cloudstack.apache.org
>> > Subject: Re: api incompatibility between 4.1 and 4.2 in ACLs
>> >
>> > So I take the silence to simply be a collective "oops".  I guess
>> > this just should serve as a reminder to not break API
>>compatibility
>> > without a discussion. Perhaps our tests will surface this better
>>in
>> > the future (altho

Re: api incompatibility between 4.1 and 4.2 in ACLs

2013-11-11 Thread Marcus Sorensen
I can say in practice, at least, if I create a rule that opens TCP 22
and another rule that opens TCP 22 through 80, they both show up on
the virtual router's iptables. That shouldn't hurt anything, and is
actually a bit less confusing. I think I see what you're saying, the
first rule listed will match in iptables and will stop processing. I
thought you meant that the ACLs would stop being installed on the
router according to whether or not they overlap.  This behavior I'm
seeing makes sense.


Let me try to duplicate in master, as well. This is with 4.2

On Mon, Nov 11, 2013 at 4:38 PM, Alena Prokharchyk
 wrote:
> On 11/11/13 3:34 PM, "Marcus Sorensen"  wrote:
>
>>On Mon, Nov 11, 2013 at 4:09 PM, Alena Prokharchyk
>> wrote:
>>> On 11/11/13 2:59 PM, "Marcus Sorensen"  wrote:
>>>
Sorry for the back and forth,  I'm interfacing with individuals who
consume our CloudStack environment. I'm being told that the issues
actually aren't related to API parameters, but behavior of the API
calls:

1) As a user, listing network ACLs now shows ALL ACLs, not just the
ones you own. An example test that was shown to me created a new user,
listed ACLs, then created two ACLs and listed again.  Previously, the
result would be 0, then 2 ACLs. Now, we get 24 and 26, as the brand
new user sees all ACLs.
>>>
>>> Its a bug if the ACLs belong to some other user in the domain as the
>>> regular user can see only his own resources. Can you please elaborate
>>>who
>>> owns 24 and 26 ACLs, and who makes the call (the type of the user -
>>>domain
>>> admin, root admin, regular user)
>>
>>Test creates a domain, creates a new user in the domain, lists ACLs as
>>that user.  ACLs from other domains and accounts are seen (all ACLs,
>>as far as I can tell).
>
>
> Sounds like a security bug to me. Kishan, can you take a look pls?
>
>
>>
>>>

2) Test case used to succeed by failing when duplicate or overlapping
ACLs were created. Now, they're allowed.  I have yet to duplicate this
and see if it causes problems for virtual routers.
>>>
>>>
>>> Not a bug. If it was the other way around - duplicated rules were
>>>allowed,
>>> and now we block it - then it would have been a bug because your DB
>>>might
>>> already have duplicated records prior to update.
>>> With the new way ACLs are implemented, you can set the priority for the
>>> rule. Once the rule with the highest priority is hit, the rest of the
>>> rules are not being processed. You can read the FS to understand how the
>>> feature works. Kishan, can you point Marcus to the spec.
>>
>>Yes, please. This sounds as though someone may create a rule for
>>22-80, and another for 80-443, and only one of the rules will work
>>(the one with priority). That would cause confusion as far as
>>understanding why a rule isn't working. I'll see if I can dig it up on
>>my own as well.
>>
>>>
>>>

I'll try to confirm/duplicate and create JIRA issues for these if I
don't get a response back from someone explaining/validating the new
behavior.

On Mon, Nov 11, 2013 at 2:22 PM, Alena Prokharchyk
 wrote:
> Marcus, if any of the CS API command(s) return the error for
> parameter/parameter combination that used to work before, then it
>means
>APIs
> are incompatible, and it has to be fixed.
> Thank you for looking into it.
>
> -Alena.
>
> From: Marcus Sorensen 
> Reply-To: "dev@cloudstack.apache.org" 
> Date: Monday, November 11, 2013 1:10 PM
> To: "dev@cloudstack.apache.org" 
>
> Subject: Re: api incompatibility between 4.1 and 4.2 in ACLs
>
> Ok, I'll dig deeper into it. Our api's ACL tests are breaking against
>4.2.
>
> On Sun, Nov 10, 2013 at 11:13 PM, Kishan Kavala
>  wrote:
>
> Marcus,
>   aclid is optional when creating a networlACL. In 4.1, networkId is
> mandatory for creating ACL. So, when networkId is specified instead of
>aclid
> in 4.2, CS gets the aclList associated with the network and adds acl
>to
>it.
> So, API doesn't break if the aclid is not specified.
>
> -Original Message-
> From: Marcus Sorensen [mailto:shadow...@gmail.com]
> Sent: Saturday, 9 November 2013 1:13 AM
> To: dev@cloudstack.apache.org
> Cc: Kishan Kavala
> Subject: Re: api incompatibility between 4.1 and 4.2 in ACLs
>
> Yes, that would certainly maintain api compatibility if one creates an
>ACL
> without specifying aclid, it creates a new list and applies it to the
>given
> network.
>
> On Fri, Nov 8, 2013 at 12:28 PM, Animesh Chaturvedi
>  wrote:
>> Actually use this link to the message in that thread
>> http://s.apache.org/QKI
>>
>>
>>
>>> -Original Message-
>>> From: Animesh Chaturvedi [mailto:animesh.chaturv...@citrix.com]
>>> Sent: Friday, November 08, 2013 11:24 AM
>>> To: dev@cloudstack.apache.org
>>> Cc: K

Re: api incompatibility between 4.1 and 4.2 in ACLs

2013-11-11 Thread Marcus Sorensen
Yes, master as of today lists all acls with a newly created user-level account.

On Mon, Nov 11, 2013 at 4:46 PM, Marcus Sorensen  wrote:
> I can say in practice, at least, if I create a rule that opens TCP 22
> and another rule that opens TCP 22 through 80, they both show up on
> the virtual router's iptables. That shouldn't hurt anything, and is
> actually a bit less confusing. I think I see what you're saying, the
> first rule listed will match in iptables and will stop processing. I
> thought you meant that the ACLs would stop being installed on the
> router according to whether or not they overlap.  This behavior I'm
> seeing makes sense.
>
>
> Let me try to duplicate in master, as well. This is with 4.2
>
> On Mon, Nov 11, 2013 at 4:38 PM, Alena Prokharchyk
>  wrote:
>> On 11/11/13 3:34 PM, "Marcus Sorensen"  wrote:
>>
>>>On Mon, Nov 11, 2013 at 4:09 PM, Alena Prokharchyk
>>> wrote:
 On 11/11/13 2:59 PM, "Marcus Sorensen"  wrote:

>Sorry for the back and forth,  I'm interfacing with individuals who
>consume our CloudStack environment. I'm being told that the issues
>actually aren't related to API parameters, but behavior of the API
>calls:
>
>1) As a user, listing network ACLs now shows ALL ACLs, not just the
>ones you own. An example test that was shown to me created a new user,
>listed ACLs, then created two ACLs and listed again.  Previously, the
>result would be 0, then 2 ACLs. Now, we get 24 and 26, as the brand
>new user sees all ACLs.

 Its a bug if the ACLs belong to some other user in the domain as the
 regular user can see only his own resources. Can you please elaborate
who
 owns 24 and 26 ACLs, and who makes the call (the type of the user -
domain
 admin, root admin, regular user)
>>>
>>>Test creates a domain, creates a new user in the domain, lists ACLs as
>>>that user.  ACLs from other domains and accounts are seen (all ACLs,
>>>as far as I can tell).
>>
>>
>> Sounds like a security bug to me. Kishan, can you take a look pls?
>>
>>
>>>

>
>2) Test case used to succeed by failing when duplicate or overlapping
>ACLs were created. Now, they're allowed.  I have yet to duplicate this
>and see if it causes problems for virtual routers.


 Not a bug. If it was the other way around - duplicated rules were
allowed,
 and now we block it - then it would have been a bug because your DB
might
 already have duplicated records prior to update.
 With the new way ACLs are implemented, you can set the priority for the
 rule. Once the rule with the highest priority is hit, the rest of the
 rules are not being processed. You can read the FS to understand how the
 feature works. Kishan, can you point Marcus to the spec.
>>>
>>>Yes, please. This sounds as though someone may create a rule for
>>>22-80, and another for 80-443, and only one of the rules will work
>>>(the one with priority). That would cause confusion as far as
>>>understanding why a rule isn't working. I'll see if I can dig it up on
>>>my own as well.
>>>


>
>I'll try to confirm/duplicate and create JIRA issues for these if I
>don't get a response back from someone explaining/validating the new
>behavior.
>
>On Mon, Nov 11, 2013 at 2:22 PM, Alena Prokharchyk
> wrote:
>> Marcus, if any of the CS API command(s) return the error for
>> parameter/parameter combination that used to work before, then it
>>means
>>APIs
>> are incompatible, and it has to be fixed.
>> Thank you for looking into it.
>>
>> -Alena.
>>
>> From: Marcus Sorensen 
>> Reply-To: "dev@cloudstack.apache.org" 
>> Date: Monday, November 11, 2013 1:10 PM
>> To: "dev@cloudstack.apache.org" 
>>
>> Subject: Re: api incompatibility between 4.1 and 4.2 in ACLs
>>
>> Ok, I'll dig deeper into it. Our api's ACL tests are breaking against
>>4.2.
>>
>> On Sun, Nov 10, 2013 at 11:13 PM, Kishan Kavala
>>  wrote:
>>
>> Marcus,
>>   aclid is optional when creating a networlACL. In 4.1, networkId is
>> mandatory for creating ACL. So, when networkId is specified instead of
>>aclid
>> in 4.2, CS gets the aclList associated with the network and adds acl
>>to
>>it.
>> So, API doesn't break if the aclid is not specified.
>>
>> -Original Message-
>> From: Marcus Sorensen [mailto:shadow...@gmail.com]
>> Sent: Saturday, 9 November 2013 1:13 AM
>> To: dev@cloudstack.apache.org
>> Cc: Kishan Kavala
>> Subject: Re: api incompatibility between 4.1 and 4.2 in ACLs
>>
>> Yes, that would certainly maintain api compatibility if one creates an
>>ACL
>> without specifying aclid, it creates a new list and applies it to the
>>given
>> network.
>>
>> On Fri, Nov 8, 2013 at 12:28 PM, Animesh Chaturvedi
>>  wrote:
>>> Actually use this link to the message

Re: [ACS4.2.1] request for QA update

2013-11-11 Thread Abhinandan Prateek
Daan reported in another thread that "4.1.1 to 4.2.1 upgrade works fine in a 
lab env”.

Raja/Lucian, any update on 2.2.14 upgrade ?

-abhi

On 11/11/13 9:17 pm, "Sudha Ponnaganti" 
mailto:sudha.ponnaga...@citrix.com>> wrote:

Hi All,

Scope Status [1]

-  Rayees has posted automation results earlier BVTs and regressions 
were done in citrix lab on 4.2.1 branch

-  Tested a few regressions around VMWare as there are couple of issues 
got fixed in last phases of 4.2

-  250 issues got fixed for 4.2.1


Blockers for RC

-  We still have 7 Criticals/blockers that need to be fixed in JIRA ( 
Use query Fixed version 4.2.1)

-  Upgrade paths need to be closed

o   4,2 ( citrix is trying this out – will report back Wednesday)

o   4.1.1 ( Daan will report back by Friday)

o   2.2.14 > ( Lucian has been trying this path)

Good to have for RC

-  There are 80 Resolved defects. Would help if community can close 
these ( you can use query fix version 4.2.1, Status Resolved )

[1] 
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Cloudstack+4.2.1+Maintenance+Release
[2] 
https://cwiki.apache.org/confluence/display/CLOUDSTACK/4.2.1+Automation+Result

From: Abhinandan Prateek
Sent: Monday, November 11, 2013 1:56 AM
To: CloudStack Dev
Cc: Raja Pullela; Sudha Ponnaganti
Subject: [ACS4.2.1] request for QA update

Sudha/Raja,

   You guys have been doing a QA on 4.2.1 for quite some time now.
It would be good for community to know in general how the 4.2.1 branch is 
coming off in terms of quality.

-abhi


Review Request 15448: add the timeout configuration for upgrade

2013-11-11 Thread Anshul Gangwar

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

Review request for cloudstack, Likitha Shetty and Rajesh Battala.


Bugs: CLOUDSTACK-5082
https://issues.apache.org/jira/browse/CLOUDSTACK-5082


Repository: cloudstack-git


Description
---

added the insert statements for newly added global configuration in upgrade 
script


Diffs
-

  setup/db/db/schema-420to421.sql 1d28485 

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


Testing
---


Thanks,

Anshul Gangwar



Re: Review Request 15448: add the timeout configuration for upgrade

2013-11-11 Thread Anshul Gangwar

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

(Updated Nov. 12, 2013, 5:23 a.m.)


Review request for cloudstack, Likitha Shetty and Rajesh Battala.


Changes
---

added the branch for patch


Bugs: CLOUDSTACK-5082
https://issues.apache.org/jira/browse/CLOUDSTACK-5082


Repository: cloudstack-git


Description
---

added the insert statements for newly added global configuration in upgrade 
script


Diffs
-

  setup/db/db/schema-420to421.sql 1d28485 

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


Testing
---


Thanks,

Anshul Gangwar



Re: SSL and JCE

2013-11-11 Thread Prasanna Santhanam
My MacOSX 1.6 jdk seems to have the crypto extensions jce builtin and
the build+test works. JDK 1.7 install does not have them though.

The JCE kit seems to carry a BCL which is not ASF friendly [1]. But
this being part of the Java install and not the project it should be
okay IMO if we note it in our wiki on building the project.

As for legal aspects - I found this which might be of some relevance.  
http://markmail.org/message/evtkc656gewrkruf

[1] http://www.apache.org/legal/3party.html#transition-examples

On Mon, Nov 11, 2013 at 10:45:12PM +0100, Laszlo Hornyak wrote:
> Hi,
> 
> That is a good question, I do not know for sure, but this package needs to
> be signed by oracle, it is not redistributable and has teritorial import
> restrictions, so it could be problematic :-( I hope it is not. Guys, can
> someone help us here?
> 
> 
> On Mon, Nov 11, 2013 at 10:21 PM, Syed Ahmed  wrote:
> 
> > Hi Laszlo,
> >
> > The CertService uses BouncyCastle for certificate parsing and validation.
> > The JCE extension provides the API for using BouncyCastle as the provider.
> > So, JCE is required. I know that BouncyCastle is added in CS. Would it be
> > possible to add JCE as a dependency too?
> >
> > Thanks,
> > -Syed
> >
> >
> > On 13-11-10 09:55 AM, Laszlo Hornyak wrote:
> >
> >> Hi Sahmed and list,
> >>
> >> I ran into some failing tests this weekend related to the patch
> >> 0076307863e9155273d9e4c14282de429388c9e9 apparently jenkins fails for
> >> the same reason. I did a short investigation and it turned out that in
> >> order to run the tests correctly, one has to download the sun jce policy
> >> files and put it in the jdk replacing the original policies.
> >>
> >> Questions:
> >> - Is there a more convenient deployment process? :-) It would be very
> >> useful for the jenkins environment as well.
> >> - I gave it a try and patched the oracle jdk 1.7 with the same plugin, it
> >> did not work. Do you know a way to make it work again with jdk 1.7?
> >>
> >> Thank you,
> >> Laszlo
> >>
> >> --
> >>
> >> EOF
> >>
> >
> >
> 
> 
> -- 
> 
> EOF

-- 
Prasanna.,


Powered by BigRock.com



Re: SSL and JCE

2013-11-11 Thread Koushik Das
I see the JCE extensions in jdk 1.7 as well. They are present under 
/jre/lib/security. But still I see a test failure. Is there any 
other configuration that is required?

Running org.apache.cloudstack.network.lb.CertServiceTest
Tests run: 2, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 1.456 sec <<< 
FAILURE!

-Koushik

On 12-Nov-2013, at 11:19 AM, Prasanna Santhanam 
 wrote:

> My MacOSX 1.6 jdk seems to have the crypto extensions jce builtin and
> the build+test works. JDK 1.7 install does not have them though.
> 
> The JCE kit seems to carry a BCL which is not ASF friendly [1]. But
> this being part of the Java install and not the project it should be
> okay IMO if we note it in our wiki on building the project.
> 
> As for legal aspects - I found this which might be of some relevance.  
> http://markmail.org/message/evtkc656gewrkruf
> 
> [1] http://www.apache.org/legal/3party.html#transition-examples
> 
> On Mon, Nov 11, 2013 at 10:45:12PM +0100, Laszlo Hornyak wrote:
>> Hi,
>> 
>> That is a good question, I do not know for sure, but this package needs to
>> be signed by oracle, it is not redistributable and has teritorial import
>> restrictions, so it could be problematic :-( I hope it is not. Guys, can
>> someone help us here?
>> 
>> 
>> On Mon, Nov 11, 2013 at 10:21 PM, Syed Ahmed  wrote:
>> 
>>> Hi Laszlo,
>>> 
>>> The CertService uses BouncyCastle for certificate parsing and validation.
>>> The JCE extension provides the API for using BouncyCastle as the provider.
>>> So, JCE is required. I know that BouncyCastle is added in CS. Would it be
>>> possible to add JCE as a dependency too?
>>> 
>>> Thanks,
>>> -Syed
>>> 
>>> 
>>> On 13-11-10 09:55 AM, Laszlo Hornyak wrote:
>>> 
 Hi Sahmed and list,
 
 I ran into some failing tests this weekend related to the patch
 0076307863e9155273d9e4c14282de429388c9e9 apparently jenkins fails for
 the same reason. I did a short investigation and it turned out that in
 order to run the tests correctly, one has to download the sun jce policy
 files and put it in the jdk replacing the original policies.
 
 Questions:
 - Is there a more convenient deployment process? :-) It would be very
 useful for the jenkins environment as well.
 - I gave it a try and patched the oracle jdk 1.7 with the same plugin, it
 did not work. Do you know a way to make it work again with jdk 1.7?
 
 Thank you,
 Laszlo
 
 --
 
 EOF
 
>>> 
>>> 
>> 
>> 
>> -- 
>> 
>> EOF
> 
> -- 
> Prasanna.,
> 
> 
> Powered by BigRock.com
> 



RE: [ACS4.2.1] request for QA update

2013-11-11 Thread Radhika Puthiyetath
Could someone share the compatibility matrix for 4.2.1. This is to include in 
the RN.

-Original Message-
From: Abhinandan Prateek [mailto:abhinandan.prat...@citrix.com] 
Sent: Tuesday, November 12, 2013 10:14 AM
To: Sudha Ponnaganti; CloudStack Dev
Cc: Raja Pullela
Subject: Re: [ACS4.2.1] request for QA update

Daan reported in another thread that "4.1.1 to 4.2.1 upgrade works fine in a 
lab env".

Raja/Lucian, any update on 2.2.14 upgrade ?

-abhi

On 11/11/13 9:17 pm, "Sudha Ponnaganti" 
mailto:sudha.ponnaga...@citrix.com>> wrote:

Hi All,

Scope Status [1]

-  Rayees has posted automation results earlier BVTs and regressions 
were done in citrix lab on 4.2.1 branch

-  Tested a few regressions around VMWare as there are couple of issues 
got fixed in last phases of 4.2

-  250 issues got fixed for 4.2.1


Blockers for RC

-  We still have 7 Criticals/blockers that need to be fixed in JIRA ( 
Use query Fixed version 4.2.1)

-  Upgrade paths need to be closed

o   4,2 ( citrix is trying this out - will report back Wednesday)

o   4.1.1 ( Daan will report back by Friday)

o   2.2.14 > ( Lucian has been trying this path)

Good to have for RC

-  There are 80 Resolved defects. Would help if community can close 
these ( you can use query fix version 4.2.1, Status Resolved )

[1] 
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Cloudstack+4.2.1+Maintenance+Release
[2] 
https://cwiki.apache.org/confluence/display/CLOUDSTACK/4.2.1+Automation+Result

From: Abhinandan Prateek
Sent: Monday, November 11, 2013 1:56 AM
To: CloudStack Dev
Cc: Raja Pullela; Sudha Ponnaganti
Subject: [ACS4.2.1] request for QA update

Sudha/Raja,

   You guys have been doing a QA on 4.2.1 for quite some time now.
It would be good for community to know in general how the 4.2.1 branch is 
coming off in terms of quality.

-abhi


Re: [PROPOSAL] Liaison with ETSI NFV ISG

2013-11-11 Thread Chiradeep Vittal
OK, here's the draft of the Liaison request (template borrowed from
OpenDaylight)

--


To:
ETSI Industry Study Group (ISG) on Network Functions Virtualization
Prodip Sen, Chairman NFV ISG prodip@verizon.com
Andrew Malis, NFV Liaison Officer 

I am a member of the Apache CloudStack Project Management Committee (PMC)
and have been asked to serve as liaison from the Apache CloudStack
community to the ETSI Industry Standard Group on Network Functions
Virtualization.

Apache CloudStack is open source software designed to deploy and manage
large networks of virtual machines, as a highly available, highly scalable
Infrastructure as a Service (IaaS) cloud computing platform.  The platform
has pioneered the use of VNF to provide network services to IAAS tenants.
We are excited to see that NFV is going to realize its potential and look
forward to collaborating to realize this promise expeditiously.

The community would like to suggest these areas of collaboration:

1)  ETSI NFV ISG Documents: It would be very helpful to receive pointers
to the various documents being produced by the ETSI NFV ISG, even before
their formal publication, so that your needs can be incorporated into the
Apache CloudStack development effort.

2)  Sharing ideas and experience: We have many shared goals and a large
community of experienced cloud implementors. We have several opportunities
where someone from ETSI NFV ISG could present to the Apache CloudStack
community, including meetups and online fora , and our CloudStack
Collaboration Summit. We would also be quite pleased to present on Apache
CloudStack to ETSI NFV ISG in any forum you find appropriate. If
appropriate we can participate in working groups such as the MANO WG.

3)  Open Source:  We would love to get members of the  ETSI NFV ISG
participate in our community, especially in design ideas, code
contributions and the like. We hope that we can assist in producing
reference implementations and help iterate faster on crucial issues such
as interoperability.

Of course we welcome other ideas for collaboration with the NFV ISG.


---
-



On 11/11/13 1:02 AM, "Sebastien Goasguen"  wrote:

>How about Chiradeep makes the contact and proposal for CloudStack to
>join/be represented ?
>
>Then we can decide who is the representative. Daan could do it and Nguyen
>could be the substitute ?
>
>
>On Nov 9, 2013, at 8:38 AM, Daan Hoogland  wrote:
>
>> I don't mind being involved if needed.
>> 
>> On Fri, Nov 8, 2013 at 6:07 PM, Chip Childers 
>>wrote:
>>> On Fri, Nov 08, 2013 at 08:58:17AM +0700, Nguyen Anh Tu wrote:
 2013/11/7 Chiradeep Vittal 
 
> While I appreciate the confidence, there are weekly calls to attend.
> The particularly interesting one (MANO WG) happens on Wednesdays at
>6am
> PST.
> I've tried but there's very little chance that I can attend these
> meetings.
> Anybody in a more agreeable timezone?
> 
 
 Not sure if I have permitted to join, I'm in agreeable timezone (9pm
at
 local time). It's great and I'm willing to join to liaison team.
>>> 
>>> I'd say you are...  you're a committer on the project.  Perhaps you and
>>> Chiradeep can discuss how to get involved?
>



Re: SSL and JCE

2013-11-11 Thread Koushik Das
The following tests are failing in my environment even with the JCE extensions.

/* Test7: If no chain is given, the certificate should be self signed. 
Else, uploadShould Fail */
runUploadSslCertNoChain();

/* Test8: Chain is given but does not have root certificate */
runUploadSslCertNoRootCert();

/* Test9: The chain given is not the correct chain for the certificate 
*/
runUploadSslCertBadChain();

/* Test12: Given a certificate signed by a CA and a valid CA chain, 
upload should succeed */
runUploadSslCertWithCAChain();




On 12-Nov-2013, at 11:35 AM, Koushik Das  wrote:

> I see the JCE extensions in jdk 1.7 as well. They are present under 
> /jre/lib/security. But still I see a test failure. Is there any 
> other configuration that is required?
> 
> Running org.apache.cloudstack.network.lb.CertServiceTest
> Tests run: 2, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 1.456 sec <<< 
> FAILURE!
> 
> -Koushik
> 
> On 12-Nov-2013, at 11:19 AM, Prasanna Santhanam 
> wrote:
> 
>> My MacOSX 1.6 jdk seems to have the crypto extensions jce builtin and
>> the build+test works. JDK 1.7 install does not have them though.
>> 
>> The JCE kit seems to carry a BCL which is not ASF friendly [1]. But
>> this being part of the Java install and not the project it should be
>> okay IMO if we note it in our wiki on building the project.
>> 
>> As for legal aspects - I found this which might be of some relevance.  
>> http://markmail.org/message/evtkc656gewrkruf
>> 
>> [1] http://www.apache.org/legal/3party.html#transition-examples
>> 
>> On Mon, Nov 11, 2013 at 10:45:12PM +0100, Laszlo Hornyak wrote:
>>> Hi,
>>> 
>>> That is a good question, I do not know for sure, but this package needs to
>>> be signed by oracle, it is not redistributable and has teritorial import
>>> restrictions, so it could be problematic :-( I hope it is not. Guys, can
>>> someone help us here?
>>> 
>>> 
>>> On Mon, Nov 11, 2013 at 10:21 PM, Syed Ahmed  wrote:
>>> 
 Hi Laszlo,
 
 The CertService uses BouncyCastle for certificate parsing and validation.
 The JCE extension provides the API for using BouncyCastle as the provider.
 So, JCE is required. I know that BouncyCastle is added in CS. Would it be
 possible to add JCE as a dependency too?
 
 Thanks,
 -Syed
 
 
 On 13-11-10 09:55 AM, Laszlo Hornyak wrote:
 
> Hi Sahmed and list,
> 
> I ran into some failing tests this weekend related to the patch
> 0076307863e9155273d9e4c14282de429388c9e9 apparently jenkins fails for
> the same reason. I did a short investigation and it turned out that in
> order to run the tests correctly, one has to download the sun jce policy
> files and put it in the jdk replacing the original policies.
> 
> Questions:
> - Is there a more convenient deployment process? :-) It would be very
> useful for the jenkins environment as well.
> - I gave it a try and patched the oracle jdk 1.7 with the same plugin, it
> did not work. Do you know a way to make it work again with jdk 1.7?
> 
> Thank you,
> Laszlo
> 
> --
> 
> EOF
> 
 
 
>>> 
>>> 
>>> -- 
>>> 
>>> EOF
>> 
>> -- 
>> Prasanna.,
>> 
>> 
>> Powered by BigRock.com
>> 
> 



Review Request 15450: Fixed build failure

2013-11-11 Thread Rajani Karuturi

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

Review request for cloudstack, Santhosh Edukulla and Prasanna Santhanam.


Repository: cloudstack-git


Description
---

 Added parent in the rdpconsole pom. Fixed build failure


Diffs
-

  services/console-proxy-rdp/rdpconsole/pom.xml 71d0241 

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


Testing
---

Yes. Did mvn clean install -Pdeveloper -Dsimulator 


Thanks,

Rajani Karuturi



[ACS4.2.1] Release readiness

2013-11-11 Thread Abhinandan Prateek

While I was doing a dry run of building a RC and waiting on closure of last 
remaining critical issues, would like to know if there are any particular 
concerns about release readiness.
For one the upgrade path from 2.2.14 to 4.2.1 is in works.

Any other issues please pop up to save some last minute surprises.

-abhi


Re: SSL and JCE

2013-11-11 Thread Laszlo Hornyak
It seems OpenJDK 6 and 7 are ok. Oracle jdk 6 needs JCE, oracle jdk 7 may
need another extension (the JCE for jdk6 did not work for me).
I would recommend that we @Ignore the failing tests, add some assumption or
move them to a special test group which is not executed by default.


On Tue, Nov 12, 2013 at 7:28 AM, Koushik Das  wrote:

> The following tests are failing in my environment even with the JCE
> extensions.
>
> /* Test7: If no chain is given, the certificate should be self
> signed. Else, uploadShould Fail */
> runUploadSslCertNoChain();
>
> /* Test8: Chain is given but does not have root certificate */
> runUploadSslCertNoRootCert();
>
> /* Test9: The chain given is not the correct chain for the
> certificate */
> runUploadSslCertBadChain();
>
> /* Test12: Given a certificate signed by a CA and a valid CA
> chain, upload should succeed */
> runUploadSslCertWithCAChain();
>
>
>
>
> On 12-Nov-2013, at 11:35 AM, Koushik Das  wrote:
>
> > I see the JCE extensions in jdk 1.7 as well. They are present under
> /jre/lib/security. But still I see a test failure. Is there any
> other configuration that is required?
> >
> > Running org.apache.cloudstack.network.lb.CertServiceTest
> > Tests run: 2, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 1.456
> sec <<< FAILURE!
> >
> > -Koushik
> >
> > On 12-Nov-2013, at 11:19 AM, Prasanna Santhanam 
> > wrote:
> >
> >> My MacOSX 1.6 jdk seems to have the crypto extensions jce builtin and
> >> the build+test works. JDK 1.7 install does not have them though.
> >>
> >> The JCE kit seems to carry a BCL which is not ASF friendly [1]. But
> >> this being part of the Java install and not the project it should be
> >> okay IMO if we note it in our wiki on building the project.
> >>
> >> As for legal aspects - I found this which might be of some relevance.
> >> http://markmail.org/message/evtkc656gewrkruf
> >>
> >> [1] http://www.apache.org/legal/3party.html#transition-examples
> >>
> >> On Mon, Nov 11, 2013 at 10:45:12PM +0100, Laszlo Hornyak wrote:
> >>> Hi,
> >>>
> >>> That is a good question, I do not know for sure, but this package
> needs to
> >>> be signed by oracle, it is not redistributable and has teritorial
> import
> >>> restrictions, so it could be problematic :-( I hope it is not. Guys,
> can
> >>> someone help us here?
> >>>
> >>>
> >>> On Mon, Nov 11, 2013 at 10:21 PM, Syed Ahmed 
> wrote:
> >>>
>  Hi Laszlo,
> 
>  The CertService uses BouncyCastle for certificate parsing and
> validation.
>  The JCE extension provides the API for using BouncyCastle as the
> provider.
>  So, JCE is required. I know that BouncyCastle is added in CS. Would
> it be
>  possible to add JCE as a dependency too?
> 
>  Thanks,
>  -Syed
> 
> 
>  On 13-11-10 09:55 AM, Laszlo Hornyak wrote:
> 
> > Hi Sahmed and list,
> >
> > I ran into some failing tests this weekend related to the patch
> > 0076307863e9155273d9e4c14282de429388c9e9 apparently jenkins fails for
> > the same reason. I did a short investigation and it turned out that
> in
> > order to run the tests correctly, one has to download the sun jce
> policy
> > files and put it in the jdk replacing the original policies.
> >
> > Questions:
> > - Is there a more convenient deployment process? :-) It would be very
> > useful for the jenkins environment as well.
> > - I gave it a try and patched the oracle jdk 1.7 with the same
> plugin, it
> > did not work. Do you know a way to make it work again with jdk 1.7?
> >
> > Thank you,
> > Laszlo
> >
> > --
> >
> > EOF
> >
> 
> 
> >>>
> >>>
> >>> --
> >>>
> >>> EOF
> >>
> >> --
> >> Prasanna.,
> >>
> >> 
> >> Powered by BigRock.com
> >>
> >
>
>


-- 

EOF


Re: the plea to openstack

2013-11-11 Thread Gavin Lee
Worth reading, focus on users rather than vendors.
CloudStack should keep up the install base to seize end users.


On Sat, Nov 9, 2013 at 7:22 PM, Daan Hoogland wrote:

> H, I finally got around reading it. Good read indeed. I wonder how
> (if) we can organize ourselves and our communication so as to
> circumvent the traps described. I think the apache model takes some of
> it for us but doesn't keep us completely save. Not to worry to much
> though. Let us trust in the ways of human nature, a little ;)
>
>
> On Wed, Nov 6, 2013 at 10:05 PM, Donal Lafferty
>  wrote:
> > The Conway Law reference is a good to keep in mind as we enter the next
> collab conference.  (http://en.wikipedia.org/wiki/Conway's_law)
> >
> >> -Original Message-
> >> From: Sebastien Goasguen [mailto:run...@gmail.com]
> >> Sent: 06 November 2013 20:02
> >> To: dev@cloudstack.apache.org
> >> Subject: Re: the plea to openstack
> >>
> >> Agreed it's a very good read.
> >>
> >> -Sebastien
> >>
> >> On 6 Nov 2013, at 17:34, Marcus Sorensen  wrote:
> >>
> >> > http://stochasticresonance.wordpress.com/2013/11/04/openstack-a-plea/
> >> >
> >> > I thought this was an interesting read. There might be some things
> >> > CloudStack could learn or issues it could avoid by keeping some of his
> >> > points in mind.
>



-- 
Gavin