date:20130619

Congrats, Mike.


On Jun 19, 2013, at 10:02 AM, Wei ZHOU  wrote:

> Congrats Mike!
> 
> 
> 2013/6/19 Sateesh Chodapuneedi 
> 
>> Congratulations Mike! Welcome...
>> 
>> Regards,
>> Sateesh
>> 
>> 
>>> -Original Message-
>>> From: Alex Huang [mailto:alex.hu...@citrix.com]
>>> Sent: 19 June 2013 19:10
>>> To: dev@cloudstack.apache.org
>>> Subject: FW: [ANNOUNCE] New committer: Mike Tutkowski
>>> 
>>> 
>>> The Project Management Committee (PMC) for Apache CloudStack has asked
>> Mike Tutkowski to become a committer and we are pleased
>>> to announce that they have accepted.
>>> 
>>> Being a committer allows many contributors to contribute more
>> autonomously. For developers, it makes it easier to submit changes and
>>> eliminates the need to have contributions reviewed via the patch
>> submission process. Whether contributions are development-related or
>>> otherwise, it is a recognition of a contributor's participation in the
>> project and commitment to the project and the Apache Way.
>>> 
>>> Please join me in congratulating Mike!
>>> 
>>> --Alex
>>> on behalf of the CloudStack PMC
>>

Re: starting VM and get error of "unable to create a deployment for VM[user|i-2-107-VM]"

2013-06-19 Thread Wei ZHOU

William,

There can be several seasons.
Could you attach the agent.log?

-Wei


2013/6/19 William Jiang 

> Anybody has the same situation before ? Any comments or suggestions will
> be great appreciated.
>
> Thanks,
> William
>
>
> -Original Message-
> From: William Jiang [mailto:william.ji...@manwin.com]
> Sent: June-18-13 12:45 PM
> To: dev@cloudstack.apache.org; us...@cloudstack.apache.org
> Subject: RE: starting VM and get error of "unable to create a deployment
> for VM[user|i-2-107-VM]"
>
> Hi,
> Ubuntu 12.04 does not fully supported by xenserver 6.0.2, but we have some
> Ubuntu 12.04 work well, and we also saw same issue in one windows server
> 2008 R2 VM which is fully supported by hypervisor.
>
> The complete logs as following:
>
>
> #
> 2013-06-14 12:28:34,328 DEBUG [cloud.async.AsyncJobManagerImpl]
> (catalina-exec-18:null) submit async job-626, details: AsyncJobVO {id:626,
> userId: 2, accountId: 2, sessionKey: null, instanceType: VirtualMachine,
> instanceId: 107, cmd: com.cloud.api.commands.StartVMCmd, cmdOriginator:
> null, cmdInfo:
> {"id":"2d7d30a0-83d1-4050-a8dd-1b702fbb08e6","response":"json","sessionkey":"eihe8Buev1Ale+nhxw+w1nqQ\u003d","ctxUserId":"2","_":"1371227586576","ctxAccountId":"2","ctxStartEventId":"2584"},
> cmdVersion: 0, callbackType: 0, callbackAddress: null, status: 0,
> processStatus: 0, resultCode: 0, result: null, initMsid: 110492071566,
> completeMsid: null, lastUpdated: null, lastPolled: null, created: null}
> 2013-06-14 12:28:34,331 DEBUG [cloud.async.AsyncJobManagerImpl]
> (Job-Executor-16:job-626) Executing com.cloud.api.commands.StartVMCmd for
> job-626
> 2013-06-14 12:28:34,349 DEBUG [cloud.network.NetworkManagerImpl]
> (Job-Executor-16:job-626) Service SecurityGroup is not supported in the
> network id=214
> 2013-06-14 12:28:34,353 DEBUG [cloud.network.NetworkManagerImpl]
> (Job-Executor-16:job-626) Service SecurityGroup is not supported in the
> network id=214
> 2013-06-14 12:28:34,355 DEBUG [cloud.capacity.CapacityManagerImpl]
> (Job-Executor-16:job-626) VM state transitted from :Stopped to Starting
> with event: StartRequestedvm's original host id: 9 new host id: null host
> id before state transition: null
> 2013-06-14 12:28:34,356 DEBUG [cloud.vm.VirtualMachineManagerImpl]
> (Job-Executor-16:job-626) Successfully transitioned to start state for
> VM[User|i-2-107-VM] reservation id = 3ee7e4d1-a732-4e6b-96d3-eb02caec4df3
> 2013-06-14 12:28:34,357 DEBUG [cloud.vm.VirtualMachineManagerImpl]
> (Job-Executor-16:job-626) Trying to deploy VM, vm has dcId: 3 and podId: 3
> 2013-06-14 12:28:34,357 DEBUG [cloud.vm.VirtualMachineManagerImpl]
> (Job-Executor-16:job-626) Deploy avoids pods: null, clusters: null, hosts:
> null
> 2013-06-14 12:28:34,359 DEBUG [cloud.vm.VirtualMachineManagerImpl]
> (Job-Executor-16:job-626) Root volume is ready, need to place VM in
> volume's cluster
> 2013-06-14 12:28:34,359 DEBUG [cloud.vm.VirtualMachineManagerImpl]
> (Job-Executor-16:job-626) Vol[129|vm=107|ROOT] is READY, changing
> deployment plan to use this pool's dcId: 3 , podId: 3 , and clusterId: 3
> 2013-06-14 12:28:34,360 DEBUG [cloud.deploy.FirstFitPlanner]
> (Job-Executor-16:job-626) DeploymentPlanner allocation algorithm: random
> 2013-06-14 12:28:34,360 DEBUG [cloud.deploy.FirstFitPlanner]
> (Job-Executor-16:job-626) Trying to allocate a host and storage pools from
> dc:3, pod:3,cluster:3, requested cpu: 1000, requested ram: 1073741824
> 2013-06-14 12:28:34,360 DEBUG [cloud.deploy.FirstFitPlanner]
> (Job-Executor-16:job-626) Is ROOT volume READY (pool already allocated)?:
> Yes
> 2013-06-14 12:28:34,360 DEBUG [cloud.deploy.FirstFitPlanner]
> (Job-Executor-16:job-626) This VM has last host_id specified, trying to
> choose the same host: 9
> 2013-06-14 12:28:34,361 DEBUG [cloud.capacity.CapacityManagerImpl]
> (Job-Executor-16:job-626) Checking if host: 9 has enough capacity for
> requested CPU: 1000 and requested RAM: 1073741824 ,
> cpuOverprovisioningFactor: 1.0
> 2013-06-14 12:28:34,362 DEBUG [cloud.capacity.CapacityManagerImpl]
> (Job-Executor-16:job-626) Hosts's actual total CPU: 18616 and CPU after
> applying overprovisioning: 18616
> 2013-06-14 12:28:34,362 DEBUG [cloud.capacity.CapacityManagerImpl]
> (Job-Executor-16:job-626) We need to allocate to the last host again, so
> checking if there is enough reserved capacity
> 2013-06-14 12:28:34,362 DEBUG [cloud.capacity.CapacityManagerImpl]
> (Job-Executor-16:job-626) Reserved CPU: 0 , Requested CPU: 1000
> 2013-06-14 12:28:34,362 DEBUG [cloud.capacity.CapacityManagerImpl]
> (Job-Executor-16:job-626) Reserved RAM: 0 , Requested RAM: 1073741824
> 2013-06-14 12:28:34,362 DEBUG [cloud.capacity.CapacityManagerImpl]
> (Job-Executor-16:job-626) STATS: Failed to alloc resource from host: 9
> reservedCpu: 0, requested cpu: 1000, reservedMem: 0, requested mem:
> 1073741824

RE: [ANNOUNCE] New committer: Mike Tutkowski

2013-06-19 Thread Pranav Saxena

 Congrats Mike !! Welcome aboard :)

-Original Message-
From: John Burwell [mailto:jburw...@basho.com] 
Sent: Wednesday, June 19, 2013 7:39 PM
To: dev@cloudstack.apache.org
Subject: Re: [ANNOUNCE] New committer: Mike Tutkowski

Congrats, Mike.


On Jun 19, 2013, at 10:02 AM, Wei ZHOU  wrote:

> Congrats Mike!
> 
> 
> 2013/6/19 Sateesh Chodapuneedi 
> 
>> Congratulations Mike! Welcome...
>> 
>> Regards,
>> Sateesh
>> 
>> 
>>> -Original Message-
>>> From: Alex Huang [mailto:alex.hu...@citrix.com]
>>> Sent: 19 June 2013 19:10
>>> To: dev@cloudstack.apache.org
>>> Subject: FW: [ANNOUNCE] New committer: Mike Tutkowski
>>> 
>>> 
>>> The Project Management Committee (PMC) for Apache CloudStack has asked
>> Mike Tutkowski to become a committer and we are pleased
>>> to announce that they have accepted.
>>> 
>>> Being a committer allows many contributors to contribute more
>> autonomously. For developers, it makes it easier to submit changes and
>>> eliminates the need to have contributions reviewed via the patch
>> submission process. Whether contributions are development-related or
>>> otherwise, it is a recognition of a contributor's participation in the
>> project and commitment to the project and the Apache Way.
>>> 
>>> Please join me in congratulating Mike!
>>> 
>>> --Alex
>>> on behalf of the CloudStack PMC
>>

Re: [ANNOUNCE] New committer: Mike Tutkowski

2013-06-19 Thread Isaac Chiang

Congrats, Mike :)


On Wed, Jun 19, 2013 at 10:26 PM, Pranav Saxena wrote:

>  Congrats Mike !! Welcome aboard :)
>
> -Original Message-
> From: John Burwell [mailto:jburw...@basho.com]
> Sent: Wednesday, June 19, 2013 7:39 PM
> To: dev@cloudstack.apache.org
> Subject: Re: [ANNOUNCE] New committer: Mike Tutkowski
>
> Congrats, Mike.
>
>
> On Jun 19, 2013, at 10:02 AM, Wei ZHOU  wrote:
>
> > Congrats Mike!
> >
> >
> > 2013/6/19 Sateesh Chodapuneedi 
> >
> >> Congratulations Mike! Welcome...
> >>
> >> Regards,
> >> Sateesh
> >>
> >>
> >>> -Original Message-
> >>> From: Alex Huang [mailto:alex.hu...@citrix.com]
> >>> Sent: 19 June 2013 19:10
> >>> To: dev@cloudstack.apache.org
> >>> Subject: FW: [ANNOUNCE] New committer: Mike Tutkowski
> >>>
> >>>
> >>> The Project Management Committee (PMC) for Apache CloudStack has asked
> >> Mike Tutkowski to become a committer and we are pleased
> >>> to announce that they have accepted.
> >>>
> >>> Being a committer allows many contributors to contribute more
> >> autonomously. For developers, it makes it easier to submit changes and
> >>> eliminates the need to have contributions reviewed via the patch
> >> submission process. Whether contributions are development-related or
> >>> otherwise, it is a recognition of a contributor's participation in the
> >> project and commitment to the project and the Apache Way.
> >>>
> >>> Please join me in congratulating Mike!
> >>>
> >>> --Alex
> >>> on behalf of the CloudStack PMC
> >>
>
>

Re: FW: [ANNOUNCE] New committer: Mike Tutkowski

2013-06-19 Thread Joe Brockmeier

On Wed, Jun 19, 2013, at 08:39 AM, Alex Huang wrote:
> Please join me in congratulating Mike!

Congrats Mike! 

Best,

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

disk_io_throttle and solidfire Patch Review Status

All,

Since the threads discussing these patches have been very long, I want to roll 
up the issue list, and ensure that we are on track to have them resolved before 
the 4.2.  The following is my current issue list and the associated status:

Mutual Exclusion of hypervisor throttled I/O and storage provisioned IOPS on a 
per volume basis:  Mike is working to implement a user interface that prevents 
a user from configured both on a single volume, as well as, service level 
checks to verify that both types of QoS are not defined for a single volume.
Verify available device capacity for provisioned IOPS: Mike has reported 
completion of the code, and will push the changes to Review Board shortly.
Verify available hypervisor capacity for throttled I/O: Unknown -- I have not 
seen any feedback on this issue from Wei.
Enhancement of usage data to reflect use of provisioned IOPS and throttled I/O: 
We have had some conversations on how usage records should reflect when these 
QoS are being used, but we have not arrived at answer/solution.  Both patches 
likely require modification to address this issue.

Finally, we need to ensure that the code-level issues identified in Review 
Board have also been addressed, and then we can run through a final review pre 
merge.

Thanks,
-John

Re: Review Request: CLOUDSTACK-1758: SSVM tests failed due to ssh error

2013-06-19 Thread Girish Shilamkar


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

(Updated June 19, 2013, 2:50 p.m.)


Review request for cloudstack and Prasanna Santhanam.


Changes
---

Updated the testcase.


Description
---

Additional fixes were needed which were found during further testing.


This addresses bug CLOUDSTACK-1758.


Diffs (updated)
-

  test/integration/smoke/test_ssvm.py d637f96 

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


Testing
---


Thanks,

Girish Shilamkar

Re: [GSOC]CloudStack deployment questions

2013-06-19 Thread Han,Meng

Thank you very much for your reply!

On Wed, 19 Jun 2013 10:30:22 +0530, Prasanna Santhanam wrote:

On Tue, Jun 18, 2013 at 10:45:27PM -0400, Han,Meng wrote:

Hi all,

I have a few questions about CloudStack deployment.

1. I am trying to deploy CloudStack, use CloudStack to start a
cluster and run hadoop on it. Now I have only one computer with
virtulization extension support in hardware and the OS is ubuntu
12.04.

I'm no hadoop person but if you require large swaths of storage you
are going to use I imagine that will be external to your development
environment. Is this true?

Testing the well functionality of hadoop might need large storage as
hadoop is designed for big data:)
But at this moment I am not quite sure what exactly need to be tailored
for hadoop case. I will come back

to this as soon as I figured it out.

what would be a good deployment suit?

Devcloud? It seems like the tiny linux guest VM in devcloud won't be
sufficient to play with hadoop.

You can register a VM of your choice in devcloud from the UI. If
devcloud is unsuitable, tell us what is missing and we can see if it
can be tailored to fit your use case.

Install Xenserver on my desktop, using one VM as the management
server and other VMs as guest VMs.

Install management server on my ubuntu desktop. Using KVM to
provision guest VMs. This is the guide I found for this solution:

http://cloudstack.apache.org/docs/en-US/Apache_CloudStack/4.0.2/html/Quick_Install_Guide/index.html

Or anything else?

You can run all the management server code from your laptop as a
development environment and add an external hypervisor host (Either
Xen/KVM) to it. The guests, system VMs etc will then be deployed on
your host and not eat up any memory on your laptop. Management server
does require quite a bit of memory to run and having Hypervisor +
Management server + storage + kitchen sink will slow it down (unless
you just need devcloud).

I will add another hypervisor host. Is there any network requirement
for the management server and hypervisor host?

May I know how does the management server know the hypervisor host and
include it to its management?

2. When I try to deploy management server on my desktop. I
encountered below error when running the command "mvn -P developer
-pl developer,tools/devcloud -Ddeploydb" in this tutorial:
https://cwiki.apache.org/CLOUDSTACK/devcloud.html

Did mvn -Pdeveloper -Dsystevm clean install succeed for you?

Yes, this step works for me.

> WARNING: Provided file does not exist:
/home/meng/cloudstack/developer/../utils/conf/db.properties.override
> Initializing database=cloud with host=localhost port=3306
username=cloud password=cloud
> Running query: drop database if exists `cloud`
SQL exception in trying initDB: java.sql.SQLException: Access denied
for user 'root'@'localhost' (using password: NO)

Does your mysql instance have a root password? If so you'll have to
put that into db.properties.override file under utils/conf.

I see the wiki(s) are missing this info, so we'll need to edit that
with this step if it works for you.

I create a file named db.properties.override under utils/conf. Put my
root password inside it and it works!

let us know.

I am running the mvn command as root. Mysql is setup locally.

The command "mvn -pl :cloud-client-ui jetty:run" gives me a
error:[INFO] Couldn't find specified project dir:
/home/meng/cloudstack/:cloud-client-ui

I notice that there is no cloud-client-ui directory under cloudstack.
So I switched to "mvn -pl client jetty:run", however it told me the
maven-jetty-plugin does not exist.

[INFO] Searching repository for plugin with prefix: 'jetty'.
[INFO]

[ERROR] BUILD ERROR
[INFO]

[INFO] The plugin 'org.apache.maven.plugins:maven-jetty-plugin' does
not exist or no valid version could be found

Any light on this?

Thanks!

Re: Review Request: CLOUDSTACK-1758: SSVM tests failed due to ssh error


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


Commit 5140473f2b754c1f178aae7946798d95027ec69a in branch refs/heads/master 
from Girish Shilamkar
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=5140473 ]

CLOUDSTACK-1758: Fix ssvm test failures, where ssh to ssvm failed.

Signed-off-by: Prasanna Santhanam 


- ASF Subversion and Git Services


On June 19, 2013, 2:50 p.m., Girish Shilamkar wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/11962/
> ---
> 
> (Updated June 19, 2013, 2:50 p.m.)
> 
> 
> Review request for cloudstack and Prasanna Santhanam.
> 
> 
> Description
> ---
> 
> Additional fixes were needed which were found during further testing.
> 
> 
> This addresses bug CLOUDSTACK-1758.
> 
> 
> Diffs
> -
> 
>   test/integration/smoke/test_ssvm.py d637f96 
> 
> Diff: https://reviews.apache.org/r/11962/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Girish Shilamkar
> 
>

Re: Review Request: CLOUDSTACK-1758: SSVM tests failed due to ssh error


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

Ship it!


5140473

- Prasanna Santhanam


On June 19, 2013, 2:50 p.m., Girish Shilamkar wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/11962/
> ---
> 
> (Updated June 19, 2013, 2:50 p.m.)
> 
> 
> Review request for cloudstack and Prasanna Santhanam.
> 
> 
> Description
> ---
> 
> Additional fixes were needed which were found during further testing.
> 
> 
> This addresses bug CLOUDSTACK-1758.
> 
> 
> Diffs
> -
> 
>   test/integration/smoke/test_ssvm.py d637f96 
> 
> Diff: https://reviews.apache.org/r/11962/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Girish Shilamkar
> 
>

RE: starting VM and get error of "unable to create a deployment for VM[user|i-2-107-VM]"

2013-06-19 Thread William Jiang

Hi,
There is no agent log on  management server /var/log/cloud/agent, do I need 
manually enable it ?

Thanks,
William

-Original Message-
From: Wei ZHOU [mailto:ustcweiz...@gmail.com]
Sent: June-19-13 10:25 AM
To: dev@cloudstack.apache.org
Subject: Re: starting VM and get error of "unable to create a deployment for 
VM[user|i-2-107-VM]"

William,

There can be several seasons.
Could you attach the agent.log?

-Wei


2013/6/19 William Jiang 

> Anybody has the same situation before ? Any comments or suggestions
> will be great appreciated.
>
> Thanks,
> William
>
>
> -Original Message-
> From: William Jiang [mailto:william.ji...@manwin.com]
> Sent: June-18-13 12:45 PM
> To: dev@cloudstack.apache.org; us...@cloudstack.apache.org
> Subject: RE: starting VM and get error of "unable to create a
> deployment for VM[user|i-2-107-VM]"
>
> Hi,
> Ubuntu 12.04 does not fully supported by xenserver 6.0.2, but we have
> some Ubuntu 12.04 work well, and we also saw same issue in one windows
> server
> 2008 R2 VM which is fully supported by hypervisor.
>
> The complete logs as following:
>
>
> ##
> ##
> #
> 2013-06-14 12:28:34,328 DEBUG [cloud.async.AsyncJobManagerImpl]
> (catalina-exec-18:null) submit async job-626, details: AsyncJobVO
> {id:626,
> userId: 2, accountId: 2, sessionKey: null, instanceType:
> VirtualMachine,
> instanceId: 107, cmd: com.cloud.api.commands.StartVMCmd, cmdOriginator:
> null, cmdInfo:
> {"id":"2d7d30a0-83d1-4050-a8dd-1b702fbb08e6","response":"json","sessio
> nkey":"eihe8Buev1Ale+nhxw+w1nqQ\u003d","ctxUserId":"2","_":"1371227586
> 576","ctxAccountId":"2","ctxStartEventId":"2584"},
> cmdVersion: 0, callbackType: 0, callbackAddress: null, status: 0,
> processStatus: 0, resultCode: 0, result: null, initMsid: 110492071566,
> completeMsid: null, lastUpdated: null, lastPolled: null, created:
> null}
> 2013-06-14 12:28:34,331 DEBUG [cloud.async.AsyncJobManagerImpl]
> (Job-Executor-16:job-626) Executing com.cloud.api.commands.StartVMCmd
> for
> job-626
> 2013-06-14 12:28:34,349 DEBUG [cloud.network.NetworkManagerImpl]
> (Job-Executor-16:job-626) Service SecurityGroup is not supported in
> the network id=214
> 2013-06-14 12:28:34,353 DEBUG [cloud.network.NetworkManagerImpl]
> (Job-Executor-16:job-626) Service SecurityGroup is not supported in
> the network id=214
> 2013-06-14 12:28:34,355 DEBUG [cloud.capacity.CapacityManagerImpl]
> (Job-Executor-16:job-626) VM state transitted from :Stopped to
> Starting with event: StartRequestedvm's original host id: 9 new host
> id: null host id before state transition: null
> 2013-06-14 12:28:34,356 DEBUG [cloud.vm.VirtualMachineManagerImpl]
> (Job-Executor-16:job-626) Successfully transitioned to start state for
> VM[User|i-2-107-VM] reservation id =
> 3ee7e4d1-a732-4e6b-96d3-eb02caec4df3
> 2013-06-14 12:28:34,357 DEBUG [cloud.vm.VirtualMachineManagerImpl]
> (Job-Executor-16:job-626) Trying to deploy VM, vm has dcId: 3 and
> podId: 3
> 2013-06-14 12:28:34,357 DEBUG [cloud.vm.VirtualMachineManagerImpl]
> (Job-Executor-16:job-626) Deploy avoids pods: null, clusters: null, hosts:
> null
> 2013-06-14 12:28:34,359 DEBUG [cloud.vm.VirtualMachineManagerImpl]
> (Job-Executor-16:job-626) Root volume is ready, need to place VM in
> volume's cluster
> 2013-06-14 12:28:34,359 DEBUG [cloud.vm.VirtualMachineManagerImpl]
> (Job-Executor-16:job-626) Vol[129|vm=107|ROOT] is READY, changing
> deployment plan to use this pool's dcId: 3 , podId: 3 , and clusterId:
> 3
> 2013-06-14 12:28:34,360 DEBUG [cloud.deploy.FirstFitPlanner]
> (Job-Executor-16:job-626) DeploymentPlanner allocation algorithm:
> random
> 2013-06-14 12:28:34,360 DEBUG [cloud.deploy.FirstFitPlanner]
> (Job-Executor-16:job-626) Trying to allocate a host and storage pools
> from dc:3, pod:3,cluster:3, requested cpu: 1000, requested ram:
> 1073741824
> 2013-06-14 12:28:34,360 DEBUG [cloud.deploy.FirstFitPlanner]
> (Job-Executor-16:job-626) Is ROOT volume READY (pool already allocated)?:
> Yes
> 2013-06-14 12:28:34,360 DEBUG [cloud.deploy.FirstFitPlanner]
> (Job-Executor-16:job-626) This VM has last host_id specified, trying
> to choose the same host: 9
> 2013-06-14 12:28:34,361 DEBUG [cloud.capacity.CapacityManagerImpl]
> (Job-Executor-16:job-626) Checking if host: 9 has enough capacity for
> requested CPU: 1000 and requested RAM: 1073741824 ,
> cpuOverprovisioningFactor: 1.0
> 2013-06-14 12:28:34,362 DEBUG [cloud.capacity.CapacityManagerImpl]
> (Job-Executor-16:job-626) Hosts's actual total CPU: 18616 and CPU
> after applying overprovisioning: 18616
> 2013-06-14 12:28:34,362 DEBUG [cloud.capacity.CapacityManagerImpl]
> (Job-Executor-16:job-626) We need to allocate to the last host again,
> so checking if there is enough reserved capacity
> 2013-06-14 12:28:34,362 DEBUG [cloud.capacity.CapacityManagerImpl]
> (Job-Executor-16:job-626) Reserved CPU: 0 , Reque

IRC meeting today

Hi all,

Joe asked me to facilitate the meeting today, however I have a $dayjob
responsibility that just came up.  I'm not going to be able to do
anything other than lurk in the channel.

I'm going to suggest that we cancel the meeting for today, unless
someone else wants to run it.

-chip

Re: [ANNOUNCE] New committer: Mike Tutkowski

2013-06-19 Thread Ahmad Emneina

Awesome stuff Mike. Excellent work getting solid fire in while the storage 
refactor was going on! Well deserved sir.

Ahmad

On Jun 19, 2013, at 6:39 AM, Alex Huang  wrote:

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

Re: IRC meeting today

2013-06-19 Thread John Kinsella

I'm happy to run it

On Jun 19, 2013, at 8:45 AM, Chip Childers 
 wrote:

> Hi all,
> 
> Joe asked me to facilitate the meeting today, however I have a $dayjob
> responsibility that just came up.  I'm not going to be able to do
> anything other than lurk in the channel.
> 
> I'm going to suggest that we cancel the meeting for today, unless
> someone else wants to run it.
> 
> -chip

Re: Test halting build every now and then

We should start a bounty on this one. 

@ke4qqq/@chipc - want to reward the fix at #CCC13? :)

On Fri, Jun 14, 2013 at 01:57:28PM -0400, Shane Witbeck wrote:
> I actually opened an issue for this: 
> 
> https://issues.apache.org/jira/browse/CLOUDSTACK-2863 
> 
> I've seen the failure using both wireless and ether on Mac OS X (10.8.4) from 
> Terminal.
> 
> 
> Thanks, 
> Shane
> 
> 
> On Friday, June 14, 2013 at 10:36 AM, Daan Hoogland wrote:
> 
> > localhost 
> 

-- 
Prasanna.,


Powered by BigRock.com

Re: disk_io_throttle and solidfire Patch Review Status

Comments below in red.

Thanks


On Wed, Jun 19, 2013 at 8:35 AM, John Burwell  wrote:

> All,
>
> Since the threads discussing these patches have been very long, I want to
> roll up the issue list, and ensure that we are on track to have them
> resolved before the 4.2.  The following is my current issue list and the
> associated status:
>
>
>- Mutual Exclusion of hypervisor throttled I/O and storage provisioned
>IOPS on a per volume basis:  Mike is working to implement a user interface
>that prevents a user from configured both on a single volume, as well as,
>service level checks to verify that both types of QoS are not defined for a
>single volume.
>
> I should have this completed today (mainly done already, but I have some
(un-related) meetings to attend before I can get back to this and finish
it).

>
>- Verify available device capacity for provisioned IOPS: Mike has
>reported completion of the code, and will push the changes to Review Board
>shortly.
>
> Yep...this is part of the diff file I pushed to Review Board yesterday.

>
>- Verify available hypervisor capacity for throttled I/O: Unknown -- I
>have not seen any feedback on this issue from Wei.
>- Enhancement of usage data to reflect use of provisioned IOPS and
>throttled I/O: We have had some conversations on how usage records should
>reflect when these QoS are being used, but we have not arrived at
>answer/solution.  Both patches likely require modification to address this
>issue.
>
> This is something I have little knowledge of (usage statistics). Please
let me know if you feel I need to make some changes for this. Thanks!

>
> Finally, we need to ensure that the code-level issues identified in Review
> Board have also been addressed, and then we can run through a final review
> pre merge.
>
> Thanks,
> -John
>
>
>


-- 
*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: disk_io_throttle and solidfire Patch Review Status

On Wed, Jun 19, 2013 at 10:34:58AM -0600, Mike Tutkowski wrote:
> Comments below in red.

We can't see the red for text emails.  ;-)

Re: disk_io_throttle and solidfire Patch Review Status

Maybe I'll just have to start doing bold like this: Bold even if it
just displays as text. :)

On Wed, Jun 19, 2013 at 10:36 AM, Chip Childers
wrote:

> On Wed, Jun 19, 2013 at 10:34:58AM -0600, Mike Tutkowski wrote:
> > Comments below in red.
>
> We can't see the red for text emails.  ;-)
>

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

Which file to update for schema change required for 4.1.1?

2013-06-19 Thread Min Chen

Hi there,

I need to fix a bug for 4.1.1, which requires some schema change. Two existing 
files (schema-40to410.sql and schema-410to420.sql) seem not fit here. In this 
case, should we create a new schema-410to411.sql for this purpose? Also, for 
fix required for 4.1.1, can we directly check into 4.1 branch or is it still a 
controlled checkin?
Thanks for clarification.

-min

Re: [GSOC]CloudStack deployment questions

On Wed, Jun 19, 2013 at 10:53:37AM -0400, Han,Meng wrote:
> >
> >You can run all the management server code from your laptop as a
> >development environment and add an external hypervisor host (Either
> >Xen/KVM) to it. The guests, system VMs etc will then be deployed on
> >your host and not eat up any memory on your laptop. Management server
> >does require quite a bit of memory to run and having Hypervisor +
> >Management server + storage + kitchen sink will slow it down (unless
> >you just need devcloud).
> 
> I will add another hypervisor host. Is there any network requirement
> for the management server and hypervisor host?
> 
> May I know how does the management server know the hypervisor host
> and include it to its management?
> 

That's what CloudStack is for. It 'discovers' the hypervisor through
its discoverers - XenDisoverer talks to XAPI to manage Xenservers, KVM
talks via SSH/libvirt and VmWare talks through the vmware SDK. It's
all abstracted so you don't have to understand the mechanics of what's
going on underneath.

Your hypervisor host needs to be prepared with the
OS+hypervisor-software of your choice. It will need to have one NIC
that the management server (your laptop) can reach. You will need some
storage (NFS) where you can pre-seed the systemVM template which is
used to launch service VMs that cloudstack uses for management
purposes.

All this and more is in the installation guide - let us know if
there's anything missing and you haven't been able to figure out about
the installation.

> >>
> >>> WARNING: Provided file does not exist:
> >>/home/meng/cloudstack/developer/../utils/conf/db.properties.override
> >>> Initializing database=cloud with host=localhost port=3306
> >>username=cloud password=cloud
> >>> Running query: drop database if exists `cloud`
> >>SQL exception in trying initDB: java.sql.SQLException: Access denied
> >>for user 'root'@'localhost' (using password: NO)
> >>
> >Does your mysql instance have a root password? If so you'll have to
> >put that into db.properties.override file under utils/conf.
> >
> >I see the wiki(s) are missing this info, so we'll need to edit that
> >with this step if it works for you.
> >
> 
> I create a file named db.properties.override under utils/conf. Put
> my root password inside it and it works!
> 

Cool! Do you mind updating the wiki @
https://cwiki.apache.org/confluence/display/CLOUDSTACK/How+to+build+on+master+branch

> 
> The command "mvn -pl :cloud-client-ui jetty:run" gives me a
> error:[INFO] Couldn't find specified project dir:
> /home/meng/cloudstack/:cloud-client-ui
> 
> I notice that there is no cloud-client-ui directory under
> cloudstack. So I switched to "mvn -pl client jetty:run", however it
> told me the maven-jetty-plugin does not exist.

Yes, client will work.

> 
> [INFO] Searching repository for plugin with prefix: 'jetty'.
> [INFO] 
> 
> [ERROR] BUILD ERROR
> [INFO] 
> 
> [INFO] The plugin 'org.apache.maven.plugins:maven-jetty-plugin' does
> not exist or no valid version could be found
> 
> Any light on this?

Odd, the jetty plugin should be downloaded automatically from
repo.maven.org. If your mvn clean install step worked I'm guessing
you're not behind any sort of http_proxy?

-- 
Prasanna.,

Powered by BigRock.com

Re: Which file to update for schema change required for 4.1.1?

Adding that 410to411 file was on my list of things to get done, but go
ahead and do it.  We also need the DB upgrade maps to be updated to
include it (as well as on master for 4.2).

The branch is not "controlled"...  so go for it!

-chip

On Wed, Jun 19, 2013 at 04:43:12PM +, Min Chen wrote:
> Hi there,
> 
> I need to fix a bug for 4.1.1, which requires some schema change. Two 
> existing files (schema-40to410.sql and schema-410to420.sql) seem not fit 
> here. In this case, should we create a new schema-410to411.sql for this 
> purpose? Also, for fix required for 4.1.1, can we directly check into 4.1 
> branch or is it still a controlled checkin?
> Thanks for clarification.
> 
> -min
>

RE: Which file to update for schema change required for 4.1.1?

2013-06-19 Thread Koushik Das

Ideally if the fix involves schema changes then it should go to 4.2. If there 
is no alternative then 410to411.sql looks like the option. But then the upgrade 
path becomes complicated. The following needs to be handled 4.1.0 -> 4.2.0, 
4.1.1 -> 4.2.0. Or else the upgrade sql script needs to be guarded with "if 
exists" kind of clause for every schema change so that a single 4.1 -> 4.2 
script suffices.

-Koushik

> -Original Message-
> From: Min Chen [mailto:min.c...@citrix.com]
> Sent: Wednesday, June 19, 2013 10:14 PM
> To: dev@cloudstack.apache.org
> Subject: Which file to update for schema change required for 4.1.1?
> 
> Hi there,
> 
> I need to fix a bug for 4.1.1, which requires some schema change. Two
> existing files (schema-40to410.sql and schema-410to420.sql) seem not fit
> here. In this case, should we create a new schema-410to411.sql for this
> purpose? Also, for fix required for 4.1.1, can we directly check into 4.1 
> branch
> or is it still a controlled checkin?
> Thanks for clarification.
> 
> -min

RE: NFS Cache storage query

2013-06-19 Thread Jessica Wang

Min, Edison,

Either way is fine with me.

Jessica

-Original Message-
From: Min Chen [mailto:min.c...@citrix.com] 
Sent: Tuesday, June 18, 2013 6:07 PM
To: Edison Su; dev@cloudstack.apache.org
Subject: Re: NFS Cache storage query

Edison, we can just add a parameter in listImageStoreCmd to show cache
store.

Thanks
-min

On 6/18/13 6:06 PM, "Edison Su"  wrote:

>Currently, no, I can add an API for it.
>
>> -Original Message-
>> From: Jessica Wang [mailto:jessica.w...@citrix.com]
>> Sent: Tuesday, June 18, 2013 4:24 PM
>> To: Min Chen
>> Cc: dev@cloudstack.apache.org
>> Subject: RE: NFS Cache storage query
>> 
>> Min,
>> 
>> > We may need to provide a way from UI to allow users to configure and
>> display their NFS cache.
>> Is there an API that list NFS cache?
>> 
>> Jessica
>> 
>> -Original Message-
>> From: Min Chen
>> Sent: Friday, June 14, 2013 9:26 AM
>> To: dev@cloudstack.apache.org
>> Cc: Jessica Wang
>> Subject: Re: NFS Cache storage query
>> 
>> Hi Sanjeev,
>> 
>>  In 4.2 release, we require that a NFS cache storage has to be added if
>> you choose S3 as the storage provider since we haven't refactored
>> hypervisor side code to handle s3 directly by bypassing NFS caching,
>>which is
>> the goal for 4.3 release. I see an issue with current UI, where user
>>can only
>> add cache storage when he/she adds a S3 storage. We may need to provide
>> a way from UI to allow users to configure and display their NFS cache.
>>You
>> can file a JIRA ticket for this UI enhancement.
>> 
>>  Thanks
>>  -min
>> 
>> On 6/14/13 6:35 AM, "Chip Childers"  wrote:
>> 
>> >On Fri, Jun 14, 2013 at 01:06:30PM +, Sanjeev Neelarapu wrote:
>> >> Hi,
>> >>
>> >> I have a query on how to add NFS Cache storage.
>> >> Before creating a zone if we create a secondary storage with s3 as
>> >>the storage provider and don't select NFS Cache Storage then we treat
>> >>it as
>> >>S3 at region level.
>> >> Later I create a zone and at "add secondary storage" creation wizard
>> >>in UI if I select NFS as secondary storage provider will it be treated
>> >>as NFS Cache Storage? If not is there a way to add NFS cache storage
>> >>for that zone?
>> >>
>> >> Thanks,
>> >> Sanjeev
>> >>
>> >
>> >Based on the thread talking about this [1], I'm not sure that it will
>> >be implemented this way anymore.
>> >
>> >-chip
>> >
>> >[1] http://markmail.org/message/c73nagj45q6iktfh
>

RE: [ANNOUNCE] New committer: Mike Tutkowski

2013-06-19 Thread Koushik Das

Congrats Mike!

> -Original Message-
> From: Alex Huang [mailto:alex.hu...@citrix.com]
> Sent: Wednesday, June 19, 2013 7:10 PM
> To: dev@cloudstack.apache.org
> Subject: FW: [ANNOUNCE] New committer: Mike Tutkowski
> 
> 
> The Project Management Committee (PMC) for Apache CloudStack has
> asked Mike Tutkowski to become a committer and we are pleased to
> announce that they have accepted.
> 
> Being a committer allows many contributors to contribute more
> autonomously. For developers, it makes it easier to submit changes and
> eliminates the need to have contributions reviewed via the patch submission
> process. Whether contributions are development-related or otherwise, it is a
> recognition of a contributor's participation in the project and commitment to
> the project and the Apache Way.
> 
> Please join me in congratulating Mike!
> 
> --Alex
> on behalf of the CloudStack PMC

Re: NFS Cache storage query

Nitin,

If we provide any APIs for the staging/temporary area, they must be read-only.  
Allowing any external manipulation of its content could cause break in-flight 
transfers or cause data loss.  I think we should consider the following APIs:

List contents including name, reference count, and size
Summary statistics for a staging area including consumed/available/total space 
and timestamp of the last garbage collection operation
Force garbage collection/cleanup operation

I think we should these are new API calls specific to the staging/temporary 
area mechanism rather than trying to overload existing API calls.

Thanks,
-John

On Jun 19, 2013, at 5:48 AM, Nitin Mehta  wrote:

> Agree with Min. How about CRUD operations on staging - all apis available ?
> 
> Thanks,
> -Nitin
> 
> On 19/06/13 6:44 AM, "Min Chen"  wrote:
> 
>> Edison, we can just add a parameter in listImageStoreCmd to show cache
>> store.
>> 
>> Thanks
>> -min
>> 
>> On 6/18/13 6:06 PM, "Edison Su"  wrote:
>> 
>>> Currently, no, I can add an API for it.
>>> 
 -Original Message-
 From: Jessica Wang [mailto:jessica.w...@citrix.com]
 Sent: Tuesday, June 18, 2013 4:24 PM
 To: Min Chen
 Cc: dev@cloudstack.apache.org
 Subject: RE: NFS Cache storage query

 Min,

> We may need to provide a way from UI to allow users to configure and
 display their NFS cache.
 Is there an API that list NFS cache?

 Jessica

 -Original Message-
 From: Min Chen
 Sent: Friday, June 14, 2013 9:26 AM
 To: dev@cloudstack.apache.org
 Cc: Jessica Wang
 Subject: Re: NFS Cache storage query

 Hi Sanjeev,

In 4.2 release, we require that a NFS cache storage has to be added if
 you choose S3 as the storage provider since we haven't refactored
 hypervisor side code to handle s3 directly by bypassing NFS caching,
 which is
 the goal for 4.3 release. I see an issue with current UI, where user
 can only
 add cache storage when he/she adds a S3 storage. We may need to provide
 a way from UI to allow users to configure and display their NFS cache.
 You
 can file a JIRA ticket for this UI enhancement.

Thanks
-min

 On 6/14/13 6:35 AM, "Chip Childers"  wrote:

> On Fri, Jun 14, 2013 at 01:06:30PM +, Sanjeev Neelarapu wrote:
>> Hi,
>> 
>> I have a query on how to add NFS Cache storage.
>> Before creating a zone if we create a secondary storage with s3 as
>> the storage provider and don't select NFS Cache Storage then we treat
>> it as
>> S3 at region level.
>> Later I create a zone and at "add secondary storage" creation wizard
>> in UI if I select NFS as secondary storage provider will it be
 treated
>> as NFS Cache Storage? If not is there a way to add NFS cache storage
>> for that zone?
>> 
>> Thanks,
>> Sanjeev
>> 
> 
> Based on the thread talking about this [1], I'm not sure that it will
> be implemented this way anymore.
> 
> -chip
> 
> [1] http://markmail.org/message/c73nagj45q6iktfh
>>> 
>> 
>

Re: NFS Cache storage query

On Wed, Jun 19, 2013 at 01:07:29PM -0400, John Burwell wrote:
> Nitin,
> 
> If we provide any APIs for the staging/temporary area, they must be 
> read-only.  Allowing any external manipulation of its content could cause 
> break in-flight transfers or cause data loss.  I think we should consider the 
> following APIs:
> 
> List contents including name, reference count, and size
> Summary statistics for a staging area including consumed/available/total 
> space and timestamp of the last garbage collection operation
> Force garbage collection/cleanup operation
> 
> I think we should these are new API calls specific to the staging/temporary 
> area mechanism rather than trying to overload existing API calls.
> 
> Thanks,
> -John

What about creating / destroying them?

Re: [ANNOUNCE] New committer: Mike Tutkowski

2013-06-19 Thread Sebastien Goasguen

Well done Mike,

-Sebastien

On 19 Jun 2013, at 16:38, Joe Brockmeier  wrote:

> On Wed, Jun 19, 2013, at 08:39 AM, Alex Huang wrote:
>> Please join me in congratulating Mike!
> 
> Congrats Mike! 
> 
> Best,
> 
> jzb
> -- 
> Joe Brockmeier
> j...@zonker.net
> Twitter: @jzb
> http://www.dissociatedpress.net/

Re: IRC meeting today

2013-06-19 Thread John Kinsella

We had about 4 of us in the meeting, so we just dropped it until next week.

On Jun 19, 2013, at 9:15 AM, John Kinsella 
 wrote:

> I'm happy to run it
> 
> On Jun 19, 2013, at 8:45 AM, Chip Childers 
> wrote:
> 
>> Hi all,
>> 
>> Joe asked me to facilitate the meeting today, however I have a $dayjob
>> responsibility that just came up.  I'm not going to be able to do
>> anything other than lurk in the channel.
>> 
>> I'm going to suggest that we cancel the meeting for today, unless
>> someone else wants to run it.
>> 
>> -chip
>

Re: NFS Cache storage query

Chip,

Good catch.  Yes, we need definitely need a create staging/temporary area API 
call.  However, destroy is a bit more complicated due in-flight operations.  
Given the complexities and time pressures, I recommend supporting only create 
in 4.2, and addressing delete in 4.3.  Does that make sense?

Thanks,
-John 

On Jun 19, 2013, at 1:11 PM, Chip Childers  wrote:

> On Wed, Jun 19, 2013 at 01:07:29PM -0400, John Burwell wrote:
>> Nitin,
>> 
>> If we provide any APIs for the staging/temporary area, they must be 
>> read-only.  Allowing any external manipulation of its content could cause 
>> break in-flight transfers or cause data loss.  I think we should consider 
>> the following APIs:
>> 
>> List contents including name, reference count, and size
>> Summary statistics for a staging area including consumed/available/total 
>> space and timestamp of the last garbage collection operation
>> Force garbage collection/cleanup operation
>> 
>> I think we should these are new API calls specific to the staging/temporary 
>> area mechanism rather than trying to overload existing API calls.
>> 
>> Thanks,
>> -John
> 
> What about creating / destroying them?

Re: NFS Cache storage query

On Wed, Jun 19, 2013 at 01:23:47PM -0400, John Burwell wrote:
> Chip,
> 
> Good catch.  Yes, we need definitely need a create staging/temporary area API 
> call.  However, destroy is a bit more complicated due in-flight operations.  
> Given the complexities and time pressures, I recommend supporting only create 
> in 4.2, and addressing delete in 4.3.  Does that make sense?
> 

If the existence of the staging datastore blocks the deleting of a
zone, or any other entity, then that doesn't work for me.

I'd rather give an operator the ability to decide how to best ensure
that in-flight operations are halted (i.e.: block users from the
environment or something else), than not give them a way to change their
configuration.

> Thanks,
> -John 
> 
> On Jun 19, 2013, at 1:11 PM, Chip Childers  wrote:
> 
> > On Wed, Jun 19, 2013 at 01:07:29PM -0400, John Burwell wrote:
> >> Nitin,
> >> 
> >> If we provide any APIs for the staging/temporary area, they must be 
> >> read-only.  Allowing any external manipulation of its content could cause 
> >> break in-flight transfers or cause data loss.  I think we should consider 
> >> the following APIs:
> >> 
> >> List contents including name, reference count, and size
> >> Summary statistics for a staging area including consumed/available/total 
> >> space and timestamp of the last garbage collection operation
> >> Force garbage collection/cleanup operation
> >> 
> >> I think we should these are new API calls specific to the 
> >> staging/temporary area mechanism rather than trying to overload existing 
> >> API calls.
> >> 
> >> Thanks,
> >> -John
> > 
> > What about creating / destroying them?
> 
>

Re: NFS Cache storage query

Chip,

Your concern had not occurred to me -- making me realize that either destroy or 
a zone attach/detach operation for the staging/temporary area mechanism in 4.2. 
 Thinking through it, there are two types of operations occurring with the 
staging/temporary area.  The first is data being pulled from the object store 
to support some activity (e.g. copying a template down to create a VM).  From a 
data integrity perspective, it is safe to kill these operations since the data 
has already been persisted to the object store.  The second is data being 
pushed to the object store which are much more problematic.  Of particular 
concern would be snapshots that are in the staging/temporary area, but not yet 
transferred to the object store.  

Edison/Min: Does the current implementation provide a destroy or attach/detach 
behavior?  If so, how are in-flight operations handled to ensure there is no 
data loss?

Thanks,
-John

On Jun 19, 2013, at 1:26 PM, Chip Childers  wrote:

> On Wed, Jun 19, 2013 at 01:23:47PM -0400, John Burwell wrote:
>> Chip,
>> 
>> Good catch.  Yes, we need definitely need a create staging/temporary area 
>> API call.  However, destroy is a bit more complicated due in-flight 
>> operations.  Given the complexities and time pressures, I recommend 
>> supporting only create in 4.2, and addressing delete in 4.3.  Does that make 
>> sense?
>> 
> 
> If the existence of the staging datastore blocks the deleting of a
> zone, or any other entity, then that doesn't work for me.
> 
> I'd rather give an operator the ability to decide how to best ensure
> that in-flight operations are halted (i.e.: block users from the
> environment or something else), than not give them a way to change their
> configuration.
> 
>> Thanks,
>> -John 
>> 
>> On Jun 19, 2013, at 1:11 PM, Chip Childers  wrote:
>> 
>>> On Wed, Jun 19, 2013 at 01:07:29PM -0400, John Burwell wrote:
 Nitin,

 If we provide any APIs for the staging/temporary area, they must be 
 read-only.  Allowing any external manipulation of its content could cause 
 break in-flight transfers or cause data loss.  I think we should consider 
 the following APIs:

 List contents including name, reference count, and size
 Summary statistics for a staging area including consumed/available/total 
 space and timestamp of the last garbage collection operation
 Force garbage collection/cleanup operation

 I think we should these are new API calls specific to the 
 staging/temporary area mechanism rather than trying to overload existing 
 API calls.

 Thanks,
 -John
>>> 
>>> What about creating / destroying them?
>> 
>>

RE: NFS Cache storage query



> -Original Message-
> From: John Burwell [mailto:jburw...@basho.com]
> Sent: Wednesday, June 19, 2013 10:42 AM
> To: dev@cloudstack.apache.org
> Cc: Edison Su
> Subject: Re: NFS Cache storage query
> 
> Chip,
> 
> Your concern had not occurred to me -- making me realize that either destroy
> or a zone attach/detach operation for the staging/temporary area
> mechanism in 4.2.  Thinking through it, there are two types of operations
> occurring with the staging/temporary area.  The first is data being pulled 
> from
> the object store to support some activity (e.g. copying a template down to
> create a VM).  From a data integrity perspective, it is safe to kill these
> operations since the data has already been persisted to the object store.
> The second is data being pushed to the object store which are much more
> problematic.  Of particular concern would be snapshots that are in the
> staging/temporary area, but not yet transferred to the object store.
> 
> Edison/Min: Does the current implementation provide a destroy or
> attach/detach behavior?  If so, how are in-flight operations handled to
> ensure there is no data loss?

The current mater branch, there is no such operation for secondary storage yet, 
so does the object_store branch.
Maybe we can discuss/implement a better life cycle management of both nfs 
secondary storage and staging area in collab next week.

> 
> Thanks,
> -John
> 
> On Jun 19, 2013, at 1:26 PM, Chip Childers 
> wrote:
> 
> > On Wed, Jun 19, 2013 at 01:23:47PM -0400, John Burwell wrote:
> >> Chip,
> >>
> >> Good catch.  Yes, we need definitely need a create staging/temporary
> area API call.  However, destroy is a bit more complicated due in-flight
> operations.  Given the complexities and time pressures, I recommend
> supporting only create in 4.2, and addressing delete in 4.3.  Does that make
> sense?
> >>
> >
> > If the existence of the staging datastore blocks the deleting of a
> > zone, or any other entity, then that doesn't work for me.
> >
> > I'd rather give an operator the ability to decide how to best ensure
> > that in-flight operations are halted (i.e.: block users from the
> > environment or something else), than not give them a way to change
> > their configuration.
> >
> >> Thanks,
> >> -John
> >>
> >> On Jun 19, 2013, at 1:11 PM, Chip Childers 
> wrote:
> >>
> >>> On Wed, Jun 19, 2013 at 01:07:29PM -0400, John Burwell wrote:
>  Nitin,
> 
>  If we provide any APIs for the staging/temporary area, they must be
> read-only.  Allowing any external manipulation of its content could cause
> break in-flight transfers or cause data loss.  I think we should consider the
> following APIs:
> 
>  List contents including name, reference count, and size Summary
>  statistics for a staging area including consumed/available/total
>  space and timestamp of the last garbage collection operation Force
>  garbage collection/cleanup operation
> 
>  I think we should these are new API calls specific to the
> staging/temporary area mechanism rather than trying to overload existing
> API calls.
> 
>  Thanks,
>  -John
> >>>
> >>> What about creating / destroying them?
> >>
> >>

Review Request: Re-enabling baremetal for 4.2/master


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

Review request for cloudstack.


Description
---

This patch would re-enable baremetal support for master, which we've disabled 
on 4.1 release due to release blocker bugs.

After review passed, I would apply the patch to master in small patches.


This addresses bug https://issues.apache.org/jira/browse/CLOUDSTACK-3077.


Diffs
-

  client/pom.xml ab758eb 
  client/tomcatconf/applicationContext.xml.in 049e483 
  client/tomcatconf/componentContext.xml.in 93ef21f 
  client/tomcatconf/nonossComponentContext.xml.in 143aa22 
  
plugins/hypervisors/baremetal/src/com/cloud/baremetal/manager/BareMetalDiscoverer.java
 edb5dea 
  
plugins/hypervisors/baremetal/src/com/cloud/baremetal/manager/BareMetalTemplateAdapter.java
 928183b 
  
plugins/hypervisors/baremetal/src/com/cloud/baremetal/networkservice/BaremetalDhcpElement.java
 fdf8b63 
  plugins/network-elements/dns-notifier/resources/components-example.xml 
2e9c5be 
  server/src/com/cloud/configuration/Config.java f6fa974 
  server/src/com/cloud/network/NetworkServiceImpl.java aace68d 
  setup/db/db/schema-410to420.sql bcdf2d9 

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


Testing
---

All the following bugs(which are the original blocker for 4.1 releases) are 
tested against the patch.

https://issues.apache.org/jira/browse/CLOUDSTACK-1610
https://issues.apache.org/jira/browse/CLOUDSTACK-1618
https://issues.apache.org/jira/browse/CLOUDSTACK-1614
https://issues.apache.org/jira/browse/CLOUDSTACK-1440


Thanks,

Sheng Yang

Re: NFS Cache storage query

Edison,

For 4.2, are we going to state that the object store is just a backup of NFS 
(i.e. the same as 4.1)?

Thanks,
-John

On Jun 19, 2013, at 1:58 PM, Edison Su  wrote:

> 
> 
>> -Original Message-
>> From: John Burwell [mailto:jburw...@basho.com]
>> Sent: Wednesday, June 19, 2013 10:42 AM
>> To: dev@cloudstack.apache.org
>> Cc: Edison Su
>> Subject: Re: NFS Cache storage query
>> 
>> Chip,
>> 
>> Your concern had not occurred to me -- making me realize that either destroy
>> or a zone attach/detach operation for the staging/temporary area
>> mechanism in 4.2.  Thinking through it, there are two types of operations
>> occurring with the staging/temporary area.  The first is data being pulled 
>> from
>> the object store to support some activity (e.g. copying a template down to
>> create a VM).  From a data integrity perspective, it is safe to kill these
>> operations since the data has already been persisted to the object store.
>> The second is data being pushed to the object store which are much more
>> problematic.  Of particular concern would be snapshots that are in the
>> staging/temporary area, but not yet transferred to the object store.
>> 
>> Edison/Min: Does the current implementation provide a destroy or
>> attach/detach behavior?  If so, how are in-flight operations handled to
>> ensure there is no data loss?
> 
> The current mater branch, there is no such operation for secondary storage 
> yet, so does the object_store branch.
> Maybe we can discuss/implement a better life cycle management of both nfs 
> secondary storage and staging area in collab next week.
> 
>> 
>> Thanks,
>> -John
>> 
>> On Jun 19, 2013, at 1:26 PM, Chip Childers 
>> wrote:
>> 
>>> On Wed, Jun 19, 2013 at 01:23:47PM -0400, John Burwell wrote:
 Chip,
 
 Good catch.  Yes, we need definitely need a create staging/temporary
>> area API call.  However, destroy is a bit more complicated due in-flight
>> operations.  Given the complexities and time pressures, I recommend
>> supporting only create in 4.2, and addressing delete in 4.3.  Does that make
>> sense?
 
>>> 
>>> If the existence of the staging datastore blocks the deleting of a
>>> zone, or any other entity, then that doesn't work for me.
>>> 
>>> I'd rather give an operator the ability to decide how to best ensure
>>> that in-flight operations are halted (i.e.: block users from the
>>> environment or something else), than not give them a way to change
>>> their configuration.
>>> 
 Thanks,
 -John
 
 On Jun 19, 2013, at 1:11 PM, Chip Childers 
>> wrote:
 
> On Wed, Jun 19, 2013 at 01:07:29PM -0400, John Burwell wrote:
>> Nitin,
>> 
>> If we provide any APIs for the staging/temporary area, they must be
>> read-only.  Allowing any external manipulation of its content could cause
>> break in-flight transfers or cause data loss.  I think we should consider the
>> following APIs:
>> 
>> List contents including name, reference count, and size Summary
>> statistics for a staging area including consumed/available/total
>> space and timestamp of the last garbage collection operation Force
>> garbage collection/cleanup operation
>> 
>> I think we should these are new API calls specific to the
>> staging/temporary area mechanism rather than trying to overload existing
>> API calls.
>> 
>> Thanks,
>> -John
> 
> What about creating / destroying them?
 
 
>

[Review Request] Re-enabling baremetal on master

Hi,

I've created the https://reviews.apache.org/r/11977/  for review. The
branch re-enabled the baremetal for master. And all major bugs are cleaned.

https://issues.apache.org/jira/browse/CLOUDSTACK-1610
https://issues.apache.org/jira/browse/CLOUDSTACK-1618
https://issues.apache.org/jira/browse/CLOUDSTACK-1614
https://issues.apache.org/jira/browse/CLOUDSTACK-1440

In fact it's not a feature merge, because the code is already in MASTER
ready. We just disable it due to stability problem of 4.1 release. Now I've
tried to enable it, and the changeset is very small, mostly just revert the
old disabling baremetal codes, and fix some issues with introducing other
new features. Here is the summary:

 client/pom.xml
|  5 +
 client/tomcatconf/applicationContext.xml.in
 |  4 
 client/tomcatconf/componentContext.xml.in
 | 10 --
 client/tomcatconf/nonossComponentContext.xml.in
 |  8 
 
plugins/hypervisors/baremetal/src/com/cloud/baremetal/manager/BareMetalDiscoverer.java
|  3 ++-
 
plugins/hypervisors/baremetal/src/com/cloud/baremetal/manager/BareMetalTemplateAdapter.java
   |  6 --
 
plugins/hypervisors/baremetal/src/com/cloud/baremetal/networkservice/BaremetalDhcpElement.java
|  6 --
 plugins/network-elements/dns-notifier/resources/components-example.xml
|  8 
 server/src/com/cloud/configuration/Config.java
|  2 +-
 server/src/com/cloud/network/NetworkServiceImpl.java
|  9 +++--
 setup/db/db/schema-410to420.sql
 | 16 
 11 files changed, 31 insertions(+), 46 deletions(-)

Alena has pointed out db upgrade issue in my previous post and I've fixed
it.

Thanks!

--Sheng

RE: IRC meeting today

2013-06-19 Thread Alex Huang

Sorry.  I had to drop out due to day job as well.

--Alex

> -Original Message-
> From: John Kinsella [mailto:j...@stratosec.co]
> Sent: Wednesday, June 19, 2013 10:19 AM
> To: 
> Subject: Re: IRC meeting today
> 
> We had about 4 of us in the meeting, so we just dropped it until next week.
> 
> On Jun 19, 2013, at 9:15 AM, John Kinsella 
>  wrote:
> 
> > I'm happy to run it
> >
> > On Jun 19, 2013, at 8:45 AM, Chip Childers 
> > wrote:
> >
> >> Hi all,
> >>
> >> Joe asked me to facilitate the meeting today, however I have a
> >> $dayjob responsibility that just came up.  I'm not going to be able
> >> to do anything other than lurk in the channel.
> >>
> >> I'm going to suggest that we cancel the meeting for today, unless
> >> someone else wants to run it.
> >>
> >> -chip
> >

RE: NFS Cache storage query

Yes and No:)
Yes, as all the hypervisors(KVM/Vmware/Xenserver) still need NFS in 4.2, even 
S3 is used as the place to store templates.
No, we make NFS is optional, if you don't want to use NFS. E.g the HyperV 
implementation will not depend on NFS. 

In 4.3, we can start work on the hypervisor side refactor, to eliminate the 
dependence on NFS as much as possible, then we may can truly make the statement 
that, S3 will be the "secondary storage".

> -Original Message-
> From: John Burwell [mailto:jburw...@basho.com]
> Sent: Wednesday, June 19, 2013 11:00 AM
> To: Edison Su
> Cc: dev@cloudstack.apache.org
> Subject: Re: NFS Cache storage query
> 
> Edison,
> 
> For 4.2, are we going to state that the object store is just a backup of NFS 
> (i.e.
> the same as 4.1)?
> 
> Thanks,
> -John
> 
> On Jun 19, 2013, at 1:58 PM, Edison Su  wrote:
> 
> >
> >
> >> -Original Message-
> >> From: John Burwell [mailto:jburw...@basho.com]
> >> Sent: Wednesday, June 19, 2013 10:42 AM
> >> To: dev@cloudstack.apache.org
> >> Cc: Edison Su
> >> Subject: Re: NFS Cache storage query
> >>
> >> Chip,
> >>
> >> Your concern had not occurred to me -- making me realize that either
> >> destroy or a zone attach/detach operation for the staging/temporary
> >> area mechanism in 4.2.  Thinking through it, there are two types of
> >> operations occurring with the staging/temporary area.  The first is
> >> data being pulled from the object store to support some activity
> >> (e.g. copying a template down to create a VM).  From a data integrity
> >> perspective, it is safe to kill these operations since the data has already
> been persisted to the object store.
> >> The second is data being pushed to the object store which are much
> >> more problematic.  Of particular concern would be snapshots that are
> >> in the staging/temporary area, but not yet transferred to the object store.
> >>
> >> Edison/Min: Does the current implementation provide a destroy or
> >> attach/detach behavior?  If so, how are in-flight operations handled
> >> to ensure there is no data loss?
> >
> > The current mater branch, there is no such operation for secondary storage
> yet, so does the object_store branch.
> > Maybe we can discuss/implement a better life cycle management of both
> nfs secondary storage and staging area in collab next week.
> >
> >>
> >> Thanks,
> >> -John
> >>
> >> On Jun 19, 2013, at 1:26 PM, Chip Childers
> >> 
> >> wrote:
> >>
> >>> On Wed, Jun 19, 2013 at 01:23:47PM -0400, John Burwell wrote:
>  Chip,
> 
>  Good catch.  Yes, we need definitely need a create
>  staging/temporary
> >> area API call.  However, destroy is a bit more complicated due
> >> in-flight operations.  Given the complexities and time pressures, I
> >> recommend supporting only create in 4.2, and addressing delete in
> >> 4.3.  Does that make sense?
> 
> >>>
> >>> If the existence of the staging datastore blocks the deleting of a
> >>> zone, or any other entity, then that doesn't work for me.
> >>>
> >>> I'd rather give an operator the ability to decide how to best ensure
> >>> that in-flight operations are halted (i.e.: block users from the
> >>> environment or something else), than not give them a way to change
> >>> their configuration.
> >>>
>  Thanks,
>  -John
> 
>  On Jun 19, 2013, at 1:11 PM, Chip Childers
>  
> >> wrote:
> 
> > On Wed, Jun 19, 2013 at 01:07:29PM -0400, John Burwell wrote:
> >> Nitin,
> >>
> >> If we provide any APIs for the staging/temporary area, they must
> >> be
> >> read-only.  Allowing any external manipulation of its content could
> >> cause break in-flight transfers or cause data loss.  I think we
> >> should consider the following APIs:
> >>
> >> List contents including name, reference count, and size Summary
> >> statistics for a staging area including consumed/available/total
> >> space and timestamp of the last garbage collection operation
> >> Force garbage collection/cleanup operation
> >>
> >> I think we should these are new API calls specific to the
> >> staging/temporary area mechanism rather than trying to overload
> >> existing API calls.
> >>
> >> Thanks,
> >> -John
> >
> > What about creating / destroying them?
> 
> 
> >

Re: [Review Request] Re-enabling baremetal on master

On Wed, Jun 19, 2013 at 11:00:33AM -0700, Sheng Yang wrote:
> Hi,
> 
> I've created the https://reviews.apache.org/r/11977/  for review. The
> branch re-enabled the baremetal for master. And all major bugs are cleaned.
> 
> https://issues.apache.org/jira/browse/CLOUDSTACK-1610
> https://issues.apache.org/jira/browse/CLOUDSTACK-1618
> https://issues.apache.org/jira/browse/CLOUDSTACK-1614
> https://issues.apache.org/jira/browse/CLOUDSTACK-1440
> 
> In fact it's not a feature merge, because the code is already in MASTER
> ready. We just disable it due to stability problem of 4.1 release. Now I've
> tried to enable it, and the changeset is very small, mostly just revert the
> old disabling baremetal codes, and fix some issues with introducing other
> new features. Here is the summary:

[snip]

So David's standing veto was because of this comment (from him):

"Baremetal seems to be suffering from a significant lack of unit tests
and integration tests for marvin to consume. Let's get those in place
before we consider re-enabling this."

If I remember correctly, the reason that master has the code in it, is 
specifically because we decided that disabling the feature was easier to 
honor the veto than reverting all of the changes.

That being said, have we addressed the original veto's concerns?

-chip

Re: Baremetal re-enabling

On Tue, Jun 18, 2013 at 4:53 PM, Sheng Yang  wrote:
> Hi,
>
> Due to absent of Frank, I've tried to make sure Baremetal wouldn't miss
> 4.2. So for the last a few days work, I am able to re-enable baremetal for
> master.
>
> It turn out the change is not big, and most of it just compose of revert of
> previous change, and I fixed some issues brought by the new features.
>
> The total change summary is:
>
> --
>  client/pom.xml
> |  5 +
>  client/tomcatconf/applicationContext.xml.in
>  |  4 
>  client/tomcatconf/componentContext.xml.in
>  | 10 --
>  client/tomcatconf/nonossComponentContext.xml.in
>  |  8 
>  
> plugins/hypervisors/baremetal/src/com/cloud/baremetal/manager/BareMetalDiscoverer.java
> |  3 ++-
>  
> plugins/hypervisors/baremetal/src/com/cloud/baremetal/manager/BareMetalTemplateAdapter.java
>|  6 --
>  
> plugins/hypervisors/baremetal/src/com/cloud/baremetal/networkservice/BaremetalDhcpElement.java
> |  6 --
>  plugins/network-elements/dns-notifier/resources/components-example.xml
> |  8 
>  server/src/com/cloud/network/NetworkServiceImpl.java
> |  9 +++--
>  9 files changed, 14 insertions(+), 45 deletions(-)
>
>
> I've tested against the original blocker issues:
> https://issues.apache.org/jira/browse/CLOUDSTACK-1610
> https://issues.apache.org/jira/browse/CLOUDSTACK-1618
> https://issues.apache.org/jira/browse/CLOUDSTACK-1614
> https://issues.apache.org/jira/browse/CLOUDSTACK-1440
>
> They all passed.
>
> Can I say we're ready to re-enable the baremetal in master now?
>
> --Sheng

Please see my question in the [REVIEW] thread you started.  Thanks!

Re: [Review Request] Re-enabling baremetal on master

On Wed, Jun 19, 2013 at 11:24 AM, Chip Childers
wrote:

> On Wed, Jun 19, 2013 at 11:00:33AM -0700, Sheng Yang wrote:
> > Hi,
> >
> > I've created the https://reviews.apache.org/r/11977/  for review. The
> > branch re-enabled the baremetal for master. And all major bugs are
> cleaned.
> >
> > https://issues.apache.org/jira/browse/CLOUDSTACK-1610
> > https://issues.apache.org/jira/browse/CLOUDSTACK-1618
> > https://issues.apache.org/jira/browse/CLOUDSTACK-1614
> > https://issues.apache.org/jira/browse/CLOUDSTACK-1440
> >
> > In fact it's not a feature merge, because the code is already in MASTER
> > ready. We just disable it due to stability problem of 4.1 release. Now
> I've
> > tried to enable it, and the changeset is very small, mostly just revert
> the
> > old disabling baremetal codes, and fix some issues with introducing other
> > new features. Here is the summary:
>
> [snip]
>
> So David's standing veto was because of this comment (from him):
>
> "Baremetal seems to be suffering from a significant lack of unit tests
> and integration tests for marvin to consume. Let's get those in place
> before we consider re-enabling this."
>
> If I remember correctly, the reason that master has the code in it, is
> specifically because we decided that disabling the feature was easier to
> honor the veto than reverting all of the changes.
>
> That being said, have we addressed the original veto's concerns?
>

Not yet. I didn't realize it's vetoed due to this. Let me see what can I do
about it.

In fact the above bugs cannot be detected for unit test or marvin test(I
even not sure if they're valid bugs or not, but at that time Frank is on
vacation and nobody took a look at these then decided disable the feature,
and after I re-enabled them, everything works fine for me).

--Sheng

>
> -chip
>

Re: [Review Request] Re-enabling baremetal on master

On Wed, Jun 19, 2013 at 11:36:11AM -0700, Sheng Yang wrote:
> On Wed, Jun 19, 2013 at 11:24 AM, Chip Childers
> wrote:
> 
> > On Wed, Jun 19, 2013 at 11:00:33AM -0700, Sheng Yang wrote:
> > > Hi,
> > >
> > > I've created the https://reviews.apache.org/r/11977/  for review. The
> > > branch re-enabled the baremetal for master. And all major bugs are
> > cleaned.
> > >
> > > https://issues.apache.org/jira/browse/CLOUDSTACK-1610
> > > https://issues.apache.org/jira/browse/CLOUDSTACK-1618
> > > https://issues.apache.org/jira/browse/CLOUDSTACK-1614
> > > https://issues.apache.org/jira/browse/CLOUDSTACK-1440
> > >
> > > In fact it's not a feature merge, because the code is already in MASTER
> > > ready. We just disable it due to stability problem of 4.1 release. Now
> > I've
> > > tried to enable it, and the changeset is very small, mostly just revert
> > the
> > > old disabling baremetal codes, and fix some issues with introducing other
> > > new features. Here is the summary:
> >
> > [snip]
> >
> > So David's standing veto was because of this comment (from him):
> >
> > "Baremetal seems to be suffering from a significant lack of unit tests
> > and integration tests for marvin to consume. Let's get those in place
> > before we consider re-enabling this."
> >
> > If I remember correctly, the reason that master has the code in it, is
> > specifically because we decided that disabling the feature was easier to
> > honor the veto than reverting all of the changes.
> >
> > That being said, have we addressed the original veto's concerns?
> >
> 
> Not yet. I didn't realize it's vetoed due to this. Let me see what can I do
> about it.

Awesome.  Thanks Sheng!

> 
> In fact the above bugs cannot be detected for unit test or marvin test(I
> even not sure if they're valid bugs or not, but at that time Frank is on
> vacation and nobody took a look at these then decided disable the feature,
> and after I re-enabled them, everything works fine for me).

Yeah, I think that the bugs were just in need of triage.  The bugs
themselves weren't the major issue (although they were concerning), as
much as test coverage at either (or both) unit or integration levels.

-chip

Re: NFS Cache storage query

Edison,

Based on the stance you have outlined, the usage of NFS in the object_store 
branch and 4.1 are not comparable.  In 4.1, NFS is the store of record for 
data.  Therefore, presence of the file in the NFS volume indicates that the 
data is permanently stored.  However, in object_store, presence in NFS in the 
object_store branch means that the data may be awaiting permanent stage 
(dependent on the type of pending transfer operation).  As such, I think we 
will need to provide insurance that in-flight operations are completed before a 
staging/temporary area is destroyed.  Another option I can see is to change the 
way these staging/temporary areas are associated with zones.  If we approached 
them as standalone entities that are attached or detached from a zone, we could 
define the detach operation as only disassociation from a zone without 
impacting in-flight operations.  This solution would allow zones to be deleted 
without impacting in-flight operations. 

Thanks,
-John

On Jun 19, 2013, at 2:15 PM, Edison Su  wrote:

> Yes and No:)
> Yes, as all the hypervisors(KVM/Vmware/Xenserver) still need NFS in 4.2, even 
> S3 is used as the place to store templates.
> No, we make NFS is optional, if you don't want to use NFS. E.g the HyperV 
> implementation will not depend on NFS. 
> 
> In 4.3, we can start work on the hypervisor side refactor, to eliminate the 
> dependence on NFS as much as possible, then we may can truly make the 
> statement that, S3 will be the "secondary storage".
> 
>> -Original Message-
>> From: John Burwell [mailto:jburw...@basho.com]
>> Sent: Wednesday, June 19, 2013 11:00 AM
>> To: Edison Su
>> Cc: dev@cloudstack.apache.org
>> Subject: Re: NFS Cache storage query
>> 
>> Edison,
>> 
>> For 4.2, are we going to state that the object store is just a backup of NFS 
>> (i.e.
>> the same as 4.1)?
>> 
>> Thanks,
>> -John
>> 
>> On Jun 19, 2013, at 1:58 PM, Edison Su  wrote:
>> 
>>> 
>>> 
 -Original Message-
 From: John Burwell [mailto:jburw...@basho.com]
 Sent: Wednesday, June 19, 2013 10:42 AM
 To: dev@cloudstack.apache.org
 Cc: Edison Su
 Subject: Re: NFS Cache storage query
 
 Chip,
 
 Your concern had not occurred to me -- making me realize that either
 destroy or a zone attach/detach operation for the staging/temporary
 area mechanism in 4.2.  Thinking through it, there are two types of
 operations occurring with the staging/temporary area.  The first is
 data being pulled from the object store to support some activity
 (e.g. copying a template down to create a VM).  From a data integrity
 perspective, it is safe to kill these operations since the data has already
>> been persisted to the object store.
 The second is data being pushed to the object store which are much
 more problematic.  Of particular concern would be snapshots that are
 in the staging/temporary area, but not yet transferred to the object store.
 
 Edison/Min: Does the current implementation provide a destroy or
 attach/detach behavior?  If so, how are in-flight operations handled
 to ensure there is no data loss?
>>> 
>>> The current mater branch, there is no such operation for secondary storage
>> yet, so does the object_store branch.
>>> Maybe we can discuss/implement a better life cycle management of both
>> nfs secondary storage and staging area in collab next week.
>>> 
 
 Thanks,
 -John
 
 On Jun 19, 2013, at 1:26 PM, Chip Childers
 
 wrote:
 
> On Wed, Jun 19, 2013 at 01:23:47PM -0400, John Burwell wrote:
>> Chip,
>> 
>> Good catch.  Yes, we need definitely need a create
>> staging/temporary
 area API call.  However, destroy is a bit more complicated due
 in-flight operations.  Given the complexities and time pressures, I
 recommend supporting only create in 4.2, and addressing delete in
 4.3.  Does that make sense?
>> 
> 
> If the existence of the staging datastore blocks the deleting of a
> zone, or any other entity, then that doesn't work for me.
> 
> I'd rather give an operator the ability to decide how to best ensure
> that in-flight operations are halted (i.e.: block users from the
> environment or something else), than not give them a way to change
> their configuration.
> 
>> Thanks,
>> -John
>> 
>> On Jun 19, 2013, at 1:11 PM, Chip Childers
>> 
 wrote:
>> 
>>> On Wed, Jun 19, 2013 at 01:07:29PM -0400, John Burwell wrote:
 Nitin,
 
 If we provide any APIs for the staging/temporary area, they must
 be
 read-only.  Allowing any external manipulation of its content could
 cause break in-flight transfers or cause data loss.  I think we
 should consider the following APIs:
 
 List contents including name, reference count, and size Summary
 statistics for a staging area including consume

RE: NFS Cache storage query



> -Original Message-
> From: John Burwell [mailto:jburw...@basho.com]
> Sent: Wednesday, June 19, 2013 11:43 AM
> To: Edison Su
> Cc: dev@cloudstack.apache.org
> Subject: Re: NFS Cache storage query
> 
> Edison,
> 
> Based on the stance you have outlined, the usage of NFS in the object_store
> branch and 4.1 are not comparable.  In 4.1, NFS is the store of record for 
> data.
> Therefore, presence of the file in the NFS volume indicates that the data is
> permanently stored.  However, in object_store, presence in NFS in the
> object_store branch means that the data may be awaiting permanent stage
> (dependent on the type of pending transfer operation).  As such, I think we
> will need to provide insurance that in-flight operations are completed before
> a staging/temporary area is destroyed.  Another option I can see is to change
> the way these staging/temporary areas are associated with zones.  If we
> approached them as standalone entities that are attached or detached from
> a zone, we could define the detach operation as only disassociation from a
> zone without impacting in-flight operations.  This solution would allow zones
> to be deleted without impacting in-flight operations.

The interface is there: 
https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=blob;f=engine/api/src/org/apache/cloudstack/engine/subsystem/api/storage/DataStoreLifeCycle.java;h=1e893db6bb5b1dbae0142e8a26019ae34d44320a;hb=refs/heads/object_store
Admin should be able to put the data store into maintenance mode, and then 
delete it, but the implementation is not there yet for both NFS secondary 
storage and staging area.
For NFS, S3 secondary storage, we should at least implement 
maintenance/cancelMaintain in 4.2
For NFS staging area, we should at least implement maintenance/cancelMaintain 
in 4.2, the delete method in 4.3.
How do you think?


> 
> Thanks,
> -John
> 
> On Jun 19, 2013, at 2:15 PM, Edison Su  wrote:
> 
> > Yes and No:)
> > Yes, as all the hypervisors(KVM/Vmware/Xenserver) still need NFS in 4.2,
> even S3 is used as the place to store templates.
> > No, we make NFS is optional, if you don't want to use NFS. E.g the HyperV
> implementation will not depend on NFS.
> >
> > In 4.3, we can start work on the hypervisor side refactor, to eliminate the
> dependence on NFS as much as possible, then we may can truly make the
> statement that, S3 will be the "secondary storage".
> >
> >> -Original Message-
> >> From: John Burwell [mailto:jburw...@basho.com]
> >> Sent: Wednesday, June 19, 2013 11:00 AM
> >> To: Edison Su
> >> Cc: dev@cloudstack.apache.org
> >> Subject: Re: NFS Cache storage query
> >>
> >> Edison,
> >>
> >> For 4.2, are we going to state that the object store is just a backup of 
> >> NFS
> (i.e.
> >> the same as 4.1)?
> >>
> >> Thanks,
> >> -John
> >>
> >> On Jun 19, 2013, at 1:58 PM, Edison Su  wrote:
> >>
> >>>
> >>>
>  -Original Message-
>  From: John Burwell [mailto:jburw...@basho.com]
>  Sent: Wednesday, June 19, 2013 10:42 AM
>  To: dev@cloudstack.apache.org
>  Cc: Edison Su
>  Subject: Re: NFS Cache storage query
> 
>  Chip,
> 
>  Your concern had not occurred to me -- making me realize that
>  either destroy or a zone attach/detach operation for the
>  staging/temporary area mechanism in 4.2.  Thinking through it,
>  there are two types of operations occurring with the
>  staging/temporary area.  The first is data being pulled from the
>  object store to support some activity (e.g. copying a template down
>  to create a VM).  From a data integrity perspective, it is safe to
>  kill these operations since the data has already
> >> been persisted to the object store.
>  The second is data being pushed to the object store which are much
>  more problematic.  Of particular concern would be snapshots that
>  are in the staging/temporary area, but not yet transferred to the object
> store.
> 
>  Edison/Min: Does the current implementation provide a destroy or
>  attach/detach behavior?  If so, how are in-flight operations
>  handled to ensure there is no data loss?
> >>>
> >>> The current mater branch, there is no such operation for secondary
> >>> storage
> >> yet, so does the object_store branch.
> >>> Maybe we can discuss/implement a better life cycle management of
> >>> both
> >> nfs secondary storage and staging area in collab next week.
> >>>
> 
>  Thanks,
>  -John
> 
>  On Jun 19, 2013, at 1:26 PM, Chip Childers
>  
>  wrote:
> 
> > On Wed, Jun 19, 2013 at 01:23:47PM -0400, John Burwell wrote:
> >> Chip,
> >>
> >> Good catch.  Yes, we need definitely need a create
> >> staging/temporary
>  area API call.  However, destroy is a bit more complicated due
>  in-flight operations.  Given the complexities and time pressures, I
>  recommend supporting only create in 4.2, and addressing delete in
>  4.3.  Does t

fixPath (was: committer wanted for review)

2013-06-19 Thread Daan Hoogland

John and others,

I have been looking for the point where the wrong path is instantiated.
After analyses I came to the DownloadAnswer class which contains the
original fixPath method that I c&p'ed to do my thing. I cannot support this
with logging however. Where the DownloadAnswer is created eludes me
however. I got trapped between DownloadManagerImpl and DownloadListener.
The creation of the answer was as far as I could tell in
handleDownloadProgressCmd but again I can not support this with logging.

As the reason I suppect eclipse class-file caching but also this theory
seems to not work.

Anyone's got a good clue for me?

I have burned to much time on this so I will save the patch for if  it is
locally needed by users, but I still want to find the best solution.

As for John's argument of creating technical debt, I am now convinced that
I am not adding but only using the present debt that is in there. The
DownloadAnswer.fixup() method is doing the same on a more obscure place
then my solution.

Also, if we decide to apply my changes anyway I think we should up the
loglevel at least as much as acceptable as to keep pointing to the
technical debt that we have at the moment.

On Tue, Jun 18, 2013 at 5:28 PM, Daan Hoogland wrote:

>  On 2013/6/18 16:49 , John Burwell wrote:
>
> Second, please don't take my feedback as passing judgements such as things 
> being ugly or
>
>  don't worry, I like the discussion and i don't mind losing an argument if
> the best solution arises from it. Let's see about that.
>
> --
>
> 
>

Re: [ANNOUNCE] New committer: Mike Tutkowski

Thanks, everyone! :)


On Wed, Jun 19, 2013 at 11:13 AM, Sebastien Goasguen wrote:

> Well done Mike,
>
> -Sebastien
>
> On 19 Jun 2013, at 16:38, Joe Brockmeier  wrote:
>
> > On Wed, Jun 19, 2013, at 08:39 AM, Alex Huang wrote:
> >> Please join me in congratulating Mike!
> >
> > Congrats Mike!
> >
> > Best,
> >
> > jzb
> > --
> > Joe Brockmeier
> > j...@zonker.net
> > Twitter: @jzb
> > http://www.dissociatedpress.net/
>



-- 
*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: disk_io_throttle and solidfire Patch Review Status

One thing I have been noticing is that there are now a lot of columns in
the Service Offerings - Disk Offerings table since Wei's four hypervisor
QoS fields are there. I don't know if others have observed this, but this
many columns seems to skew the table a bit: The columns don't entirely line
up. Initially, I thought this might "only" be a problem on my laptop's
relatively small screen, but in the office on a big monitor today, I see
the same issue.

I wonder if we want these four fields exposed in this table. For some it
will be useful, but for others it will always be four columns of empty
data. Perhaps we could get away with only showing them in the Details view
of a Disk Offering?

Just a thought.

On Wed, Jun 19, 2013 at 10:39 AM, Mike Tutkowski <
mike.tutkow...@solidfire.com> wrote:

> Maybe I'll just have to start doing bold like this: Bold even if it
> just displays as text. :)
>
>
> On Wed, Jun 19, 2013 at 10:36 AM, Chip Childers  > wrote:
>
>> On Wed, Jun 19, 2013 at 10:34:58AM -0600, Mike Tutkowski wrote:
>> > Comments below in red.
>>
>> We can't see the red for text emails.  ;-)
>>
>
>
>
> --
> *Mike Tutkowski*
> *Senior CloudStack Developer, SolidFire Inc.*
> e: mike.tutkow...@solidfire.com
> o: 303.746.7302
> Advancing the way the world uses the 
> cloud
> *™*
>

-- 
*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: disk_io_throttle and solidfire Patch Review Status

Well...it's not "necessary" per se. :) I just wanted to throw it out there
and get people's thoughts. I certainly don't want to take anything away
from your feature that you may value a lot.


On Wed, Jun 19, 2013 at 2:03 PM, Wei ZHOU  wrote:

> Mike,
>
> You can remove them from UI if necessary.
>
> -Wei
>
>
> 2013/6/19 Mike Tutkowski 
>
>> One thing I have been noticing is that there are now a lot of columns in
>> the Service Offerings - Disk Offerings table since Wei's four hypervisor
>> QoS fields are there. I don't know if others have observed this, but this
>> many columns seems to skew the table a bit: The columns don't entirely line
>> up. Initially, I thought this might "only" be a problem on my laptop's
>> relatively small screen, but in the office on a big monitor today, I see
>> the same issue.
>>
>> I wonder if we want these four fields exposed in this table. For some it
>> will be useful, but for others it will always be four columns of empty
>> data. Perhaps we could get away with only showing them in the Details view
>> of a Disk Offering?
>>
>> Just a thought.
>>
>>
>> On Wed, Jun 19, 2013 at 10:39 AM, Mike Tutkowski <
>> mike.tutkow...@solidfire.com> wrote:
>>
>>> Maybe I'll just have to start doing bold like this: Bold even if
>>> it just displays as text. :)
>>>
>>>
>>> On Wed, Jun 19, 2013 at 10:36 AM, Chip Childers <
>>> chip.child...@sungard.com> wrote:
>>>
 On Wed, Jun 19, 2013 at 10:34:58AM -0600, Mike Tutkowski wrote:
 > Comments below in red.

 We can't see the red for text emails.  ;-)

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


-- 
*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: fixPath (was: committer wanted for review)

The double slash can happen in every where, there is bug fix long time 
ago(http://bugs.cloud.com/show_bug.cgi?id=14066), which tries to change all the 
path concatenation, unfortunately, it's not been checked into cloudstack.
I am +1 with your patch, which at least fixes this particular issue, without 
changing too much code.

From: Daan Hoogland [mailto:daan.hoogl...@gmail.com]
Sent: Wednesday, June 19, 2013 12:38 PM
To: dev
Subject: fixPath (was: committer wanted for review)

John and others,
I have been looking for the point where the wrong path is instantiated. After 
analyses I came to the DownloadAnswer class which contains the original fixPath 
method that I c&p'ed to do my thing. I cannot support this with logging 
however. Where the DownloadAnswer is created eludes me however. I got trapped 
between DownloadManagerImpl and DownloadListener. The creation of the answer 
was as far as I could tell in handleDownloadProgressCmd but again I can not 
support this with logging.
As the reason I suppect eclipse class-file caching but also this theory seems 
to not work.
Anyone's got a good clue for me?

I have burned to much time on this so I will save the patch for if  it is 
locally needed by users, but I still want to find the best solution.
As for John's argument of creating technical debt, I am now convinced that I am 
not adding but only using the present debt that is in there. The 
DownloadAnswer.fixup() method is doing the same on a more obscure place then my 
solution.

Also, if we decide to apply my changes anyway I think we should up the loglevel 
at least as much as acceptable as to keep pointing to the technical debt that 
we have at the moment.

On Tue, Jun 18, 2013 at 5:28 PM, Daan Hoogland 
mailto:daan.hoogl...@gmail.com>> wrote:
On 2013/6/18 16:49 , John Burwell wrote:

Second, please don't take my feedback as passing judgements such as things 
being ugly or
don't worry, I like the discussion and i don't mind losing an argument if the 
best solution arises from it. Let's see about that.
--
[cid:part1.06080303.01090409@gmail.com]

Review Request: FileUtil simplified

2013-06-19 Thread Laszlo Hornyak


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

Review request for cloudstack.


Description
---

- writeToFile removed since no references to it
- readFileAsString replaced with FileUtils.readFileToString
- minor code duplication removed in dependent method getNicStats
- unit test added


Diffs
-

  
plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/LibvirtComputingResource.java
 7d90f6a 
  
plugins/hypervisors/kvm/test/com/cloud/hypervisor/kvm/resource/LibvirtComputingResourceTest.java
 c82c31f 
  utils/src/com/cloud/utils/FileUtil.java 74f4088 

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


Testing
---

test included


Thanks,

Laszlo Hornyak

Re: Review Request: FileUtil simplified

2013-06-19 Thread edison su


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



plugins/hypervisors/kvm/test/com/cloud/hypervisor/kvm/resource/LibvirtComputingResourceTest.java


unit test will fail when compiling the code on Mac/Windows. How about add 
something like: 
http://www.thekua.com/atwork/2008/09/running-tests-on-a-specific-os-under-junit4/


- edison su


On June 19, 2013, 9:03 p.m., Laszlo Hornyak wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/11980/
> ---
> 
> (Updated June 19, 2013, 9:03 p.m.)
> 
> 
> Review request for cloudstack.
> 
> 
> Description
> ---
> 
> - writeToFile removed since no references to it
> - readFileAsString replaced with FileUtils.readFileToString
> - minor code duplication removed in dependent method getNicStats
> - unit test added
> 
> 
> Diffs
> -
> 
>   
> plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/LibvirtComputingResource.java
>  7d90f6a 
>   
> plugins/hypervisors/kvm/test/com/cloud/hypervisor/kvm/resource/LibvirtComputingResourceTest.java
>  c82c31f 
>   utils/src/com/cloud/utils/FileUtil.java 74f4088 
> 
> Diff: https://reviews.apache.org/r/11980/diff/
> 
> 
> Testing
> ---
> 
> test included
> 
> 
> Thanks,
> 
> Laszlo Hornyak
> 
>

Review Request: Adding base support for NVP security groups to the NVP API

2013-06-19 Thread Adrian Steer


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

Review request for cloudstack and Hugo Trippaers.


Description
---

This is initial version of API implementation of security groups within the NVP 
API


Diffs
-

  
plugins/network-elements/nicira-nvp/src/com/cloud/network/nicira/LogicalSwitchPort.java
 c571458 
  
plugins/network-elements/nicira-nvp/src/com/cloud/network/nicira/NiciraAddressPairs.java
 PRE-CREATION 
  
plugins/network-elements/nicira-nvp/src/com/cloud/network/nicira/NiciraLogicalPortRule.java
 PRE-CREATION 
  
plugins/network-elements/nicira-nvp/src/com/cloud/network/nicira/NiciraNvpApi.java
 12fa6c0 
  
plugins/network-elements/nicira-nvp/src/com/cloud/network/nicira/NiciraSecurityProfile.java
 PRE-CREATION 

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


Testing
---

Compile testing


Thanks,

Adrian Steer

RE: instance is not coming on the vmware deployment

2013-06-19 Thread Sateesh Chodapuneedi

Seeing this issue with latest master.

> -Original Message-
> From: Srikanteswararao Talluri [mailto:srikanteswararao.tall...@citrix.com]
> Sent: 14 June 2013 18:55
> To: dev@cloudstack.apache.org
> Subject: instance is not coming on the vmware deployment
> 
> I am encountering the following error while deploying VM . Has anyone 
> observed this issue?
> 
>  (DirectAgent-207:10.147.40.24) Failed to authentication SSH user root on 
> host 10.147.40.168
> 2013-06-14 21:27:01,711 ERROR [vmware.resource.VmwareResource] 
> (DirectAgent-207:10.147.40.24) Unable to execute NetworkUsage
> command on DomR (10.147.40.168), domR may not be ready yet. failure due to 
> Exception: java.lang.Exception
> Message: Failed to authentication SSH user root on host 10.147.40.168
> 
> java.lang.Exception: Failed to authentication SSH user root on host 
> 10.147.40.168 at
> com.cloud.utils.ssh.SshHelper.sshExecute(SshHelper.java:144)
> at com.cloud.utils.ssh.SshHelper.sshExecute(SshHelper.java:37)
> at 
> com.cloud.hypervisor.vmware.resource.VmwareResource.networkUsage(VmwareResource.java:5451)
> at 
> com.cloud.hypervisor.vmware.resource.VmwareResource.execute(VmwareResource.java:2301)
> at 
> com.cloud.hypervisor.vmware.resource.VmwareResource.executeRequest(VmwareResource.java:480)
> at 
> com.cloud.agent.manager.DirectAgentAttache$Task.run(DirectAgentAttache.java:186)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:165)
> at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:266)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:679)
> 2013-06-14 21:27:01,723 DEBUG [cloud.api.ApiServlet] (catalina-exec-25:null) 
> ===START===  10.101.255.119 -- GET
> command=queryAsyncJobResult&jobId=028ed6bf-3155-497b-b680-
> f621e7267fbb&response=json&sessionkey=cA5artzeaAoXYJ8O5MNXTCjAdZU%3D&_=1371205895591
> 
> 
> Thanks,
> ~Talluri

Re: Review Request: CLOUDSTACK-702: Tests for Multiple IP Ranges

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

Commit b3fb4851ee204b1be514e389c66fd6e08d4b7fa4 in branch refs/heads/master 
from Sheng Yang
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=b3fb485 ]

Fix regression of return Userdata provider when caller asked for DHCP

It's introduced by:

commit 052c24c4d1c881f791b804dbb9c2fc083af7da36
Author: Bharat Kumar 
Date:   Mon May 13 17:02:27 2013 +0530

CLOUDSTACK-702: Multiple ip ranges in different subnets.

This commit get userdata provider when caller asked for dhcp provider, thus
result in trouble e.g.

ERROR [cloud.async.AsyncJobManagerImpl] (Job-Executor-11:job-10) Unexpected
exception while executing
org.apache.cloudstack.api.command.user.network.DeleteNetworkCmd
java.lang.ClassCastException:
com.cloud.baremetal.networkservice.BaremetalUserdataElement_EnhancerByCloudStack_5dee69d2
cannot be cast to com.cloud.network.element.DhcpServiceProvider
at
com.cloud.network.NetworkManagerImpl.getDhcpServiceProvider(NetworkManagerImpl.java:3309)
...

- ASF Subversion and Git Services

On May 9, 2013, 1:23 p.m., sanjeev n wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/11026/
> ---
> 
> (Updated May 9, 2013, 1:23 p.m.)
> 
> 
> Review request for cloudstack, Prasanna Santhanam and SrikanteswaraRao 
> Talluri.
> 
> 
> Description
> ---
> 
> CLOUDSTACK-702: Tests for Multiple IP Ranges
> 1. Add ip range super set to existing CIDR
> 2. Add ip range subset to existing CIDR
> 
> 
> This addresses bug CLOUDSTACK-702.
> 
> 
> Diffs
> -
> 
>   test/integration/component/test_multiple_ip_ranges.py 7e9eeb1 
> 
> Diff: https://reviews.apache.org/r/11026/diff/
> 
> 
> Testing
> ---
> 
> yes
> 
> 
> Thanks,
> 
> sanjeev n
> 
>

RE: instance is not coming on the vmware deployment

2013-06-19 Thread Vijayendra Bhamidipati

Hi Sateesh,

This happens because of a stale systemvm.iso existing in the systemvm directory 
on the secondary storage - if you delete it and then rebuild the systemvm.iso, 
and redeploy, the latest systemvm.iso gets copied over to the secondary 
systemvm directory and the problem will go away.

Cheers!
Regards,
Vijay

-Original Message-
From: Sateesh Chodapuneedi [mailto:sateesh.chodapune...@citrix.com] 
Sent: Wednesday, June 19, 2013 4:44 PM
To: dev@cloudstack.apache.org
Subject: RE: instance is not coming on the vmware deployment

Seeing this issue with latest master.

> -Original Message-
> From: Srikanteswararao Talluri 
> [mailto:srikanteswararao.tall...@citrix.com]
> Sent: 14 June 2013 18:55
> To: dev@cloudstack.apache.org
> Subject: instance is not coming on the vmware deployment
> 
> I am encountering the following error while deploying VM . Has anyone 
> observed this issue?
> 
>  (DirectAgent-207:10.147.40.24) Failed to authentication SSH user root 
> on host 10.147.40.168
> 2013-06-14 21:27:01,711 ERROR [vmware.resource.VmwareResource] 
> (DirectAgent-207:10.147.40.24) Unable to execute NetworkUsage command 
> on DomR (10.147.40.168), domR may not be ready yet. failure due to 
> Exception: java.lang.Exception
> Message: Failed to authentication SSH user root on host 10.147.40.168
> 
> java.lang.Exception: Failed to authentication SSH user root on host 
> 10.147.40.168 at
> com.cloud.utils.ssh.SshHelper.sshExecute(SshHelper.java:144)
> at com.cloud.utils.ssh.SshHelper.sshExecute(SshHelper.java:37)
> at 
> com.cloud.hypervisor.vmware.resource.VmwareResource.networkUsage(Vmwar
> eResource.java:5451) at 
> com.cloud.hypervisor.vmware.resource.VmwareResource.execute(VmwareReso
> urce.java:2301) at 
> com.cloud.hypervisor.vmware.resource.VmwareResource.executeRequest(Vmw
> areResource.java:480) at 
> com.cloud.agent.manager.DirectAgentAttache$Task.run(DirectAgentAttache
> .java:186) at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471
> ) at 
> java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.a
> ccess$101(ScheduledThreadPoolExecutor.java:165)
> at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.r
> un(ScheduledThreadPoolExecutor.java:266)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.j
> ava:1110) at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.
> java:603) at java.lang.Thread.run(Thread.java:679)
> 2013-06-14 21:27:01,723 DEBUG [cloud.api.ApiServlet] 
> (catalina-exec-25:null) ===START===  10.101.255.119 -- GET
> command=queryAsyncJobResult&jobId=028ed6bf-3155-497b-b680-
> f621e7267fbb&response=json&sessionkey=cA5artzeaAoXYJ8O5MNXTCjAdZU%3D&_
> =1371205895591
> 
> 
> Thanks,
> ~Talluri

Some commands didn't show up in the marvin test API

Hi,

I just found out that some commands (e.g. AddBaremetalHostCmd,
AddBaremetalKickStartPxeCmd) didn't show in the marvin's
API(tools/marvin/marvin/cloudstackAPI), make it hard for me to write marvin
test case for them.

The baremetal function is disabled for master but these commands are still
there in master, so they should show up for marvin.

Any ideas?

--Sheng

RE: instance is not coming on the vmware deployment

2013-06-19 Thread Sateesh Chodapuneedi

Hi Vijay!

Thanks a lot for the tip. It worked wonderfully.
Yes, Deleteing stale systemvm.iso from secondary storage did it.

Regards,
Sateesh

> -Original Message-
> From: Vijayendra Bhamidipati [mailto:vijayendra.bhamidip...@citrix.com]
> Sent: 20 June 2013 06:14
> To: dev@cloudstack.apache.org
> Subject: RE: instance is not coming on the vmware deployment
> 
> Hi Sateesh,
> 
> This happens because of a stale systemvm.iso existing in the systemvm 
> directory on the secondary storage - if you delete it and then rebuild
> the systemvm.iso, and redeploy, the latest systemvm.iso gets copied over to 
> the secondary systemvm directory and the problem will go
> away.
> 
> Cheers!
> Regards,
> Vijay
> 
> -Original Message-
> From: Sateesh Chodapuneedi [mailto:sateesh.chodapune...@citrix.com]
> Sent: Wednesday, June 19, 2013 4:44 PM
> To: dev@cloudstack.apache.org
> Subject: RE: instance is not coming on the vmware deployment
> 
> Seeing this issue with latest master.
> 
> > -Original Message-
> > From: Srikanteswararao Talluri
> > [mailto:srikanteswararao.tall...@citrix.com]
> > Sent: 14 June 2013 18:55
> > To: dev@cloudstack.apache.org
> > Subject: instance is not coming on the vmware deployment
> >
> > I am encountering the following error while deploying VM . Has anyone 
> > observed this issue?
> >
> >  (DirectAgent-207:10.147.40.24) Failed to authentication SSH user root
> > on host 10.147.40.168
> > 2013-06-14 21:27:01,711 ERROR [vmware.resource.VmwareResource]
> > (DirectAgent-207:10.147.40.24) Unable to execute NetworkUsage command
> > on DomR (10.147.40.168), domR may not be ready yet. failure due to
> > Exception: java.lang.Exception
> > Message: Failed to authentication SSH user root on host 10.147.40.168
> >
> > java.lang.Exception: Failed to authentication SSH user root on host
> > 10.147.40.168 at
> > com.cloud.utils.ssh.SshHelper.sshExecute(SshHelper.java:144)
> > at com.cloud.utils.ssh.SshHelper.sshExecute(SshHelper.java:37)
> > at
> > com.cloud.hypervisor.vmware.resource.VmwareResource.networkUsage(Vmwar
> > eResource.java:5451) at
> > com.cloud.hypervisor.vmware.resource.VmwareResource.execute(VmwareReso
> > urce.java:2301) at
> > com.cloud.hypervisor.vmware.resource.VmwareResource.executeRequest(Vmw
> > areResource.java:480) at
> > com.cloud.agent.manager.DirectAgentAttache$Task.run(DirectAgentAttache
> > .java:186) at
> > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471
> > ) at
> > java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> > at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> > at
> > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.a
> > ccess$101(ScheduledThreadPoolExecutor.java:165)
> > at
> > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.r
> > un(ScheduledThreadPoolExecutor.java:266)
> > at
> > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.j
> > ava:1110) at
> > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.
> > java:603) at java.lang.Thread.run(Thread.java:679)
> > 2013-06-14 21:27:01,723 DEBUG [cloud.api.ApiServlet]
> > (catalina-exec-25:null) ===START===  10.101.255.119 -- GET
> > command=queryAsyncJobResult&jobId=028ed6bf-3155-497b-b680-
> > f621e7267fbb&response=json&sessionkey=cA5artzeaAoXYJ8O5MNXTCjAdZU%3D&_
> > =1371205895591
> >
> >
> > Thanks,
> > ~Talluri

RE: instance is not coming on the vmware deployment

2013-06-19 Thread Vijayendra Bhamidipati

Great! :)

Cheers!
Regards,
Vijay

-Original Message-
From: Sateesh Chodapuneedi [mailto:sateesh.chodapune...@citrix.com] 
Sent: Wednesday, June 19, 2013 6:04 PM
To: dev@cloudstack.apache.org
Subject: RE: instance is not coming on the vmware deployment

Hi Vijay!

Thanks a lot for the tip. It worked wonderfully.
Yes, Deleteing stale systemvm.iso from secondary storage did it.

Regards,
Sateesh

> -Original Message-
> From: Vijayendra Bhamidipati 
> [mailto:vijayendra.bhamidip...@citrix.com]
> Sent: 20 June 2013 06:14
> To: dev@cloudstack.apache.org
> Subject: RE: instance is not coming on the vmware deployment
> 
> Hi Sateesh,
> 
> This happens because of a stale systemvm.iso existing in the systemvm 
> directory on the secondary storage - if you delete it and then rebuild 
> the systemvm.iso, and redeploy, the latest systemvm.iso gets copied over to 
> the secondary systemvm directory and the problem will go away.
> 
> Cheers!
> Regards,
> Vijay
> 
> -Original Message-
> From: Sateesh Chodapuneedi [mailto:sateesh.chodapune...@citrix.com]
> Sent: Wednesday, June 19, 2013 4:44 PM
> To: dev@cloudstack.apache.org
> Subject: RE: instance is not coming on the vmware deployment
> 
> Seeing this issue with latest master.
> 
> > -Original Message-
> > From: Srikanteswararao Talluri
> > [mailto:srikanteswararao.tall...@citrix.com]
> > Sent: 14 June 2013 18:55
> > To: dev@cloudstack.apache.org
> > Subject: instance is not coming on the vmware deployment
> >
> > I am encountering the following error while deploying VM . Has anyone 
> > observed this issue?
> >
> >  (DirectAgent-207:10.147.40.24) Failed to authentication SSH user 
> > root on host 10.147.40.168
> > 2013-06-14 21:27:01,711 ERROR [vmware.resource.VmwareResource]
> > (DirectAgent-207:10.147.40.24) Unable to execute NetworkUsage 
> > command on DomR (10.147.40.168), domR may not be ready yet. failure 
> > due to
> > Exception: java.lang.Exception
> > Message: Failed to authentication SSH user root on host 
> > 10.147.40.168
> >
> > java.lang.Exception: Failed to authentication SSH user root on host
> > 10.147.40.168 at
> > com.cloud.utils.ssh.SshHelper.sshExecute(SshHelper.java:144)
> > at com.cloud.utils.ssh.SshHelper.sshExecute(SshHelper.java:37)
> > at
> > com.cloud.hypervisor.vmware.resource.VmwareResource.networkUsage(Vmw
> > ar
> > eResource.java:5451) at
> > com.cloud.hypervisor.vmware.resource.VmwareResource.execute(VmwareRe
> > so
> > urce.java:2301) at
> > com.cloud.hypervisor.vmware.resource.VmwareResource.executeRequest(V
> > mw
> > areResource.java:480) at
> > com.cloud.agent.manager.DirectAgentAttache$Task.run(DirectAgentAttac
> > he
> > .java:186) at
> > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:4
> > 71
> > ) at
> > java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> > at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> > at
> > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask
> > .a
> > ccess$101(ScheduledThreadPoolExecutor.java:165)
> > at
> > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask
> > .r
> > un(ScheduledThreadPoolExecutor.java:266)
> > at
> > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor
> > .j
> > ava:1110) at
> > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.
> > java:603) at java.lang.Thread.run(Thread.java:679)
> > 2013-06-14 21:27:01,723 DEBUG [cloud.api.ApiServlet]
> > (catalina-exec-25:null) ===START===  10.101.255.119 -- GET
> > command=queryAsyncJobResult&jobId=028ed6bf-3155-497b-b680-
> > f621e7267fbb&response=json&sessionkey=cA5artzeaAoXYJ8O5MNXTCjAdZU%3D
> > &_
> > =1371205895591
> >
> >
> > Thanks,
> > ~Talluri

Re: Hack Day at CloudStack Collaboration Conference

2013-06-19 Thread Gavin Lee

There are so many wonderful sessions; is it open or just for whom brought
ideas?
I really want to join.


On Tue, Jun 18, 2013 at 8:49 PM, David Nalley  wrote:

> On Tue, Jun 18, 2013 at 7:49 AM, John Burwell  wrote:
> > Daan,
> >
> > I think that would make a lot of sense.  My plan is to collect a list
> > of topics from the group and work through them. Does that still make
> > sense?
> >
> > Thanks,
> > -John
> >
>
> So we've had John Willis volunteer to run a Kanban board for us during
> the hackathon - so bring plenty of topics, we'll work through them.
>



-- 
Gavin

Re: Hack Day at CloudStack Collaboration Conference

2013-06-19 Thread David Nalley

It is completely open - come have fun with us.

--David

On Wed, Jun 19, 2013 at 10:02 PM, Gavin Lee  wrote:
> There are so many wonderful sessions; is it open or just for whom brought
> ideas?
> I really want to join.
>
>
> On Tue, Jun 18, 2013 at 8:49 PM, David Nalley  wrote:
>
>> On Tue, Jun 18, 2013 at 7:49 AM, John Burwell  wrote:
>> > Daan,
>> >
>> > I think that would make a lot of sense.  My plan is to collect a list
>> > of topics from the group and work through them. Does that still make
>> > sense?
>> >
>> > Thanks,
>> > -John
>> >
>>
>> So we've had John Willis volunteer to run a Kanban board for us during
>> the hackathon - so bring plenty of topics, we'll work through them.
>>
>
>
>
> --
> Gavin

Re: [DISCUSS] Issue with cloudmonkey-4.1.0-0 on pypi

2013-06-19 Thread David Nalley

On Tue, Jun 18, 2013 at 2:24 PM, Rohit Yadav  wrote:
> On Tue, Jun 18, 2013 at 9:08 PM, David Nalley  wrote:
>
>> On Tue, Jun 18, 2013 at 11:33 AM, Sebastien Goasguen 
>> wrote:
>> >
>> >
>> >
>> > On 18 Jun 2013, at 17:08, David Nalley  wrote:
>> >
>> >> On Mon, Jun 17, 2013 at 7:00 AM, Prasanna Santhanam 
>> wrote:
>> >>> On Sun, Jun 09, 2013 at 10:26:43AM -0400, David Nalley wrote:
>>  On Sun, Jun 9, 2013 at 7:51 AM, Rohit Yadav 
>> wrote:
>> > Hi,
>> >
>> > I was about to test CloudStack but the cloudmonkey-4.1.0-0 release
>> on pypi
>> > does not bundle failsafe api cache so when I install it I don't get
>> any api
>> > commands. The autodiscovery using sync is useful but only with the
>> > ApiDiscovery plugin which works only for 4.2 and later. For 4.1 and
>> below I
>> > think we should, in that case, bundle the cache for all the apis. Or
>> maybe
>> > just oss components/plugins?
>> >
>> > I'll wait for Chip and others to comment if we want to ship it as it
>> is or
>> > bundle the cache against 4.1 release?
>> >
>> > Cheers.
>> 
>>  Honestly - this is exactly why I've been suggesting[1] that we break
>>  CloudMonkey (and Marvin) out of the main repo and giving it it's own
>>  lifecycle. It's far easier/faster to iterate cloudmonkey than all of
>>  CloudStack and tying it to the slower lifecycle of ACS will continue
>>  to trouble it IMO.
>> 
>>  --David
>> 
>>  [1] http://markmail.org/message/wir5vfawex3y22ot
>> >>>
>> >>> I haven't given breaking out the project much thought. But it's
>> >>> certainly a possibility:
>> >>>
>> >>> a) However, there are parts of the codebase (checkin tests) that depend
>> >>> on marvin.
>> >>>
>> >>> b) I need to come up with a easier way to update marvin across
>> >>> cloudstack providers to enable auto-upating marvin's libraries like
>> >>> cloudmonkey can. For this I've made a couple enhancements to
>> >>> apidiscovery but it's not in master yet and I don't have it fully
>> >>> figured out.
>> >>>
>> >>> Need some time to think through this.
>> >>>
>> >>> --
>> >>> Prasanna.,
>> >>>
>> >>> 
>> >>> Powered by BigRock.com
>> >>>
>> >>
>> >>
>> >> OK - are your concerns CM-related? or Marvin only?
>> >>
>> >> Any problems I am not seeing with breaking out CloudMonkey?
>> >>
>> >> Anyone else have concerns here about breaking out CloudMonkey?
>> >>
>> >> --David
>> >
>> > Could we talk about it during the hack day and report to the list ? I
>> for one dont understand how these break out repos would work ...process
>> wise, release wise, ml wise etc ?
>>
>>
>> Seems like it's something that we def. need to discuss on list.
>>
>> Here is my thinking:
>>
>> I'd move everything under tools/cli in master to a separate repo - I'd
>> abandon history (unless someone objects and volunteers to extract all
>> of that history)
>>
>> Releases - they'd be separate, with separate versioning. We'd still
>> vote on CM releases, but likely at a much faster rate than current
>> mainline ACS releases.
>>
>>
> Hey David, let's do that. Separate versioning makes sense as cloudmonkey no
> longer really depends on CloudStack or marvin with its api discovery,
> though we can keep a failsafe precache or have instructions on how to build
> one using one's synced cache (which is in ~/.cloudmonkey/cache).
>
> I've separated out cloudmonkey in a separate git repo retaining its history
> using my git-fu; https://github.com/bhaisaab/cloudmonkey
>
> It's same as latest master plus some commit on adding the license file from
> CloudStack's root directory, a README.md file, a Makefile and a .gitignore
> file.
>
> Cheers.
>


AWESOME - thanks for the work on this.
I'll stand up a RO git repo clone in the next day or so for review.

--David

Review Request: Fix primary datastore NPE/incorrect db entry/exception propagation for KVM on cloudstack

2013-06-19 Thread Venkata Siva Vijayendra Bhamidipati


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

Review request for cloudstack, Chip Childers, edison su, and Min Chen.


Description
---

Patch for fixes for issues detected while working on bug CLOUDSTACK-1510 
(https://issues.apache.org/jira/browse/CLOUDSTACK-1510).


This addresses bug CLOUDSTACK-1510.


Diffs
-

  
api/src/org/apache/cloudstack/api/command/admin/storage/CreateStoragePoolCmd.java
 74eb2b9 
  
engine/api/src/org/apache/cloudstack/engine/subsystem/api/storage/DataStoreLifeCycle.java
 cb46709 
  
plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/storage/LibvirtStorageAdaptor.java
 89e22c8 
  
plugins/storage/volume/default/src/org/apache/cloudstack/storage/datastore/lifecycle/CloudStackPrimaryDataStoreLifeCycleImpl.java
 fb37e8f 
  server/src/com/cloud/storage/StorageManagerImpl.java 20b435c 

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


Testing
---

Deploy KVM cluster in cloudstack. Attempt to add a primary NFS datastore using 
an invalid path. NPE is not encountered anymore. If KVM host is down or the 
cloud-agent on the KVM host is down, the primary datastore (whether valid or 
otherwise) is not logged to the db's storage_pool table. So invalid datastores 
do not show up in the GUI when listing the primary datastores available. Also, 
exception is propagated to GUI.


Thanks,

Venkata Siva Vijayendra Bhamidipati

CHAP problem in cloudstack

2013-06-19 Thread MatriX Phuong

Hi everyone,
when i add iscsi primary storage with chap enabled,i don't see anywhere in
the GUI to provide it.
I wonder that does cloudstack have already supported in new version 4.1 or
in the other release?

Thanks and best regards.

PCI-Passthrough with CloudStack (Improved)

2013-06-19 Thread Pawit Pornkitprasan

Hi,

Following my previous post about implementing PCI Passthrough on
CloudStack (KVM), I have taken Edison Su’s and others’ comments into
account and came up with an improved design.

Because the devices available at each agent may be different, the
available devices for passthrough are now configured at the agent
configuration file (/etc/cloudstack/agent/agent.properties).
Configuration is a comma separated list of available PCI devices and
its given name.

pci.devices=28:00.1|10GE,28:00.2|10GE,28:00.3|10GE,28:00.4|10GE,28:00.5|10GE,28:00.6|10GE,28:00.7|10GE,28:01.0|10GE

At agent startup, the list of PCI devices is parsed and sent together
with StartupRoutingCommand (in a new field, not in details). The
management server then stores it in a new table “op_host_pci_devices”.
If a device is added, removed, or renamed, the table is updated
accordingly. The current schema has the following fields

id (auto-increment)
host_id (host that this device belongs to)
name (given name of the PCI device)
domain (PCI ID - domain)
bus (PCI ID - bus)
slot (PCI ID - slot)
function (PCI ID - function)
instance_id (ID of the VM using the PCI device, NULL if not in use)

The “name” of the PCI device is what is used to assign a device. In a
compute offering, the user can specify the name of one or more PCI
devices (as a comma-separated list) and CloudStack will find a host
with the PCI device of the specified name available and assign it.

A new manager, PciDeviceManager, is then created to handle the
allocation of PCI device. The manager implements StateListener and
assigns PCI devices on state change to “starting” and also release the
devices VM stop. First fit allocator and first fit planner are also
modified to check for PCI device availability accordingly.

For migration, there are 2 approaches. The first approach is to forbid
migration and is straightforward. The second approach is to PCI
Hotplug to detach the device, migrate and attach it again at the other
end. This will interrupt whatever is using the device on the VM.
However, it may be desirable for networking devices where the VM can
use a bonding device to channel network traffic through a standard
virtualized network device while the PCI Passthrough device is down.

The design mentioned here (including detach-attach migration) has been
implemented in code and is working. Again, comments and suggestions
are welcomed.

Best Regards,
Pawit

Re: PCI-Passthrough with CloudStack (Improved)

2013-06-19 Thread Pawit Pornkitprasan

Hi,

I've forgot to describe the detach-attach mechanism, so I'll describe
it in this reply.

PCI Device detach is done automatically by the agent when a
MigrateCommand is processed. In KVM case, the server gets a list of
attached PCI devices from libvirt's XML and detach very device. If
detach is not successful (i.e. the guest does not have the acpiphp
module loaded), libvirt will error out and the migration will be
canceled.

For re-attachment: Before the migration start, a PCI Device on the new
host is assigned by PciDeviceManager and the one on the old host is
freed (also on state change event). After the migration is successful,
PciDeviceManager sends AttachPciDevicesCommand to the new agent with a
list of the PCI IDs on the new host and the agent orders libvirt to
attach it based on the command.

Best Regards,
Pawit

On Thu, Jun 20, 2013 at 1:12 PM, Pawit Pornkitprasan  wrote:
> Hi,
>
> Following my previous post about implementing PCI Passthrough on
> CloudStack (KVM), I have taken Edison Su’s and others’ comments into
> account and came up with an improved design.
>
> Because the devices available at each agent may be different, the
> available devices for passthrough are now configured at the agent
> configuration file (/etc/cloudstack/agent/agent.properties).
> Configuration is a comma separated list of available PCI devices and
> its given name.
>
> pci.devices=28:00.1|10GE,28:00.2|10GE,28:00.3|10GE,28:00.4|10GE,28:00.5|10GE,28:00.6|10GE,28:00.7|10GE,28:01.0|10GE
>
> At agent startup, the list of PCI devices is parsed and sent together
> with StartupRoutingCommand (in a new field, not in details). The
> management server then stores it in a new table “op_host_pci_devices”.
> If a device is added, removed, or renamed, the table is updated
> accordingly. The current schema has the following fields
>
> id (auto-increment)
> host_id (host that this device belongs to)
> name (given name of the PCI device)
> domain (PCI ID - domain)
> bus (PCI ID - bus)
> slot (PCI ID - slot)
> function (PCI ID - function)
> instance_id (ID of the VM using the PCI device, NULL if not in use)
>
> The “name” of the PCI device is what is used to assign a device. In a
> compute offering, the user can specify the name of one or more PCI
> devices (as a comma-separated list) and CloudStack will find a host
> with the PCI device of the specified name available and assign it.
>
> A new manager, PciDeviceManager, is then created to handle the
> allocation of PCI device. The manager implements StateListener and
> assigns PCI devices on state change to “starting” and also release the
> devices VM stop. First fit allocator and first fit planner are also
> modified to check for PCI device availability accordingly.
>
> For migration, there are 2 approaches. The first approach is to forbid
> migration and is straightforward. The second approach is to PCI
> Hotplug to detach the device, migrate and attach it again at the other
> end. This will interrupt whatever is using the device on the VM.
> However, it may be desirable for networking devices where the VM can
> use a bonding device to channel network traffic through a standard
> virtualized network device while the PCI Passthrough device is down.
>
> The design mentioned here (including detach-attach migration) has been
> implemented in code and is working. Again, comments and suggestions
> are welcomed.
>
> Best Regards,
> Pawit

Re: Review Request: Fix for CLOUDSTACK-2987 Ensure XStools to be there in template inorder to enable dynamic scaling of vm


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

Ship it!


Ship It!

- Abhinandan Prateek


On June 19, 2013, 11 a.m., Harikrishna Patnala wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/11910/
> ---
> 
> (Updated June 19, 2013, 11 a.m.)
> 
> 
> Review request for cloudstack, Abhinandan Prateek and Nitin Mehta.
> 
> 
> Description
> ---
> 
> CLOUDSTACK-2987 Ensure XStools to be there in template inorder to enable 
> dynamic scaling of vm 
> 
> CLOUDSTACK-3042 - handle Scaling up of vm memory/CPU based on the presence of 
> XS tools in the template
> This should also take care of updation of VM after XS tools are installed in 
> the vm and set memory values accordingly to support dynamic scaling after 
> stop start of VM
> 
> 
> This addresses bugs CLOUDSTACK-2987 and CLOUDSTACK-3042.
> 
> 
> Diffs
> -
> 
>   api/src/com/cloud/template/VirtualMachineTemplate.java cedc793 
>   api/src/com/cloud/vm/VirtualMachine.java ce9add6 
>   api/src/org/apache/cloudstack/api/ApiConstants.java ab1402c 
>   api/src/org/apache/cloudstack/api/BaseUpdateTemplateOrIsoCmd.java 6fd9773 
>   api/src/org/apache/cloudstack/api/command/user/iso/RegisterIsoCmd.java 
> 284d553 
>   
> api/src/org/apache/cloudstack/api/command/user/template/RegisterTemplateCmd.java
>  c9da0c2 
>   api/src/org/apache/cloudstack/api/command/user/vm/UpdateVMCmd.java 2860283 
>   api/src/org/apache/cloudstack/api/response/TemplateResponse.java 896154a 
>   api/src/org/apache/cloudstack/api/response/UserVmResponse.java 1f9eb1a 
>   core/src/com/cloud/agent/api/ScaleVmCommand.java b361485 
>   engine/schema/src/com/cloud/storage/VMTemplateVO.java e643d75 
>   engine/schema/src/com/cloud/vm/VMInstanceVO.java fbe03dc 
>   
> engine/storage/src/org/apache/cloudstack/storage/image/TemplateEntityImpl.java
>  4d162bb 
>   plugins/hypervisors/xen/src/com/cloud/hypervisor/XenServerGuru.java 8c38a69 
>   
> plugins/hypervisors/xen/src/com/cloud/hypervisor/xen/resource/CitrixResourceBase.java
>  5e8283a 
>   
> plugins/hypervisors/xen/src/com/cloud/hypervisor/xen/resource/XenServer56FP1Resource.java
>  8e37809 
>   server/src/com/cloud/api/ApiResponseHelper.java 94c5d6c 
>   server/src/com/cloud/api/query/dao/UserVmJoinDaoImpl.java dbfe94d 
>   server/src/com/cloud/api/query/vo/UserVmJoinVO.java 8ad0fdd 
>   server/src/com/cloud/hypervisor/HypervisorGuruBase.java 1ad9a1f 
>   server/src/com/cloud/server/ManagementServerImpl.java 96c72e4 
>   server/src/com/cloud/storage/TemplateProfile.java 0b55f1f 
>   server/src/com/cloud/template/TemplateAdapter.java 9a2d877 
>   server/src/com/cloud/template/TemplateAdapterBase.java 0940d3e 
>   server/src/com/cloud/vm/UserVmManagerImpl.java 1c8ab75 
>   server/src/com/cloud/vm/VirtualMachineManagerImpl.java f946cd1 
>   server/test/com/cloud/vm/VirtualMachineManagerImplTest.java 8715c9e 
>   setup/db/db/schema-410to420.sql 272fc42 
> 
> Diff: https://reviews.apache.org/r/11910/diff/
> 
> 
> Testing
> ---
> 
> Tested locally
> 
> 
> Thanks,
> 
> Harikrishna Patnala
> 
>

Re: CHAP problem in cloudstack

Hi,

At present (4.1 and earlier), CHAP is not supported when creating Primary
Storage.

If you want to use CHAP (as I often do), you must set it up from the
hypervisor side.

For example, if you're using XenServer, create a storage repository based
on your iSCSI target and use CHAP.

Then, go into CloudStack and select PreSetup for the protocol of the
Primary Storage.

If you're using VMware, select vmfs as the protocol and point to the iSCSI
datastore you created and set up with CHAP.

Does that make sense?

On Wed, Jun 19, 2013 at 9:45 PM, MatriX Phuong  wrote:

> Hi everyone,
> when i add iscsi primary storage with chap enabled,i don't see anywhere in
> the GUI to provide it.
> I wonder that does cloudstack have already supported in new version 4.1 or
> in the other release?
>
> Thanks and best regards.
>

-- 
*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: CHAP problem in cloudstack

I discuss Primary Storage in CloudStack in this video, if you're interested:

http://www.youtube.com/watch?v=Mg2nTWejiwM

Also, I wrote this document up that might be of use to you:

http://buildacloud.org/blog/260-cloudstack-storage-configuration-guide.html


On Wed, Jun 19, 2013 at 10:43 PM, Mike Tutkowski <
mike.tutkow...@solidfire.com> wrote:

> Hi,
>
> At present (4.1 and earlier), CHAP is not supported when creating Primary
> Storage.
>
> If you want to use CHAP (as I often do), you must set it up from the
> hypervisor side.
>
> For example, if you're using XenServer, create a storage repository based
> on your iSCSI target and use CHAP.
>
> Then, go into CloudStack and select PreSetup for the protocol of the
> Primary Storage.
>
> If you're using VMware, select vmfs as the protocol and point to the iSCSI
> datastore you created and set up with CHAP.
>
> Does that make sense?
>
>
> On Wed, Jun 19, 2013 at 9:45 PM, MatriX Phuong wrote:
>
>> Hi everyone,
>> when i add iscsi primary storage with chap enabled,i don't see anywhere in
>> the GUI to provide it.
>> I wonder that does cloudstack have already supported in new version 4.1 or
>> in the other release?
>>
>> Thanks and best regards.
>>
>
>
>
> --
> *Mike Tutkowski*
> *Senior CloudStack Developer, SolidFire Inc.*
> e: mike.tutkow...@solidfire.com
> o: 303.746.7302
> Advancing the way the world uses the 
> cloud
> *™*
>



-- 
*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: Egress firewall rules default policy configuration using network offering

2013-06-19 Thread Jayapal Reddy


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

Review request for cloudstack, Anthony Urso, Abhinandan Prateek, Murali Reddy, 
and Alena Prokharchyk.


Description
---

Egress rules default policy configuration using the network offering.
This patch is for xenserver with VR as firewall provider.

Here is the FS:
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Egress+firewall+rules+-+Ability+to+change+the+default

The work flow:
1. For default network offerings the egress default policy is block
2. While creating network offering, by default egress default policy is allow 
and it can be configured to deny.
3. When egress default policy is allow, rules are added to block the traffic 
and if default policy is deny rules added to allow the traffic


This addresses bug CLOUDSTACK-1578.


Diffs
-

  api/src/com/cloud/agent/api/to/FirewallRuleTO.java f296aa4 
  api/src/com/cloud/offering/NetworkOffering.java 72e2a2b 
  api/src/org/apache/cloudstack/api/ApiConstants.java ab1402c 
  
api/src/org/apache/cloudstack/api/command/admin/network/CreateNetworkOfferingCmd.java
 6410715 
  api/src/org/apache/cloudstack/api/response/NetworkOfferingResponse.java 
7a7e371 
  core/src/com/cloud/agent/api/routing/NetworkElementCommand.java ddb7ac8 
  engine/schema/src/com/cloud/network/rules/FirewallRuleVO.java 9f73029 
  engine/schema/src/com/cloud/offerings/NetworkOfferingVO.java 3ae0bf3 
  patches/systemvm/debian/config/root/firewallRule_egress.sh 0da7718 
  
plugins/hypervisors/xen/src/com/cloud/hypervisor/xen/resource/CitrixResourceBase.java
 5e8283a 
  server/src/com/cloud/api/ApiResponseHelper.java 94c5d6c 
  server/src/com/cloud/configuration/ConfigurationManager.java 8db037b 
  server/src/com/cloud/configuration/ConfigurationManagerImpl.java 131d340 
  server/src/com/cloud/network/NetworkManagerImpl.java d6a6450 
  server/src/com/cloud/network/firewall/FirewallManagerImpl.java f7275b0 
  server/src/com/cloud/network/router/VirtualNetworkApplianceManagerImpl.java 
8da5176 
  server/src/com/cloud/network/rules/FirewallManager.java 2bce8fe 
  server/src/com/cloud/server/ConfigurationServerImpl.java d334d7e 
  server/test/com/cloud/network/MockFirewallManagerImpl.java 95bb1d1 
  server/test/com/cloud/vpc/MockConfigurationManagerImpl.java 21b3590 
  
server/test/org/apache/cloudstack/networkoffering/CreateNetworkOfferingTest.java
 4a2c867 
  setup/db/db/schema-410to420.sql bcfbcc9 

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


Testing
---

1. Tested on xenserver with VR as firewall


Thanks,

Jayapal Reddy

Re: Review Request: Cloudstack-2938 [Multiple_IP_Ranges] Password Service does not work in case of multiple subnets in a vlan


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

Ship it!


Ship It!

- Abhinandan Prateek


On June 19, 2013, 7 a.m., bharat kumar wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/11960/
> ---
> 
> (Updated June 19, 2013, 7 a.m.)
> 
> 
> Review request for cloudstack and Abhinandan Prateek.
> 
> 
> Description
> ---
> 
> Cloudstack-2938 [Multiple_IP_Ranges] Password Service does not work in case 
> of multiple subnets in a vlan
> https://issues.apache.org/jira/browse/CLOUDSTACK-2938
> 
> 
> This addresses bug Cloudstack-2938.
> 
> 
> Diffs
> -
> 
>   patches/systemvm/debian/config/root/createIpAlias.sh 2c79813 
> 
> Diff: https://reviews.apache.org/r/11960/diff/
> 
> 
> Testing
> ---
> 
> Tested on master.
> 
> 
> Thanks,
> 
> bharat kumar
> 
>

Re: Review Request: Fix for CLOUDSTACK-2987 Ensure XStools to be there in template inorder to enable dynamic scaling of vm

2013-06-19 Thread Harikrishna Patnala


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

(Updated June 20, 2013, 5:19 a.m.)


Review request for cloudstack, Abhinandan Prateek and Nitin Mehta.


Changes
---

Updated patch after resolving merge conflicts


Description
---

CLOUDSTACK-2987 Ensure XStools to be there in template inorder to enable 
dynamic scaling of vm 

CLOUDSTACK-3042 - handle Scaling up of vm memory/CPU based on the presence of 
XS tools in the template
This should also take care of updation of VM after XS tools are installed in 
the vm and set memory values accordingly to support dynamic scaling after stop 
start of VM


This addresses bugs CLOUDSTACK-2987 and CLOUDSTACK-3042.


Diffs (updated)
-

  api/src/com/cloud/template/VirtualMachineTemplate.java cedc793 
  api/src/com/cloud/vm/VirtualMachine.java ce9add6 
  api/src/org/apache/cloudstack/api/ApiConstants.java 12e5097 
  api/src/org/apache/cloudstack/api/BaseUpdateTemplateOrIsoCmd.java 6fd9773 
  api/src/org/apache/cloudstack/api/command/user/iso/RegisterIsoCmd.java 
284d553 
  
api/src/org/apache/cloudstack/api/command/user/template/RegisterTemplateCmd.java
 c9da0c2 
  api/src/org/apache/cloudstack/api/command/user/vm/UpdateVMCmd.java 2860283 
  api/src/org/apache/cloudstack/api/response/TemplateResponse.java ed933ff 
  api/src/org/apache/cloudstack/api/response/UserVmResponse.java 5b71ba2 
  core/src/com/cloud/agent/api/ScaleVmCommand.java b361485 
  engine/schema/src/com/cloud/storage/VMTemplateVO.java e643d75 
  engine/schema/src/com/cloud/vm/VMInstanceVO.java fbe03dc 
  
engine/storage/src/org/apache/cloudstack/storage/image/TemplateEntityImpl.java 
4d162bb 
  plugins/hypervisors/xen/src/com/cloud/hypervisor/XenServerGuru.java 8c38a69 
  
plugins/hypervisors/xen/src/com/cloud/hypervisor/xen/resource/CitrixResourceBase.java
 5e8283a 
  
plugins/hypervisors/xen/src/com/cloud/hypervisor/xen/resource/XenServer56FP1Resource.java
 8e37809 
  server/src/com/cloud/api/ApiResponseHelper.java 7ffa30f 
  server/src/com/cloud/api/query/dao/UserVmJoinDaoImpl.java f9877ab 
  server/src/com/cloud/api/query/vo/UserVmJoinVO.java c97d71a 
  server/src/com/cloud/hypervisor/HypervisorGuruBase.java 1ad9a1f 
  server/src/com/cloud/server/ManagementServerImpl.java cfc8333 
  server/src/com/cloud/storage/TemplateProfile.java 0b55f1f 
  server/src/com/cloud/template/TemplateAdapter.java 9a2d877 
  server/src/com/cloud/template/TemplateAdapterBase.java 0940d3e 
  server/src/com/cloud/vm/UserVmManagerImpl.java e8ea024 
  server/src/com/cloud/vm/VirtualMachineManagerImpl.java 5814075 
  server/test/com/cloud/vm/VirtualMachineManagerImplTest.java 8715c9e 
  setup/db/db/schema-410to420.sql c782234 

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


Testing
---

Tested locally


Thanks,

Harikrishna Patnala

Re: Review Request: Fix for CLOUDSTACK-2987 Ensure XStools to be there in template inorder to enable dynamic scaling of vm



> On June 20, 2013, 4:42 a.m., Abhinandan Prateek wrote:
> > Ship It!

Patch fails:


Applying: CLOUDSTACK-2987 Ensure XStools to be there in template inorder to 
enable dynamic scaling of vm
error: patch failed: setup/db/db/schema-410to420.sql:1857
error: setup/db/db/schema-410to420.sql: patch does not apply
Patch failed at 0001 CLOUDSTACK-2987 Ensure XStools to be there in template 
inorder to enable dynamic scaling of vm


- Abhinandan


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


On June 20, 2013, 5:19 a.m., Harikrishna Patnala wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/11910/
> ---
> 
> (Updated June 20, 2013, 5:19 a.m.)
> 
> 
> Review request for cloudstack, Abhinandan Prateek and Nitin Mehta.
> 
> 
> Description
> ---
> 
> CLOUDSTACK-2987 Ensure XStools to be there in template inorder to enable 
> dynamic scaling of vm 
> 
> CLOUDSTACK-3042 - handle Scaling up of vm memory/CPU based on the presence of 
> XS tools in the template
> This should also take care of updation of VM after XS tools are installed in 
> the vm and set memory values accordingly to support dynamic scaling after 
> stop start of VM
> 
> 
> This addresses bugs CLOUDSTACK-2987 and CLOUDSTACK-3042.
> 
> 
> Diffs
> -
> 
>   api/src/com/cloud/template/VirtualMachineTemplate.java cedc793 
>   api/src/com/cloud/vm/VirtualMachine.java ce9add6 
>   api/src/org/apache/cloudstack/api/ApiConstants.java 12e5097 
>   api/src/org/apache/cloudstack/api/BaseUpdateTemplateOrIsoCmd.java 6fd9773 
>   api/src/org/apache/cloudstack/api/command/user/iso/RegisterIsoCmd.java 
> 284d553 
>   
> api/src/org/apache/cloudstack/api/command/user/template/RegisterTemplateCmd.java
>  c9da0c2 
>   api/src/org/apache/cloudstack/api/command/user/vm/UpdateVMCmd.java 2860283 
>   api/src/org/apache/cloudstack/api/response/TemplateResponse.java ed933ff 
>   api/src/org/apache/cloudstack/api/response/UserVmResponse.java 5b71ba2 
>   core/src/com/cloud/agent/api/ScaleVmCommand.java b361485 
>   engine/schema/src/com/cloud/storage/VMTemplateVO.java e643d75 
>   engine/schema/src/com/cloud/vm/VMInstanceVO.java fbe03dc 
>   
> engine/storage/src/org/apache/cloudstack/storage/image/TemplateEntityImpl.java
>  4d162bb 
>   plugins/hypervisors/xen/src/com/cloud/hypervisor/XenServerGuru.java 8c38a69 
>   
> plugins/hypervisors/xen/src/com/cloud/hypervisor/xen/resource/CitrixResourceBase.java
>  5e8283a 
>   
> plugins/hypervisors/xen/src/com/cloud/hypervisor/xen/resource/XenServer56FP1Resource.java
>  8e37809 
>   server/src/com/cloud/api/ApiResponseHelper.java 7ffa30f 
>   server/src/com/cloud/api/query/dao/UserVmJoinDaoImpl.java f9877ab 
>   server/src/com/cloud/api/query/vo/UserVmJoinVO.java c97d71a 
>   server/src/com/cloud/hypervisor/HypervisorGuruBase.java 1ad9a1f 
>   server/src/com/cloud/server/ManagementServerImpl.java cfc8333 
>   server/src/com/cloud/storage/TemplateProfile.java 0b55f1f 
>   server/src/com/cloud/template/TemplateAdapter.java 9a2d877 
>   server/src/com/cloud/template/TemplateAdapterBase.java 0940d3e 
>   server/src/com/cloud/vm/UserVmManagerImpl.java e8ea024 
>   server/src/com/cloud/vm/VirtualMachineManagerImpl.java 5814075 
>   server/test/com/cloud/vm/VirtualMachineManagerImplTest.java 8715c9e 
>   setup/db/db/schema-410to420.sql c782234 
> 
> Diff: https://reviews.apache.org/r/11910/diff/
> 
> 
> Testing
> ---
> 
> Tested locally
> 
> 
> Thanks,
> 
> Harikrishna Patnala
> 
>

Re: Review Request: CLOUDSTACK-2167: The Vlan ranges displayed are not in ascending order.

2013-06-19 Thread Likitha Shetty


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

Ship it!


Ship It!

- Likitha Shetty


On June 19, 2013, 11:37 a.m., Saksham Srivastava wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/11708/
> ---
> 
> (Updated June 19, 2013, 11:37 a.m.)
> 
> 
> Review request for cloudstack and Devdeep Singh.
> 
> 
> Description
> ---
> 
> When multiple vlan ranges are added to a physical networks the vlan ranges 
> displayed in the output of the listPhysicalNetworks api displays the vlan 
> range in the order the ranges were added,Instead if they are displayed in the 
> ascending order range this would make it easy for the end user.
> 
> 
> This addresses bug CLOUDSTACK-2167.
> 
> 
> Diffs
> -
> 
>   server/src/com/cloud/api/ApiResponseHelper.java 7ffa30f 
> 
> Diff: https://reviews.apache.org/r/11708/diff/
> 
> 
> Testing
> ---
> 
> The response of list api is now enhanced:
> 
> 1
> 
> 49e5cdfc-2c14-415a-9dd3-38ac2fdeef54
> Physical Network 1
> ZONE
> 0bd17058-2931-479b-98b5-29c8c91c24d3
> Enabled
> 480-504;910-914;916-918;920-923;925-934;936-940
> VLAN
> 
> 
> Build passes successfully.
> 
> 
> Thanks,
> 
> Saksham Srivastava
> 
>

Re: Review Request: CLOUDSTACK-2167: The Vlan ranges displayed are not in ascending order.


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


Commit e420c3be8c597da6abf8915a99b0e3f860fda034 in branch refs/heads/master 
from Saksham Srivastava
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=e420c3b ]

CLOUDSTACK-2167: The Vlan ranges displayed are not in ascending order


- ASF Subversion and Git Services


On June 19, 2013, 11:37 a.m., Saksham Srivastava wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/11708/
> ---
> 
> (Updated June 19, 2013, 11:37 a.m.)
> 
> 
> Review request for cloudstack and Devdeep Singh.
> 
> 
> Description
> ---
> 
> When multiple vlan ranges are added to a physical networks the vlan ranges 
> displayed in the output of the listPhysicalNetworks api displays the vlan 
> range in the order the ranges were added,Instead if they are displayed in the 
> ascending order range this would make it easy for the end user.
> 
> 
> This addresses bug CLOUDSTACK-2167.
> 
> 
> Diffs
> -
> 
>   server/src/com/cloud/api/ApiResponseHelper.java 7ffa30f 
> 
> Diff: https://reviews.apache.org/r/11708/diff/
> 
> 
> Testing
> ---
> 
> The response of list api is now enhanced:
> 
> 1
> 
> 49e5cdfc-2c14-415a-9dd3-38ac2fdeef54
> Physical Network 1
> ZONE
> 0bd17058-2931-479b-98b5-29c8c91c24d3
> Enabled
> 480-504;910-914;916-918;920-923;925-934;936-940
> VLAN
> 
> 
> Build passes successfully.
> 
> 
> Thanks,
> 
> Saksham Srivastava
> 
>

Re: Review Request: CLOUDSTACK-2167: The Vlan ranges displayed are not in ascending order.


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


Commit fd77b60c5d3a3a5029d40583d4fc391e0cb41253 in branch 
refs/heads/master-6-17-stable from Saksham Srivastava
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=fd77b60 ]

CLOUDSTACK-2167: The Vlan ranges displayed are not in ascending order


- ASF Subversion and Git Services


On June 19, 2013, 11:37 a.m., Saksham Srivastava wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/11708/
> ---
> 
> (Updated June 19, 2013, 11:37 a.m.)
> 
> 
> Review request for cloudstack and Devdeep Singh.
> 
> 
> Description
> ---
> 
> When multiple vlan ranges are added to a physical networks the vlan ranges 
> displayed in the output of the listPhysicalNetworks api displays the vlan 
> range in the order the ranges were added,Instead if they are displayed in the 
> ascending order range this would make it easy for the end user.
> 
> 
> This addresses bug CLOUDSTACK-2167.
> 
> 
> Diffs
> -
> 
>   server/src/com/cloud/api/ApiResponseHelper.java 7ffa30f 
> 
> Diff: https://reviews.apache.org/r/11708/diff/
> 
> 
> Testing
> ---
> 
> The response of list api is now enhanced:
> 
> 1
> 
> 49e5cdfc-2c14-415a-9dd3-38ac2fdeef54
> Physical Network 1
> ZONE
> 0bd17058-2931-479b-98b5-29c8c91c24d3
> Enabled
> 480-504;910-914;916-918;920-923;925-934;936-940
> VLAN
> 
> 
> Build passes successfully.
> 
> 
> Thanks,
> 
> Saksham Srivastava
> 
>

Re: Review Request: Cloudstack-2644 [Multiple_IP_Ranges] user data service on VR does not work in case of multiple subnets Cloudstack-2953 [Multiple_IP_Ranges] VM does not get the public key from VR i

2013-06-19 Thread bharat kumar


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

(Updated June 20, 2013, 5:37 a.m.)


Review request for cloudstack and Abhinandan Prateek.


Description
---

Cloudstack-2644 [Multiple_IP_Ranges] user data service on VR does not work in 
case of multiple subnets 
https://issues.apache.org/jira/browse/CLOUDSTACK-2644

Cloudstack-2953 [Multiple_IP_Ranges] VM does not get the public key from VR 
incase of multiple subnets per vlan Also removed some
 unused code.
https://issues.apache.org/jira/browse/CLOUDSTACK-2953


This addresses bugs Cloudstack-2644 and Cloudstack-2953.


Diffs (updated)
-

  patches/systemvm/debian/config/etc/init.d/cloud-early-config 0dcd571 
  server/src/com/cloud/network/router/VirtualNetworkApplianceManagerImpl.java 
8edd5bd 
  server/src/com/cloud/vm/dao/NicIpAliasDao.java f1e4b8e 
  server/src/com/cloud/vm/dao/NicIpAliasDaoImpl.java e6c52a2 
  setup/bindir/cloud-set-guest-sshkey.in f3f02b1 

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


Testing
---

tested on master.


Thanks,

bharat kumar

Re: Review Request: Fix for CLOUDSTACK-2987 Ensure XStools to be there in template inorder to enable dynamic scaling of vm


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


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

CLOUDSTACK-2987 Ensure XStools to be there in template inorder to enable 
dynamic scaling of vm

CLOUDSTACK-3042 - handle Scaling up of vm memory/CPU based on the presence of 
XS tools in the template
This also takes care of updation of VM after XS tools are installed in the vm 
and set memory values accordingly to support dynamic scaling after stop start 
of VM

Signed-off-by: Abhinandan Prateek 


- ASF Subversion and Git Services


On June 20, 2013, 5:19 a.m., Harikrishna Patnala wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/11910/
> ---
> 
> (Updated June 20, 2013, 5:19 a.m.)
> 
> 
> Review request for cloudstack, Abhinandan Prateek and Nitin Mehta.
> 
> 
> Description
> ---
> 
> CLOUDSTACK-2987 Ensure XStools to be there in template inorder to enable 
> dynamic scaling of vm 
> 
> CLOUDSTACK-3042 - handle Scaling up of vm memory/CPU based on the presence of 
> XS tools in the template
> This should also take care of updation of VM after XS tools are installed in 
> the vm and set memory values accordingly to support dynamic scaling after 
> stop start of VM
> 
> 
> This addresses bugs CLOUDSTACK-2987 and CLOUDSTACK-3042.
> 
> 
> Diffs
> -
> 
>   api/src/com/cloud/template/VirtualMachineTemplate.java cedc793 
>   api/src/com/cloud/vm/VirtualMachine.java ce9add6 
>   api/src/org/apache/cloudstack/api/ApiConstants.java 12e5097 
>   api/src/org/apache/cloudstack/api/BaseUpdateTemplateOrIsoCmd.java 6fd9773 
>   api/src/org/apache/cloudstack/api/command/user/iso/RegisterIsoCmd.java 
> 284d553 
>   
> api/src/org/apache/cloudstack/api/command/user/template/RegisterTemplateCmd.java
>  c9da0c2 
>   api/src/org/apache/cloudstack/api/command/user/vm/UpdateVMCmd.java 2860283 
>   api/src/org/apache/cloudstack/api/response/TemplateResponse.java ed933ff 
>   api/src/org/apache/cloudstack/api/response/UserVmResponse.java 5b71ba2 
>   core/src/com/cloud/agent/api/ScaleVmCommand.java b361485 
>   engine/schema/src/com/cloud/storage/VMTemplateVO.java e643d75 
>   engine/schema/src/com/cloud/vm/VMInstanceVO.java fbe03dc 
>   
> engine/storage/src/org/apache/cloudstack/storage/image/TemplateEntityImpl.java
>  4d162bb 
>   plugins/hypervisors/xen/src/com/cloud/hypervisor/XenServerGuru.java 8c38a69 
>   
> plugins/hypervisors/xen/src/com/cloud/hypervisor/xen/resource/CitrixResourceBase.java
>  5e8283a 
>   
> plugins/hypervisors/xen/src/com/cloud/hypervisor/xen/resource/XenServer56FP1Resource.java
>  8e37809 
>   server/src/com/cloud/api/ApiResponseHelper.java 7ffa30f 
>   server/src/com/cloud/api/query/dao/UserVmJoinDaoImpl.java f9877ab 
>   server/src/com/cloud/api/query/vo/UserVmJoinVO.java c97d71a 
>   server/src/com/cloud/hypervisor/HypervisorGuruBase.java 1ad9a1f 
>   server/src/com/cloud/server/ManagementServerImpl.java cfc8333 
>   server/src/com/cloud/storage/TemplateProfile.java 0b55f1f 
>   server/src/com/cloud/template/TemplateAdapter.java 9a2d877 
>   server/src/com/cloud/template/TemplateAdapterBase.java 0940d3e 
>   server/src/com/cloud/vm/UserVmManagerImpl.java e8ea024 
>   server/src/com/cloud/vm/VirtualMachineManagerImpl.java 5814075 
>   server/test/com/cloud/vm/VirtualMachineManagerImplTest.java 8715c9e 
>   setup/db/db/schema-410to420.sql c782234 
> 
> Diff: https://reviews.apache.org/r/11910/diff/
> 
> 
> Testing
> ---
> 
> Tested locally
> 
> 
> Thanks,
> 
> Harikrishna Patnala
> 
>

Re: Review Request: Cloudstack-2644 [Multiple_IP_Ranges] user data service on VR does not work in case of multiple subnets Cloudstack-2953 [Multiple_IP_Ranges] VM does not get the public key from VR i

2013-06-19 Thread bharat kumar


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

(Updated June 20, 2013, 5:39 a.m.)


Review request for cloudstack and Abhinandan Prateek.


Changes
---

Removed tabs


Description
---

Cloudstack-2644 [Multiple_IP_Ranges] user data service on VR does not work in 
case of multiple subnets 
https://issues.apache.org/jira/browse/CLOUDSTACK-2644

Cloudstack-2953 [Multiple_IP_Ranges] VM does not get the public key from VR 
incase of multiple subnets per vlan Also removed some
 unused code.
https://issues.apache.org/jira/browse/CLOUDSTACK-2953


This addresses bugs Cloudstack-2644 and Cloudstack-2953.


Diffs (updated)
-

  patches/systemvm/debian/config/etc/init.d/cloud-early-config 0dcd571 
  server/src/com/cloud/network/router/VirtualNetworkApplianceManagerImpl.java 
8edd5bd 
  server/src/com/cloud/vm/dao/NicIpAliasDao.java f1e4b8e 
  server/src/com/cloud/vm/dao/NicIpAliasDaoImpl.java e6c52a2 
  setup/bindir/cloud-set-guest-sshkey.in f3f02b1 

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


Testing
---

tested on master.


Thanks,

bharat kumar

Re: Review Request: Fix CLOUDSTACK-2168


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

Ship it!


Ship It!

- Abhinandan Prateek


On June 18, 2013, 8:38 a.m., Ian Duffy wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/11907/
> ---
> 
> (Updated June 18, 2013, 8:38 a.m.)
> 
> 
> Review request for cloudstack, Abhinandan Prateek and Sebastien Goasguen.
> 
> 
> Description
> ---
> 
> CLOUDSTACK-2168 detailed a bug that caused the ldap configuration to not 
> appear.
> 
> This bug occurred due to the UI expecting a "list" of ldap configurations 
> back from the API.
> 
> I have modified the API command to return a "list" like format, but since 
> cloudstack only currently supports authentication against one ldap server it 
> will only return 1 configuration.
> 
> Whoever takes up CLOUDSTACK-430 
> https://issues.apache.org/jira/browse/CLOUDSTACK-430 - Add support for 
> multiple ldap servers will have to expand on this output. 
> 
> 
> This addresses bug CLOUDSTACK-2168.
> 
> 
> Diffs
> -
> 
>   api/src/org/apache/cloudstack/api/command/admin/ldap/LDAPConfigCmd.java 
> 2726f84 
> 
> Diff: https://reviews.apache.org/r/11907/diff/
> 
> 
> Testing
> ---
> 
> Build the code with the changes, confirmed the API still returned the 
> expected results.
> Confirmed that the UI showed the configuration.
> 
> 
> Thanks,
> 
> Ian Duffy
> 
>

Re: Review Request: Fix CLOUDSTACK-2168


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


Commit 576884ec10b4a46b243b8138926c0fc650bcdaba in branch refs/heads/master 
from Ian Duffy
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=576884e ]

Add fix for CLOUDSTACK-2168. Changed listAll output to conform to the same 
output as listconfiguration

Signed-off-by: Abhinandan Prateek 


- ASF Subversion and Git Services


On June 18, 2013, 8:38 a.m., Ian Duffy wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/11907/
> ---
> 
> (Updated June 18, 2013, 8:38 a.m.)
> 
> 
> Review request for cloudstack, Abhinandan Prateek and Sebastien Goasguen.
> 
> 
> Description
> ---
> 
> CLOUDSTACK-2168 detailed a bug that caused the ldap configuration to not 
> appear.
> 
> This bug occurred due to the UI expecting a "list" of ldap configurations 
> back from the API.
> 
> I have modified the API command to return a "list" like format, but since 
> cloudstack only currently supports authentication against one ldap server it 
> will only return 1 configuration.
> 
> Whoever takes up CLOUDSTACK-430 
> https://issues.apache.org/jira/browse/CLOUDSTACK-430 - Add support for 
> multiple ldap servers will have to expand on this output. 
> 
> 
> This addresses bug CLOUDSTACK-2168.
> 
> 
> Diffs
> -
> 
>   api/src/org/apache/cloudstack/api/command/admin/ldap/LDAPConfigCmd.java 
> 2726f84 
> 
> Diff: https://reviews.apache.org/r/11907/diff/
> 
> 
> Testing
> ---
> 
> Build the code with the changes, confirmed the API still returned the 
> expected results.
> Confirmed that the UI showed the configuration.
> 
> 
> Thanks,
> 
> Ian Duffy
> 
>

Re: Review Request: Fix CLOUDSTACK-2168


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


Commit d3d6350219c9f02ce5d604a81a0c3c12ff700672 in branch refs/heads/master 
from Abhinandan Prateek
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=d3d6350 ]

CLOUDSTACK-2168: removed unused commit


- ASF Subversion and Git Services


On June 18, 2013, 8:38 a.m., Ian Duffy wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/11907/
> ---
> 
> (Updated June 18, 2013, 8:38 a.m.)
> 
> 
> Review request for cloudstack, Abhinandan Prateek and Sebastien Goasguen.
> 
> 
> Description
> ---
> 
> CLOUDSTACK-2168 detailed a bug that caused the ldap configuration to not 
> appear.
> 
> This bug occurred due to the UI expecting a "list" of ldap configurations 
> back from the API.
> 
> I have modified the API command to return a "list" like format, but since 
> cloudstack only currently supports authentication against one ldap server it 
> will only return 1 configuration.
> 
> Whoever takes up CLOUDSTACK-430 
> https://issues.apache.org/jira/browse/CLOUDSTACK-430 - Add support for 
> multiple ldap servers will have to expand on this output. 
> 
> 
> This addresses bug CLOUDSTACK-2168.
> 
> 
> Diffs
> -
> 
>   api/src/org/apache/cloudstack/api/command/admin/ldap/LDAPConfigCmd.java 
> 2726f84 
> 
> Diff: https://reviews.apache.org/r/11907/diff/
> 
> 
> Testing
> ---
> 
> Build the code with the changes, confirmed the API still returned the 
> expected results.
> Confirmed that the UI showed the configuration.
> 
> 
> Thanks,
> 
> Ian Duffy
> 
>

Re: Review Request: Adding base support for NVP security groups to the NVP API