date:20141110


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

Ship it!


ea99ff1c8622eadf8024ee9922d5f2b2b18d4f80

- Kishan Kavala


On Oct. 22, 2014, 11:33 a.m., bharat kumar wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/27021/
> ---
> 
> (Updated Oct. 22, 2014, 11:33 a.m.)
> 
> 
> Review request for cloudstack and Kishan Kavala.
> 
> 
> Bugs: CLOUDSTACK-7763
> https://issues.apache.org/jira/browse/CLOUDSTACK-7763
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Reservations for VMware VMs remain after dynamic scaling
> https://issues.apache.org/jira/browse/CLOUDSTACK-7763
> 
> 
> Diffs
> -
> 
>   
> plugins/hypervisors/vmware/src/com/cloud/hypervisor/vmware/resource/VmwareResource.java
>  085b6bbed4918be3155fd44c8bed785983526e11 
> 
> Diff: https://reviews.apache.org/r/27021/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> bharat kumar
> 
>

Re: Review Request 27520: Usage Job fails with "Data too long for column 'user_name'"


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

Ship it!


Master: 895cc9189ab61d4d084c1aa6a2773b65eb6ad5f7

- Kishan Kavala


On Nov. 10, 2014, 2:44 p.m., Damodar Reddy Talakanti wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/27520/
> ---
> 
> (Updated Nov. 10, 2014, 2:44 p.m.)
> 
> 
> Review request for cloudstack and Kishan Kavala.
> 
> 
> Bugs: CLOUDSTACK-7830
> https://issues.apache.org/jira/browse/CLOUDSTACK-7830
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> While inserting into the cloud_usage database  it is getting the following 
> exception.
> 
> INSERT INTO usage_vpn_user (usage_vpn_user.zone_id, 
> usage_vpn_user.account_id, usage_vpn_user.domain_id, usage_vpn_user.user_id, 
> usage_vpn_user.user_name, usage_vpn_user.created, usage_vpn_user.deleted) 
> VALUES (0, 13, 14, 4, _binary'timothy.lother...@dcxclouddemo.co.za', 
> '2014-03-11 14:36:50', null)
> 
> Caused by: com.mysql.jdbc.MysqlDataTruncation: Data truncation: Data too long 
> for column 'user_name' at row 1
>   at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:4072)
> 
> 
> Diffs
> -
> 
>   setup/db/db/schema-441to450.sql d9bc8e0 
> 
> Diff: https://reviews.apache.org/r/27520/diff/
> 
> 
> Testing
> ---
> 
> Tested on 4.5.0 by upgrading from 4.3.0
> 
> 
> Thanks,
> 
> Damodar Reddy Talakanti
> 
>

Re: Review Request 26969: During VM deployment and while choosing CUSTOM disk offering for data disk, the size of the data disk is not considered for checking resource limit of primary storage.


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

Ship it!


Master: 991d783e0332d07cba18d046dfc7220a063f670f

- Kishan Kavala


On Oct. 21, 2014, 6:04 p.m., bharat kumar wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/26969/
> ---
> 
> (Updated Oct. 21, 2014, 6:04 p.m.)
> 
> 
> Review request for cloudstack and Kishan Kavala.
> 
> 
> Bugs: CLOUDSTACK-7760
> https://issues.apache.org/jira/browse/CLOUDSTACK-7760
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> https://issues.apache.org/jira/browse/CLOUDSTACK-7760
> During VM deployment and while choosing CUSTOM disk offering for data disk, 
> the size of the data disk is not considered for checking resource limit of 
> primary storage.
> 
> 
> Diffs
> -
> 
>   server/src/com/cloud/vm/UserVmManagerImpl.java 
> 2636096d03d7cfa097605ac066b8bd66b24972b7 
> 
> Diff: https://reviews.apache.org/r/26969/diff/
> 
> 
> Testing
> ---
> 
> tested on 4.5
> 
> 
> Thanks,
> 
> bharat kumar
> 
>

Re: Review Request 27671: MS does not start after the VM it is running on is rebooted


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

Ship it!


Master: 131c2f2014f69685b200b5304be88d9b1da3a2c9

- Kishan Kavala


On Nov. 6, 2014, 12:26 p.m., Damodar Reddy Talakanti wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/27671/
> ---
> 
> (Updated Nov. 6, 2014, 12:26 p.m.)
> 
> 
> Review request for cloudstack, Kishan Kavala and Santhosh Edukulla.
> 
> 
> Bugs: CLOUDSTACK-7851
> https://issues.apache.org/jira/browse/CLOUDSTACK-7851
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> After installing management server on centos and try to reboot the machine. 
> It will not start the management server automatically.
> 
> 
> Diffs
> -
> 
>   packaging/centos63/cloud-management.rc eaabd30 
> 
> Diff: https://reviews.apache.org/r/27671/diff/
> 
> 
> Testing
> ---
> 
> Tested on Centos 6.x and RHEL 7
> 
> 
> Thanks,
> 
> Damodar Reddy Talakanti
> 
>

Re: Review Request 27641: CLOUDSTACK-7849



> On Nov. 6, 2014, 4:50 a.m., Rajani Karuturi wrote:
> > Can you also assign and resolve the JIRA ticket?
> 
> Rajani Karuturi wrote:
> commit: e03a7e6feaae2d024f2a53afd71e0230309b1085 on 4.5 and master
> 
> Rajani Karuturi wrote:
> putting the JIRA ID in commit message will also help.
> 
> Daniel Vega Simoes wrote:
> Thanks Rajani. Will update the JIRA.
> 
> Daniel Vega Simoes wrote:
> We did resolve the JIRA ticket, but were not able to change the assignee

Thanks. Can you also mark the review submitted?


- Rajani


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


On Nov. 5, 2014, 8:39 p.m., Daniel Vega Simoes wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/27641/
> ---
> 
> (Updated Nov. 5, 2014, 8:39 p.m.)
> 
> 
> Review request for cloudstack.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> There should be some kind of criteria to list the projects on the drop-down 
> menu. We changed the projectSelect.js to sort the projects alphabetically.
> 
> JIRA - CLOUDSTACK-7849
> https://issues.apache.org/jira/browse/CLOUDSTACK-7849
> 
> 
> Diffs
> -
> 
>   ui/scripts/ui-custom/projectSelect.js ba4c7c7 
> 
> Diff: https://reviews.apache.org/r/27641/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Daniel Vega Simoes
> 
>

Re: Review Request 27613: sync Job Failures always reported as success on Event Bus


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

Ship it!


Master: ca66062cd54305afaaa64d707a88fc11764e292d

- Kishan Kavala


On Nov. 5, 2014, 5:26 p.m., Damodar Reddy Talakanti wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/27613/
> ---
> 
> (Updated Nov. 5, 2014, 5:26 p.m.)
> 
> 
> Review request for cloudstack, Kishan Kavala and Koushik Das.
> 
> 
> Bugs: CLOUDSTACK-7843
> https://issues.apache.org/jira/browse/CLOUDSTACK-7843
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> As complete async job event gets published before saving the job status to 
> the database. so it is not putting correct job status into event bus while 
> publishing.
> 
> 
> Diffs
> -
> 
>   
> framework/jobs/src/org/apache/cloudstack/framework/jobs/impl/AsyncJobManagerImpl.java
>  548182a 
> 
> Diff: https://reviews.apache.org/r/27613/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Damodar Reddy Talakanti
> 
>

Build failed in Jenkins: build-master #1833

See 

--
Started by an SCM change
[EnvInject] - Loading node environment variables.
Building remotely on cloudstack-buildslave-centos6-b00 
(cloudstack-buildslave-centos6) in workspace /jenkins/workspace/build-master
Cloning the remote Git repository
Cloning repository https://git-wip-us.apache.org/repos/asf/cloudstack.git
 > /usr/bin/git init /jenkins/workspace/build-master # timeout=400
Fetching upstream changes from 
https://git-wip-us.apache.org/repos/asf/cloudstack.git
 > /usr/bin/git --version # timeout=400
 > /usr/bin/git fetch --tags --progress 
 > https://git-wip-us.apache.org/repos/asf/cloudstack.git 
 > +refs/heads/*:refs/remotes/origin/*
 > /usr/bin/git config remote.origin.url 
 > https://git-wip-us.apache.org/repos/asf/cloudstack.git # timeout=400
 > /usr/bin/git config remote.origin.fetch +refs/heads/*:refs/remotes/origin/* 
 > # timeout=400
 > /usr/bin/git config remote.origin.url 
 > https://git-wip-us.apache.org/repos/asf/cloudstack.git # timeout=400
Fetching upstream changes from 
https://git-wip-us.apache.org/repos/asf/cloudstack.git
 > /usr/bin/git fetch --tags --progress 
 > https://git-wip-us.apache.org/repos/asf/cloudstack.git 
 > +refs/heads/*:refs/remotes/origin/*
FATAL: java.io.IOException: Unexpected termination of the channel
hudson.remoting.RequestAbortedException: java.io.IOException: Unexpected 
termination of the channel
at hudson.remoting.Request.abort(Request.java:295)
at hudson.remoting.Channel.terminate(Channel.java:814)
at 
hudson.remoting.SynchronousCommandTransport$ReaderThread.run(SynchronousCommandTransport.java:69)
at ..remote call to cloudstack-buildslave-centos6-b00(Native Method)
at hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1356)
at hudson.remoting.Request.call(Request.java:171)
at hudson.remoting.Channel.call(Channel.java:751)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler.execute(RemoteGitImpl.java:146)
at sun.reflect.GeneratedMethodAccessor462.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at 
org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler.invoke(RemoteGitImpl.java:132)
at sun.proxy.$Proxy112.execute(Unknown Source)
at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:645)
at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:889)
at hudson.plugins.git.GitSCM.checkout(GitSCM.java:914)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1258)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:622)
at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:528)
at hudson.model.Run.execute(Run.java:1759)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
at hudson.model.ResourceController.execute(ResourceController.java:89)
at hudson.model.Executor.run(Executor.java:240)
Caused by: java.io.IOException: Unexpected termination of the channel
at 
hudson.remoting.SynchronousCommandTransport$ReaderThread.run(SynchronousCommandTransport.java:50)
Caused by: java.io.EOFException
at 
java.io.ObjectInputStream$PeekInputStream.readFully(ObjectInputStream.java:2304)
at 
java.io.ObjectInputStream$BlockDataInputStream.readShort(ObjectInputStream.java:2773)
at 
java.io.ObjectInputStream.readStreamHeader(ObjectInputStream.java:798)
at java.io.ObjectInputStream.(ObjectInputStream.java:298)
at 
hudson.remoting.ObjectInputStreamEx.(ObjectInputStreamEx.java:40)
at 
hudson.remoting.AbstractSynchronousByteArrayCommandTransport.read(AbstractSynchronousByteArrayCommandTransport.java:34)
at 
hudson.remoting.SynchronousCommandTransport$ReaderThread.run(SynchronousCommandTransport.java:48)

Re: Review Request 27652: Normalize error message strings to make maintenance of said strings a bit easier.



> On Nov. 6, 2014, 4:49 a.m., Rajani Karuturi wrote:
> > looking at the diff isnt giving me much information. Can you share what 
> > issues it is solving(a JIRA ticket?)? Is this related to internationalizing 
> > the strings?
> 
> Derrick Schneider wrote:
> Sorry it's not more clear. I asked on the dev list if this kind of change 
> needed a JIRA ticket, and my understanding was that it did not. If I 
> misunderstood, I'm happy to add one. I noticed this while debugging a 
> separate unrelated issue.
> 
> This is just making code maintenance a little easier. Right now, the code 
> does this:
> 
> doSomethingWithString("blah blah blah");
> doSomethingElseWithString("blah blah blah");
> 
> If you wanted to change the string, you'd have to change it in both 
> places, and thus you might forget one, which would create inconsistent log 
> messages relative to the message in the exception that gets thrown.
> 
> So my change just moves the String into a variable and then uses that 
> variable in both places. Now changing the string means changing it once. And 
> it does it for a few places where that was true. 
> 
> I hope that clarifies.

I didnt check in my earlier review that the strings is being used twice. 
Thanks. I will submit the patch.


- Rajani


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


On Nov. 6, 2014, 12:46 a.m., Derrick Schneider wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/27652/
> ---
> 
> (Updated Nov. 6, 2014, 12:46 a.m.)
> 
> 
> Review request for cloudstack.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Takes strings that were duplicated within DatabaseUpgradeChecker and puts 
> them into nearby variables.
> 
> 
> Diffs
> -
> 
>   engine/schema/src/com/cloud/upgrade/DatabaseUpgradeChecker.java cba6b83 
> 
> Diff: https://reviews.apache.org/r/27652/diff/
> 
> 
> Testing
> ---
> 
> As this is just putting an extant value into a variable, I simply did a build 
> to make sure everything was still good. If there's other stuff I can do, 
> please advise.
> 
> 
> Thanks,
> 
> Derrick Schneider
> 
>

Re: Review Request 27652: Normalize error message strings to make maintenance of said strings a bit easier.


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

Ship it!


Ship It!

- Rajani Karuturi


On Nov. 6, 2014, 12:46 a.m., Derrick Schneider wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/27652/
> ---
> 
> (Updated Nov. 6, 2014, 12:46 a.m.)
> 
> 
> Review request for cloudstack.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Takes strings that were duplicated within DatabaseUpgradeChecker and puts 
> them into nearby variables.
> 
> 
> Diffs
> -
> 
>   engine/schema/src/com/cloud/upgrade/DatabaseUpgradeChecker.java cba6b83 
> 
> Diff: https://reviews.apache.org/r/27652/diff/
> 
> 
> Testing
> ---
> 
> As this is just putting an extant value into a variable, I simply did a build 
> to make sure everything was still good. If there's other stuff I can do, 
> please advise.
> 
> 
> Thanks,
> 
> Derrick Schneider
> 
>

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

See

Re: Review Request 27652: Normalize error message strings to make maintenance of said strings a bit easier.



> On Nov. 10, 2014, 9:33 a.m., Rajani Karuturi wrote:
> > Ship It!

commit: de3eb88b33eabc98568c353df4f5ee9e3233239c on 4.5 and master


- Rajani


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


On Nov. 6, 2014, 12:46 a.m., Derrick Schneider wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/27652/
> ---
> 
> (Updated Nov. 6, 2014, 12:46 a.m.)
> 
> 
> Review request for cloudstack.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Takes strings that were duplicated within DatabaseUpgradeChecker and puts 
> them into nearby variables.
> 
> 
> Diffs
> -
> 
>   engine/schema/src/com/cloud/upgrade/DatabaseUpgradeChecker.java cba6b83 
> 
> Diff: https://reviews.apache.org/r/27652/diff/
> 
> 
> Testing
> ---
> 
> As this is just putting an extant value into a variable, I simply did a build 
> to make sure everything was still good. If there's other stuff I can do, 
> please advise.
> 
> 
> Thanks,
> 
> Derrick Schneider
> 
>

Re: Review Request 26969: During VM deployment and while choosing CUSTOM disk offering for data disk, the size of the data disk is not considered for checking resource limit of primary storage.


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


4.5: 310bb255acd74b6347bd778590e15543eef7333b

- Kishan Kavala


On Oct. 21, 2014, 6:04 p.m., bharat kumar wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/26969/
> ---
> 
> (Updated Oct. 21, 2014, 6:04 p.m.)
> 
> 
> Review request for cloudstack and Kishan Kavala.
> 
> 
> Bugs: CLOUDSTACK-7760
> https://issues.apache.org/jira/browse/CLOUDSTACK-7760
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> https://issues.apache.org/jira/browse/CLOUDSTACK-7760
> During VM deployment and while choosing CUSTOM disk offering for data disk, 
> the size of the data disk is not considered for checking resource limit of 
> primary storage.
> 
> 
> Diffs
> -
> 
>   server/src/com/cloud/vm/UserVmManagerImpl.java 
> 2636096d03d7cfa097605ac066b8bd66b24972b7 
> 
> Diff: https://reviews.apache.org/r/26969/diff/
> 
> 
> Testing
> ---
> 
> tested on 4.5
> 
> 
> Thanks,
> 
> bharat kumar
> 
>

Re: Review Request 27021: Reservations for VMware VMs remain after dynamic scaling


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


4.5 0e7f1ea9b819de197e70a088e92d7ffb7016d063

- Kishan Kavala


On Oct. 22, 2014, 11:33 a.m., bharat kumar wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/27021/
> ---
> 
> (Updated Oct. 22, 2014, 11:33 a.m.)
> 
> 
> Review request for cloudstack and Kishan Kavala.
> 
> 
> Bugs: CLOUDSTACK-7763
> https://issues.apache.org/jira/browse/CLOUDSTACK-7763
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Reservations for VMware VMs remain after dynamic scaling
> https://issues.apache.org/jira/browse/CLOUDSTACK-7763
> 
> 
> Diffs
> -
> 
>   
> plugins/hypervisors/vmware/src/com/cloud/hypervisor/vmware/resource/VmwareResource.java
>  085b6bbed4918be3155fd44c8bed785983526e11 
> 
> Diff: https://reviews.apache.org/r/27021/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> bharat kumar
> 
>

Re: Review Request 27613: sync Job Failures always reported as success on Event Bus


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


4.5 cdabb2407a0761939d5159fd2317ebd7dcca4eb7

- Kishan Kavala


On Nov. 5, 2014, 5:26 p.m., Damodar Reddy Talakanti wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/27613/
> ---
> 
> (Updated Nov. 5, 2014, 5:26 p.m.)
> 
> 
> Review request for cloudstack, Kishan Kavala and Koushik Das.
> 
> 
> Bugs: CLOUDSTACK-7843
> https://issues.apache.org/jira/browse/CLOUDSTACK-7843
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> As complete async job event gets published before saving the job status to 
> the database. so it is not putting correct job status into event bus while 
> publishing.
> 
> 
> Diffs
> -
> 
>   
> framework/jobs/src/org/apache/cloudstack/framework/jobs/impl/AsyncJobManagerImpl.java
>  548182a 
> 
> Diff: https://reviews.apache.org/r/27613/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Damodar Reddy Talakanti
> 
>

Re: Review Request 27671: MS does not start after the VM it is running on is rebooted


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


4.5 34f31f90331d0027b133ccdc8fdb65ab86ce26cc

- Kishan Kavala


On Nov. 6, 2014, 12:26 p.m., Damodar Reddy Talakanti wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/27671/
> ---
> 
> (Updated Nov. 6, 2014, 12:26 p.m.)
> 
> 
> Review request for cloudstack, Kishan Kavala and Santhosh Edukulla.
> 
> 
> Bugs: CLOUDSTACK-7851
> https://issues.apache.org/jira/browse/CLOUDSTACK-7851
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> After installing management server on centos and try to reboot the machine. 
> It will not start the management server automatically.
> 
> 
> Diffs
> -
> 
>   packaging/centos63/cloud-management.rc eaabd30 
> 
> Diff: https://reviews.apache.org/r/27671/diff/
> 
> 
> Testing
> ---
> 
> Tested on Centos 6.x and RHEL 7
> 
> 
> Thanks,
> 
> Damodar Reddy Talakanti
> 
>

Re: Review Request 27520: Usage Job fails with "Data too long for column 'user_name'"


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


4.5 36fd780482dbd65ef9328f630d0af0793d0fed2e

- Kishan Kavala


On Nov. 10, 2014, 2:44 p.m., Damodar Reddy Talakanti wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/27520/
> ---
> 
> (Updated Nov. 10, 2014, 2:44 p.m.)
> 
> 
> Review request for cloudstack and Kishan Kavala.
> 
> 
> Bugs: CLOUDSTACK-7830
> https://issues.apache.org/jira/browse/CLOUDSTACK-7830
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> While inserting into the cloud_usage database  it is getting the following 
> exception.
> 
> INSERT INTO usage_vpn_user (usage_vpn_user.zone_id, 
> usage_vpn_user.account_id, usage_vpn_user.domain_id, usage_vpn_user.user_id, 
> usage_vpn_user.user_name, usage_vpn_user.created, usage_vpn_user.deleted) 
> VALUES (0, 13, 14, 4, _binary'timothy.lother...@dcxclouddemo.co.za', 
> '2014-03-11 14:36:50', null)
> 
> Caused by: com.mysql.jdbc.MysqlDataTruncation: Data truncation: Data too long 
> for column 'user_name' at row 1
>   at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:4072)
> 
> 
> Diffs
> -
> 
>   setup/db/db/schema-441to450.sql d9bc8e0 
> 
> Diff: https://reviews.apache.org/r/27520/diff/
> 
> 
> Testing
> ---
> 
> Tested on 4.5.0 by upgrading from 4.3.0
> 
> 
> Thanks,
> 
> Damodar Reddy Talakanti
> 
>

Re: Review Request 27222: Usage Events to be captured based on Volume State Machine

2014-11-10 Thread Damodar Reddy Talakanti

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

(Updated Nov. 10, 2014, 9:45 a.m.)

Review request for cloudstack, Kishan Kavala and Koushik Das.

Changes
---

Updating the patch as it is not getting applied on the master

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

Repository: cloudstack-git

Description
---

Currently in CloudStack the Usage Events for Volume related actions are
captured directly at various places.

But actually Volume has a State Machine which can be used to capture Usage
Events for volume similar to VM Usage Events

Diffs (updated)
-

api/src/com/cloud/storage/Volume.java 91ad955
api/src/com/cloud/vm/VirtualMachine.java 99152d6

engine/api/src/org/apache/cloudstack/engine/subsystem/api/storage/ObjectInDataStoreStateMachine.java
b21616a

engine/orchestration/src/org/apache/cloudstack/engine/orchestration/VolumeOrchestrator.java
826e2ee
engine/schema/src/com/cloud/storage/VolumeVO.java e328253

engine/storage/volume/src/org/apache/cloudstack/storage/volume/VolumeObject.java
f2b4c95

engine/storage/volume/src/org/apache/cloudstack/storage/volume/VolumeServiceImpl.java
9c45cb8
server/src/com/cloud/storage/StorageManagerImpl.java 153c25a
server/src/com/cloud/storage/VolumeApiServiceImpl.java 088f054
server/src/com/cloud/storage/listener/VolumeStateListener.java 0ba2969

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

Testing
---

Tested on Simulator. Also tested on XenServer for the following use cases

1. Add Volume (Migrate, Destroy)
2. Attach Volume (Live Migration and normal Migration)
3. Upload Volume (Attach also)
4. Delete Volume
5. Deploy VM (With Data Disk and with out Data Disk)
6. Destroy VM (With Data Disk and with out Data Disk)
7. Recover VM
8. Restore VM
9. Resize Volume

Thanks,

Damodar Reddy Talakanti

Re: Review Request 27222: Usage Events to be captured based on Volume State Machine


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

Ship it!


master: 781648fb1003c8c32875e9ff7a6c4ef4694539f7

- Kishan Kavala


On Nov. 10, 2014, 3:15 p.m., Damodar Reddy Talakanti wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/27222/
> ---
> 
> (Updated Nov. 10, 2014, 3:15 p.m.)
> 
> 
> Review request for cloudstack, Kishan Kavala and Koushik Das.
> 
> 
> Bugs: CLOUDSTACK-7792
> https://issues.apache.org/jira/browse/CLOUDSTACK-7792
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Currently in CloudStack the Usage Events for Volume related actions are 
> captured directly at various places.
> 
> But actually Volume has a State Machine which can be used to capture Usage 
> Events for volume similar to VM Usage Events
> 
> 
> Diffs
> -
> 
>   api/src/com/cloud/storage/Volume.java 91ad955 
>   api/src/com/cloud/vm/VirtualMachine.java 99152d6 
>   
> engine/api/src/org/apache/cloudstack/engine/subsystem/api/storage/ObjectInDataStoreStateMachine.java
>  b21616a 
>   
> engine/orchestration/src/org/apache/cloudstack/engine/orchestration/VolumeOrchestrator.java
>  826e2ee 
>   engine/schema/src/com/cloud/storage/VolumeVO.java e328253 
>   
> engine/storage/volume/src/org/apache/cloudstack/storage/volume/VolumeObject.java
>  f2b4c95 
>   
> engine/storage/volume/src/org/apache/cloudstack/storage/volume/VolumeServiceImpl.java
>  9c45cb8 
>   server/src/com/cloud/storage/StorageManagerImpl.java 153c25a 
>   server/src/com/cloud/storage/VolumeApiServiceImpl.java 088f054 
>   server/src/com/cloud/storage/listener/VolumeStateListener.java 0ba2969 
> 
> Diff: https://reviews.apache.org/r/27222/diff/
> 
> 
> Testing
> ---
> 
> Tested on Simulator. Also tested on XenServer for the following use cases
> 
> 1. Add Volume (Migrate, Destroy)
> 2. Attach Volume (Live Migration and normal Migration)
> 3. Upload Volume (Attach also)
> 4. Delete Volume
> 5. Deploy VM (With Data Disk and with out Data Disk)
> 6. Destroy VM (With Data Disk and with out Data Disk)
> 7. Recover VM
> 8. Restore VM
> 9. Resize Volume
> 
> 
> Thanks,
> 
> Damodar Reddy Talakanti
> 
>

Jenkins build is back to normal : build-4.5 #108

See

Re: Review Request 20518: CLOUDSTACK-6465: vmware.reserve.mem is missing from cluster level settings


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

(Updated Nov. 10, 2014, 10:04 a.m.)


Review request for cloudstack and Kishan Kavala.


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


Repository: cloudstack-git


Description
---

CLOUDSTACK-6465: vmware.reserve.mem is missing from cluster level settings 


Diffs (updated)
-

  plugins/hypervisors/vmware/src/com/cloud/hypervisor/guru/VMwareGuru.java 
7c23699 
  
plugins/hypervisors/vmware/src/com/cloud/hypervisor/vmware/manager/VmwareManagerImpl.java
 4f24882 
  
plugins/hypervisors/vmware/src/com/cloud/hypervisor/vmware/resource/VmwareResource.java
 e3bfbe5 
  server/src/com/cloud/configuration/Config.java 5ac0e90 

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


Testing
---


Thanks,

Harikrishna Patnala

Re: Review Request 17941: CLOUDSTACK-6075: Increase the ram size for router service offering


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

(Updated Nov. 10, 2014, 10:18 a.m.)


Review request for cloudstack and Jayapal Reddy.


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


Repository: cloudstack-git


Description
---

CLOUDSTACK-6075: Increase the ram size for router service offering 
Increased the ram size of Internal load balancer vm service offering also


Diffs (updated)
-

  engine/schema/src/com/cloud/upgrade/dao/Upgrade441to450.java cde661b 
  
plugins/network-elements/internal-loadbalancer/src/org/apache/cloudstack/network/lb/InternalLoadBalancerVMManager.java
 803d3a5 
  server/src/com/cloud/configuration/Config.java 517c76c 
  server/src/com/cloud/network/router/VirtualNetworkApplianceManager.java 
85ce8b9 
  setup/db/db/schema-441to450.sql c899289 

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


Testing
---

tested locally


Thanks,

Harikrishna Patnala

Re: Review Request 17941: CLOUDSTACK-6075: Increase the ram size for router service offering


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

(Updated Nov. 10, 2014, 10:20 a.m.)


Review request for cloudstack, Jayapal Reddy and Kishan Kavala.


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


Repository: cloudstack-git


Description
---

CLOUDSTACK-6075: Increase the ram size for router service offering 
Increased the ram size of Internal load balancer vm service offering also


Diffs
-

  engine/schema/src/com/cloud/upgrade/dao/Upgrade441to450.java cde661b 
  
plugins/network-elements/internal-loadbalancer/src/org/apache/cloudstack/network/lb/InternalLoadBalancerVMManager.java
 803d3a5 
  server/src/com/cloud/configuration/Config.java 517c76c 
  server/src/com/cloud/network/router/VirtualNetworkApplianceManager.java 
85ce8b9 
  setup/db/db/schema-441to450.sql c899289 

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


Testing
---

tested locally


Thanks,

Harikrishna Patnala

Re: Review Request 21805: CLOUDSTACK-6748: Creating an instance with user-data when network doesn't support user-data should error


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

(Updated Nov. 10, 2014, 10:21 a.m.)


Review request for cloudstack, Jayapal Reddy, Kishan Kavala, Murali Reddy, and 
Shengsheng Huang.


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


Repository: cloudstack-git


Description
---

CLOUDSTACK-6748: Creating an instance with user-data when network doesn't 
support user-data should error

When vm is deployed with userdata or ssh key or using password enabled template 
and in the default network that does not support userdata we should error the 
vm creation.


Diffs
-

  
engine/orchestration/src/org/apache/cloudstack/engine/orchestration/NetworkOrchestrator.java
 96dafe9 
  server/src/com/cloud/vm/UserVmManagerImpl.java cf04270 

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


Testing
---


Thanks,

Harikrishna Patnala

Re: Review Request 27801: CLOUDSTACK-7866: Passing type value to list_hosts method so as to avoid listing SSVM and CPVM

2014-11-10 Thread Gaurav Aradhye


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

(Updated Nov. 10, 2014, 4:20 p.m.)


Review request for cloudstack and SrikanteswaraRao Talluri.


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


Repository: cloudstack-git


Description (updated)
---

Changes:

1. Adding type="Routing" while listing hosts (to migrate VM to) so as to avoid 
listing SSVMs and CPVMs.
2. Correcting host.hostid to host.id
3. Replacing import * with actual module names


Diffs (updated)
-

  test/integration/component/maint/test_host_high_availability.py ecc23f7 

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


Testing (updated)
---

Yes.

Log:
Test VM deployments (Create HA enabled Compute Service Offering and VM) ... 
SKIP: Skip
Verify you can not create new VMs on hosts with an ha.tag ... SKIP: Skip
Verify you can not migrate VMs to hosts with an ha.tag (positive) ... SKIP: Skip
Verify you can not migrate VMs to hosts with an ha.tag (negative) ... === 
TestName: test_04_cant_migrate_vm_to_host_with_ha_negative | Status : SUCCESS 
===
ok
Verify that none of the VMs with HA enabled migrate to an ha tagged host during 
live migration ... SKIP: Skip
Verify that none of the VMs without HA enabled migrate to an ha tagged host 
during live migration ... SKIP: Skip

--
Ran 6 tests in 226.880s

OK (SKIP=5)


Thanks,

Gaurav Aradhye

Re: Review Request 27801: CLOUDSTACK-7866: Passing type value to list_hosts method so as to avoid listing SSVM and CPVM


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

Ship it!


b00f144c204bfa4ffa3db73c9d1fc9e86d79015c master
3e00f99c535e318faab4c09ac943fd8540f81d17 4.5

- SrikanteswaraRao Talluri


On Nov. 10, 2014, 10:50 a.m., Gaurav Aradhye wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/27801/
> ---
> 
> (Updated Nov. 10, 2014, 10:50 a.m.)
> 
> 
> Review request for cloudstack and SrikanteswaraRao Talluri.
> 
> 
> Bugs: CLOUDSTACK-7866
> https://issues.apache.org/jira/browse/CLOUDSTACK-7866
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Changes:
> 
> 1. Adding type="Routing" while listing hosts (to migrate VM to) so as to 
> avoid listing SSVMs and CPVMs.
> 2. Correcting host.hostid to host.id
> 3. Replacing import * with actual module names
> 
> 
> Diffs
> -
> 
>   test/integration/component/maint/test_host_high_availability.py ecc23f7 
> 
> Diff: https://reviews.apache.org/r/27801/diff/
> 
> 
> Testing
> ---
> 
> Yes.
> 
> Log:
> Test VM deployments (Create HA enabled Compute Service Offering and VM) ... 
> SKIP: Skip
> Verify you can not create new VMs on hosts with an ha.tag ... SKIP: Skip
> Verify you can not migrate VMs to hosts with an ha.tag (positive) ... SKIP: 
> Skip
> Verify you can not migrate VMs to hosts with an ha.tag (negative) ... === 
> TestName: test_04_cant_migrate_vm_to_host_with_ha_negative | Status : SUCCESS 
> ===
> ok
> Verify that none of the VMs with HA enabled migrate to an ha tagged host 
> during live migration ... SKIP: Skip
> Verify that none of the VMs without HA enabled migrate to an ha tagged host 
> during live migration ... SKIP: Skip
> 
> --
> Ran 6 tests in 226.880s
> 
> OK (SKIP=5)
> 
> 
> Thanks,
> 
> Gaurav Aradhye
> 
>

Re: Review Request 27756: CLOUDSTACK-7863 : Fixed the script "test_vpc_vms_deployment.py" - Test Cases failing on Simulator as Testcases try to ssh to the VMs


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

Ship it!


f78defda0fa1c07d440b484c414b16a09e58433a 4.5
aed6e95e5d17b2348d1f45f6319445360d3c6361 master

- SrikanteswaraRao Talluri


On Nov. 7, 2014, 11:36 p.m., Chandan Purushothama wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/27756/
> ---
> 
> (Updated Nov. 7, 2014, 11:36 p.m.)
> 
> 
> Review request for cloudstack, sangeetha hariharan and SrikanteswaraRao 
> Talluri.
> 
> 
> Bugs: CLOUDSTACK-7863
> https://issues.apache.org/jira/browse/CLOUDSTACK-7863
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Test Cases are trying to validate SSH access and failing. These Test Cases 
> are not meant to be run on SImulator due to their validation requirements. 
> Hence they cannot be run with Simulator
> 
> 
> Diffs
> -
> 
>   test/integration/component/test_vpc_vms_deployment.py e61b2f8 
> 
> Diff: https://reviews.apache.org/r/27756/diff/
> 
> 
> Testing
> ---
> 
> Changed the tags on Tests. Testing not done
> 
> 
> Thanks,
> 
> Chandan Purushothama
> 
>

Re: Review Request 27751: CLOUDSTACK-7862: Fixed the script 'maint/test_high_availability.py' - Test Cases failing on Simulator as Testcases try to ssh to the VMs


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

Ship it!


fa8f0a43c3ae9025fede058178284792936c8657 master
2f7959d2190d3afbd71f42a84725b75107f925d8 4.5

- SrikanteswaraRao Talluri


On Nov. 7, 2014, 11:27 p.m., Chandan Purushothama wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/27751/
> ---
> 
> (Updated Nov. 7, 2014, 11:27 p.m.)
> 
> 
> Review request for cloudstack, sangeetha hariharan and SrikanteswaraRao 
> Talluri.
> 
> 
> Bugs: CLOUDSTACK-7862
> https://issues.apache.org/jira/browse/CLOUDSTACK-7862
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Test Cases are trying to validate SSH access and failing. These Test Cases 
> are not meant to be run on SImulator due to their validation requirements. 
> Hence they cannot be run with Simulator
> 
> 
> Diffs
> -
> 
>   test/integration/component/maint/test_high_availability.py cc687f8 
> 
> Diff: https://reviews.apache.org/r/27751/diff/
> 
> 
> Testing
> ---
> 
> Changed the tags on Tests. Testing not done
> 
> 
> Thanks,
> 
> Chandan Purushothama
> 
>

Re: Review Request 27677: CLOUDSTACK-7856: test_vpc_network_pf_rules.py - Check if httpd service is running or not, if not, start it


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

Ship it!


23df5f22ac96bf8032d10a5b65c6016534d67fcb 4.5
a3d08aebb70bff102cb898d8c979f14cecc275cd master

- SrikanteswaraRao Talluri


On Nov. 6, 2014, 1:03 p.m., Gaurav Aradhye wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/27677/
> ---
> 
> (Updated Nov. 6, 2014, 1:03 p.m.)
> 
> 
> Review request for cloudstack and SrikanteswaraRao Talluri.
> 
> 
> Bugs: CLOUDSTACK-7856
> https://issues.apache.org/jira/browse/CLOUDSTACK-7856
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Wget operation will fail if httpd service is stopped. Check if it is running 
> or not, if not, start it.
> 
> Changes:
> 1. Start httpd service if it not running.
> 2. In case VM is not accessible, make it accessible before SSH
> 3. Improve logging.
> 
> 
> Diffs
> -
> 
>   test/integration/component/test_vpc_network_pfrules.py c3a8161 
> 
> Diff: https://reviews.apache.org/r/27677/diff/
> 
> 
> Testing
> ---
> 
> Yes.
> 
> 
> Thanks,
> 
> Gaurav Aradhye
> 
>

Re: Review Request 20518: CLOUDSTACK-6465: vmware.reserve.mem is missing from cluster level settings



> On Sept. 16, 2014, 10:17 a.m., Rohit Yadav wrote:
> > plugins/hypervisors/vmware/src/com/cloud/hypervisor/vmware/resource/VmwareResource.java,
> >  line 4995
> > 
> >
> > Are we using _reserveCpu and _reserveMem in any other place?

There are no any references


> On Sept. 16, 2014, 10:17 a.m., Rohit Yadav wrote:
> > server/src/com/cloud/configuration/Config.java, line 1194
> > 
> >
> > This removes vmware.reserve.mem and vmware.reserve.cpu from global 
> > settings, won't this break backward compatibility.

We have corresponding objects in vmwareguru. So this won't break anything. 
This is the way we are following to use ConfigKey interface


- Harikrishna


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


On Nov. 10, 2014, 10:04 a.m., Harikrishna Patnala wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/20518/
> ---
> 
> (Updated Nov. 10, 2014, 10:04 a.m.)
> 
> 
> Review request for cloudstack and Kishan Kavala.
> 
> 
> Bugs: CLOUDSTACK-6465
> https://issues.apache.org/jira/browse/CLOUDSTACK-6465
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> CLOUDSTACK-6465: vmware.reserve.mem is missing from cluster level settings 
> 
> 
> Diffs
> -
> 
>   plugins/hypervisors/vmware/src/com/cloud/hypervisor/guru/VMwareGuru.java 
> 7c23699 
>   
> plugins/hypervisors/vmware/src/com/cloud/hypervisor/vmware/manager/VmwareManagerImpl.java
>  4f24882 
>   
> plugins/hypervisors/vmware/src/com/cloud/hypervisor/vmware/resource/VmwareResource.java
>  e3bfbe5 
>   server/src/com/cloud/configuration/Config.java 5ac0e90 
> 
> Diff: https://reviews.apache.org/r/20518/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Harikrishna Patnala
> 
>

Re: Review Request 27416: CLOUDSTACK-7823: test_snapshots.py - remove test case dependency on each other


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

Ship it!


d4d8326a313b4dfecbeac04cfc51cbbf0a020563 master 
53694133d8848d56cdf10bf756022b3f2e9cf8d0 4.5

- SrikanteswaraRao Talluri


On Nov. 5, 2014, 8:44 a.m., Gaurav Aradhye wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/27416/
> ---
> 
> (Updated Nov. 5, 2014, 8:44 a.m.)
> 
> 
> Review request for cloudstack and SrikanteswaraRao Talluri.
> 
> 
> Bugs: CLOUDSTACK-7823
> https://issues.apache.org/jira/browse/CLOUDSTACK-7823
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> All test cases in this test suite are using the same account.
> Hence it leads to failures some times.
> 
> It is necessary to remove the dependency of test cases from each other.
> 
> I have not fixed pep8 issues because it becomes difficult to see the actual 
> changes then.
> Will add a new patch for pep8 issues.
> 
> 
> Diffs
> -
> 
>   test/integration/component/test_snapshots.py 0811eb1 
> 
> Diff: https://reviews.apache.org/r/27416/diff/
> 
> 
> Testing
> ---
> 
> Yes.
> 
> Log:
> Test create VM, Snapshot and Template ... === TestName: 
> test_01_createVM_snapshotTemplate | Status : SUCCESS ===
> ok
> Test snapshot events ... === TestName: test_05_snapshot_events | Status : 
> SUCCESS ===
> ok
> Test Creating snapshot from volume having spaces in name(KVM) ... === 
> TestName: test_01_volume_from_snapshot | Status : SUCCESS ===
> ok
> Test Snapshot Data Disk ... === TestName: test_02_snapshot_data_disk | Status 
> : SUCCESS ===
> ok
> Test snapshot from detached disk ... === TestName: 
> test_03_snapshot_detachedDisk | Status : SUCCESS ===
> ok
> Test Delete Snapshot ... === TestName: test_04_delete_snapshot | Status : 
> SUCCESS ===
> ok
> Create Template from snapshot ... === TestName: 
> test_07_template_from_snapshot | Status : SUCCESS ===
> ok
> 
> --
> Ran 7 tests in 2273.877s
> 
> OK
> 
> 
> Thanks,
> 
> Gaurav Aradhye
> 
>

Re: Review Request 27379: CLOUDSTACK-7118: Fixing test_escalations_instances.py, Removing dependency of test cases on each other


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

Ship it!


85ac979f72e7ea4b65f466429e786fe468a03646 4.5 
46802557e81c4fb114367b05fd55ea87b16aeeb5 master

- SrikanteswaraRao Talluri


On Nov. 5, 2014, 8:36 a.m., Gaurav Aradhye wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/27379/
> ---
> 
> (Updated Nov. 5, 2014, 8:36 a.m.)
> 
> 
> Review request for cloudstack and SrikanteswaraRao Talluri.
> 
> 
> Bugs: CLOUDSTACK-7818
> https://issues.apache.org/jira/browse/CLOUDSTACK-7818
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Changes:
> 
> 1. Removing dependency of test cases on each other, creating new account for 
> each test case.
> 2. Fix pep8 issues
> 3. Fixing imports
> 
> 
> Diffs
> -
> 
>   test/integration/component/test_escalations_instances.py 1aaa688 
> 
> Diff: https://reviews.apache.org/r/27379/diff/
> 
> 
> Testing
> ---
> 
> Yes. Tested with KVM advanced setup. Only one test case failed because it was 
> run on wrong configuration.
> 
> Log:
> @Desc: Test Attach ISO to VM and Detach ISO from VM. ... SKIP: This feature 
> is not supported on existing hypervisor. Hence, skipping the test
> @Desc: Test VM Snapshots pagination. ... SKIP: This feature is not supported 
> on existing hypervisor. Hence, skipping the test
> @Desc: Test Revert VM to Snapshot functionality. ... SKIP: This feature is 
> not supported on existing hypervisor. Hence, skipping the test
> @Desc: Test to verify pagination of Volumes for a VM ... === TestName: 
> test_16_list_vm_volumes_pagination | Status : SUCCESS ===
> ok
> @Desc: Test to verify change service for Running VM ... SKIP: ScaleVM is not 
> supported on KVM. Hence, skipping the test
> @Desc: Test to verify change service for Stopped VM ... === TestName: 
> test_18_stopped_vm_change_service | Status : SUCCESS ===
> ok
> @Desc: Test to verify creation and reset of SSH Key for VM ... === TestName: 
> test_19_create_reset_vm_sshkey | Status : SUCCESS ===
> ok
> @Desc: Test to verify Update VM details ... === TestName: 
> test_20_update_vm_displayname_group | Status : SUCCESS ===
> ok
> @Desc: Test to verify Restore VM ... === TestName: test_21_restore_vm | 
> Status : SUCCESS ===
> ok
> @Desc: Test to verify deploy VM with multiple networks ... === TestName: 
> test_22_deploy_vm_multiple_networks | Status : SUCCESS ===
> ok
> @Desc: Test to verify deploy VM with multiple Security Groups ... === 
> TestName: test_23_deploy_vm_multiple_securitygroups | Status : EXCEPTION ===
> ERROR
> @Desc: Test to verify deploy VM with static ip address assignment ... === 
> TestName: test_24_deploy_vm_with_static_ip_ES1662 | Status : SUCCESS ===
> ok
> @Desc: Test to verify dnsmasq dhcp conflict issue due to /ect/hosts not 
> getting udpated ... === TestName: test_25_ip_reallocation_ES1377 | Status : 
> SUCCESS ===
> ok
> @Desc: Test List Instances pagination ... === TestName: 
> test_01_list_instances_pagination | Status : SUCCESS ===
> ok
> @Desc: Test List Running VM's ... === TestName: test_02_list_Running_vm | 
> Status : SUCCESS ===
> ok
> @Desc: Test List Stopped VM's ... === TestName: test_03_list_Stopped_vm | 
> Status : SUCCESS ===
> ok
> @Desc: Test List Destroyed VM's ... === TestName: test_04_list_Destroyed_vm | 
> Status : SUCCESS ===
> ok
> @Desc: Test List VM by Id ... === TestName: test_05_list_vm_by_id | Status : 
> SUCCESS ===
> ok
> @Desc: Test List VM's by Name ... === TestName: test_06_list_vm_by_name | 
> Status : SUCCESS ===
> ok
> @Desc: Test List VM's by Name and State ... === TestName: 
> test_07_list_vm_by_name_state | Status : SUCCESS ===
> ok
> @Desc: Test List VM by Zone. ... === TestName: test_08_list_vm_by_zone | 
> Status : SUCCESS ===
> ok
> @Desc: Test List VM by Zone. ... === TestName: test_09_list_vm_by_zone_name | 
> Status : SUCCESS ===
> ok
> @Desc: Test List VM by Zone. ... === TestName: 
> test_10_list_vm_by_zone_name_state | Status : SUCCESS ===
> ok
> @Desc: Test to verify registering and reset of SSH Key for VM ... === 
> TestName: test_11_register_reset_vm_sshkey | Status : SUCCESS ===
> ok
> @Desc: Test to verify change service for Running VM ... === TestName: 
> test_12_running_vm_change_service | Status : SUCCESS ===
> ok
> @Desc: Test to verify Nics for a VM ... === TestName: test_13_vm_nics | 
> Status : SUCCESS ===
> ok
> 
> 
> Thanks,
> 
> Gaurav Aradhye
> 
>

Re: Review Request 27321: CLOUDSTACK-7815: Automation test cases for system VM HA test path


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



test/integration/testpaths/testpath_system_vm_ha.py


I feel this step is not related to this test.



test/integration/testpaths/testpath_system_vm_ha.py


how do you make sure that guest  VMs and router VMs are on the same host. 
otherwise, you will not see them migrate to another host.


- SrikanteswaraRao Talluri


On Nov. 3, 2014, 8:51 a.m., Ashutosh Kelkar wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/27321/
> ---
> 
> (Updated Nov. 3, 2014, 8:51 a.m.)
> 
> 
> Review request for cloudstack, suresh sadhu and SrikanteswaraRao Talluri.
> 
> 
> Bugs: CLOUDSTACK-7815
> https://issues.apache.org/jira/browse/CLOUDSTACK-7815
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Convers around 12 scenarios.
> More patches to follow if scenarios are automatable.
> 
> 
> Diffs
> -
> 
>   test/integration/testpaths/testpath_system_vm_ha.py PRE-CREATION 
> 
> Diff: https://reviews.apache.org/r/27321/diff/
> 
> 
> Testing
> ---
> 
> Bring down the host on which SSVM is running ... === TestName: 
> test_01_bring_ssvm_host_down | Status : SUCCESS ===
> ok
> Bring down the host on which CPVM is running ... === TestName: 
> test_02_bring_cpvm_host_down | Status : SUCCESS ===
> ok
> Bring down the host on which router is running ... === TestName: 
> test_03_bring_router_host_down | Status : SUCCESS ===
> ok
> 
> --
> Ran 3 tests in 1137.479s
> 
> OK
> 
> 
> Thanks,
> 
> Ashutosh Kelkar
> 
>

acs 4.3.1 cannot find bridge under KVM advanced zone setup

2014-11-10 Thread Sebastien Goasguen

hi folks,

I am doing a 4.3.1KVM install on one centOS 6.6 host (mgt + agent).

Trying to setup an advanced zone with two bridges

I have two bridges br0 and br1 which have IPs like so:

br0   Link encap:Ethernet  HWaddr 00:00:00:00:00:00  
  inet addr:172.16.0.1  Bcast:172.16.0.255  Mask:255.255.255.0

br1   Link encap:Ethernet  HWaddr 2E:2B:6E:E6:83:35  
  inet addr:172.18.0.1  Bcast:172.18.0.255  Mask:255.255.255.0

br0 used for public and mgmt and br1 for guests.

During the host install, I get this error:

2014-11-10 12:25:53,821 DEBUG [c.c.a.m.AgentManagerImpl] 
(AgentConnectTaskPool-209:ctx-687f8403) Failed to handle host connection: 
com.cloud.exception.ConnectionException: Incorrect Network setup on agent, 
Reinitialize agent after network names are setup, details : Can not find 
network: br1
2014-11-10 12:25:53,821 DEBUG [c.c.a.m.AgentManagerImpl] 
(AgentConnectTaskPool-209:ctx-687f8403) Can not send command 
com.cloud.agent.api.ReadyCommand due to Host 1 is not up

the agent log just shows:

2014-11-10 12:31:22,684 INFO  [cloud.agent.Agent] (Agent-Handler-2:null) 
Reconnecting...
2014-11-10 12:31:22,684 INFO  [utils.nio.NioClient] (Agent-Selector:null) 
Connecting to 172.16.0.1:8250
2014-11-10 12:31:22,766 INFO  [utils.nio.NioClient] (Agent-Selector:null) SSL: 
Handshake done
2014-11-10 12:31:22,766 INFO  [utils.nio.NioClient] (Agent-Selector:null) 
Connected to 172.16.0.1:8250
2014-11-10 12:31:22,886 INFO  [cloud.agent.Agent] (Agent-Handler-2:null) 
Proccess agent startup answer, agent id = 0
2014-11-10 12:31:22,887 INFO  [cloud.agent.Agent] (Agent-Handler-2:null) Set 
agent id 0
2014-11-10 12:31:22,887 INFO  [cloud.agent.Agent] (Agent-Handler-2:null) 
Startup Response Received: agent id = 0
2014-11-10 12:31:22,983 WARN  [cloud.agent.Agent] (Agent-Handler-4:null) Unable 
to send response: null


If I don't specify traffic labels everything more of less works, but with 
traffic labels if fails with this. 

Anybody will have a clue why cloudstack would not be able to recognize the 
bridges ?

-sebastien

Jenkins build is back to normal : cloudstack-4.4-maven-build #487

See

Build failed in Jenkins: cloudstack-4.3-maven-build #621

See 

Changes:

[Rohit Yadav] CLOUDSTACK-7871: allow VM and template details update using 
update APIs

--
Started by an SCM change
Started by an SCM change
[EnvInject] - Loading node environment variables.
Building remotely on cloudstack-buildslave-centos6-87d 
(cloudstack-buildslave-centos6) in workspace 

 > /usr/bin/git rev-parse --is-inside-work-tree # timeout=400
Fetching changes from the remote Git repository
 > /usr/bin/git config remote.origin.url git://git.apache.org/cloudstack.git # 
 > timeout=400
Fetching upstream changes from git://git.apache.org/cloudstack.git
 > /usr/bin/git --version # timeout=400
 > /usr/bin/git fetch --tags --progress git://git.apache.org/cloudstack.git 
 > +refs/heads/*:refs/remotes/origin/*
 > /usr/bin/git rev-parse origin/4.3^{commit} # timeout=400
Checking out Revision c8929dfd10a3c0361dca6fd4bd4ff83010c9bcad (origin/4.3)
 > /usr/bin/git config core.sparsecheckout # timeout=400
 > /usr/bin/git checkout -f c8929dfd10a3c0361dca6fd4bd4ff83010c9bcad
 > /usr/bin/git rev-list 9a4e79990a8a4564102f666b3e4f2bcf84799824 # timeout=400
FATAL: Couldn’t find any executable in /opt/apache-maven-3.0.5
Build step 'Invoke top-level Maven targets' marked build as failure

RE: i18n issues in (master) GUI

2014-11-10 Thread Mihaela Stoica

Hi,

Is anyone still experiencing these issues? If so, and willing to test a fix, 
please let me know and I can provide you with a patch.

Many thanks,
Mihaela

-Original Message-
From: Leo Simons [mailto:lsim...@schubergphilis.com] 
Sent: 15 October 2014 07:58
To: 
Subject: Re: i18n issues in (master) GUI

Yeah I've seen it, though not consistently, so I thought I might have been 
going crazy, or more optimistically that someone has been doing work in that 
area.

Cheers,

Leo

Sent from my iPhone

> On 15 Oct 2014, at 03:43, "Mike Tutkowski"  
> wrote:
> 
> Hi,
> 
> Is anyone else noticing a lot of issues where text is not being found 
> in the applicable properties file and so we end up with text like 
> label.storage, label.volumes, label.upload.volume, etc. in the GUI?
> 
> Thanks,
> 
> --
> *Mike Tutkowski*
> *Senior CloudStack Developer, SolidFire Inc.*
> e: mike.tutkow...@solidfire.com
> o: 303.746.7302
> Advancing the way the world uses the cloud
> *(tm)*

Build failed in Jenkins: cloudstack-4.3-maven-build #622

See 

--
Started by an SCM change
[EnvInject] - Loading node environment variables.
Building remotely on cloudstack-buildslave-centos6-87d 
(cloudstack-buildslave-centos6) in workspace 

 > /usr/bin/git rev-parse --is-inside-work-tree # timeout=400
Fetching changes from the remote Git repository
 > /usr/bin/git config remote.origin.url git://git.apache.org/cloudstack.git # 
 > timeout=400
Fetching upstream changes from git://git.apache.org/cloudstack.git
 > /usr/bin/git --version # timeout=400
 > /usr/bin/git fetch --tags --progress git://git.apache.org/cloudstack.git 
 > +refs/heads/*:refs/remotes/origin/*
 > /usr/bin/git rev-parse origin/4.3^{commit} # timeout=400
Checking out Revision c8929dfd10a3c0361dca6fd4bd4ff83010c9bcad (origin/4.3)
 > /usr/bin/git config core.sparsecheckout # timeout=400
 > /usr/bin/git checkout -f c8929dfd10a3c0361dca6fd4bd4ff83010c9bcad
 > /usr/bin/git rev-list c8929dfd10a3c0361dca6fd4bd4ff83010c9bcad # timeout=400
FATAL: Couldn’t find any executable in /opt/apache-maven-3.0.5
Build step 'Invoke top-level Maven targets' marked build as failure

New Defects reported by Coverity Scan for cloudstack

2014-11-10 Thread scan-admin


Hi,

Please find the latest report on new defect(s) introduced to cloudstack found 
with Coverity Scan.

2 new defect(s) introduced to cloudstack found with Coverity Scan.
16 defect(s), reported by Coverity Scan earlier, were marked fixed in the 
recent build analyzed by Coverity Scan.

New defect(s) Reported-by: Coverity Scan
Showing 2 of 2 defect(s)


** CID 1251370:  REC: RuntimeException capture  (FB.REC_CATCH_EXCEPTION)
/plugins/hypervisors/xenserver/src/com/cloud/hypervisor/xenserver/resource/XenServerStorageProcessor.java:
 1559 in 
com.cloud.hypervisor.xenserver.resource.XenServerStorageProcessor.createTemplateFromSnapshot(org.apache.cloudstack.storage.command.CopyCommand)()

** CID 1251369:  Dereference after null check  (FORWARD_NULL)
/server/src/com/cloud/storage/snapshot/SnapshotManagerImpl.java: 323 in 
com.cloud.storage.snapshot.SnapshotManagerImpl.createSnapshot(java.lang.Long, 
java.lang.Long, java.lang.Long, com.cloud.user.Account)()



*** CID 1251370:  REC: RuntimeException capture  (FB.REC_CATCH_EXCEPTION)
/plugins/hypervisors/xenserver/src/com/cloud/hypervisor/xenserver/resource/XenServerStorageProcessor.java:
 1559 in 
com.cloud.hypervisor.xenserver.resource.XenServerStorageProcessor.createTemplateFromSnapshot(org.apache.cloudstack.storage.command.CopyCommand)()
1553 newTemplate.setPhysicalSize(physicalSize);
1554 newTemplate.setName(templateUuid);
1555 
1556 result = true;
1557 
1558 return new CopyCmdAnswer(newTemplate);
>>> CID 1251370:  REC: RuntimeException capture  (FB.REC_CATCH_EXCEPTION)
>>> Catching RuntimeExceptions, perhaps unintentionally, with a catch block 
>>> for Exception
1559 } catch (Exception ex) {
1560 s_logger.error("Failed to create a template from a 
snapshot", ex);
1561 
1562 return new CopyCmdAnswer("Failed to create a template from 
a snapshot: " + ex.toString());
1563 } finally {
1564 if (!result) {


*** CID 1251369:  Dereference after null check  (FORWARD_NULL)
/server/src/com/cloud/storage/snapshot/SnapshotManagerImpl.java: 323 in 
com.cloud.storage.snapshot.SnapshotManagerImpl.createSnapshot(java.lang.Long, 
java.lang.Long, java.lang.Long, com.cloud.user.Account)()
317 if(snapshot != null)
318 {
319 s_logger.debug("Failed to create snapshot");
320 throw new CloudRuntimeException("Failed to create 
snapshot");
321 }
322 try {
>>> CID 1251369:  Dereference after null check  (FORWARD_NULL)
>>> Calling a method on null object "snapshot".
323 postCreateSnapshot(volumeId, snapshot.getId(), policyId);
324 //Check if the snapshot was removed while backingUp. If 
yes, do not log snapshot create usage event
325 SnapshotVO freshSnapshot = 
_snapshotDao.findById(snapshot.getId());
326 if (freshSnapshot != null)  {
327 
UsageEventUtils.publishUsageEvent(EventTypes.EVENT_SNAPSHOT_CREATE, 
snapshot.getAccountId(), snapshot.getDataCenterId(), snapshotId, 
snapshot.getName(),
328 null, null, volume.getSize(), 
snapshot.getClass().getName(), snapshot.getUuid());



To view the defects in Coverity Scan visit, 
http://scan.coverity.com/projects/943?tab=overview

To unsubscribe from the email notification for new defects, 
http://scan5.coverity.com/cgi-bin/unsubscribe.py

Re: certificate error (was: Build failed in Jenkins: cloudstack-4.4-maven-build #485)

2014-11-10 Thread Pierre-Luc Dion

yes, I don't know why this commit do both but it as been push in master +
4.5.




*Pierre-Luc DION*
Architecte de Solution Cloud | Cloud Solutions Architect
t 855.652.5683

*CloudOps* Votre partenaire infonuagique* | *Cloud Solutions Experts
420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6
w cloudops.com *|* tw @CloudOps_


On Mon, Nov 10, 2014 at 4:22 AM, Daan Hoogland 
wrote:

> On Sun, Nov 9, 2014 at 8:42 PM, Pierre-Luc Dion 
> wrote:
> > 88561e154f6d451d2437e7e6887417df6106c275
>
>
> picked it but... it disables tests and replaces certificates. should
> one of the two be enough?
>
> --
> Daan
>

Re: i18n issues in (master) GUI

I do see this issue still every now and then. Typically I notice it when I
re-compile the codebase and access the GUI for the first time. If I log out
and back in again, the problem goes away.

I can try out your fix.

Thanks!

On Mon, Nov 10, 2014 at 6:15 AM, Mihaela Stoica 
wrote:

> Hi,
>
> Is anyone still experiencing these issues? If so, and willing to test a
> fix, please let me know and I can provide you with a patch.
>
> Many thanks,
> Mihaela
>
> -Original Message-
> From: Leo Simons [mailto:lsim...@schubergphilis.com]
> Sent: 15 October 2014 07:58
> To: 
> Subject: Re: i18n issues in (master) GUI
>
> Yeah I've seen it, though not consistently, so I thought I might have been
> going crazy, or more optimistically that someone has been doing work in
> that area.
>
> Cheers,
>
> Leo
>
> Sent from my iPhone
>
> > On 15 Oct 2014, at 03:43, "Mike Tutkowski" 
> wrote:
> >
> > Hi,
> >
> > Is anyone else noticing a lot of issues where text is not being found
> > in the applicable properties file and so we end up with text like
> > label.storage, label.volumes, label.upload.volume, etc. in the GUI?
> >
> > Thanks,
> >
> > --
> > *Mike Tutkowski*
> > *Senior CloudStack Developer, SolidFire Inc.*
> > e: mike.tutkow...@solidfire.com
> > o: 303.746.7302
> > Advancing the way the world uses the cloud
> > *(tm)*
>



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

RE: Strange if else under LibvirtStorageAdaptor.java[lines 1203-1206]

2014-11-10 Thread Santhosh Edukulla

Wido,

If i get your note, then shall i remove the mentioned if else logic only to one 
liner as below?

newDisk = destPool.createPhysicalDisk(name, Storage.ProvisioningType.THIN, 
disk.getVirtualSize());

Regards,
Santhosh

From: Wido den Hollander [w...@widodh.nl]
Sent: Monday, November 03, 2014 5:27 AM
To: Santhosh Edukulla; dev@cloudstack.apache.org
Cc: shadow...@gmail.com
Subject: Re: Strange if else under LibvirtStorageAdaptor.java[lines 1203-1206]

On 11/03/2014 10:05 AM, Santhosh Edukulla wrote:
> Team,
>
> Either of the paths are doing the same thing for below if else, please check. 
> This is observed under master.
>

I think that is a weird merge thing somewhere. I don't see any reason
why this if statement is there.

Wido

>  if (srcPool.getType() != StoragePoolType.RBD) {
> newDisk = destPool.createPhysicalDisk(name, 
> Storage.ProvisioningType.THIN, disk.getVirtualSize());
> } else {
> newDisk = destPool.createPhysicalDisk(name, 
> Storage.ProvisioningType.THIN, disk.getVirtualSize());
> }
>
> Santhosh
>

Re: Strange if else under LibvirtStorageAdaptor.java[lines 1203-1206]

2014-11-10 Thread Wido den Hollander



On 10-11-14 17:04, Santhosh Edukulla wrote:
> Wido,
> 
> If i get your note, then shall i remove the mentioned if else logic only to 
> one liner as below?
> 
> newDisk = destPool.createPhysicalDisk(name, Storage.ProvisioningType.THIN, 
> disk.getVirtualSize());
> 

Yes, that should be right. The if-statement doesn't actually do anything.

> Regards,
> Santhosh
> 
> From: Wido den Hollander [w...@widodh.nl]
> Sent: Monday, November 03, 2014 5:27 AM
> To: Santhosh Edukulla; dev@cloudstack.apache.org
> Cc: shadow...@gmail.com
> Subject: Re: Strange if else under LibvirtStorageAdaptor.java[lines 1203-1206]
> 
> On 11/03/2014 10:05 AM, Santhosh Edukulla wrote:
>> Team,
>>
>> Either of the paths are doing the same thing for below if else, please 
>> check. This is observed under master.
>>
> 
> I think that is a weird merge thing somewhere. I don't see any reason
> why this if statement is there.
> 
> Wido
> 
>>  if (srcPool.getType() != StoragePoolType.RBD) {
>> newDisk = destPool.createPhysicalDisk(name, 
>> Storage.ProvisioningType.THIN, disk.getVirtualSize());
>> } else {
>> newDisk = destPool.createPhysicalDisk(name, 
>> Storage.ProvisioningType.THIN, disk.getVirtualSize());
>> }
>>
>> Santhosh
>>
>

RE: i18n issues in (master) GUI

2014-11-10 Thread Mihaela Stoica

Mike,

Thank you for offering to try out my fix.
I will email you directly the patched files.

Thanks,
Mihaela

-Original Message-
From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com] 
Sent: 10 November 2014 15:46
To: dev@cloudstack.apache.org
Subject: Re: i18n issues in (master) GUI

I do see this issue still every now and then. Typically I notice it when I 
re-compile the codebase and access the GUI for the first time. If I log out and 
back in again, the problem goes away.

I can try out your fix.

Thanks!

On Mon, Nov 10, 2014 at 6:15 AM, Mihaela Stoica 
wrote:

> Hi,
>
> Is anyone still experiencing these issues? If so, and willing to test 
> a fix, please let me know and I can provide you with a patch.
>
> Many thanks,
> Mihaela
>
> -Original Message-
> From: Leo Simons [mailto:lsim...@schubergphilis.com]
> Sent: 15 October 2014 07:58
> To: 
> Subject: Re: i18n issues in (master) GUI
>
> Yeah I've seen it, though not consistently, so I thought I might have 
> been going crazy, or more optimistically that someone has been doing 
> work in that area.
>
> Cheers,
>
> Leo
>
> Sent from my iPhone
>
> > On 15 Oct 2014, at 03:43, "Mike Tutkowski" 
> > 
> wrote:
> >
> > Hi,
> >
> > Is anyone else noticing a lot of issues where text is not being 
> > found in the applicable properties file and so we end up with text 
> > like label.storage, label.volumes, label.upload.volume, etc. in the GUI?
> >
> > Thanks,
> >
> > --
> > *Mike Tutkowski*
> > *Senior CloudStack Developer, SolidFire Inc.*
> > e: mike.tutkow...@solidfire.com
> > o: 303.746.7302
> > Advancing the way the world uses the cloud
> > *(tm)*
>



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

UI: "CPU (in MHz)" doesn't make sense

2014-11-10 Thread Nux!

Hi,

Basically I'm annoyed with the "CPU (in MHz)" usage in service offerings as 
they are a lie basically.
Opened https://issues.apache.org/jira/browse/CLOUDSTACK-7874 and suggest to 
have calculated automatically based on CPU cores number or at least having it 
renamed to something like "cpu weight".
MHz means nothing.

Thoughts?

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

Re: UI: "CPU (in MHz)" doesn't make sense

2014-11-10 Thread Logan Barfield

I agree completely.  We've set all of our service offerings to equal
weights, and hard coded the same weight into the custom offering form.
It's a bit too confusing otherwise.

The way I understand the weights for (Xen/KVM at least) is that they're
just relative, so 1 vs 2 is the same as 1 vs 1000.  That being the case I'd
suggest a solution that has worked for us in the past: set the weight equal
to the memory amount (in MB).

Thoughts?

Thank You,

Logan Barfield
Tranquil Hosting

On Mon, Nov 10, 2014 at 11:17 AM, Nux!  wrote:

> Hi,
>
> Basically I'm annoyed with the "CPU (in MHz)" usage in service offerings
> as they are a lie basically.
> Opened https://issues.apache.org/jira/browse/CLOUDSTACK-7874 and suggest
> to have calculated automatically based on CPU cores number or at least
> having it renamed to something like "cpu weight".
> MHz means nothing.
>
> Thoughts?
>
> --
> Sent from the Delta quadrant using Borg technology!
>
> Nux!
> www.nux.ro
>

RE: Patched 4.3.1 SystemVMs (was Re: git commit: updated refs/heads/master to 88acc9b)

2014-11-10 Thread Santhosh Edukulla

Rohit,

1. Regarding the below note, you can decided on that, but removing or not is 
not related to this fix though.

2. Check the below link for other areas in code that need to be fixed as part 
of poodle issue fix.

http://security.coverity.com/blog.html

Regards,
Santhosh

From: Rohit Yadav [rohit.ya...@shapeblue.com]
Sent: Tuesday, November 04, 2014 10:44 AM
To: dev@cloudstack.apache.org
Subject: Re: Patched 4.3.1 SystemVMs (was Re: git commit: updated 
refs/heads/master to 88acc9b)

IMO - Let’s remove httpd.conf, it’s not used anywhere; if people want they can 
add it later down the lane.

> On 04-Nov-2014, at 8:43 pm, Santhosh Edukulla  
> wrote:
>
> Rohit,
>
> The recent fix can solve the issue, but instead if we can use apache2.conf 
> for these directives and remove them from http2.conf and ssl.conf, it makes 
> usage at one place and avoids usage at different places.
>
> As well, if some body downs the lane includes httpd.conf under apache2.conf, 
> then these references can lead to confusion.
>
> Santhosh
> 
> From: Rohit Yadav [rohit.ya...@shapeblue.com]
> Sent: Tuesday, November 04, 2014 4:28 AM
> To: dev@cloudstack.apache.org
> Subject: Re: Patched 4.3.1 SystemVMs (was Re: git commit: updated 
> refs/heads/master to 88acc9b)
>
> - user-ML
>
>> On 04-Nov-2014, at 2:52 pm, Santhosh Edukulla  
>> wrote:
>>
>> There we mentioned to support only TLS1...etc through + logic
>
> I checked again, where and how is httpd.conf used?
>
> I think this file that is no longer used. I think very old systemvms were 
> build using a base (CentOS?) linux which used the old buildsystemvm.sh 
> script, the build scripts that we use now (that uses 
> VirtualBox+vagrant/veewee) is the one that I made using Debian as the base 
> distro two years ago and in that we install apache2.conf. So, if there is any 
> file needed there it should be a fixed version of apache2.conf and not 
> httpd.conf
>
> Regards,
> Rohit Yadav
> Software Architect, ShapeBlue
> M. +91 88 262 30892 | rohit.ya...@shapeblue.com
> Blog: bhaisaab.org | Twitter: @_bhaisaab
>
>
>
> Find out more about ShapeBlue and our range of CloudStack related services
>
> IaaS Cloud Design & Build
> CSForge – rapid IaaS deployment framework
> CloudStack Consulting
> CloudStack Infrastructure 
> Support
> CloudStack Bootcamp Training 
> Courses
>
> This email and any attachments to it may be confidential and are intended 
> solely for the use of the individual to whom it is addressed. Any views or 
> opinions expressed are solely those of the author and do not necessarily 
> represent those of Shape Blue Ltd or related companies. If you are not the 
> intended recipient of this email, you must neither take any action based upon 
> its contents, nor copy or show it to anyone. Please contact the sender if you 
> believe you have received this email in error. Shape Blue Ltd is a company 
> incorporated in England & Wales. ShapeBlue Services India LLP is a company 
> incorporated in India and is operated under license from Shape Blue Ltd. 
> Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is 
> operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is a company 
> registered by The Republic of South Africa and is traded under license from 
> Shape Blue Ltd. ShapeBlue is a registered trademark.

Regards,
Rohit Yadav
Software Architect, ShapeBlue
M. +91 88 262 30892 | rohit.ya...@shapeblue.com
Blog: bhaisaab.org | Twitter: @_bhaisaab



Find out more about ShapeBlue and our range of CloudStack related services

IaaS Cloud Design & Build
CSForge – rapid IaaS deployment framework
CloudStack Consulting
CloudStack Infrastructure 
Support
CloudStack Bootcamp Training Courses

This email and any attachments to it may be confidential and are intended 
solely for the use of the individual to whom it is addressed. Any views or 
opinions expressed are solely those of the author and do not necessarily 
represent those of Shape Blue Ltd or related companies. If you are not the 
intended recipient of this email, you must neither take any action based upon 
its contents, nor copy or show it to anyone. Please contact the sender if you 
believe you have received this email in error. Shape Blue Ltd is a company 
incorporated in England & Wales. ShapeBlue Services India LLP is a company 
incorporated in India and is operated under license from Shape Blue Ltd. Shape 
Blue Brasil Consultoria Ltda is a company incorporated i

RE: UI: "CPU (in MHz)" doesn't make sense

2014-11-10 Thread Stephen Turner

Certainly it's wrong at the moment, because XenServer doesn't allow you to 
change the MHz of the CPU of a VM. Can someone find out which XenServer API 
calls it actually makes? Then we can work out how to describe it.

-- 
Stephen Turner

-Original Message-
From: Logan Barfield [mailto:lbarfi...@tqhosting.com] 
Sent: 10 November 2014 16:24
To: dev@cloudstack.apache.org
Subject: Re: UI: "CPU (in MHz)" doesn't make sense

I agree completely.  We've set all of our service offerings to equal weights, 
and hard coded the same weight into the custom offering form.
It's a bit too confusing otherwise.

The way I understand the weights for (Xen/KVM at least) is that they're just 
relative, so 1 vs 2 is the same as 1 vs 1000.  That being the case I'd suggest 
a solution that has worked for us in the past: set the weight equal to the 
memory amount (in MB).

Thoughts?

Thank You,

Logan Barfield
Tranquil Hosting

On Mon, Nov 10, 2014 at 11:17 AM, Nux!  wrote:

> Hi,
>
> Basically I'm annoyed with the "CPU (in MHz)" usage in service 
> offerings as they are a lie basically.
> Opened https://issues.apache.org/jira/browse/CLOUDSTACK-7874 and 
> suggest to have calculated automatically based on CPU cores number or 
> at least having it renamed to something like "cpu weight".
> MHz means nothing.
>
> Thoughts?
>
> --
> Sent from the Delta quadrant using Borg technology!
>
> Nux!
> www.nux.ro
>

Re: UI: "CPU (in MHz)" doesn't make sense

2014-11-10 Thread Nux!

I am not entirely sure if 1 vs 2 = 1 vs 1000. It might be that the one with 
1000 will get 1000 more prio to CPU compared to the one with 1. This needs to 
be clarified per each hypervisor.

Lucian

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

- Original Message -
> From: "Logan Barfield" 
> To: dev@cloudstack.apache.org
> Sent: Monday, 10 November, 2014 16:23:41
> Subject: Re: UI: "CPU (in MHz)" doesn't make sense

> I agree completely.  We've set all of our service offerings to equal
> weights, and hard coded the same weight into the custom offering form.
> It's a bit too confusing otherwise.
> 
> The way I understand the weights for (Xen/KVM at least) is that they're
> just relative, so 1 vs 2 is the same as 1 vs 1000.  That being the case I'd
> suggest a solution that has worked for us in the past: set the weight equal
> to the memory amount (in MB).
> 
> Thoughts?
> 
> 
> Thank You,
> 
> Logan Barfield
> Tranquil Hosting
> 
> On Mon, Nov 10, 2014 at 11:17 AM, Nux!  wrote:
> 
>> Hi,
>>
>> Basically I'm annoyed with the "CPU (in MHz)" usage in service offerings
>> as they are a lie basically.
>> Opened https://issues.apache.org/jira/browse/CLOUDSTACK-7874 and suggest
>> to have calculated automatically based on CPU cores number or at least
>> having it renamed to something like "cpu weight".
>> MHz means nothing.
>>
>> Thoughts?
>>
>> --
>> Sent from the Delta quadrant using Borg technology!
>>
>> Nux!
>> www.nux.ro

Re: UI: "CPU (in MHz)" doesn't make sense

2014-11-10 Thread Logan Barfield

That was definitely only an assumption.  If each host handles it different
it may be preferable to hard code a "Default" level for each hypervisor
type, as well as a few different levels (e.g., 'Max', 'High', 'Default',
'Low', 'Min' & 'Custom').  This would operators & end-users clear options
to work with, while retaining the flexibility of a custom option.


Thank You,

Logan Barfield
Tranquil Hosting

On Mon, Nov 10, 2014 at 11:46 AM, Nux!  wrote:

> I am not entirely sure if 1 vs 2 = 1 vs 1000. It might be that the one
> with 1000 will get 1000 more prio to CPU compared to the one with 1. This
> needs to be clarified per each hypervisor.
>
> Lucian
>
> --
> Sent from the Delta quadrant using Borg technology!
>
> Nux!
> www.nux.ro
>
> - Original Message -
> > From: "Logan Barfield" 
> > To: dev@cloudstack.apache.org
> > Sent: Monday, 10 November, 2014 16:23:41
> > Subject: Re: UI: "CPU (in MHz)" doesn't make sense
>
> > I agree completely.  We've set all of our service offerings to equal
> > weights, and hard coded the same weight into the custom offering form.
> > It's a bit too confusing otherwise.
> >
> > The way I understand the weights for (Xen/KVM at least) is that they're
> > just relative, so 1 vs 2 is the same as 1 vs 1000.  That being the case
> I'd
> > suggest a solution that has worked for us in the past: set the weight
> equal
> > to the memory amount (in MB).
> >
> > Thoughts?
> >
> >
> > Thank You,
> >
> > Logan Barfield
> > Tranquil Hosting
> >
> > On Mon, Nov 10, 2014 at 11:17 AM, Nux!  wrote:
> >
> >> Hi,
> >>
> >> Basically I'm annoyed with the "CPU (in MHz)" usage in service offerings
> >> as they are a lie basically.
> >> Opened https://issues.apache.org/jira/browse/CLOUDSTACK-7874 and
> suggest
> >> to have calculated automatically based on CPU cores number or at least
> >> having it renamed to something like "cpu weight".
> >> MHz means nothing.
> >>
> >> Thoughts?
> >>
> >> --
> >> Sent from the Delta quadrant using Borg technology!
> >>
> >> Nux!
> >> www.nux.ro
>

Re: UI: "CPU (in MHz)" doesn't make sense

2014-11-10 Thread Nux!

Personally, I'd propose the defaults should be values proportional or equal to 
the cores number (that's how openstack does it).

Anyway, all this doesn't matter as long as no developer is listening. :-)

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

- Original Message -
> From: "Logan Barfield" 
> To: dev@cloudstack.apache.org
> Sent: Monday, 10 November, 2014 17:49:15
> Subject: Re: UI: "CPU (in MHz)" doesn't make sense

> That was definitely only an assumption.  If each host handles it different
> it may be preferable to hard code a "Default" level for each hypervisor
> type, as well as a few different levels (e.g., 'Max', 'High', 'Default',
> 'Low', 'Min' & 'Custom').  This would operators & end-users clear options
> to work with, while retaining the flexibility of a custom option.
> 
> 
> Thank You,
> 
> Logan Barfield
> Tranquil Hosting
> 
> On Mon, Nov 10, 2014 at 11:46 AM, Nux!  wrote:
> 
>> I am not entirely sure if 1 vs 2 = 1 vs 1000. It might be that the one
>> with 1000 will get 1000 more prio to CPU compared to the one with 1. This
>> needs to be clarified per each hypervisor.
>>
>> Lucian
>>
>> --
>> Sent from the Delta quadrant using Borg technology!
>>
>> Nux!
>> www.nux.ro
>>
>> - Original Message -
>> > From: "Logan Barfield" 
>> > To: dev@cloudstack.apache.org
>> > Sent: Monday, 10 November, 2014 16:23:41
>> > Subject: Re: UI: "CPU (in MHz)" doesn't make sense
>>
>> > I agree completely.  We've set all of our service offerings to equal
>> > weights, and hard coded the same weight into the custom offering form.
>> > It's a bit too confusing otherwise.
>> >
>> > The way I understand the weights for (Xen/KVM at least) is that they're
>> > just relative, so 1 vs 2 is the same as 1 vs 1000.  That being the case
>> I'd
>> > suggest a solution that has worked for us in the past: set the weight
>> equal
>> > to the memory amount (in MB).
>> >
>> > Thoughts?
>> >
>> >
>> > Thank You,
>> >
>> > Logan Barfield
>> > Tranquil Hosting
>> >
>> > On Mon, Nov 10, 2014 at 11:17 AM, Nux!  wrote:
>> >
>> >> Hi,
>> >>
>> >> Basically I'm annoyed with the "CPU (in MHz)" usage in service offerings
>> >> as they are a lie basically.
>> >> Opened https://issues.apache.org/jira/browse/CLOUDSTACK-7874 and
>> suggest
>> >> to have calculated automatically based on CPU cores number or at least
>> >> having it renamed to something like "cpu weight".
>> >> MHz means nothing.
>> >>
>> >> Thoughts?
>> >>
>> >> --
>> >> Sent from the Delta quadrant using Borg technology!
>> >>
>> >> Nux!
>> >> www.nux.ro

Re: UI: "CPU (in MHz)" doesn't make sense

2014-11-10 Thread Marcus

I can't speak for all hypervisors, but with KVM, it takes the hypervisor
CPU MHz * cores and treats that as 'capacity' of the hypervisor. This
translates directly to the number used for cgroups cpu shares. So a 2GHz
quad core would have 8000 "MHz" worth of vms allocated to it  (ignoring
overprovisioning).

On Mon, Nov 10, 2014 at 9:58 AM, Nux!  wrote:

> Personally, I'd propose the defaults should be values proportional or
> equal to the cores number (that's how openstack does it).
>
> Anyway, all this doesn't matter as long as no developer is listening. :-)
>
> --
> Sent from the Delta quadrant using Borg technology!
>
> Nux!
> www.nux.ro
>
> - Original Message -
> > From: "Logan Barfield" 
> > To: dev@cloudstack.apache.org
> > Sent: Monday, 10 November, 2014 17:49:15
> > Subject: Re: UI: "CPU (in MHz)" doesn't make sense
>
> > That was definitely only an assumption.  If each host handles it
> different
> > it may be preferable to hard code a "Default" level for each hypervisor
> > type, as well as a few different levels (e.g., 'Max', 'High', 'Default',
> > 'Low', 'Min' & 'Custom').  This would operators & end-users clear options
> > to work with, while retaining the flexibility of a custom option.
> >
> >
> > Thank You,
> >
> > Logan Barfield
> > Tranquil Hosting
> >
> > On Mon, Nov 10, 2014 at 11:46 AM, Nux!  wrote:
> >
> >> I am not entirely sure if 1 vs 2 = 1 vs 1000. It might be that the one
> >> with 1000 will get 1000 more prio to CPU compared to the one with 1.
> This
> >> needs to be clarified per each hypervisor.
> >>
> >> Lucian
> >>
> >> --
> >> Sent from the Delta quadrant using Borg technology!
> >>
> >> Nux!
> >> www.nux.ro
> >>
> >> - Original Message -
> >> > From: "Logan Barfield" 
> >> > To: dev@cloudstack.apache.org
> >> > Sent: Monday, 10 November, 2014 16:23:41
> >> > Subject: Re: UI: "CPU (in MHz)" doesn't make sense
> >>
> >> > I agree completely.  We've set all of our service offerings to equal
> >> > weights, and hard coded the same weight into the custom offering form.
> >> > It's a bit too confusing otherwise.
> >> >
> >> > The way I understand the weights for (Xen/KVM at least) is that
> they're
> >> > just relative, so 1 vs 2 is the same as 1 vs 1000.  That being the
> case
> >> I'd
> >> > suggest a solution that has worked for us in the past: set the weight
> >> equal
> >> > to the memory amount (in MB).
> >> >
> >> > Thoughts?
> >> >
> >> >
> >> > Thank You,
> >> >
> >> > Logan Barfield
> >> > Tranquil Hosting
> >> >
> >> > On Mon, Nov 10, 2014 at 11:17 AM, Nux!  wrote:
> >> >
> >> >> Hi,
> >> >>
> >> >> Basically I'm annoyed with the "CPU (in MHz)" usage in service
> offerings
> >> >> as they are a lie basically.
> >> >> Opened https://issues.apache.org/jira/browse/CLOUDSTACK-7874 and
> >> suggest
> >> >> to have calculated automatically based on CPU cores number or at
> least
> >> >> having it renamed to something like "cpu weight".
> >> >> MHz means nothing.
> >> >>
> >> >> Thoughts?
> >> >>
> >> >> --
> >> >> Sent from the Delta quadrant using Borg technology!
> >> >>
> >> >> Nux!
> >> >> www.nux.ro
>

Re: Patched 4.3.1 SystemVMs (was Re: git commit: updated refs/heads/master to 88acc9b)

2014-11-10 Thread Rohit Yadav

Santhosh,

Please go ahead with any better fix you think would work on any/all of the 
affected (release) branches.

> On 10-Nov-2014, at 9:53 pm, Santhosh Edukulla  
> wrote:
>
> Rohit,
>
> 1. Regarding the below note, you can decided on that, but removing or not is 
> not related to this fix though.
>
> 2. Check the below link for other areas in code that need to be fixed as part 
> of poodle issue fix.
>
> http://security.coverity.com/blog.html
>
> Regards,
> Santhosh
> 
> From: Rohit Yadav [rohit.ya...@shapeblue.com]
> Sent: Tuesday, November 04, 2014 10:44 AM
> To: dev@cloudstack.apache.org
> Subject: Re: Patched 4.3.1 SystemVMs (was Re: git commit: updated 
> refs/heads/master to 88acc9b)
>
> IMO - Let’s remove httpd.conf, it’s not used anywhere; if people want they 
> can add it later down the lane.
>
>> On 04-Nov-2014, at 8:43 pm, Santhosh Edukulla  
>> wrote:
>>
>> Rohit,
>>
>> The recent fix can solve the issue, but instead if we can use apache2.conf 
>> for these directives and remove them from http2.conf and ssl.conf, it makes 
>> usage at one place and avoids usage at different places.
>>
>> As well, if some body downs the lane includes httpd.conf under apache2.conf, 
>> then these references can lead to confusion.
>>
>> Santhosh
>> 
>> From: Rohit Yadav [rohit.ya...@shapeblue.com]
>> Sent: Tuesday, November 04, 2014 4:28 AM
>> To: dev@cloudstack.apache.org
>> Subject: Re: Patched 4.3.1 SystemVMs (was Re: git commit: updated 
>> refs/heads/master to 88acc9b)
>>
>> - user-ML
>>
>>> On 04-Nov-2014, at 2:52 pm, Santhosh Edukulla 
>>>  wrote:
>>>
>>> There we mentioned to support only TLS1...etc through + logic
>>
>> I checked again, where and how is httpd.conf used?
>>
>> I think this file that is no longer used. I think very old systemvms were 
>> build using a base (CentOS?) linux which used the old buildsystemvm.sh 
>> script, the build scripts that we use now (that uses 
>> VirtualBox+vagrant/veewee) is the one that I made using Debian as the base 
>> distro two years ago and in that we install apache2.conf. So, if there is 
>> any file needed there it should be a fixed version of apache2.conf and not 
>> httpd.conf
>>
>> Regards,
>> Rohit Yadav
>> Software Architect, ShapeBlue
>> M. +91 88 262 30892 | rohit.ya...@shapeblue.com
>> Blog: bhaisaab.org | Twitter: @_bhaisaab
>>
>>
>>
>> Find out more about ShapeBlue and our range of CloudStack related services
>>
>> IaaS Cloud Design & Build
>> CSForge – rapid IaaS deployment framework
>> CloudStack Consulting
>> CloudStack Infrastructure 
>> Support
>> CloudStack Bootcamp Training 
>> Courses
>>
>> This email and any attachments to it may be confidential and are intended 
>> solely for the use of the individual to whom it is addressed. Any views or 
>> opinions expressed are solely those of the author and do not necessarily 
>> represent those of Shape Blue Ltd or related companies. If you are not the 
>> intended recipient of this email, you must neither take any action based 
>> upon its contents, nor copy or show it to anyone. Please contact the sender 
>> if you believe you have received this email in error. Shape Blue Ltd is a 
>> company incorporated in England & Wales. ShapeBlue Services India LLP is a 
>> company incorporated in India and is operated under license from Shape Blue 
>> Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil 
>> and is operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is a 
>> company registered by The Republic of South Africa and is traded under 
>> license from Shape Blue Ltd. ShapeBlue is a registered trademark.
>
> Regards,
> Rohit Yadav
> Software Architect, ShapeBlue
> M. +91 88 262 30892 | rohit.ya...@shapeblue.com
> Blog: bhaisaab.org | Twitter: @_bhaisaab
>
>
>
> Find out more about ShapeBlue and our range of CloudStack related services
>
> IaaS Cloud Design & Build
> CSForge – rapid IaaS deployment framework
> CloudStack Consulting
> CloudStack Infrastructure 
> Support
> CloudStack Bootcamp Training 
> Courses
>
> This email and any attachments to it may be confidential and are intended 
> solely for the use of the individual to whom it is addressed. Any views or 
> opinions expressed are solely those of the author and do not necessarily 
> represent those of Shape Blue Ltd or related companies. If you are not the 
> intended recipient of this email, you must neither take any action based upon 
> its contents, nor copy or show it to a

Re: UI: "CPU (in MHz)" doesn't make sense

2014-11-10 Thread Logan Barfield

That option would probably work too.  I do think that it should have a
custom option though.  No changes should be implemented that could
potentially mess with current production environments, so leaving a custom
option in for operators that are already using it should prevent that.




Thank You,

Logan Barfield
Tranquil Hosting

On Mon, Nov 10, 2014 at 12:58 PM, Nux!  wrote:

> Personally, I'd propose the defaults should be values proportional or
> equal to the cores number (that's how openstack does it).
>
> Anyway, all this doesn't matter as long as no developer is listening. :-)
>
> --
> Sent from the Delta quadrant using Borg technology!
>
> Nux!
> www.nux.ro
>
> - Original Message -
> > From: "Logan Barfield" 
> > To: dev@cloudstack.apache.org
> > Sent: Monday, 10 November, 2014 17:49:15
> > Subject: Re: UI: "CPU (in MHz)" doesn't make sense
>
> > That was definitely only an assumption.  If each host handles it
> different
> > it may be preferable to hard code a "Default" level for each hypervisor
> > type, as well as a few different levels (e.g., 'Max', 'High', 'Default',
> > 'Low', 'Min' & 'Custom').  This would operators & end-users clear options
> > to work with, while retaining the flexibility of a custom option.
> >
> >
> > Thank You,
> >
> > Logan Barfield
> > Tranquil Hosting
> >
> > On Mon, Nov 10, 2014 at 11:46 AM, Nux!  wrote:
> >
> >> I am not entirely sure if 1 vs 2 = 1 vs 1000. It might be that the one
> >> with 1000 will get 1000 more prio to CPU compared to the one with 1.
> This
> >> needs to be clarified per each hypervisor.
> >>
> >> Lucian
> >>
> >> --
> >> Sent from the Delta quadrant using Borg technology!
> >>
> >> Nux!
> >> www.nux.ro
> >>
> >> - Original Message -
> >> > From: "Logan Barfield" 
> >> > To: dev@cloudstack.apache.org
> >> > Sent: Monday, 10 November, 2014 16:23:41
> >> > Subject: Re: UI: "CPU (in MHz)" doesn't make sense
> >>
> >> > I agree completely.  We've set all of our service offerings to equal
> >> > weights, and hard coded the same weight into the custom offering form.
> >> > It's a bit too confusing otherwise.
> >> >
> >> > The way I understand the weights for (Xen/KVM at least) is that
> they're
> >> > just relative, so 1 vs 2 is the same as 1 vs 1000.  That being the
> case
> >> I'd
> >> > suggest a solution that has worked for us in the past: set the weight
> >> equal
> >> > to the memory amount (in MB).
> >> >
> >> > Thoughts?
> >> >
> >> >
> >> > Thank You,
> >> >
> >> > Logan Barfield
> >> > Tranquil Hosting
> >> >
> >> > On Mon, Nov 10, 2014 at 11:17 AM, Nux!  wrote:
> >> >
> >> >> Hi,
> >> >>
> >> >> Basically I'm annoyed with the "CPU (in MHz)" usage in service
> offerings
> >> >> as they are a lie basically.
> >> >> Opened https://issues.apache.org/jira/browse/CLOUDSTACK-7874 and
> >> suggest
> >> >> to have calculated automatically based on CPU cores number or at
> least
> >> >> having it renamed to something like "cpu weight".
> >> >> MHz means nothing.
> >> >>
> >> >> Thoughts?
> >> >>
> >> >> --
> >> >> Sent from the Delta quadrant using Borg technology!
> >> >>
> >> >> Nux!
> >> >> www.nux.ro
>

Re: Review Request 24991: CLOUDSTACK-6697: BigSwitchVns plugin update

2014-11-10 Thread Kuang-Ching Wang


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

(Updated Nov. 10, 2014, 7:23 p.m.)


Review request for cloudstack, Chiradeep Vittal, David Nalley, Sebastien 
Goasguen, and Hugo Trippaers.


Repository: cloudstack-git


Description (updated)
---

CLOUDSTACK-6697: Big Switch network plugin update
1. provide compatibility with the Big Cloud Fabric (BCF) controller
   L2 Connectivity Service in both VPC and non-VPC modes
2. virtual network terminology updates: VNS --> BCF_SEGMENT
3. uses HTTPS with sticky/trust-always certificate handling
4. topology sync support with BCF controller
5. support multiple BCF controllers


Diffs (updated)
-

  api/src/com/cloud/network/Network.java 
c5a9bf286df8d502a6ca33661fb52ee717643566 
  api/src/com/cloud/network/PhysicalNetwork.java 
7c9349d932771fdbecc4a0b1ae4cad28b3d67857 
  client/WEB-INF/classes/resources/messages.properties 
6aeeb66da79693eb5af41cd3a681d52198cc4e77 
  client/WEB-INF/classes/resources/messages_fr_FR.properties 
004187f69b4f8449c88214ff3b047ef603ad65dc 
  client/WEB-INF/classes/resources/messages_ja_JP.properties 
7bc90b538a4f8160e74b72720bc83a776d244b75 
  client/WEB-INF/classes/resources/messages_ko_KR.properties 
ce79d2e5b27d861960c8ee1fd4b1e099ed883ef3 
  client/WEB-INF/classes/resources/messages_nl_NL.properties 
89ef828a3c157228680b90adbcb76b182f342638 
  client/WEB-INF/classes/resources/messages_pt_BR.properties 
8ee08ba3cbbfa3285b7ad728b8b119ee9e379c65 
  client/WEB-INF/classes/resources/messages_ru_RU.properties 
ff68668e6ff75546236a11d29e37d8d4ad1f58f1 
  client/WEB-INF/classes/resources/messages_zh_CN.properties 
ebba5e0bb07a992ee55eb2ab8e71a11073064cfe 
  client/pom.xml 6803f9a11fd2c80523ea16bdd35f2a4d163f953c 
  client/tomcatconf/commands.properties.in 
ce84e69710910834aab5bbf3597760996a341798 
  engine/schema/src/com/cloud/user/dao/VmDiskStatisticsDaoImpl.java 
e1136d3cf567b73fd1198181aea4d6995df6b78a 
  plugins/network-elements/bigswitch-vns/pom.xml 
afb267cdb5bc52aea23bc6739ea21d8f52e94ede 
  
plugins/network-elements/bigswitch-vns/resources/META-INF/cloudstack/vns/module.properties
 5783d38e5cb78be0d418c80981246d721d18b62a 
  
plugins/network-elements/bigswitch-vns/resources/META-INF/cloudstack/vns/spring-vns-context.xml
 d5bb92afe3d3051dbdd4b4d49698c313c77d255f 
  
plugins/network-elements/bigswitch-vns/src/com/cloud/agent/api/CreateVnsNetworkAnswer.java
 e950abe3bed85b75a20be2b8c4537a2fbd6be39e 
  
plugins/network-elements/bigswitch-vns/src/com/cloud/agent/api/CreateVnsNetworkCommand.java
 534bb7f9f9154a652a20310fe020bddc4249ef54 
  
plugins/network-elements/bigswitch-vns/src/com/cloud/agent/api/CreateVnsPortAnswer.java
 82c2fe90d63e0148bca8de9ce8612e4dd53cf735 
  
plugins/network-elements/bigswitch-vns/src/com/cloud/agent/api/CreateVnsPortCommand.java
 c3b9a9d6d9504e34cbe1294ac640f56aab101395 
  
plugins/network-elements/bigswitch-vns/src/com/cloud/agent/api/DeleteVnsNetworkAnswer.java
 72ac98ac9e0a1ae4858019e3baccc160300e24bf 
  
plugins/network-elements/bigswitch-vns/src/com/cloud/agent/api/DeleteVnsNetworkCommand.java
 6cf169bbfc97b57561af729aef297c76230fd118 
  
plugins/network-elements/bigswitch-vns/src/com/cloud/agent/api/DeleteVnsPortAnswer.java
 076b187fdf48cf776902dc9a91dc26e00396158a 
  
plugins/network-elements/bigswitch-vns/src/com/cloud/agent/api/DeleteVnsPortCommand.java
 0cae01d471dd9c5c504002c24f865ded59812d9e 
  
plugins/network-elements/bigswitch-vns/src/com/cloud/agent/api/StartupBigSwitchVnsCommand.java
 8310b0763708c3f049ef4ce427d09f0c07cd05b3 
  
plugins/network-elements/bigswitch-vns/src/com/cloud/agent/api/UpdateVnsPortAnswer.java
 39cd26649c9bb0c4993f55bef65edfc326c4ceda 
  
plugins/network-elements/bigswitch-vns/src/com/cloud/agent/api/UpdateVnsPortCommand.java
 40f09207606115a5d0ec7f9378c4c52d16405dfd 
  
plugins/network-elements/bigswitch-vns/src/com/cloud/api/commands/AddBigSwitchVnsDeviceCmd.java
 5c6f555c8a40a4b785aed6fdfa743131006be209 
  
plugins/network-elements/bigswitch-vns/src/com/cloud/api/commands/DeleteBigSwitchVnsDeviceCmd.java
 1e2155dcd899bc11f9e9463cec432c020751e905 
  
plugins/network-elements/bigswitch-vns/src/com/cloud/api/commands/ListBigSwitchVnsDevicesCmd.java
 4cde78e503935f7ba3b4a90a6f4568f0dd32c7ab 
  
plugins/network-elements/bigswitch-vns/src/com/cloud/api/commands/VnsConstants.java
 7942b6f2be3467465334b0628577b87564dbdab2 
  
plugins/network-elements/bigswitch-vns/src/com/cloud/api/response/BigSwitchVnsDeviceResponse.java
 790ac9c6afbee9156cb8d26ee2a2b5980fe4ce18 
  
plugins/network-elements/bigswitch-vns/src/com/cloud/network/BigSwitchVnsDeviceVO.java
 01b5d49a90bb4428716d6b9c344d4ccfc97fb34f 
  
plugins/network-elements/bigswitch-vns/src/com/cloud/network/bigswitch/AttachmentData.java
 f1866e2621b6f9c19e4a9be310791b086ce3a350 
  
plugins/network-elements/bigswitch-vns/src/com/cloud/network/bigswitch/B

Re: Creating a backup of a hypervisor snapshot

So, interesting, I'm now using XenServer 6.2 (with the patches that
CloudStack ends up calling XenServer 6.2.5).

When I created a second snapshot/backup of my volume, another hypervisor
snapshot was created and the data contained in the second hypervisor
snapshot was copied to secondary storage (all as expected).

At this point, CloudStack was, in fact, successful at deleting the original
hypervisor snapshot (this was not the case when I was testing this on
XenServer 6.1, if I recall).

However, when I later deleted the volume, I noticed that the one hypervisor
snapshot on primary storage remained there. I was expecting it to either be
deleted immediately or be deleted in the background (it's been a day or so
and that old hypervisor snapshot for the deleted volume remains on primary
storage).

Does anyone know off hand if the deletion of this hypervisor snapshot is
supposed to happen right away or in the background?

Thanks!

On Fri, Nov 7, 2014 at 10:47 AM, Mike Tutkowski <
mike.tutkow...@solidfire.com> wrote:

> Let me look into this again. At the time, I was busy implementing some
> other functionality when I came across what seemed like an existing issue
> in our code.
>
> It is odd to me that old (hypervisor) snapshots never get deleted and the
> code I copy/pasted in has the purpose of deleting those old snapshots, but
> it never seems to work that way.
>
> On Fri, Nov 7, 2014 at 10:20 AM, Stephen Turner  > wrote:
>
>> Mike, are you saying that XenCenter disagrees with xe? That doesn't seem
>> right as they both get their info from the same API. Maybe XenCenter is
>> looking at something subtly different.
>>
>> XenCenter is open source (https://github.com/xenserver/xenadmin), so you
>> can consult the source to see what it's reporting. Or send a screenshot of
>> what you're looking at and I can find the correct bit of source.
>>
>> --
>> Stephen Turner
>>
>>
>> -Original Message-
>> From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com]
>> Sent: 04 November 2014 17:28
>> To: dev@cloudstack.apache.org; Edison Su
>> Subject: Creating a backup of a hypervisor snapshot
>>
>> Hi,
>>
>> The standard behavior when we take a snapshot of a volume on XenServer is
>> to take a hypervisor snapshot of the volume and then copy this snapshot to
>> secondary storage.
>>
>> We then try to delete all other hypervisor snapshots for this volume.
>>
>> I notice the process of deleting all other hypervisor snapshots for this
>> volume never finds any snapshots to delete and our list of hypervisor
>> snapshots continues to grow over time for the volume in question.
>>
>> (Below) Set snapshots = volume.getSnapshots(conn); returns the empty
>> set, so there's nothing to delete.
>>
>> However, if I look in XenCenter, I can see hypervisor snapshots for the
>> volume in question.
>>
>> It appears we are passing in the correct info to this method, too.
>>
>> When I use xe, it confirms that the VDI that represents our volume does
>> not have any snapshots, which seems odds.
>>
>> protected boolean destroySnapshotOnPrimaryStorageExceptThis(Connection
>> conn, String volumeUuid, String avoidSnapshotUuid) {
>>
>> try {
>>
>> VDI volume = getVDIbyUuid(conn, volumeUuid);
>>
>> if (volume == null) {
>>
>> throw new InternalErrorException("Could not destroy
>> snapshot on volume " + volumeUuid + " due to can not find it");
>>
>> }
>>
>> Set snapshots = volume.getSnapshots(conn);
>>
>> for (VDI snapshot : snapshots) {
>>
>> try {
>>
>> if
>> (!snapshot.getUuid(conn).equals(avoidSnapshotUuid)) {
>>
>> snapshot.destroy(conn);
>>
>> }
>>
>> } catch (Exception e) {
>>
>> String msg = "Destroying snapshot: " + snapshot + "
>> on primary storage failed due to " + e.toString();
>>
>> s_logger.warn(msg, e);
>>
>> }
>>
>> }
>>
>> s_logger.debug("Successfully destroyed snapshot on volume: "
>> + volumeUuid + " execept this current snapshot " + avoidSnapshotUuid);
>>
>> return true;
>>
>> } catch (XenAPIException e) {
>>
>> String msg = "Destroying snapshot on volume: " + volumeUuid +
>> "
>> execept this current snapshot " + avoidSnapshotUuid + " failed due to " +
>> e.toString();
>>
>> s_logger.error(msg, e);
>>
>> } catch (Exception e) {
>>
>> String msg = "Destroying snapshot on volume: " + volumeUuid +
>> "
>> execept this current snapshot " + avoidSnapshotUuid + " failed due to " +
>> e.toString();
>>
>> s_logger.warn(msg, e);
>>
>> }
>>
>>
>> return false;
>>
>> }
>>
>> --
>> *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: Creating a backup of a hypervisor snapshot

I should test this out, but I'm thinking the current logic of "blindly"
deleting all previous hypervisor snapshots for a given volume will be
incompatible with the "Take VM Snapshot" feature (where a hypervisor
snapshot is created for the VM and every disk the VM is using).

If you've taken a VM Snapshot and then you do a Volume Snapshot, it would
seem the Volume Snapshot process will delete the hypervisor snapshot that
was taken as part of the "Take VM Snapshot" process. You would then only
find out about this when you tried to revert the VM back to that previous
state.

On Mon, Nov 10, 2014 at 1:33 PM, Mike Tutkowski <
mike.tutkow...@solidfire.com> wrote:

> So, interesting, I'm now using XenServer 6.2 (with the patches that
> CloudStack ends up calling XenServer 6.2.5).
>
> When I created a second snapshot/backup of my volume, another hypervisor
> snapshot was created and the data contained in the second hypervisor
> snapshot was copied to secondary storage (all as expected).
>
> At this point, CloudStack was, in fact, successful at deleting the
> original hypervisor snapshot (this was not the case when I was testing this
> on XenServer 6.1, if I recall).
>
> However, when I later deleted the volume, I noticed that the one
> hypervisor snapshot on primary storage remained there. I was expecting it
> to either be deleted immediately or be deleted in the background (it's been
> a day or so and that old hypervisor snapshot for the deleted volume remains
> on primary storage).
>
> Does anyone know off hand if the deletion of this hypervisor snapshot is
> supposed to happen right away or in the background?
>
> Thanks!
>
> On Fri, Nov 7, 2014 at 10:47 AM, Mike Tutkowski <
> mike.tutkow...@solidfire.com> wrote:
>
>> Let me look into this again. At the time, I was busy implementing some
>> other functionality when I came across what seemed like an existing issue
>> in our code.
>>
>> It is odd to me that old (hypervisor) snapshots never get deleted and the
>> code I copy/pasted in has the purpose of deleting those old snapshots, but
>> it never seems to work that way.
>>
>> On Fri, Nov 7, 2014 at 10:20 AM, Stephen Turner <
>> stephen.tur...@citrix.com> wrote:
>>
>>> Mike, are you saying that XenCenter disagrees with xe? That doesn't seem
>>> right as they both get their info from the same API. Maybe XenCenter is
>>> looking at something subtly different.
>>>
>>> XenCenter is open source (https://github.com/xenserver/xenadmin), so
>>> you can consult the source to see what it's reporting. Or send a screenshot
>>> of what you're looking at and I can find the correct bit of source.
>>>
>>> --
>>> Stephen Turner
>>>
>>>
>>> -Original Message-
>>> From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com]
>>> Sent: 04 November 2014 17:28
>>> To: dev@cloudstack.apache.org; Edison Su
>>> Subject: Creating a backup of a hypervisor snapshot
>>>
>>> Hi,
>>>
>>> The standard behavior when we take a snapshot of a volume on XenServer
>>> is to take a hypervisor snapshot of the volume and then copy this snapshot
>>> to secondary storage.
>>>
>>> We then try to delete all other hypervisor snapshots for this volume.
>>>
>>> I notice the process of deleting all other hypervisor snapshots for this
>>> volume never finds any snapshots to delete and our list of hypervisor
>>> snapshots continues to grow over time for the volume in question.
>>>
>>> (Below) Set snapshots = volume.getSnapshots(conn); returns the
>>> empty set, so there's nothing to delete.
>>>
>>> However, if I look in XenCenter, I can see hypervisor snapshots for the
>>> volume in question.
>>>
>>> It appears we are passing in the correct info to this method, too.
>>>
>>> When I use xe, it confirms that the VDI that represents our volume does
>>> not have any snapshots, which seems odds.
>>>
>>> protected boolean
>>> destroySnapshotOnPrimaryStorageExceptThis(Connection
>>> conn, String volumeUuid, String avoidSnapshotUuid) {
>>>
>>> try {
>>>
>>> VDI volume = getVDIbyUuid(conn, volumeUuid);
>>>
>>> if (volume == null) {
>>>
>>> throw new InternalErrorException("Could not destroy
>>> snapshot on volume " + volumeUuid + " due to can not find it");
>>>
>>> }
>>>
>>> Set snapshots = volume.getSnapshots(conn);
>>>
>>> for (VDI snapshot : snapshots) {
>>>
>>> try {
>>>
>>> if
>>> (!snapshot.getUuid(conn).equals(avoidSnapshotUuid)) {
>>>
>>> snapshot.destroy(conn);
>>>
>>> }
>>>
>>> } catch (Exception e) {
>>>
>>> String msg = "Destroying snapshot: " + snapshot + "
>>> on primary storage failed due to " + e.toString();
>>>
>>> s_logger.warn(msg, e);
>>>
>>> }
>>>
>>> }
>>>
>>> s_logger.debug("Successfully destroyed snapshot on volume: "
>>> + volumeUuid + " execept this current snapshot " + avoidSnapshotU

Templates created from snapshots get purged from cloud.template_store_ref

Hi,

In 4.6 I've noticed when I create a template from a snapshot that I can
spin VMs up from this template until I shut the CS MS down and re-start it.

Upon re-start, the template entries in cloud.template_store_ref get purged
(as in completely removed from the table). That being the case, the CS MS
no longer returns these templates as usable, so they're not available, say,
in the GUI to use to spin up VMs from.

Has anyone else noticed this behavior? I'm doing this on what CloudStack
refers to as XenServer 6.2.5 (which is really XS 6.2 + some specific
patches).

Thanks!

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

Review Request 27845: CLOUDSTACK-7876 - Fixed the script 'test_vpc_vm_life_cycle.py' - Prevent Destruction of VM before it can be recovered

2014-11-10 Thread Chandan Purushothama


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

Review request for cloudstack and sangeetha hariharan.


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


Repository: cloudstack-git


Description
---

Multiple Test Cases in the Test Suite Fail as the VMs 
destroy_instance_in_network test case step ends up expunged before the can be 
recovered for the subsequent test cases. Hence it is important not to wait for 
too much time before the VMs can be recovered.

As a fix, I reshuffled the code such that two VM destroy operations are not 
performed one after another immediately. This will cut down the time for the 
VMs retreival.


Diffs
-

  test/integration/component/test_vpc_vm_life_cycle.py e8df680 

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


Testing
---

Test deploy virtual machine in two isolated networks ... === TestName: 
test_01_deploy_vm_two_isolated_nw | Status : SUCCESS ===
ok
Test deploy virtual machine when VPC VR in stopped state ... === TestName: 
test_02_deploy_vm_vpcvr_stopped | Status : SUCCESS ===
ok
Test deploy an instance in VPC networks ... === TestName: 
test_01_deploy_instance_in_network | Status : SUCCESS ===
ok
Test stop an instance in VPC networks ... === TestName: 
test_02_stop_instance_in_network | Status : SUCCESS ===
ok
Test start an instance in VPC networks ... === TestName: 
test_03_start_instance_in_network | Status : SUCCESS ===
ok
Test reboot an instance in VPC networks ... === TestName: 
test_04_reboot_instance_in_network | Status : SUCCESS ===
ok
Test destroy an instance in VPC networks ... === TestName: 
test_05_destroy_instance_in_network | Status : SUCCESS ===
ok
Test migrate an instance in VPC networks ... SKIP: Could not find suitable host 
for migration, please ensure setup has required no. of hosts
Test user data in virtual machines ... === TestName: test_07_user_data | Status 
: SUCCESS ===
ok
Test meta data in virtual machines ... === TestName: test_08_meta_data | Status 
: SUCCESS ===
ok
Test expunge an instance in VPC networks ... === TestName: 
test_09_expunge_instance_in_network | Status : FAILED ===
FAIL
[Please note that this failure happened due to intermmitent network issue which 
is Independent of the fix]
Test deploy an instance in VPC networks ... === TestName: 
test_01_deploy_instance_in_network | Status : SUCCESS ===
ok
Test stop an instance in VPC networks ... === TestName: 
test_02_stop_instance_in_network | Status : SUCCESS ===
ok
Test start an instance in VPC networks ... === TestName: 
test_03_start_instance_in_network | Status : SUCCESS ===
ok
Test reboot an instance in VPC networks ... === TestName: 
test_04_reboot_instance_in_network | Status : SUCCESS ===
ok
Test destroy an instance in VPC networks ... === TestName: 
test_05_destroy_instance_in_network | Status : SUCCESS ===
ok
Test recover an instance in VPC networks ... === TestName: 
test_06_recover_instance_in_network | Status : SUCCESS ===
ok
Test migrate an instance in VPC networks ... === TestName: 
test_07_migrate_instance_in_network | Status : SUCCESS ===
ok
Test user data in virtual machines ... === TestName: test_08_user_data | Status 
: SUCCESS ===
ok
Test meta data in virtual machines ... === TestName: test_09_meta_data | Status 
: SUCCESS ===
ok
Test expunge an instance in VPC networks ... === TestName: 
test_10_expunge_instance_in_network | Status : SUCCESS ===
ok
=== TestName: test_10_expunge_instance_in_network | Status : EXCEPTION === 
[Please note that this failure happened due to intermmitent network issue which 
is Independent of the fix]
ERROR
Test deploy an instance in VPC networks ... === TestName: 
test_01_deploy_instance_in_network | Status : SUCCESS ===
ok
Test stop an instance in VPC networks ... === TestName: 
test_02_stop_instance_in_network | Status : SUCCESS ===
ok
Test start an instance in VPC networks ... === TestName: 
test_03_start_instance_in_network | Status : SUCCESS ===
ok
Test reboot an instance in VPC networks ... === TestName: 
test_04_reboot_instance_in_network | Status : SUCCESS ===
ok
Test destroy an instance in VPC networks ... === TestName: 
test_05_destroy_instance_in_network | Status : SUCCESS ===
ok
Test migrate an instance in VPC networks ... === TestName: 
test_07_migrate_instance_in_network | Status : SUCCESS ===
ok
Test user data in virtual machines ... === TestName: test_08_user_data | Status 
: SUCCESS ===
ok
Test meta data in virtual machines ... === TestName: test_09_meta_data | Status 
: SUCCESS ===
ok
Test expunge an instance in VPC networks ... === TestName: 
test_10_expunge_instance_in_network | Status : SUCCESS ===
ok


Thanks,

Chandan Purushothama

Re: Templates created from snapshots get purged from cloud.template_store_ref

2014-11-10 Thread Marcus

I remember there was an issue with that occasionally happening when
templates were simply registered. Sometimes they'd be downloaded and
installed, and other times they would disappear. I think that was fixed
maybe 18 months ago, could be related.
On Nov 10, 2014 3:36 PM, "Mike Tutkowski" 
wrote:

> Hi,
>
> In 4.6 I've noticed when I create a template from a snapshot that I can
> spin VMs up from this template until I shut the CS MS down and re-start it.
>
> Upon re-start, the template entries in cloud.template_store_ref get purged
> (as in completely removed from the table). That being the case, the CS MS
> no longer returns these templates as usable, so they're not available, say,
> in the GUI to use to spin up VMs from.
>
> Has anyone else noticed this behavior? I'm doing this on what CloudStack
> refers to as XenServer 6.2.5 (which is really XS 6.2 + some specific
> patches).
>
> Thanks!
>
> --
> *Mike Tutkowski*
> *Senior CloudStack Developer, SolidFire Inc.*
> e: mike.tutkow...@solidfire.com
> o: 303.746.7302
> Advancing the way the world uses the cloud
> *™*
>

Re: Templates created from snapshots get purged from cloud.template_store_ref

Thanks, Marcus

I'll take a look into it later tonight more. I'm working on a feature for
4.6 and noticed this yesterday. It happened again today and I narrowed it
down to occurring when the CS MS was stopped and re-started.

On Mon, Nov 10, 2014 at 5:44 PM, Marcus  wrote:

> I remember there was an issue with that occasionally happening when
> templates were simply registered. Sometimes they'd be downloaded and
> installed, and other times they would disappear. I think that was fixed
> maybe 18 months ago, could be related.
> On Nov 10, 2014 3:36 PM, "Mike Tutkowski" 
> wrote:
>
> > Hi,
> >
> > In 4.6 I've noticed when I create a template from a snapshot that I can
> > spin VMs up from this template until I shut the CS MS down and re-start
> it.
> >
> > Upon re-start, the template entries in cloud.template_store_ref get
> purged
> > (as in completely removed from the table). That being the case, the CS MS
> > no longer returns these templates as usable, so they're not available,
> say,
> > in the GUI to use to spin up VMs from.
> >
> > Has anyone else noticed this behavior? I'm doing this on what CloudStack
> > refers to as XenServer 6.2.5 (which is really XS 6.2 + some specific
> > patches).
> >
> > Thanks!
> >
> > --
> > *Mike Tutkowski*
> > *Senior CloudStack Developer, SolidFire Inc.*
> > e: mike.tutkow...@solidfire.com
> > o: 303.746.7302
> > Advancing the way the world uses the cloud
> > *™*
> >
>



-- 
*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: UI: "CPU (in MHz)" doesn't make sense

2014-11-10 Thread ilya musayev

Similar to VmWare, however unless you enable cpu reservation flag in 
general settings, it does not actually allocate and reserve it on vmware 
side - it only keeps it in cloudstack for tracking purposes.





On 11/10/14, 10:02 AM, Marcus wrote:

I can't speak for all hypervisors, but with KVM, it takes the hypervisor
CPU MHz * cores and treats that as 'capacity' of the hypervisor. This
translates directly to the number used for cgroups cpu shares. So a 2GHz
quad core would have 8000 "MHz" worth of vms allocated to it  (ignoring
overprovisioning).

On Mon, Nov 10, 2014 at 9:58 AM, Nux!  wrote:


Personally, I'd propose the defaults should be values proportional or
equal to the cores number (that's how openstack does it).

Anyway, all this doesn't matter as long as no developer is listening. :-)

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

- Original Message -

From: "Logan Barfield" 
To: dev@cloudstack.apache.org
Sent: Monday, 10 November, 2014 17:49:15
Subject: Re: UI: "CPU (in MHz)" doesn't make sense
That was definitely only an assumption.  If each host handles it

different

it may be preferable to hard code a "Default" level for each hypervisor
type, as well as a few different levels (e.g., 'Max', 'High', 'Default',
'Low', 'Min' & 'Custom').  This would operators & end-users clear options
to work with, while retaining the flexibility of a custom option.


Thank You,

Logan Barfield
Tranquil Hosting

On Mon, Nov 10, 2014 at 11:46 AM, Nux!  wrote:


I am not entirely sure if 1 vs 2 = 1 vs 1000. It might be that the one
with 1000 will get 1000 more prio to CPU compared to the one with 1.

This

needs to be clarified per each hypervisor.

Lucian

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

- Original Message -

From: "Logan Barfield" 
To: dev@cloudstack.apache.org
Sent: Monday, 10 November, 2014 16:23:41
Subject: Re: UI: "CPU (in MHz)" doesn't make sense
I agree completely.  We've set all of our service offerings to equal
weights, and hard coded the same weight into the custom offering form.
It's a bit too confusing otherwise.

The way I understand the weights for (Xen/KVM at least) is that

they're

just relative, so 1 vs 2 is the same as 1 vs 1000.  That being the

case

I'd

suggest a solution that has worked for us in the past: set the weight

equal

to the memory amount (in MB).

Thoughts?


Thank You,

Logan Barfield
Tranquil Hosting

On Mon, Nov 10, 2014 at 11:17 AM, Nux!  wrote:


Hi,

Basically I'm annoyed with the "CPU (in MHz)" usage in service

offerings

as they are a lie basically.
Opened https://issues.apache.org/jira/browse/CLOUDSTACK-7874 and

suggest

to have calculated automatically based on CPU cores number or at

least

having it renamed to something like "cpu weight".
MHz means nothing.

Thoughts?

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

Regions setup in existing installs

2014-11-10 Thread Conrad Geiger

For existing installs(4.4 & 4.4.1), is there currently a method in place to 
move an existing zone into a new region?


I found this but it says: Limitation:Zone migration currently does not support 
zones with KVM hosts

https://cwiki.apache.org/confluence/display/CLOUDSTACK/Zone+Migration+to+new+Region
Is it still accurate?  If so, why is KVM not supported?

[cid:image005.jpg@01CE3B8A.C6DBEAF0]
Conrad Geiger | Owner / Engineer
1320 Elmwood Avenue Ste. C, Columbia, SC  29201
Direct/Fax: 803.457.7205 | Main Office: 803.457.7200
cgei...@it1solutions.com | 
www.iT1solutions.com

Re: Templates created from snapshots get purged from cloud.template_store_ref