RE: deleteAffinityGroup API

[Prachi Damle]

Account and domainId are not required parameters of this API. It works fine 
with just an id too.

Account and domain will be used if delete is called providing a name of the 
group instead of id, say by an admin for a regular user's group.


-Original Message-
From: Prasanna Santhanam [mailto:t...@apache.org] 
Sent: Wednesday, July 17, 2013 10:12 PM
To: CloudStack Dev
Subject: deleteAffinityGroup API

This API unlike all the other delete APIs in cloudstack needs an account and 
domainid to delete the cloud resource (affinity group).
Any reason why this should flout the semantics of other delete APIs which work 
with just an id?

Signature below:

AffinityGroupServiceImpl.java
@DB
@Override
@ActionEvent(eventType = EventTypes.EVENT_AFFINITY_GROUP_DELETE, 
eventDescription = "Deleting affinity group")
public boolean deleteAffinityGroup(Long affinityGroupId, String account, 
Long domainId, String affinityGroupName) {

Thanks,

--
Prasanna.,


Powered by BigRock.com

Re: CallContexts?

[Prasanna Santhanam]

On Thu, Jul 18, 2013 at 11:58:30AM +0530, Prasanna Santhanam wrote:
> I see the following repeated lines with API calls on master code
> lately: What's the call context? and what's the role?
> 
> 2013-07-18 11:52:24,372 DEBUG [cloudstack.context.CallContext] 
> (RouterStatusMonitor-1:ctx-9bb138b4) Context removed CallContext[acct=1; 
> user=1; session=9bb138b4-29c1-4ddf-ab47-9307a600d31e]
> 
>  * CallContext records information about the environment the call is made.  
> This
>  * class must be always be available in all CloudStack code.
> 
> Does this mean we have to do something special when creating new APIs? I'm not
> quite clear from this description.
> 
It seems from the logs that all APIs are now getting the context as
user=1,account=1 (SYSTEM). Filed CLOUDSTACK-3626.



-- 
Prasanna.,


Powered by BigRock.com

Re: Review Request 12700: Fix for CLOUDSTACK-3596 to include domain id

[ASF Subversion and Git Services]

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


Commit f5bd253b2b8d50bb42ce8a85b4d1db5b8e729b41 in branch refs/heads/master 
from sailajam
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=f5bd253 ]

CLOUDSTACK-3596: Domain ID missing to deploy VM request . Included Domain id


- ASF Subversion and Git Services


On July 17, 2013, 6:10 p.m., sailaja mada wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/12700/
> ---
> 
> (Updated July 17, 2013, 6:10 p.m.)
> 
> 
> Review request for cloudstack and Prasanna Santhanam.
> 
> 
> Bugs: CLOUDSTACK-3596
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Deploy VM request is sent without providing the Domain id . Cloudstack 
> mandates to provide domain id along with account name.
> 
> Fix is to include domain id to resolve script failure (Execute cmd: 
> deployvirtualmachine failed, due to: errorCode: 431, errorText:Account must 
> be specified with domainId parameter)
> 
> 
> Diffs
> -
> 
>   test/integration/component/test_accounts.py 65c0c6f 
> 
> Diff: https://reviews.apache.org/r/12700/diff/
> 
> 
> Testing
> ---
> 
> Tested with the change. Now test is passed.
> 
> 
> Thanks,
> 
> sailaja mada
> 
>

Re: Review Request 12546: CLOUDSTACK-3168: test_network.py - Changed try_ssh function defn. Resolved Object NoneType issues

[Gaurav Aradhye]

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

(Updated July 18, 2013, 8:45 a.m.)


Review request for cloudstack and Prasanna Santhanam.


Changes
---

Updated the diff for 4.2 branch. This patch needs to be applied after the 
b8d876fff806e33e859016c252bd208c1ea28c2d" commit in this branch.


Repository: cloudstack-git


Description
---

Resolved CLOUDSTACK-3168: Changed try_ssh function defn. Now it directly 
accepts ip address as parameter instead of reading it from object l
ater. This resolves object Nonetype issues which were arising due to passing 
wrong parameter as ip address


Diffs (updated)
-

  test/integration/smoke/test_loadbalance.py 7bf560c 

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


Testing
---


Thanks,

Gaurav Aradhye

Re: deleteAffinityGroup API

[Prasanna Santhanam]

On Thu, Jul 18, 2013 at 07:14:42AM +, Prachi Damle wrote:
> Account and domainId are not required parameters of this API. It
> works fine with just an id too.
> 
> Account and domain will be used if delete is called providing a name
> of the group instead of id, say by an admin for a regular user's
> group.
> 

Thanks Prachi - I think it is related to the recent changes in
CallContext that is making the user system for the API call preventing
it from deleteing the aff.group with just an id. Filed a bug for it.

-- 
Prasanna.,


Powered by BigRock.com

Re: Review Request 12700: Fix for CLOUDSTACK-3596 to include domain id

[Prasanna Santhanam]

> On July 18, 2013, 8:31 a.m., ASF Subversion and Git Services wrote:
> > Commit f5bd253b2b8d50bb42ce8a85b4d1db5b8e729b41 in branch refs/heads/master 
> > from sailajam
> > [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=f5bd253 ]
> > 
> > CLOUDSTACK-3596: Domain ID missing to deploy VM request . Included Domain id
> >

thanks. submitted this


- Prasanna


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


On July 17, 2013, 6:10 p.m., sailaja mada wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/12700/
> ---
> 
> (Updated July 17, 2013, 6:10 p.m.)
> 
> 
> Review request for cloudstack and Prasanna Santhanam.
> 
> 
> Bugs: CLOUDSTACK-3596
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Deploy VM request is sent without providing the Domain id . Cloudstack 
> mandates to provide domain id along with account name.
> 
> Fix is to include domain id to resolve script failure (Execute cmd: 
> deployvirtualmachine failed, due to: errorCode: 431, errorText:Account must 
> be specified with domainId parameter)
> 
> 
> Diffs
> -
> 
>   test/integration/component/test_accounts.py 65c0c6f 
> 
> Diff: https://reviews.apache.org/r/12700/diff/
> 
> 
> Testing
> ---
> 
> Tested with the change. Now test is passed.
> 
> 
> Thanks,
> 
> sailaja mada
> 
>

Review Request 12717: CLOUDSTACK-3618: [Automation] API call listprojectaccounts failed, and test case test_projects.py:test_08_cleanup_after_project_delete failed due to this.

[Sanjay Tripathi]

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

Review request for cloudstack, Devdeep Singh and Prasanna Santhanam.


Bugs: CLOUDSTACK-3618


Repository: cloudstack-git


Description
---

CLOUDSTACK-3618: [Automation] API call listprojectaccounts failed, and test 
case test_projects.py:test_08_cleanup_after_project_delete failed due to this.

The test is failing because listProjectAccount throws InvalidParameterException 
if the project with the projectid passed along with the API does not exist.


Diffs
-

  test/integration/component/test_projects.py 39e9bee 

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


Testing
---

Verified that test runs properly on my local cloudstack setup.


Thanks,

Sanjay Tripathi

Re: Review Request 12358: CLOUDSTACK-3228: system vms are not comming up in zone with two cluster xen and kvm

[Harikrishna Patnala]

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

(Updated July 18, 2013, 9:23 a.m.)


Review request for cloudstack and Nitin Mehta.


Changes
---

Updated patch based on review comments and included an enhancement on retry 
mechanism of system vm deployment


Bugs: CLOUDSTACK-3228 and CLOUDSTACK-3631


Repository: cloudstack-git


Description (updated)
---

CLOUDSTACK-3228: system vms are not comming up in zone with two cluster xen and 
kvm;Zone host is ready, but secondary storage vm template: 3 is not ready on 
secondary storage: 2

CLOUDSTACK-3631: Enhance System vm deployment retry mechanism


Diffs (updated)
-

  engine/schema/src/com/cloud/storage/dao/VMTemplateDao.java c3d44bd 
  engine/schema/src/com/cloud/storage/dao/VMTemplateDaoImpl.java 9e75990 
  
plugins/hypervisors/xen/src/com/cloud/hypervisor/xen/resource/XenServer56FP1Resource.java
 2cc592d 
  server/src/com/cloud/consoleproxy/ConsoleProxyManagerImpl.java 5983aa7 
  server/src/com/cloud/storage/secondary/SecondaryStorageManagerImpl.java 
6859b0b 

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


Testing
---

tested locally


Thanks,

Harikrishna Patnala

Re: Review Request 12717: CLOUDSTACK-3618: [Automation] API call listprojectaccounts failed, and test case test_projects.py:test_08_cleanup_after_project_delete failed due to this.

[Prasanna Santhanam]

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

Ship it!


Ship It!

- Prasanna Santhanam


On July 18, 2013, 9:14 a.m., Sanjay Tripathi wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/12717/
> ---
> 
> (Updated July 18, 2013, 9:14 a.m.)
> 
> 
> Review request for cloudstack, Devdeep Singh and Prasanna Santhanam.
> 
> 
> Bugs: CLOUDSTACK-3618
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> CLOUDSTACK-3618: [Automation] API call listprojectaccounts failed, and test 
> case test_projects.py:test_08_cleanup_after_project_delete failed due to this.
> 
> The test is failing because listProjectAccount throws 
> InvalidParameterException if the project with the projectid passed along with 
> the API does not exist.
> 
> 
> Diffs
> -
> 
>   test/integration/component/test_projects.py 39e9bee 
> 
> Diff: https://reviews.apache.org/r/12717/diff/
> 
> 
> Testing
> ---
> 
> Verified that test runs properly on my local cloudstack setup.
> 
> 
> Thanks,
> 
> Sanjay Tripathi
> 
>

RE: Quick Secondary Storage Question

[Donal Lafferty]

tl;dr - your network config may result in a need for system VMs on both Xen and 
VMWare clusters.

Long form:

System VMs provide services that are not feasible to deploy alongside the 
CloudStack management server.

Currently, there are three kinds:  secondary storage management services (aka 
SSVM), network services (aka virtual router), console services (aka console VM).

Sanjeev makes the point that SSVM can provide zone-wide secondary storage 
management services.  This SSVM has a light load, because it only setups up and 
manages images such as templates.  The hypervisors access secondary storage 
directly when downloading images.

In contrast, the virtual router's load and locality requirements may force 
CloudStack to create multiple instances.  IIRC, this occurs when the virtual 
routers take on packet routing tasks as opposed to higher level services.  
IIRC, security groups are enforced by an on the hypervisor virtual router. 

If someone could comment on console VMs that would be great.  Likewise, I would 
be interested to know if DHCP is zone wide or local to a hypervisor.


> -Original Message-
> From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com]
> Sent: 18 July 2013 7:21 AM
> To: dev@cloudstack.apache.org
> Subject: Re: Quick Secondary Storage Question
> 
> Thanks for your reply, Sanjeev!
> 
> I was curious what the answer to that was (even though I realized after I sent
> my e-mail why my system VMs weren't restarting and that it had nothing, as
> you noted, to do with only having the XenServer system template).
> 
> Thanks again!
> 
> 
> On Thu, Jul 18, 2013 at 12:12 AM, Sanjeev Neelarapu <
> sanjeev.neelar...@citrix.com> wrote:
> 
> > Hi,
> >
> > If both the hypervisors are in the same zone , then you don't need to
> > have the system templates installed for both hypervisor types. One
> > system template should be fine.
> >
> > Thanks,
> > Sanjeev
> >
> > -Original Message-
> > From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com]
> > Sent: Thursday, July 18, 2013 7:17 AM
> > To: dev@cloudstack.apache.org
> > Subject: Quick Secondary Storage Question
> >
> > Hi,
> >
> > I was wondering, if I am using two hypervisors (in my case, XenServer
> > and ESXi), do I need to have the system template installed for both
> > hypervisor types or will CloudStack function fine with having just one or 
> > the
> other?
> >
> > I ask because I actually have a config with XenServer and VMware, but
> > only have the XenServer system template on secondary storage because
> > the VMware one was not working for me (some kind of a SOAP error when
> > it was trying to deploy the template).
> >
> > I seem to be having trouble with system VMs not getting restarted, so
> > I'm thinking it's because I don't have the VMware template on secondary
> storage.
> >
> > Thanks!
> >
> > --
> > *Mike Tutkowski*
> > *Senior CloudStack Developer, SolidFire Inc.*
> > e: mike.tutkow...@solidfire.com
> > o: 303.746.7302
> > Advancing the way the world uses the
> > cloud
> > *(tm)*
> >
> 
> 
> 
> --
> *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 12632: CLOUDSTACK-3551: Fix value over flow due to type conversion

[ASF Subversion and Git Services]

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


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

CLOUDSTACK-3551: scaling up VM to service offering with 2gbram
Fixed the type overflow of Ram value.
Signed off by : Nitin Mehta


- ASF Subversion and Git Services


On July 17, 2013, 6:09 a.m., Harikrishna Patnala wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/12632/
> ---
> 
> (Updated July 17, 2013, 6:09 a.m.)
> 
> 
> Review request for cloudstack and Nitin Mehta.
> 
> 
> Bugs: CLOUDSTACK-3551
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> CLOUDSTACK-3551: scaling up VM to service offering with 2gbram 
> Fixed the type overflow of Ram value.
> 
> 
> Diffs
> -
> 
>   
> plugins/hypervisors/baremetal/src/com/cloud/baremetal/manager/BareMetalPlanner.java
>  97b2840 
>   server/src/com/cloud/capacity/CapacityManagerImpl.java d54624d 
>   server/src/com/cloud/vm/VirtualMachineManagerImpl.java 827e233 
> 
> Diff: https://reviews.apache.org/r/12632/diff/
> 
> 
> Testing
> ---
> 
> Tested locally
> 
> 
> Thanks,
> 
> Harikrishna Patnala
> 
>

Re: Review Request 12546: CLOUDSTACK-3168: test_network.py - Changed try_ssh function defn. Resolved Object NoneType issues

[ASF Subversion and Git Services]

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


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

CLOUDSTACK-3168: Change in try_ssh function

Signed-off-by: Prasanna Santhanam 


- ASF Subversion and Git Services


On July 18, 2013, 8:45 a.m., Gaurav Aradhye wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/12546/
> ---
> 
> (Updated July 18, 2013, 8:45 a.m.)
> 
> 
> Review request for cloudstack and Prasanna Santhanam.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Resolved CLOUDSTACK-3168: Changed try_ssh function defn. Now it directly 
> accepts ip address as parameter instead of reading it from object l
> ater. This resolves object Nonetype issues which were arising due to passing 
> wrong parameter as ip address
> 
> 
> Diffs
> -
> 
>   test/integration/smoke/test_loadbalance.py 7bf560c 
> 
> Diff: https://reviews.apache.org/r/12546/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Gaurav Aradhye
> 
>

Re: Review Request 12546: CLOUDSTACK-3168: test_network.py - Changed try_ssh function defn. Resolved Object NoneType issues

[ASF Subversion and Git Services]

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


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

CLOUDSTACK-3168: Change in try_ssh function

Signed-off-by: Prasanna Santhanam 
(cherry picked from commit e25cbd66d2b13db684f2f339b05aafa6b119bcfe)


- ASF Subversion and Git Services


On July 18, 2013, 8:45 a.m., Gaurav Aradhye wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/12546/
> ---
> 
> (Updated July 18, 2013, 8:45 a.m.)
> 
> 
> Review request for cloudstack and Prasanna Santhanam.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Resolved CLOUDSTACK-3168: Changed try_ssh function defn. Now it directly 
> accepts ip address as parameter instead of reading it from object l
> ater. This resolves object Nonetype issues which were arising due to passing 
> wrong parameter as ip address
> 
> 
> Diffs
> -
> 
>   test/integration/smoke/test_loadbalance.py 7bf560c 
> 
> Diff: https://reviews.apache.org/r/12546/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Gaurav Aradhye
> 
>

Re: Review Request 12717: CLOUDSTACK-3618: [Automation] API call listprojectaccounts failed, and test case test_projects.py:test_08_cleanup_after_project_delete failed due to this.

[ASF Subversion and Git Services]

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


Commit 52fa8532bb2821f9b5472e713a905bc6b7f712b5 in branch refs/heads/4.2 from 
Sanjay Tripathi
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=52fa853 ]

CLOUDSTACK-3618: When project account does not exist, API now throws exception

API call listprojectaccounts failed, and test case
test_projects.py:test_08_cleanup_after_project_delete failed due to
this

Signed-off-by: Prasanna Santhanam 


- ASF Subversion and Git Services


On July 18, 2013, 9:14 a.m., Sanjay Tripathi wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/12717/
> ---
> 
> (Updated July 18, 2013, 9:14 a.m.)
> 
> 
> Review request for cloudstack, Devdeep Singh and Prasanna Santhanam.
> 
> 
> Bugs: CLOUDSTACK-3618
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> CLOUDSTACK-3618: [Automation] API call listprojectaccounts failed, and test 
> case test_projects.py:test_08_cleanup_after_project_delete failed due to this.
> 
> The test is failing because listProjectAccount throws 
> InvalidParameterException if the project with the projectid passed along with 
> the API does not exist.
> 
> 
> Diffs
> -
> 
>   test/integration/component/test_projects.py 39e9bee 
> 
> Diff: https://reviews.apache.org/r/12717/diff/
> 
> 
> Testing
> ---
> 
> Verified that test runs properly on my local cloudstack setup.
> 
> 
> Thanks,
> 
> Sanjay Tripathi
> 
>

Re: Review Request 12717: CLOUDSTACK-3618: [Automation] API call listprojectaccounts failed, and test case test_projects.py:test_08_cleanup_after_project_delete failed due to this.

[Prasanna Santhanam]

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

Ship it!


Ship It!

- Prasanna Santhanam


On July 18, 2013, 9:14 a.m., Sanjay Tripathi wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/12717/
> ---
> 
> (Updated July 18, 2013, 9:14 a.m.)
> 
> 
> Review request for cloudstack, Devdeep Singh and Prasanna Santhanam.
> 
> 
> Bugs: CLOUDSTACK-3618
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> CLOUDSTACK-3618: [Automation] API call listprojectaccounts failed, and test 
> case test_projects.py:test_08_cleanup_after_project_delete failed due to this.
> 
> The test is failing because listProjectAccount throws 
> InvalidParameterException if the project with the projectid passed along with 
> the API does not exist.
> 
> 
> Diffs
> -
> 
>   test/integration/component/test_projects.py 39e9bee 
> 
> Diff: https://reviews.apache.org/r/12717/diff/
> 
> 
> Testing
> ---
> 
> Verified that test runs properly on my local cloudstack setup.
> 
> 
> Thanks,
> 
> Sanjay Tripathi
> 
>

Re: Review Request 12546: CLOUDSTACK-3168: test_network.py - Changed try_ssh function defn. Resolved Object NoneType issues

[Prasanna Santhanam]

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

Ship it!


Ship It!

- Prasanna Santhanam


On July 18, 2013, 8:45 a.m., Gaurav Aradhye wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/12546/
> ---
> 
> (Updated July 18, 2013, 8:45 a.m.)
> 
> 
> Review request for cloudstack and Prasanna Santhanam.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Resolved CLOUDSTACK-3168: Changed try_ssh function defn. Now it directly 
> accepts ip address as parameter instead of reading it from object l
> ater. This resolves object Nonetype issues which were arising due to passing 
> wrong parameter as ip address
> 
> 
> Diffs
> -
> 
>   test/integration/smoke/test_loadbalance.py 7bf560c 
> 
> Diff: https://reviews.apache.org/r/12546/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Gaurav Aradhye
> 
>

Re: Review Request 12499: CLOUDSTACK-3376: NPE: resource count calculation from the account manager on account cleanup

[ASF Subversion and Git Services]

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


Commit c9548e37885bee6abf62c515c910fe29f9fcd7c6 in branch refs/heads/4.2 from 
Sanjay Tripathi
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=c9548e3 ]

CLOUDSTACK-3376: NPE: resource count calculation from the account manager on 
account cleanup

This issue is happing because of the steps the code follow to cleanup the 
account.
The cleanupAccount was deleting the entries from the resource_limit and
resource_count table and performing further cleaning afterwards. Ideally, 
deletion
of entries from resourceLimit and resourceCount should be the last step in
cleanupAccount process.

Signed-off-by: Prasanna Santhanam 
(cherry picked from commit 21b1c9449a1289db9fa92c2ec76a936006100ab3)


- ASF Subversion and Git Services


On July 12, 2013, 9:13 a.m., Sanjay Tripathi wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/12499/
> ---
> 
> (Updated July 12, 2013, 9:13 a.m.)
> 
> 
> Review request for cloudstack, Devdeep Singh and Prasanna Santhanam.
> 
> 
> Bugs: CLOUDSTACK-3376
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> CLOUDSTACK-3376: NPE: resource count calculation from the account manager 
> on account cleanup
> 
> This issue is happing because of the steps the code follow to cleanup the 
> account.
> The cleanupAccount was deleting the entries from the resource_limit and
> resource_count table and performing further cleaning afterwards. Ideally, 
> deletion
> of entries from resourceLimit and resourceCount should be the last step in
> cleanupAccount process.
> 
> 
> Diffs
> -
> 
>   server/src/com/cloud/user/AccountManagerImpl.java 283e832 
> 
> Diff: https://reviews.apache.org/r/12499/diff/
> 
> 
> Testing
> ---
> 
> Steps I followed to test account cleanup scenario:
> 
> 1. Create a user account.
> 2. Login as user.
> 3. Register a template and deploy an instance using this registered template.
> 4. Create a project from this user account.
> 5. Go to project view
> 6. Register a template and create a volume in this project_account.
> 7. Logout and login as root-admin.
> 8. Delete the project manages by the user account.
> 9. Delete the user account.
> 
> In MS logs, verified that cleanupAccount is happing properly.
> 
> 
> Thanks,
> 
> Sanjay Tripathi
> 
>

RE: Template Question

[Koushik Das]

I am also seeing it.

-Koushik

> -Original Message-
> From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com]
> Sent: Wednesday, July 17, 2013 9:22 PM
> To: dev@cloudstack.apache.org
> Subject: Template Question
> 
> Hi,
> 
> I've noticed recently on XenServer when SSVM and CPVM are deployed that
> Template routing-1 appears twice in my Disks list (it used to appear only
> once).
> 
> Is this change in behavior expected?
> 
> Thanks!
> 
> --
> *Mike Tutkowski*
> *Senior CloudStack Developer, SolidFire Inc.*
> e: mike.tutkow...@solidfire.com
> o: 303.746.7302
> Advancing the way the world uses the
> cloud
> *(tm)*

RE: Template Question

[Devdeep Singh]

Changes were made recently to allow some commands to execute in parallel on a 
hypervisor resource. Maybe that is causing it.

Regards,
Devdeep

> -Original Message-
> From: Koushik Das [mailto:koushik@citrix.com]
> Sent: Thursday, July 18, 2013 3:11 PM
> To: dev@cloudstack.apache.org
> Subject: RE: Template Question
> 
> I am also seeing it.
> 
> -Koushik
> 
> > -Original Message-
> > From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com]
> > Sent: Wednesday, July 17, 2013 9:22 PM
> > To: dev@cloudstack.apache.org
> > Subject: Template Question
> >
> > Hi,
> >
> > I've noticed recently on XenServer when SSVM and CPVM are deployed
> > that Template routing-1 appears twice in my Disks list (it used to
> > appear only once).
> >
> > Is this change in behavior expected?
> >
> > Thanks!
> >
> > --
> > *Mike Tutkowski*
> > *Senior CloudStack Developer, SolidFire Inc.*
> > e: mike.tutkow...@solidfire.com
> > o: 303.746.7302
> > Advancing the way the world uses the
> > cloud
> > *(tm)*

Review Request 12719: CLOUDSTACK-3634: Adding router.template.xen/kvm/hyperv/kvm/lxc in upgrade setup

[Harikrishna Patnala]

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

Review request for cloudstack, Abhinandan Prateek and Kishan Kavala.


Bugs: CLOUDSTACK-3634


Repository: cloudstack-git


Description
---

CLOUDSTACK-3634: Adding router.template.xen/kvm/hyperv/kvm/lxc in upgrade setup

Presently during system vm template upgrade from 4.1 to 4.2 takes care of 
inserting these parameters.
Adding now in 4.1 to 4.2 sql file so that normal developer upgrade does not 
fail in deploying router.


Diffs
-

  engine/schema/src/com/cloud/upgrade/dao/Upgrade410to420.java e37ccd5 
  setup/db/db/schema-410to420.sql 40e3d2b 

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


Testing
---


Thanks,

Harikrishna Patnala

Review Request 12720: CLOUDSTACK: 3382 Unable to Migrate VM's If the hosts are implicitly or explicitly dedicated.

[Saksham Srivastava]

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

Review request for cloudstack and Devdeep Singh.


Bugs: 3382


Repository: cloudstack-git


Description
---

Allow root admin to migrate VMs across dedicated hosts.
Generate alerts for each migration performed between dedicated hosts.
Alerts are generated for VM migration between:
1) Source host is dedicated and destination host is not.
2) Source host is not dedicated and destination host is dedicated.
3) Both hosts are dedicated.
Alerts are now generated for both explicit and implicit dedication.


Diffs
-

  server/src/com/cloud/deploy/dao/PlannerHostReservationDao.java 69118f1 
  server/src/com/cloud/deploy/dao/PlannerHostReservationDaoImpl.java 41e0964 
  server/src/com/cloud/vm/UserVmManagerImpl.java 9968690 

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


Testing
---

Migrated VMs across explicitly dedicated hosts and alerts are generated.
Migrated VMs across implicitly dedicated hosts and alerts are generated.
 


Thanks,

Saksham Srivastava

Re: Review Request 12720: CLOUDSTACK: 3382 Unable to Migrate VM's If the hosts are implicitly or explicitly dedicated.

[Prasanna Santhanam]

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


Do you think you can add a integration test to test_explicit_dedication.py for 
this failure? That would be really useful to catch this part of tricky code

- Prasanna Santhanam


On July 18, 2013, 11:06 a.m., Saksham Srivastava wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/12720/
> ---
> 
> (Updated July 18, 2013, 11:06 a.m.)
> 
> 
> Review request for cloudstack and Devdeep Singh.
> 
> 
> Bugs: 3382
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Allow root admin to migrate VMs across dedicated hosts.
> Generate alerts for each migration performed between dedicated hosts.
> Alerts are generated for VM migration between:
> 1) Source host is dedicated and destination host is not.
> 2) Source host is not dedicated and destination host is dedicated.
> 3) Both hosts are dedicated.
> Alerts are now generated for both explicit and implicit dedication.
> 
> 
> Diffs
> -
> 
>   server/src/com/cloud/deploy/dao/PlannerHostReservationDao.java 69118f1 
>   server/src/com/cloud/deploy/dao/PlannerHostReservationDaoImpl.java 41e0964 
>   server/src/com/cloud/vm/UserVmManagerImpl.java 9968690 
> 
> Diff: https://reviews.apache.org/r/12720/diff/
> 
> 
> Testing
> ---
> 
> Migrated VMs across explicitly dedicated hosts and alerts are generated.
> Migrated VMs across implicitly dedicated hosts and alerts are generated.
>  
> 
> 
> Thanks,
> 
> Saksham Srivastava
> 
>

Re: Review Request 11782: (CLOUDSTACK-1301) VM Disk I/O Throttling

[ASF Subversion and Git Services]

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


Commit 27b5085542cbc881ea1847e9b894d7723dc869db in branch refs/heads/4.2 from 
Wei Zhou
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=27b5085 ]

CLOUDSTACK-1301: fixed issues and add fields descriptions for disk I/O 
throttling


- ASF Subversion and Git Services


On June 17, 2013, 12:03 p.m., Wei Zhou wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/11782/
> ---
> 
> (Updated June 17, 2013, 12:03 p.m.)
> 
> 
> Review request for cloudstack, John Burwell and Wido den Hollander.
> 
> 
> Bugs: CLOUDSTACK-1301
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> The patch for VM Disk I/O throttling based on commit 
> 3f3c6aa35f64c4129c203d54840524e6aa2c4621
> 
> 
> Diffs
> -
> 
>   api/src/com/cloud/agent/api/to/VolumeTO.java 4cbe82b 
>   api/src/com/cloud/offering/DiskOffering.java dd77c70 
>   api/src/com/cloud/vm/DiskProfile.java e3a3386 
>   api/src/org/apache/cloudstack/api/ApiConstants.java ab1402c 
>   
> api/src/org/apache/cloudstack/api/command/admin/offering/CreateDiskOfferingCmd.java
>  aa11599 
>   
> api/src/org/apache/cloudstack/api/command/admin/offering/CreateServiceOfferingCmd.java
>  4c54a4e 
>   api/src/org/apache/cloudstack/api/response/DiskOfferingResponse.java 
> 377e66e 
>   api/src/org/apache/cloudstack/api/response/ServiceOfferingResponse.java 
> 31533f8 
>   api/src/org/apache/cloudstack/api/response/VolumeResponse.java 21d7d1a 
>   client/WEB-INF/classes/resources/messages.properties 2b17359 
>   core/src/com/cloud/agent/api/AttachVolumeCommand.java 302b8f8 
>   engine/schema/src/com/cloud/storage/DiskOfferingVO.java 909d7fe 
>   
> plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/LibvirtComputingResource.java
>  f90edd8 
>   
> plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/LibvirtDomainXMLParser.java
>  b8645e1 
>   
> plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/LibvirtVMDef.java
>  e91e347 
>   server/src/com/cloud/api/query/dao/DiskOfferingJoinDaoImpl.java 283181f 
>   server/src/com/cloud/api/query/dao/ServiceOfferingJoinDaoImpl.java 56e4d0a 
>   server/src/com/cloud/api/query/dao/VolumeJoinDaoImpl.java e27e2d9 
>   server/src/com/cloud/api/query/vo/DiskOfferingJoinVO.java 6d3cdcb 
>   server/src/com/cloud/api/query/vo/ServiceOfferingJoinVO.java e87a101 
>   server/src/com/cloud/api/query/vo/VolumeJoinVO.java 6ef8c91 
>   server/src/com/cloud/configuration/Config.java 5ee0fad 
>   server/src/com/cloud/configuration/ConfigurationManager.java 8db037b 
>   server/src/com/cloud/configuration/ConfigurationManagerImpl.java 131d340 
>   server/src/com/cloud/storage/StorageManager.java d49a7f8 
>   server/src/com/cloud/storage/StorageManagerImpl.java d38b35e 
>   server/src/com/cloud/storage/VolumeManagerImpl.java 4297efb 
>   server/src/com/cloud/test/DatabaseConfig.java 70c8178 
>   server/test/com/cloud/vpc/MockConfigurationManagerImpl.java 21b3590 
>   setup/db/db/schema-410to420.sql bcfbcc9 
>   ui/dictionary.jsp a5f0662 
>   ui/scripts/configuration.js cadde8c 
> 
> Diff: https://reviews.apache.org/r/11782/diff/
> 
> 
> Testing
> ---
> 
> testing ok.
> 
> 
> Thanks,
> 
> Wei Zhou
> 
>

Meet up on July 20th - Hyderabad, India

[Nitin Mehta]

There is an upcoming meet up on July 20th at Hyderabad, India
There will be talks on CS architecture and hacking with devcloud.
Detailed info @ 
http://www.meetup.com/CloudStack-Hyderabad-Group/events/125208462/

Thanks,
-Nitin

Re: [jira] [Closed] (CLOUDSTACK-3636) [Automation]Fix iintegration.component.test_accounts.TestServiceOfferingHierarchy.test_01_service_offering_hierarchy script

[Prasanna Santhanam]

Can you apply the fixes on 4.2 as well?

On Thu, Jul 18, 2013 at 11:38:49AM +, Sailaja Mada (JIRA) wrote:
> 
>  [ 
> https://issues.apache.org/jira/browse/CLOUDSTACK-3636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
>  ]
> 
> Sailaja Mada closed CLOUDSTACK-3636.
> 
> 
> Resolution: Fixed
> 
> Failure Root Cause:
> 
> List service offerings API response will be none as there are no offerings 
> for this domain . But we are looking for list of offerings.
> 
> Fix:
> 
> Add condition to look for empty response.
> 
> 
> > [Automation]Fix 
> > iintegration.component.test_accounts.TestServiceOfferingHierarchy.test_01_service_offering_hierarchy
> >  script
> > ---
> >
> > Key: CLOUDSTACK-3636
> > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3636
> > Project: CloudStack
> >  Issue Type: Bug
> >  Security Level: Public(Anyone can view this level - this is the 
> > default.) 
> >  Components: Automation
> >Affects Versions: 4.2.0
> >Reporter: Sailaja Mada
> >Assignee: Sailaja Mada
> >Priority: Minor
> > Fix For: 4.2.0
> >
> >
> > Observation:
> > Regression test failed while listing private service offerings added to a 
> > domain
> > Scenario: 
> > When we look for private service offerings it should not list the service 
> > offerings of some other domain. 
> > Failure Root Cause: 
> > This API response will be none as there are no offerings for this domain . 
> > But we are looking for list of offerings.  
> > Fix:
> > Add condition to look for empty response. 
> > ==
> > Failed
> > integration.component.test_accounts.TestServiceOfferingHierarchy.test_01_service_offering_hierarchy
> >  (from nosetests)
> > Failing for the past 9 builds (Since Unstable#47 )
> > Took 0.23 sec.
> > add description
> > Error Message
> > Check List Service Offerings for a valid response
> > Stacktrace
> > Traceback (most recent call last):
> >   File "/usr/local/lib/python2.7/unittest/case.py", line 318, in run
> > testMethod()
> >   File "/root/cloudstack/test/integration/component/test_accounts.py", line 
> > 827, in test_01_service_offering_hierarchy
> > "Check List Service Offerings for a valid response"
> >   File "/usr/local/lib/python2.7/unittest/case.py", line 494, in assertEqual
> > assertion_func(first, second, msg=msg)
> >   File "/usr/local/lib/python2.7/unittest/case.py", line 487, in 
> > _baseAssertEqual
> > raise self.failureException(msg)
> > AssertionError: Check List Service Offerings for a valid response
> 
> --
> This message is automatically generated by JIRA.
> If you think it was sent incorrectly, please contact your JIRA administrators
> For more information on JIRA, see: http://www.atlassian.com/software/jira

-- 
Prasanna.,


Powered by BigRock.com

Re: Review Request 12720: CLOUDSTACK: 3382 Unable to Migrate VM's If the hosts are implicitly or explicitly dedicated.

[Devdeep Singh]

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


Few comments:
1. You need to handle when migration with storage is taking place. That isn't 
handled right now.
2. The check to raise alerts should be abstracted into a function.
3. In case of implicit the scenario when a vm is migrated from a dedicated host 
of one account to dedicated host of another account isn't handled.

- Devdeep Singh


On July 18, 2013, 11:06 a.m., Saksham Srivastava wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/12720/
> ---
> 
> (Updated July 18, 2013, 11:06 a.m.)
> 
> 
> Review request for cloudstack and Devdeep Singh.
> 
> 
> Bugs: 3382
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Allow root admin to migrate VMs across dedicated hosts.
> Generate alerts for each migration performed between dedicated hosts.
> Alerts are generated for VM migration between:
> 1) Source host is dedicated and destination host is not.
> 2) Source host is not dedicated and destination host is dedicated.
> 3) Both hosts are dedicated.
> Alerts are now generated for both explicit and implicit dedication.
> 
> 
> Diffs
> -
> 
>   server/src/com/cloud/deploy/dao/PlannerHostReservationDao.java 69118f1 
>   server/src/com/cloud/deploy/dao/PlannerHostReservationDaoImpl.java 41e0964 
>   server/src/com/cloud/vm/UserVmManagerImpl.java 9968690 
> 
> Diff: https://reviews.apache.org/r/12720/diff/
> 
> 
> Testing
> ---
> 
> Migrated VMs across explicitly dedicated hosts and alerts are generated.
> Migrated VMs across implicitly dedicated hosts and alerts are generated.
>  
> 
> 
> Thanks,
> 
> Saksham Srivastava
> 
>

Auto format javascript

[Ian Duffy]

Hi,

Anybody have suggestions for automatically formatting javascript?

Just going through some of the UI stuff and noticed the indentation is a
bit all over the place.

Thanks,
Ian

RE: Review Request 12510: CLOUDSTACK 3476 : deleteDomain api should fail when release dedicated resource to that domain fails:

[Saksham Srivastava]

The fix should qualify for 4.1.1

Thanks,
Saksham

-Original Message-
From: Musayev, Ilya [mailto:imusa...@webmd.net] 
Sent: Thursday, July 18, 2013 6:41 AM
To: dev@cloudstack.apache.org; Alena Prokharchyk; Devdeep Singh
Cc: Saksham Srivastava; cloudstack
Subject: RE: Review Request 12510: CLOUDSTACK 3476 : deleteDomain api should 
fail when release dedicated resource to that domain fails:

Does this fix qualify for 4.1.1?

> -Original Message-
> From: Alena Prokharchyk [mailto:nore...@reviews.apache.org] On Behalf 
> Of Alena Prokharchyk
> Sent: Wednesday, July 17, 2013 2:26 PM
> To: Devdeep Singh; Alena Prokharchyk
> Cc: Saksham Srivastava; cloudstack
> Subject: Re: Review Request 12510: CLOUDSTACK 3476 : deleteDomain api 
> should fail when release dedicated resource to that domain fails:
> 
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/12510/#review23314
> ---
> 
> Ship it!
> 
> 
> Ship It!
> 
> - Alena Prokharchyk
> 
> 
> On July 13, 2013, 6 a.m., Saksham Srivastava wrote:
> >
> > ---
> > This is an automatically generated e-mail. To reply, visit:
> > https://reviews.apache.org/r/12510/
> > ---
> >
> > (Updated July 13, 2013, 6 a.m.)
> >
> >
> > Review request for cloudstack, Alena Prokharchyk and Devdeep Singh.
> >
> >
> > Bugs: 3476
> >
> >
> > Repository: cloudstack-git
> >
> >
> > Description
> > ---
> >
> > In case the release dedicate resource fails, deletion of domain 
> > should not
> happen.
> > Whenever deleting a domain all the resources dedicated to it must be
> released of dedication and moved to shared pool.
> > Currently even if release API fails the deleteDomain API is executed
> successfully.
> >
> > Further if there are dedicated resources to a domiain and cleanup is 
> > not
> true, resources should not be released.
> > Added checks to prohibit this behaviour.
> >
> >
> > Diffs
> > -
> >
> >   server/src/com/cloud/user/DomainManagerImpl.java aad5787
> >
> > Diff: https://reviews.apache.org/r/12510/diff/
> >
> >
> > Testing
> > ---
> >
> > If domain has dedicated resources, cleanup=true will release 
> > dedication
> and delete the domain.
> > cleanup=false will not release dedication and will not delete the domain.
> >
> >
> > Thanks,
> >
> > Saksham Srivastava
> >
> >

Re: Auto format javascript

[Pranav Saxena]

+1 .

 I was thinking of proposing this thing too . JS code is a little messed up
probably due to different editor settings being used in different
environments by different people . One tool which I have used is
http://jsbeautifier.org/ . But somebody would have to make the effort to
manually copy the js files , auto-format them and then re-copy them back
and then everyone who contributes to js code should follow the "auto-format
Covention".


On Thu, Jul 18, 2013 at 6:13 PM, Ian Duffy  wrote:

> Hi,
>
> Anybody have suggestions for automatically formatting javascript?
>
> Just going through some of the UI stuff and noticed the indentation is a
> bit all over the place.
>
> Thanks,
> Ian
>

Re: Review Request 12700: Fix for CLOUDSTACK-3596 to include domain id

[ASF Subversion and Git Services]

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


Commit 3385b200faa929d2027c5e4743e58271f4d7ad56 in branch refs/heads/4.2 from 
sailajam
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=3385b20 ]

CLOUDSTACK-3596: Domain ID missing to deploy VM request . Included Domain id
(cherry picked from commit f5bd253b2b8d50bb42ce8a85b4d1db5b8e729b41)


- ASF Subversion and Git Services


On July 17, 2013, 6:10 p.m., sailaja mada wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/12700/
> ---
> 
> (Updated July 17, 2013, 6:10 p.m.)
> 
> 
> Review request for cloudstack and Prasanna Santhanam.
> 
> 
> Bugs: CLOUDSTACK-3596
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Deploy VM request is sent without providing the Domain id . Cloudstack 
> mandates to provide domain id along with account name.
> 
> Fix is to include domain id to resolve script failure (Execute cmd: 
> deployvirtualmachine failed, due to: errorCode: 431, errorText:Account must 
> be specified with domainId parameter)
> 
> 
> Diffs
> -
> 
>   test/integration/component/test_accounts.py 65c0c6f 
> 
> Diff: https://reviews.apache.org/r/12700/diff/
> 
> 
> Testing
> ---
> 
> Tested with the change. Now test is passed.
> 
> 
> Thanks,
> 
> sailaja mada
> 
>

Re: deleteAffinityGroup API

[Prasanna Santhanam]

On Thu, Jul 18, 2013 at 02:17:46PM +0530, Prasanna Santhanam wrote:
> On Thu, Jul 18, 2013 at 07:14:42AM +, Prachi Damle wrote:
> > Account and domainId are not required parameters of this API. It
> > works fine with just an id too.
> > 
> > Account and domain will be used if delete is called providing a name
> > of the group instead of id, say by an admin for a regular user's
> > group.
> > 
> 
> Thanks Prachi - I think it is related to the recent changes in
> CallContext that is making the user system for the API call preventing
> it from deleteing the aff.group with just an id. Filed a bug for it.

Ok - Alex mentioned the bug is 'Not a Problem'. So it's only the
background CS workers which use the CallContext. But the affinity
group is still failing to delete using the id. 

-- 
Prasanna.,


Powered by BigRock.com

Re: Auto format javascript

[Ian Duffy]

Should be able to format them all at once using the node module of it
Will install it and submit a patch over the next few minutes.

Using something like http://editorconfig.org/ to keep styling the same for
html/css/js based stuff might not be a bad idea.

That site you recommended has a sublime text plugin which seems to work a
charm.

Re: Auto format javascript

[Pranav Saxena]

Awesome . Yeah it's an awesome auto-formatting tool , which I have used in
the past !!:)


On Thu, Jul 18, 2013 at 6:41 PM, Ian Duffy  wrote:

> Should be able to format them all at once using the node module of it
> Will install it and submit a patch over the next few minutes.
>
> Using something like http://editorconfig.org/ to keep styling the same for
> html/css/js based stuff might not be a bad idea.
>
> That site you recommended has a sublime text plugin which seems to work a
> charm.
>

Re: Review Request 12277: Add VHDX image support

[Devdeep Singh]

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

Ship it!


Committed to master with commit id 876a7b3361a17bc16b1342fdebbff0f0306674a6.

- Devdeep Singh


On July 15, 2013, 9:12 a.m., Donal Lafferty wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/12277/
> ---
> 
> (Updated July 15, 2013, 9:12 a.m.)
> 
> 
> Review request for cloudstack, Devdeep Singh and edison su.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Add VHDX image support, which is missing from DiskFormat class, revised 
> ImageFormat interface, StorageManager implementation, and the application 
> component spec.
> 
> NB:  applicationContext.xml.in can only be checked at runtime.  A non-Hyper-V 
> user should verify that it does not break anything.
> 
> 
> Diffs
> -
> 
>   client/tomcatconf/applicationContext.xml.in 
> 14255c1e7a50719757ffa4f3d6f27eaeacfde917 
>   
> engine/api/src/org/apache/cloudstack/engine/subsystem/api/storage/disktype/DiskFormat.java
>  6be7a6bb49eb534b56cb9da9c88da5ffb7d00fa4 
>   
> engine/api/src/org/apache/cloudstack/engine/subsystem/api/storage/disktype/VHDX.java
>  PRE-CREATION 
>   engine/storage/src/org/apache/cloudstack/storage/image/format/VHDX.java 
> PRE-CREATION 
>   server/src/com/cloud/storage/StorageManagerImpl.java 
> d9ef853a743c1bfbb1e8a3aa911f1f857985b15a 
> 
> Diff: https://reviews.apache.org/r/12277/diff/
> 
> 
> Testing
> ---
> 
> Compiles and runs when using Hyper-V plugin.
> 
> Has not been run in non-Hyper-V scenarios.
> 
> 
> Thanks,
> 
> Donal Lafferty
> 
>

Re: Review Request 12277: Add VHDX image support

[Devdeep Singh]

> On July 18, 2013, 1:36 p.m., Devdeep Singh wrote:
> > Committed to master with commit id 876a7b3361a17bc16b1342fdebbff0f0306674a6.

Kindly close the request.


- Devdeep


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


On July 15, 2013, 9:12 a.m., Donal Lafferty wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/12277/
> ---
> 
> (Updated July 15, 2013, 9:12 a.m.)
> 
> 
> Review request for cloudstack, Devdeep Singh and edison su.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Add VHDX image support, which is missing from DiskFormat class, revised 
> ImageFormat interface, StorageManager implementation, and the application 
> component spec.
> 
> NB:  applicationContext.xml.in can only be checked at runtime.  A non-Hyper-V 
> user should verify that it does not break anything.
> 
> 
> Diffs
> -
> 
>   client/tomcatconf/applicationContext.xml.in 
> 14255c1e7a50719757ffa4f3d6f27eaeacfde917 
>   
> engine/api/src/org/apache/cloudstack/engine/subsystem/api/storage/disktype/DiskFormat.java
>  6be7a6bb49eb534b56cb9da9c88da5ffb7d00fa4 
>   
> engine/api/src/org/apache/cloudstack/engine/subsystem/api/storage/disktype/VHDX.java
>  PRE-CREATION 
>   engine/storage/src/org/apache/cloudstack/storage/image/format/VHDX.java 
> PRE-CREATION 
>   server/src/com/cloud/storage/StorageManagerImpl.java 
> d9ef853a743c1bfbb1e8a3aa911f1f857985b15a 
> 
> Diff: https://reviews.apache.org/r/12277/diff/
> 
> 
> Testing
> ---
> 
> Compiles and runs when using Hyper-V plugin.
> 
> Has not been run in non-Hyper-V scenarios.
> 
> 
> Thanks,
> 
> Donal Lafferty
> 
>

Re: [DISCUSS] Upgrade path to ACS 4.2 from CCP

[Chip Childers]

On Wed, Jul 17, 2013 at 11:43:49PM +, Animesh Chaturvedi wrote:
> 
> Folks
> 
> We have an upgrade path from CCP 3.0.2 to 4.0 ACS and since then we have 
> diverged. I would like to propose adding upgrade path from later CCP versions 
> to ACS 4.2 which provides customers the choice to move to ACS from CCP and 
> also brings CCP closer to upstream ACS releases.
> 
> The proposed upgrade paths are CCP3.0.4, CCP3.0.5, CCP3.06, CCP3.0.7 to 
> ACS4.2. Please provide your feedback.
> 
> Thanks
> Animesh
> 
> 
> 
>

Generally...  +1000.  I think that this is a wonderful idea.

I have a couple of thoughts:  

We will really need to implement the "checkpoint"
version concept that Hugo proposed earlier [1].  The reason that I say
this, is that the source and binaries for CCP aren't available to
non-customers of citrix / non-citrix devs.  

I obviously assume that Citrix is officially OK with this (and you are
basically representing that to the list).  Given that "ok", I further
assume that Citrix employeed engineers would do the work (since they
have access to the CCP releases).

Once the upgrades are in ACS, we would want to reduce the testing effort
around them going forward by ensuring that the targeted ACS release that
we test the upgrades to will be one of the "checkpoint" releases per
Hugo's proposal.

Last thought...  this doesn't seem like a 4.2 change to me.  Isn't it
too late to deal with testing it now?  If not, and there are people
ready to roll, then no worries.  I'm just pointing out what may be
obvious:  you've hit feature freeze, and this seems like a significant
amount of work.

-chip

[1] http://markmail.org/thread/p34jbalr25pwocez

Re: [DISCUSS] Upgrade path to ACS 4.2 from CCP

[Wei ZHOU]

+1
I received the question from many clients about how to upgrade CCP 3.0.6 to
ACS 4.1/4.2.


2013/7/18 Animesh Chaturvedi 

>
> Folks
>
> We have an upgrade path from CCP 3.0.2 to 4.0 ACS and since then we have
> diverged. I would like to propose adding upgrade path from later CCP
> versions to ACS 4.2 which provides customers the choice to move to ACS from
> CCP and also brings CCP closer to upstream ACS releases.
>
> The proposed upgrade paths are CCP3.0.4, CCP3.0.5, CCP3.06, CCP3.0.7 to
> ACS4.2. Please provide your feedback.
>
> Thanks
> Animesh
>
>
>
>

Review Request 12721: Formatting of CSS and JS files

[Ian Duffy]

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

Review request for cloudstack, Abhinandan Prateek, Pranav Saxena, and Sebastien 
Goasguen.


Repository: cloudstack-git


Description
---

Format CSS and JS files using js-beautifier as discussed on the mailing list.


Diffs
-

  ui/css/cloudstack3-ie7.css 114e9c0 
  ui/css/cloudstack3.css 4545e96 
  ui/css/cloudstack3.ja.css 85c23a1 
  ui/scripts/accounts.js bad8435 
  ui/scripts/affinity.js a9c6695 
  ui/scripts/autoscaler.js 15a9dac 
  ui/scripts/cloud.core.callbacks.js 6eb7644 
  ui/scripts/cloudStack.js c0ff7f2 
  ui/scripts/configuration.js 8bc40d6 
  ui/scripts/dashboard.js e8ab6c5 
  ui/scripts/docs.js c8ef0d9 
  ui/scripts/domains.js 01f4236 
  ui/scripts/events.js bd50887 
  ui/scripts/globalSettings.js 1ae73b7 
  ui/scripts/installWizard.js 46769fa 
  ui/scripts/instanceWizard.js ff130d3 
  ui/scripts/instances.js 9b27d93 
  ui/scripts/lbStickyPolicy.js c0e2bfa 
  ui/scripts/network.js 95a93bc 
  ui/scripts/plugins.js 3c5bc0f 
  ui/scripts/projects.js ea1e6db 
  ui/scripts/regions.js 4be600f 
  ui/scripts/sharedFunctions.js a9f833c 
  ui/scripts/storage.js ad0965a 
  ui/scripts/system.js 3038a8a 
  ui/scripts/templates.js dbb0083 
  ui/scripts/ui-custom/affinity.js 1a23ff7 
  ui/scripts/ui-custom/autoscaler.js 119b672 
  ui/scripts/ui-custom/dashboard.js 6d92318 
  ui/scripts/ui-custom/enableStaticNAT.js 1b2bf7b 
  ui/scripts/ui-custom/granularSettings.js 02d5c1f 
  ui/scripts/ui-custom/healthCheck.js 4b42fa7 
  ui/scripts/ui-custom/installWizard.js c53a642 
  ui/scripts/ui-custom/instanceWizard.js 31b4baa 
  ui/scripts/ui-custom/ipRules.js 34b2398 
  ui/scripts/ui-custom/login.js 0dbbf82 
  ui/scripts/ui-custom/physicalResources.js 5173172 
  ui/scripts/ui-custom/pluginListing.js 3dcce98 
  ui/scripts/ui-custom/projectSelect.js aef49ed 
  ui/scripts/ui-custom/projects.js f1f9eba 
  ui/scripts/ui-custom/recurringSnapshots.js 985f369 
  ui/scripts/ui-custom/regions.js 9fc36f3 
  ui/scripts/ui-custom/securityRules.js 2e2c9ac 
  ui/scripts/ui-custom/uploadVolume.js 996d8ac 
  ui/scripts/ui-custom/vpc.js 4edccf1 
  ui/scripts/ui-custom/zoneChart.js 5d4e0c0 
  ui/scripts/ui-custom/zoneFilter.js 9e6a493 
  ui/scripts/ui-custom/zoneWizard.js 877dbc0 
  ui/scripts/ui/core.js 18c3363 
  ui/scripts/ui/dialog.js 7f82eea 
  ui/scripts/ui/events.js bd609d2 
  ui/scripts/ui/utils.js 39ef3e3 
  ui/scripts/ui/widgets/cloudBrowser.js 9a56bb3 
  ui/scripts/ui/widgets/dataTable.js 1b3ea82 
  ui/scripts/ui/widgets/detailView.js 0bccef5 
  ui/scripts/ui/widgets/listView.js bc68a72 
  ui/scripts/ui/widgets/multiEdit.js 08bd0bf 
  ui/scripts/ui/widgets/notifications.js 0299603 
  ui/scripts/ui/widgets/overlay.js ecf12e6 
  ui/scripts/ui/widgets/tagger.js 9af6fb7 
  ui/scripts/ui/widgets/toolTip.js 6967acc 
  ui/scripts/ui/widgets/treeView.js fa1ceb6 
  ui/scripts/vm_snapshots.js c50c7e1 
  ui/scripts/vpc.js e90d8a7 
  ui/scripts/zoneWizard.js 04687fe 

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


Testing
---

Compiled... previewed in browser, navigated the pages, checked everything 
looked normal.


Thanks,

Ian Duffy

Re: Review Request 11479: SolidFire storage plug-in and enhancements to the storage framework and GUI

[John Burwell]

> On May 31, 2013, 8:32 p.m., Wei Zhou wrote:
> > Mike,
> > 
> > I think it is better to create a table for SolidFire instead of changing 
> > disk_offering table.
> > It is not a good idea to change disk_offering for a specific vendor.
> > You can have a look at what nicira did in the past, maybe it helps you.
> > 
> > 
> > -Wei

+1 to this notion.  Could we achieve the same goal by adding a column to the 
disk_offering table that contained a JSON string of extended, vendor specific 
attributes?  On the Java interface side, the JSON document would represented as 
a Map from the appropriate interface with driver 
implementations responsible for validating their contents.  This approach would 
reduce the situations where a driver would require schema modifications.


- John


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


On June 21, 2013, 4:35 p.m., Mike Tutkowski wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/11479/
> ---
> 
> (Updated June 21, 2013, 4:35 p.m.)
> 
> 
> Review request for cloudstack, edison su and John Burwell.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> This patch implements a storage plug-in for SolidFire. The plug-in is based 
> on the new storage framework that went in with 4.2, as well.
> 
> In addition, there are GUI (and related) changes to enable admins and end 
> users to specify a Min, Max, and Burst number of IOPS for a Disk Offering. 
> These fields (although optional) tend to follow the pattern previously 
> established for the Disk Size field.
> 
> Also, the storage framework itself has been enhanced. For example, it now 
> supports creating and deleting storage repositories as is necessary for a 
> dynamic type of zone-wide primary storage (such as the SolidFire plug-in is).
> 
> The desired behavior of the software is as such:
> 
> * Allow an admin to invoke the CloudStack API to add Primary Storage based on 
> the SolidFire plug-in.
> 
> * Allow an admin to create a Disk Offering that specifies a Min, Max, and 
> Burst number of IOPS or allows the admin to pass this ability on to the end 
> user.
> 
> * Allow an end user to execute such a Disk Offering. As is the case for any 
> Disk Offering, this leads to the creation of a row in the volumes table.
> 
> * Allow an end user to attach the resultant volume (noted in the DB) to a VM. 
> The storage framework invokes logic in the plug-in and the plug-in creates a 
> volume on its SAN with the correct size and IOPS values. The agent software 
> for XenServer detects that such an attach is being requested and creates a 
> Storage Repository (and single VDI within the SR) based on the storage IP 
> address of the SAN and the IQN of the volume. The VDI is then hooked up to 
> the VM.
> 
> * Allow an end user to detach the volume. This leads to the destruction of 
> the SR, but the SAN volume remains intact and can be reattached later to any 
> VM running in a XenServer resource pool in the zone.
> 
> * Allow an end user to delete the volume. This leads to the volume being 
> deleted on the SAN and being marked in the CloudStack DB as deleted.
> 
> 
> Diffs
> -
> 
>   api/src/com/cloud/offering/DiskOffering.java ae4528c 
>   api/src/com/cloud/storage/StoragePool.java 8b95383 
>   api/src/com/cloud/storage/Volume.java 4903594 
>   api/src/org/apache/cloudstack/api/ApiConstants.java 1704ca3 
>   
> api/src/org/apache/cloudstack/api/command/admin/offering/CreateDiskOfferingCmd.java
>  a2c5f77 
>   
> api/src/org/apache/cloudstack/api/command/admin/storage/CreateStoragePoolCmd.java
>  74eb2b9 
>   api/src/org/apache/cloudstack/api/command/user/volume/CreateVolumeCmd.java 
> 86a494b 
>   api/src/org/apache/cloudstack/api/response/DiskOfferingResponse.java 
> 35cf21a 
>   api/src/org/apache/cloudstack/api/response/StoragePoolResponse.java 965407d 
>   api/src/org/apache/cloudstack/api/response/VolumeResponse.java e3463bd 
>   client/WEB-INF/classes/resources/messages.properties a0a36c8 
>   client/pom.xml ab758eb 
>   client/tomcatconf/applicationContext.xml.in 049e483 
>   core/src/com/cloud/agent/api/AttachVolumeAnswer.java b377b7c 
>   core/src/com/cloud/agent/api/AttachVolumeCommand.java 2658262 
>   core/test/org/apache/cloudstack/api/agent/test/AttachVolumeAnswerTest.java 
> 251a6cb 
>   core/test/org/apache/cloudstack/api/agent/test/AttachVolumeCommandTest.java 
> 1ec416a 
>   
> core/test/org/apache/cloudstack/api/agent/test/BackupSnapshotCommandTest.java 
> 44d53aa 
>   core/test/org/apache/cloudstack/api/agent/test/SnapshotCommandTest.java 
> c2d69c0 
>   core/test/src/com/cloud/agent/api/test/ResizeVolumeCommandTest.java 02085f5 
>   
> engine/

Re: Review Request 11479: SolidFire storage plug-in and enhancements to the storage framework and GUI

[John Burwell]

> On June 28, 2013, 3:42 p.m., John Burwell wrote:
> > api/src/com/cloud/offering/DiskOffering.java, line 60
> > 
> >
> > When would it be valid for the value of this property to be null?  
> > Seems like it should be boolean, not Boolean.
> 
> Mike Tutkowski wrote:
> null is used if this feature is not in use.

What is the difference between false and null?


- John


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


On June 21, 2013, 4:35 p.m., Mike Tutkowski wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/11479/
> ---
> 
> (Updated June 21, 2013, 4:35 p.m.)
> 
> 
> Review request for cloudstack, edison su and John Burwell.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> This patch implements a storage plug-in for SolidFire. The plug-in is based 
> on the new storage framework that went in with 4.2, as well.
> 
> In addition, there are GUI (and related) changes to enable admins and end 
> users to specify a Min, Max, and Burst number of IOPS for a Disk Offering. 
> These fields (although optional) tend to follow the pattern previously 
> established for the Disk Size field.
> 
> Also, the storage framework itself has been enhanced. For example, it now 
> supports creating and deleting storage repositories as is necessary for a 
> dynamic type of zone-wide primary storage (such as the SolidFire plug-in is).
> 
> The desired behavior of the software is as such:
> 
> * Allow an admin to invoke the CloudStack API to add Primary Storage based on 
> the SolidFire plug-in.
> 
> * Allow an admin to create a Disk Offering that specifies a Min, Max, and 
> Burst number of IOPS or allows the admin to pass this ability on to the end 
> user.
> 
> * Allow an end user to execute such a Disk Offering. As is the case for any 
> Disk Offering, this leads to the creation of a row in the volumes table.
> 
> * Allow an end user to attach the resultant volume (noted in the DB) to a VM. 
> The storage framework invokes logic in the plug-in and the plug-in creates a 
> volume on its SAN with the correct size and IOPS values. The agent software 
> for XenServer detects that such an attach is being requested and creates a 
> Storage Repository (and single VDI within the SR) based on the storage IP 
> address of the SAN and the IQN of the volume. The VDI is then hooked up to 
> the VM.
> 
> * Allow an end user to detach the volume. This leads to the destruction of 
> the SR, but the SAN volume remains intact and can be reattached later to any 
> VM running in a XenServer resource pool in the zone.
> 
> * Allow an end user to delete the volume. This leads to the volume being 
> deleted on the SAN and being marked in the CloudStack DB as deleted.
> 
> 
> Diffs
> -
> 
>   api/src/com/cloud/offering/DiskOffering.java ae4528c 
>   api/src/com/cloud/storage/StoragePool.java 8b95383 
>   api/src/com/cloud/storage/Volume.java 4903594 
>   api/src/org/apache/cloudstack/api/ApiConstants.java 1704ca3 
>   
> api/src/org/apache/cloudstack/api/command/admin/offering/CreateDiskOfferingCmd.java
>  a2c5f77 
>   
> api/src/org/apache/cloudstack/api/command/admin/storage/CreateStoragePoolCmd.java
>  74eb2b9 
>   api/src/org/apache/cloudstack/api/command/user/volume/CreateVolumeCmd.java 
> 86a494b 
>   api/src/org/apache/cloudstack/api/response/DiskOfferingResponse.java 
> 35cf21a 
>   api/src/org/apache/cloudstack/api/response/StoragePoolResponse.java 965407d 
>   api/src/org/apache/cloudstack/api/response/VolumeResponse.java e3463bd 
>   client/WEB-INF/classes/resources/messages.properties a0a36c8 
>   client/pom.xml ab758eb 
>   client/tomcatconf/applicationContext.xml.in 049e483 
>   core/src/com/cloud/agent/api/AttachVolumeAnswer.java b377b7c 
>   core/src/com/cloud/agent/api/AttachVolumeCommand.java 2658262 
>   core/test/org/apache/cloudstack/api/agent/test/AttachVolumeAnswerTest.java 
> 251a6cb 
>   core/test/org/apache/cloudstack/api/agent/test/AttachVolumeCommandTest.java 
> 1ec416a 
>   
> core/test/org/apache/cloudstack/api/agent/test/BackupSnapshotCommandTest.java 
> 44d53aa 
>   core/test/org/apache/cloudstack/api/agent/test/SnapshotCommandTest.java 
> c2d69c0 
>   core/test/src/com/cloud/agent/api/test/ResizeVolumeCommandTest.java 02085f5 
>   
> engine/api/src/org/apache/cloudstack/engine/subsystem/api/storage/DataStoreDriver.java
>  cf5759b 
>   
> engine/api/src/org/apache/cloudstack/engine/subsystem/api/storage/PrimaryDataStoreParameters.java
>  b2b787c 
>   
> engine/api/src/org/apache/cloudstack/storage/datastore/db/PrimaryDataStoreDaoImpl.java
>  d461d58 
>   
> engine/api/

Re: [ACS42] Release Status Update

[John Burwell]

Mike,

Have you posted the diff with the resolved second round issues for the 
SolidFire patch to Review Board?

Thanks,
-John

On Jun 28, 2013, at 12:49 PM, Mike Tutkowski  
wrote:

> Hi John,
> 
> OK, this sounds good.
> 
> I updated from master yesterday and was resolving some (major) conflicts last 
> night and this morning. I want to get in some more testing before I commit.
> 
> Sounds good on the points you make. It should be, as you say, easy to resolve 
> them.
> 
> Thanks,
> Mike
> 
> 
> On Fri, Jun 28, 2013 at 9:50 AM, John Burwell  wrote:
> Mike,
> 
> I (finally) completed the review of the patch.  The TL;DR is that I am 
> removing my -1 on the patch so long as a supplemental patch that addresses 
> the issues raised is submitted to Review Board for a third review .  The 
> following items are concern me, and must be addressed before release:
> 
> Error handling in the patch catches and throws Exception too broadly.  There 
> is also no attempt in methods manipulating the hypervisor to back out partial 
> changes.  I am concerned that errors could put a hypervisor in an 
> inconsistent state.
> There is a manually built thread pool in the VMwareResource.  What is driving 
> the use of multiple threads?  It feels like pre-mature optimization.  If it 
> is necessary, ExceutorService should be used.
> There are unresolved TODOs in the PrimaryDataStoreImpl where getters are not 
> returning internal state as expected
> 
> Since we had Collab this week and I couldn't review it, I don't think we 
> should prevent the feature from coming into the release.  I also think these 
> issues can addressed rather quickly next week.  Finally, this patch has had 
> two rounds of review, so I don't expect the need for a fourth round.  As 
> such, let's get it merged and do the last bits of cleanup next week.
> 
> Thanks,
> -John
> 
> On Jun 26, 2013, at 11:42 PM, Mike Tutkowski  
> wrote:
> 
>> Hey John,
>> 
>> I know you were at a CloudStack Meetup today, but any thoughts on when we 
>> are going to get Storage QoS (the SolidFire plug-in) merged into master?
>> 
>> Thanks!
>> 
>> 
>> On Wed, Jun 26, 2013 at 9:37 PM, Animesh Chaturvedi 
>>  wrote:
>> Folks
>> 
>> The status for features or improvement is depicted in table below
>> 
>> |-+---+---|
>> | New Features / Improvements | This Week | TwoWeekAgo|
>> |-+---+---|
>> | Closed  | 8 | 7 |
>> | Resolved|56 |52 |
>> | In Progress |13 |17 |
>> | Reopened| 1 | 2 |
>> | Ready To Review | 2 | 2 |
>> | Open|22 |23 |
>> |-+---+---|
>> | Total   |   102 |   103 |
>> |-+---+---|
>> 
>> We are now just two days away from feature freeze, but still there are many 
>> open tickets. If the feature or improvement is unlikely to be wrapped up by 
>> 6/28 it should be moved out of 4.2
>> 
>> 
>> 
>> As for bugs here is a summary for this week:
>> 
>>   Bugs| This Week| Two Week Ago
>>  
>> -+---+--+---+---+---+--+---+---
>>   |   Blocker   Critical   Major   Total |   Blocker   
>> Critical   Major   Total
>>  
>> -+---+--+---+---+---+--+---+---
>>   Incoming| 4 19  37  68 | 8 
>> 20  29  60
>>   Outgoing|19 42  34 102 |18 
>> 10  42  76
>>   Open Unassigned | 4 27 116 184 | 7 
>> 35  93 166
>>   Open Total  |17 62 223 365 |19 
>> 74 192 345
>> 
>> 
>> 
>> The outgoing defect fix rate is much higher than incoming defects which is a 
>> good sign but we still have large number of open defects. We have a large 
>> number of unassigned open defects and it is increasing every week. If you 
>> are interested in helping out on defects please check the release dashboard  
>> http://s.apache.org/M5k
>> 
>> The resolved but not verified /closed has gone up now to 458 and needs to be 
>> contained. If you reported a issues and fixed it yourself but did not close 
>> it please take a moment to close the defect after verification.
>> 
>> I also wanted to call out that there are large number of patches on review 
>> board. If you are reviewer please attend to your reviews. If you are a 
>> submitter and want your contribution to be included in 4.2 please follow 
>> through with your reviewers.
>> 
>> 
>> Comments/feedback on this release status update are appreciated. You can 
>> always visit the

Re: Review Request 12721: Formatting of CSS and JS files

[Ian Duffy]

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

(Updated July 18, 2013, 2:47 p.m.)


Review request for cloudstack, Abhinandan Prateek, Pranav Saxena, and Sebastien 
Goasguen.


Changes
---

Remove trailing whitespace from diff.


Repository: cloudstack-git


Description
---

Format CSS and JS files using js-beautifier as discussed on the mailing list.


Diffs (updated)
-

  ui/scripts/accounts.js bad8435 
  ui/scripts/affinity.js a9c6695 
  ui/scripts/autoscaler.js 15a9dac 
  ui/scripts/cloud.core.callbacks.js 6eb7644 
  ui/scripts/cloudStack.js c0ff7f2 
  ui/scripts/configuration.js 8bc40d6 
  ui/scripts/dashboard.js e8ab6c5 
  ui/scripts/docs.js c8ef0d9 
  ui/scripts/domains.js 01f4236 
  ui/scripts/events.js bd50887 
  ui/scripts/globalSettings.js 1ae73b7 
  ui/scripts/installWizard.js 46769fa 
  ui/scripts/instanceWizard.js ff130d3 
  ui/scripts/instances.js 9b27d93 
  ui/scripts/lbStickyPolicy.js c0e2bfa 
  ui/scripts/network.js 95a93bc 
  ui/scripts/plugins.js 3c5bc0f 
  ui/scripts/projects.js ea1e6db 
  ui/scripts/regions.js 4be600f 
  ui/scripts/sharedFunctions.js a9f833c 
  ui/scripts/storage.js ad0965a 
  ui/scripts/system.js 3038a8a 
  ui/scripts/templates.js dbb0083 
  ui/scripts/ui-custom/affinity.js 1a23ff7 
  ui/scripts/ui-custom/autoscaler.js 119b672 
  ui/scripts/ui-custom/dashboard.js 6d92318 
  ui/scripts/ui-custom/enableStaticNAT.js 1b2bf7b 
  ui/scripts/ui-custom/granularSettings.js 02d5c1f 
  ui/scripts/ui-custom/healthCheck.js 4b42fa7 
  ui/scripts/ui-custom/installWizard.js c53a642 
  ui/scripts/ui-custom/instanceWizard.js 31b4baa 
  ui/scripts/ui-custom/ipRules.js 34b2398 
  ui/scripts/ui-custom/login.js 0dbbf82 
  ui/scripts/ui-custom/physicalResources.js 5173172 
  ui/scripts/ui-custom/pluginListing.js 3dcce98 
  ui/scripts/ui-custom/projectSelect.js aef49ed 
  ui/scripts/ui-custom/projects.js f1f9eba 
  ui/scripts/ui-custom/recurringSnapshots.js 985f369 
  ui/scripts/ui-custom/regions.js 9fc36f3 
  ui/scripts/ui-custom/securityRules.js 2e2c9ac 
  ui/scripts/ui-custom/uploadVolume.js 996d8ac 
  ui/scripts/ui-custom/vpc.js 4edccf1 
  ui/scripts/ui-custom/zoneChart.js 5d4e0c0 
  ui/scripts/ui-custom/zoneFilter.js 9e6a493 
  ui/scripts/ui-custom/zoneWizard.js 877dbc0 
  ui/scripts/ui/core.js 18c3363 
  ui/scripts/ui/dialog.js 7f82eea 
  ui/scripts/ui/events.js bd609d2 
  ui/scripts/ui/utils.js 39ef3e3 
  ui/scripts/ui/widgets/cloudBrowser.js 9a56bb3 
  ui/scripts/ui/widgets/dataTable.js 1b3ea82 
  ui/scripts/ui/widgets/detailView.js 0bccef5 
  ui/scripts/ui/widgets/listView.js bc68a72 
  ui/scripts/ui/widgets/multiEdit.js 08bd0bf 
  ui/scripts/ui/widgets/notifications.js 0299603 
  ui/scripts/ui/widgets/overlay.js ecf12e6 
  ui/scripts/ui/widgets/tagger.js 9af6fb7 
  ui/scripts/ui/widgets/toolTip.js 6967acc 
  ui/scripts/ui/widgets/treeView.js fa1ceb6 
  ui/scripts/vm_snapshots.js c50c7e1 
  ui/scripts/vpc.js e90d8a7 
  ui/scripts/zoneWizard.js 04687fe 

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


Testing
---

Compiled... previewed in browser, navigated the pages, checked everything 
looked normal.


Thanks,

Ian Duffy

Review Request 12723: test for Script

[Laszlo Hornyak]

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

Review request for cloudstack.


Repository: cloudstack-git


Description
---

a unit test for the most frequently used methods in the Script class


Diffs
-

  utils/test/com/cloud/utils/ScriptTest.java PRE-CREATION 

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


Testing
---

yes, this is the test


Thanks,

Laszlo Hornyak

Re: Is it possible for reviewer to add other reviewers in the reviewboard?

[Chip Childers]

So personally, I try my best to look at reviews whenever I have a spare
moment.  That's not all that frequent, but if everyone did that we would
be moving new code into the repo much more effectively and efficiently.


On Thu, Jul 18, 2013 at 11:42:01AM +0530, Prasanna Santhanam wrote:
> Yes and I've been doing it for months assigning reviewers, adding
> comments. In some cases I've also added possible contributors who are
> working in that area because committers are too "busy" to respond.
> 
> Hate to be the pessimist around here but even upon adding reviewers I
> don't see any response. So we likely don't really care for what
> contributors are doing beyond our own silo of work. IF you like I can
> pick out several reviews that have been sitting around for months with
> no response from reviewers.
> 
> It's unhealthy to say the least and I don't see adding reviewers to a
> patch going to help if we don't change our attitude about pro-actively
> reviewing areas of code that interest and/or break what we're working
> on. Also I sense this power to assign reviewers is becoming like the
> "Reply-To" thread where one doesnt respond until called-out for. I
> hope it isn't
> 
> When you see a new contributor the best boost they get from
> contributing more and more is when the community cares/bothers to
> review their work because they painfully worked on it. And that's
> confirmation to the fact that their work is useful and welcome.
> Committers more so should become "maintainers" like in the LKML
> shepherding and mentoring new contributors to become committers so
> they can leave behind their body of work and take this project to new
> levels, adding robust architecture, features, making it more and more
> solid and the best damn cloud orchestrator out there.
> 
> On Wed, Jul 17, 2013 at 03:02:23PM -0700, Sheng Yang wrote:
> > Or only submitter can modify it?
> > 
> > I find it would be useful if we identify the people who need to review it
> > after it's submitted.
> > 
> > --Sheng
> 
> -- 
> Prasanna.,
> 
> 
> Powered by BigRock.com
> 
> 

Re: Review Request 12716: Fix for NPE

[Sheng Yang]

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

Ship it!


Ship It!

- Sheng Yang


On July 18, 2013, 2:10 a.m., Venkata Siva Vijayendra Bhamidipati wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/12716/
> ---
> 
> (Updated July 18, 2013, 2:10 a.m.)
> 
> 
> Review request for cloudstack, Chip Childers, edison su, Min Chen, Sateesh 
> Chodapuneedi, and Sheng Yang.
> 
> 
> Bugs: CLOUDSTACK-3598
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Minor fix for an NPE when setting resource count.
> 
> 
> Diffs
> -
> 
>   engine/schema/src/com/cloud/configuration/dao/ResourceCountDaoImpl.java 
> cfd2137 
> 
> Diff: https://reviews.apache.org/r/12716/diff/
> 
> 
> Testing
> ---
> 
> This showed up in automation tests in the code path that handles template 
> sync operations. I wasn't able to reproduce this in a manual setup. But the 
> NPE does exist and the code needs to be fixed for that, so I'm submitting the 
> patch.
> 
> 
> Thanks,
> 
> Venkata Siva Vijayendra Bhamidipati
> 
>

Re: Review Request 12660: Replaced multiple grep/awk/head commands by one awk

[David Nalley]

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

(Updated July 18, 2013, 3:57 p.m.)


Review request for cloudstack and Wido den Hollander.


Repository: cloudstack-git


Description
---

Replaced multiple grep/awk/head commands by one awk.


Diffs
-

  scripts/vm/network/security_group.py c1c87da 

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


Testing
---

Tested output. Not able to test using cloudstack function execute() or real 
ebtables output.


Thanks,

Rene Diepstraten

Re: Review Request 12646: Truncated trailing/double spaces.

[David Nalley]

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

(Updated July 18, 2013, 4:07 p.m.)


Review request for cloudstack and Wido den Hollander.


Changes
---

adding the cloudstack group so that this hits the mailinglist


Repository: cloudstack-git


Description
---

Truncated trailing/double spaces.


Diffs
-

  scripts/vm/network/security_group.py 10610f0 

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


Testing
---

No real testing done, just cleanup work. Should not change the code.


Thanks,

Rene Diepstraten

Re: Review Request 12646: Truncated trailing/double spaces.

[David Nalley]

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

(Updated July 18, 2013, 4:07 p.m.)


Review request for cloudstack and Wido den Hollander.


Changes
---

adding the cloudstack group so that this hits the mailinglist


Repository: cloudstack-git


Description
---

Truncated trailing/double spaces.


Diffs
-

  scripts/vm/network/security_group.py 10610f0 

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


Testing
---

No real testing done, just cleanup work. Should not change the code.


Thanks,

Rene Diepstraten

Re: Is it possible for reviewer to add other reviewers in the reviewboard?

[Daan Hoogland]

this has been kind of bugging me too. Along with unanswered questions on
teh list by newbees like me. As we all depend on volunteers and
conculeagues I don't really see a solution but reporting on outstanding
reviews and maybe unanswered questions. The latter can only be done
manually though, as it is really hard to automatically determine that a
mail requires reply. I kept track of the unanswered mails for one week
after ccc13. It were six that I didn't have time to gain knowledge to
answer. This is not extreme, but still may be a waste as some of the posing
people might have been thrown of the cloudstack track by them. Hugo said he
had a script querying the review board for old reviews and an automated
report on that would be easier. I know all you guru's do your best but a
weekly report, keeping us all conscious might help.

As you might have guessed this is me volunteering to keep track of
unanswered questions for a few weeks. As we go along good ideas on how to
improve our way might spring up. /me is an optimist at rare occasions.

regards,
Daan


On Thu, Jul 18, 2013 at 5:43 PM, Chip Childers wrote:

> So personally, I try my best to look at reviews whenever I have a spare
> moment.  That's not all that frequent, but if everyone did that we would
> be moving new code into the repo much more effectively and efficiently.
>
>
> On Thu, Jul 18, 2013 at 11:42:01AM +0530, Prasanna Santhanam wrote:
> > Yes and I've been doing it for months assigning reviewers, adding
> > comments. In some cases I've also added possible contributors who are
> > working in that area because committers are too "busy" to respond.
> >
> > Hate to be the pessimist around here but even upon adding reviewers I
> > don't see any response. So we likely don't really care for what
> > contributors are doing beyond our own silo of work. IF you like I can
> > pick out several reviews that have been sitting around for months with
> > no response from reviewers.
> >
> > It's unhealthy to say the least and I don't see adding reviewers to a
> > patch going to help if we don't change our attitude about pro-actively
> > reviewing areas of code that interest and/or break what we're working
> > on. Also I sense this power to assign reviewers is becoming like the
> > "Reply-To" thread where one doesnt respond until called-out for. I
> > hope it isn't
> >
> > When you see a new contributor the best boost they get from
> > contributing more and more is when the community cares/bothers to
> > review their work because they painfully worked on it. And that's
> > confirmation to the fact that their work is useful and welcome.
> > Committers more so should become "maintainers" like in the LKML
> > shepherding and mentoring new contributors to become committers so
> > they can leave behind their body of work and take this project to new
> > levels, adding robust architecture, features, making it more and more
> > solid and the best damn cloud orchestrator out there.
> >
> > On Wed, Jul 17, 2013 at 03:02:23PM -0700, Sheng Yang wrote:
> > > Or only submitter can modify it?
> > >
> > > I find it would be useful if we identify the people who need to review
> it
> > > after it's submitted.
> > >
> > > --Sheng
> >
> > --
> > Prasanna.,
> >
> > 
> > Powered by BigRock.com
> >
> >
>

Re: Review Request 12659: Removed unused script scripts/storage/qcow2/cleanupmyvms.sh

[David Nalley]

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

(Updated July 18, 2013, 4:09 p.m.)


Review request for cloudstack and Wido den Hollander.


Changes
---

adding the cloudstack group in the mailing list


Repository: cloudstack-git


Description
---

Removed unused script scripts/storage/qcow2/cleanupmyvms.sh


Diffs
-

  scripts/storage/qcow2/cleanupmyvms.sh e270a01 

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


Testing
---

Ran a grep :
grep -ir cleanupmyvms agent plugins/hypervisors/kvm/


Thanks,

Rene Diepstraten

Problem in adding Ceph RBD storage to CloudStack

[Takuma Nakajima]

Hi,

I'm building a CloudStack 4.1 with Ceph RBD storage using RHEL 6.3 recently
but it fails when adding RBD storage to primary storage.
Does anybody know about the problem?

1. qemu (1.5.50, configured with "--enable-rbd") and libvirt (0.10.2,
configured with "--with-storage-rbd") are installed to the computing
node.
2. The virtual machine with ceph storage configured with "virsh edit"
(not under controll of CloudStack) works well
3. /var/log/libvirt/libvirtd.log says "internal error missing backend
for pool type 8" when adding RBD storage with following parameters

Zone : 
Pod : 
Cluster : 
Name : primary_rbd
Protocol : RBD
RADOS Monitor : 
RADOS Pool : libvirt-pool
RADOS User : libvirt
RADOS Secret : AQ...==
Storage Tags : rbd

4. management server log when adding the ceph storage is following

2013-07-18 12:23:47,712 DEBUG [cloud.storage.StorageManagerImpl]
(catalina-exec-9:null) In createPool Adding the pool to each of the
hosts
2013-07-18 12:23:47,712 DEBUG [cloud.storage.StorageManagerImpl]
(catalina-exec-9:null) Adding pool primary_rbd to  host 1
2013-07-18 12:23:47,716 DEBUG [agent.transport.Request]
(catalina-exec-9:null) Seq 1-80819236: Sending
...
2013-07-18 12:23:47,843 DEBUG [agent.transport.Request]
(catalina-exec-9:null) Seq 1-80819236: Received:  { Ans: , MgmtId:
90520734321155, via: 1, Ver: v1, Flags: 10, { Answer } }
2013-07-18 12:23:47,843 DEBUG [agent.manager.AgentManagerImpl]
(catalina-exec-9:null) Details from executing class
com.cloud.agent.api.ModifyStoragePoolCommand:
java.lang.NullPointerException
at 
com.cloud.hypervisor.kvm.storage.LibvirtStorageAdaptor.createStoragePool(LibvirtStorageAdaptor.java:540)
at 
com.cloud.hypervisor.kvm.storage.KVMStoragePoolManager.createStoragePool(KVMStoragePoolManager.java:111)
...
2013-07-18 12:23:47,892 WARN  [cloud.storage.StorageManagerImpl]
(catalina-exec-9:null) Unable to establish a connection between
Host[-1-Routing] and Pool[218|RBD]
com.cloud.exception.StorageUnavailableException: Resource
[StoragePool:218] is nreachable: Unable establish connection from
storage head to storage pool 218 due to java.lang.NullPointerException
at 
com.cloud.hypervisor.kvm.storage.LibvirtStorageAdaptor.createStoragePool(LibvirtStorageAdaptor.java:540)
at 
com.cloud.hypervisor.kvm.storage.KVMStoragePoolManager.createStoragePool(KVMStoragePoolManager.java:111)
...
2013-07-18 12:23:47,894 WARN  [cloud.storage.StorageManagerImpl]
(catalina-exec-9:null) No host can access storage pool Pool[218|RBD]
on cluster 1
2013-07-18 12:23:47,975 INFO  [cloud.api.ApiServer]
(catalina-exec-9:null) Failed to add storage pool


Takuma Nakajima

Re: Review Request 12658: Corrected typos in log messages

[David Nalley]

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

(Updated July 18, 2013, 4:07 p.m.)


Review request for cloudstack and Wido den Hollander.


Changes
---

adding to the cloudstack group so that this hits the mailing list 


Repository: cloudstack-git


Description
---

Corrected typos in log messages


Diffs
-

  scripts/vm/network/security_group.py 044747a 

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


Testing
---

These are only log messages and should not change how the code works.


Thanks,

Rene Diepstraten

Re: Review Request 12679: CLOUDSTACK-904: Changed multiple vcpus to one vcpu with multiple sockets

[David Nalley]

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

(Updated July 18, 2013, 4:06 p.m.)


Review request for cloudstack and Wido den Hollander.


Bugs: CLOUDSTACK-904


Repository: cloudstack-git


Description
---

Cloudstack defines a vm with multiple CPUs instead of one CPU with multiple 
cores. 
For Windows as well as RHEL guests, the license is based on the amount of CPU 
sockets.
The definition of VCPUs should therefore translate to the amount of cores, not 
CPUs.


Diffs
-

  
plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/LibvirtVMDef.java 
5120870 

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


Testing
---

Only tested the output of the append rule.


Thanks,

Rene Diepstraten

Re: Problem in adding Ceph RBD storage to CloudStack

[Wido den Hollander]

Hi,

On 07/18/2013 06:09 PM, Takuma Nakajima wrote:

Hi,

I'm building a CloudStack 4.1 with Ceph RBD storage using RHEL 6.3 recently
but it fails when adding RBD storage to primary storage.
Does anybody know about the problem?



No, it works for me like a charm :)

Could you set the Agent logging to DEBUG as well and show the output of 
that log? Maybe paste the log on pastebin.


I'm interested in the XMLs the Agent is feeding to libvirt when adding 
the RBD pool.


Seems like I forgot some checks here and there, so I wan't to find out 
what I forgot.


Wido


1. qemu (1.5.50, configured with "--enable-rbd") and libvirt (0.10.2,
configured with "--with-storage-rbd") are installed to the computing
node.
2. The virtual machine with ceph storage configured with "virsh edit"
(not under controll of CloudStack) works well
3. /var/log/libvirt/libvirtd.log says "internal error missing backend
for pool type 8" when adding RBD storage with following parameters

Zone : 
Pod : 
Cluster : 
Name : primary_rbd
Protocol : RBD
RADOS Monitor : 
RADOS Pool : libvirt-pool
RADOS User : libvirt
RADOS Secret : AQ...==
Storage Tags : rbd

4. management server log when adding the ceph storage is following

2013-07-18 12:23:47,712 DEBUG [cloud.storage.StorageManagerImpl]
(catalina-exec-9:null) In createPool Adding the pool to each of the
hosts
2013-07-18 12:23:47,712 DEBUG [cloud.storage.StorageManagerImpl]
(catalina-exec-9:null) Adding pool primary_rbd to  host 1
2013-07-18 12:23:47,716 DEBUG [agent.transport.Request]
(catalina-exec-9:null) Seq 1-80819236: Sending
...
2013-07-18 12:23:47,843 DEBUG [agent.transport.Request]
(catalina-exec-9:null) Seq 1-80819236: Received:  { Ans: , MgmtId:
90520734321155, via: 1, Ver: v1, Flags: 10, { Answer } }
2013-07-18 12:23:47,843 DEBUG [agent.manager.AgentManagerImpl]
(catalina-exec-9:null) Details from executing class
com.cloud.agent.api.ModifyStoragePoolCommand:
java.lang.NullPointerException
 at 
com.cloud.hypervisor.kvm.storage.LibvirtStorageAdaptor.createStoragePool(LibvirtStorageAdaptor.java:540)
 at 
com.cloud.hypervisor.kvm.storage.KVMStoragePoolManager.createStoragePool(KVMStoragePoolManager.java:111)
...
2013-07-18 12:23:47,892 WARN  [cloud.storage.StorageManagerImpl]
(catalina-exec-9:null) Unable to establish a connection between
Host[-1-Routing] and Pool[218|RBD]
com.cloud.exception.StorageUnavailableException: Resource
[StoragePool:218] is nreachable: Unable establish connection from
storage head to storage pool 218 due to java.lang.NullPointerException
 at 
com.cloud.hypervisor.kvm.storage.LibvirtStorageAdaptor.createStoragePool(LibvirtStorageAdaptor.java:540)
 at 
com.cloud.hypervisor.kvm.storage.KVMStoragePoolManager.createStoragePool(KVMStoragePoolManager.java:111)
...
2013-07-18 12:23:47,894 WARN  [cloud.storage.StorageManagerImpl]
(catalina-exec-9:null) No host can access storage pool Pool[218|RBD]
on cluster 1
2013-07-18 12:23:47,975 INFO  [cloud.api.ApiServer]
(catalina-exec-9:null) Failed to add storage pool


Takuma Nakajima

Re: Is it possible for reviewer to add other reviewers in the reviewboard?

[Prasanna Santhanam]

On Thu, Jul 18, 2013 at 06:07:48PM +0200, Daan Hoogland wrote:
> this has been kind of bugging me too. Along with unanswered questions on
> teh list by newbees like me. As we all depend on volunteers and
> conculeagues I don't really see a solution but reporting on outstanding
> reviews and maybe unanswered questions. The latter can only be done
> manually though, as it is really hard to automatically determine that a
> mail requires reply. I kept track of the unanswered mails for one week
> after ccc13. It were six that I didn't have time to gain knowledge to
> answer. This is not extreme, but still may be a waste as some of the posing
> people might have been thrown of the cloudstack track by them. Hugo said he
> had a script querying the review board for old reviews and an automated
> report on that would be easier. I know all you guru's do your best but a
> weekly report, keeping us all conscious might help.
> 
Yes - Rohit wrote the script and I send it sometimes before things
like freeze/deadlines to alert the community but everyone's like ...
meh.

https://github.com/vogxn/RBTool (that's the tool)

We should also have IRC alerts via ASFBot for every rb request posted
and merged.  I was going to work on this with Humbeedoh (INFRA) but am
yet to get to it. Feel free to pick it up - ASFBot is written in Lua.

If you can't convince the people, try write tools around it eh?


> As you might have guessed this is me volunteering to keep track of
> unanswered questions for a few weeks. As we go along good ideas on how to
> improve our way might spring up. /me is an optimist at rare occasions.

I rant and go do the postive thing hoping for it to be picked up.
Guess that makes me an optimist :)

-- 
Prasanna.,


Powered by BigRock.com

Re: Problem in adding Ceph RBD storage to CloudStack

[David Nalley]

On Thu, Jul 18, 2013 at 12:09 PM, Takuma Nakajima
 wrote:
> Hi,
>
> I'm building a CloudStack 4.1 with Ceph RBD storage using RHEL 6.3 recently
> but it fails when adding RBD storage to primary storage.
> Does anybody know about the problem?


Why not 6.4?

Re: Review Request 12721: Formatting of CSS and JS files

[Pranav Saxena]

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

Ship it!


Changes look good. I don't have an access to my machine from where I could 
commit your changes. Hence, request a committer to merge these into all the 
relevant branches.
Thanks !

- Pranav Saxena


On July 18, 2013, 2:47 p.m., Ian Duffy wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/12721/
> ---
> 
> (Updated July 18, 2013, 2:47 p.m.)
> 
> 
> Review request for cloudstack, Abhinandan Prateek, Pranav Saxena, and 
> Sebastien Goasguen.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Format CSS and JS files using js-beautifier as discussed on the mailing list.
> 
> 
> Diffs
> -
> 
>   ui/scripts/accounts.js bad8435 
>   ui/scripts/affinity.js a9c6695 
>   ui/scripts/autoscaler.js 15a9dac 
>   ui/scripts/cloud.core.callbacks.js 6eb7644 
>   ui/scripts/cloudStack.js c0ff7f2 
>   ui/scripts/configuration.js 8bc40d6 
>   ui/scripts/dashboard.js e8ab6c5 
>   ui/scripts/docs.js c8ef0d9 
>   ui/scripts/domains.js 01f4236 
>   ui/scripts/events.js bd50887 
>   ui/scripts/globalSettings.js 1ae73b7 
>   ui/scripts/installWizard.js 46769fa 
>   ui/scripts/instanceWizard.js ff130d3 
>   ui/scripts/instances.js 9b27d93 
>   ui/scripts/lbStickyPolicy.js c0e2bfa 
>   ui/scripts/network.js 95a93bc 
>   ui/scripts/plugins.js 3c5bc0f 
>   ui/scripts/projects.js ea1e6db 
>   ui/scripts/regions.js 4be600f 
>   ui/scripts/sharedFunctions.js a9f833c 
>   ui/scripts/storage.js ad0965a 
>   ui/scripts/system.js 3038a8a 
>   ui/scripts/templates.js dbb0083 
>   ui/scripts/ui-custom/affinity.js 1a23ff7 
>   ui/scripts/ui-custom/autoscaler.js 119b672 
>   ui/scripts/ui-custom/dashboard.js 6d92318 
>   ui/scripts/ui-custom/enableStaticNAT.js 1b2bf7b 
>   ui/scripts/ui-custom/granularSettings.js 02d5c1f 
>   ui/scripts/ui-custom/healthCheck.js 4b42fa7 
>   ui/scripts/ui-custom/installWizard.js c53a642 
>   ui/scripts/ui-custom/instanceWizard.js 31b4baa 
>   ui/scripts/ui-custom/ipRules.js 34b2398 
>   ui/scripts/ui-custom/login.js 0dbbf82 
>   ui/scripts/ui-custom/physicalResources.js 5173172 
>   ui/scripts/ui-custom/pluginListing.js 3dcce98 
>   ui/scripts/ui-custom/projectSelect.js aef49ed 
>   ui/scripts/ui-custom/projects.js f1f9eba 
>   ui/scripts/ui-custom/recurringSnapshots.js 985f369 
>   ui/scripts/ui-custom/regions.js 9fc36f3 
>   ui/scripts/ui-custom/securityRules.js 2e2c9ac 
>   ui/scripts/ui-custom/uploadVolume.js 996d8ac 
>   ui/scripts/ui-custom/vpc.js 4edccf1 
>   ui/scripts/ui-custom/zoneChart.js 5d4e0c0 
>   ui/scripts/ui-custom/zoneFilter.js 9e6a493 
>   ui/scripts/ui-custom/zoneWizard.js 877dbc0 
>   ui/scripts/ui/core.js 18c3363 
>   ui/scripts/ui/dialog.js 7f82eea 
>   ui/scripts/ui/events.js bd609d2 
>   ui/scripts/ui/utils.js 39ef3e3 
>   ui/scripts/ui/widgets/cloudBrowser.js 9a56bb3 
>   ui/scripts/ui/widgets/dataTable.js 1b3ea82 
>   ui/scripts/ui/widgets/detailView.js 0bccef5 
>   ui/scripts/ui/widgets/listView.js bc68a72 
>   ui/scripts/ui/widgets/multiEdit.js 08bd0bf 
>   ui/scripts/ui/widgets/notifications.js 0299603 
>   ui/scripts/ui/widgets/overlay.js ecf12e6 
>   ui/scripts/ui/widgets/tagger.js 9af6fb7 
>   ui/scripts/ui/widgets/toolTip.js 6967acc 
>   ui/scripts/ui/widgets/treeView.js fa1ceb6 
>   ui/scripts/vm_snapshots.js c50c7e1 
>   ui/scripts/vpc.js e90d8a7 
>   ui/scripts/zoneWizard.js 04687fe 
> 
> Diff: https://reviews.apache.org/r/12721/diff/
> 
> 
> Testing
> ---
> 
> Compiled... previewed in browser, navigated the pages, checked everything 
> looked normal.
> 
> 
> Thanks,
> 
> Ian Duffy
> 
>

Re: Review Request 12721: Formatting of CSS and JS files

[Ian Duffy]

> On July 18, 2013, 4:24 p.m., Pranav Saxena wrote:
> > Changes look good. I don't have an access to my machine from where I could 
> > commit your changes. Hence, request a committer to merge these into all the 
> > relevant branches.
> > Thanks !

Okay will leave it as open until a committer merges them.


- Ian


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


On July 18, 2013, 2:47 p.m., Ian Duffy wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/12721/
> ---
> 
> (Updated July 18, 2013, 2:47 p.m.)
> 
> 
> Review request for cloudstack, Abhinandan Prateek, Pranav Saxena, and 
> Sebastien Goasguen.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Format CSS and JS files using js-beautifier as discussed on the mailing list.
> 
> 
> Diffs
> -
> 
>   ui/scripts/accounts.js bad8435 
>   ui/scripts/affinity.js a9c6695 
>   ui/scripts/autoscaler.js 15a9dac 
>   ui/scripts/cloud.core.callbacks.js 6eb7644 
>   ui/scripts/cloudStack.js c0ff7f2 
>   ui/scripts/configuration.js 8bc40d6 
>   ui/scripts/dashboard.js e8ab6c5 
>   ui/scripts/docs.js c8ef0d9 
>   ui/scripts/domains.js 01f4236 
>   ui/scripts/events.js bd50887 
>   ui/scripts/globalSettings.js 1ae73b7 
>   ui/scripts/installWizard.js 46769fa 
>   ui/scripts/instanceWizard.js ff130d3 
>   ui/scripts/instances.js 9b27d93 
>   ui/scripts/lbStickyPolicy.js c0e2bfa 
>   ui/scripts/network.js 95a93bc 
>   ui/scripts/plugins.js 3c5bc0f 
>   ui/scripts/projects.js ea1e6db 
>   ui/scripts/regions.js 4be600f 
>   ui/scripts/sharedFunctions.js a9f833c 
>   ui/scripts/storage.js ad0965a 
>   ui/scripts/system.js 3038a8a 
>   ui/scripts/templates.js dbb0083 
>   ui/scripts/ui-custom/affinity.js 1a23ff7 
>   ui/scripts/ui-custom/autoscaler.js 119b672 
>   ui/scripts/ui-custom/dashboard.js 6d92318 
>   ui/scripts/ui-custom/enableStaticNAT.js 1b2bf7b 
>   ui/scripts/ui-custom/granularSettings.js 02d5c1f 
>   ui/scripts/ui-custom/healthCheck.js 4b42fa7 
>   ui/scripts/ui-custom/installWizard.js c53a642 
>   ui/scripts/ui-custom/instanceWizard.js 31b4baa 
>   ui/scripts/ui-custom/ipRules.js 34b2398 
>   ui/scripts/ui-custom/login.js 0dbbf82 
>   ui/scripts/ui-custom/physicalResources.js 5173172 
>   ui/scripts/ui-custom/pluginListing.js 3dcce98 
>   ui/scripts/ui-custom/projectSelect.js aef49ed 
>   ui/scripts/ui-custom/projects.js f1f9eba 
>   ui/scripts/ui-custom/recurringSnapshots.js 985f369 
>   ui/scripts/ui-custom/regions.js 9fc36f3 
>   ui/scripts/ui-custom/securityRules.js 2e2c9ac 
>   ui/scripts/ui-custom/uploadVolume.js 996d8ac 
>   ui/scripts/ui-custom/vpc.js 4edccf1 
>   ui/scripts/ui-custom/zoneChart.js 5d4e0c0 
>   ui/scripts/ui-custom/zoneFilter.js 9e6a493 
>   ui/scripts/ui-custom/zoneWizard.js 877dbc0 
>   ui/scripts/ui/core.js 18c3363 
>   ui/scripts/ui/dialog.js 7f82eea 
>   ui/scripts/ui/events.js bd609d2 
>   ui/scripts/ui/utils.js 39ef3e3 
>   ui/scripts/ui/widgets/cloudBrowser.js 9a56bb3 
>   ui/scripts/ui/widgets/dataTable.js 1b3ea82 
>   ui/scripts/ui/widgets/detailView.js 0bccef5 
>   ui/scripts/ui/widgets/listView.js bc68a72 
>   ui/scripts/ui/widgets/multiEdit.js 08bd0bf 
>   ui/scripts/ui/widgets/notifications.js 0299603 
>   ui/scripts/ui/widgets/overlay.js ecf12e6 
>   ui/scripts/ui/widgets/tagger.js 9af6fb7 
>   ui/scripts/ui/widgets/toolTip.js 6967acc 
>   ui/scripts/ui/widgets/treeView.js fa1ceb6 
>   ui/scripts/vm_snapshots.js c50c7e1 
>   ui/scripts/vpc.js e90d8a7 
>   ui/scripts/zoneWizard.js 04687fe 
> 
> Diff: https://reviews.apache.org/r/12721/diff/
> 
> 
> Testing
> ---
> 
> Compiled... previewed in browser, navigated the pages, checked everything 
> looked normal.
> 
> 
> Thanks,
> 
> Ian Duffy
> 
>

Re: Review Request 12721: Formatting of CSS and JS files

[Sebastien Goasguen]

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

Ship it!


committed to master ad69bc8da3244b783dd003ddf3184fca2762c514

mark as submitted

thanks

- Sebastien Goasguen


On July 18, 2013, 2:47 p.m., Ian Duffy wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/12721/
> ---
> 
> (Updated July 18, 2013, 2:47 p.m.)
> 
> 
> Review request for cloudstack, Abhinandan Prateek, Pranav Saxena, and 
> Sebastien Goasguen.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Format CSS and JS files using js-beautifier as discussed on the mailing list.
> 
> 
> Diffs
> -
> 
>   ui/scripts/accounts.js bad8435 
>   ui/scripts/affinity.js a9c6695 
>   ui/scripts/autoscaler.js 15a9dac 
>   ui/scripts/cloud.core.callbacks.js 6eb7644 
>   ui/scripts/cloudStack.js c0ff7f2 
>   ui/scripts/configuration.js 8bc40d6 
>   ui/scripts/dashboard.js e8ab6c5 
>   ui/scripts/docs.js c8ef0d9 
>   ui/scripts/domains.js 01f4236 
>   ui/scripts/events.js bd50887 
>   ui/scripts/globalSettings.js 1ae73b7 
>   ui/scripts/installWizard.js 46769fa 
>   ui/scripts/instanceWizard.js ff130d3 
>   ui/scripts/instances.js 9b27d93 
>   ui/scripts/lbStickyPolicy.js c0e2bfa 
>   ui/scripts/network.js 95a93bc 
>   ui/scripts/plugins.js 3c5bc0f 
>   ui/scripts/projects.js ea1e6db 
>   ui/scripts/regions.js 4be600f 
>   ui/scripts/sharedFunctions.js a9f833c 
>   ui/scripts/storage.js ad0965a 
>   ui/scripts/system.js 3038a8a 
>   ui/scripts/templates.js dbb0083 
>   ui/scripts/ui-custom/affinity.js 1a23ff7 
>   ui/scripts/ui-custom/autoscaler.js 119b672 
>   ui/scripts/ui-custom/dashboard.js 6d92318 
>   ui/scripts/ui-custom/enableStaticNAT.js 1b2bf7b 
>   ui/scripts/ui-custom/granularSettings.js 02d5c1f 
>   ui/scripts/ui-custom/healthCheck.js 4b42fa7 
>   ui/scripts/ui-custom/installWizard.js c53a642 
>   ui/scripts/ui-custom/instanceWizard.js 31b4baa 
>   ui/scripts/ui-custom/ipRules.js 34b2398 
>   ui/scripts/ui-custom/login.js 0dbbf82 
>   ui/scripts/ui-custom/physicalResources.js 5173172 
>   ui/scripts/ui-custom/pluginListing.js 3dcce98 
>   ui/scripts/ui-custom/projectSelect.js aef49ed 
>   ui/scripts/ui-custom/projects.js f1f9eba 
>   ui/scripts/ui-custom/recurringSnapshots.js 985f369 
>   ui/scripts/ui-custom/regions.js 9fc36f3 
>   ui/scripts/ui-custom/securityRules.js 2e2c9ac 
>   ui/scripts/ui-custom/uploadVolume.js 996d8ac 
>   ui/scripts/ui-custom/vpc.js 4edccf1 
>   ui/scripts/ui-custom/zoneChart.js 5d4e0c0 
>   ui/scripts/ui-custom/zoneFilter.js 9e6a493 
>   ui/scripts/ui-custom/zoneWizard.js 877dbc0 
>   ui/scripts/ui/core.js 18c3363 
>   ui/scripts/ui/dialog.js 7f82eea 
>   ui/scripts/ui/events.js bd609d2 
>   ui/scripts/ui/utils.js 39ef3e3 
>   ui/scripts/ui/widgets/cloudBrowser.js 9a56bb3 
>   ui/scripts/ui/widgets/dataTable.js 1b3ea82 
>   ui/scripts/ui/widgets/detailView.js 0bccef5 
>   ui/scripts/ui/widgets/listView.js bc68a72 
>   ui/scripts/ui/widgets/multiEdit.js 08bd0bf 
>   ui/scripts/ui/widgets/notifications.js 0299603 
>   ui/scripts/ui/widgets/overlay.js ecf12e6 
>   ui/scripts/ui/widgets/tagger.js 9af6fb7 
>   ui/scripts/ui/widgets/toolTip.js 6967acc 
>   ui/scripts/ui/widgets/treeView.js fa1ceb6 
>   ui/scripts/vm_snapshots.js c50c7e1 
>   ui/scripts/vpc.js e90d8a7 
>   ui/scripts/zoneWizard.js 04687fe 
> 
> Diff: https://reviews.apache.org/r/12721/diff/
> 
> 
> Testing
> ---
> 
> Compiled... previewed in browser, navigated the pages, checked everything 
> looked normal.
> 
> 
> Thanks,
> 
> Ian Duffy
> 
>

Re: [ACS42] Release Status Update

[Mike Tutkowski]

Hi John,

Oh, not yet...I am still working on one of your VMware issues. It should be
done today or tomorrow, I expect.

Thanks


On Thu, Jul 18, 2013 at 8:47 AM, John Burwell  wrote:

> Mike,
>
> Have you posted the diff with the resolved second round issues for the
> SolidFire patch to Review Board?
>
> Thanks,
> -John
>
> On Jun 28, 2013, at 12:49 PM, Mike Tutkowski 
> wrote:
>
> Hi John,
>
> OK, this sounds good.
>
> I updated from master yesterday and was resolving some (major) conflicts
> last night and this morning. I want to get in some more testing before I
> commit.
>
> Sounds good on the points you make. It should be, as you say, easy to
> resolve them.
>
> Thanks,
> Mike
>
>
> On Fri, Jun 28, 2013 at 9:50 AM, John Burwell  wrote:
>
>> Mike,
>>
>> I (finally) completed the review of the patch.  The TL;DR is that I am
>> removing my -1 on the patch so long as a supplemental patch that addresses
>> the issues raised is submitted to Review Board for a third review .  The
>> following items are concern me, and must be addressed before release:
>>
>>
>>- Error handling in the patch catches and throws Exception too
>>broadly.  There is also no attempt in methods manipulating the hypervisor
>>to back out partial changes.  I am concerned that errors could put a
>>hypervisor in an inconsistent state.
>>- There is a manually built thread pool in the VMwareResource.  What
>>is driving the use of multiple threads?  It feels like pre-mature
>>optimization.  If it is necessary, ExceutorService should be used.
>>- There are unresolved TODOs in the PrimaryDataStoreImpl where
>>getters are not returning internal state as expected
>>
>>
>> Since we had Collab this week and I couldn't review it, I don't think we
>> should prevent the feature from coming into the release.  I also think
>> these issues can addressed rather quickly next week.  Finally, this patch
>> has had two rounds of review, so I don't expect the need for a fourth
>> round.  As such, let's get it merged and do the last bits of cleanup next
>> week.
>>
>> Thanks,
>> -John
>>
>> On Jun 26, 2013, at 11:42 PM, Mike Tutkowski <
>> mike.tutkow...@solidfire.com> wrote:
>>
>> Hey John,
>>
>> I know you were at a CloudStack Meetup today, but any thoughts on when we
>> are going to get Storage QoS (the SolidFire plug-in) merged into master?
>>
>> Thanks!
>>
>>
>> On Wed, Jun 26, 2013 at 9:37 PM, Animesh Chaturvedi <
>> animesh.chaturv...@citrix.com> wrote:
>>
>>> Folks
>>>
>>> The status for features or improvement is depicted in table below
>>>
>>> |-+---+---|
>>> | New Features / Improvements | This Week | TwoWeekAgo|
>>> |-+---+---|
>>> | Closed  | 8 | 7 |
>>> | Resolved|56 |52 |
>>> | In Progress |13 |17 |
>>> | Reopened| 1 | 2 |
>>> | Ready To Review | 2 | 2 |
>>> | Open|22 |23 |
>>> |-+---+---|
>>> | Total   |   102 |   103 |
>>> |-+---+---|
>>>
>>> We are now just two days away from feature freeze, but still there are
>>> many open tickets. If the feature or improvement is unlikely to be wrapped
>>> up by 6/28 it should be moved out of 4.2
>>>
>>>
>>>
>>> As for bugs here is a summary for this week:
>>>
>>>   Bugs| This Week| Two Week Ago
>>>
>>>  
>>> -+---+--+---+---+---+--+---+---
>>>   |   Blocker   Critical   Major   Total |   Blocker
>>> Critical   Major   Total
>>>
>>>  
>>> -+---+--+---+---+---+--+---+---
>>>   Incoming| 4 19  37  68 | 8
>>> 20  29  60
>>>   Outgoing|19 42  34 102 |18
>>> 10  42  76
>>>   Open Unassigned | 4 27 116 184 | 7
>>> 35  93 166
>>>   Open Total  |17 62 223 365 |19
>>> 74 192 345
>>>
>>>
>>>
>>> The outgoing defect fix rate is much higher than incoming defects which
>>> is a good sign but we still have large number of open defects. We have a
>>> large number of unassigned open defects and it is increasing every week. If
>>> you are interested in helping out on defects please check the release
>>> dashboard  http://s.apache.org/M5k
>>>
>>> The resolved but not verified /closed has gone up now to 458 and needs
>>> to be contained. If you reported a issues and fixed it yourself but did not
>>> close it please take a moment to close the defect after verification.
>>>
>>> I also wanted to call out that there 

RE: [rant] stupid test cases

[Alex Huang]

I don't believe this is a bad testcase.  It's to force the code path on cleanup 
procedure before a domain is properly deleted.  

If this was a unit-test I would say there's no point.  For a 
systems/integration test, the testcase makes sense.

--Alex

> -Original Message-
> From: Prasanna Santhanam [mailto:t...@apache.org]
> Sent: Wednesday, July 17, 2013 10:33 PM
> To: CloudStack Dev
> Subject: [rant] stupid test cases
> 
> I was just going through one of the automated test cases and I find it really
> silly that there's the following test:
> 
> def test_forceDeleteDomain(self):
> """ Test delete domain force option"""
> 
> # Steps for validations
> # 1. create a domain DOM
> # 2. create 2 users under this domain
> # 3. deploy 1 VM into each of these user accounts
> # 4. create PF / FW rules for port 22 on these VMs for their
> #respective accounts
> # 5. delete the domain with force=true option
> # Validate the following
> # 1. listDomains should list the created domain
> # 2. listAccounts should list the created accounts
> # 3. listvirtualmachines should show the Running VMs
> # 4. PF and FW rules should be shown in listFirewallRules
> # 5. domain should delete successfully and above three list calls
> #should show all the resources now deleted. listRouters should
> #not return any routers in the deleted accounts/domains
> 
> Why would one need the overhead of creating VMs in a domain deletion test?
> Do we not understand that the basics accounts/domains/ etc that cloudstack
> has nothing to do with the virtual machines? This kind of a test slows down
> other useful tests that we could be running. More over when this fails in the
> VM creation step I'd have to go in and analyse logs to realize that
> deletedomain was perhaps fine but vm creation has failed.
> 
> That's a pointless effort. I'm sure there are others in the automated tests
> that do this kind of wasteful testing. So please please pleaes &*()#@()#
> please review test plans before automating them!
> 
> I'm not going to be looking at this forever to fix these issues when we want
> to see pretty metrics and numbers.
> 
> --
> Prasanna.,
> 
> 
> Powered by BigRock.com

Re: Template Question

[Mike Tutkowski]

It does seem indeterministic. Sometimes there are two; sometimes there is
only one.


On Thu, Jul 18, 2013 at 4:23 AM, Devdeep Singh wrote:

> Changes were made recently to allow some commands to execute in parallel
> on a hypervisor resource. Maybe that is causing it.
>
> Regards,
> Devdeep
>
> > -Original Message-
> > From: Koushik Das [mailto:koushik@citrix.com]
> > Sent: Thursday, July 18, 2013 3:11 PM
> > To: dev@cloudstack.apache.org
> > Subject: RE: Template Question
> >
> > I am also seeing it.
> >
> > -Koushik
> >
> > > -Original Message-
> > > From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com]
> > > Sent: Wednesday, July 17, 2013 9:22 PM
> > > To: dev@cloudstack.apache.org
> > > Subject: Template Question
> > >
> > > Hi,
> > >
> > > I've noticed recently on XenServer when SSVM and CPVM are deployed
> > > that Template routing-1 appears twice in my Disks list (it used to
> > > appear only once).
> > >
> > > Is this change in behavior expected?
> > >
> > > Thanks!
> > >
> > > --
> > > *Mike Tutkowski*
> > > *Senior CloudStack Developer, SolidFire Inc.*
> > > e: mike.tutkow...@solidfire.com
> > > o: 303.746.7302
> > > Advancing the way the world uses the
> > > cloud
> > > *(tm)*
>



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

Regarding the bug Cloudstack-3589 VM created from VPC network is not getting IP

[Bharat Kumar]

Hi Dann,

The bug fix  
https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=commitdiff;h=b903262df5e2ff5d174859ce28abae75c4689f0c
 is 
causing an null value in dnsmasq.config file while creating VPC network (bug-id 
Cloudstack-3589 ).  

Can you please take a look at this.

Regards,
Bharat.

Re: Review Request 11479: SolidFire storage plug-in and enhancements to the storage framework and GUI

[Mike Tutkowski]

> On May 31, 2013, 2:32 p.m., Wei Zhou wrote:
> > Mike,
> > 
> > I think it is better to create a table for SolidFire instead of changing 
> > disk_offering table.
> > It is not a good idea to change disk_offering for a specific vendor.
> > You can have a look at what nicira did in the past, maybe it helps you.
> > 
> > 
> > -Wei
> 
> John Burwell wrote:
> +1 to this notion.  Could we achieve the same goal by adding a column to 
> the disk_offering table that contained a JSON string of extended, vendor 
> specific attributes?  On the Java interface side, the JSON document would 
> represented as a Map from the appropriate interface with 
> driver implementations responsible for validating their contents.  This 
> approach would reduce the situations where a driver would require schema 
> modifications.

I'm not sure how the Storage Quality of Service fields are any different (in 
principal) from the Hypervisor Quality of Service fields. The Hypervisor QoS 
fields are storaged in the disk_offering table right next to the Storage QoS 
ones. Not all hypervisors will support the Hypervisor QoS fields just like not 
all storage will support the storage QoS fields.

If we change the storage QoS fields to reside elsewhere, we should do the same 
for the hypervisor QoS fields.

We should make a decision on this, though, quickly because we are SUPER late in 
the game here and changes like this will invalidate all of the testing I've 
performed over the past couple weeks (as well as whatever testing Wei has 
performed).

Thanks!


- Mike


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


On June 21, 2013, 10:35 a.m., Mike Tutkowski wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/11479/
> ---
> 
> (Updated June 21, 2013, 10:35 a.m.)
> 
> 
> Review request for cloudstack, edison su and John Burwell.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> This patch implements a storage plug-in for SolidFire. The plug-in is based 
> on the new storage framework that went in with 4.2, as well.
> 
> In addition, there are GUI (and related) changes to enable admins and end 
> users to specify a Min, Max, and Burst number of IOPS for a Disk Offering. 
> These fields (although optional) tend to follow the pattern previously 
> established for the Disk Size field.
> 
> Also, the storage framework itself has been enhanced. For example, it now 
> supports creating and deleting storage repositories as is necessary for a 
> dynamic type of zone-wide primary storage (such as the SolidFire plug-in is).
> 
> The desired behavior of the software is as such:
> 
> * Allow an admin to invoke the CloudStack API to add Primary Storage based on 
> the SolidFire plug-in.
> 
> * Allow an admin to create a Disk Offering that specifies a Min, Max, and 
> Burst number of IOPS or allows the admin to pass this ability on to the end 
> user.
> 
> * Allow an end user to execute such a Disk Offering. As is the case for any 
> Disk Offering, this leads to the creation of a row in the volumes table.
> 
> * Allow an end user to attach the resultant volume (noted in the DB) to a VM. 
> The storage framework invokes logic in the plug-in and the plug-in creates a 
> volume on its SAN with the correct size and IOPS values. The agent software 
> for XenServer detects that such an attach is being requested and creates a 
> Storage Repository (and single VDI within the SR) based on the storage IP 
> address of the SAN and the IQN of the volume. The VDI is then hooked up to 
> the VM.
> 
> * Allow an end user to detach the volume. This leads to the destruction of 
> the SR, but the SAN volume remains intact and can be reattached later to any 
> VM running in a XenServer resource pool in the zone.
> 
> * Allow an end user to delete the volume. This leads to the volume being 
> deleted on the SAN and being marked in the CloudStack DB as deleted.
> 
> 
> Diffs
> -
> 
>   api/src/com/cloud/offering/DiskOffering.java ae4528c 
>   api/src/com/cloud/storage/StoragePool.java 8b95383 
>   api/src/com/cloud/storage/Volume.java 4903594 
>   api/src/org/apache/cloudstack/api/ApiConstants.java 1704ca3 
>   
> api/src/org/apache/cloudstack/api/command/admin/offering/CreateDiskOfferingCmd.java
>  a2c5f77 
>   
> api/src/org/apache/cloudstack/api/command/admin/storage/CreateStoragePoolCmd.java
>  74eb2b9 
>   api/src/org/apache/cloudstack/api/command/user/volume/CreateVolumeCmd.java 
> 86a494b 
>   api/src/org/apache/cloudstack/api/response/DiskOfferingResponse.java 
> 35cf21a 
>   api/src/org/apache/cloudstack/api/response/StoragePoolResponse.java 965407d 
>   api/src/org/apache/cloudstack/api/response/

Re: Review Request 11479: SolidFire storage plug-in and enhancements to the storage framework and GUI

[Mike Tutkowski]

> On June 28, 2013, 9:42 a.m., John Burwell wrote:
> > api/src/com/cloud/offering/DiskOffering.java, line 60
> > 
> >
> > When would it be valid for the value of this property to be null?  
> > Seems like it should be boolean, not Boolean.
> 
> Mike Tutkowski wrote:
> null is used if this feature is not in use.
> 
> John Burwell wrote:
> What is the difference between false and null?

null means storage QoS is not in use.

false means storage QoS is in use and the admin has selected the min and max 
IOPS values.

true means storage QoS is in use and the admin has not selected the min and max 
IOPS values (the end user can select them).


- Mike


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


On June 21, 2013, 10:35 a.m., Mike Tutkowski wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/11479/
> ---
> 
> (Updated June 21, 2013, 10:35 a.m.)
> 
> 
> Review request for cloudstack, edison su and John Burwell.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> This patch implements a storage plug-in for SolidFire. The plug-in is based 
> on the new storage framework that went in with 4.2, as well.
> 
> In addition, there are GUI (and related) changes to enable admins and end 
> users to specify a Min, Max, and Burst number of IOPS for a Disk Offering. 
> These fields (although optional) tend to follow the pattern previously 
> established for the Disk Size field.
> 
> Also, the storage framework itself has been enhanced. For example, it now 
> supports creating and deleting storage repositories as is necessary for a 
> dynamic type of zone-wide primary storage (such as the SolidFire plug-in is).
> 
> The desired behavior of the software is as such:
> 
> * Allow an admin to invoke the CloudStack API to add Primary Storage based on 
> the SolidFire plug-in.
> 
> * Allow an admin to create a Disk Offering that specifies a Min, Max, and 
> Burst number of IOPS or allows the admin to pass this ability on to the end 
> user.
> 
> * Allow an end user to execute such a Disk Offering. As is the case for any 
> Disk Offering, this leads to the creation of a row in the volumes table.
> 
> * Allow an end user to attach the resultant volume (noted in the DB) to a VM. 
> The storage framework invokes logic in the plug-in and the plug-in creates a 
> volume on its SAN with the correct size and IOPS values. The agent software 
> for XenServer detects that such an attach is being requested and creates a 
> Storage Repository (and single VDI within the SR) based on the storage IP 
> address of the SAN and the IQN of the volume. The VDI is then hooked up to 
> the VM.
> 
> * Allow an end user to detach the volume. This leads to the destruction of 
> the SR, but the SAN volume remains intact and can be reattached later to any 
> VM running in a XenServer resource pool in the zone.
> 
> * Allow an end user to delete the volume. This leads to the volume being 
> deleted on the SAN and being marked in the CloudStack DB as deleted.
> 
> 
> Diffs
> -
> 
>   api/src/com/cloud/offering/DiskOffering.java ae4528c 
>   api/src/com/cloud/storage/StoragePool.java 8b95383 
>   api/src/com/cloud/storage/Volume.java 4903594 
>   api/src/org/apache/cloudstack/api/ApiConstants.java 1704ca3 
>   
> api/src/org/apache/cloudstack/api/command/admin/offering/CreateDiskOfferingCmd.java
>  a2c5f77 
>   
> api/src/org/apache/cloudstack/api/command/admin/storage/CreateStoragePoolCmd.java
>  74eb2b9 
>   api/src/org/apache/cloudstack/api/command/user/volume/CreateVolumeCmd.java 
> 86a494b 
>   api/src/org/apache/cloudstack/api/response/DiskOfferingResponse.java 
> 35cf21a 
>   api/src/org/apache/cloudstack/api/response/StoragePoolResponse.java 965407d 
>   api/src/org/apache/cloudstack/api/response/VolumeResponse.java e3463bd 
>   client/WEB-INF/classes/resources/messages.properties a0a36c8 
>   client/pom.xml ab758eb 
>   client/tomcatconf/applicationContext.xml.in 049e483 
>   core/src/com/cloud/agent/api/AttachVolumeAnswer.java b377b7c 
>   core/src/com/cloud/agent/api/AttachVolumeCommand.java 2658262 
>   core/test/org/apache/cloudstack/api/agent/test/AttachVolumeAnswerTest.java 
> 251a6cb 
>   core/test/org/apache/cloudstack/api/agent/test/AttachVolumeCommandTest.java 
> 1ec416a 
>   
> core/test/org/apache/cloudstack/api/agent/test/BackupSnapshotCommandTest.java 
> 44d53aa 
>   core/test/org/apache/cloudstack/api/agent/test/SnapshotCommandTest.java 
> c2d69c0 
>   core/test/src/com/cloud/agent/api/test/ResizeVolumeCommandTest.java 02085f5 
>   
> engine/api/src/org/apache/cloudstack/engine/subsyst

Re: Is it possible for reviewer to add other reviewers in the reviewboard?

[Sheng Yang]

We need some mechanism to help on review board. Sometime the people didn't
know who to ask for review and sometime committer push the code they didn't
familiar with.

I decided to spend much more time on reviewing code during 4.2 release
period, trying to make sure I would review everything on network part, and
also change reviewer(potentially follow up) to ensure the expert on the
certain area has a chance to take a look at the code before the patch
checked in.

Let's see how it would go...

--Sheng


On Thu, Jul 18, 2013 at 9:18 AM, Prasanna Santhanam  wrote:

> On Thu, Jul 18, 2013 at 06:07:48PM +0200, Daan Hoogland wrote:
> > this has been kind of bugging me too. Along with unanswered questions on
> > teh list by newbees like me. As we all depend on volunteers and
> > conculeagues I don't really see a solution but reporting on outstanding
> > reviews and maybe unanswered questions. The latter can only be done
> > manually though, as it is really hard to automatically determine that a
> > mail requires reply. I kept track of the unanswered mails for one week
> > after ccc13. It were six that I didn't have time to gain knowledge to
> > answer. This is not extreme, but still may be a waste as some of the
> posing
> > people might have been thrown of the cloudstack track by them. Hugo said
> he
> > had a script querying the review board for old reviews and an automated
> > report on that would be easier. I know all you guru's do your best but a
> > weekly report, keeping us all conscious might help.
> >
> Yes - Rohit wrote the script and I send it sometimes before things
> like freeze/deadlines to alert the community but everyone's like ...
> meh.
>
> https://github.com/vogxn/RBTool (that's the tool)
>
> We should also have IRC alerts via ASFBot for every rb request posted
> and merged.  I was going to work on this with Humbeedoh (INFRA) but am
> yet to get to it. Feel free to pick it up - ASFBot is written in Lua.
>
> If you can't convince the people, try write tools around it eh?
>
>
> > As you might have guessed this is me volunteering to keep track of
> > unanswered questions for a few weeks. As we go along good ideas on how to
> > improve our way might spring up. /me is an optimist at rare occasions.
>
> I rant and go do the postive thing hoping for it to be picked up.
> Guess that makes me an optimist :)
>
> --
> Prasanna.,
>
> 
> Powered by BigRock.com
>
>

Why are these code in utils?

[Alex Huang]

As part of the work to merge vmsync over to master, I've been combing through 
our code.

I'm surprised to find the following code in the utils package.

Cisco n1kv.vsm
S3
Swift

The intent of the utils package is to provide generic java software libraries 
that all other cloudstack libraries to use.  These packages do not belong here.

--Alex

Re: Why are these code in utils?

[Prasanna Santhanam]

On Thu, Jul 18, 2013 at 05:01:54PM +, Alex Huang wrote:
> As part of the work to merge vmsync over to master, I've been combing through 
> our code.
> 
> I'm surprised to find the following code in the utils package.
> 
> Cisco n1kv.vsm
> S3
> Swift
> 
> The intent of the utils package is to provide generic java software
> libraries that all other cloudstack libraries to use.  These
> packages do not belong here.
> 
> --Alex
I was going to pull in another item into utils wherein OTW params sent
as maps could be translated to what the service layer expects as
Map but wasn't sure if it should go here. I guess it
should now that you mention it?

-- 
Prasanna.,


Powered by BigRock.com

Re: Ending IRC Meetings

[David Nalley]

On Wed, Jul 17, 2013 at 6:04 PM, Donal Lafferty
 wrote:
>
>> -Original Message-
>> From: David Nalley [mailto:da...@gnsa.us]
>> Sent: 17 July 2013 6:46 PM
>> To: dev@cloudstack.apache.org
>> Subject: Re: Ending IRC Meetings
>>
>> On Wed, Jul 17, 2013 at 1:43 PM, Joe Brockmeier  wrote:
>> >
>> > At this point, I'm going to suggest we take the weekly meeting off the
>> > schedule. If there's a need down the road to set up a weekly meeting,
>> > we can always fire it up again.
>> >
>> > Best,
>> >
>>
>> As someone who is frequently absent - I agree.
>> I find that I can either find folks, tell ASFbot my message, or if really
>> necessary fire an email to the list.
>>
>> --David
> [Donal Lafferty]
> ASFBot?
>
> In a nutshell, what can it do for me?

http://wilderness.apache.org/manual.html

Re: Review Request 12702: Fix CopyCmdAnswer returned by backupSnapshotCommand for VMware

[edison su]

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

Ship it!


Ship It!

- edison su


On July 18, 2013, 4:29 a.m., Sateesh Chodapuneedi wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/12702/
> ---
> 
> (Updated July 18, 2013, 4:29 a.m.)
> 
> 
> Review request for cloudstack, edison su, Fang Wang, and Kelven Yang.
> 
> 
> Bugs: CLOUDSTACK-3595
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Even after successful backup of snapshot to secondary storage, CopyCmdAnswer 
> is sent with failure result.
> Now sending pass result with full path of backup set to snapshotTO object.
> 
> 
> Diffs
> -
> 
>   
> plugins/hypervisors/vmware/src/com/cloud/storage/resource/VmwareStorageProcessor.java
>  4113803 
> 
> Diff: https://reviews.apache.org/r/12702/diff/
> 
> 
> Testing
> ---
> 
> Created snapshot from volume in cloudstack deployed over VMware servers.
> 
> 
> Thanks,
> 
> Sateesh Chodapuneedi
> 
>

RE: [DISCUSS] Upgrade path to ACS 4.2 from CCP

[Sudha Ponnaganti]

Citrix QA would test the upgrades on the suggested paths. 
> The proposed upgrade paths are CCP3.0.4, CCP3.0.5, CCP3.06, CCP3.0.7 to ACS4.2

So far it is always testing from all versions to current release.  Hope with 
the suggestion from Hugo/Chip, this can be reduced to checkpoint releases.  



-Original Message-
From: Chip Childers [mailto:chip.child...@sungard.com] 
Sent: Thursday, July 18, 2013 6:49 AM
To: dev@cloudstack.apache.org
Subject: Re: [DISCUSS] Upgrade path to ACS 4.2 from CCP

On Wed, Jul 17, 2013 at 11:43:49PM +, Animesh Chaturvedi wrote:
> 
> Folks
> 
> We have an upgrade path from CCP 3.0.2 to 4.0 ACS and since then we have 
> diverged. I would like to propose adding upgrade path from later CCP versions 
> to ACS 4.2 which provides customers the choice to move to ACS from CCP and 
> also brings CCP closer to upstream ACS releases.
> 
> The proposed upgrade paths are CCP3.0.4, CCP3.0.5, CCP3.06, CCP3.0.7 to 
> ACS4.2. Please provide your feedback.
> 
> Thanks
> Animesh
> 
> 
> 
>

Generally...  +1000.  I think that this is a wonderful idea.

I have a couple of thoughts:  

We will really need to implement the "checkpoint"
version concept that Hugo proposed earlier [1].  The reason that I say this, is 
that the source and binaries for CCP aren't available to non-customers of 
citrix / non-citrix devs.  

I obviously assume that Citrix is officially OK with this (and you are 
basically representing that to the list).  Given that "ok", I further assume 
that Citrix employeed engineers would do the work (since they have access to 
the CCP releases).

Once the upgrades are in ACS, we would want to reduce the testing effort around 
them going forward by ensuring that the targeted ACS release that we test the 
upgrades to will be one of the "checkpoint" releases per Hugo's proposal.

Last thought...  this doesn't seem like a 4.2 change to me.  Isn't it too late 
to deal with testing it now?  If not, and there are people ready to roll, then 
no worries.  I'm just pointing out what may be
obvious:  you've hit feature freeze, and this seems like a significant amount 
of work.

-chip

[1] http://markmail.org/thread/p34jbalr25pwocez

RE: Why are these code in utils?

[Edison Su]

For s3/swift, both secondary storage code and storage plugin will access 
S3/Swift library.
What you suggestion to put these library?

> -Original Message-
> From: Alex Huang [mailto:alex.hu...@citrix.com]
> Sent: Thursday, July 18, 2013 10:02 AM
> To: dev@cloudstack.apache.org
> Subject: Why are these code in utils?
> 
> As part of the work to merge vmsync over to master, I've been combing
> through our code.
> 
> I'm surprised to find the following code in the utils package.
> 
> Cisco n1kv.vsm
> S3
> Swift
> 
> The intent of the utils package is to provide generic java software libraries
> that all other cloudstack libraries to use.  These packages do not belong 
> here.
> 
> --Alex

RE: deleteAffinityGroup API

[Prachi Damle]

Hi Alex,

The error thrown while deleting affinitygroup by Id is: " Account and domainId 
are needed for resource creation "


Many of our APIs call AccntManager to figure out owner of the resources the API 
is working on like this:

Account caller = CallContext.current().getCallingAccount(); //earlier 
it was using UserContext and was replaced by CallContext
Account owner = _accountMgr.finalizeOwner(caller, account, domainId, 
null);

And AccountManager: finalizeOwner has this check at start:

if (caller.getId() == Account.ACCOUNT_ID_SYSTEM && ((accountName == 
null || domainId == null) && projectId == null)) {
throw new InvalidParameterValueException("Account and domainId are 
needed for resource creation");
}


Now the CallContext.current().getCallingAccount(); is returning the System user 
causing the subsequent failure. Why would it return system user, if the caller 
is admin user?

Thanks,
Prachi

-Original Message-
From: Prasanna Santhanam [mailto:t...@apache.org] 
Sent: Thursday, July 18, 2013 6:09 AM
To: dev@cloudstack.apache.org
Subject: Re: deleteAffinityGroup API

On Thu, Jul 18, 2013 at 02:17:46PM +0530, Prasanna Santhanam wrote:
> On Thu, Jul 18, 2013 at 07:14:42AM +, Prachi Damle wrote:
> > Account and domainId are not required parameters of this API. It 
> > works fine with just an id too.
> > 
> > Account and domain will be used if delete is called providing a name 
> > of the group instead of id, say by an admin for a regular user's 
> > group.
> > 
> 
> Thanks Prachi - I think it is related to the recent changes in 
> CallContext that is making the user system for the API call preventing 
> it from deleteing the aff.group with just an id. Filed a bug for it.

Ok - Alex mentioned the bug is 'Not a Problem'. So it's only the background CS 
workers which use the CallContext. But the affinity group is still failing to 
delete using the id. 

--
Prasanna.,


Powered by BigRock.com

[ACS 4.1.1] Bug fixes applicable to 4.1.1

[Musayev, Ilya]

Dear ACS Dev Community,

We need help with identifying which bug fixes in 4.2 or 4.0 need to be 
back-ported to 4.1 before ACS 4.1.1 release.

If you've released a bug fix that is applicable to 4.1, please kindly back-port 
or let me know and I will do it on your behalf.

We need a response by next Tuesday, July 18th.

Thank you for making ACS a better cloud platform,

Regards
ilya

Re: Why are these code in utils?

[John Burwell]

Edison,

I suggest creating a utils model in engine/storage in package 
org.apache.cloudstack.engine.storage.utils.  When I Swift and S3 were 
originally implemented, we didn't have such a good place to put these types of 
classes.  Now that we have a more robust module structure, it seems appropriate 
to move them out. 

Thanks,
-John

On Jul 18, 2013, at 1:53 PM, Edison Su  wrote:

> For s3/swift, both secondary storage code and storage plugin will access 
> S3/Swift library.
> What you suggestion to put these library?
> 
>> -Original Message-
>> From: Alex Huang [mailto:alex.hu...@citrix.com]
>> Sent: Thursday, July 18, 2013 10:02 AM
>> To: dev@cloudstack.apache.org
>> Subject: Why are these code in utils?
>> 
>> As part of the work to merge vmsync over to master, I've been combing
>> through our code.
>> 
>> I'm surprised to find the following code in the utils package.
>> 
>> Cisco n1kv.vsm
>> S3
>> Swift
>> 
>> The intent of the utils package is to provide generic java software libraries
>> that all other cloudstack libraries to use.  These packages do not belong 
>> here.
>> 
>> --Alex
> 

Re: code formatting for enums

[John Burwell]

All,

Another thing I have noticed is that enum values are not capitalized.  General 
coding convention is that enum values are declared in all caps using an 
underscore to separate words.  I notice that our coding conventions are silent 
on enumerations.  Any opposition to adding this rule to our coding conventions?

Thanks,
-John

On Jul 17, 2013, at 12:24 PM, Alex Huang  wrote:

> That's because the first rule of auto-formatting is do no harm.
> 
> The formatter is set not to screw with lines that are already wrapped 
> assuming the previous developer intended it that way.
> 
> --Alex
> 
>> -Original Message-
>> From: Daan Hoogland [mailto:daan.hoogl...@gmail.com]
>> Sent: Wednesday, July 17, 2013 8:23 AM
>> To: dev
>> Subject: Re: code formatting for enums
>> 
>> thanks,
>> it doesn't correct back to the one per line format, but at least it doesn't
>> garble the enum when right anymore.
>> 
>> 
>> 
>> On Wed, Jul 17, 2013 at 4:24 PM, Alex Huang  wrote:
>> 
>>> Windows->Preferences
>>> Java->Formatter
>>> Click on Edit in Active Profiles
>>> Line Wrapping tab
>>> Look for 'enum' declaration->Constants Select Wrap all elements, every
>>> element on a new line in the "Line Wrapping policy:" drop down
>>> 
>>> --Alex
>>> 
>>> 
 -Original Message-
 From: Daan Hoogland [mailto:daan.hoogl...@gmail.com]
 Sent: Wednesday, July 17, 2013 6:22 AM
 To: dev
 Subject: code formatting for enums
 
 H,
 
 I am working on Networks with the eclipse.epf file loaded. Now the
 enum BroadcastDomainType gets saved as
Native(null, null), Vlan("vlan", Integer.class), Vswitch("vs",
String.class), LinkLocal(null, null), Vnet("vnet",
>>> Long.class), Storage(
"storage", Integer.class), Lswitch("lswitch",
>>> String.class), Mido(
"mido", String.class), Pvlan("pvlan", String.class),
>>> UnDecided(
null, null);
 instead of
Native(null, null),
Vlan("vlan", Integer.class),
Vswitch("vs", String.class),
LinkLocal(null, null),
Vnet("vnet", Long.class),
Storage("storage", Integer.class),
Lswitch("lswitch", String.class),
Mido("mido", String.class),
Pvlan("pvlan", String.class),
UnDecided(null, null);
 anybody know how to fix this?
 
 thanks,
 Daan
>>> 

Re: [DISCUSS] coding convention for method - and class length

[Mike Tutkowski]

I'm not sure how I feel about an arbitrary number of lines per method
(although 200 is obviously quite high and I would recommend modularizing
such a method), but I'm not in favor of limiting the number of methods per
class (especially not to just 10). Some types of objects simply need many
discrete operations and 10 is too limiting.


On Tue, Jul 16, 2013 at 6:14 AM, Daan Hoogland wrote:

> I am all for re-oping discussions on the ten commandments, but let's stick
> to method and class level for now.
>
>
>
>
> On Tue, Jul 16, 2013 at 12:19 PM, Donal Lafferty
> wrote:
>
> > Hmm.  The original comment was "maximum length of 80 lines per method".
> >
> > Did you want to start a new thread covering max characters per line?
> >
> > > -Original Message-
> > > From: Isaac Chiang [mailto:isaacchi...@gmail.com]
> > > Sent: 16 July 2013 11:12 AM
> > > To: dev@cloudstack.apache.org
> > > Subject: Re: [DISCUSS] coding convention for method - and class length
> > >
> > > +1 for the maximum length per line
> > >
> > > I also agree with Wido that around 120 characters will be more fit
> > current
> > > needs.
> > >
> > >
> > > Regards
> > >
> > > Isaac
> >
>



-- 
*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: Why are these code in utils?

[Alex Huang]

+1

> -Original Message-
> From: John Burwell [mailto:jburw...@basho.com]
> Sent: Thursday, July 18, 2013 12:25 PM
> To: dev@cloudstack.apache.org
> Subject: Re: Why are these code in utils?
> 
> Edison,
> 
> I suggest creating a utils model in engine/storage in package
> org.apache.cloudstack.engine.storage.utils.  When I Swift and S3 were
> originally implemented, we didn't have such a good place to put these types
> of classes.  Now that we have a more robust module structure, it seems
> appropriate to move them out.
> 
> Thanks,
> -John
> 
> On Jul 18, 2013, at 1:53 PM, Edison Su  wrote:
> 
> > For s3/swift, both secondary storage code and storage plugin will access
> S3/Swift library.
> > What you suggestion to put these library?
> >
> >> -Original Message-
> >> From: Alex Huang [mailto:alex.hu...@citrix.com]
> >> Sent: Thursday, July 18, 2013 10:02 AM
> >> To: dev@cloudstack.apache.org
> >> Subject: Why are these code in utils?
> >>
> >> As part of the work to merge vmsync over to master, I've been combing
> >> through our code.
> >>
> >> I'm surprised to find the following code in the utils package.
> >>
> >> Cisco n1kv.vsm
> >> S3
> >> Swift
> >>
> >> The intent of the utils package is to provide generic java software
> >> libraries that all other cloudstack libraries to use.  These packages do 
> >> not
> belong here.
> >>
> >> --Alex
> >

Re: [DISCUSS] coding convention for method - and class length

[Chip Childers]

On Thu, Jul 18, 2013 at 02:34:36PM -0600, Mike Tutkowski wrote:
> I'm not sure how I feel about an arbitrary number of lines per method
> (although 200 is obviously quite high and I would recommend modularizing
> such a method), but I'm not in favor of limiting the number of methods per
> class (especially not to just 10). Some types of objects simply need many
> discrete operations and 10 is too limiting.

+1 to both thoughts.

Smaller methods is good, but a specific number of lines as policy vs. a rule 
of thumb are two different things.

I completely agree with Daan's underlying concern though...  some of
these class files are horrible to try and comprehend.

My favorite example:

https://git-wip-us.apache.org/repos/asf/cloudstack/?p=cloudstack.git;a=blob_plain;f=plugins/hypervisors/xen/src/com/cloud/hypervisor/xen/resource/CitrixResourceBase.java;hb=master



> 
> 
> On Tue, Jul 16, 2013 at 6:14 AM, Daan Hoogland wrote:
> 
> > I am all for re-oping discussions on the ten commandments, but let's stick
> > to method and class level for now.
> >
> >
> >
> >
> > On Tue, Jul 16, 2013 at 12:19 PM, Donal Lafferty
> > wrote:
> >
> > > Hmm.  The original comment was "maximum length of 80 lines per method".
> > >
> > > Did you want to start a new thread covering max characters per line?
> > >
> > > > -Original Message-
> > > > From: Isaac Chiang [mailto:isaacchi...@gmail.com]
> > > > Sent: 16 July 2013 11:12 AM
> > > > To: dev@cloudstack.apache.org
> > > > Subject: Re: [DISCUSS] coding convention for method - and class length
> > > >
> > > > +1 for the maximum length per line
> > > >
> > > > I also agree with Wido that around 120 characters will be more fit
> > > current
> > > > needs.
> > > >
> > > >
> > > > Regards
> > > >
> > > > Isaac
> > >
> >
> 
> 
> 
> -- 
> *Mike Tutkowski*
> *Senior CloudStack Developer, SolidFire Inc.*
> e: mike.tutkow...@solidfire.com
> o: 303.746.7302
> Advancing the way the world uses the
> cloud
> *™*

Review Request 12743: removed unused class and related test utils

[Laszlo Hornyak]

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

Review request for cloudstack.


Repository: cloudstack-git


Description
---

MethodCapturer and related test utilities was not used


Diffs
-

  utils/src/com/cloud/utils/MethodCapturer.java f9fe046 
  utils/test/com/cloud/utils/DummyImpl.java 467d8e2 
  utils/test/com/cloud/utils/DummyInterface.java f79a53e 
  utils/test/com/cloud/utils/DummyPremiumImpl.java bf8bfea 

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


Testing
---


Thanks,

Laszlo Hornyak

Review Request 12744: Removed unused classes

[Laszlo Hornyak]

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

Review request for cloudstack.


Repository: cloudstack-git


Description
---

ScriptBuilder and Executor was not actually used.


Diffs
-

  utils/src/com/cloud/utils/script/Executor.java 4e70a77 
  utils/src/com/cloud/utils/script/Script.java d3a3591 
  utils/src/com/cloud/utils/script/ScriptBuilder.java 96cadfb 

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


Testing
---


Thanks,

Laszlo Hornyak

RE: [DISCUSS] coding convention for method - and class length

[Donal Lafferty]

> -Original Message-
> From: Chip Childers [mailto:chip.child...@sungard.com]
> Sent: 18 July 2013 9:43 PM
> To: dev@cloudstack.apache.org
> Subject: Re: [DISCUSS] coding convention for method - and class length
> 
> On Thu, Jul 18, 2013 at 02:34:36PM -0600, Mike Tutkowski wrote:
> > I'm not sure how I feel about an arbitrary number of lines per method
> > (although 200 is obviously quite high and I would recommend
> > modularizing such a method), but I'm not in favor of limiting the
> > number of methods per class (especially not to just 10). Some types of
> > objects simply need many discrete operations and 10 is too limiting.
> 
> +1 to both thoughts.
> 
> Smaller methods is good, but a specific number of lines as policy vs. a rule 
> of
> thumb are two different things.
> 
> I completely agree with Daan's underlying concern though...  some of these
> class files are horrible to try and comprehend.
> 
> My favorite example:
> 
> https://git-wip-
> us.apache.org/repos/asf/cloudstack/?p=cloudstack.git;a=blob_plain;f=plugin
> s/hypervisors/xen/src/com/cloud/hypervisor/xen/resource/CitrixResourceB
> ase.java;hb=master
> 
[Donal Lafferty] 
StyleCheck sets a default limit of 150 lines.

Meanwhile, have you heard of the function 'best kick' in a certain company's 
soccer video game?  IIRC, it's several 1000 lines.

Re: [jira] [Commented] (CLOUDSTACK-3163) KVM Virtual Router startup time is painfully long

[Marcus Sorensen]

... and each vmdata.sh calls ssh and/or scp several times. Off the top
of my head, it seems like we could serialize that cmd.getVmData()
output to maybe JSON or something, get it up on the router in one
call, and then process it there in a python script.

On Thu, Jul 18, 2013 at 7:08 AM, Wido den Hollander (JIRA)
 wrote:
>
> [ 
> https://issues.apache.org/jira/browse/CLOUDSTACK-3163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13712294#comment-13712294
>  ]
>
> Wido den Hollander commented on CLOUDSTACK-3163:
> 
>
> So, I took a quick peek at how this works and I see it does about 13 calls on 
> my set up, of which 11 are calling "vmdata.sh" with different parameters.
>
> I think that can be brought back to one call, bringing the total (in my 
> setup) back to 3 instead of 13.
>
> I'll see if I can find the time to test this out.
>
>> KVM Virtual Router startup time is painfully long
>> -
>>
>> Key: CLOUDSTACK-3163
>> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3163
>> Project: CloudStack
>>  Issue Type: Bug
>>  Security Level: Public(Anyone can view this level - this is the 
>> default.)
>>  Components: KVM
>>Affects Versions: pre-4.0.0
>> Environment: CloudPlatform 3.0.3, but I don't see any changes to the 
>> relevant code (I think) on master
>>Reporter: Andrew Bayer
>>Priority: Critical
>>
>> When you've got a couple thousand instances, spread across 10 or so pods, 
>> virtual router startup time is near crippling - actually, if you don't 
>> enable the option to have virtual routers only populated with instances in 
>> their pod, it *is* crippling, in that the virtual routers don't finish 
>> starting before the management server decides they've timed out and tries to 
>> start a new one.
>> This seems to be the result of a few painful inefficiencies:
>> - The same codepath is followed whether you're adding a new instance to an 
>> already running VR, or adding two hundred already running instances to a new 
>> VR. So each ssh/scp/sed/cp/chmod/etc command is replicated for each 
>> instance, rather than finding efficiencies by doing things across the whole 
>> set of instances.
>> - But what really eats up the time is the population of vm data - for each 
>> piece of vm data (which, from a rough look at the code, seems to be 
>> something like 10 or 11 data files), there are something like 7 ssh calls 
>> and an scp call. So that means that per instance, we have somewhere around 
>> 80 to 90 ssh/scp calls, plus the single ssh call for dhcp_entry.sh. So with 
>> 200 instances, that's 1600 to 1800 ssh/scp calls on a single VR, with all 
>> the overhead entailed in opening that many ssh connections, starting bash, 
>> etc, etc... Given that in my experience, a VR with ~200 instances takes ~90 
>> minutes to start up (I may be misremembering slightly - it could be ~200 
>> instances takes closer to 60 minutes, and ~300 takes closer to 90), that 
>> works out to 3 seconds or so per ssh/scp, which doesn't seem implausible to 
>> me.
>> So, this shouldn't be this way. At a minimum, there's no reason not to 
>> offload the whole process from a script run on the host making repeated ssh 
>> calls to the VR to a script on the VR that gets called from the host, albeit 
>> possibly a temporary one that's generated on the fly and copied over to the 
>> VR. That alone would probably save most of the VR startup time, just by 
>> dropping the number of ssh/scp connections per instance from 80-90 to 3 
>> (dhcp_entry.sh call, scp of temporary script, execution of temporary script).
>
> --
> This message is automatically generated by JIRA.
> If you think it was sent incorrectly, please contact your JIRA administrators
> For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: [DISCUSS] coding convention for method - and class length

[Mike Tutkowski]

Like eight or so years ago, I sent a method I had to modify to the printer
(so I could study it on regular paper) and it came out on 14 pages.


On Thu, Jul 18, 2013 at 3:04 PM, Donal Lafferty
wrote:

> > -Original Message-
> > From: Chip Childers [mailto:chip.child...@sungard.com]
> > Sent: 18 July 2013 9:43 PM
> > To: dev@cloudstack.apache.org
> > Subject: Re: [DISCUSS] coding convention for method - and class length
> >
> > On Thu, Jul 18, 2013 at 02:34:36PM -0600, Mike Tutkowski wrote:
> > > I'm not sure how I feel about an arbitrary number of lines per method
> > > (although 200 is obviously quite high and I would recommend
> > > modularizing such a method), but I'm not in favor of limiting the
> > > number of methods per class (especially not to just 10). Some types of
> > > objects simply need many discrete operations and 10 is too limiting.
> >
> > +1 to both thoughts.
> >
> > Smaller methods is good, but a specific number of lines as policy vs. a
> rule of
> > thumb are two different things.
> >
> > I completely agree with Daan's underlying concern though...  some of
> these
> > class files are horrible to try and comprehend.
> >
> > My favorite example:
> >
> > https://git-wip-
> >
> us.apache.org/repos/asf/cloudstack/?p=cloudstack.git;a=blob_plain;f=plugin
> > s/hypervisors/xen/src/com/cloud/hypervisor/xen/resource/CitrixResourceB
> > ase.java;hb=master
> >
> [Donal Lafferty]
> StyleCheck sets a default limit of 150 lines.
>
> Meanwhile, have you heard of the function 'best kick' in a certain
> company's soccer video game?  IIRC, it's several 1000 lines.
>
>


-- 
*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: CallContexts?

[Kelven Yang]

CallContext was renamed from original UserContext. The semantic is pretty
much the same as before to API calls

Kelven

On 7/18/13 1:25 AM, "Prasanna Santhanam"  wrote:

>On Thu, Jul 18, 2013 at 11:58:30AM +0530, Prasanna Santhanam wrote:
>> I see the following repeated lines with API calls on master code
>> lately: What's the call context? and what's the role?
>> 
>> 2013-07-18 11:52:24,372 DEBUG [cloudstack.context.CallContext]
>>(RouterStatusMonitor-1:ctx-9bb138b4) Context removed CallContext[acct=1;
>>user=1; session=9bb138b4-29c1-4ddf-ab47-9307a600d31e]
>> 
>>  * CallContext records information about the environment the call is
>>made.  This
>>  * class must be always be available in all CloudStack code.
>> 
>> Does this mean we have to do something special when creating new APIs?
>>I'm not
>> quite clear from this description.
>> 
>It seems from the logs that all APIs are now getting the context as
>user=1,account=1 (SYSTEM). Filed CLOUDSTACK-3626.
>
>
>
>-- 
>Prasanna.,
>
>
>Powered by BigRock.com
>

Re: [ACS4.1.1][BLOCKER] Unable to launch VNC Console to VSphere VMs

[Kelven Yang]

I'll take a look at it. It seems that my devCloud environment failed to
get CPVM upgraded thus let my testing on this skipped with success

Kelven

On 7/17/13 8:04 PM, "Musayev, Ilya"  wrote:

>Kelven
>
>Please review the commit "73a6aa78854f379e6439bf22457094a5272cbfed",
>cloudstack-3433.
>
>After reverting this commit, everything functioned normally. We cannot
>release 4.1.1 with this defect :(
>
>Thanks
>ilya
>
>
>
>> -Original Message-
>> From: Musayev, Ilya [mailto:imusa...@webmd.net]
>> Sent: Wednesday, July 17, 2013 7:57 PM
>> To: dev@cloudstack.apache.org
>> Cc: Kelven Yang (kelven.y...@citrix.com)
>> Subject: [ACS4.1.1][BLOCKER] Unable to launch VNC Console to VSphere
>> VMs
>> 
>> Post my upgrade from 4.1 to 4.1.1 I'm unable to launch console, with
>> message Caused by: com.cloud.utils.exception.CloudRuntimeException:
>> can't find ConsoleAccessAuthenticationCommand.
>> 
>> I've looked through commit history, and it looks like the only change
>>that was
>> made is related to a commit CLOUDSTACK-3456. Not 100% certain that's
>> issue, but seems like the only change in this area.
>> 
>> Also, why do I get given the "type class
>>[Lcom.cloud.agent.api.Command;" -
>> the L appending to com.cloud seems new.
>> 
>> Log below:
>> 
>> 
>> 2013-07-17 19:38:20,949 DEBUG [agent.transport.Request]
>>(http-8080-3:null)
>> Seq 5-1052639262: Received:  { Ans: , MgmtId: 345049078181, via: 5,
>>Ver: v1,
>> Flags: 10, { GetVncPortAnswer } }
>> 2013-07-17 19:38:20,950 DEBUG [cloud.servlet.ConsoleProxyServlet] (http-
>> 8080-3:null) Port info 172.25.243.31
>> 2013-07-17 19:38:20,950 INFO  [cloud.servlet.ConsoleProxyServlet] (http-
>> 8080-3:null) Parse host info returned from executing GetVNCPortCommand.
>> host info: 172.25.243.31
>> 2013-07-17 19:38:20,958 DEBUG [cloud.servlet.ConsoleProxyServlet] (http-
>> 8080-3:null) Compose console url: https://172-24-20-
>> 22.realhostip.com/ajax?token=1LYgydVEstHtlOuUWpMC3lNponA8tI8kA10rq
>> njR1Tl1HPws9wEaTKE6IvMaV_iUtnNNqSjcoFTyO9NIDzaBTUWpfGumQ5cAijs
>> vKJ0Mx8fyQwyCDLko8ekhjIKLkngtuofPmQRbBwsfaZj6_N4JpLYKWoOVdZ6Eq
>> qerLKas1ErQ0e2yRnDvYq5C2OVSGQgl08a2RCF0WFWuYyl1HW3fDIkivzVJE9IC
>> 6266_CSEWuQV65bmjVIuUMPekgzq_R6PBm85a_wsxGX8rdae0x05UQ
>> 2013-07-17 19:38:20,958 DEBUG [cloud.servlet.ConsoleProxyServlet] (http-
>> 8080-3:null) the console url is :: rhn01t-ops-
>> 08https://172-24-20-
>> 22.realhostip.com/ajax?token=1LYgydVEstHtlOuUWpMC3lNponA8tI8kA10rq
>> njR1Tl1HPws9wEaTKE6IvMaV_iUtnNNqSjcoFTyO9NIDzaBTUWpfGumQ5cAijs
>> vKJ0Mx8fyQwyCDLko8ekhjIKLkngtuofPmQRbBwsfaZj6_N4JpLYKWoOVdZ6Eq
>> qerLKas1ErQ0e2yRnDvYq5C2OVSGQgl08a2RCF0WFWuYyl1HW3fDIkivzVJE9IC
>> 6266_CSEWuQV65bmjVIuUMPekgzq_R6PBm85a_wsxGX8rdae0x05UQ">> ame>
>> 2013-07-17 19:38:20,992 ERROR [agent.transport.Request] (AgentManager-
>> Handler-7:null) Caught problem with
>> [{"ConsoleAccessAuthenticationCommand":{"_host":"172.25.243.31","_port"
>> :"5924","_vmId":"0c9354d4-cbad-4cd0-9a38-
>> 48e0efc6a3f5","_sid":"585d97c4cf867d6d","_ticket":"7w0YL4G35QDQj79Jm3
>> h5NzNtwXo\u003d","_isReauthenticating":false,"contextMap":{},"wait":0}}]
>> com.google.gson.JsonParseException: The JsonDeserializer
>> com.cloud.agent.transport.ArrayTypeAdaptor@1aa9a7bb failed to
>> deserialize json object
>> [{"ConsoleAccessAuthenticationCommand":{"_host":"172.25.243.31","_port"
>> :"5924","_vmId":"0c9354d4-cbad-4cd0-9a38-
>> 48e0efc6a3f5","_sid":"585d97c4cf867d6d","_ticket":"7w0YL4G35QDQj79Jm3
>> h5NzNtwXo=","_isReauthenticating":false,"contextMap":{},"wait":0}}]
>>given
>> the type class [Lcom.cloud.agent.api.Command;
>>  at
>> 
>>com.google.gson.JsonDeserializerExceptionWrapper.deserialize(JsonDeserial
>> izerExceptionWrapper.java:64)
>>  at
>> 
>>com.google.gson.JsonDeserializationVisitor.invokeCustomDeserializer(JsonD
>> eserializationVisitor.java:92)
>>  at
>> 
>>com.google.gson.JsonDeserializationVisitor.visitUsingCustomHandler(JsonDe
>> serializationVisitor.java:80)
>>  at com.google.gson.ObjectNavigator.accept(ObjectNavigator.java:101)
>>  at
>> com.google.gson.JsonDeserializationContextDefault.fromJsonArray(JsonDes
>> erializationContextDefault.java:67)
>>  at
>> 
>>com.google.gson.JsonDeserializationContextDefault.deserialize(JsonDeseria
>>l
>> izationContextDefault.java:52)
>>  at com.google.gson.Gson.fromJson(Gson.java:551)
>>  at com.google.gson.Gson.fromJson(Gson.java:498)
>>  at com.cloud.agent.transport.Request.getCommands(Request.java:235)
>>  at
>> com.cloud.agent.manager.AgentManagerImpl$AgentHandler.processReque
>> st(AgentManagerImpl.java:1221)
>>  at
>> com.cloud.agent.manager.AgentManagerImpl$AgentHandler.doTask(Agent
>> ManagerImpl.java:1374)
>>  at
>> com.cloud.agent.manager.ClusteredAgentManagerImpl$ClusteredAgentHan
>> dler.doTask(ClusteredAgentManagerImpl.java:659)
>>  at com.cloud.utils.nio.Task.run(Task.java:83)
>>  at
>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.jav
>> a:1110)
>>  at
>> java.util.concurrent.ThreadPo

Re: Review Request 12716: Fix for NPE

[Sheng Yang]

> On July 18, 2013, 3:54 p.m., Sheng Yang wrote:
> > Ship It!

Pushed to 4.2 and MASTER.


- Sheng


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


On July 18, 2013, 2:10 a.m., Venkata Siva Vijayendra Bhamidipati wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/12716/
> ---
> 
> (Updated July 18, 2013, 2:10 a.m.)
> 
> 
> Review request for cloudstack, Chip Childers, edison su, Min Chen, Sateesh 
> Chodapuneedi, and Sheng Yang.
> 
> 
> Bugs: CLOUDSTACK-3598
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Minor fix for an NPE when setting resource count.
> 
> 
> Diffs
> -
> 
>   engine/schema/src/com/cloud/configuration/dao/ResourceCountDaoImpl.java 
> cfd2137 
> 
> Diff: https://reviews.apache.org/r/12716/diff/
> 
> 
> Testing
> ---
> 
> This showed up in automation tests in the code path that handles template 
> sync operations. I wasn't able to reproduce this in a manual setup. But the 
> NPE does exist and the code needs to be fixed for that, so I'm submitting the 
> patch.
> 
> 
> Thanks,
> 
> Venkata Siva Vijayendra Bhamidipati
> 
>

Review Request 12747: Fix configuration of Jetty-based execution so that CloudStack can execute scripts properly

[Donal Lafferty]

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

Review request for cloudstack, Chip Childers, Devdeep Singh, and Hugo Trippaers.


Bugs: CLOUDSTACK-3650


Repository: cloudstack-git


Description
---

CloudStack scripts fail when running on Jetty because the executable flag is 
not set on their permissions.


Diffs
-

  client/pom.xml 32ab94a3cc80d1136d962cad6493461f1d366e29 

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


Testing
---

Deployed sample XenServer cloud, verified that error message no longer appears.

Inspected file system as well.


Thanks,

Donal Lafferty

RE: [ACS4.1.1][BLOCKER] Unable to launch VNC Console to VSphere VMs

[Musayev, Ilya]

Kelven,

Perhaps I missed it,

Does CPVM needs to be upgraded from 4.1 to 4.1.1?

Thanks
ilya

> -Original Message-
> From: Kelven Yang [mailto:kelven.y...@citrix.com]
> Sent: Thursday, July 18, 2013 5:25 PM
> To: Musayev, Ilya; dev@cloudstack.apache.org
> Subject: Re: [ACS4.1.1][BLOCKER] Unable to launch VNC Console to VSphere
> VMs
> 
> I'll take a look at it. It seems that my devCloud environment failed to get
> CPVM upgraded thus let my testing on this skipped with success
> 
> Kelven
> 
> On 7/17/13 8:04 PM, "Musayev, Ilya"  wrote:
> 
> >Kelven
> >
> >Please review the commit "73a6aa78854f379e6439bf22457094a5272cbfed",
> >cloudstack-3433.
> >
> >After reverting this commit, everything functioned normally. We cannot
> >release 4.1.1 with this defect :(
> >
> >Thanks
> >ilya
> >
> >
> >
> >> -Original Message-
> >> From: Musayev, Ilya [mailto:imusa...@webmd.net]
> >> Sent: Wednesday, July 17, 2013 7:57 PM
> >> To: dev@cloudstack.apache.org
> >> Cc: Kelven Yang (kelven.y...@citrix.com)
> >> Subject: [ACS4.1.1][BLOCKER] Unable to launch VNC Console to VSphere
> >> VMs
> >>
> >> Post my upgrade from 4.1 to 4.1.1 I'm unable to launch console, with
> >> message Caused by: com.cloud.utils.exception.CloudRuntimeException:
> >> can't find ConsoleAccessAuthenticationCommand.
> >>
> >> I've looked through commit history, and it looks like the only change
> >>that was  made is related to a commit CLOUDSTACK-3456. Not 100%
> >>certain that's  issue, but seems like the only change in this area.
> >>
> >> Also, why do I get given the "type class
> >>[Lcom.cloud.agent.api.Command;" -  the L appending to com.cloud seems
> >>new.
> >>
> >> Log below:
> >>
> >>
> >> 2013-07-17 19:38:20,949 DEBUG [agent.transport.Request]
> >>(http-8080-3:null)
> >> Seq 5-1052639262: Received:  { Ans: , MgmtId: 345049078181, via: 5,
> >>Ver: v1,
> >> Flags: 10, { GetVncPortAnswer } }
> >> 2013-07-17 19:38:20,950 DEBUG [cloud.servlet.ConsoleProxyServlet]
> >>(http-
> >> 8080-3:null) Port info 172.25.243.31
> >> 2013-07-17 19:38:20,950 INFO  [cloud.servlet.ConsoleProxyServlet]
> >>(http-
> >> 8080-3:null) Parse host info returned from executing
> GetVNCPortCommand.
> >> host info: 172.25.243.31
> >> 2013-07-17 19:38:20,958 DEBUG [cloud.servlet.ConsoleProxyServlet]
> >>(http-
> >> 8080-3:null) Compose console url: https://172-24-20-
> >>22.realhostip.com/ajax?token=1LYgydVEstHtlOuUWpMC3lNponA8tI8kA10
> rq
> >>
> njR1Tl1HPws9wEaTKE6IvMaV_iUtnNNqSjcoFTyO9NIDzaBTUWpfGumQ5cAijs
> >>
> vKJ0Mx8fyQwyCDLko8ekhjIKLkngtuofPmQRbBwsfaZj6_N4JpLYKWoOVdZ6Eq
> >>
> qerLKas1ErQ0e2yRnDvYq5C2OVSGQgl08a2RCF0WFWuYyl1HW3fDIkivzVJE9IC
> >> 6266_CSEWuQV65bmjVIuUMPekgzq_R6PBm85a_wsxGX8rdae0x05UQ
> >> 2013-07-17 19:38:20,958 DEBUG [cloud.servlet.ConsoleProxyServlet]
> >>(http-
> >> 8080-3:null) the console url is :: rhn01t-ops-
> >>08https://172-24-20-
> >>22.realhostip.com/ajax?token=1LYgydVEstHtlOuUWpMC3lNponA8tI8kA10
> rq
> >>
> njR1Tl1HPws9wEaTKE6IvMaV_iUtnNNqSjcoFTyO9NIDzaBTUWpfGumQ5cAijs
> >>
> vKJ0Mx8fyQwyCDLko8ekhjIKLkngtuofPmQRbBwsfaZj6_N4JpLYKWoOVdZ6Eq
> >>
> qerLKas1ErQ0e2yRnDvYq5C2OVSGQgl08a2RCF0WFWuYyl1HW3fDIkivzVJE9IC
> >>
> 6266_CSEWuQV65bmjVIuUMPekgzq_R6PBm85a_wsxGX8rdae0x05UQ"> >> ame>
> >> 2013-07-17 19:38:20,992 ERROR [agent.transport.Request]
> >>(AgentManager-
> >> Handler-7:null) Caught problem with
> >>
> [{"ConsoleAccessAuthenticationCommand":{"_host":"172.25.243.31","_port"
> >> :"5924","_vmId":"0c9354d4-cbad-4cd0-9a38-
> >>
> 48e0efc6a3f5","_sid":"585d97c4cf867d6d","_ticket":"7w0YL4G35QDQj79Jm3
> >>
> >>h5NzNtwXo\u003d","_isReauthenticating":false,"contextMap":{},"wait":0
> }
> >>}]
> >> com.google.gson.JsonParseException: The JsonDeserializer
> >>com.cloud.agent.transport.ArrayTypeAdaptor@1aa9a7bb failed to
> >>deserialize json object
> >>[{"ConsoleAccessAuthenticationCommand":{"_host":"172.25.243.31","_po
> rt"
> >> :"5924","_vmId":"0c9354d4-cbad-4cd0-9a38-
> >>
> 48e0efc6a3f5","_sid":"585d97c4cf867d6d","_ticket":"7w0YL4G35QDQj79Jm3
> >> h5NzNtwXo=","_isReauthenticating":false,"contextMap":{},"wait":0}}]
> >>given
> >> the type class [Lcom.cloud.agent.api.Command;
> >>  at
> >>
> >>com.google.gson.JsonDeserializerExceptionWrapper.deserialize(JsonDese
> r
> >>ial
> >> izerExceptionWrapper.java:64)
> >>  at
> >>
> >>com.google.gson.JsonDeserializationVisitor.invokeCustomDeserializer(Js
> >>onD
> >> eserializationVisitor.java:92)
> >>  at
> >>
> >>com.google.gson.JsonDeserializationVisitor.visitUsingCustomHandler(Jso
> >>nDe
> >> serializationVisitor.java:80)
> >>  at com.google.gson.ObjectNavigator.accept(ObjectNavigator.java:101)
> >>  at
> >>
> >>com.google.gson.JsonDeserializationContextDefault.fromJsonArray(JsonD
> e
> >>s
> >> erializationContextDefault.java:67)
> >>  at
> >>
> >>com.google.gson.JsonDeserializationContextDefault.deserialize(JsonDese
> >>ria
> >>l
> >> izationContextDefault.java:52)
> >>  at com.google.gson.Gson.fromJson(Gson.java:551)
> >>  at com.google.gson.Gson.fromJson

RE: [ACS4.1.1][BLOCKER] Unable to launch VNC Console to VSphere VMs

[Musayev, Ilya]

When I say upgraded, I mean it needs to be trashed and redeployed.

> -Original Message-
> From: Musayev, Ilya [mailto:imusa...@webmd.net]
> Sent: Thursday, July 18, 2013 5:46 PM
> To: Kelven Yang; dev@cloudstack.apache.org
> Subject: RE: [ACS4.1.1][BLOCKER] Unable to launch VNC Console to VSphere
> VMs
> 
> Kelven,
> 
> Perhaps I missed it,
> 
> Does CPVM needs to be upgraded from 4.1 to 4.1.1?
> 
> Thanks
> ilya
> 
> > -Original Message-
> > From: Kelven Yang [mailto:kelven.y...@citrix.com]
> > Sent: Thursday, July 18, 2013 5:25 PM
> > To: Musayev, Ilya; dev@cloudstack.apache.org
> > Subject: Re: [ACS4.1.1][BLOCKER] Unable to launch VNC Console to
> > VSphere VMs
> >
> > I'll take a look at it. It seems that my devCloud environment failed
> > to get CPVM upgraded thus let my testing on this skipped with success
> >
> > Kelven
> >
> > On 7/17/13 8:04 PM, "Musayev, Ilya"  wrote:
> >
> > >Kelven
> > >
> > >Please review the commit
> "73a6aa78854f379e6439bf22457094a5272cbfed",
> > >cloudstack-3433.
> > >
> > >After reverting this commit, everything functioned normally. We
> > >cannot release 4.1.1 with this defect :(
> > >
> > >Thanks
> > >ilya
> > >
> > >
> > >
> > >> -Original Message-
> > >> From: Musayev, Ilya [mailto:imusa...@webmd.net]
> > >> Sent: Wednesday, July 17, 2013 7:57 PM
> > >> To: dev@cloudstack.apache.org
> > >> Cc: Kelven Yang (kelven.y...@citrix.com)
> > >> Subject: [ACS4.1.1][BLOCKER] Unable to launch VNC Console to
> > >> VSphere VMs
> > >>
> > >> Post my upgrade from 4.1 to 4.1.1 I'm unable to launch console,
> > >> with message Caused by:
> com.cloud.utils.exception.CloudRuntimeException:
> > >> can't find ConsoleAccessAuthenticationCommand.
> > >>
> > >> I've looked through commit history, and it looks like the only
> > >>change that was  made is related to a commit CLOUDSTACK-3456. Not
> > >>100% certain that's  issue, but seems like the only change in this area.
> > >>
> > >> Also, why do I get given the "type class
> > >>[Lcom.cloud.agent.api.Command;" -  the L appending to com.cloud
> > >>seems new.
> > >>
> > >> Log below:
> > >>
> > >>
> > >> 2013-07-17 19:38:20,949 DEBUG [agent.transport.Request]
> > >>(http-8080-3:null)
> > >> Seq 5-1052639262: Received:  { Ans: , MgmtId: 345049078181, via: 5,
> > >>Ver: v1,
> > >> Flags: 10, { GetVncPortAnswer } }
> > >> 2013-07-17 19:38:20,950 DEBUG [cloud.servlet.ConsoleProxyServlet]
> > >>(http-
> > >> 8080-3:null) Port info 172.25.243.31
> > >> 2013-07-17 19:38:20,950 INFO  [cloud.servlet.ConsoleProxyServlet]
> > >>(http-
> > >> 8080-3:null) Parse host info returned from executing
> > GetVNCPortCommand.
> > >> host info: 172.25.243.31
> > >> 2013-07-17 19:38:20,958 DEBUG [cloud.servlet.ConsoleProxyServlet]
> > >>(http-
> > >> 8080-3:null) Compose console url: https://172-24-20-
> >
> >>22.realhostip.com/ajax?token=1LYgydVEstHtlOuUWpMC3lNponA8tI8kA10
> > rq
> > >>
> >
> njR1Tl1HPws9wEaTKE6IvMaV_iUtnNNqSjcoFTyO9NIDzaBTUWpfGumQ5cAijs
> > >>
> >
> vKJ0Mx8fyQwyCDLko8ekhjIKLkngtuofPmQRbBwsfaZj6_N4JpLYKWoOVdZ6Eq
> > >>
> >
> qerLKas1ErQ0e2yRnDvYq5C2OVSGQgl08a2RCF0WFWuYyl1HW3fDIkivzVJE9IC
> > >> 6266_CSEWuQV65bmjVIuUMPekgzq_R6PBm85a_wsxGX8rdae0x05UQ
> > >> 2013-07-17 19:38:20,958 DEBUG [cloud.servlet.ConsoleProxyServlet]
> > >>(http-
> > >> 8080-3:null) the console url is :: rhn01t-ops-
> > >>08https://172-24-20-
> >
> >>22.realhostip.com/ajax?token=1LYgydVEstHtlOuUWpMC3lNponA8tI8kA10
> > rq
> > >>
> >
> njR1Tl1HPws9wEaTKE6IvMaV_iUtnNNqSjcoFTyO9NIDzaBTUWpfGumQ5cAijs
> > >>
> >
> vKJ0Mx8fyQwyCDLko8ekhjIKLkngtuofPmQRbBwsfaZj6_N4JpLYKWoOVdZ6Eq
> > >>
> >
> qerLKas1ErQ0e2yRnDvYq5C2OVSGQgl08a2RCF0WFWuYyl1HW3fDIkivzVJE9IC
> > >>
> >
> 6266_CSEWuQV65bmjVIuUMPekgzq_R6PBm85a_wsxGX8rdae0x05UQ"> > >> ame>
> > >> 2013-07-17 19:38:20,992 ERROR [agent.transport.Request]
> > >>(AgentManager-
> > >> Handler-7:null) Caught problem with
> > >>
> >
> [{"ConsoleAccessAuthenticationCommand":{"_host":"172.25.243.31","_port"
> > >> :"5924","_vmId":"0c9354d4-cbad-4cd0-9a38-
> > >>
> >
> 48e0efc6a3f5","_sid":"585d97c4cf867d6d","_ticket":"7w0YL4G35QDQj79Jm3
> > >>
> > >>h5NzNtwXo\u003d","_isReauthenticating":false,"contextMap":{},"wait":
> > >>0
> > }
> > >>}]
> > >> com.google.gson.JsonParseException: The JsonDeserializer
> > >>com.cloud.agent.transport.ArrayTypeAdaptor@1aa9a7bb failed to
> > >>deserialize json object
> >
> >>[{"ConsoleAccessAuthenticationCommand":{"_host":"172.25.243.31","_po
> > rt"
> > >> :"5924","_vmId":"0c9354d4-cbad-4cd0-9a38-
> > >>
> >
> 48e0efc6a3f5","_sid":"585d97c4cf867d6d","_ticket":"7w0YL4G35QDQj79Jm3
> > >> h5NzNtwXo=","_isReauthenticating":false,"contextMap":{},"wait":0}}]
> > >>given
> > >> the type class [Lcom.cloud.agent.api.Command;
> > >>  at
> > >>
> >
> >>com.google.gson.JsonDeserializerExceptionWrapper.deserialize(JsonDes
> > >>e
> > r
> > >>ial
> > >> izerExceptionWrapper.java:64)
> > >>  at
> > >>
> > >>com.google.gson.JsonDeserializationVisitor.invokeCustomDeserializer(
> > >>Js
> > >>onD
> > >> 

RE: [DISCUSS] Upgrade path to ACS 4.2 from CCP

[Animesh Chaturvedi]

> -Original Message-
> From: Chip Childers [mailto:chip.child...@sungard.com]
> Sent: Thursday, July 18, 2013 6:49 AM
> To: dev@cloudstack.apache.org
> Subject: Re: [DISCUSS] Upgrade path to ACS 4.2 from CCP
> 
> On Wed, Jul 17, 2013 at 11:43:49PM +, Animesh Chaturvedi wrote:
> >
> > Folks
> >
> > We have an upgrade path from CCP 3.0.2 to 4.0 ACS and since then we
> have diverged. I would like to propose adding upgrade path from later
> CCP versions to ACS 4.2 which provides customers the choice to move to
> ACS from CCP and also brings CCP closer to upstream ACS releases.
> >
> > The proposed upgrade paths are CCP3.0.4, CCP3.0.5, CCP3.06, CCP3.0.7
> to ACS4.2. Please provide your feedback.
> >
> > Thanks
> > Animesh
> >
> >
> >
> >
> 
> Generally...  +1000.  I think that this is a wonderful idea.
> 
> I have a couple of thoughts:
> 
> We will really need to implement the "checkpoint"
> version concept that Hugo proposed earlier [1].  The reason that I say
> this, is that the source and binaries for CCP aren't available to non-
> customers of citrix / non-citrix devs.
[Animesh>] Agreed I also like the checkpoint, as Hugo points out our dbupgrade 
are sequentially applied so not a coding issue but certainly matters to QA
> 
> I obviously assume that Citrix is officially OK with this (and you are
> basically representing that to the list).  Given that "ok", I further
> assume that Citrix employeed engineers would do the work (since they
> have access to the CCP releases).
> 
> Once the upgrades are in ACS, we would want to reduce the testing effort
> around them going forward by ensuring that the targeted ACS release that
> we test the upgrades to will be one of the "checkpoint" releases per
> Hugo's proposal.
[Animesh>] Agreed
> 
> Last thought...  this doesn't seem like a 4.2 change to me.  Isn't it
> too late to deal with testing it now?  
[Animesh>] Yes this seems late for 4.2, but it makes it easier to add support 
now. If there is objection we can track it for 4.3.  

If not, and there are people
> ready to roll, then no worries.  I'm just pointing out what may be
> obvious:  you've hit feature freeze, and this seems like a significant
> amount of work.
> 
> -chip
> 
> [1] http://markmail.org/thread/p34jbalr25pwocez

RE: [rant] stupid test cases

[Anthony Xu]

+1   VM can be in "Stopped" state


Anthony

-Original Message-
From: Marcus Sorensen [mailto:shadow...@gmail.com] 
Sent: Wednesday, July 17, 2013 10:47 PM
To: dev@cloudstack.apache.org
Subject: Re: [rant] stupid test cases

I can understand that we may want to test that everything related to the domain 
gets cleaned up properly. We have run into all sorts of things when deleting 
accounts, for example where resources won't clean up because the account is 
gone and we throw null pointers because a bunch of code looks up account when 
deleting. However, to your point, VMs can be created in a "stopped" state and 
that wouldn't incur the overhead of deployment.
On Jul 17, 2013 11:33 PM, "Prasanna Santhanam"  wrote:

> I was just going through one of the automated test cases and I find it 
> really silly that there's the following test:
>
> def test_forceDeleteDomain(self):
> """ Test delete domain force option"""
>
> # Steps for validations
> # 1. create a domain DOM
> # 2. create 2 users under this domain
> # 3. deploy 1 VM into each of these user accounts
> # 4. create PF / FW rules for port 22 on these VMs for their
> #respective accounts
> # 5. delete the domain with force=true option
> # Validate the following
> # 1. listDomains should list the created domain
> # 2. listAccounts should list the created accounts
> # 3. listvirtualmachines should show the Running VMs
> # 4. PF and FW rules should be shown in listFirewallRules
> # 5. domain should delete successfully and above three list calls
> #should show all the resources now deleted. listRouters should
> #not return any routers in the deleted accounts/domains
>
> Why would one need the overhead of creating VMs in a domain deletion test?
> Do
> we not understand that the basics accounts/domains/ etc that 
> cloudstack has nothing to do with the virtual machines? This kind of a 
> test slows down other useful tests that we could be running. More over 
> when this fails in the VM creation step I'd have to go in and analyse 
> logs to realize that deletedomain was perhaps fine but vm creation has 
> failed.
>
> That's a pointless effort. I'm sure there are others in the automated 
> tests that do this kind of wasteful testing. So please please pleaes 
> &*()#@()# please review test plans before automating them!
>
> I'm not going to be looking at this forever to fix these issues when 
> we want to see pretty metrics and numbers.
>
> --
> Prasanna.,
>
> 
> Powered by BigRock.com
>
>

Re: Review Request 12744: Removed unused classes

[Sheng Yang]

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

Ship it!


Ship It!

- Sheng Yang


On July 18, 2013, 8:51 p.m., Laszlo Hornyak wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/12744/
> ---
> 
> (Updated July 18, 2013, 8:51 p.m.)
> 
> 
> Review request for cloudstack.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> ScriptBuilder and Executor was not actually used.
> 
> 
> Diffs
> -
> 
>   utils/src/com/cloud/utils/script/Executor.java 4e70a77 
>   utils/src/com/cloud/utils/script/Script.java d3a3591 
>   utils/src/com/cloud/utils/script/ScriptBuilder.java 96cadfb 
> 
> Diff: https://reviews.apache.org/r/12744/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Laszlo Hornyak
> 
>

Re: Review Request 12744: Removed unused classes

[Sheng Yang]

> On July 18, 2013, 10:42 p.m., Sheng Yang wrote:
> > Ship It!

Pushed to MASTER.


- Sheng


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


On July 18, 2013, 8:51 p.m., Laszlo Hornyak wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/12744/
> ---
> 
> (Updated July 18, 2013, 8:51 p.m.)
> 
> 
> Review request for cloudstack.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> ScriptBuilder and Executor was not actually used.
> 
> 
> Diffs
> -
> 
>   utils/src/com/cloud/utils/script/Executor.java 4e70a77 
>   utils/src/com/cloud/utils/script/Script.java d3a3591 
>   utils/src/com/cloud/utils/script/ScriptBuilder.java 96cadfb 
> 
> Diff: https://reviews.apache.org/r/12744/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Laszlo Hornyak
> 
>

Re: Review Request 12743: removed unused class and related test utils

[Sheng Yang]

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

(Updated July 18, 2013, 10:53 p.m.)


Review request for cloudstack and Kelven Yang.


Changes
---

Kelven, it's related to your unmerged VMsync code. Is it OK to remove it for 
now?


Repository: cloudstack-git


Description
---

MethodCapturer and related test utilities was not used


Diffs
-

  utils/src/com/cloud/utils/MethodCapturer.java f9fe046 
  utils/test/com/cloud/utils/DummyImpl.java 467d8e2 
  utils/test/com/cloud/utils/DummyInterface.java f79a53e 
  utils/test/com/cloud/utils/DummyPremiumImpl.java bf8bfea 

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


Testing
---


Thanks,

Laszlo Hornyak

RE: code formatting for enums

[Alex Huang]

Actually, that's more of a C/C++ coding convention.  (Speaking of which, please 
don't use "I" to start interfaces.)

I prefer to have enums as follows

Public class Vm {
enum State {
  IsRunning,
  Stopped,
}
}

I generally like to write Vm.State.IsRunning  in the code.  It's readable and 
clear.  

As opposed to Vm.State.IS_RUNNING which is a little less readable.  

But the thing I've seen people do is just using IS_RUNNING or State.IsRunning 
which often becomes confusing.  I'm more against that then all caps and 
underscore.

My $.02.  I will caution that any change to existing enums, we have to think 
about how it maps to the database.  If the VO object stores the enum, you'll 
have to either upgrade the database or add methods to the enum so that when 
storing it, it becomes the same.

--Alex

> -Original Message-
> From: John Burwell [mailto:jburw...@basho.com]
> Sent: Thursday, July 18, 2013 12:33 PM
> To: dev@cloudstack.apache.org
> Subject: Re: code formatting for enums
> 
> All,
> 
> Another thing I have noticed is that enum values are not capitalized.  General
> coding convention is that enum values are declared in all caps using an
> underscore to separate words.  I notice that our coding conventions are
> silent on enumerations.  Any opposition to adding this rule to our coding
> conventions?
> 
> Thanks,
> -John
> 
> On Jul 17, 2013, at 12:24 PM, Alex Huang  wrote:
> 
> > That's because the first rule of auto-formatting is do no harm.
> >
> > The formatter is set not to screw with lines that are already wrapped
> assuming the previous developer intended it that way.
> >
> > --Alex
> >
> >> -Original Message-
> >> From: Daan Hoogland [mailto:daan.hoogl...@gmail.com]
> >> Sent: Wednesday, July 17, 2013 8:23 AM
> >> To: dev
> >> Subject: Re: code formatting for enums
> >>
> >> thanks,
> >> it doesn't correct back to the one per line format, but at least it
> >> doesn't garble the enum when right anymore.
> >>
> >>
> >>
> >> On Wed, Jul 17, 2013 at 4:24 PM, Alex Huang 
> wrote:
> >>
> >>> Windows->Preferences
> >>> Java->Formatter
> >>> Click on Edit in Active Profiles
> >>> Line Wrapping tab
> >>> Look for 'enum' declaration->Constants Select Wrap all elements,
> >>> every element on a new line in the "Line Wrapping policy:" drop down
> >>>
> >>> --Alex
> >>>
> >>>
>  -Original Message-
>  From: Daan Hoogland [mailto:daan.hoogl...@gmail.com]
>  Sent: Wednesday, July 17, 2013 6:22 AM
>  To: dev
>  Subject: code formatting for enums
> 
>  H,
> 
>  I am working on Networks with the eclipse.epf file loaded. Now the
>  enum BroadcastDomainType gets saved as
> Native(null, null), Vlan("vlan", Integer.class), Vswitch("vs",
> String.class), LinkLocal(null, null), Vnet("vnet",
> >>> Long.class), Storage(
> "storage", Integer.class), Lswitch("lswitch",
> >>> String.class), Mido(
> "mido", String.class), Pvlan("pvlan", String.class),
> >>> UnDecided(
> null, null);
>  instead of
> Native(null, null),
> Vlan("vlan", Integer.class),
> Vswitch("vs", String.class),
> LinkLocal(null, null),
> Vnet("vnet", Long.class),
> Storage("storage", Integer.class),
> Lswitch("lswitch", String.class),
> Mido("mido", String.class),
> Pvlan("pvlan", String.class),
> UnDecided(null, null);
>  anybody know how to fix this?
> 
>  thanks,
>  Daan
> >>>

RE: deleteAffinityGroup API

[Alex Huang]

This one is a problem.  I will look into it.  In the bug description, all the 
logs were background threads.  All of CloudStack background threads act with 
system context.  That's correct.  That's why I closed it out.

Here I think you're actually saying that when called through admin API, it came 
in as System context.  That would be a bug if I understand you correctly.  

--Alex

> -Original Message-
> From: Prachi Damle
> Sent: Thursday, July 18, 2013 11:55 AM
> To: dev@cloudstack.apache.org
> Cc: Alex Huang
> Subject: RE: deleteAffinityGroup API
> 
> Hi Alex,
> 
> The error thrown while deleting affinitygroup by Id is: " Account and
> domainId are needed for resource creation "
> 
> 
> Many of our APIs call AccntManager to figure out owner of the resources the
> API is working on like this:
> 
> Account caller = CallContext.current().getCallingAccount(); //earlier 
> it
> was using UserContext and was replaced by CallContext
> Account owner = _accountMgr.finalizeOwner(caller, account, domainId,
> null);
> 
> And AccountManager: finalizeOwner has this check at start:
> 
> if (caller.getId() == Account.ACCOUNT_ID_SYSTEM && ((accountName
> == null || domainId == null) && projectId == null)) {
> throw new InvalidParameterValueException("Account and domainId
> are needed for resource creation");
> }
> 
> 
> Now the CallContext.current().getCallingAccount(); is returning the System
> user causing the subsequent failure. Why would it return system user, if the
> caller is admin user?
> 
> Thanks,
> Prachi
> 
> -Original Message-
> From: Prasanna Santhanam [mailto:t...@apache.org]
> Sent: Thursday, July 18, 2013 6:09 AM
> To: dev@cloudstack.apache.org
> Subject: Re: deleteAffinityGroup API
> 
> On Thu, Jul 18, 2013 at 02:17:46PM +0530, Prasanna Santhanam wrote:
> > On Thu, Jul 18, 2013 at 07:14:42AM +, Prachi Damle wrote:
> > > Account and domainId are not required parameters of this API. It
> > > works fine with just an id too.
> > >
> > > Account and domain will be used if delete is called providing a name
> > > of the group instead of id, say by an admin for a regular user's
> > > group.
> > >
> >
> > Thanks Prachi - I think it is related to the recent changes in
> > CallContext that is making the user system for the API call preventing
> > it from deleteing the aff.group with just an id. Filed a bug for it.
> 
> Ok - Alex mentioned the bug is 'Not a Problem'. So it's only the background
> CS workers which use the CallContext. But the affinity group is still failing 
> to
> delete using the id.
> 
> --
> Prasanna.,
> 
> 
> Powered by BigRock.com

Re: deleteAffinityGroup API

[Alena Prokharchyk]

If the API came through port 8096, then the caller comes as a System context 
(System default user id=1, account id=1). It was always like this since the 
time the UserContext was introduced.

-Alena.

From: Alex Huang mailto:alex.hu...@citrix.com>>
Reply-To: "dev@cloudstack.apache.org" 
mailto:dev@cloudstack.apache.org>>
Date: Thursday, July 18, 2013 4:00 PM
To: Prachi Damle mailto:prachi.da...@citrix.com>>, 
"dev@cloudstack.apache.org" 
mailto:dev@cloudstack.apache.org>>
Subject: RE: deleteAffinityGroup API

This one is a problem.  I will look into it.  In the bug description, all the 
logs were background threads.  All of CloudStack background threads act with 
system context.  That's correct.  That's why I closed it out.

Here I think you're actually saying that when called through admin API, it came 
in as System context.  That would be a bug if I understand you correctly.

--Alex

-Original Message-
From: Prachi Damle
Sent: Thursday, July 18, 2013 11:55 AM
To: dev@cloudstack.apache.org
Cc: Alex Huang
Subject: RE: deleteAffinityGroup API
Hi Alex,
The error thrown while deleting affinitygroup by Id is: " Account and
domainId are needed for resource creation "
Many of our APIs call AccntManager to figure out owner of the resources the
API is working on like this:
 Account caller = CallContext.current().getCallingAccount(); //earlier 
it
was using UserContext and was replaced by CallContext
 Account owner = _accountMgr.finalizeOwner(caller, account, domainId,
null);
And AccountManager: finalizeOwner has this check at start:
 if (caller.getId() == Account.ACCOUNT_ID_SYSTEM && ((accountName
== null || domainId == null) && projectId == null)) {
 throw new InvalidParameterValueException("Account and domainId
are needed for resource creation");
 }
Now the CallContext.current().getCallingAccount(); is returning the System
user causing the subsequent failure. Why would it return system user, if the
caller is admin user?
Thanks,
Prachi
-Original Message-
From: Prasanna Santhanam [mailto:t...@apache.org]
Sent: Thursday, July 18, 2013 6:09 AM
To: dev@cloudstack.apache.org
Subject: Re: deleteAffinityGroup API
On Thu, Jul 18, 2013 at 02:17:46PM +0530, Prasanna Santhanam wrote:
> On Thu, Jul 18, 2013 at 07:14:42AM +, Prachi Damle wrote:
> > Account and domainId are not required parameters of this API. It
> > works fine with just an id too.
> >
> > Account and domain will be used if delete is called providing a name
> > of the group instead of id, say by an admin for a regular user's
> > group.
> >
>
> Thanks Prachi - I think it is related to the recent changes in
> CallContext that is making the user system for the API call preventing
> it from deleteing the aff.group with just an id. Filed a bug for it.
Ok - Alex mentioned the bug is 'Not a Problem'. So it's only the background
CS workers which use the CallContext. But the affinity group is still failing to
delete using the id.
--
Prasanna.,

Powered by BigRock.com

RE: deleteAffinityGroup API

[Prachi Damle]

Prasanna does the regression  test scripts call using 8096 port?

If yes then that's the reason why the API is failing.

From: Alena Prokharchyk
Sent: Thursday, July 18, 2013 4:13 PM
To: dev@cloudstack.apache.org; Prachi Damle; Alex Huang
Subject: Re: deleteAffinityGroup API

If the API came through port 8096, then the caller comes as a System context 
(System default user id=1, account id=1). It was always like this since the 
time the UserContext was introduced.

-Alena.

From: Alex Huang mailto:alex.hu...@citrix.com>>
Reply-To: "dev@cloudstack.apache.org" 
mailto:dev@cloudstack.apache.org>>
Date: Thursday, July 18, 2013 4:00 PM
To: Prachi Damle mailto:prachi.da...@citrix.com>>, 
"dev@cloudstack.apache.org" 
mailto:dev@cloudstack.apache.org>>
Subject: RE: deleteAffinityGroup API

This one is a problem.  I will look into it.  In the bug description, all the 
logs were background threads.  All of CloudStack background threads act with 
system context.  That's correct.  That's why I closed it out.

Here I think you're actually saying that when called through admin API, it came 
in as System context.  That would be a bug if I understand you correctly.

--Alex

-Original Message-
From: Prachi Damle
Sent: Thursday, July 18, 2013 11:55 AM
To: dev@cloudstack.apache.org
Cc: Alex Huang
Subject: RE: deleteAffinityGroup API
Hi Alex,
The error thrown while deleting affinitygroup by Id is: " Account and
domainId are needed for resource creation "
Many of our APIs call AccntManager to figure out owner of the resources the
API is working on like this:
 Account caller = CallContext.current().getCallingAccount(); //earlier 
it
was using UserContext and was replaced by CallContext
 Account owner = _accountMgr.finalizeOwner(caller, account, domainId,
null);
And AccountManager: finalizeOwner has this check at start:
 if (caller.getId() == Account.ACCOUNT_ID_SYSTEM && ((accountName
== null || domainId == null) && projectId == null)) {
 throw new InvalidParameterValueException("Account and domainId
are needed for resource creation");
 }
Now the CallContext.current().getCallingAccount(); is returning the System
user causing the subsequent failure. Why would it return system user, if the
caller is admin user?
Thanks,
Prachi
-Original Message-
From: Prasanna Santhanam [mailto:t...@apache.org]
Sent: Thursday, July 18, 2013 6:09 AM
To: dev@cloudstack.apache.org
Subject: Re: deleteAffinityGroup API
On Thu, Jul 18, 2013 at 02:17:46PM +0530, Prasanna Santhanam wrote:
> On Thu, Jul 18, 2013 at 07:14:42AM +, Prachi Damle wrote:
> > Account and domainId are not required parameters of this API. It
> > works fine with just an id too.
> >
> > Account and domain will be used if delete is called providing a name
> > of the group instead of id, say by an admin for a regular user's
> > group.
> >
>
> Thanks Prachi - I think it is related to the recent changes in
> CallContext that is making the user system for the API call preventing
> it from deleteing the aff.group with just an id. Filed a bug for it.
Ok - Alex mentioned the bug is 'Not a Problem'. So it's only the background
CS workers which use the CallContext. But the affinity group is still failing to
delete using the id.
--
Prasanna.,

Powered by BigRock.com

Re: [ACS4.1.1][BLOCKER] Unable to launch VNC Console to VSphere VMs

[Kelven Yang]

Yes, CPVM has to be destroyed and be re-deployed so that updates can be
pushed over to make it work

Kelven

On 7/18/13 2:54 PM, "Musayev, Ilya"  wrote:

>When I say upgraded, I mean it needs to be trashed and redeployed.
>
>> -Original Message-
>> From: Musayev, Ilya [mailto:imusa...@webmd.net]
>> Sent: Thursday, July 18, 2013 5:46 PM
>> To: Kelven Yang; dev@cloudstack.apache.org
>> Subject: RE: [ACS4.1.1][BLOCKER] Unable to launch VNC Console to VSphere
>> VMs
>> 
>> Kelven,
>> 
>> Perhaps I missed it,
>> 
>> Does CPVM needs to be upgraded from 4.1 to 4.1.1?
>> 
>> Thanks
>> ilya
>> 
>> > -Original Message-
>> > From: Kelven Yang [mailto:kelven.y...@citrix.com]
>> > Sent: Thursday, July 18, 2013 5:25 PM
>> > To: Musayev, Ilya; dev@cloudstack.apache.org
>> > Subject: Re: [ACS4.1.1][BLOCKER] Unable to launch VNC Console to
>> > VSphere VMs
>> >
>> > I'll take a look at it. It seems that my devCloud environment failed
>> > to get CPVM upgraded thus let my testing on this skipped with success
>> >
>> > Kelven
>> >
>> > On 7/17/13 8:04 PM, "Musayev, Ilya"  wrote:
>> >
>> > >Kelven
>> > >
>> > >Please review the commit
>> "73a6aa78854f379e6439bf22457094a5272cbfed",
>> > >cloudstack-3433.
>> > >
>> > >After reverting this commit, everything functioned normally. We
>> > >cannot release 4.1.1 with this defect :(
>> > >
>> > >Thanks
>> > >ilya
>> > >
>> > >
>> > >
>> > >> -Original Message-
>> > >> From: Musayev, Ilya [mailto:imusa...@webmd.net]
>> > >> Sent: Wednesday, July 17, 2013 7:57 PM
>> > >> To: dev@cloudstack.apache.org
>> > >> Cc: Kelven Yang (kelven.y...@citrix.com)
>> > >> Subject: [ACS4.1.1][BLOCKER] Unable to launch VNC Console to
>> > >> VSphere VMs
>> > >>
>> > >> Post my upgrade from 4.1 to 4.1.1 I'm unable to launch console,
>> > >> with message Caused by:
>> com.cloud.utils.exception.CloudRuntimeException:
>> > >> can't find ConsoleAccessAuthenticationCommand.
>> > >>
>> > >> I've looked through commit history, and it looks like the only
>> > >>change that was  made is related to a commit CLOUDSTACK-3456. Not
>> > >>100% certain that's  issue, but seems like the only change in this
>>area.
>> > >>
>> > >> Also, why do I get given the "type class
>> > >>[Lcom.cloud.agent.api.Command;" -  the L appending to com.cloud
>> > >>seems new.
>> > >>
>> > >> Log below:
>> > >>
>> > >>
>> > >> 2013-07-17 19:38:20,949 DEBUG [agent.transport.Request]
>> > >>(http-8080-3:null)
>> > >> Seq 5-1052639262: Received:  { Ans: , MgmtId: 345049078181, via: 5,
>> > >>Ver: v1,
>> > >> Flags: 10, { GetVncPortAnswer } }
>> > >> 2013-07-17 19:38:20,950 DEBUG [cloud.servlet.ConsoleProxyServlet]
>> > >>(http-
>> > >> 8080-3:null) Port info 172.25.243.31
>> > >> 2013-07-17 19:38:20,950 INFO  [cloud.servlet.ConsoleProxyServlet]
>> > >>(http-
>> > >> 8080-3:null) Parse host info returned from executing
>> > GetVNCPortCommand.
>> > >> host info: 172.25.243.31
>> > >> 2013-07-17 19:38:20,958 DEBUG [cloud.servlet.ConsoleProxyServlet]
>> > >>(http-
>> > >> 8080-3:null) Compose console url: https://172-24-20-
>> >
>> >>22.realhostip.com/ajax?token=1LYgydVEstHtlOuUWpMC3lNponA8tI8kA10
>> > rq
>> > >>
>> >
>> njR1Tl1HPws9wEaTKE6IvMaV_iUtnNNqSjcoFTyO9NIDzaBTUWpfGumQ5cAijs
>> > >>
>> >
>> vKJ0Mx8fyQwyCDLko8ekhjIKLkngtuofPmQRbBwsfaZj6_N4JpLYKWoOVdZ6Eq
>> > >>
>> >
>> qerLKas1ErQ0e2yRnDvYq5C2OVSGQgl08a2RCF0WFWuYyl1HW3fDIkivzVJE9IC
>> > >> 6266_CSEWuQV65bmjVIuUMPekgzq_R6PBm85a_wsxGX8rdae0x05UQ
>> > >> 2013-07-17 19:38:20,958 DEBUG [cloud.servlet.ConsoleProxyServlet]
>> > >>(http-
>> > >> 8080-3:null) the console url is :: rhn01t-ops-
>> > >>08https://172-24-20-
>> >
>> >>22.realhostip.com/ajax?token=1LYgydVEstHtlOuUWpMC3lNponA8tI8kA10
>> > rq
>> > >>
>> >
>> njR1Tl1HPws9wEaTKE6IvMaV_iUtnNNqSjcoFTyO9NIDzaBTUWpfGumQ5cAijs
>> > >>
>> >
>> vKJ0Mx8fyQwyCDLko8ekhjIKLkngtuofPmQRbBwsfaZj6_N4JpLYKWoOVdZ6Eq
>> > >>
>> >
>> qerLKas1ErQ0e2yRnDvYq5C2OVSGQgl08a2RCF0WFWuYyl1HW3fDIkivzVJE9IC
>> > >>
>> >
>> 6266_CSEWuQV65bmjVIuUMPekgzq_R6PBm85a_wsxGX8rdae0x05UQ">> > >> ame>
>> > >> 2013-07-17 19:38:20,992 ERROR [agent.transport.Request]
>> > >>(AgentManager-
>> > >> Handler-7:null) Caught problem with
>> > >>
>> >
>> [{"ConsoleAccessAuthenticationCommand":{"_host":"172.25.243.31","_port"
>> > >> :"5924","_vmId":"0c9354d4-cbad-4cd0-9a38-
>> > >>
>> >
>> 48e0efc6a3f5","_sid":"585d97c4cf867d6d","_ticket":"7w0YL4G35QDQj79Jm3
>> > >>
>> > >>h5NzNtwXo\u003d","_isReauthenticating":false,"contextMap":{},"wait":
>> > >>0
>> > }
>> > >>}]
>> > >> com.google.gson.JsonParseException: The JsonDeserializer
>> > >>com.cloud.agent.transport.ArrayTypeAdaptor@1aa9a7bb failed to
>> > >>deserialize json object
>> >
>> >>[{"ConsoleAccessAuthenticationCommand":{"_host":"172.25.243.31","_po
>> > rt"
>> > >> :"5924","_vmId":"0c9354d4-cbad-4cd0-9a38-
>> > >>
>> >
>> 48e0efc6a3f5","_sid":"585d97c4cf867d6d","_ticket":"7w0YL4G35QDQj79Jm3
>> > >> h5NzNtwXo=","_isReauthenticating":false,"contextMap":{},"wait":0}}]
>> > >>given
>> > >> the type class [Lcom.cloud