Review Request 16731: CLOUDSTACK-5803: Fixed issues related to egress rule

2014-01-08 Thread Gaurav Aradhye

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

Review request for cloudstack and Girish Shilamkar.


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


Repository: cloudstack-git


Description
---

Changes:

1) Ping to outside world was failing because the egress rule was created for 
TCP protocol.
Changed it to ICMP.

2) Changed assertion for security group behavior after revoking egress rule. By 
default, all outbound traffic is allowed when there is no egress rule is 
defined. This also fixes CLOUDSTACK-5191.

3) Code cleanup - removing unused variables, modification of imports.


Diffs
-

  test/integration/component/test_egress_rules.py 590f72a 

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


Testing
---

Tested on basic setup with SG.

Log:

test_authorizeIngressRule (test_egress_rules.TestAuthorizeIngressRule)
Test authorize ingress rule ... skipped 'skip'
test_01_default_group_with_egress (test_egress_rules.TestDefaultGroupEgress)
Test default group with egress rule before VM deploy and ping, ssh ... ok
test_01_default_group_with_egress 
(test_egress_rules.TestDefaultGroupEgressAfterDeploy)
Test default group with egress rule added after vm deploy and ping, ... ok
test_deployVM_InDefaultSecurityGroup 
(test_egress_rules.TestDefaultSecurityGroupEgress)
Test deploy VM in default security group with no egress rules ... skipped 'skip'
test_invalid_account_authroize (test_egress_rules.TestInvalidAccountAuthroize)
Test invalid account authroize ... skipped 'skip'
test_invalid_parameters (test_egress_rules.TestInvalidParametersForEgress)
Test invalid parameters for egress rules ... skipped 'skip'
test_multiple_account_egress_rule_positive 
(test_egress_rules.TestMultipleAccountsEgressRule)
Test multiple account egress rules positive case ... skipped 'skip'
test_multiple_account_egress_rule_negative 
(test_egress_rules.TestMultipleAccountsEgressRuleNeg)
Test multiple account egress rules negative case ... skipped 'skip'
test_revoke_egress_rule (test_egress_rules.TestRevokeEgressRule)
Test revoke security group egress rule ... ok
test_start_stop_vm_egress (test_egress_rules.TestStartStopVMWithEgressRule)
Test stop start Vm with egress rules ... skipped 'skip'

--
Ran 10 tests in 361.398s

OK (skipped=7)


Thanks,

Gaurav Aradhye



Re: Review Request 16731: CLOUDSTACK-5803: Fixed issues related to egress rule

2014-01-08 Thread Gaurav Aradhye

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

(Updated Jan. 8, 2014, 1:50 p.m.)


Review request for cloudstack and Girish Shilamkar.


Changes
---

This also fixes CLOUDSTACK-5191


Bugs: CLOUDSTACK-5191 and CLOUDSTACK-5803
https://issues.apache.org/jira/browse/CLOUDSTACK-5191
https://issues.apache.org/jira/browse/CLOUDSTACK-5803


Repository: cloudstack-git


Description
---

Changes:

1) Ping to outside world was failing because the egress rule was created for 
TCP protocol.
Changed it to ICMP.

2) Changed assertion for security group behavior after revoking egress rule. By 
default, all outbound traffic is allowed when there is no egress rule is 
defined. This also fixes CLOUDSTACK-5191.

3) Code cleanup - removing unused variables, modification of imports.


Diffs
-

  test/integration/component/test_egress_rules.py 590f72a 

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


Testing
---

Tested on basic setup with SG.

Log:

test_authorizeIngressRule (test_egress_rules.TestAuthorizeIngressRule)
Test authorize ingress rule ... skipped 'skip'
test_01_default_group_with_egress (test_egress_rules.TestDefaultGroupEgress)
Test default group with egress rule before VM deploy and ping, ssh ... ok
test_01_default_group_with_egress 
(test_egress_rules.TestDefaultGroupEgressAfterDeploy)
Test default group with egress rule added after vm deploy and ping, ... ok
test_deployVM_InDefaultSecurityGroup 
(test_egress_rules.TestDefaultSecurityGroupEgress)
Test deploy VM in default security group with no egress rules ... skipped 'skip'
test_invalid_account_authroize (test_egress_rules.TestInvalidAccountAuthroize)
Test invalid account authroize ... skipped 'skip'
test_invalid_parameters (test_egress_rules.TestInvalidParametersForEgress)
Test invalid parameters for egress rules ... skipped 'skip'
test_multiple_account_egress_rule_positive 
(test_egress_rules.TestMultipleAccountsEgressRule)
Test multiple account egress rules positive case ... skipped 'skip'
test_multiple_account_egress_rule_negative 
(test_egress_rules.TestMultipleAccountsEgressRuleNeg)
Test multiple account egress rules negative case ... skipped 'skip'
test_revoke_egress_rule (test_egress_rules.TestRevokeEgressRule)
Test revoke security group egress rule ... ok
test_start_stop_vm_egress (test_egress_rules.TestStartStopVMWithEgressRule)
Test stop start Vm with egress rules ... skipped 'skip'

--
Ran 10 tests in 361.398s

OK (skipped=7)


Thanks,

Gaurav Aradhye



Review Request 16732: CLOUDSTACK-5827: [Automation] Destroy VM failed, while deleting account

2014-01-08 Thread Harikrishna Patnala

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

Review request for cloudstack and Koushik Das.


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


Repository: cloudstack-git


Description
---

CLOUDSTACK-5827: [Automation] Destroy VM failed, while deleting account

VMInstanceVO needs to be updated after advancestop.


Diffs
-

  engine/orchestration/src/com/cloud/vm/VirtualMachineManagerImpl.java f959b93 

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


Testing
---


Thanks,

Harikrishna Patnala



[Responsiveness report] 2014w01 users

2014-01-08 Thread Daan Hoogland
Here's one for the early day gurus:

http://markmail.org/message/yfpzrhks525fj626 Usage record clean-up? by
Tamas Monos


for an explanation of this report see
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Responsiveness+report


Jenkins build is back to normal : build-master #375

2014-01-08 Thread jenkins
See 



Jenkins build is back to normal : build-master » Apache CloudStack Plugin - Hypervisor KVM #375

2014-01-08 Thread jenkins
See 




RE: [Proposal] Switch to Java 7

2014-01-08 Thread Donal Lafferty
+1 - used Java 7 for Hyper-V work.  Only annoying bit was back porting to 6 for 
master merge.

DL


> -Original Message-
> From: Hugo Trippaers [mailto:trip...@gmail.com]
> Sent: 07 January 2014 22:50
> To: dev@cloudstack.apache.org
> Cc: dev@cloudstack.apache.org
> Subject: Re: [Proposal] Switch to Java 7
> 
> I would be in favor as well. In addition to the already discussed reasons, I
> think it would be good to try to get our users to a well maintained version of
> Java. From a security point of view 1.6 is not a smart choice any more.
> 
> Upgrading to Jdk 7 could also trigger an upgrade to tomcat 7. Best practice
> indicates that t6 should be used with Jdk 16 and T7 with Jdk 17. I didn't 
> check
> yet if t7 is available in our supported distros atm.
> 
> Anyway I would propose to bump the version of CS to 5 when we do this, so
> we clearly indicate to our users that something serious has changed. Some of
> our users will have to upgrade components outside the CS scope (Jdk) and I
> think that warrants a major version bump.
> 
> Cheers,
> 
> Hugo
> 
> Verstuurd vanaf mijn iPad
> 
> > Op 7 jan. 2014 om 23:38 heeft Kelven Yang  het
> volgende geschreven:
> >
> > +1 for switching to Java 7 in CloudStack 4.4.
> >
> > Kelven
> >
> >> On 1/6/14, 10:27 PM, "Wido den Hollander"  wrote:
> >>
> >> Just to repeat what has been discussed some time ago.
> >>
> >> All the current Long Term Support distributions have Java 7 available.
> >>
> >> RHEL6, RHEL7, Ubuntu 12.04, Ubuntu 14.04 (due in April) will all have
> >> Java 7 available.
> >>
> >> I don't see a problem in switching to Java 7 with CloudStack 4.4 or
> >> 4.5
> >>
> >> Wido
> >>
> >>> On 01/07/2014 12:18 AM, Kelven Yang wrote:
> >>> Java 7 has been around for some time now. I strongly suggest
> >>> CloudStack to adopt Java 7 as early as possible, the reason I feel
> >>> like to raise the issue is from the some of practicing with the new
> >>> DB transaction pattern, as following example shows.  The new
> >>> Transaction pattern uses anonymous class to beautify the code
> >>> structure, but in the mean time, it will introduce a couple runtime
> >>> costs
> >>>
> >>>   1.  Anonymous class introduces a ³captured context², information
> >>> exchange between the containing context and the anonymous class
> >>> implementation context has either to go through with mutable
> >>> passed-in parameter or returned result object, in the following
> >>> example, without changing basic Transaction framework, I have to
> >>> exchange through returned result with an un-typed array. This has a
> >>> few implications at run time, basically with each call of the
> >>> method, it will generate two objects to the heap. Depends on how
> >>> frequently the involved method will be called, it may introduce quite a
> burden to java GC process
> >>>   2.  Anonymous class captured context also means that there will be
> >>> more hidden classes be generated, since each appearance of the
> >>> anonymous class implementation will have a distance copy of its own
> >>> as hidden class, it will generally increase our permanent heap
> >>> usage, which is already pretty huge with current CloudStack code base.
> >>>
> >>> Java 7 has a language level support to address the issues in a
> >>> cheaper way that our current DB Transaction code pattern is trying to
> solve.
> >>>
> http://docs.oracle.com/javase/tutorial/essential/exceptions/tryResourceCl
> >>> ose.html.   So, time to adopt Java 7?
> >>>
> >>> public Outcome startVmThroughJobQueue(final
> >>> String vmUuid,
> >>> final Map params,
> >>> final DeploymentPlan planToDeploy) {
> >>>
> >>> final CallContext context = CallContext.current();
> >>> final User callingUser = context.getCallingUser();
> >>> final Account callingAccount = context.getCallingAccount();
> >>>
> >>> final VMInstanceVO vm = _vmDao.findByUuid(vmUuid);
> >>>
> >>>
> >>> Object[] result = Transaction.execute(new
> >>> TransactionCallback() {
> >>> @Override
> >>> public Object[] doInTransaction(TransactionStatus status) {
> >>> VmWorkJobVO workJob = null;
> >>>
> >>>_vmDao.lockRow(vm.getId(), true);
> >>>List pendingWorkJobs =
> >>> _workJobDao.listPendingWorkJobs(VirtualMachine.Type.Instance,
> >>> vm.getId(), VmWorkStart.class.getName());
> >>>
> >>>if (pendingWorkJobs.size() > 0) {
> >>>assert (pendingWorkJobs.size() == 1);
> >>>workJob = pendingWorkJobs.get(0);
> >>>} else {
> >>>workJob = new VmWorkJobVO(context.getContextId());
> >>>
> >>>
> >>>
> workJob.setDispatcher(VmWorkConstants.VM_WORK_JOB_DISPATCHER);
> >>>workJob.setCmd(VmWorkStart.class.getName());
> >>>
> >>>workJob.setAccountId(callingAccount.getId());
> >>>workJob.setUserId(callingUser.getId());
> >>>workJob.setStep(VmWorkJobVO.Step.Starting);
> >>>   

Re: [VOTE] 3rd round of voting for ASF 4.2.1 RC

2014-01-08 Thread Abhinandan Prateek
4.2.1 RC is now approved as a GA build with following votes:

+1 : 7 votes - 3 bindings from Daan, Chip and David.
+/-0: 2 votes from Tomesz and sebastian.

Some issues have been pointed out by Tomasz (5422,5332 & 3806), Andrei
(issue with KVM:S3) and Wei pointed out issues with DevCloud and OVS
support for KVM. 
These should be addresses in the next release (4.3).

-abhi



On 17/12/13 7:19 pm, "Abhinandan Prateek" 
wrote:

>The 4.2.1 is re-spun mainly because the commit that was used to generate
>the previous RC did not get pushed to repo.
>
>Following are the particulars to vote for this time around:
>
>https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=shortlog;h=refs
>/heads/4.2
>commit: 1b2b58fe352a19aee1721bd79b9d023d36e80ec5
>
>List of changes are available in Release Notes, a summary can be accessed
>here:
>https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=blob_plain;f=CH
>ANGES;hb=4.2
>
>Source release revision 3911 (checksums and signatures are available at
>the same location):
>https://dist.apache.org/repos/dist/dev/cloudstack/4.2.1/
>
>PGP release keys (signed using RSA Key ID = 42443AA1):
>https://dist.apache.org/repos/dist/release/cloudstack/KEYS
>
>Vote will be open for 72 hours (until 20 Dec 2013 End of day PST).
>
>For sanity in tallying the vote, can PMC members please be sure to
>indicate "(binding)" with their vote?
>
>[ ] +1  approve
>[ ] +0  no opinion
>[ ] -1  disapprove (and reason why)
>



[VOTE][RESULT] 3rd round of voting for ASF 4.2.1 RC is now closed

2014-01-08 Thread Abhinandan Prateek
4.2.1 RC is now approved as a GA build with following votes:

+1 : 7 votes -- 3 bindings from Daan, Chip and David.
+/-0: 2 votes from Tomesz and sebastian.

Some issues have been pointed out by Tomasz (5422,5332 & 3806), Andrei
(issue with KVM:S3) and Wei pointed out issues with DevCloud and OVS
support for KVM.
These should be addresses in the next release (4.3).

-abhi




On 17/12/13 7:19 pm, "Abhinandan Prateek" 
wrote:

>The 4.2.1 is re-spun mainly because the commit that was used to generate
>the previous RC did not get pushed to repo.
>
>Following are the particulars to vote for this time around:
>
>https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=shortlog;h=refs
>/heads/4.2
>commit: 1b2b58fe352a19aee1721bd79b9d023d36e80ec5
>
>List of changes are available in Release Notes, a summary can be accessed
>here:
>https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=blob_plain;f=CH
>ANGES;hb=4.2
>
>Source release revision 3911 (checksums and signatures are available at
>the same location):
>https://dist.apache.org/repos/dist/dev/cloudstack/4.2.1/
>
>PGP release keys (signed using RSA Key ID = 42443AA1):
>https://dist.apache.org/repos/dist/release/cloudstack/KEYS
>
>Vote will be open for 72 hours (until 20 Dec 2013 End of day PST).
>
>For sanity in tallying the vote, can PMC members please be sure to
>indicate "(binding)" with their vote?
>
>[ ] +1  approve
>[ ] +0  no opinion
>[ ] -1  disapprove (and reason why)
>



Unicode Characters in Input Fields

2014-01-08 Thread Alex Hitchins
Hi all,

I've run in to a bug regarding entering Unicode characters in input fields, 
namely the new user form.

My issue is that you can create new users in CPBM with Unicode characters in 
the name - such as ü however this causes a problem in CloudStack as they aren't 
supported.

I can see the line of code where the validation occurs - my question is - is 
this be design or is this an issue? I'm guessing Japanese and German users can 
enter in Unicode characters, especially for the users names.




Regards,

Alex Hitchins

Need Enterprise Grade Support for Apache CloudStack?
Our CloudStack Infrastructure 
Support offers the 
best 24/7 SLA for CloudStack Environments.

Apache CloudStack Bootcamp training courses

**NEW!** CloudStack 4.2 training
08/09 January 2014, London
13-17 January 2014, GLOBAL. Instructor led, 
On-line
20-24 January 2014, GLOBAL. Instructor led, 
On-line

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 16733: CLOUDSTACK-5630: Fixed snapshots' test cases

2014-01-08 Thread ASF Subversion and Git Services

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


Commit b98c0ee80953e801cef2ede18f720d0cf8c91194 in branch refs/heads/master 
from Gaurav Aradhye
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=b98c0ee ]

CLOUDSTACK-5630: Fixed snapshots' test cases


- ASF Subversion and Git Services


On Jan. 8, 2014, 11:39 a.m., Gaurav Aradhye wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/16733/
> ---
> 
> (Updated Jan. 8, 2014, 11:39 a.m.)
> 
> 
> Review request for cloudstack and Girish Shilamkar.
> 
> 
> Bugs: CLOUDSTACK-5630
> https://issues.apache.org/jira/browse/CLOUDSTACK-5630
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Fixes:
> [1]
> test_03_snapshots_per_account FAILED  Check Snapshot state is Running or not 
> test_03_snapshots_per_domain  FAILED  Check Snapshot state is Running or not
> 
> Above test cases failed because the snapshot state was Allocated in this 
> case, and the state "Allocated" was not added in the assertion list.
> Corrected the assertion messages.
> 
> [2]
> test_02_accountSnapshotClean  FAILED  Snapshot was not found on NFS 
> test_04_snapshot_limitFAILED  False is not True 
> test_01_createVM_snapshotTemplate FAILED  False is not True 
> test_02_snapshot_data_diskFAILED  False is not True
> 
> Above test cases failed because the code would check whether the snapshot is 
> present or not in wrong storage pool.
> When there are multiple secondary storage allocated for a zone, we should get 
> the store_id of the snapshot and then get the respective image store and then 
> check on that store.
> This additional step was missing.
> 
> 
> Diffs
> -
> 
>   test/integration/component/test_resource_limits.py b543e7b 
>   tools/marvin/marvin/integration/lib/utils.py 25ebe28 
> 
> Diff: https://reviews.apache.org/r/16733/diff/
> 
> 
> Testing
> ---
> 
> Tested locally.
> 
> 
> Thanks,
> 
> Gaurav Aradhye
> 
>



Re: Review Request 16733: CLOUDSTACK-5630: Fixed snapshots' test cases

2014-01-08 Thread ASF Subversion and Git Services

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


Commit 4e0b44c0d683dec2c4f28b3e05aa1d136e949fdd in branch refs/heads/4.3 from 
Gaurav Aradhye
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=4e0b44c ]

CLOUDSTACK-5630: Fixed snapshots' test cases


- ASF Subversion and Git Services


On Jan. 8, 2014, 11:39 a.m., Gaurav Aradhye wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/16733/
> ---
> 
> (Updated Jan. 8, 2014, 11:39 a.m.)
> 
> 
> Review request for cloudstack and Girish Shilamkar.
> 
> 
> Bugs: CLOUDSTACK-5630
> https://issues.apache.org/jira/browse/CLOUDSTACK-5630
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Fixes:
> [1]
> test_03_snapshots_per_account FAILED  Check Snapshot state is Running or not 
> test_03_snapshots_per_domain  FAILED  Check Snapshot state is Running or not
> 
> Above test cases failed because the snapshot state was Allocated in this 
> case, and the state "Allocated" was not added in the assertion list.
> Corrected the assertion messages.
> 
> [2]
> test_02_accountSnapshotClean  FAILED  Snapshot was not found on NFS 
> test_04_snapshot_limitFAILED  False is not True 
> test_01_createVM_snapshotTemplate FAILED  False is not True 
> test_02_snapshot_data_diskFAILED  False is not True
> 
> Above test cases failed because the code would check whether the snapshot is 
> present or not in wrong storage pool.
> When there are multiple secondary storage allocated for a zone, we should get 
> the store_id of the snapshot and then get the respective image store and then 
> check on that store.
> This additional step was missing.
> 
> 
> Diffs
> -
> 
>   test/integration/component/test_resource_limits.py b543e7b 
>   tools/marvin/marvin/integration/lib/utils.py 25ebe28 
> 
> Diff: https://reviews.apache.org/r/16733/diff/
> 
> 
> Testing
> ---
> 
> Tested locally.
> 
> 
> Thanks,
> 
> Gaurav Aradhye
> 
>



Re: Review Request 16733: CLOUDSTACK-5630: Fixed snapshots' test cases

2014-01-08 Thread Girish Shilamkar

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

Ship it!


Committed to 4.3 and master

- Girish Shilamkar


On Jan. 8, 2014, 11:39 a.m., Gaurav Aradhye wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/16733/
> ---
> 
> (Updated Jan. 8, 2014, 11:39 a.m.)
> 
> 
> Review request for cloudstack and Girish Shilamkar.
> 
> 
> Bugs: CLOUDSTACK-5630
> https://issues.apache.org/jira/browse/CLOUDSTACK-5630
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Fixes:
> [1]
> test_03_snapshots_per_account FAILED  Check Snapshot state is Running or not 
> test_03_snapshots_per_domain  FAILED  Check Snapshot state is Running or not
> 
> Above test cases failed because the snapshot state was Allocated in this 
> case, and the state "Allocated" was not added in the assertion list.
> Corrected the assertion messages.
> 
> [2]
> test_02_accountSnapshotClean  FAILED  Snapshot was not found on NFS 
> test_04_snapshot_limitFAILED  False is not True 
> test_01_createVM_snapshotTemplate FAILED  False is not True 
> test_02_snapshot_data_diskFAILED  False is not True
> 
> Above test cases failed because the code would check whether the snapshot is 
> present or not in wrong storage pool.
> When there are multiple secondary storage allocated for a zone, we should get 
> the store_id of the snapshot and then get the respective image store and then 
> check on that store.
> This additional step was missing.
> 
> 
> Diffs
> -
> 
>   test/integration/component/test_resource_limits.py b543e7b 
>   tools/marvin/marvin/integration/lib/utils.py 25ebe28 
> 
> Diff: https://reviews.apache.org/r/16733/diff/
> 
> 
> Testing
> ---
> 
> Tested locally.
> 
> 
> Thanks,
> 
> Gaurav Aradhye
> 
>



Review Request 16733: CLOUDSTACK-5630: Fixed snapshots' test cases

2014-01-08 Thread Gaurav Aradhye

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

Review request for cloudstack and Girish Shilamkar.


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


Repository: cloudstack-git


Description
---

Fixes:
[1]
test_03_snapshots_per_account   FAILED  Check Snapshot state is Running or not 
test_03_snapshots_per_domainFAILED  Check Snapshot state is Running or not

Above test cases failed because the snapshot state was Allocated in this case, 
and the state "Allocated" was not added in the assertion list.
Corrected the assertion messages.

[2]
test_02_accountSnapshotCleanFAILED  Snapshot was not found on NFS 
test_04_snapshot_limit  FAILED  False is not True 
test_01_createVM_snapshotTemplate   FAILED  False is not True 
test_02_snapshot_data_disk  FAILED  False is not True

Above test cases failed because the code would check whether the snapshot is 
present or not in wrong storage pool.
When there are multiple secondary storage allocated for a zone, we should get 
the store_id of the snapshot and then get the respective image store and then 
check on that store.
This additional step was missing.


Diffs
-

  test/integration/component/test_resource_limits.py b543e7b 
  tools/marvin/marvin/integration/lib/utils.py 25ebe28 

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


Testing
---

Tested locally.


Thanks,

Gaurav Aradhye



Jenkins build is back to normal : cloudstack-4.3-maven-build #291

2014-01-08 Thread jenkins
See 



Re: Review Request 16560: CLOUDSTACK-5711 allow scaling from the same offering when using custom compute offering.

2014-01-08 Thread bharat kumar

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

(Updated Jan. 8, 2014, 12:16 p.m.)


Review request for cloudstack and Koushik Das.


Repository: cloudstack-git


Description
---

CLOUDSTACK-5711 allow scaling from the same offering when using custom compute 
offering.
https://issues.apache.org/jira/browse/CLOUDSTACK-5711


Diffs (updated)
-

  api/src/com/cloud/vm/VirtualMachineProfile.java 3da8397 
  engine/api/src/com/cloud/vm/VirtualMachineManager.java 5e57b85 
  engine/components-api/src/com/cloud/vm/VirtualMachineProfileImpl.java 8282b16 
  engine/orchestration/src/com/cloud/vm/VirtualMachineManagerImpl.java f959b93 
  engine/orchestration/src/com/cloud/vm/VmWorkReconfigure.java 1141577 
  engine/orchestration/test/com/cloud/vm/VirtualMachineManagerImplTest.java 
7d55064 
  server/src/com/cloud/vm/UserVmManager.java 85322f2 
  server/src/com/cloud/vm/UserVmManagerImpl.java 23df880 
  server/test/com/cloud/vm/UserVmManagerTest.java 34090ef 

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


Testing
---

tested on 4.3


Thanks,

bharat kumar



Re: Review Request 16731: CLOUDSTACK-5803: Fixed issues related to egress rule

2014-01-08 Thread ASF Subversion and Git Services

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


Commit f15c8d22e19fda0f1b2fc09051626a32ba732c0e in branch refs/heads/4.3 from 
Gaurav Aradhye
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=f15c8d2 ]

CLOUDSTACK-5803: Fixed issues related to egress rule


- ASF Subversion and Git Services


On Jan. 8, 2014, 8:20 a.m., Gaurav Aradhye wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/16731/
> ---
> 
> (Updated Jan. 8, 2014, 8:20 a.m.)
> 
> 
> Review request for cloudstack and Girish Shilamkar.
> 
> 
> Bugs: CLOUDSTACK-5191 and CLOUDSTACK-5803
> https://issues.apache.org/jira/browse/CLOUDSTACK-5191
> https://issues.apache.org/jira/browse/CLOUDSTACK-5803
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Changes:
> 
> 1) Ping to outside world was failing because the egress rule was created for 
> TCP protocol.
> Changed it to ICMP.
> 
> 2) Changed assertion for security group behavior after revoking egress rule. 
> By default, all outbound traffic is allowed when there is no egress rule is 
> defined. This also fixes CLOUDSTACK-5191.
> 
> 3) Code cleanup - removing unused variables, modification of imports.
> 
> 
> Diffs
> -
> 
>   test/integration/component/test_egress_rules.py 590f72a 
> 
> Diff: https://reviews.apache.org/r/16731/diff/
> 
> 
> Testing
> ---
> 
> Tested on basic setup with SG.
> 
> Log:
> 
> test_authorizeIngressRule (test_egress_rules.TestAuthorizeIngressRule)
> Test authorize ingress rule ... skipped 'skip'
> test_01_default_group_with_egress (test_egress_rules.TestDefaultGroupEgress)
> Test default group with egress rule before VM deploy and ping, ssh ... ok
> test_01_default_group_with_egress 
> (test_egress_rules.TestDefaultGroupEgressAfterDeploy)
> Test default group with egress rule added after vm deploy and ping, ... ok
> test_deployVM_InDefaultSecurityGroup 
> (test_egress_rules.TestDefaultSecurityGroupEgress)
> Test deploy VM in default security group with no egress rules ... skipped 
> 'skip'
> test_invalid_account_authroize (test_egress_rules.TestInvalidAccountAuthroize)
> Test invalid account authroize ... skipped 'skip'
> test_invalid_parameters (test_egress_rules.TestInvalidParametersForEgress)
> Test invalid parameters for egress rules ... skipped 'skip'
> test_multiple_account_egress_rule_positive 
> (test_egress_rules.TestMultipleAccountsEgressRule)
> Test multiple account egress rules positive case ... skipped 'skip'
> test_multiple_account_egress_rule_negative 
> (test_egress_rules.TestMultipleAccountsEgressRuleNeg)
> Test multiple account egress rules negative case ... skipped 'skip'
> test_revoke_egress_rule (test_egress_rules.TestRevokeEgressRule)
> Test revoke security group egress rule ... ok
> test_start_stop_vm_egress (test_egress_rules.TestStartStopVMWithEgressRule)
> Test stop start Vm with egress rules ... skipped 'skip'
> 
> --
> Ran 10 tests in 361.398s
> 
> OK (skipped=7)
> 
> 
> Thanks,
> 
> Gaurav Aradhye
> 
>



Re: Review Request 16731: CLOUDSTACK-5803: Fixed issues related to egress rule

2014-01-08 Thread ASF Subversion and Git Services

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


Commit 777ab1494205667c073f3d876d2ba1665b5c3f4b in branch refs/heads/master 
from Gaurav Aradhye
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=777ab14 ]

CLOUDSTACK-5803: Fixed issues related to egress rule


- ASF Subversion and Git Services


On Jan. 8, 2014, 8:20 a.m., Gaurav Aradhye wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/16731/
> ---
> 
> (Updated Jan. 8, 2014, 8:20 a.m.)
> 
> 
> Review request for cloudstack and Girish Shilamkar.
> 
> 
> Bugs: CLOUDSTACK-5191 and CLOUDSTACK-5803
> https://issues.apache.org/jira/browse/CLOUDSTACK-5191
> https://issues.apache.org/jira/browse/CLOUDSTACK-5803
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Changes:
> 
> 1) Ping to outside world was failing because the egress rule was created for 
> TCP protocol.
> Changed it to ICMP.
> 
> 2) Changed assertion for security group behavior after revoking egress rule. 
> By default, all outbound traffic is allowed when there is no egress rule is 
> defined. This also fixes CLOUDSTACK-5191.
> 
> 3) Code cleanup - removing unused variables, modification of imports.
> 
> 
> Diffs
> -
> 
>   test/integration/component/test_egress_rules.py 590f72a 
> 
> Diff: https://reviews.apache.org/r/16731/diff/
> 
> 
> Testing
> ---
> 
> Tested on basic setup with SG.
> 
> Log:
> 
> test_authorizeIngressRule (test_egress_rules.TestAuthorizeIngressRule)
> Test authorize ingress rule ... skipped 'skip'
> test_01_default_group_with_egress (test_egress_rules.TestDefaultGroupEgress)
> Test default group with egress rule before VM deploy and ping, ssh ... ok
> test_01_default_group_with_egress 
> (test_egress_rules.TestDefaultGroupEgressAfterDeploy)
> Test default group with egress rule added after vm deploy and ping, ... ok
> test_deployVM_InDefaultSecurityGroup 
> (test_egress_rules.TestDefaultSecurityGroupEgress)
> Test deploy VM in default security group with no egress rules ... skipped 
> 'skip'
> test_invalid_account_authroize (test_egress_rules.TestInvalidAccountAuthroize)
> Test invalid account authroize ... skipped 'skip'
> test_invalid_parameters (test_egress_rules.TestInvalidParametersForEgress)
> Test invalid parameters for egress rules ... skipped 'skip'
> test_multiple_account_egress_rule_positive 
> (test_egress_rules.TestMultipleAccountsEgressRule)
> Test multiple account egress rules positive case ... skipped 'skip'
> test_multiple_account_egress_rule_negative 
> (test_egress_rules.TestMultipleAccountsEgressRuleNeg)
> Test multiple account egress rules negative case ... skipped 'skip'
> test_revoke_egress_rule (test_egress_rules.TestRevokeEgressRule)
> Test revoke security group egress rule ... ok
> test_start_stop_vm_egress (test_egress_rules.TestStartStopVMWithEgressRule)
> Test stop start Vm with egress rules ... skipped 'skip'
> 
> --
> Ran 10 tests in 361.398s
> 
> OK (skipped=7)
> 
> 
> Thanks,
> 
> Gaurav Aradhye
> 
>



Re: Review Request 16684: CLOUDSTACK-5802: Increased timeout for template state to become ready, improved assertion messages

2014-01-08 Thread Girish Shilamkar

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

Ship it!


Committed to 4.3 and master

- Girish Shilamkar


On Jan. 7, 2014, 1:13 p.m., Ashutosh Kelkar wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/16684/
> ---
> 
> (Updated Jan. 7, 2014, 1:13 p.m.)
> 
> 
> Review request for cloudstack and Girish Shilamkar.
> 
> 
> Bugs: CLOUDSTACK-5802
> https://issues.apache.org/jira/browse/CLOUDSTACK-5802
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Template fails to come to ready state after 60 seconds, so increased the 
> timeout. Also, improved the assertion messages to reflect the correct error.
> 
> 
> Diffs
> -
> 
>   test/integration/component/test_blocker_bugs.py 5488ddb 
>   test/integration/component/test_templates.py af86d32 
> 
> Diff: https://reviews.apache.org/r/16684/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Ashutosh Kelkar
> 
>



Review Request 16736: reverted encryption changes for ldap hostname and port. handled encryption during upgrade

2014-01-08 Thread Rajani Karuturi

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

Review request for cloudstack and Abhinandan Prateek.


Bugs: CLOUDSTACK-5790 and CLOUDSTACK-5791
https://issues.apache.org/jira/browse/CLOUDSTACK-5790
https://issues.apache.org/jira/browse/CLOUDSTACK-5791


Repository: cloudstack-git


Description
---

1. Reverted the commit for encrypting ldap hostname and port
2. decrypted ldap hostname and port during upgrade as they are not encrypted 
now.


Diffs
-

  engine/schema/src/com/cloud/upgrade/dao/Upgrade421to430.java 6df44ec 
  
plugins/user-authenticators/ldap/src/org/apache/cloudstack/api/command/LDAPConfigCmd.java
 db6d7dd 
  
plugins/user-authenticators/ldap/src/org/apache/cloudstack/api/response/LdapConfigurationResponse.java
 f03df42 
  
plugins/user-authenticators/ldap/src/org/apache/cloudstack/ldap/LdapConfigurationVO.java
 54b35cb 
  
plugins/user-authenticators/ldap/src/org/apache/cloudstack/ldap/LdapManagerImpl.java
 42b0aeb 
  setup/db/db/schema-421to430.sql 1cd891b 
  setup/db/db/schema-421to430.sql b26166a 

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


Testing
---

manually


Thanks,

Rajani Karuturi



Re: Review Request 16736: reverted encryption changes for ldap hostname and port. handled encryption during upgrade

2014-01-08 Thread Rajani Karuturi

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

(Updated Jan. 8, 2014, 1:03 p.m.)


Review request for cloudstack and Abhinandan Prateek.


Changes
---

this patch is for 4.3 branch


Bugs: CLOUDSTACK-5790 and CLOUDSTACK-5791
https://issues.apache.org/jira/browse/CLOUDSTACK-5790
https://issues.apache.org/jira/browse/CLOUDSTACK-5791


Repository: cloudstack-git


Description
---

1. Reverted the commit for encrypting ldap hostname and port
2. decrypted ldap hostname and port during upgrade as they are not encrypted 
now.


Diffs (updated)
-

  engine/schema/src/com/cloud/upgrade/dao/Upgrade421to430.java 471307a 
  
plugins/user-authenticators/ldap/src/org/apache/cloudstack/api/command/LDAPConfigCmd.java
 53d3877 
  
plugins/user-authenticators/ldap/src/org/apache/cloudstack/api/response/LdapConfigurationResponse.java
 caabbe7 
  
plugins/user-authenticators/ldap/src/org/apache/cloudstack/ldap/LdapConfigurationVO.java
 2fb6332 
  
plugins/user-authenticators/ldap/src/org/apache/cloudstack/ldap/LdapManagerImpl.java
 c2158f4 
  setup/db/db/schema-421to430.sql 284fb17 
  setup/db/db/schema-421to430.sql 7098632 

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


Testing
---

manually


Thanks,

Rajani Karuturi



Re: Review Request 16732: CLOUDSTACK-5827: [Automation] Destroy VM failed, while deleting account

2014-01-08 Thread ASF Subversion and Git Services

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


Commit c3e6444adfe6d8a640cf6e50b3d2637af74253d5 in branch refs/heads/4.3 from 
Harikrishna Patnala
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=c3e6444 ]

CLOUDSTACK-5827: [Automation] Destroy VM failed, while deleting account

Signed-off-by: Koushik Das 


- ASF Subversion and Git Services


On Jan. 8, 2014, 9:43 a.m., Harikrishna Patnala wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/16732/
> ---
> 
> (Updated Jan. 8, 2014, 9:43 a.m.)
> 
> 
> Review request for cloudstack and Koushik Das.
> 
> 
> Bugs: CLOUDSTACK-5827
> https://issues.apache.org/jira/browse/CLOUDSTACK-5827
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> CLOUDSTACK-5827: [Automation] Destroy VM failed, while deleting account
> 
> VMInstanceVO needs to be updated after advancestop.
> 
> 
> Diffs
> -
> 
>   engine/orchestration/src/com/cloud/vm/VirtualMachineManagerImpl.java 
> f959b93 
> 
> Diff: https://reviews.apache.org/r/16732/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Harikrishna Patnala
> 
>



Re: Review Request 16732: CLOUDSTACK-5827: [Automation] Destroy VM failed, while deleting account

2014-01-08 Thread ASF Subversion and Git Services

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


Commit 00e67f57e7c5354a36a664f38ad72e3481dabdec in branch refs/heads/master 
from Harikrishna Patnala
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=00e67f5 ]

CLOUDSTACK-5827: [Automation] Destroy VM failed, while deleting account

Signed-off-by: Koushik Das 


- ASF Subversion and Git Services


On Jan. 8, 2014, 9:43 a.m., Harikrishna Patnala wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/16732/
> ---
> 
> (Updated Jan. 8, 2014, 9:43 a.m.)
> 
> 
> Review request for cloudstack and Koushik Das.
> 
> 
> Bugs: CLOUDSTACK-5827
> https://issues.apache.org/jira/browse/CLOUDSTACK-5827
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> CLOUDSTACK-5827: [Automation] Destroy VM failed, while deleting account
> 
> VMInstanceVO needs to be updated after advancestop.
> 
> 
> Diffs
> -
> 
>   engine/orchestration/src/com/cloud/vm/VirtualMachineManagerImpl.java 
> f959b93 
> 
> Diff: https://reviews.apache.org/r/16732/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Harikrishna Patnala
> 
>



Re: Review Request 16732: CLOUDSTACK-5827: [Automation] Destroy VM failed, while deleting account

2014-01-08 Thread Koushik Das

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

Ship it!


Ship It!

- Koushik Das


On Jan. 8, 2014, 9:43 a.m., Harikrishna Patnala wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/16732/
> ---
> 
> (Updated Jan. 8, 2014, 9:43 a.m.)
> 
> 
> Review request for cloudstack and Koushik Das.
> 
> 
> Bugs: CLOUDSTACK-5827
> https://issues.apache.org/jira/browse/CLOUDSTACK-5827
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> CLOUDSTACK-5827: [Automation] Destroy VM failed, while deleting account
> 
> VMInstanceVO needs to be updated after advancestop.
> 
> 
> Diffs
> -
> 
>   engine/orchestration/src/com/cloud/vm/VirtualMachineManagerImpl.java 
> f959b93 
> 
> Diff: https://reviews.apache.org/r/16732/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Harikrishna Patnala
> 
>



Review Request 16737: CLOUDSTACK-5619: Egress Firewall rules - Increased timeout for router to come up

2014-01-08 Thread Ashutosh Kelkar

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

Review request for cloudstack and Girish Shilamkar.


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


Repository: cloudstack-git


Description
---

Many test cases failed due to "Router did not come up in specified time".
Increased time out to 720 seconds.


Diffs
-

  test/integration/component/test_egress_fw_rules.py 6c0bfd2 

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


Testing
---

Tested locally.

Log:
test_01_1_egress_fr1 (test_egress_fw_rules_fixed.TestEgressFWRules)
Test By-default the communication from guest n/w to public n/w is NOT allowed. 
... skipped 'Skip'
test_01_egress_fr1 (test_egress_fw_rules_fixed.TestEgressFWRules)
Test By-default the communication from guest n/w to public n/w is allowed. ... 
ok
test_02_1_egress_fr2 (test_egress_fw_rules_fixed.TestEgressFWRules)
Test Allow Communication using Egress rule with CIDR + Port Range + Protocol. 
... skipped 'Skip'
test_02_egress_fr2 (test_egress_fw_rules_fixed.TestEgressFWRules)
Test Allow Communication using Egress rule with CIDR + Port Range + Protocol. 
... skipped 'Skip'
test_03_1_egress_fr3 (test_egress_fw_rules_fixed.TestEgressFWRules)
Test Communication blocked with network that is other than specified ... 
skipped 'Skip'
test_03_egress_fr3 (test_egress_fw_rules_fixed.TestEgressFWRules)
Test Communication blocked with network that is other than specified ... 
skipped 'Skip'
test_04_1_egress_fr4 (test_egress_fw_rules_fixed.TestEgressFWRules)
Test Create Egress rule and check the Firewall_Rules DB table ... skipped 'Skip'
test_04_egress_fr4 (test_egress_fw_rules_fixed.TestEgressFWRules)
Test Create Egress rule and check the Firewall_Rules DB table ... skipped 'Skip'
test_05_1_egress_fr5 (test_egress_fw_rules_fixed.TestEgressFWRules)
Test Create Egress rule and check the IP tables ... skipped 'Skip'
test_05_egress_fr5 (test_egress_fw_rules_fixed.TestEgressFWRules)
Test Create Egress rule and check the IP tables ... skipped 'Skip'
test_06_1_egress_fr6 (test_egress_fw_rules_fixed.TestEgressFWRules)
Test Create Egress rule without CIDR ... skipped 'Skip'
test_06_egress_fr6 (test_egress_fw_rules_fixed.TestEgressFWRules)
Test Create Egress rule without CIDR ... skipped 'Skip'
test_07_1_egress_fr7 (test_egress_fw_rules_fixed.TestEgressFWRules)
Test Create Egress rule without End Port ... skipped 'Skip'
test_07_egress_fr7 (test_egress_fw_rules_fixed.TestEgressFWRules)
Test Create Egress rule without End Port ... skipped 'Skip'
test_08_1_egress_fr8 (test_egress_fw_rules_fixed.TestEgressFWRules)
Test Port Forwarding and Egress Conflict ... skipped 'Skip'
test_08_egress_fr8 (test_egress_fw_rules_fixed.TestEgressFWRules)
Test Port Forwarding and Egress Conflict ... skipped 'Skip'
test_09_1_egress_fr9 (test_egress_fw_rules_fixed.TestEgressFWRules)
Test Delete Egress rule ... skipped 'Skip'
test_09_egress_fr9 (test_egress_fw_rules_fixed.TestEgressFWRules)
Test Delete Egress rule ... skipped 'Skip'
test_10_1_egress_fr10 (test_egress_fw_rules_fixed.TestEgressFWRules)
Test Invalid CIDR and Invalid Port ranges ... skipped 'Skip'
test_10_egress_fr10 (test_egress_fw_rules_fixed.TestEgressFWRules)
Test Invalid CIDR and Invalid Port ranges ... skipped 'Skip'
test_11_1_egress_fr11 (test_egress_fw_rules_fixed.TestEgressFWRules)
Test Regression on Firewall + PF + LB + SNAT ... skipped 'Skip'
test_11_egress_fr11 (test_egress_fw_rules_fixed.TestEgressFWRules)
Test Regression on Firewall + PF + LB + SNAT ... skipped 'Skip'
test_12_1_egress_fr12 (test_egress_fw_rules_fixed.TestEgressFWRules)
Test Reboot Router ... skipped 'Skip'
test_12_egress_fr12 (test_egress_fw_rules_fixed.TestEgressFWRules)
Test Reboot Router ... skipped 'Skip'
test_13_1_egress_fr13 (test_egress_fw_rules_fixed.TestEgressFWRules)
Test Redundant Router : Master failover ... skipped 'Skip'
test_13_egress_fr13 (test_egress_fw_rules_fixed.TestEgressFWRules)
Test Redundant Router : Master failover ... skipped 'Skip'

--
Ran 26 tests in 646.486s

OK (skipped=25)


Thanks,

Ashutosh Kelkar



Re: Review Request 16730: Add usage event detials for vm state transitions when using custom compute offering.

2014-01-08 Thread Kishan Kavala

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

Ship it!


55a9b5d2a2dae4883d52506c6f6a2d5dac4c91cd

- Kishan Kavala


On Jan. 8, 2014, 11:20 a.m., bharat kumar wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/16730/
> ---
> 
> (Updated Jan. 8, 2014, 11:20 a.m.)
> 
> 
> Review request for cloudstack and Kishan Kavala.
> 
> 
> Bugs: CLOUDSTACK-5742
> https://issues.apache.org/jira/browse/CLOUDSTACK-5742
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> https://issues.apache.org/jira/browse/CLOUDSTACK-5742
> Add usage event detials for vm state transitions when using custom compute 
> offering.
> 
> 
> Diffs
> -
> 
>   server/src/com/cloud/vm/UserVmManagerImpl.java 23df880 
>   server/src/com/cloud/vm/UserVmStateListener.java 6c0c5e9 
> 
> Diff: https://reviews.apache.org/r/16730/diff/
> 
> 
> Testing
> ---
> 
> tested on 4.3
> 
> 
> Thanks,
> 
> bharat kumar
> 
>



Re: Review Request 16737: CLOUDSTACK-5619: Egress Firewall rules - Increased timeout for router to come up

2014-01-08 Thread ASF Subversion and Git Services

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


Commit 3d9a6ecbcd6ff6f9c87f51dc37762936f3777086 in branch refs/heads/4.3 from 
Ashutosh K
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=3d9a6ec ]

CLOUDSTACK-5619: Egress Firewall rules - Increased timeout for router to come up


- ASF Subversion and Git Services


On Jan. 8, 2014, 1:41 p.m., Ashutosh Kelkar wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/16737/
> ---
> 
> (Updated Jan. 8, 2014, 1:41 p.m.)
> 
> 
> Review request for cloudstack and Girish Shilamkar.
> 
> 
> Bugs: CLOUDSTACK-5619
> https://issues.apache.org/jira/browse/CLOUDSTACK-5619
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Many test cases failed due to "Router did not come up in specified time".
> Increased time out to 720 seconds.
> 
> 
> Diffs
> -
> 
>   test/integration/component/test_egress_fw_rules.py 6c0bfd2 
> 
> Diff: https://reviews.apache.org/r/16737/diff/
> 
> 
> Testing
> ---
> 
> Tested locally.
> 
> Log:
> test_01_1_egress_fr1 (test_egress_fw_rules_fixed.TestEgressFWRules)
> Test By-default the communication from guest n/w to public n/w is NOT 
> allowed. ... skipped 'Skip'
> test_01_egress_fr1 (test_egress_fw_rules_fixed.TestEgressFWRules)
> Test By-default the communication from guest n/w to public n/w is allowed. 
> ... ok
> test_02_1_egress_fr2 (test_egress_fw_rules_fixed.TestEgressFWRules)
> Test Allow Communication using Egress rule with CIDR + Port Range + Protocol. 
> ... skipped 'Skip'
> test_02_egress_fr2 (test_egress_fw_rules_fixed.TestEgressFWRules)
> Test Allow Communication using Egress rule with CIDR + Port Range + Protocol. 
> ... skipped 'Skip'
> test_03_1_egress_fr3 (test_egress_fw_rules_fixed.TestEgressFWRules)
> Test Communication blocked with network that is other than specified ... 
> skipped 'Skip'
> test_03_egress_fr3 (test_egress_fw_rules_fixed.TestEgressFWRules)
> Test Communication blocked with network that is other than specified ... 
> skipped 'Skip'
> test_04_1_egress_fr4 (test_egress_fw_rules_fixed.TestEgressFWRules)
> Test Create Egress rule and check the Firewall_Rules DB table ... skipped 
> 'Skip'
> test_04_egress_fr4 (test_egress_fw_rules_fixed.TestEgressFWRules)
> Test Create Egress rule and check the Firewall_Rules DB table ... skipped 
> 'Skip'
> test_05_1_egress_fr5 (test_egress_fw_rules_fixed.TestEgressFWRules)
> Test Create Egress rule and check the IP tables ... skipped 'Skip'
> test_05_egress_fr5 (test_egress_fw_rules_fixed.TestEgressFWRules)
> Test Create Egress rule and check the IP tables ... skipped 'Skip'
> test_06_1_egress_fr6 (test_egress_fw_rules_fixed.TestEgressFWRules)
> Test Create Egress rule without CIDR ... skipped 'Skip'
> test_06_egress_fr6 (test_egress_fw_rules_fixed.TestEgressFWRules)
> Test Create Egress rule without CIDR ... skipped 'Skip'
> test_07_1_egress_fr7 (test_egress_fw_rules_fixed.TestEgressFWRules)
> Test Create Egress rule without End Port ... skipped 'Skip'
> test_07_egress_fr7 (test_egress_fw_rules_fixed.TestEgressFWRules)
> Test Create Egress rule without End Port ... skipped 'Skip'
> test_08_1_egress_fr8 (test_egress_fw_rules_fixed.TestEgressFWRules)
> Test Port Forwarding and Egress Conflict ... skipped 'Skip'
> test_08_egress_fr8 (test_egress_fw_rules_fixed.TestEgressFWRules)
> Test Port Forwarding and Egress Conflict ... skipped 'Skip'
> test_09_1_egress_fr9 (test_egress_fw_rules_fixed.TestEgressFWRules)
> Test Delete Egress rule ... skipped 'Skip'
> test_09_egress_fr9 (test_egress_fw_rules_fixed.TestEgressFWRules)
> Test Delete Egress rule ... skipped 'Skip'
> test_10_1_egress_fr10 (test_egress_fw_rules_fixed.TestEgressFWRules)
> Test Invalid CIDR and Invalid Port ranges ... skipped 'Skip'
> test_10_egress_fr10 (test_egress_fw_rules_fixed.TestEgressFWRules)
> Test Invalid CIDR and Invalid Port ranges ... skipped 'Skip'
> test_11_1_egress_fr11 (test_egress_fw_rules_fixed.TestEgressFWRules)
> Test Regression on Firewall + PF + LB + SNAT ... skipped 'Skip'
> test_11_egress_fr11 (test_egress_fw_rules_fixed.TestEgressFWRules)
> Test Regression on Firewall + PF + LB + SNAT ... skipped 'Skip'
> test_12_1_egress_fr12 (test_egress_fw_rules_fixed.TestEgressFWRules)
> Test Reboot Router ... skipped 'Skip'
> test_12_egress_fr12 (test_egress_fw_rules_fixed.TestEgressFWRules)
> Test Reboot Router ... skipped 'Skip'
> test_13_1_egress_fr13 (test_egress_fw_rules_fixed.TestEgressFWRules)
> Test Redundant Router : Master failover ... skipped 'Skip'
> test_13_egress_fr13 (test_egress_fw_rules_fixed.TestEgressFWRules)
> Test Redundant Router : Master failover ... skipped 'Skip'
> 
> --

Re: Review Request 16737: CLOUDSTACK-5619: Egress Firewall rules - Increased timeout for router to come up

2014-01-08 Thread ASF Subversion and Git Services

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


Commit e58c3c809d4063e46e5e1c1f594763e2488bec30 in branch refs/heads/master 
from Ashutosh K
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=e58c3c8 ]

CLOUDSTACK-5619: Egress Firewall rules - Increased timeout for router to come up


- ASF Subversion and Git Services


On Jan. 8, 2014, 1:41 p.m., Ashutosh Kelkar wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/16737/
> ---
> 
> (Updated Jan. 8, 2014, 1:41 p.m.)
> 
> 
> Review request for cloudstack and Girish Shilamkar.
> 
> 
> Bugs: CLOUDSTACK-5619
> https://issues.apache.org/jira/browse/CLOUDSTACK-5619
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Many test cases failed due to "Router did not come up in specified time".
> Increased time out to 720 seconds.
> 
> 
> Diffs
> -
> 
>   test/integration/component/test_egress_fw_rules.py 6c0bfd2 
> 
> Diff: https://reviews.apache.org/r/16737/diff/
> 
> 
> Testing
> ---
> 
> Tested locally.
> 
> Log:
> test_01_1_egress_fr1 (test_egress_fw_rules_fixed.TestEgressFWRules)
> Test By-default the communication from guest n/w to public n/w is NOT 
> allowed. ... skipped 'Skip'
> test_01_egress_fr1 (test_egress_fw_rules_fixed.TestEgressFWRules)
> Test By-default the communication from guest n/w to public n/w is allowed. 
> ... ok
> test_02_1_egress_fr2 (test_egress_fw_rules_fixed.TestEgressFWRules)
> Test Allow Communication using Egress rule with CIDR + Port Range + Protocol. 
> ... skipped 'Skip'
> test_02_egress_fr2 (test_egress_fw_rules_fixed.TestEgressFWRules)
> Test Allow Communication using Egress rule with CIDR + Port Range + Protocol. 
> ... skipped 'Skip'
> test_03_1_egress_fr3 (test_egress_fw_rules_fixed.TestEgressFWRules)
> Test Communication blocked with network that is other than specified ... 
> skipped 'Skip'
> test_03_egress_fr3 (test_egress_fw_rules_fixed.TestEgressFWRules)
> Test Communication blocked with network that is other than specified ... 
> skipped 'Skip'
> test_04_1_egress_fr4 (test_egress_fw_rules_fixed.TestEgressFWRules)
> Test Create Egress rule and check the Firewall_Rules DB table ... skipped 
> 'Skip'
> test_04_egress_fr4 (test_egress_fw_rules_fixed.TestEgressFWRules)
> Test Create Egress rule and check the Firewall_Rules DB table ... skipped 
> 'Skip'
> test_05_1_egress_fr5 (test_egress_fw_rules_fixed.TestEgressFWRules)
> Test Create Egress rule and check the IP tables ... skipped 'Skip'
> test_05_egress_fr5 (test_egress_fw_rules_fixed.TestEgressFWRules)
> Test Create Egress rule and check the IP tables ... skipped 'Skip'
> test_06_1_egress_fr6 (test_egress_fw_rules_fixed.TestEgressFWRules)
> Test Create Egress rule without CIDR ... skipped 'Skip'
> test_06_egress_fr6 (test_egress_fw_rules_fixed.TestEgressFWRules)
> Test Create Egress rule without CIDR ... skipped 'Skip'
> test_07_1_egress_fr7 (test_egress_fw_rules_fixed.TestEgressFWRules)
> Test Create Egress rule without End Port ... skipped 'Skip'
> test_07_egress_fr7 (test_egress_fw_rules_fixed.TestEgressFWRules)
> Test Create Egress rule without End Port ... skipped 'Skip'
> test_08_1_egress_fr8 (test_egress_fw_rules_fixed.TestEgressFWRules)
> Test Port Forwarding and Egress Conflict ... skipped 'Skip'
> test_08_egress_fr8 (test_egress_fw_rules_fixed.TestEgressFWRules)
> Test Port Forwarding and Egress Conflict ... skipped 'Skip'
> test_09_1_egress_fr9 (test_egress_fw_rules_fixed.TestEgressFWRules)
> Test Delete Egress rule ... skipped 'Skip'
> test_09_egress_fr9 (test_egress_fw_rules_fixed.TestEgressFWRules)
> Test Delete Egress rule ... skipped 'Skip'
> test_10_1_egress_fr10 (test_egress_fw_rules_fixed.TestEgressFWRules)
> Test Invalid CIDR and Invalid Port ranges ... skipped 'Skip'
> test_10_egress_fr10 (test_egress_fw_rules_fixed.TestEgressFWRules)
> Test Invalid CIDR and Invalid Port ranges ... skipped 'Skip'
> test_11_1_egress_fr11 (test_egress_fw_rules_fixed.TestEgressFWRules)
> Test Regression on Firewall + PF + LB + SNAT ... skipped 'Skip'
> test_11_egress_fr11 (test_egress_fw_rules_fixed.TestEgressFWRules)
> Test Regression on Firewall + PF + LB + SNAT ... skipped 'Skip'
> test_12_1_egress_fr12 (test_egress_fw_rules_fixed.TestEgressFWRules)
> Test Reboot Router ... skipped 'Skip'
> test_12_egress_fr12 (test_egress_fw_rules_fixed.TestEgressFWRules)
> Test Reboot Router ... skipped 'Skip'
> test_13_1_egress_fr13 (test_egress_fw_rules_fixed.TestEgressFWRules)
> Test Redundant Router : Master failover ... skipped 'Skip'
> test_13_egress_fr13 (test_egress_fw_rules_fixed.TestEgressFWRules)
> Test Redundant Router : Master failover ... skipped 'Skip'
> 
> ---

Re: Review Request 16737: CLOUDSTACK-5619: Egress Firewall rules - Increased timeout for router to come up

2014-01-08 Thread Girish Shilamkar

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

Ship it!


Committed to 4.3 and master

- Girish Shilamkar


On Jan. 8, 2014, 1:41 p.m., Ashutosh Kelkar wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/16737/
> ---
> 
> (Updated Jan. 8, 2014, 1:41 p.m.)
> 
> 
> Review request for cloudstack and Girish Shilamkar.
> 
> 
> Bugs: CLOUDSTACK-5619
> https://issues.apache.org/jira/browse/CLOUDSTACK-5619
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Many test cases failed due to "Router did not come up in specified time".
> Increased time out to 720 seconds.
> 
> 
> Diffs
> -
> 
>   test/integration/component/test_egress_fw_rules.py 6c0bfd2 
> 
> Diff: https://reviews.apache.org/r/16737/diff/
> 
> 
> Testing
> ---
> 
> Tested locally.
> 
> Log:
> test_01_1_egress_fr1 (test_egress_fw_rules_fixed.TestEgressFWRules)
> Test By-default the communication from guest n/w to public n/w is NOT 
> allowed. ... skipped 'Skip'
> test_01_egress_fr1 (test_egress_fw_rules_fixed.TestEgressFWRules)
> Test By-default the communication from guest n/w to public n/w is allowed. 
> ... ok
> test_02_1_egress_fr2 (test_egress_fw_rules_fixed.TestEgressFWRules)
> Test Allow Communication using Egress rule with CIDR + Port Range + Protocol. 
> ... skipped 'Skip'
> test_02_egress_fr2 (test_egress_fw_rules_fixed.TestEgressFWRules)
> Test Allow Communication using Egress rule with CIDR + Port Range + Protocol. 
> ... skipped 'Skip'
> test_03_1_egress_fr3 (test_egress_fw_rules_fixed.TestEgressFWRules)
> Test Communication blocked with network that is other than specified ... 
> skipped 'Skip'
> test_03_egress_fr3 (test_egress_fw_rules_fixed.TestEgressFWRules)
> Test Communication blocked with network that is other than specified ... 
> skipped 'Skip'
> test_04_1_egress_fr4 (test_egress_fw_rules_fixed.TestEgressFWRules)
> Test Create Egress rule and check the Firewall_Rules DB table ... skipped 
> 'Skip'
> test_04_egress_fr4 (test_egress_fw_rules_fixed.TestEgressFWRules)
> Test Create Egress rule and check the Firewall_Rules DB table ... skipped 
> 'Skip'
> test_05_1_egress_fr5 (test_egress_fw_rules_fixed.TestEgressFWRules)
> Test Create Egress rule and check the IP tables ... skipped 'Skip'
> test_05_egress_fr5 (test_egress_fw_rules_fixed.TestEgressFWRules)
> Test Create Egress rule and check the IP tables ... skipped 'Skip'
> test_06_1_egress_fr6 (test_egress_fw_rules_fixed.TestEgressFWRules)
> Test Create Egress rule without CIDR ... skipped 'Skip'
> test_06_egress_fr6 (test_egress_fw_rules_fixed.TestEgressFWRules)
> Test Create Egress rule without CIDR ... skipped 'Skip'
> test_07_1_egress_fr7 (test_egress_fw_rules_fixed.TestEgressFWRules)
> Test Create Egress rule without End Port ... skipped 'Skip'
> test_07_egress_fr7 (test_egress_fw_rules_fixed.TestEgressFWRules)
> Test Create Egress rule without End Port ... skipped 'Skip'
> test_08_1_egress_fr8 (test_egress_fw_rules_fixed.TestEgressFWRules)
> Test Port Forwarding and Egress Conflict ... skipped 'Skip'
> test_08_egress_fr8 (test_egress_fw_rules_fixed.TestEgressFWRules)
> Test Port Forwarding and Egress Conflict ... skipped 'Skip'
> test_09_1_egress_fr9 (test_egress_fw_rules_fixed.TestEgressFWRules)
> Test Delete Egress rule ... skipped 'Skip'
> test_09_egress_fr9 (test_egress_fw_rules_fixed.TestEgressFWRules)
> Test Delete Egress rule ... skipped 'Skip'
> test_10_1_egress_fr10 (test_egress_fw_rules_fixed.TestEgressFWRules)
> Test Invalid CIDR and Invalid Port ranges ... skipped 'Skip'
> test_10_egress_fr10 (test_egress_fw_rules_fixed.TestEgressFWRules)
> Test Invalid CIDR and Invalid Port ranges ... skipped 'Skip'
> test_11_1_egress_fr11 (test_egress_fw_rules_fixed.TestEgressFWRules)
> Test Regression on Firewall + PF + LB + SNAT ... skipped 'Skip'
> test_11_egress_fr11 (test_egress_fw_rules_fixed.TestEgressFWRules)
> Test Regression on Firewall + PF + LB + SNAT ... skipped 'Skip'
> test_12_1_egress_fr12 (test_egress_fw_rules_fixed.TestEgressFWRules)
> Test Reboot Router ... skipped 'Skip'
> test_12_egress_fr12 (test_egress_fw_rules_fixed.TestEgressFWRules)
> Test Reboot Router ... skipped 'Skip'
> test_13_1_egress_fr13 (test_egress_fw_rules_fixed.TestEgressFWRules)
> Test Redundant Router : Master failover ... skipped 'Skip'
> test_13_egress_fr13 (test_egress_fw_rules_fixed.TestEgressFWRules)
> Test Redundant Router : Master failover ... skipped 'Skip'
> 
> --
> Ran 26 tests in 646.486s
> 
> OK (skipped=25)
> 
> 
> Thanks,
> 
> Ashutosh Kelkar
> 
>



DR as a service in CloudPlatform?

2014-01-08 Thread Octavian Popescu
Hello,

Could you please confirm if any DR specific features are being developed for 
CloudStack/CloudPlatform? (e.g. DR tags that indicate whether a machine should 
be moved between zones in case of a failure) If positive, could you please 
share some details about how exactly it will work?

Thanks,
Octavian





FW: Unicode Characters in Input Fields

2014-01-08 Thread Alex Hitchins
All,

Further to the below, I've done some digging around and have located the 
following change : 
http://permalink.gmane.org/gmane.comp.apache.cloudstack.devel/7621

It looks like the validation was created to prevent non-printable characters 
from being entered. A regex was used to match the undesirable characters. This 
was included in 4.1 (note that 3.x does not have this issue).

My regular expression knowledge could do with improving. Could someone verify 
that the pattern [\000-\037\177] will match on characters such as ü as well as 
the ASCII non-printable characters are numbers 0 to 31 and 127 decimal.

If so, I can refine the validation to allow unicode yet exclude 0, 31 & 127.



Alex Hitchins
+44 7788 423 969

-Original Message-
From: Alex Hitchins [mailto:alex.hitch...@shapeblue.com]
Sent: 08 January 2014 11:31
To: dev@cloudstack.apache.org
Subject: Unicode Characters in Input Fields

Hi all,

I've run in to a bug regarding entering Unicode characters in input fields, 
namely the new user form.

My issue is that you can create new users in CPBM with Unicode characters in 
the name - such as ü however this causes a problem in CloudStack as they aren't 
supported.

I can see the line of code where the validation occurs - my question is - is 
this be design or is this an issue? I'm guessing Japanese and German users can 
enter in Unicode characters, especially for the users names.




Regards,

Alex Hitchins

Need Enterprise Grade Support for Apache CloudStack?
Our CloudStack Infrastructure 
Support offers the 
best 24/7 SLA for CloudStack Environments.

Apache CloudStack Bootcamp training courses

**NEW!** CloudStack 4.2 training
08/09 January 2014, London
13-17 January 2014, GLOBAL. Instructor led, 
On-line
20-24 January 2014, GLOBAL. Instructor led, 
On-line

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 16385: Fix for CloudStack JIRA 4406

2014-01-08 Thread daan Hoogland


> On Dec. 23, 2013, 5:58 p.m., Nitin Mehta wrote:
> > api/src/org/apache/cloudstack/api/BaseListTemplateOrIsoPermissionsCmd.java, 
> > line 53
> > 
> >
> > You shouldn't have to override for every cmd. By default its false and 
> > the cmds having sensitive information can have methods returning true. Also 
> > they do not need to be set in execute. This is static information, doesn't 
> > change per command so why this needs to be set ?
> 
> Mandar Barve wrote:
> Nitin,
> You are right. This was discussed in the earlier discussion thread. 
> You should really have to modify only commands that carry sensitive 
> information. The problem with that approach as stated earlier is API 
> developer can forget to declare command/response sensitivity by implementing 
> a method that sets the flags, returns true etc. The wrapper abstract method 
> was introduced essentially to ensure new APIs as they get introduced will 
> give compiler error if this wrapper is not implemented enforcing the 
> developer to declare such sensitivity upfront.
> Hope that addresses your concern.
> 
> Thanks,
> Mandar
> 
> Nitin Mehta wrote:
> Thanks Mandar. I see your point and was thinking on the same lines as 
> well. I appreciate your thinking for future API devs. But I have the 
> following concerns
> 1. I probably think that this information should be static for the Cmd 
> class and doesnt have to be set on every execute invocation
> 2. For few commands having sensitive information we are writing 
> boilerplate code in all the api's, this is not en elegant way of enforcing 
> every API developer to look into this. I would rather want this to be dealt 
> through an annotation (if it doesnt exist lets create one in the public 
> @interface APICommand and keep the default value to true that it contains 
> sensitive information)
> 
> Mandar Barve wrote:
> Nitin,
>  I see us going back to PROPOSAL discussion which is fine but IMO its 
> happening little late. 
> 
>  I am new to this process of development in CloudStack and would want 
> to take this opportunity to understand how this thing works. As I understood 
> it I tried to:
> - reproduce and understand the issue, come up with a solution, 
> - ran a PoC making sure the proposed solution will work, will scale etc. 
> - Put down a proposal providing multiple solution approaches discussing 
> pros/cons and shared with the team inviting comments. 
> - Addressed all the concerns related to the proposal until I saw no more 
> concerns raised over this.
> - went through an entire exercise of manually changing each command file 
> carefully going through API doc with the proposed change.
>  
>   I truly appreciate all the comments and also understand sometimes 
> important things may need to be addressed even if they are late. Is there any 
> norm in the community to close a "PROPOSAL/DISCUSS" phase? Are we supposed to 
> get "VOTE" on the proposed solution before moving to implementation? This 
> didn't look like the case for every discussion from my reading of wiki.
> 
>  Now coming to your comments on the PROPOSAL. You are suggesting 
> making declarative changes (static)to API Commands e.g. to APICommand 
> annotation or a new annotation. Something like this can surely make the 
> change look more elegant in the sense the change itself will potentially be 
> limited to one/two lines per file (ensuring all annotations for all commands 
> are changed to the new one) and won't need a call from execute. The checking 
> code will need to load the annotation to check the flag status in the 
> annotation meaning a reflective code. Daan had earlier proposed using 
> reflection with string match but also had raised security concerns over using 
> reflection. Leaving that aside, to ensure every API does its job of declaring 
> sensitivity upfront we should really be able to enforce it at compile time 
> like mentioned before. I don't see a way to enforce annotation implementation 
> by all sub classes at compile time. IF such method doesn't exist then we will 
> be leaving use of this a
 nnotation to the mercy of the API developer who can forget to do so. In such 
case your default true values can come into play but then essentially losing 
the whole purpose where a command that is not sensitive will still need to go 
through a cleanString call.
> 
> Assuming we apply this annotation to all known API commands to date 
> close to 437 files will need to change and that is truly a boiler plate 
> change. If we rely on using default "false" e.g. and modify only sensitive 
> classes then also it can come to around 50 files or little more I believe 
> with a hole left open where newly added commands can go without annotation 
> with unintended results as mentioned above.
> 
>  In my solution the a

Re: Unicode Characters in Input Fields

2014-01-08 Thread sebgoa

On Jan 8, 2014, at 3:16 PM, Alex Hitchins  wrote:

> All,
> 
> Further to the below, I've done some digging around and have located the 
> following change : 
> http://permalink.gmane.org/gmane.comp.apache.cloudstack.devel/7621
> 
> It looks like the validation was created to prevent non-printable characters 
> from being entered. A regex was used to match the undesirable characters. 
> This was included in 4.1 (note that 3.x does not have this issue).
> 
> My regular expression knowledge could do with improving. Could someone verify 
> that the pattern [\000-\037\177] will match on characters such as ü as well 
> as the ASCII non-printable characters are numbers 0 to 31 and 127 decimal.
> 
> If so, I can refine the validation to allow unicode yet exclude 0, 31 & 127.
> 

Alex, is there a bug for this in JIRA ?

If yes, you can submit a patch via review board and describe the tests you did 
to make sure this does not break anything .

-sebastien


> 
> 
> Alex Hitchins
> +44 7788 423 969
> 
> -Original Message-
> From: Alex Hitchins [mailto:alex.hitch...@shapeblue.com]
> Sent: 08 January 2014 11:31
> To: dev@cloudstack.apache.org
> Subject: Unicode Characters in Input Fields
> 
> Hi all,
> 
> I've run in to a bug regarding entering Unicode characters in input fields, 
> namely the new user form.
> 
> My issue is that you can create new users in CPBM with Unicode characters in 
> the name - such as ü however this causes a problem in CloudStack as they 
> aren't supported.
> 
> I can see the line of code where the validation occurs - my question is - is 
> this be design or is this an issue? I'm guessing Japanese and German users 
> can enter in Unicode characters, especially for the users names.
> 
> 
> 
> 
> Regards,
> 
> Alex Hitchins
> 
> Need Enterprise Grade Support for Apache CloudStack?
> Our CloudStack Infrastructure 
> Support offers the 
> best 24/7 SLA for CloudStack Environments.
> 
> Apache CloudStack Bootcamp training courses
> 
> **NEW!** CloudStack 4.2 training
> 08/09 January 2014, London
> 13-17 January 2014, GLOBAL. Instructor led, 
> On-line
> 20-24 January 2014, GLOBAL. Instructor led, 
> On-line
> 
> 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: Unicode Characters in Input Fields

2014-01-08 Thread Alex Hitchins
Yes - Sorry there is a related bug :

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

and a linked issue :

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

I will work on the patch and submit with tests.



Alex Hitchins
+44 7788 423 969

-Original Message-
From: sebgoa [mailto:run...@gmail.com]
Sent: 08 January 2014 15:09
To: dev@cloudstack.apache.org
Subject: Re: Unicode Characters in Input Fields


On Jan 8, 2014, at 3:16 PM, Alex Hitchins  wrote:

> All,
>
> Further to the below, I've done some digging around and have located the 
> following change : 
> http://permalink.gmane.org/gmane.comp.apache.cloudstack.devel/7621
>
> It looks like the validation was created to prevent non-printable characters 
> from being entered. A regex was used to match the undesirable characters. 
> This was included in 4.1 (note that 3.x does not have this issue).
>
> My regular expression knowledge could do with improving. Could someone verify 
> that the pattern [\000-\037\177] will match on characters such as ü as well 
> as the ASCII non-printable characters are numbers 0 to 31 and 127 decimal.
>
> If so, I can refine the validation to allow unicode yet exclude 0, 31 & 127.
>

Alex, is there a bug for this in JIRA ?

If yes, you can submit a patch via review board and describe the tests you did 
to make sure this does not break anything .

-sebastien


>
>
> Alex Hitchins
> +44 7788 423 969
>
> -Original Message-
> From: Alex Hitchins [mailto:alex.hitch...@shapeblue.com]
> Sent: 08 January 2014 11:31
> To: dev@cloudstack.apache.org
> Subject: Unicode Characters in Input Fields
>
> Hi all,
>
> I've run in to a bug regarding entering Unicode characters in input fields, 
> namely the new user form.
>
> My issue is that you can create new users in CPBM with Unicode characters in 
> the name - such as ü however this causes a problem in CloudStack as they 
> aren't supported.
>
> I can see the line of code where the validation occurs - my question is - is 
> this be design or is this an issue? I'm guessing Japanese and German users 
> can enter in Unicode characters, especially for the users names.
>
>
>
>
> Regards,
>
> Alex Hitchins
>
> Need Enterprise Grade Support for Apache CloudStack?
> Our CloudStack Infrastructure 
> Support offers the 
> best 24/7 SLA for CloudStack Environments.
>
> Apache CloudStack Bootcamp training courses
>
> **NEW!** CloudStack 4.2 training
> 08/09 January 2014, London
> 13-17 January 2014, GLOBAL. Instructor led, 
> On-line
> 20-24 January 2014, GLOBAL. Instructor led, 
> On-line
>
> 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.

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 

RE: DR as a service in CloudPlatform?

2014-01-08 Thread Giles Sirett
Hi Octavian

The closest thing in CloudStack that I know of is probably GSLB - but it won't 
start individual VMs up in a different zone but transfer the traffic to a 
different zone if 'primary' zone fails

https://cwiki.apache.org/confluence/display/CLOUDSTACK/GSLB+%28Global+Server+Load+Balancing%29+Functional+specification+and+Design+Document


WRT Citrix Cloudplaform : this isn't really the right place to ask about the 
Citrix roadmap. You should ask your Citrix rep that


Kind Regards
Giles

D: +44 20 3603 0541 | M: +44 796 111 2055
giles.sir...@shapeblue.com




-Original Message-
From: Octavian Popescu [mailto:octavian.pope...@interoute.com]
Sent: 08 January 2014 14:13
To: dev@cloudstack.apache.org
Subject: DR as a service in CloudPlatform?

Hello,

Could you please confirm if any DR specific features are being developed for 
CloudStack/CloudPlatform? (e.g. DR tags that indicate whether a machine should 
be moved between zones in case of a failure) If positive, could you please 
share some details about how exactly it will work?

Thanks,
Octavian



Need Enterprise Grade Support for Apache CloudStack?
Our CloudStack Infrastructure 
Support offers the 
best 24/7 SLA for CloudStack Environments.

Apache CloudStack Bootcamp training courses

**NEW!** CloudStack 4.2 training
08/09 January 2014, London
13-17 January 2014, GLOBAL. Instructor led, 
On-line
20-24 January 2014, GLOBAL. Instructor led, 
On-line

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: DR as a service in CloudPlatform?

2014-01-08 Thread Octavian Popescu
Thanks Giles - I've always thought the two development roadmaps are somewhat 
aligned (at least roughly), hence my question about CP as well.

Octavian

>-Original Message-
>From: Giles Sirett [mailto:giles.sir...@shapeblue.com]
>Sent: 08 January 2014 16:42
>To: dev@cloudstack.apache.org
>Subject: RE: DR as a service in CloudPlatform?
>
>Hi Octavian
>
>The closest thing in CloudStack that I know of is probably GSLB - but it won't
>start individual VMs up in a different zone but transfer the traffic to a
>different zone if 'primary' zone fails
>
>https://cwiki.apache.org/confluence/display/CLOUDSTACK/GSLB+%28Global
>+Server+Load+Balancing%29+Functional+specification+and+Design+Docume
>nt
>
>
>WRT Citrix Cloudplaform : this isn't really the right place to ask about the 
>Citrix
>roadmap. You should ask your Citrix rep that
>
>
>Kind Regards
>Giles
>
>D: +44 20 3603 0541 | M: +44 796 111 2055 giles.sir...@shapeblue.com
>
>
>
>
>-Original Message-
>From: Octavian Popescu [mailto:octavian.pope...@interoute.com]
>Sent: 08 January 2014 14:13
>To: dev@cloudstack.apache.org
>Subject: DR as a service in CloudPlatform?
>
>Hello,
>
>Could you please confirm if any DR specific features are being developed for
>CloudStack/CloudPlatform? (e.g. DR tags that indicate whether a machine
>should be moved between zones in case of a failure) If positive, could you
>please share some details about how exactly it will work?
>
>Thanks,
>Octavian
>
>
>
>Need Enterprise Grade Support for Apache CloudStack?
>Our CloudStack Infrastructure Supportinfrastructure-support/> offers the best 24/7 SLA for CloudStack
>Environments.
>
>Apache CloudStack Bootcamp training courses
>
>**NEW!** CloudStack 4.2 trainingtraining/>
>08/09 January 2014, London
>13-17 January 2014, GLOBAL. Instructor led, On-
>line
>20-24 January 2014, GLOBAL. Instructor led, On-
>line
>
>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: [MERGE] Opendaylight plugin

2014-01-08 Thread Hugo Trippaers
Thanks for the feedback.

The support is merged into master:

612a41e3f5b7f57b205ea84503d670793fb44c4f Add UI interface for managing the 
OpenDaylight provider and controllers.
e4cb9ce8bcb0ffa8b3a4f82f0e32002e19f35085 Add opendaylight provider to system.js
57da2bc784f125f61af4020d8589c690b89f058a Apply two small fixes to system.js
0ba1abe2627bd05c64aabf25142b266837c6e044 Apply some formatting to system.js
8ddcc9ba808041fbf42fc45f478574502dcad256 Set unique gre key for every network.
f3f93a96f549203e00046bd681ddc87e174c2a6b Adding OpenDayLight Neutron API. It 
includes 24 unit tests and 3 integration tests. Everythin passed the build.
850bc9fa826393c5ab110bf49138b4d0e1c1c313 Hook the OpenDaylight plugin into 
CloudStack
1f9528bad3493f287bfd6dfc48dfd077697e7d1f Add a network plugin for OpenDaylight


Cheers,

Hugo

On 7 jan. 2014, at 17:21, Nguyen Anh Tu  wrote:

> +1 Hugo.
> 
> Looking forward if I can do anything for that plugin.
> 
> --Tuna
> 
> 
> On Mon, Jan 6, 2014 at 9:45 PM, sebgoa  wrote:
> 
>> 
>> On Jan 6, 2014, at 9:03 AM, Hugo Trippaers  wrote:
>> 
>>> Hey all,
>>> 
>>> I would like to merge the branch open daylight into master. This branch
>> contains a plugin with an interface to an OpenDaylight controller.
>>> 
>>> The current functionality is limited to creating layer 2 isolated
>> networks using overlay networking as supported by opendaylight. We are
>> using the OVSDB and OpenFlow modules in OpenDaylight to build overlay
>> networks using gre tunneling. Opendaylight does not have a release yet, so
>> the state of the plugin is more of a technology preview, but has been
>> tested with several KVM hypervisors and the latest build of the
>> OpenDaylight controller and the ovsdb subproject. The functionality is
>> enough to work as an equivalent to the existing GRE tunnel implementation
>> for KVM hypervisors.
>>> 
>>> Ideally this plugin should be the basic groundwork to start supporting
>> more functions/features available in OpenDaylight when they become
>> available. It allows interested parties to work with CloudStack and
>> OpenDaylight without having to work with a CS fork and keep rebasing a
>> separate branch.
>>> 
>>> 
>>> Cheers,
>>> 
>>> Hugo
>> 
>> I have not tested it, but saw the patches and I am +1
>> 
>> 



Re: [MERGE] Opendaylight plugin

2014-01-08 Thread Hugo Trippaers

On 7 jan. 2014, at 17:21, Nguyen Anh Tu  wrote:

> +1 Hugo.
> 
> Looking forward if I can do anything for that plugin.

Absolutely! There is more than enough work to do. Do you have a chance to setup 
a test environment and help testing? Ideally i would like to add openvswitch to 
devcloud and use ODL to control it, but thats a lot of work.

> 
> --Tuna
> 
> 
> On Mon, Jan 6, 2014 at 9:45 PM, sebgoa  wrote:
> 
>> 
>> On Jan 6, 2014, at 9:03 AM, Hugo Trippaers  wrote:
>> 
>>> Hey all,
>>> 
>>> I would like to merge the branch open daylight into master. This branch
>> contains a plugin with an interface to an OpenDaylight controller.
>>> 
>>> The current functionality is limited to creating layer 2 isolated
>> networks using overlay networking as supported by opendaylight. We are
>> using the OVSDB and OpenFlow modules in OpenDaylight to build overlay
>> networks using gre tunneling. Opendaylight does not have a release yet, so
>> the state of the plugin is more of a technology preview, but has been
>> tested with several KVM hypervisors and the latest build of the
>> OpenDaylight controller and the ovsdb subproject. The functionality is
>> enough to work as an equivalent to the existing GRE tunnel implementation
>> for KVM hypervisors.
>>> 
>>> Ideally this plugin should be the basic groundwork to start supporting
>> more functions/features available in OpenDaylight when they become
>> available. It allows interested parties to work with CloudStack and
>> OpenDaylight without having to work with a CS fork and keep rebasing a
>> separate branch.
>>> 
>>> 
>>> Cheers,
>>> 
>>> Hugo
>> 
>> I have not tested it, but saw the patches and I am +1
>> 
>> 



Re: Committer license for IntelliJ set to expire

2014-01-08 Thread Chip Childers
On Wed, Jan 08, 2014 at 02:05:29AM +, Sateesh Chodapuneedi wrote:
> I am also using it.
> 
> Regards,
> Sateesh

ACK


Re: Committer license for IntelliJ set to expire

2014-01-08 Thread Frankie Onuonga
I plan to start committing this year.
Do you think that I should wait to get this when I actually do or get it
right now ?


thanks and kind regards,



On Wed, Jan 8, 2014 at 6:41 PM, Chip Childers wrote:

> On Wed, Jan 08, 2014 at 02:05:29AM +, Sateesh Chodapuneedi wrote:
> > I am also using it.
> >
> > Regards,
> > Sateesh
>
> ACK
>



-- 
Skype: Frankie.Onuonga
twitter: Frankieonuonga
irc #freenode: Frankie.onuonga


Re: Wrong dates for network bytes sent/received usages

2014-01-08 Thread Olivier Lemasle
Hi,

Now that CloudStack 4.2.1 is released, could you please have a look to my
review request, in order to apply the patch to CLOUDSTACK-5404 in branch
4.3 and master?

Please let me know if you have concerns/questions about it.

Regards,

--
Olivier Lemasle
Apalia


On Wed, Dec 11, 2013 at 4:39 PM, Wei ZHOU  wrote:

> I will have a look.
>
>
> 2013/12/11 Olivier Lemasle 
>
> > Hi,
> >
> > There is currently a bug in network usages in CS 4.2+: usage records for
> > network bytes sent/received are saved in database in local time whereas
> all
> > other usage records are saved in GMT (see issue CLOUDSTACK-5404 [1]).
> >
> > I've written simple patches for branchs 4.2 / 4.3 and for master. Can
> > someone review them, please [2] ?
> >
> > Regards,
> >
> > [1] https://issues.apache.org/jira/browse/CLOUDSTACK-5404
> > [2] https://reviews.apache.org/r/16126/
> >
> > --
> > Olivier Lemasle
> > Software Engineer
> > *Apalia*™
> > Mobile: +33-611-69-12-11
> >
> > *http://www.apalia.net 
> > olivier.lema...@apalia.net
> > *
> >


RE: Unicode Characters in Input Fields

2014-01-08 Thread Santhosh Edukulla
Alex,

Few notes:

1.Regular Expression [^\x00-\x1F\x7F]  can be used as "not" to  allow 
characters in the range 0-31 and 127 i believe. Not clear of \177 in the below 
mentioned reg ex.

2. Also, i believe when we say unicode, we mean only extended ascii charcter 
set( excluding non printable range 0-31,127), but not complete unicode code 
points?  I believe this will as well effect  mysql db and other code areas in 
CS of storing and handling these values changes. Changing  encoding either to 
utf-8\other for that column and byte set to read and write to accommodate the 
range we are looking to handle?


Thanks!
Santhosh

From: Alex Hitchins [alex.hitch...@shapeblue.com]
Sent: Wednesday, January 08, 2014 10:31 AM
To: dev@cloudstack.apache.org
Subject: RE: Unicode Characters in Input Fields

Yes - Sorry there is a related bug :

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

and a linked issue :

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

I will work on the patch and submit with tests.



Alex Hitchins
+44 7788 423 969

-Original Message-
From: sebgoa [mailto:run...@gmail.com]
Sent: 08 January 2014 15:09
To: dev@cloudstack.apache.org
Subject: Re: Unicode Characters in Input Fields


On Jan 8, 2014, at 3:16 PM, Alex Hitchins  wrote:

> All,
>
> Further to the below, I've done some digging around and have located the 
> following change : 
> http://permalink.gmane.org/gmane.comp.apache.cloudstack.devel/7621
>
> It looks like the validation was created to prevent non-printable characters 
> from being entered. A regex was used to match the undesirable characters. 
> This was included in 4.1 (note that 3.x does not have this issue).
>
> My regular expression knowledge could do with improving. Could someone verify 
> that the pattern [\000-\037\177] will match on characters such as ü as well 
> as the ASCII non-printable characters are numbers 0 to 31 and 127 decimal.
>
> If so, I can refine the validation to allow unicode yet exclude 0, 31 & 127.
>

Alex, is there a bug for this in JIRA ?

If yes, you can submit a patch via review board and describe the tests you did 
to make sure this does not break anything .

-sebastien


>
>
> Alex Hitchins
> +44 7788 423 969
>
> -Original Message-
> From: Alex Hitchins [mailto:alex.hitch...@shapeblue.com]
> Sent: 08 January 2014 11:31
> To: dev@cloudstack.apache.org
> Subject: Unicode Characters in Input Fields
>
> Hi all,
>
> I've run in to a bug regarding entering Unicode characters in input fields, 
> namely the new user form.
>
> My issue is that you can create new users in CPBM with Unicode characters in 
> the name - such as ü however this causes a problem in CloudStack as they 
> aren't supported.
>
> I can see the line of code where the validation occurs - my question is - is 
> this be design or is this an issue? I'm guessing Japanese and German users 
> can enter in Unicode characters, especially for the users names.
>
>
>
>
> Regards,
>
> Alex Hitchins
>
> Need Enterprise Grade Support for Apache CloudStack?
> Our CloudStack Infrastructure 
> Support offers the 
> best 24/7 SLA for CloudStack Environments.
>
> Apache CloudStack Bootcamp training courses
>
> **NEW!** CloudStack 4.2 training
> 08/09 January 2014, London
> 13-17 January 2014, GLOBAL. Instructor led, 
> On-line
> 20-24 January 2014, GLOBAL. Instructor led, 
> On-line
>
> 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

RE: Hyper-V agent

2014-01-08 Thread Paul Angus
OK so

ipconfig /all returned:

Host Name:  WIN-G23HSIAIU40
And
Primary dns suffix: BLANK

I ran:

netdom computername hostname.domain.com /add:newhostname.newdomain.com
netdom computername hostname.domain.com /makeprimary:newhostname.newdomain.com

to set the dns suffix (then rebooted)

Agentshell.exe --install still failed,

I needed to uninstall the agent first

Agentshell.exe --uninstall
Then reinstall
Agentshell.exe --install

Et voila:
14-01-08 17:58:45,173 [1] DEBUG CloudStack.Plugin.AgentShell.Program [(null)] - 
CloudStack Hyper-V Agent arg is
2014-01-08 17:58:45,204 [1] INFO  CloudStack.Plugin.AgentShell.Program [(null)] 
- Installing and running CloudStack Hyper-V Agent
2014-01-08 17:58:45,220 [1] ERROR CloudStack.Plugin.AgentShell.Program [(null)] 
-  Error occured in starting service Cannot start service CloudStack Hyper-V 
Agent on computer '.'.
2014-01-08 17:58:51,637 [1] DEBUG CloudStack.Plugin.AgentShell.Program [(null)] 
- CloudStack Hyper-V Agent arg is
2014-01-08 17:58:51,683 [1] INFO  CloudStack.Plugin.AgentShell.Program [(null)] 
- Stopping and uninstalling CloudStack Hyper-V Agent
2014-01-08 17:58:53,621 [1] DEBUG CloudStack.Plugin.AgentShell.Program [(null)] 
- CloudStack Hyper-V Agent arg is
2014-01-08 17:58:53,652 [1] INFO  CloudStack.Plugin.AgentShell.Program [(null)] 
- Installing and running CloudStack Hyper-V Agent
2014-01-08 17:58:53,995 [1] INFO  CloudStack.Plugin.AgentShell.Program [(null)] 
- CloudStack Hyper-V Agent running as Windows Service
2014-01-08 17:58:54,042 [1] INFO  CloudStack.Plugin.AgentShell.AgentService 
[(null)] - Starting CloudStack agent
2014-01-08 17:58:54,292 [1] DEBUG CloudStack.Plugin.AgentShell.AgentService 
[(null)] - Controller HypervResourceController is available


Now to add it into cloudstack...


Regards,

Paul Angus
Cloud Architect
S: +44 20 3603 0540 | M: +447711418784 | T: @CloudyAngus
paul.an...@shapeblue.com

-Original Message-
From: Alex Hitchins [mailto:alex.hitch...@shapeblue.com]
Sent: 06 January 2014 09:02
To: dev@cloudstack.apache.org; Donal Lafferty; Anshul Gangwar
Subject: RE: Hyper-V agent

Just noticed in the error log that it's trying to start on computer '.' - while 
I know the . works in SQL Server etc, could it not be working here? Or have you 
set a custom hosts file?

--
Error occured in starting service Cannot start service CloudStack Hyper-V Agent 
on computer '.'.



Alex Hitchins
+44 7788 423 969

-Original Message-
From: Devdeep Singh [mailto:devdeep.si...@citrix.com]
Sent: 06 January 2014 08:40
To: dev@cloudstack.apache.org; Donal Lafferty; Anshul Gangwar
Subject: RE: Hyper-V agent

Error seems to be in starting the service. Can you check under services 
(services.msc) if a service is present by the name "CloudStack Hyper-V Agent"? 
To debug the service start issue, can you open up the 8250 port (or try disable 
firewall) and check if the service starts up.

Regards,
Devdeep

-Original Message-
From: Paul Angus [mailto:paul.an...@shapeblue.com]
Sent: Friday, January 3, 2014 11:19 PM
To: dev@cloudstack.apache.org; Donal Lafferty; Anshul Gangwar
Subject: RE: Hyper-V agent

So... updating .net 4.5.1 and a reboot and CloudAgent builds (with 19 warnings) 
http://pastebin.com/ahz5yJw2

I copy it to my hyper-v box and it bombs out immediately 
http://imgur.com/NMan0S2

Install log says:

Installing assembly 'B:\Microsoft\AgentShell\AgentShell.exe'.
Affected parameters are:
   assemblypath = B:\Microsoft\AgentShell\AgentShell.exe
   logfile = B:\Microsoft\AgentShell\AgentShell.InstallLog
Installing service CloudStack Hyper-V Agent...
Service CloudStack Hyper-V Agent has been successfully installed.
Creating EventLog source CloudStack Hyper-V Agent in log Application...
See the contents of the log file for the B:\Microsoft\AgentShell\AgentShell.exe 
assembly's progress.
The file is located at B:\Microsoft\AgentShell\AgentShell.InstallLog.
Committing assembly 'B:\Microsoft\AgentShell\AgentShell.exe'.
Affected parameters are:
   logtoconsole =
   assemblypath = B:\Microsoft\AgentShell\AgentShell.exe
   logfile = B:\Microsoft\AgentShell\AgentShell.InstallLog

agent log says:

2014-01-03 17:33:59,755 [1] DEBUG CloudStack.Plugin.AgentShell.Program [(null)] 
- CloudStack Hyper-V Agent arg is
2014-01-03 17:33:59,823 [1] INFO  CloudStack.Plugin.AgentShell.Program [(null)] 
- Installing and running CloudStack Hyper-V Agent
2014-01-03 17:34:02,185 [1] ERROR CloudStack.Plugin.AgentShell.Program [(null)] 
-  Error occured in starting service Cannot start service CloudStack Hyper-V 
Agent on computer '.'.


Regards,

Paul Angus
Cloud Architect
S: +44 20 3603 0540 | M: +447711418784 | T: @CloudyAngus 
paul.an...@shapeblue.com

From: Paul Angus [mailto:paul.an...@shapeblue.com]
Sent: 03 January 2014 16:35
To: Donal Lafferty; dev@cloudstack.apache.org; Anshul Gangwar
Subject: RE: Hyper-V agent

When (trying) to build the hyper-v agent I get these errors:

Build FAILED.

Warnings:

C:\cygwin64\usr\local\cloudstack\plug

RE: Unicode Characters in Input Fields

2014-01-08 Thread Alex Hitchins
Santhosh,

Thanks for your rely.

I'll try that regex and see what happens.

Regards to the db, it's not changed from 3.x schema. I've updated it to include 
an extended character and it accepts it accordingly. I believe therefore my 
findings are accurate.

I'll give that regex pattern a go and see if that allows the extended 
characters.

Many thanks,



Alex Hitchins
+44 7788 423 969

-Original Message-
From: Santhosh Edukulla [mailto:santhosh.eduku...@citrix.com]
Sent: 08 January 2014 17:45
To: dev@cloudstack.apache.org
Subject: RE: Unicode Characters in Input Fields

Alex,

Few notes:

1.Regular Expression [^\x00-\x1F\x7F]  can be used as "not" to  allow 
characters in the range 0-31 and 127 i believe. Not clear of \177 in the below 
mentioned reg ex.

2. Also, i believe when we say unicode, we mean only extended ascii charcter 
set( excluding non printable range 0-31,127), but not complete unicode code 
points?  I believe this will as well effect  mysql db and other code areas in 
CS of storing and handling these values changes. Changing  encoding either to 
utf-8\other for that column and byte set to read and write to accommodate the 
range we are looking to handle?


Thanks!
Santhosh

From: Alex Hitchins [alex.hitch...@shapeblue.com]
Sent: Wednesday, January 08, 2014 10:31 AM
To: dev@cloudstack.apache.org
Subject: RE: Unicode Characters in Input Fields

Yes - Sorry there is a related bug :

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

and a linked issue :

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

I will work on the patch and submit with tests.



Alex Hitchins
+44 7788 423 969

-Original Message-
From: sebgoa [mailto:run...@gmail.com]
Sent: 08 January 2014 15:09
To: dev@cloudstack.apache.org
Subject: Re: Unicode Characters in Input Fields


On Jan 8, 2014, at 3:16 PM, Alex Hitchins  wrote:

> All,
>
> Further to the below, I've done some digging around and have located the 
> following change : 
> http://permalink.gmane.org/gmane.comp.apache.cloudstack.devel/7621
>
> It looks like the validation was created to prevent non-printable characters 
> from being entered. A regex was used to match the undesirable characters. 
> This was included in 4.1 (note that 3.x does not have this issue).
>
> My regular expression knowledge could do with improving. Could someone verify 
> that the pattern [\000-\037\177] will match on characters such as ü as well 
> as the ASCII non-printable characters are numbers 0 to 31 and 127 decimal.
>
> If so, I can refine the validation to allow unicode yet exclude 0, 31 & 127.
>

Alex, is there a bug for this in JIRA ?

If yes, you can submit a patch via review board and describe the tests you did 
to make sure this does not break anything .

-sebastien


>
>
> Alex Hitchins
> +44 7788 423 969
>
> -Original Message-
> From: Alex Hitchins [mailto:alex.hitch...@shapeblue.com]
> Sent: 08 January 2014 11:31
> To: dev@cloudstack.apache.org
> Subject: Unicode Characters in Input Fields
>
> Hi all,
>
> I've run in to a bug regarding entering Unicode characters in input fields, 
> namely the new user form.
>
> My issue is that you can create new users in CPBM with Unicode characters in 
> the name - such as ü however this causes a problem in CloudStack as they 
> aren't supported.
>
> I can see the line of code where the validation occurs - my question is - is 
> this be design or is this an issue? I'm guessing Japanese and German users 
> can enter in Unicode characters, especially for the users names.
>
>
>
>
> Regards,
>
> Alex Hitchins
>
> Need Enterprise Grade Support for Apache CloudStack?
> Our CloudStack Infrastructure 
> Support offers the 
> best 24/7 SLA for CloudStack Environments.
>
> Apache CloudStack Bootcamp training courses
>
> **NEW!** CloudStack 4.2 training
> 08/09 January 2014, London
> 13-17 January 2014, GLOBAL. Instructor led, 
> On-line
> 20-24 January 2014, GLOBAL. Instructor led, 
> On-line
>
> 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 i

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

2014-01-08 Thread Alex Ough
All,

A little bit of updates after a long vacation,
I'm currently creating automated test scripts that randomly
create/delete/update domain/account/user objects in random regions to
trigger the sync-up and full scans regularly.
Once they are completed, I'll post it in the github also and submit the
review requests for this implementation.

Let me know if you have any comments.
Thanks
Alex Ough


On Wed, Dec 18, 2013 at 3:39 PM, Alex Ough  wrote:

> All,
>
> I updated the wiki after some logic changes, so please review them,
> especially "Full Scan", which is newly introduced.
>
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Domain-Account-User+Sync+Up+Among+Multiple+Regions
>
> And I implemented this functionality in Java and you can get the pull
> request of it here.
> (This does not include the 'full scan' yet and I'm currently working
> on this to finalize.)
> https://github.com/alexoughsg/Albatross/pull/1
>
> Especially, I really want to have your review on the "Full Scan" logic
> to confirm if it does not miss any cases.
> Thanks for your interest and your feedback will be very helpful.
> Alex Ough
>
> On Tue, Nov 12, 2013 at 6:00 PM, Alex Ough  wrote:
> > Good point, Chiradeep,
> >
> > I'm not sure if you reviewed my design doc in the wiki, but my design is
> to
> > just skip any actions for target resources that already took place by any
> > means.
> > But the issue is when conflict actions in the same resources (like
> create &
> > delete the same users) are enqueued in reversed orders, which is
> hopefully
> > rare.
> >
> > And to support consistency in the AP system, I'd like to provide a full
> sync
> > up, which will sync up all data in all region servers by selecting a
> region
> > as a master and force its data to other regions.
> >
> > Let me know what you think.
> > Thanks
> > Alex Ough
> >
> >
> > On Tue, Nov 12, 2013 at 1:22 PM, Chiradeep Vittal
> >  wrote:
> >>
> >> Missed this one. In a single region, the CloudStack DB is the master for
> >> most operations. If the infra is not in the state the DB says it should
> >> be, generally the approach is to whack it and make it conform. For some
> >> exceptions (live migration/related use cases are exceptions) the DB is
> the
> >> slave -- the point is that the inconsistency that inevitably arise in an
> >> AP system need a conflict resolution system. In a single region, the
> >> default is to assume that the MySQL DB is correct and handle other cases
> >> carefully.
> >>
> >> In a multi-region case, there is no master: disable an account in one
> >> region, and it may not propagate to the other regions for many
> hours/days.
> >> You could add a user in one region and then add the same user in a
> >> different region and conflict before the sync happens.
> >>
> >> This is of course not a problem unique to CloudStack -- people pay mucho
> >> dinero for Global AD/LDAP sync. I don't think this is a problem for
> >> CloudStack core to solve: I support the event-based mechanism for those
> >> who want this facility.
> >>
> >> Distributed systems are hard and research continues to try and make
> >> building these systems easier, but there are very few solutions for
> global
> >> state synchronization (Google Spanner comes to mind)
> >>
> >> --
> >> Chiradeep
> >>
> >>
> >> On 11/8/13 4:53 PM, "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
> >> >> 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.
> >> >>
> >>
> >>
> >
>


[ACS43] Closing Resolved Defects

2014-01-08 Thread Sudha Ponnaganti
Community Members,

Following are the defects that are resolved for ACS 4.3.  As RC would be done 
soon, can you make sure to validate and close these defects

Thanks
/sudha

Reporter  Total
Abhinav Roy   6
Ahmad Emneina   1
Alena Prokharchyk  7
Alex Huang 1
angeline shen11
Anshul Gangwar   4
Ashutosk Kelkar   2
Bharat Kumar4
Brian Federle 1
Chandan Purushothama   8
Chris Suich  9
Darren Shepherd 1
Dave Garbus  1
David Matteson1
Denis Finko 2
Devdeep Singh 2
Donal Lafferty   2
Francois Gaudreault   1
frank zhang1
Gaurav Aradhye   4
gavin lee  1
Harikrishna Patnala 6
ilya musayev  1
Jayapal Reddy   3
Jessica Wang  3
John Kinsella  1
kelcey damage  1
Kiran Koneti   7
Kishan Kavala 1
Koushik Das2
Likitha Shetty 9
manasaveloori  9
Min Chen2
Murali Reddy 5
Nicolas Lamirault  1
Nitin Mehta6
Parth Jagirdar1
Pavan Kumar Bandarupally  3
Prachi Damle  4
prashant kumar mishra 5
Rajani Karuturi  1
Rajesh Battala   10
rashid2
Rayees Namathponnan23
sadhu suresh 3
Sailaja Mada   13
Sangeetha Hariharan  14
Sanjay Tripathi  1
Sanjeev N   8
Sateesh Chodapuneedi 2
Sheng Yang 5
shweta agarwal3
sie,chih-wei1
Sowmya Krishnan13
Srikanteswararao Talluri8
Sten Spans  1
Stephen Lamb   1
Steve Searles 1
Thomas O'Dowd   1
Tomasz Zieba 2
venkata swamybabu budumuru   3
Vladimir Ostrovsky  1
Will Stevens   2
Yoshikazu Nojima2
Grand Total261


Status of CLVM?

2014-01-08 Thread Nux!

Hi,

I've just watched Marcus Sorensen's presentation on CLVM on youtube and 
he was mentioning that migrating a VM with snapshots will make the 
snapshots disappear.

Can anyone testify if this is still the case?
Since at it, are there any alternative ways of using a multipathed 
iSCSI lun with Cloudstack (KVM)? I'm thinking clustered filesystems such 
as GFS or Ocfs, but afraid of the penalty performance.


Regards,
Lucian

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro


Re: Status of CLVM?

2014-01-08 Thread Marcus Sorensen
Yes, because current snapshot is really "Copy raw-formatted LVM volume
to qcow2 file on secondary storage". So there is no real LVM snapshot,
and if there were, it wouldn't be copied internally.

On Wed, Jan 8, 2014 at 3:47 PM, Nux!  wrote:
> Hi,
>
> I've just watched Marcus Sorensen's presentation on CLVM on youtube and he
> was mentioning that migrating a VM with snapshots will make the snapshots
> disappear.
> Can anyone testify if this is still the case?
> Since at it, are there any alternative ways of using a multipathed iSCSI lun
> with Cloudstack (KVM)? I'm thinking clustered filesystems such as GFS or
> Ocfs, but afraid of the penalty performance.
>
> Regards,
> Lucian
>
> --
> Sent from the Delta quadrant using Borg technology!
>
> Nux!
> www.nux.ro


Re: Status of CLVM?

2014-01-08 Thread Marcus Sorensen
You'd create a sharedmountpoint style primary storage, which would
host qcow2 files. You can do this via iscsi, fibrechannel, or any
other SAN tech.

On Wed, Jan 8, 2014 at 3:49 PM, Marcus Sorensen  wrote:
> Yes, because current snapshot is really "Copy raw-formatted LVM volume
> to qcow2 file on secondary storage". So there is no real LVM snapshot,
> and if there were, it wouldn't be copied internally.
>
> On Wed, Jan 8, 2014 at 3:47 PM, Nux!  wrote:
>> Hi,
>>
>> I've just watched Marcus Sorensen's presentation on CLVM on youtube and he
>> was mentioning that migrating a VM with snapshots will make the snapshots
>> disappear.
>> Can anyone testify if this is still the case?
>> Since at it, are there any alternative ways of using a multipathed iSCSI lun
>> with Cloudstack (KVM)? I'm thinking clustered filesystems such as GFS or
>> Ocfs, but afraid of the penalty performance.
>>
>> Regards,
>> Lucian
>>
>> --
>> Sent from the Delta quadrant using Borg technology!
>>
>> Nux!
>> www.nux.ro


Re: [ACS43] Closing Resolved Defects

2014-01-08 Thread Mike Tutkowski
I was wondering, we originally planned on spinning up a RC1 build this
coming Friday, right?

Just curious if that is still the plan?

Thanks!


On Wed, Jan 8, 2014 at 3:29 PM, Sudha Ponnaganti <
sudha.ponnaga...@citrix.com> wrote:

> Community Members,
>
> Following are the defects that are resolved for ACS 4.3.  As RC would be
> done soon, can you make sure to validate and close these defects
>
> Thanks
> /sudha
>
> Reporter  Total
> Abhinav Roy   6
> Ahmad Emneina   1
> Alena Prokharchyk  7
> Alex Huang 1
> angeline shen11
> Anshul Gangwar   4
> Ashutosk Kelkar   2
> Bharat Kumar4
> Brian Federle 1
> Chandan Purushothama   8
> Chris Suich  9
> Darren Shepherd 1
> Dave Garbus  1
> David Matteson1
> Denis Finko 2
> Devdeep Singh 2
> Donal Lafferty   2
> Francois Gaudreault   1
> frank zhang1
> Gaurav Aradhye   4
> gavin lee  1
> Harikrishna Patnala 6
> ilya musayev  1
> Jayapal Reddy   3
> Jessica Wang  3
> John Kinsella  1
> kelcey damage  1
> Kiran Koneti   7
> Kishan Kavala 1
> Koushik Das2
> Likitha Shetty 9
> manasaveloori  9
> Min Chen2
> Murali Reddy 5
> Nicolas Lamirault  1
> Nitin Mehta6
> Parth Jagirdar1
> Pavan Kumar Bandarupally  3
> Prachi Damle  4
> prashant kumar mishra 5
> Rajani Karuturi  1
> Rajesh Battala   10
> rashid2
> Rayees Namathponnan23
> sadhu suresh 3
> Sailaja Mada   13
> Sangeetha Hariharan  14
> Sanjay Tripathi  1
> Sanjeev N   8
> Sateesh Chodapuneedi 2
> Sheng Yang 5
> shweta agarwal3
> sie,chih-wei1
> Sowmya Krishnan13
> Srikanteswararao Talluri8
> Sten Spans  1
> Stephen Lamb   1
> Steve Searles 1
> Thomas O'Dowd   1
> Tomasz Zieba 2
> venkata swamybabu budumuru   3
> Vladimir Ostrovsky  1
> Will Stevens   2
> Yoshikazu Nojima2
> Grand Total261
>



-- 
*Mike Tutkowski*
*Senior CloudStack Developer, SolidFire Inc.*
e: mike.tutkow...@solidfire.com
o: 303.746.7302
Advancing the way the world uses the
cloud
*™*


RE: [ACS43] Closing Resolved Defects

2014-01-08 Thread Animesh Chaturvedi


-Original Message-
From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com] 
Sent: Wednesday, January 08, 2014 3:08 PM
To: dev@cloudstack.apache.org
Subject: Re: [ACS43] Closing Resolved Defects

I was wondering, we originally planned on spinning up a RC1 build this coming 
Friday, right?

Just curious if that is still the plan?

Thanks!
[Animesh] Mike  the existing backlog is close to 50 and I am still hopeful that 
we can bring it down significantly  and I can proceed with RC as planned. Need 
yours and other community members to help out resolve the backlog and try out 
4.3 as it stands to check if something has been missed out (especially upgrades)


On Wed, Jan 8, 2014 at 3:29 PM, Sudha Ponnaganti < sudha.ponnaga...@citrix.com> 
wrote:

> Community Members,
>
> Following are the defects that are resolved for ACS 4.3.  As RC would 
> be done soon, can you make sure to validate and close these defects
>
> Thanks
> /sudha
>
> Reporter  Total
> Abhinav Roy   6
> Ahmad Emneina   1
> Alena Prokharchyk  7
> Alex Huang 1
> angeline shen11
> Anshul Gangwar   4
> Ashutosk Kelkar   2
> Bharat Kumar4
> Brian Federle 1
> Chandan Purushothama   8
> Chris Suich  9
> Darren Shepherd 1
> Dave Garbus  1
> David Matteson1
> Denis Finko 2
> Devdeep Singh 2
> Donal Lafferty   2
> Francois Gaudreault   1
> frank zhang1
> Gaurav Aradhye   4
> gavin lee  1
> Harikrishna Patnala 6
> ilya musayev  1
> Jayapal Reddy   3
> Jessica Wang  3
> John Kinsella  1
> kelcey damage  1
> Kiran Koneti   7
> Kishan Kavala 1
> Koushik Das2
> Likitha Shetty 9
> manasaveloori  9
> Min Chen2
> Murali Reddy 5
> Nicolas Lamirault  1
> Nitin Mehta6
> Parth Jagirdar1
> Pavan Kumar Bandarupally  3
> Prachi Damle  4
> prashant kumar mishra 5
> Rajani Karuturi  1
> Rajesh Battala   10
> rashid2
> Rayees Namathponnan23
> sadhu suresh 3
> Sailaja Mada   13
> Sangeetha Hariharan  14
> Sanjay Tripathi  1
> Sanjeev N   8
> Sateesh Chodapuneedi 2
> Sheng Yang 5
> shweta agarwal3
> sie,chih-wei1
> Sowmya Krishnan13
> Srikanteswararao Talluri8
> Sten Spans  1
> Stephen Lamb   1
> Steve Searles 1
> Thomas O'Dowd   1
> Tomasz Zieba 2
> venkata swamybabu budumuru   3
> Vladimir Ostrovsky  1
> Will Stevens   2
> Yoshikazu Nojima2
> Grand Total261
>



--
*Mike Tutkowski*
*Senior CloudStack Developer, SolidFire Inc.*
e: mike.tutkow...@solidfire.com
o: 303.746.7302
Advancing the way the world uses the
cloud
*(tm)*


Re: Review Request 16361: CLOUDSTACK-5535: Do not allow addNetwork to create NIC across VPC tiers and Isolated Networks

2014-01-08 Thread Alena Prokharchyk

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


One more check is needed: don't let to add vm to VPC network if its already a 
part of another VPC network.

- Alena Prokharchyk


On Dec. 19, 2013, 5:25 a.m., Saksham Srivastava wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/16361/
> ---
> 
> (Updated Dec. 19, 2013, 5:25 a.m.)
> 
> 
> Review request for cloudstack and Alena Prokharchyk.
> 
> 
> Bugs: CLOUDSTACK-5535
> https://issues.apache.org/jira/browse/CLOUDSTACK-5535
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> addNetworkToVM allows adding any network to VM.
> Ideally a VM running in isolated Guest Network should not be able to add a 
> VPC tier.
> A VM running in VPC tier should not be allowed to add another tier
> A VM running in VPC tier should not be allowed to add another isolated guest 
> network
> 
> 
> Diffs
> -
> 
>   server/src/com/cloud/vm/UserVmManagerImpl.java 3ad49d8 
> 
> Diff: https://reviews.apache.org/r/16361/diff/
> 
> 
> Testing
> ---
> 
> VM having a nic in isolated guest network cannot add a VPC tier.
> VM having a nic in one VPC tier cannot add another VPC tier.
> VM having a nic in a VPC tier cannot add a isolated guest network.
> 
> 
> Thanks,
> 
> Saksham Srivastava
> 
>



Re: Trying to add Amazon S3 to CloudPlatform?

2014-01-08 Thread John Burwell
(+ @dev)

Min,

I don't think that the current implementation is a limitation or problem.  
Region-wide storage will impose certain constraints on secondary storage in 
contained zones to satisfy data consistency and reliability requirements.  
Therefore, it seems completely logically that region wide secondary storage 
would prevent the contained zones from defining a potentially conflicting 
secondary storage configuration.

Thanks,
-John

> On Jan 8, 2014, at 6:13 PM, Min Chen  wrote:
> 
> Unfortunately, our current implementation cannot have two zones, one using 
> NFS secondary, the other using S3 secondary. We don't support heterogeneous 
> secondary storages in a region so far.
> 
> Thanks
> min
> 
> From: Aaron Delp 
> Date: Wednesday, January 8, 2014 3:10 PM
> To: Min Chen , Tim Mackey , 
> Edison Su 
> Cc: John Burwell 
> Subject: Re: Trying to add Amazon S3 to CloudPlatform?
> 
> Ahhh – I thought you could only have one type of object storage (swift or S3) 
> but you are saying we can only have one kind of secondary no matter the type, 
> correct?
> 
> Does this apply at the zone level or at the region level? We currently have 
> one region, could I create another zone in that region and put S3 as 
> secondary in the new region and retain my NFS in the existing region?  In the 
> end could we have one region with two zones (one with NFS secondary and one 
> with S3 secondary)?
> 
> Thank you!!!
> 
> Aaron Delp
> Senior Director Technical Marketing, Cloud Platform Group
> aaron.d...@citrix.com / 919-561-7904
> blog: aarondelp.com / twitter: @aarondelp
> 
> 
> From: Min Chen 
> Date: Wednesday, January 8, 2014 6:02 PM
> To: Aaron Delp , Timothy Mackey 
> , Edison Su 
> Cc: John Burwell 
> Subject: Re: Trying to add Amazon S3 to CloudPlatform?
> 
> Hi Aaron,
> 
> This is the current limitation of our support for using S3 as region-wide 
> secondary storage. In a cloud, if you add S3 as a secondary storage, you 
> cannot have other zone-wide secondary storage existing, in your case, you 
> already have a NFS secondary storage there, so we will prevent you from 
> adding a S3 as secondary storage. If you want to use S3 as secondary storage, 
> then you can add your NFS as S3 staging store.
> 
> Thanks
> -min
> 
> From: Aaron Delp 
> Date: Wednesday, January 8, 2014 2:43 PM
> To: Tim Mackey , Edison Su , 
> Min Chen 
> Cc: John Burwell 
> Subject: Trying to add Amazon S3 to CloudPlatform?
> 
> Edison and Min – We have Citrix Summit coming up next week and we are trying 
> to add Amazon S3 backed secondary storage to Tim Mackey's lab (copied).  I 
> reached out to John and he helped me understand some things but I'm at a 
> stopping point and he suggested you might be able to help out.
> 
> We have an NFS share on a NetApp array (/vol/exports/temp) that I can add as 
> secondary storage with an NFS type. When I try to add the same scratch area 
> and put in all my S3 credentials I get the following error: You can only add 
> new image stores from the same provider NFS already added. I don't understand 
> that error and I'm not sure how to proceed. It pops up even if I add bogus 
> NFS paths. We're on a pretty tight time line and we hoping you might be able 
> to lend a hand.
> 
> I'm also going to post to the CloudStack User list (this is CCP 4.2 though) 
> and see what happens over there.
> 
> Thank you!
> 
> 


Re: Trying to add Amazon S3 to CloudPlatform?

2014-01-08 Thread John Burwell
+ @dev

> On Jan 8, 2014, at 10:12 PM, John Burwell  wrote:
> 
> Rashika,
> 
> It seems appropriate to also defect the error message as unclear.  I am very 
> familiar with the code and functionality, but that error message made no 
> sense to me.
> 
> Thanks,
> -John
> 
>> On Jan 8, 2014, at 8:24 PM, Radhika Puthiyetath 
>>  wrote:
>> 
>> + Animesh
>>  
>> Sure, I will take care of both CCP/ACS docs.
>>  
>> -Radhika
>>  
>> From: Aaron Delp 
>> Sent: Thursday, January 09, 2014 4:59 AM
>> To: Min Chen; Tim Mackey; Edison Su
>> Cc: John Burwell; Radhika Puthiyetath
>> Subject: Re: Trying to add Amazon S3 to CloudPlatform?
>> Importance: High
>>  
>> Happy to but never have before and don't know where to start. Radhika, can 
>> you get me started?
>>  
>> Thanks!
>>  
>> Aaron Delp
>> Senior Director Technical Marketing, Cloud Platform Group
>> aaron.d...@citrix.com / 919-561-7904
>> blog: aarondelp.com / twitter: @aarondelp
>>  
>>  
>> From: Min Chen 
>> Date: Wednesday, January 8, 2014 6:25 PM
>> To: Aaron Delp , Timothy Mackey 
>> , Edison Su 
>> Cc: John Burwell , Radhika Puthiyetath 
>> 
>> Subject: Re: Trying to add Amazon S3 to CloudPlatform?
>>  
>> Can you please file a doc bug on that? We should fix this. Including Radhika 
>> here.
>>  
>> Thanks
>> -min
>>  
>> From: Aaron Delp 
>> Date: Wednesday, January 8, 2014 3:22 PM
>> To: Min Chen , Tim Mackey , 
>> Edison Su 
>> Cc: John Burwell 
>> Subject: Re: Trying to add Amazon S3 to CloudPlatform?
>>  
>> Awesome! Thanks for that link. The following is in both the CCP Install and 
>> Admin guides and that is what I was using:
>> You can use only a single region-wide object storage account per region. For 
>> example, you can not mix both Swift and S3, or use S3 accounts from multiple 
>> different users. 
>> 
>>  
>> Aaron Delp
>> Senior Director Technical Marketing, Cloud Platform Group
>> aaron.d...@citrix.com / 919-561-7904
>> blog: aarondelp.com / twitter: @aarondelp
>>  
>>  
>> From: Min Chen 
>> Date: Wednesday, January 8, 2014 6:20 PM
>> To: Aaron Delp , Timothy Mackey 
>> , Edison Su 
>> Cc: John Burwell 
>> Subject: Re: Trying to add Amazon S3 to CloudPlatform?
>>  
>> This is documented in the design doc published on ACS 
>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Storage+Backup+Object+Store+Plugin+Framework,
>>  maybe release notes didn't state that clearly. In 4.3, we will support 
>> migration NFS to S3 by automatically converting existing NFS secondary 
>> storage to S3 staging stores. See 
>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Migration+of+NFS+Secondary+Storage+to+Object+Store
>>  for details.
>>  
>> Thanks
>> -min
>>  
>> From: Aaron Delp 
>> Date: Wednesday, January 8, 2014 3:16 PM
>> To: Min Chen , Tim Mackey , 
>> Edison Su 
>> Cc: John Burwell 
>> Subject: Re: Trying to add Amazon S3 to CloudPlatform?
>>  
>> Got it. Thanks! Is that a doc bug then? Docs state no S3 and Swift but no 
>> mention of not mixing NFS as well. That's probably a show stopper for our 
>> lab as we have a lot on NFS now and no time to convert over.
>>  
>> Thanks again!
>>  
>> Aaron Delp
>> Senior Director Technical Marketing, Cloud Platform Group
>> aaron.d...@citrix.com / 919-561-7904
>> blog: aarondelp.com / twitter: @aarondelp
>>  
>>  
>> From: Min Chen 
>> Date: Wednesday, January 8, 2014 6:13 PM
>> To: Aaron Delp , Timothy Mackey 
>> , Edison Su 
>> Cc: John Burwell 
>> Subject: Re: Trying to add Amazon S3 to CloudPlatform?
>>  
>> Unfortunately, our current implementation cannot have two zones, one using 
>> NFS secondary, the other using S3 secondary. We don't support heterogeneous 
>> secondary storages in a region so far.
>>  
>> Thanks
>> min
>>  
>> From: Aaron Delp 
>> Date: Wednesday, January 8, 2014 3:10 PM
>> To: Min Chen , Tim Mackey , 
>> Edison Su 
>> Cc: John Burwell 
>> Subject: Re: Trying to add Amazon S3 to CloudPlatform?
>>  
>> Ahhh – I thought you could only have one type of object storage (swift or 
>> S3) but you are saying we can only have one kind of secondary no matter the 
>> type, correct?
>>  
>> Does this apply at the zone level or at the region level? We currently have 
>> one region, could I create another zone in that region and put S3 as 
>> secondary in the new region and retain my NFS in the existing region?  In 
>> the end could we have one region with two zones (one with NFS secondary and 
>> one with S3 secondary)?
>>  
>> Thank you!!!
>>  
>> Aaron Delp
>> Senior Director Technical Marketing, Cloud Platform Group
>> aaron.d...@citrix.com / 919-561-7904
>> blog: aarondelp.com / twitter: @aarondelp
>>  
>>  
>> From: Min Chen 
>> Date: Wednesday, January 8, 2014 6:02 PM
>> To: Aaron Delp , Timothy Mackey 
>> , Edison Su 
>> Cc: John Burwell 
>> Subject: Re: Trying to add Amazon S3 to CloudPlatform?
>>  
>> Hi Aaron,
>>  
>> This is the current limitation of our support for using S3 as region-wide 
>> secondary storage. In a cloud, if you add S3 as a secondary storage, you 

Re: [VOTE] 3rd round of voting for ASF 4.2.1 RC

2014-01-08 Thread Abhinandan Prateek


On 04/01/14 6:52 pm, "David Nalley"  wrote:

>Abhi:
>
>Please send a [VOTE] [RESULT] email with the vote tally.
>
>I am somewhat surprised that 4.2.1 wasn't tagged using build_asf.sh
>during the creation of the RC artifacts. Are you sure you aren't
>sitting on the tag locally? Also the tag should be 4.2.1, look at the
>other tags for examples.
>

4.2.1 tag is now moved to the right commit:
https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=commit;h=1b2b58f
e352a19aee1721bd79b9d023d36e80ec5

-abhi

>



RE: DR as a service in CloudPlatform?

2014-01-08 Thread Radhika Puthiyetath
Hi,

Here is the documentation on GSLB.

https://cloudstack.apache.org/docs/en-US/Apache_CloudStack/4.2.0/html-single/Admin_Guide/index.html#gslb

-Radhika

-Original Message-
From: Octavian Popescu [mailto:octavian.pope...@interoute.com] 
Sent: Wednesday, January 08, 2014 7:43 PM
To: dev@cloudstack.apache.org
Subject: DR as a service in CloudPlatform?

Hello,

Could you please confirm if any DR specific features are being developed for 
CloudStack/CloudPlatform? (e.g. DR tags that indicate whether a machine should 
be moved between zones in case of a failure) If positive, could you please 
share some details about how exactly it will work?

Thanks,
Octavian





RE: [MERGE] Opendaylight plugin

2014-01-08 Thread Wilder Rodrigues
Good stuff! :)

Cheers,
Wilder

-Original Message-
From: Trippie [mailto:trip...@gmail.com] On Behalf Of Hugo Trippaers
Sent: Wednesday, January 08, 2014 5:13 PM
To: dev
Subject: Re: [MERGE] Opendaylight plugin

Thanks for the feedback.

The support is merged into master:

612a41e3f5b7f57b205ea84503d670793fb44c4f Add UI interface for managing the 
OpenDaylight provider and controllers.
e4cb9ce8bcb0ffa8b3a4f82f0e32002e19f35085 Add opendaylight provider to system.js 
57da2bc784f125f61af4020d8589c690b89f058a Apply two small fixes to system.js
0ba1abe2627bd05c64aabf25142b266837c6e044 Apply some formatting to system.js
8ddcc9ba808041fbf42fc45f478574502dcad256 Set unique gre key for every network.
f3f93a96f549203e00046bd681ddc87e174c2a6b Adding OpenDayLight Neutron API. It 
includes 24 unit tests and 3 integration tests. Everythin passed the build.
850bc9fa826393c5ab110bf49138b4d0e1c1c313 Hook the OpenDaylight plugin into 
CloudStack 1f9528bad3493f287bfd6dfc48dfd077697e7d1f Add a network plugin for 
OpenDaylight


Cheers,

Hugo

On 7 jan. 2014, at 17:21, Nguyen Anh Tu  wrote:

> +1 Hugo.
> 
> Looking forward if I can do anything for that plugin.
> 
> --Tuna
> 
> 
> On Mon, Jan 6, 2014 at 9:45 PM, sebgoa  wrote:
> 
>> 
>> On Jan 6, 2014, at 9:03 AM, Hugo Trippaers  wrote:
>> 
>>> Hey all,
>>> 
>>> I would like to merge the branch open daylight into master. This 
>>> branch
>> contains a plugin with an interface to an OpenDaylight controller.
>>> 
>>> The current functionality is limited to creating layer 2 isolated
>> networks using overlay networking as supported by opendaylight. We 
>> are using the OVSDB and OpenFlow modules in OpenDaylight to build 
>> overlay networks using gre tunneling. Opendaylight does not have a 
>> release yet, so the state of the plugin is more of a technology 
>> preview, but has been tested with several KVM hypervisors and the 
>> latest build of the OpenDaylight controller and the ovsdb subproject. 
>> The functionality is enough to work as an equivalent to the existing 
>> GRE tunnel implementation for KVM hypervisors.
>>> 
>>> Ideally this plugin should be the basic groundwork to start 
>>> supporting
>> more functions/features available in OpenDaylight when they become 
>> available. It allows interested parties to work with CloudStack and 
>> OpenDaylight without having to work with a CS fork and keep rebasing 
>> a separate branch.
>>> 
>>> 
>>> Cheers,
>>> 
>>> Hugo
>> 
>> I have not tested it, but saw the patches and I am +1
>> 
>> 



Re: Review Request 16729: CLOUDSTACK-4904: Unable to see a derieved template if the parent template is deleted

2014-01-08 Thread Harikrishna Patnala

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

(Updated Jan. 9, 2014, 6:47 a.m.)


Review request for cloudstack and Nitin Mehta.


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


Repository: cloudstack-git


Description (updated)
---

CLOUDSTACK-4904: Unable to see a derieved template if the parent template is 
deleted

Modified template_view so that removed(or InActive) templates also be there in 
the view.
Previous behavior of listing templates and state column in vm_templates will be 
the same. 


Diffs
-

  api/src/org/apache/cloudstack/api/ApiConstants.java e08923c 
  api/src/org/apache/cloudstack/api/command/user/iso/ListIsosCmd.java c3f558b 
  api/src/org/apache/cloudstack/api/command/user/template/ListTemplatesCmd.java 
4b34909 
  server/src/com/cloud/api/query/QueryManagerImpl.java 37c2ef6 
  server/src/com/cloud/api/query/dao/TemplateJoinDao.java f73f5bd 
  server/src/com/cloud/api/query/dao/TemplateJoinDaoImpl.java 468fb83 
  server/src/com/cloud/api/query/vo/TemplateJoinVO.java ca5963e 
  setup/db/db/schema-421to430.sql 76c2399 

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


Testing
---


Thanks,

Harikrishna Patnala