Re: Review Request 22364: Fixed 26 issues reported by coverity

[Koushik Das]

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



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


These methods are getting used by the job framework. Check 
handleVmWorkJob() method in the same java file.


- Koushik Das


On June 10, 2014, 4:06 a.m., Rajani Karuturi wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/22364/
> ---
> 
> (Updated June 10, 2014, 4:06 a.m.)
> 
> 
> Review request for cloudstack, daan Hoogland, Kelven Yang, Koushik Das, and 
> Santhosh Edukulla.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> NPEs, unused code or dead code, unwritten field access and self assignment
> 
> 
> Diffs
> -
> 
>   engine/orchestration/src/com/cloud/vm/VirtualMachineManagerImpl.java 
> 25c67db 
> 
> Diff: https://reviews.apache.org/r/22364/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Rajani Karuturi
> 
>

Re: Review Request 22354: CLOUDSTACK-6850: Return cpu cores, cpu speed and memory in listUsageRecords

[ASF Subversion and Git Services]

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


Commit a5902f1db4b14012ecd1d5660257655e9dfe4354 in cloudstack's branch 
refs/heads/master from Olivier Lemasle
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=a5902f1 ]

CLOUDSTACK-6850: Return cpu cores, cpu speed and memory in listUsageRecords

Signed-off-by: Sebastien Goasguen 


- ASF Subversion and Git Services


On June 8, 2014, 4:40 p.m., Olivier Lemasle wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/22354/
> ---
> 
> (Updated June 8, 2014, 4:40 p.m.)
> 
> 
> Review request for cloudstack and Kishan Kavala.
> 
> 
> Bugs: CLOUDSTACK-6850
> https://issues.apache.org/jira/browse/CLOUDSTACK-6850
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> This patch updates VMInstanceUsageParser to process usage details (cpu cores, 
> cpu speed and memory) for dynamic compute offering usages, in order to save 
> them in table cloud_usage.cloud_usage and return them with the API 
> (listUsageRecords).
> 
> See CLOUDSTACK-6850.
> 
> A change in database model is required for this patch (three new columns in 
> cloud_usage.cloud_usage).
> 
> The patch should apply on master and 4.4.
> 
> 
> Diffs
> -
> 
>   api/src/org/apache/cloudstack/api/response/UsageRecordResponse.java 5e2e85d 
>   api/src/org/apache/cloudstack/usage/Usage.java 20dc189 
>   engine/schema/src/com/cloud/usage/UsageVMInstanceVO.java 06d4876 
>   engine/schema/src/com/cloud/usage/UsageVO.java 67014ef 
>   engine/schema/src/com/cloud/usage/dao/UsageVMInstanceDaoImpl.java b94e12f 
>   server/src/com/cloud/api/ApiResponseHelper.java 119f56d 
>   setup/db/db/schema-430to440.sql d149a65 
>   usage/src/com/cloud/usage/parser/VMInstanceUsageParser.java ba0d4bf 
> 
> Diff: https://reviews.apache.org/r/22354/diff/
> 
> 
> Testing
> ---
> 
> Packaged in RPMs, installed and manually tested.
> 
> 1. Create a VM with compute offering "Small instance".
> 2. Stop the VM.
> 3. Change service offering to a custom offering, with cpu_number=1, 
> cpu_speed=500 MHz, memory=512 MB
> 4. Start the VM, wait... Stop the VM.
> 6. Change service offering to an other custom offering, with cpu_number=2, 
> cpu_speed=800 MHz, memory=1024 MB
> 7. Start the VM, wait... Stop the VM.
> 8. Change service offering to the first custom offering, with same "details" 
> (cpu_number=2, cpu_speed=800 MHz, memory=1024 MB)
> 9. Start the VM, wait... Stop the VM.
> 10. Change service offering to "Medium instance".
> 
> Usages and details are reflected in database and in API response. There is no 
> regression found for other usage types.
> Details are returned (and saved in database) only for RUNNING_VM and 
> ALLOCATED_VM, only if the service offering is a custom one.
> 
> Example of response:
> 
> 
> admin
> 184a6564-edab-11e3-b629-0050569ed71c
> fbc7578a-edaa-11e3-b629-0050569ed71c
> e5047089-c911-40ea-8251-4a76810ac1e0
> california allocated (ServiceOffering: 12) (Template: 
> 5)
> 0.098078 Hrs
> 2
> 0.098078
> e89c22af-65cf-42a2-8905-6f4bbd7d59a1
> california
> b05b64e9-8e0f-4335-b0e0-acc5bad81938
> fbca2564-edaa-11e3-b629-0050569ed71c
> e89c22af-65cf-42a2-8905-6f4bbd7d59a1
> XenServer
> 1
> 500
> 512
> 2014-06-08'T'17:05:52+02:00
> 2014-06-08'T'17:15:52+02:00
> 
> 
> admin
> 184a6564-edab-11e3-b629-0050569ed71c
> fbc7578a-edaa-11e3-b629-0050569ed71c
> e5047089-c911-40ea-8251-4a76810ac1e0
> california allocated (ServiceOffering: 1) (Template: 
> 5)
> 0.068594 Hrs
> 2
> 0.068594
> e89c22af-65cf-42a2-8905-6f4bbd7d59a1
> california
> 84bbf38f-b582-440b-8a8d-20e63e0dbed7
> fbca2564-edaa-11e3-b629-0050569ed71c
> e89c22af-65cf-42a2-8905-6f4bbd7d59a1
> XenServer
> 2014-06-08'T'17:05:52+02:00
> 2014-06-08'T'17:15:52+02:00
> 
> 
> 
> Thanks,
> 
> Olivier Lemasle
> 
>

Re: Review Request 22354: CLOUDSTACK-6850: Return cpu cores, cpu speed and memory in listUsageRecords

[ASF Subversion and Git Services]

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


Commit a1f278e9d47e8029d58df6d3aae13495965ca434 in cloudstack's branch 
refs/heads/4.4-forward from Olivier Lemasle
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=a1f278e ]

CLOUDSTACK-6850: Return cpu cores, cpu speed and memory in listUsageRecords

Signed-off-by: Sebastien Goasguen 


- ASF Subversion and Git Services


On June 8, 2014, 4:40 p.m., Olivier Lemasle wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/22354/
> ---
> 
> (Updated June 8, 2014, 4:40 p.m.)
> 
> 
> Review request for cloudstack and Kishan Kavala.
> 
> 
> Bugs: CLOUDSTACK-6850
> https://issues.apache.org/jira/browse/CLOUDSTACK-6850
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> This patch updates VMInstanceUsageParser to process usage details (cpu cores, 
> cpu speed and memory) for dynamic compute offering usages, in order to save 
> them in table cloud_usage.cloud_usage and return them with the API 
> (listUsageRecords).
> 
> See CLOUDSTACK-6850.
> 
> A change in database model is required for this patch (three new columns in 
> cloud_usage.cloud_usage).
> 
> The patch should apply on master and 4.4.
> 
> 
> Diffs
> -
> 
>   api/src/org/apache/cloudstack/api/response/UsageRecordResponse.java 5e2e85d 
>   api/src/org/apache/cloudstack/usage/Usage.java 20dc189 
>   engine/schema/src/com/cloud/usage/UsageVMInstanceVO.java 06d4876 
>   engine/schema/src/com/cloud/usage/UsageVO.java 67014ef 
>   engine/schema/src/com/cloud/usage/dao/UsageVMInstanceDaoImpl.java b94e12f 
>   server/src/com/cloud/api/ApiResponseHelper.java 119f56d 
>   setup/db/db/schema-430to440.sql d149a65 
>   usage/src/com/cloud/usage/parser/VMInstanceUsageParser.java ba0d4bf 
> 
> Diff: https://reviews.apache.org/r/22354/diff/
> 
> 
> Testing
> ---
> 
> Packaged in RPMs, installed and manually tested.
> 
> 1. Create a VM with compute offering "Small instance".
> 2. Stop the VM.
> 3. Change service offering to a custom offering, with cpu_number=1, 
> cpu_speed=500 MHz, memory=512 MB
> 4. Start the VM, wait... Stop the VM.
> 6. Change service offering to an other custom offering, with cpu_number=2, 
> cpu_speed=800 MHz, memory=1024 MB
> 7. Start the VM, wait... Stop the VM.
> 8. Change service offering to the first custom offering, with same "details" 
> (cpu_number=2, cpu_speed=800 MHz, memory=1024 MB)
> 9. Start the VM, wait... Stop the VM.
> 10. Change service offering to "Medium instance".
> 
> Usages and details are reflected in database and in API response. There is no 
> regression found for other usage types.
> Details are returned (and saved in database) only for RUNNING_VM and 
> ALLOCATED_VM, only if the service offering is a custom one.
> 
> Example of response:
> 
> 
> admin
> 184a6564-edab-11e3-b629-0050569ed71c
> fbc7578a-edaa-11e3-b629-0050569ed71c
> e5047089-c911-40ea-8251-4a76810ac1e0
> california allocated (ServiceOffering: 12) (Template: 
> 5)
> 0.098078 Hrs
> 2
> 0.098078
> e89c22af-65cf-42a2-8905-6f4bbd7d59a1
> california
> b05b64e9-8e0f-4335-b0e0-acc5bad81938
> fbca2564-edaa-11e3-b629-0050569ed71c
> e89c22af-65cf-42a2-8905-6f4bbd7d59a1
> XenServer
> 1
> 500
> 512
> 2014-06-08'T'17:05:52+02:00
> 2014-06-08'T'17:15:52+02:00
> 
> 
> admin
> 184a6564-edab-11e3-b629-0050569ed71c
> fbc7578a-edaa-11e3-b629-0050569ed71c
> e5047089-c911-40ea-8251-4a76810ac1e0
> california allocated (ServiceOffering: 1) (Template: 
> 5)
> 0.068594 Hrs
> 2
> 0.068594
> e89c22af-65cf-42a2-8905-6f4bbd7d59a1
> california
> 84bbf38f-b582-440b-8a8d-20e63e0dbed7
> fbca2564-edaa-11e3-b629-0050569ed71c
> e89c22af-65cf-42a2-8905-6f4bbd7d59a1
> XenServer
> 2014-06-08'T'17:05:52+02:00
> 2014-06-08'T'17:15:52+02:00
> 
> 
> 
> Thanks,
> 
> Olivier Lemasle
> 
>

[ACS44] CS6850

[Sebastien Goasguen]

Daan,

Can you cherry-pick:
a1f278e9d47e8029d58df6d3aae13495965ca434

from 4.4 forward, it fixes CS-6850

thank you

-sebastien

Re: Review Request 22354: CLOUDSTACK-6850: Return cpu cores, cpu speed and memory in listUsageRecords

[Sebastien Goasguen]

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

Ship it!


Ok fine with me, I trust that you will stay on top of this, test and submit 
further fixes.

I applied your patch to master and 4.4-forward. It should be cherry-picked to 
4.4
Nothing done to 4.3.



- Sebastien Goasguen


On June 8, 2014, 4:40 p.m., Olivier Lemasle wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/22354/
> ---
> 
> (Updated June 8, 2014, 4:40 p.m.)
> 
> 
> Review request for cloudstack and Kishan Kavala.
> 
> 
> Bugs: CLOUDSTACK-6850
> https://issues.apache.org/jira/browse/CLOUDSTACK-6850
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> This patch updates VMInstanceUsageParser to process usage details (cpu cores, 
> cpu speed and memory) for dynamic compute offering usages, in order to save 
> them in table cloud_usage.cloud_usage and return them with the API 
> (listUsageRecords).
> 
> See CLOUDSTACK-6850.
> 
> A change in database model is required for this patch (three new columns in 
> cloud_usage.cloud_usage).
> 
> The patch should apply on master and 4.4.
> 
> 
> Diffs
> -
> 
>   api/src/org/apache/cloudstack/api/response/UsageRecordResponse.java 5e2e85d 
>   api/src/org/apache/cloudstack/usage/Usage.java 20dc189 
>   engine/schema/src/com/cloud/usage/UsageVMInstanceVO.java 06d4876 
>   engine/schema/src/com/cloud/usage/UsageVO.java 67014ef 
>   engine/schema/src/com/cloud/usage/dao/UsageVMInstanceDaoImpl.java b94e12f 
>   server/src/com/cloud/api/ApiResponseHelper.java 119f56d 
>   setup/db/db/schema-430to440.sql d149a65 
>   usage/src/com/cloud/usage/parser/VMInstanceUsageParser.java ba0d4bf 
> 
> Diff: https://reviews.apache.org/r/22354/diff/
> 
> 
> Testing
> ---
> 
> Packaged in RPMs, installed and manually tested.
> 
> 1. Create a VM with compute offering "Small instance".
> 2. Stop the VM.
> 3. Change service offering to a custom offering, with cpu_number=1, 
> cpu_speed=500 MHz, memory=512 MB
> 4. Start the VM, wait... Stop the VM.
> 6. Change service offering to an other custom offering, with cpu_number=2, 
> cpu_speed=800 MHz, memory=1024 MB
> 7. Start the VM, wait... Stop the VM.
> 8. Change service offering to the first custom offering, with same "details" 
> (cpu_number=2, cpu_speed=800 MHz, memory=1024 MB)
> 9. Start the VM, wait... Stop the VM.
> 10. Change service offering to "Medium instance".
> 
> Usages and details are reflected in database and in API response. There is no 
> regression found for other usage types.
> Details are returned (and saved in database) only for RUNNING_VM and 
> ALLOCATED_VM, only if the service offering is a custom one.
> 
> Example of response:
> 
> 
> admin
> 184a6564-edab-11e3-b629-0050569ed71c
> fbc7578a-edaa-11e3-b629-0050569ed71c
> e5047089-c911-40ea-8251-4a76810ac1e0
> california allocated (ServiceOffering: 12) (Template: 
> 5)
> 0.098078 Hrs
> 2
> 0.098078
> e89c22af-65cf-42a2-8905-6f4bbd7d59a1
> california
> b05b64e9-8e0f-4335-b0e0-acc5bad81938
> fbca2564-edaa-11e3-b629-0050569ed71c
> e89c22af-65cf-42a2-8905-6f4bbd7d59a1
> XenServer
> 1
> 500
> 512
> 2014-06-08'T'17:05:52+02:00
> 2014-06-08'T'17:15:52+02:00
> 
> 
> admin
> 184a6564-edab-11e3-b629-0050569ed71c
> fbc7578a-edaa-11e3-b629-0050569ed71c
> e5047089-c911-40ea-8251-4a76810ac1e0
> california allocated (ServiceOffering: 1) (Template: 
> 5)
> 0.068594 Hrs
> 2
> 0.068594
> e89c22af-65cf-42a2-8905-6f4bbd7d59a1
> california
> 84bbf38f-b582-440b-8a8d-20e63e0dbed7
> fbca2564-edaa-11e3-b629-0050569ed71c
> e89c22af-65cf-42a2-8905-6f4bbd7d59a1
> XenServer
> 2014-06-08'T'17:05:52+02:00
> 2014-06-08'T'17:15:52+02:00
> 
> 
> 
> Thanks,
> 
> Olivier Lemasle
> 
>

Re: Review Request 22354: CLOUDSTACK-6850: Return cpu cores, cpu speed and memory in listUsageRecords

[Sebastien Goasguen]

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


Please mark you reviews as 'submitted' and update the JIRA tickets accordingly.

thanks

- Sebastien Goasguen


On June 8, 2014, 4:40 p.m., Olivier Lemasle wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/22354/
> ---
> 
> (Updated June 8, 2014, 4:40 p.m.)
> 
> 
> Review request for cloudstack and Kishan Kavala.
> 
> 
> Bugs: CLOUDSTACK-6850
> https://issues.apache.org/jira/browse/CLOUDSTACK-6850
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> This patch updates VMInstanceUsageParser to process usage details (cpu cores, 
> cpu speed and memory) for dynamic compute offering usages, in order to save 
> them in table cloud_usage.cloud_usage and return them with the API 
> (listUsageRecords).
> 
> See CLOUDSTACK-6850.
> 
> A change in database model is required for this patch (three new columns in 
> cloud_usage.cloud_usage).
> 
> The patch should apply on master and 4.4.
> 
> 
> Diffs
> -
> 
>   api/src/org/apache/cloudstack/api/response/UsageRecordResponse.java 5e2e85d 
>   api/src/org/apache/cloudstack/usage/Usage.java 20dc189 
>   engine/schema/src/com/cloud/usage/UsageVMInstanceVO.java 06d4876 
>   engine/schema/src/com/cloud/usage/UsageVO.java 67014ef 
>   engine/schema/src/com/cloud/usage/dao/UsageVMInstanceDaoImpl.java b94e12f 
>   server/src/com/cloud/api/ApiResponseHelper.java 119f56d 
>   setup/db/db/schema-430to440.sql d149a65 
>   usage/src/com/cloud/usage/parser/VMInstanceUsageParser.java ba0d4bf 
> 
> Diff: https://reviews.apache.org/r/22354/diff/
> 
> 
> Testing
> ---
> 
> Packaged in RPMs, installed and manually tested.
> 
> 1. Create a VM with compute offering "Small instance".
> 2. Stop the VM.
> 3. Change service offering to a custom offering, with cpu_number=1, 
> cpu_speed=500 MHz, memory=512 MB
> 4. Start the VM, wait... Stop the VM.
> 6. Change service offering to an other custom offering, with cpu_number=2, 
> cpu_speed=800 MHz, memory=1024 MB
> 7. Start the VM, wait... Stop the VM.
> 8. Change service offering to the first custom offering, with same "details" 
> (cpu_number=2, cpu_speed=800 MHz, memory=1024 MB)
> 9. Start the VM, wait... Stop the VM.
> 10. Change service offering to "Medium instance".
> 
> Usages and details are reflected in database and in API response. There is no 
> regression found for other usage types.
> Details are returned (and saved in database) only for RUNNING_VM and 
> ALLOCATED_VM, only if the service offering is a custom one.
> 
> Example of response:
> 
> 
> admin
> 184a6564-edab-11e3-b629-0050569ed71c
> fbc7578a-edaa-11e3-b629-0050569ed71c
> e5047089-c911-40ea-8251-4a76810ac1e0
> california allocated (ServiceOffering: 12) (Template: 
> 5)
> 0.098078 Hrs
> 2
> 0.098078
> e89c22af-65cf-42a2-8905-6f4bbd7d59a1
> california
> b05b64e9-8e0f-4335-b0e0-acc5bad81938
> fbca2564-edaa-11e3-b629-0050569ed71c
> e89c22af-65cf-42a2-8905-6f4bbd7d59a1
> XenServer
> 1
> 500
> 512
> 2014-06-08'T'17:05:52+02:00
> 2014-06-08'T'17:15:52+02:00
> 
> 
> admin
> 184a6564-edab-11e3-b629-0050569ed71c
> fbc7578a-edaa-11e3-b629-0050569ed71c
> e5047089-c911-40ea-8251-4a76810ac1e0
> california allocated (ServiceOffering: 1) (Template: 
> 5)
> 0.068594 Hrs
> 2
> 0.068594
> e89c22af-65cf-42a2-8905-6f4bbd7d59a1
> california
> 84bbf38f-b582-440b-8a8d-20e63e0dbed7
> fbca2564-edaa-11e3-b629-0050569ed71c
> e89c22af-65cf-42a2-8905-6f4bbd7d59a1
> XenServer
> 2014-06-08'T'17:05:52+02:00
> 2014-06-08'T'17:15:52+02:00
> 
> 
> 
> Thanks,
> 
> Olivier Lemasle
> 
>

Re: [GSoC] [CLOUDSTACK-6114] Progress update

[Sebastien Goasguen]

On Jun 9, 2014, at 4:20 PM, Ian Duffy  wrote:

> Hi All,
> 
> Started making some fast progress on this.
> 
> I uploaded the xenserver box[1] to vagrant cloud. This means people can
> easily get a xenserver VM by executing vagrant init duffy/xenserver &&
> vagrant up.
> 
> I adjusted the configuration on the box to allow for multiple xenserver
> boxes to be brought up by one vagrant file. In order to allow this I had to
> remove the host-only network configuration from the packaged box into an
> external script [2]. It can be used as follows:
> 
>  config.vm.define "xenserver" do |xenserver|
>xenserver.vm.box = "duffy/xenserver"
> 
>xenserver.vm.provision "shell" do |s|
>  s.path = "xenserver/reset-network.sh"
>  s.args = ["eth1", "192.168.56.10", "255.255.255.0"]
>end
>  end
> 
> 
> I created a skeleton for the chef cookbook [3]. At the moment it include
> calls to the MySQL, NFS and IPTables gateway recipes with default
> attributes specified for the included devcloud.cfg. Along with this I wrote
> a systemvm downloading recipe which reads an array of systemvms from the
> cookbooks attributes file and downloads/installed them accordingly. It uses
> the -t switch to on the cloud-install-sys-tmplt script to avoid querying
> the MySQL db for information.
> 
> I added some brief usage documentation too [4]
> 
> 
> [1] https://github.com/imduffy15/packer-xenserver
> [2]
> https://github.com/imduffy15/GSoC-2014/blob/master/MySql_NFS_XenServer/xenserver/reset-network.sh
> [3] https://github.com/imduffy15/cookbook_cloudstack
> [4] https://github.com/imduffy15/GSoC-2014/blob/master/README.md

Good work Ian, I hope to test it this week.

-sebastien

Re: [GSOC2014] Progress Update - week two

[Sebastien Goasguen]

On Jun 3, 2014, at 5:30 PM, Darren Brogan  wrote:

>>> Dif you upload a new version to pypi ?
> 
> Not yet, this will be done very shortly though.
> 
>>> I dont recall if we had the same version number or not. Probably good to
> increment it so we can upggrade via pip
> 
> Yup, the versions numbers are different, upgrade should work fine.
> 
> 0.0.1 = initial gcloud release
> 0.0.2 = rename from gcloud to gstack
> 0.0.3 = extract configuration file out of project folder
> 0.1.0 = Add support for GCE GA
> 
> 
> I'll add a HISTORY.rst file to the repo to keep track of release changes.
> 


And fwiw, I tested both gstack and ec2stack latest versions this weekend and 
everything  worked fine.

Good work adding the ec2 tags, and making gstack compliant with GA v1

> Darren
> 
> 
> On Tue, Jun 3, 2014 at 9:41 PM, Sebastien Goasguen  wrote:
> 
>> Great job Darren, and thanks for the update. See inline
>> 
>> -Sebastien
>> 
>>> On 3 Jun 2014, at 22:25, Darren Brogan 
>> wrote:
>>> 
>>> Hi Guys,
>>> 
>>> Just a quick update on progress for last week.
>>> 
>>> *[ec2stack]*
>>> 
>>> Since the last progress email I've completed support of tag actions.
>> There
>>> is now support for listing / creating / deleting Cloudstack tags through
>>> ec2stack. I wrote the required tests and updated the documentation
>>> accordingly. I was working in a branch called 'tag_support', this has
>> been
>>> merged into master since my last email.
>> 
>> A quick howto on how to add new api would be nice.
>> 
>>> 
>>> ec2stack github repo - https://github.com/BroganD1993/ec2stack
>>> 
>> 
>> Dif you upload a new version to pypi ?
>> 
>> 
>>> *[gstack]*
>>> 
>>> Since my last update I've completed work on basic GCE GA support for
>>> gstack. Anything that was supported in the original release of gstack,
>>> using the GCE v15beta API should now work with the GCE GA API.
>>> 
>>> The documentation on GitHub was updated with new setup instructions for
>>> users.
>>> 
>>> After completing the GCE GA support work I made a new release on pypi
>> which
>>> is available for download here:
>> https://pypi.python.org/pypi/gstack/0.1.0
>>> 
>> 
>> I dont recall if we had the same version number or not. Probably good to
>> increment it so we can upggrade via pip
>> 
>>> 
>>> I began writing tests for the project, which is progressing nicely. I
>> have
>>> most of the major functionality tested, there's still a bit of work left
>> to
>>> do. The test support branch was merged into master earlier today.
>>> 
>>> gstack project repo - https://github.com/NOPping/gstack
>>> 
>>> My next step is to finish the unittesting for gstack and then move on to
>>> refactoring, restructuring & cleaning of the code base.
>>> 
>> 
>> Sounds like a plan
>> 
>>> Thanks,
>>> Darren
>> 

Re: [GSoC] [CLOUDSTACK-6114] Progress update

[Rohit Yadav]

Hi Ian,

Thanks for sharing, I was trying to do something miserably to make an
appliance for testing xenserver/xenproject with ACS. Will try it in the
evening.

Cheers.


On Tue, Jun 10, 2014 at 1:50 AM, Ian Duffy  wrote:

> Hi All,
>
> Started making some fast progress on this.
>
> I uploaded the xenserver box[1] to vagrant cloud. This means people can
> easily get a xenserver VM by executing vagrant init duffy/xenserver &&
> vagrant up.
>
> I adjusted the configuration on the box to allow for multiple xenserver
> boxes to be brought up by one vagrant file. In order to allow this I had to
> remove the host-only network configuration from the packaged box into an
> external script [2]. It can be used as follows:
>
>   config.vm.define "xenserver" do |xenserver|
> xenserver.vm.box = "duffy/xenserver"
>
> xenserver.vm.provision "shell" do |s|
>   s.path = "xenserver/reset-network.sh"
>   s.args = ["eth1", "192.168.56.10", "255.255.255.0"]
> end
>   end
>
>
> I created a skeleton for the chef cookbook [3]. At the moment it include
> calls to the MySQL, NFS and IPTables gateway recipes with default
> attributes specified for the included devcloud.cfg. Along with this I wrote
> a systemvm downloading recipe which reads an array of systemvms from the
> cookbooks attributes file and downloads/installed them accordingly. It uses
> the -t switch to on the cloud-install-sys-tmplt script to avoid querying
> the MySQL db for information.
>
> I added some brief usage documentation too [4]
>
>
> [1] https://github.com/imduffy15/packer-xenserver
> [2]
>
> https://github.com/imduffy15/GSoC-2014/blob/master/MySql_NFS_XenServer/xenserver/reset-network.sh
> [3] https://github.com/imduffy15/cookbook_cloudstack
> [4] https://github.com/imduffy15/GSoC-2014/blob/master/README.md
>

RE: redundant virtual routers for VPCs

[Daan Hoogland]

Quite right:


-  Feasibility experiment plans by Schuberg Philis

-  Reusable work by Karl

-  Problems Citrix encountered with the regular redundant router (and 
how to avoid them)

-  Work division

-  (next meeting needed?)

Any additions?

\DaanH

From: Sheng Yang [mailto:sh...@yasker.org]
Sent: dinsdag 10 juni 2014 1:39
To: Sander Botman
Cc: Daan Hoogland; Karl Harris; dev; Alena Prokharchyk; kis...@cloud.com; 
Christopher Litsinger; Hugo Trippaers; int-toolkit
Subject: Re: redundant virtual routers for VPCs

BTW, do we have an agenda or some topics we want to discuss for the meeting? I 
just want to make sure it's efficient.

--Sheng

On Mon, Jun 9, 2014 at 1:14 PM, Sander Botman 
mailto:sbot...@schubergphilis.com>> wrote:
Hi all

I can make 15:00.

Cannon join at 20:00.

Cheers Sander

Verstuurd vanaf mijn iPhone

> Op 9 jun. 2014 om 21:31 heeft "Daan Hoogland" 
> mailto:daan.hoogl...@gmail.com>> het volgende 
> geschreven:
>
> nice,
>
> so given pacific time I can have a meeting at 15:00 utc or at 20:00
> utc (8 am or 2 pm if I'm correct). Given office hours in Holland 17:00
> (15:00 utc) would be best but if you're not in it could be later. As
> the person calling the meeting I would like to participate but if the
> highest attendance can be found only between 16 and 22 utc thats fine
> as well.
>
>> On Mon, Jun 9, 2014 at 8:35 PM, Karl Harris 
>> mailto:karl.har...@sungardas.com>> wrote:
>> I will be happy to join!
>>
>>
>>
>>> On Saturday, June 7, 2014, Daan Hoogland 
>>> mailto:daan.hoogl...@gmail.com>> wrote:
>>>
>>> At Schuberg Philis, the urge to have virtual routers in a redundant
>>> way is getting to be pressing. It seems Citrix wants to move away from
>>> it entirely and Sungard is working on it but has to little resources
>>> for it. Withing our dev group we are now planning a sprint to
>>> experiment with this subject and then implement or fix the present
>>> routers to support this. However we would very much like input from
>>> the people who have already worked on this and are also very willing
>>> to let them in our sprint-team if they are willing.
>>>
>>> So: who want to join in a irc meeting (or conf call) on the subject
>>> coming week? Dutch people are not in the office on the day after
>>> ascension so tuesday is our intention.
>>>
>>> on behalf of some very impatient operators;)
>>> --
>>> Daan
>
>
>
> --
> Daan

Re: Review Request 22364: Fixed 26 issues reported by coverity

[Rajani Karuturi]

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

(Updated June 10, 2014, 8:24 a.m.)


Review request for cloudstack, daan Hoogland, Kelven Yang, Koushik Das, and 
Santhosh Edukulla.


Changes
---

brought back the unused private methods which are used through reflection.


Repository: cloudstack-git


Description
---

NPEs, unused code or dead code, unwritten field access and self assignment


Diffs (updated)
-

  engine/orchestration/src/com/cloud/vm/VirtualMachineManagerImpl.java 25c67db 

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


Testing
---


Thanks,

Rajani Karuturi

Re: Review Request 22364: Fixed 26 issues reported by coverity

[Rajani Karuturi]

> On June 10, 2014, 7:07 a.m., Koushik Das wrote:
> > engine/orchestration/src/com/cloud/vm/VirtualMachineManagerImpl.java, line 
> > 5132
> > 
> >
> > These methods are getting used by the job framework. Check 
> > handleVmWorkJob() method in the same java file.

I updated the diff by adding the unused methods. Will start a separate 
discussion on these


- Rajani


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


On June 10, 2014, 8:24 a.m., Rajani Karuturi wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/22364/
> ---
> 
> (Updated June 10, 2014, 8:24 a.m.)
> 
> 
> Review request for cloudstack, daan Hoogland, Kelven Yang, Koushik Das, and 
> Santhosh Edukulla.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> NPEs, unused code or dead code, unwritten field access and self assignment
> 
> 
> Diffs
> -
> 
>   engine/orchestration/src/com/cloud/vm/VirtualMachineManagerImpl.java 
> 25c67db 
> 
> Diff: https://reviews.apache.org/r/22364/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Rajani Karuturi
> 
>

Re: redundant virtual routers for VPCs

[Hugo Trippaers]

I can’t make 15:00, but 22:00 could work.

Cheers,

Hugo


On 10 jun. 2014, at 10:14, Daan Hoogland  wrote:

> Quite right:
> 
> 
> -  Feasibility experiment plans by Schuberg Philis
> 
> -  Reusable work by Karl
> 
> -  Problems Citrix encountered with the regular redundant router (and 
> how to avoid them)
> 
> -  Work division
> 
> -  (next meeting needed?)
> 
> Any additions?
> 
> \DaanH
> 
> From: Sheng Yang [mailto:sh...@yasker.org]
> Sent: dinsdag 10 juni 2014 1:39
> To: Sander Botman
> Cc: Daan Hoogland; Karl Harris; dev; Alena Prokharchyk; kis...@cloud.com; 
> Christopher Litsinger; Hugo Trippaers; int-toolkit
> Subject: Re: redundant virtual routers for VPCs
> 
> BTW, do we have an agenda or some topics we want to discuss for the meeting? 
> I just want to make sure it's efficient.
> 
> --Sheng
> 
> On Mon, Jun 9, 2014 at 1:14 PM, Sander Botman 
> mailto:sbot...@schubergphilis.com>> wrote:
> Hi all
> 
> I can make 15:00.
> 
> Cannon join at 20:00.
> 
> Cheers Sander
> 
> Verstuurd vanaf mijn iPhone
> 
>> Op 9 jun. 2014 om 21:31 heeft "Daan Hoogland" 
>> mailto:daan.hoogl...@gmail.com>> het volgende 
>> geschreven:
>> 
>> nice,
>> 
>> so given pacific time I can have a meeting at 15:00 utc or at 20:00
>> utc (8 am or 2 pm if I'm correct). Given office hours in Holland 17:00
>> (15:00 utc) would be best but if you're not in it could be later. As
>> the person calling the meeting I would like to participate but if the
>> highest attendance can be found only between 16 and 22 utc thats fine
>> as well.
>> 
>>> On Mon, Jun 9, 2014 at 8:35 PM, Karl Harris 
>>> mailto:karl.har...@sungardas.com>> wrote:
>>> I will be happy to join!
>>> 
>>> 
>>> 
 On Saturday, June 7, 2014, Daan Hoogland 
 mailto:daan.hoogl...@gmail.com>> wrote:
 
 At Schuberg Philis, the urge to have virtual routers in a redundant
 way is getting to be pressing. It seems Citrix wants to move away from
 it entirely and Sungard is working on it but has to little resources
 for it. Withing our dev group we are now planning a sprint to
 experiment with this subject and then implement or fix the present
 routers to support this. However we would very much like input from
 the people who have already worked on this and are also very willing
 to let them in our sprint-team if they are willing.
 
 So: who want to join in a irc meeting (or conf call) on the subject
 coming week? Dutch people are not in the office on the day after
 ascension so tuesday is our intention.
 
 on behalf of some very impatient operators;)
 --
 Daan
>> 
>> 
>> 
>> --
>> Daan
> 

[EVENT] CloudStack conference Budapest Nov. 19-21

[sebgoa]

Hi folks,

There is only 15 days left to submit your talks to CloudStack Conference 
Budapest.

http://events.linuxfoundation.org/events/cloudstack-collaboration-conference-europe/program/cfp

This year is going to be super exciting, thanks to your amazing talks :)

-Sebastien

Re: Review Request 22364: Fixed 26 issues reported by coverity

[Koushik Das]

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

Ship it!


master -> b666a1f3a5bcd17663af1675e82759c3ff8cbeb9
4.4-forward -> 390e498dc58a89f0b060c50e5b796061bc97342e

- Koushik Das


On June 10, 2014, 8:24 a.m., Rajani Karuturi wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/22364/
> ---
> 
> (Updated June 10, 2014, 8:24 a.m.)
> 
> 
> Review request for cloudstack, daan Hoogland, Kelven Yang, Koushik Das, and 
> Santhosh Edukulla.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> NPEs, unused code or dead code, unwritten field access and self assignment
> 
> 
> Diffs
> -
> 
>   engine/orchestration/src/com/cloud/vm/VirtualMachineManagerImpl.java 
> 25c67db 
> 
> Diff: https://reviews.apache.org/r/22364/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Rajani Karuturi
> 
>

unused private methods in VirtualMachinManagerImpl

[Rajani Karuturi]

Hi Kelven,
while fixing some of the issues reported by coverity I encountered some unused 
private methods in VirtualMachineManagerImpl.java 
(https://reviews.apache.org/r/22364 ) and removed them. Koushik pointed that 
they are getting used by the job framework.
Looks like these are used by the job framework by making them public through 
reflection and following some convention for the function names. 

Its very difficult to find the usages or refactor which can have some 
unforeseen consequences.

Can you share some details about them? probably some javadoc?


~Rajani



On 10-Jun-2014, at 12:37 pm, Koushik Das  wrote:

> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/22364/#review45200
> ---
> 
> 
> 
> engine/orchestration/src/com/cloud/vm/VirtualMachineManagerImpl.java
> 
> 
>These methods are getting used by the job framework. Check 
> handleVmWorkJob() method in the same java file.
> 
> 
> - Koushik Das
> 
> 
> On June 10, 2014, 4:06 a.m., Rajani Karuturi wrote:
>> 
>> ---
>> This is an automatically generated e-mail. To reply, visit:
>> https://reviews.apache.org/r/22364/
>> ---
>> 
>> (Updated June 10, 2014, 4:06 a.m.)
>> 
>> 
>> Review request for cloudstack, daan Hoogland, Kelven Yang, Koushik Das, and 
>> Santhosh Edukulla.
>> 
>> 
>> Repository: cloudstack-git
>> 
>> 
>> Description
>> ---
>> 
>> NPEs, unused code or dead code, unwritten field access and self assignment
>> 
>> 
>> Diffs
>> -
>> 
>>  engine/orchestration/src/com/cloud/vm/VirtualMachineManagerImpl.java 
>> 25c67db 
>> 
>> Diff: https://reviews.apache.org/r/22364/diff/
>> 
>> 
>> Testing
>> ---
>> 
>> 
>> Thanks,
>> 
>> Rajani Karuturi
>> 
>> 
> 

Re: Review Request 22232: Fix for test_01_create_volume to use the correct volume name for KVM

[Alex Brett]

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

(Updated June 10, 2014, 10:09 a.m.)


Review request for cloudstack and SrikanteswaraRao Talluri.


Changes
---

Adding cloudstack group


Repository: cloudstack-git


Description
---

test_01_create_volume was expecting the new volume to appears as /dev/sda when 
running on KVM (as this is the default volume used in util.checkVolumeSize), 
whereas it actually appears as /dev/vdb.

This patch determines the appropriate volume name in the same way as we do for 
XenServer, and uses that instead.


Diffs
-

  test/integration/smoke/test_volumes.py 73c2722 

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


Testing
---

Verified the test now passes when running against a KVM host.


Thanks,

Alex Brett

Re: Review Request 22232: Fix for test_01_create_volume to use the correct volume name for KVM

[SrikanteswaraRao Talluri]

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

Ship it!


for future review requests, please create a bug in issues.apache.org and add it 
to the review request.

- SrikanteswaraRao Talluri


On June 10, 2014, 10:09 a.m., Alex Brett wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/22232/
> ---
> 
> (Updated June 10, 2014, 10:09 a.m.)
> 
> 
> Review request for cloudstack and SrikanteswaraRao Talluri.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> test_01_create_volume was expecting the new volume to appears as /dev/sda 
> when running on KVM (as this is the default volume used in 
> util.checkVolumeSize), whereas it actually appears as /dev/vdb.
> 
> This patch determines the appropriate volume name in the same way as we do 
> for XenServer, and uses that instead.
> 
> 
> Diffs
> -
> 
>   test/integration/smoke/test_volumes.py 73c2722 
> 
> Diff: https://reviews.apache.org/r/22232/diff/
> 
> 
> Testing
> ---
> 
> Verified the test now passes when running against a KVM host.
> 
> 
> Thanks,
> 
> Alex Brett
> 
>

Re: redundant virtual routers for VPCs

[Daan Hoogland]

I would like to have Hugo in the meeting So let's make it 20:00 UTC

I would suggest #cloudstack-meeting

On Tue, Jun 10, 2014 at 10:29 AM, Hugo Trippaers  wrote:
>
> I can’t make 15:00, but 22:00 could work.
>
> Cheers,
>
> Hugo
>
>
> On 10 jun. 2014, at 10:14, Daan Hoogland  wrote:
>
>> Quite right:
>>
>>
>> -  Feasibility experiment plans by Schuberg Philis
>>
>> -  Reusable work by Karl
>>
>> -  Problems Citrix encountered with the regular redundant router 
>> (and how to avoid them)
>>
>> -  Work division
>>
>> -  (next meeting needed?)
>>
>> Any additions?
>>
>> \DaanH
>>
>> From: Sheng Yang [mailto:sh...@yasker.org]
>> Sent: dinsdag 10 juni 2014 1:39
>> To: Sander Botman
>> Cc: Daan Hoogland; Karl Harris; dev; Alena Prokharchyk; kis...@cloud.com; 
>> Christopher Litsinger; Hugo Trippaers; int-toolkit
>> Subject: Re: redundant virtual routers for VPCs
>>
>> BTW, do we have an agenda or some topics we want to discuss for the meeting? 
>> I just want to make sure it's efficient.
>>
>> --Sheng
>>
>> On Mon, Jun 9, 2014 at 1:14 PM, Sander Botman 
>> mailto:sbot...@schubergphilis.com>> wrote:
>> Hi all
>>
>> I can make 15:00.
>>
>> Cannon join at 20:00.
>>
>> Cheers Sander
>>
>> Verstuurd vanaf mijn iPhone
>>
>>> Op 9 jun. 2014 om 21:31 heeft "Daan Hoogland" 
>>> mailto:daan.hoogl...@gmail.com>> het volgende 
>>> geschreven:
>>>
>>> nice,
>>>
>>> so given pacific time I can have a meeting at 15:00 utc or at 20:00
>>> utc (8 am or 2 pm if I'm correct). Given office hours in Holland 17:00
>>> (15:00 utc) would be best but if you're not in it could be later. As
>>> the person calling the meeting I would like to participate but if the
>>> highest attendance can be found only between 16 and 22 utc thats fine
>>> as well.
>>>
 On Mon, Jun 9, 2014 at 8:35 PM, Karl Harris 
 mailto:karl.har...@sungardas.com>> wrote:
 I will be happy to join!



> On Saturday, June 7, 2014, Daan Hoogland 
> mailto:daan.hoogl...@gmail.com>> wrote:
>
> At Schuberg Philis, the urge to have virtual routers in a redundant
> way is getting to be pressing. It seems Citrix wants to move away from
> it entirely and Sungard is working on it but has to little resources
> for it. Withing our dev group we are now planning a sprint to
> experiment with this subject and then implement or fix the present
> routers to support this. However we would very much like input from
> the people who have already worked on this and are also very willing
> to let them in our sprint-team if they are willing.
>
> So: who want to join in a irc meeting (or conf call) on the subject
> coming week? Dutch people are not in the office on the day after
> ascension so tuesday is our intention.
>
> on behalf of some very impatient operators;)
> --
> Daan
>>>
>>>
>>>
>>> --
>>> Daan
>>
>



-- 
Daan

Re: Review Request 21973: CLOUDSTACK-6780: Resolved cleanup issue in portable ip test cases

[Ashutosh Kelkar]

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

(Updated June 10, 2014, 11:16 a.m.)


Review request for cloudstack, Girish Shilamkar and Santhosh Edukulla.


Changes
---

Santhosh, please take a look at updated patch.


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


Repository: cloudstack-git


Description
---

Portable IP address was not getting disassociated. Added it to finally block so 
that it will get associated always and portable ip range gets cleaned up 
properly during cleanup.


Diffs
-

  test/integration/component/test_portable_ip.py 847bb4a 

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


Testing
---

Test disassociating portable ip ... === TestName: 
test_disassociate_ip_address_no_services | Status : SUCCESS ===
ok
Test disassociating portable IP with non-owner account ... === TestName: 
test_disassociate_ip_address_other_account | Status : SUCCESS ===
ok
Test disassociating portable ip ... === TestName: 
test_disassociate_ip_address_services_enabled | Status : SUCCESS ===
ok

--
Ran 3 tests in 263.215s

OK


Thanks,

Ashutosh Kelkar

Re: [ACS44] Cherry pick request

[Daan Hoogland]

2 picked

On Tue, Jun 10, 2014 at 2:09 AM, Amogh Vasekar  wrote:
> Hi Daan,
>
> Request you to please cherry-pick the following two commits to 4.4 branch :
>
> 1. ac92b3690304ff224e7e2530ea7d8e39f28a05c3 for CLOUDSTACK-6710
> 2. a4b401f29f83f2f0b467a9d05b509f951b5a3bca for CLOUDSTACK-6358
>
> Thanks,
> Amogh
>



-- 
Daan

Review Request 22414: CLOUDSTACK-6865, CLOUDSTACK-6868: [hyper-v] attach volume of vhd format volume is failing

[Anshul Gangwar]

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

Review request for cloudstack, Devdeep Singh and Rajesh Battala.


Bugs: CLOUDSTACK-6865 and CLOUDSTACK-6868
https://issues.apache.org/jira/browse/CLOUDSTACK-6865
https://issues.apache.org/jira/browse/CLOUDSTACK-6868


Repository: cloudstack-git


Description
---

while attaching the volume we were changing the volume's Image format to 
hypervisor's default Image format, hence it was failing to find the volume with 
vhdx format
Now changed the behavior to set Image Format for volume only when it is not 
set


Diffs
-

  
engine/orchestration/src/org/apache/cloudstack/engine/orchestration/VolumeOrchestrator.java
 064ffca 

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


Testing
---

verified by uploading the vhd volume and attaching it to VM


Thanks,

Anshul Gangwar

Re: Review Request 22354: CLOUDSTACK-6850: Return cpu cores, cpu speed and memory in listUsageRecords

[ASF Subversion and Git Services]

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


Commit c934e7b052c09df2fae52a005e69951ed0235574 in cloudstack's branch 
refs/heads/4.4 from Olivier Lemasle
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=c934e7b ]

CLOUDSTACK-6850: Return cpu cores, cpu speed and memory in listUsageRecords

Signed-off-by: Sebastien Goasguen 
(cherry picked from commit a1f278e9d47e8029d58df6d3aae13495965ca434)


- ASF Subversion and Git Services


On June 8, 2014, 4:40 p.m., Olivier Lemasle wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/22354/
> ---
> 
> (Updated June 8, 2014, 4:40 p.m.)
> 
> 
> Review request for cloudstack and Kishan Kavala.
> 
> 
> Bugs: CLOUDSTACK-6850
> https://issues.apache.org/jira/browse/CLOUDSTACK-6850
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> This patch updates VMInstanceUsageParser to process usage details (cpu cores, 
> cpu speed and memory) for dynamic compute offering usages, in order to save 
> them in table cloud_usage.cloud_usage and return them with the API 
> (listUsageRecords).
> 
> See CLOUDSTACK-6850.
> 
> A change in database model is required for this patch (three new columns in 
> cloud_usage.cloud_usage).
> 
> The patch should apply on master and 4.4.
> 
> 
> Diffs
> -
> 
>   api/src/org/apache/cloudstack/api/response/UsageRecordResponse.java 5e2e85d 
>   api/src/org/apache/cloudstack/usage/Usage.java 20dc189 
>   engine/schema/src/com/cloud/usage/UsageVMInstanceVO.java 06d4876 
>   engine/schema/src/com/cloud/usage/UsageVO.java 67014ef 
>   engine/schema/src/com/cloud/usage/dao/UsageVMInstanceDaoImpl.java b94e12f 
>   server/src/com/cloud/api/ApiResponseHelper.java 119f56d 
>   setup/db/db/schema-430to440.sql d149a65 
>   usage/src/com/cloud/usage/parser/VMInstanceUsageParser.java ba0d4bf 
> 
> Diff: https://reviews.apache.org/r/22354/diff/
> 
> 
> Testing
> ---
> 
> Packaged in RPMs, installed and manually tested.
> 
> 1. Create a VM with compute offering "Small instance".
> 2. Stop the VM.
> 3. Change service offering to a custom offering, with cpu_number=1, 
> cpu_speed=500 MHz, memory=512 MB
> 4. Start the VM, wait... Stop the VM.
> 6. Change service offering to an other custom offering, with cpu_number=2, 
> cpu_speed=800 MHz, memory=1024 MB
> 7. Start the VM, wait... Stop the VM.
> 8. Change service offering to the first custom offering, with same "details" 
> (cpu_number=2, cpu_speed=800 MHz, memory=1024 MB)
> 9. Start the VM, wait... Stop the VM.
> 10. Change service offering to "Medium instance".
> 
> Usages and details are reflected in database and in API response. There is no 
> regression found for other usage types.
> Details are returned (and saved in database) only for RUNNING_VM and 
> ALLOCATED_VM, only if the service offering is a custom one.
> 
> Example of response:
> 
> 
> admin
> 184a6564-edab-11e3-b629-0050569ed71c
> fbc7578a-edaa-11e3-b629-0050569ed71c
> e5047089-c911-40ea-8251-4a76810ac1e0
> california allocated (ServiceOffering: 12) (Template: 
> 5)
> 0.098078 Hrs
> 2
> 0.098078
> e89c22af-65cf-42a2-8905-6f4bbd7d59a1
> california
> b05b64e9-8e0f-4335-b0e0-acc5bad81938
> fbca2564-edaa-11e3-b629-0050569ed71c
> e89c22af-65cf-42a2-8905-6f4bbd7d59a1
> XenServer
> 1
> 500
> 512
> 2014-06-08'T'17:05:52+02:00
> 2014-06-08'T'17:15:52+02:00
> 
> 
> admin
> 184a6564-edab-11e3-b629-0050569ed71c
> fbc7578a-edaa-11e3-b629-0050569ed71c
> e5047089-c911-40ea-8251-4a76810ac1e0
> california allocated (ServiceOffering: 1) (Template: 
> 5)
> 0.068594 Hrs
> 2
> 0.068594
> e89c22af-65cf-42a2-8905-6f4bbd7d59a1
> california
> 84bbf38f-b582-440b-8a8d-20e63e0dbed7
> fbca2564-edaa-11e3-b629-0050569ed71c
> e89c22af-65cf-42a2-8905-6f4bbd7d59a1
> XenServer
> 2014-06-08'T'17:05:52+02:00
> 2014-06-08'T'17:15:52+02:00
> 
> 
> 
> Thanks,
> 
> Olivier Lemasle
> 
>

Re: [ACS44] CS6850

[Daan Hoogland]

On Tue, Jun 10, 2014 at 9:13 AM, Sebastien Goasguen  wrote:
> a1f278e9d47e8029d58df6d3aae13495965ca434


is in

-- 
Daan

[ANNOUNCE] Pierre-Luc Dion as a committer

[sebgoa]

The Project Management Committee (PMC) for Apache CloudStack has
asked Pierre-Luc Dion to become a committer and we are pleased to announce
that he has accepted.

Being a committer allows many contributors to contribute more autonomously. For
developers, it makes it easier to submit changes and eliminates the need to
have contributions reviewed via the patch submission process. Whether
contributions are development-related or otherwise, it is a recognition of a
contributor's participation in the project and commitment to the project and
the Apache Way.

Please join me in congratulating Pierre-Luc!

PS: Nice work on the documentation

-Sebastien, on behalf of the CloudStack PMC

Re: [ANNOUNCE] Pierre-Luc Dion as a committer

[Rohit Yadav]

Congrats Pierre-Luc!

Regards.


On Tue, Jun 10, 2014 at 5:15 PM, sebgoa  wrote:

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

Re: Review Request 22354: CLOUDSTACK-6850: Return cpu cores, cpu speed and memory in listUsageRecords

[Olivier Lemasle]

> On June 10, 2014, 9:14 a.m., Sebastien Goasguen wrote:
> > Ok fine with me, I trust that you will stay on top of this, test and submit 
> > further fixes.
> > 
> > I applied your patch to master and 4.4-forward. It should be cherry-picked 
> > to 4.4
> > Nothing done to 4.3.
> > 
> >

Thanks. I commit myself to maintain this patch and other usage server features 
as far as I can.


- Olivier


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


On June 8, 2014, 6:40 p.m., Olivier Lemasle wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/22354/
> ---
> 
> (Updated June 8, 2014, 6:40 p.m.)
> 
> 
> Review request for cloudstack and Kishan Kavala.
> 
> 
> Bugs: CLOUDSTACK-6850
> https://issues.apache.org/jira/browse/CLOUDSTACK-6850
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> This patch updates VMInstanceUsageParser to process usage details (cpu cores, 
> cpu speed and memory) for dynamic compute offering usages, in order to save 
> them in table cloud_usage.cloud_usage and return them with the API 
> (listUsageRecords).
> 
> See CLOUDSTACK-6850.
> 
> A change in database model is required for this patch (three new columns in 
> cloud_usage.cloud_usage).
> 
> The patch should apply on master and 4.4.
> 
> 
> Diffs
> -
> 
>   api/src/org/apache/cloudstack/api/response/UsageRecordResponse.java 5e2e85d 
>   api/src/org/apache/cloudstack/usage/Usage.java 20dc189 
>   engine/schema/src/com/cloud/usage/UsageVMInstanceVO.java 06d4876 
>   engine/schema/src/com/cloud/usage/UsageVO.java 67014ef 
>   engine/schema/src/com/cloud/usage/dao/UsageVMInstanceDaoImpl.java b94e12f 
>   server/src/com/cloud/api/ApiResponseHelper.java 119f56d 
>   setup/db/db/schema-430to440.sql d149a65 
>   usage/src/com/cloud/usage/parser/VMInstanceUsageParser.java ba0d4bf 
> 
> Diff: https://reviews.apache.org/r/22354/diff/
> 
> 
> Testing
> ---
> 
> Packaged in RPMs, installed and manually tested.
> 
> 1. Create a VM with compute offering "Small instance".
> 2. Stop the VM.
> 3. Change service offering to a custom offering, with cpu_number=1, 
> cpu_speed=500 MHz, memory=512 MB
> 4. Start the VM, wait... Stop the VM.
> 6. Change service offering to an other custom offering, with cpu_number=2, 
> cpu_speed=800 MHz, memory=1024 MB
> 7. Start the VM, wait... Stop the VM.
> 8. Change service offering to the first custom offering, with same "details" 
> (cpu_number=2, cpu_speed=800 MHz, memory=1024 MB)
> 9. Start the VM, wait... Stop the VM.
> 10. Change service offering to "Medium instance".
> 
> Usages and details are reflected in database and in API response. There is no 
> regression found for other usage types.
> Details are returned (and saved in database) only for RUNNING_VM and 
> ALLOCATED_VM, only if the service offering is a custom one.
> 
> Example of response:
> 
> 
> admin
> 184a6564-edab-11e3-b629-0050569ed71c
> fbc7578a-edaa-11e3-b629-0050569ed71c
> e5047089-c911-40ea-8251-4a76810ac1e0
> california allocated (ServiceOffering: 12) (Template: 
> 5)
> 0.098078 Hrs
> 2
> 0.098078
> e89c22af-65cf-42a2-8905-6f4bbd7d59a1
> california
> b05b64e9-8e0f-4335-b0e0-acc5bad81938
> fbca2564-edaa-11e3-b629-0050569ed71c
> e89c22af-65cf-42a2-8905-6f4bbd7d59a1
> XenServer
> 1
> 500
> 512
> 2014-06-08'T'17:05:52+02:00
> 2014-06-08'T'17:15:52+02:00
> 
> 
> admin
> 184a6564-edab-11e3-b629-0050569ed71c
> fbc7578a-edaa-11e3-b629-0050569ed71c
> e5047089-c911-40ea-8251-4a76810ac1e0
> california allocated (ServiceOffering: 1) (Template: 
> 5)
> 0.068594 Hrs
> 2
> 0.068594
> e89c22af-65cf-42a2-8905-6f4bbd7d59a1
> california
> 84bbf38f-b582-440b-8a8d-20e63e0dbed7
> fbca2564-edaa-11e3-b629-0050569ed71c
> e89c22af-65cf-42a2-8905-6f4bbd7d59a1
> XenServer
> 2014-06-08'T'17:05:52+02:00
> 2014-06-08'T'17:15:52+02:00
> 
> 
> 
> Thanks,
> 
> Olivier Lemasle
> 
>

Re: Review Request 22356: Fixed few coverity issues reported

[daan Hoogland]

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


most of it looks good. thanks for great work.

Have a closer look at the Connection conn = tx.getConnection() statements These 
should be solved more elegant/robust. And remove the commits that might be 
partially. They defeat the purpose of transactions.


engine/schema/src/com/cloud/upgrade/DatabaseIntegrityChecker.java


a commit in a finally when try-with-resource used seems not what you want. 
What do you expect to be committed here?



engine/schema/src/com/cloud/upgrade/DatabaseIntegrityChecker.java


put in the try() clause if it needs closing



engine/schema/src/com/cloud/upgrade/DatabaseIntegrityChecker.java


use CloudRuntimeException(String msg, Exception e) if you want the pass 
root cause.



engine/schema/src/com/cloud/upgrade/DatabaseIntegrityChecker.java


spelling: premium(g)



engine/schema/src/com/cloud/upgrade/DatabaseIntegrityChecker.java


use CloudRuntimeException(msg,e)



engine/schema/src/com/cloud/upgrade/DatabaseIntegrityChecker.java


a commit in a finally means you might partialy commit. That is not what you 
want.



engine/schema/src/com/cloud/upgrade/DatabaseIntegrityChecker.java


find another solution for close in the finally: in the try() or outside the 
block!



framework/db/src/com/cloud/utils/crypt/EncryptionSecretKeyChanger.java


some better naming for the second statement is a welcome luxury;)



framework/db/src/com/cloud/utils/db/TransactionLegacy.java


maybe you want to put type.equals(item.type) and some extra check to 
prevent NPEs?
and use a similar construct for item.ref?



server/src/com/cloud/test/IPRangeConfig.java


Is Connection not Closable?



server/src/com/cloud/test/IPRangeConfig.java


good riddens :)


- daan Hoogland


On June 10, 2014, 4:43 a.m., Santhosh Edukulla wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/22356/
> ---
> 
> (Updated June 10, 2014, 4:43 a.m.)
> 
> 
> Review request for cloudstack and daan Hoogland.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Fixed few coverity issues reported for resource leak, value comparison, 
> invalid loop check for result set.
> 
> 
> Diffs
> -
> 
>   engine/schema/src/com/cloud/upgrade/DatabaseCreator.java 91ef318 
>   engine/schema/src/com/cloud/upgrade/DatabaseIntegrityChecker.java c20a418 
>   engine/schema/src/com/cloud/upgrade/DatabaseUpgradeChecker.java 0761c9f 
>   framework/db/src/com/cloud/utils/crypt/EncryptionSecretKeyChanger.java 
> 58584f9 
>   framework/db/src/com/cloud/utils/db/Merovingian2.java 6eeea9f 
>   framework/db/src/com/cloud/utils/db/ScriptRunner.java 6614527 
>   framework/db/src/com/cloud/utils/db/TransactionLegacy.java ac0ea21 
>   server/src/com/cloud/test/IPRangeConfig.java 1d56471 
>   usage/src/com/cloud/usage/UsageSanityChecker.java 5e6123b 
>   utils/src/com/cloud/utils/crypt/EncryptionSecretKeySender.java 086e8a8 
> 
> Diff: https://reviews.apache.org/r/22356/diff/
> 
> 
> Testing
> ---
> 
> 1.Built the code and found no issues.
> 2.Built the simulator and ran a deploy datacenter with the changes.
> 
> 
> Thanks,
> 
> Santhosh Edukulla
> 
>

Re: hackathon CCCEU14

[Daan Hoogland]

Hello everybody,

Do we still want to have a Hackathon next CCC? we need to plan for the
resources (noticably the room) pretty soon.

On Thu, Jun 5, 2014 at 12:01 PM, Daan Hoogland
 wrote:
> People,
>
> I added two more hackathon subjects at 
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/CloudStack+Collaboration+Conference+EU
> In doing so I saw no moderators on the hackathons that were already 
> announced. We need moderators to have successful hackathons. If  you feel a 
> hackathon subject is important enough to go through, please add your name in 
> the wiki. Only hackathons with enough attendance will have resources assigned 
> at the conference.
>
> \DaanH
>



-- 
Daan

Re: redundant virtual routers for VPCs

[Karl Harris]

Recovering from a laptop hard disk crash should be back online by 22:00 UTC!

Karl


On Tuesday, June 10, 2014, Daan Hoogland  wrote:

> I would like to have Hugo in the meeting So let's make it 20:00 UTC
>
> I would suggest #cloudstack-meeting
>
> On Tue, Jun 10, 2014 at 10:29 AM, Hugo Trippaers 
> wrote:
> >
> > I can’t make 15:00, but 22:00 could work.
> >
> > Cheers,
> >
> > Hugo
> >
> >
> > On 10 jun. 2014, at 10:14, Daan Hoogland 
> wrote:
> >
> >> Quite right:
> >>
> >>
> >> -  Feasibility experiment plans by Schuberg Philis
> >>
> >> -  Reusable work by Karl
> >>
> >> -  Problems Citrix encountered with the regular redundant
> router (and how to avoid them)
> >>
> >> -  Work division
> >>
> >> -  (next meeting needed?)
> >>
> >> Any additions?
> >>
> >> \DaanH
> >>
> >> From: Sheng Yang [mailto:sh...@yasker.org]
> >> Sent: dinsdag 10 juni 2014 1:39
> >> To: Sander Botman
> >> Cc: Daan Hoogland; Karl Harris; dev; Alena Prokharchyk;
> kis...@cloud.com; Christopher Litsinger; Hugo Trippaers; int-toolkit
> >> Subject: Re: redundant virtual routers for VPCs
> >>
> >> BTW, do we have an agenda or some topics we want to discuss for the
> meeting? I just want to make sure it's efficient.
> >>
> >> --Sheng
> >>
> >> On Mon, Jun 9, 2014 at 1:14 PM, Sander Botman <
> sbot...@schubergphilis.com> wrote:
> >> Hi all
> >>
> >> I can make 15:00.
> >>
> >> Cannon join at 20:00.
> >>
> >> Cheers Sander
> >>
> >> Verstuurd vanaf mijn iPhone
> >>
> >>> Op 9 jun. 2014 om 21:31 heeft "Daan Hoogland"  > het volgende geschreven:
> >>>
> >>> nice,
> >>>
> >>> so given pacific time I can have a meeting at 15:00 utc or at 20:00
> >>> utc (8 am or 2 pm if I'm correct). Given office hours in Holland 17:00
> >>> (15:00 utc) would be best but if you're not in it could be later. As
> >>> the person calling the meeting I would like to participate but if the
> >>> highest attendance can be found only between 16 and 22 utc thats fine
> >>> as well.
> >>>
>  On Mon, Jun 9, 2014 at 8:35 PM, Karl Harris <
> karl.har...@sungardas.com> wrote:
>  I will be happy to join!
> 
> 
> 
> > On Saturday, June 7, 2014, Daan Hoogland  > wrote:
> >
> > At Schuberg Philis, the urge to have virtual routers in a redundant
> > way is getting to be pressing. It seems Citrix wants to move away
> from
> > it entirely and Sungard is working on it but has to little resources
> > for it. Withing our dev group we are now planning a sprint to
> > experiment with this subject and then implement or fix the present
> > routers to support this. However we would very much like input from
> > the people who have already worked on this and are also very willing
> > to let them in our sprint-team if they are willing.
> >
> > So: who want to join in a irc meeting (or conf call) on the subject
> > coming week? Dutch people are not in the office on the day after
> > ascension so tuesday is our intention.
> >
> --
> Daan
>

RE: redundant virtual routers for VPCs

[Daan Hoogland]

Karl, That’s midnight over here! :(

\DaanH

From: Karl Harris [mailto:karl.har...@sungardas.com]
Sent: dinsdag 10 juni 2014 2:43
To: Daan Hoogland
Cc: Hugo Trippaers; dev; Sheng Yang; Sander Botman; Alena Prokharchyk; 
kis...@cloud.com; Christopher Litsinger; Hugo Trippaers; int-toolkit
Subject: Re: redundant virtual routers for VPCs

Recovering from a laptop hard disk crash should be back online by 22:00 UTC!

Karl


On Tuesday, June 10, 2014, Daan Hoogland 
mailto:daan.hoogl...@gmail.com>> wrote:
I would like to have Hugo in the meeting So let's make it 20:00 UTC

I would suggest #cloudstack-meeting

On Tue, Jun 10, 2014 at 10:29 AM, Hugo Trippaers 
mailto:h...@trippaers.nl>> wrote:
>
> I can’t make 15:00, but 22:00 could work.
>
> Cheers,
>
> Hugo
>
>
> On 10 jun. 2014, at 10:14, Daan Hoogland 
> mailto:dhoogl...@schubergphilis.com>> wrote:
>
>> Quite right:
>>
>>
>> -  Feasibility experiment plans by Schuberg Philis
>>
>> -  Reusable work by Karl
>>
>> -  Problems Citrix encountered with the regular redundant router 
>> (and how to avoid them)
>>
>> -  Work division
>>
>> -  (next meeting needed?)
>>
>> Any additions?
>>
>> \DaanH
>>
>> From: Sheng Yang [mailto:sh...@yasker.org]
>> Sent: dinsdag 10 juni 2014 1:39
>> To: Sander Botman
>> Cc: Daan Hoogland; Karl Harris; dev; Alena Prokharchyk; 
>> kis...@cloud.com; Christopher Litsinger; Hugo 
>> Trippaers; int-toolkit
>> Subject: Re: redundant virtual routers for VPCs
>>
>> BTW, do we have an agenda or some topics we want to discuss for the meeting? 
>> I just want to make sure it's efficient.
>>
>> --Sheng
>>
>> On Mon, Jun 9, 2014 at 1:14 PM, Sander Botman 
>> mailto:sbot...@schubergphilis.com>>
>>  wrote:
>> Hi all
>>
>> I can make 15:00.
>>
>> Cannon join at 20:00.
>>
>> Cheers Sander
>>
>> Verstuurd vanaf mijn iPhone
>>
>>> Op 9 jun. 2014 om 21:31 heeft "Daan Hoogland" 
>>> mailto:daan.hoogl...@gmail.com>>
>>>  het volgende geschreven:
>>>
>>> nice,
>>>
>>> so given pacific time I can have a meeting at 15:00 utc or at 20:00
>>> utc (8 am or 2 pm if I'm correct). Given office hours in Holland 17:00
>>> (15:00 utc) would be best but if you're not in it could be later. As
>>> the person calling the meeting I would like to participate but if the
>>> highest attendance can be found only between 16 and 22 utc thats fine
>>> as well.
>>>
 On Mon, Jun 9, 2014 at 8:35 PM, Karl Harris 
 mailto:karl.har...@sungardas.com>>
  wrote:
 I will be happy to join!



> On Saturday, June 7, 2014, Daan Hoogland 
> mailto:daan.hoogl...@gmail.com>>
>  wrote:
>
> At Schuberg Philis, the urge to have virtual routers in a redundant
> way is getting to be pressing. It seems Citrix wants to move away from
> it entirely and Sungard is working on it but has to little resources
> for it. Withing our dev group we are now planning a sprint to
> experiment with this subject and then implement or fix the present
> routers to support this. However we would very much like input from
> the people who have already worked on this and are also very willing
> to let them in our sprint-team if they are willing.
>
> So: who want to join in a irc meeting (or conf call) on the subject
> coming week? Dutch people are not in the office on the day after
> ascension so tuesday is our intention.
>
--
Daan

Re: redundant virtual routers for VPCs

[Karl Harris]

20:00 utc ;-) missed the last change in time!


Karl


On Tuesday, June 10, 2014, Daan Hoogland 
wrote:

>  Karl, That’s midnight over here! :(
>
>
>
> *\*DaanH
>
>
>
> *From:* Karl Harris [mailto:karl.har...@sungardas.com
> ]
> *Sent:* dinsdag 10 juni 2014 2:43
> *To:* Daan Hoogland
> *Cc:* Hugo Trippaers; dev; Sheng Yang; Sander Botman; Alena Prokharchyk;
> kis...@cloud.com ;
> Christopher Litsinger; Hugo Trippaers; int-toolkit
> *Subject:* Re: redundant virtual routers for VPCs
>
>
>
> Recovering from a laptop hard disk crash should be back online by 22:00
> UTC!
>
>
>
> Karl
>
>
>
> On Tuesday, June 10, 2014, Daan Hoogland  wrote:
>
> I would like to have Hugo in the meeting So let's make it 20:00 UTC
>
> I would suggest #cloudstack-meeting
>
> On Tue, Jun 10, 2014 at 10:29 AM, Hugo Trippaers 
> wrote:
> >
> > I can’t make 15:00, but 22:00 could work.
> >
> > Cheers,
> >
> > Hugo
> >
> >
> > On 10 jun. 2014, at 10:14, Daan Hoogland 
> wrote:
> >
> >> Quite right:
> >>
> >>
> >> -  Feasibility experiment plans by Schuberg Philis
> >>
> >> -  Reusable work by Karl
> >>
> >> -  Problems Citrix encountered with the regular redundant
> router (and how to avoid them)
> >>
> >> -  Work division
> >>
> >> -  (next meeting needed?)
> >>
> >> Any additions?
> >>
> >> \DaanH
> >>
> >> From: Sheng Yang [mailto:sh...@yasker.org]
> >> Sent: dinsdag 10 juni 2014 1:39
> >> To: Sander Botman
> >> Cc: Daan Hoogland; Karl Harris; dev; Alena Prokharchyk;
> kis...@cloud.com; Christopher Litsinger; Hugo Trippaers; int-toolkit
> >> Subject: Re: redundant virtual routers for VPCs
> >>
> >> BTW, do we have an agenda or some topics we want to discuss for the
> meeting? I just want to make sure it's efficient.
> >>
> >> --Sheng
> >>
> >> On Mon, Jun 9, 2014 at 1:14 PM, Sander Botman <
> sbot...@schubergphilis.com> wrote:
> >> Hi all
> >>
> >> I can make 15:00.
> >>
> >> Cannon join at 20:00.
> >>
> >> Cheers Sander
> >>
> >> Verstuurd vanaf mijn iPhone
> >>
> >>> Op 9 jun. 2014 om 21:31 heeft "Daan Hoogland" <
> daan.hoogl...@gmail.com> het volgende
> geschreven:
> >>>
> >>> nice,
> >>>
> >>> so given pacific time I can have a meeting at 15:00 utc or at 20:00
> >>> utc (8 am or 2 pm if I'm correct). Given office hours in Holland 17:00
> >>> (15:00 utc) would be best but if you're not in it could be later. As
> >>> the person calling the meeting I would like to participate but if the
> >>> highest attendance can be found only between 16 and 22 utc thats fine
> >>> as well.
> >>>
>  On Mon, Jun 9, 2014 at 8:35 PM, Karl Harris <
> karl.har...@sungardas.com> wrote:
>  I will be happy to join!
> 
> 
> 
> > On Saturday, June 7, 2014, Daan Hoogland <
> daan.hoogl...@gmail.com> wrote:
> >
> > At Schuberg Philis, the urge to have virtual routers in a redundant
> > way is getting to be pressing. It seems Citrix wants to move away
> from
> > it entirely and Sungard is working on it but has to little resources
> > for it. Withing our dev group we are now planning a sprint to
> > experiment with this subject and then implement or fix the present
> > routers to support this. However we would very much like input from
> > the people who have already worked on this and are also
>

Re: Review Request 21375: CLOUDSTACK-6654: Configkey parameters are not validated

[ASF Subversion and Git Services]

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


Commit 5bcd017de6f421a6125406120b39fb8602276dc7 in cloudstack's branch 
refs/heads/4.4-forward from Saksham Srivastava
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=5bcd017 ]

CLOUDSTACK-6654: Configkey parameters are not validated


- ASF Subversion and Git Services


On May 13, 2014, 1:01 p.m., Saksham Srivastava wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/21375/
> ---
> 
> (Updated May 13, 2014, 1:01 p.m.)
> 
> 
> Review request for cloudstack, Abhinandan Prateek and Devdeep Singh.
> 
> 
> Bugs: CLOUDSTACK-6654
> https://issues.apache.org/jira/browse/CLOUDSTACK-6654
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> ConfigKey variables values are not validated. So anything  like -5.6 or “abc” 
>  as the value of cpu/memory/storage overprovision factors can be set. 
> Similarly for all of the variables in ConfigKey.
> We have a verification mechanism but it is never executed. The code is 
> unreachable in the preset 4.4
> 
> In ConfigurationManagerImpl.java: validateConfigurationValue()
>  
> Config c = Config.getConfig(name);
>  if (c == null) {
> s_logger.warn("Did not find configuration " + name + " in Config.java. 
> Perhaps moved to ConfigDepot?");
> -return null;
> }
> Since for the ConfigKey parameters ‘c’ is always null, we return null and do 
> not further validate.
> 
> Fix is to make sure type is validated by using  _configDepot.get(name)
> 
> Note: Configkey does not have a range flag. Each range param has to be 
> considered as per case basis.
> Added comments for the same.
> 
> 
> Diffs
> -
> 
>   server/src/com/cloud/configuration/ConfigurationManagerImpl.java 231b5e1 
> 
> Diff: https://reviews.apache.org/r/21375/diff/
> 
> 
> Testing
> ---
> 
> Tested both Configkey variables as well as old Config parameters.
> ConfigKey values are now validated before setting them in db.
> 
> The following status message appears when cpu.overprovisioning.factor is set 
> to incorrect value.
> There was an error trying to parse the float value for: 
> cpu.overprovisioning.factor
> 
> Build passes.
> Findbug is clean.
> 
> 
> Thanks,
> 
> Saksham Srivastava
> 
>

Re: hackathon CCCEU14

[Rohit Yadav]

Hi Daan,

I'm up for the new (restful/hateoas) API redesign and unit tests!

Regards.


On Tue, Jun 10, 2014 at 6:05 PM, Daan Hoogland 
wrote:

> Hello everybody,
>
> Do we still want to have a Hackathon next CCC? we need to plan for the
> resources (noticably the room) pretty soon.
>
> On Thu, Jun 5, 2014 at 12:01 PM, Daan Hoogland
>  wrote:
> > People,
> >
> > I added two more hackathon subjects at
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/CloudStack+Collaboration+Conference+EU
> > In doing so I saw no moderators on the hackathons that were already
> announced. We need moderators to have successful hackathons. If  you feel a
> hackathon subject is important enough to go through, please add your name
> in the wiki. Only hackathons with enough attendance will have resources
> assigned at the conference.
> >
> > \DaanH
> >
>
>
>
> --
> Daan
>

Re: feature : changing volume properties dynamically in 4.5

[Punith S]

hi mike,

thanks for the reply, i like your approach which is a very generic way and
also we only need to do a few changes to the current cloudstack,

but on the other hand we are tying every property of the vendor to a disk
offering through key/value pairs, since we offer lot of properties like i
mentioned, this can create a lot of permutation combinations of disk
offerings, for say if i need to turn deduplication On for a specific volume
, should i have to create a new disk offering having current properties
with deduplication On?

is this approach already implemented in the current master ?

and also like you mentioned about exposing a new api, is it okay if i
expose our own api in my util by extending the PlugableService like in
network plugins ?

thanks.


On Tue, Jun 10, 2014 at 1:17 AM, Mike Tutkowski <
mike.tutkow...@solidfire.com> wrote:

> Allow me to follow this up with more detail (with regards to what Chris
> and I talked about):
>
> As you are aware, today the way you associate a Compute Offering (CO) or a
> Disk Offering (DO) with a Primary Storage (PS) is via storage tagging.
>
> This has some benefits and drawbacks.
>
> One benefit is being able to have some level of vendor independence from
> the point of view of the CO or DO. For example, if the storage tag of a DO
> is "Fast", then this can be satisfied by PS that describes itself as
> "Fast", regardless of vendor.
>
> A major drawback with the storage-tagging approach, however, is that you
> are not easily able to leverage vendor-specific features, which is often
> why you bought storage from the vendor in question to begin with.
>
> Ideally we do not want to add each vendor's features into the system as
> properties that can be seen by the admin regardless of whether or not the
> underlying storage he's actually using supports the feature in question.
>
> This coarse approach, however, was sort of business as usual when I
> started in with CloudStack 1.5 years ago.
>
> That being the case, when I added QoS options to CS, I did so in a way
> where the admin would see Min IOPS and Max IOPS options regardless of
> whether or not his storage actually supported those controls (to mitigate
> this a bit in the GUI, the admin has to explicitly select "Storage QoS"
> from a combobox).
>
> We leverage the same use model with Hypervisor QoS: The admin sees these
> options regardless of whether or not they actually apply on the hypervisor
> where the VM gets deployed.
>
> Going forward, we want to implement a more fine-grain and generic approach.
>
> We would like to have a storage provider field for the CO and DO windows
> (this equates to the name of one and only one storage provider). If the
> admin inputs a specific storage provider and does not use the storage tags
> field, he can enter in an arbitrary number of key/value pairs in another
> text field (perhaps we would provide a nice entry dialog to make this
> easier in the GUI). These key value pairs can be passed into the storage
> driver when it's asked to create (or update) a volume and the storage
> driver can decide what each and every key/value pair means.
>
> What do you think about this approach?
>
> Thanks
>
>
> On Mon, Jun 9, 2014 at 1:14 PM, Mike Tutkowski <
> mike.tutkow...@solidfire.com> wrote:
>
>> Hi Punith,
>>
>> This kind of a feature is something Chris Suich and I discussed a while
>> back.
>>
>> We talked about leveraging arbitrary key/value pairs to make this happen
>> (OpenStack does something similar). The key/value pairs would be vendor
>> specific.
>>
>> If we take a key/value approach, we might be able to make this all work
>> the way things work today when the user wants to change an existing Compute
>> Offering and/or Disk Offering.
>>
>> For example, the user would pick a new Compute Offering (with presumably
>> has different key/value pairs) and CloudStack could inform the applicable
>> storage provider, who could update the volume in question.
>>
>> This way we don't need to introduce a new API command and the use model
>> for the user doesn't really change.
>>
>> What are you thoughts on this?
>>
>> Thanks,
>> Mike
>>
>>
>> On Mon, Jun 9, 2014 at 8:08 AM, Punith S  wrote:
>>
>>> hi guys,
>>>
>>> since most of the third party storage providers have been implementing
>>> 1:1 mapping(managed storage) between a volume(dataset) and a vm
>>> disk(vdi/vmdk) for guaranteeing the Qos, i would like to propose a new
>>> feature to dynamically change the volume properties supported by storage
>>> vendors such as IOPS, Deduplication, Compression, Grace, Syncronization,
>>> Latency etc, depending on properties and features supported by respective
>>> storage vendors. hence providing more flexibility for users.
>>>
>>> in case of using default cloudstack storage provider, we can change the
>>> properties of the vdi/vmdk files apart from resizing the volume(vdi/vmdk).
>>>
>>> changes in management server include,
>>>
>>> new async web api ChangeVolumePropertiesCmd,
>>> new m

[CS 4.3 | XenServer] Unable to start Virtual Router (com.cloud.exception.AgentUnavailableException)

[Florin Dumitrascu]

Hi,

Could anyone please help with the following issue I am seeing?
I am running CloudStack 4.3 and XenServer 6.2 (SP1)

I have removed a host which was working normally and re-added it (it is Host 15 
in the log appended).
The communication with the host seems to be established as shown in the GUI 
(State is "Up").
However, every attempt to start a Virtual Router on that host is failing. The 
reasons that seem to be related to the issue are (as seen in the appended log):

"Unable to get the template/scripts version of router r-187-VM due to: 
getDomRVersionCmd failed"
"com.cloud.exception.AgentUnavailableException: Resource [Host:15] is 
unreachable"

How can I further debug this ? How can I check the state of the agent running 
on XenServer ?

Thank you for your help,
Florin

Debug Log
---

2014-06-10 14:14:10,549 DEBUG [c.c.a.m.DirectAgentAttache] 
(DirectAgent-292:ctx-fb46119b) Seq 15-1518796837: Response Received:
2014-06-10 14:14:10,551 DEBUG [c.c.a.t.Request] (DirectAgent-292:ctx-fb46119b) 
Seq 15-1518796837: Processing:  { Ans: , MgmtId: 123561959226, via: 15, Ver: 
v1, Flags: 10, [{"com.cloud.agent.api.StartAnswer":{
"vm":{"id":187,"name":"r-187-VM","bootloader":"PyGrub","type":"DomainRouter","cpus":1,"minSpeed":500,"maxSpeed":500,"minRam":134217728,"maxRam":134217728,"arch":"x86_64","os":"Debian
 GNU/Linux 7(32-bit)","boo
tArgs":" template=domP name=r-187-VM eth2ip=192.168.18.22 
eth2mask=255.255.252.0 gateway=192.168.16.1 eth0ip=10.10.2.1 
eth0mask=255.255.255.0 domain=cs2cloud.internal dhcprange=10.10.2.1 
eth1ip=169.254.2.254
eth1mask=255.255.0.0 type=router disable_rp_filter=true dns1=192.168.20.18 
dns2=192.168.20.81","rebootOnCrash":false,"enableHA":true,"limitCpuUse":false,"enableDynamicallyScaleVm":false,"vncPassword":"128a547
57b1466cc","params":{},"uuid":"035c06a8-8b08-46e7-88ef-ac128b1e2aeb","disks":[{"data":{"org.apache.cloudstack.storage.to.VolumeObjectTO":{"uuid":"9c8b32ff-8864-4681-acb3-3a76b0c04d91","volumeType":"ROOT","dat
aStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"d9242b8f-5342-3225-bda3-8b79202af571","id":19,"poolType":"IscsiLUN","host":"10.20.1.12","path":"/iqn.2014-03.local.intune:cloudstorsrv3.
target1/1","port":3260,"url":"IscsiLUN://10.20.1.12//iqn.2014-03.local.intune:cloudstorsrv3.target1/1/?ROLE=Primary&STOREUUID=d9242b8f-5342-3225-bda3-8b79202af571"}},"name":"ROOT-187","size":262144,"path"
:"05b0fb51-f725-46e5-8af0-43884bfd6edf","volumeId":228,"vmName":"r-187-VM","accountId":2,"format":"VHD","id":228,"deviceId":0,"hypervisorType":"XenServer"}},"diskSeq":0,"path":"05b0fb51-f725-46e5-8af0-43884bf
d6edf","type":"ROOT","_details":{"managed":"false","storagePort":"3260","storageHost":"10.20.1.12","volumeSize":"262144"}}],"nics":[{"deviceId":2,"networkRateMbps":200,"defaultNic":true,"uuid":"52d1b19d-b
053-4358-9659-6462f4d320ba","ip":"192.168.18.22","netmask":"255.255.252.0","gateway":"192.168.16.1","mac":"06:2c:bc:00:00:22","dns1":"192.168.20.18","dns2":"192.168.20.81","broadcastType":"Vlan","type":"Publi
c","broadcastUri":"vlan://untagged","isolationUri":"vlan://untagged","isSecurityGroupEnabled":false,"name":"PUBLIC"},{"deviceId":0,"networkRateMbps":200,"defaultNic":false,"uuid":"ea1180aa-9889-4db5-8414-6d0b
b9653f65","ip":"10.10.2.1","netmask":"255.255.255.0","mac":"02:00:4a:0a:00:02","dns1":"192.168.20.18","dns2":"192.168.20.81","broadcastType":"Vswitch","type":"Guest","broadcastUri":"vs://385","isolationUri":"
vs://385","isSecurityGroupEnabled":false,"name":"GUEST"},{"deviceId":1,"networkRateMbps":-1,"defaultNic":false,"uuid":"c17a414d-e0d1-4ff8-80a3-6db65c5af96e","ip":"169.254.2.254","netmask":"255.255.0.0","gatew
ay":"169.254.0.1","mac":"0e:00:a9:fe:02:fe","broadcastType":"LinkLocal","type":"Control","isSecurityGroupEnabled":false}]},"_iqnToPath":{},"result":true,"wait":0}},{"com.cloud.agent.api.check.CheckSshAnswer":
{"result":true,"wait":0}},{"com.cloud.agent.api.GetDomRVersionAnswer":{"result":false,"details":"getDomRVersionCmd
 failed","wait":0}}] }
2014-06-10 14:14:10,551 DEBUG [c.c.a.t.Request] (Job-Executor-17:ctx-7e9e98c6 
ctx-8fd8ddc7) Seq 15-1518796837: Received:  { Ans: , MgmtId: 123561959226, via: 
15, Ver: v1, Flags: 10, { StartAnswer, CheckSshAns
wer, GetDomRVersionAnswer } }
2014-06-10 14:14:10,602 WARN  [c.c.n.r.VirtualNetworkApplianceManagerImpl] 
(Job-Executor-17:ctx-7e9e98c6 ctx-8fd8ddc7) Unable to get the template/scripts 
version of router r-187-VM due to: getDomRVersionCmd f
ailed
2014-06-10 14:14:10,602 INFO  [c.c.v.VirtualMachineManagerImpl] 
(Job-Executor-17:ctx-7e9e98c6 ctx-8fd8ddc7) The guru did not like the answers 
so stopping VM[DomainRouter|r-187-VM]
2014-06-10 14:14:10,605 DEBUG [c.c.a.t.Request] (Job-Executor-17:ctx-7e9e98c6 
ctx-8fd8ddc7) Seq 15-1518796840: Sending  { Cmd , MgmtId: 123561959226, via: 
15(xenserver2), Ver: v1, Flags: 100011, [{"com.cloud.
agent.api.StopCommand":{"isProxy":false,"executeInSequence":false,"vmName":"r-187-VM","wait":0}}]
 }
2014-06-10 14:14:10,605 DEBUG [c

Re: redundant virtual routers for VPCs

[Daan Hoogland]

ok, write you then.

On Tue, Jun 10, 2014 at 2:52 PM, Karl Harris  wrote:
> 20:00 utc ;-) missed the last change in time!
>
>
> Karl
>
>
> On Tuesday, June 10, 2014, Daan Hoogland 
> wrote:
>>
>> Karl, That’s midnight over here! :(
>>
>>
>>
>> \DaanH
>>
>>
>>
>> From: Karl Harris [mailto:karl.har...@sungardas.com]
>> Sent: dinsdag 10 juni 2014 2:43
>> To: Daan Hoogland
>> Cc: Hugo Trippaers; dev; Sheng Yang; Sander Botman; Alena Prokharchyk;
>> kis...@cloud.com; Christopher Litsinger; Hugo Trippaers; int-toolkit
>> Subject: Re: redundant virtual routers for VPCs
>>
>>
>>
>> Recovering from a laptop hard disk crash should be back online by 22:00
>> UTC!
>>
>>
>>
>> Karl
>>
>>
>>
>> On Tuesday, June 10, 2014, Daan Hoogland  wrote:
>>
>> I would like to have Hugo in the meeting So let's make it 20:00 UTC
>>
>> I would suggest #cloudstack-meeting
>>
>> On Tue, Jun 10, 2014 at 10:29 AM, Hugo Trippaers 
>> wrote:
>> >
>> > I can’t make 15:00, but 22:00 could work.
>> >
>> > Cheers,
>> >
>> > Hugo
>> >
>> >
>> > On 10 jun. 2014, at 10:14, Daan Hoogland 
>> > wrote:
>> >
>> >> Quite right:
>> >>
>> >>
>> >> -  Feasibility experiment plans by Schuberg Philis
>> >>
>> >> -  Reusable work by Karl
>> >>
>> >> -  Problems Citrix encountered with the regular redundant
>> >> router (and how to avoid them)
>> >>
>> >> -  Work division
>> >>
>> >> -  (next meeting needed?)
>> >>
>> >> Any additions?
>> >>
>> >> \DaanH
>> >>
>> >> From: Sheng Yang [mailto:sh...@yasker.org]
>> >> Sent: dinsdag 10 juni 2014 1:39
>> >> To: Sander Botman
>> >> Cc: Daan Hoogland; Karl Harris; dev; Alena Prokharchyk;
>> >> kis...@cloud.com; Christopher Litsinger; Hugo Trippaers; int-toolkit
>> >> Subject: Re: redundant virtual routers for VPCs
>> >>
>> >> BTW, do we have an agenda or some topics we want to discuss for the
>> >> meeting? I just want to make sure it's efficient.
>> >>
>> >> --Sheng
>> >>
>> >> On Mon, Jun 9, 2014 at 1:14 PM, Sander Botman
>> >> mailto:sbot...@schubergphilis.com>> wrote:
>> >> Hi all
>> >>
>> >> I can make 15:00.
>> >>
>> >> Cannon join at 20:00.
>> >>
>> >> Cheers Sander
>> >>
>> >> Verstuurd vanaf mijn iPhone
>> >>
>> >>> Op 9 jun. 2014 om 21:31 heeft "Daan Hoogland"
>> >>> mailto:daan.hoogl...@gmail.com>> het volgende
>> >>> geschreven:
>> >>>
>> >>> nice,
>> >>>
>> >>> so given pacific time I can have a meeting at 15:00 utc or at 20:00
>> >>> utc (8 am or 2 pm if I'm correct). Given office hours in Holland 17:00
>> >>> (15:00 utc) would be best but if you're not in it could be later. As
>> >>> the person calling the meeting I would like to participate but if the
>> >>> highest attendance can be found only between 16 and 22 utc thats fine
>> >>> as well.
>> >>>
>>  On Mon, Jun 9, 2014 at 8:35 PM, Karl Harris
>>  mailto:karl.har...@sungardas.com>> wrote:
>>  I will be happy to join!
>> 
>> 
>> 
>> > On Saturday, June 7, 2014, Daan Hoogland
>> > mailto:daan.hoogl...@gmail.com>> wrote:
>> >
>> > At Schuberg Philis, the urge to have virtual routers in a redundant
>> > way is getting to be pressing. It seems Citrix wants to move away
>> > from
>> > it entirely and Sungard is working on it but has to little resources
>> > for it. Withing our dev group we are now planning a sprint to
>> > experiment with this subject and then implement or fix the present
>> > routers to support this. However we would very much like input from
>> > the people who have already worked on this and are also



-- 
Daan

Re: Review Request 21767: Preload modules so that some sysctl settings will actually get set during boot and some ftp modules to get pasive ftp to work through iptables

[daan Hoogland]

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

Ship it!


bfccf439cfe120f5d1380a642e8b798335e1cf2e

- daan Hoogland


On May 21, 2014, 1:27 p.m., Joris van Lieshout wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/21767/
> ---
> 
> (Updated May 21, 2014, 1:27 p.m.)
> 
> 
> Review request for cloudstack, Abhinandan Prateek, daan Hoogland, edison su, 
> and Hugo Trippaers.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> During the boot of a systemvm sysctl ip_conntrack_max is not set, preloading 
> these module will fix that. Also in order to get passive ftp to work through 
> iptables we need to load some additional modules.
> 
> 
> Diffs
> -
> 
>   tools/appliance/definitions/systemvm64template/postinstall.sh cc8ead9 
>   tools/appliance/definitions/systemvmtemplate/postinstall.sh 23e66dd 
> 
> Diff: https://reviews.apache.org/r/21767/diff/
> 
> 
> Testing
> ---
> 
> We have been running this for a while now in our own production environment.
> 
> 
> Thanks,
> 
> Joris van Lieshout
> 
>

Re: Review Request 21769: blacklisting pcspkr as cosmetic improvement. fixing aesni_intel blacklisting because modprobe.d files have to end with .conf

[daan Hoogland]

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

Ship it!


11f532bbecca08b41dd15d1abdf04957c84eebda

- daan Hoogland


On May 21, 2014, 1:56 p.m., Joris van Lieshout wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/21769/
> ---
> 
> (Updated May 21, 2014, 1:56 p.m.)
> 
> 
> Review request for cloudstack and daan Hoogland.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> the blacklisting of aesni_intel was not working. the file has to end with 
> .conf. blacklisting pcspkr as cosmetic improvement.
> 
> 
> Diffs
> -
> 
>   systemvm/patches/debian/config/etc/modprobe.d/aesni_intel 1c140f0 
>   systemvm/patches/debian/config/etc/modprobe.d/aesni_intel.conf PRE-CREATION 
>   systemvm/patches/debian/config/etc/modprobe.d/pcspkr.conf PRE-CREATION 
> 
> Diff: https://reviews.apache.org/r/21769/diff/
> 
> 
> Testing
> ---
> 
> running in our own production environment on many svms for a while now
> 
> 
> Thanks,
> 
> Joris van Lieshout
> 
>

Re: Review Request 21771: Cosmetic fixes in cloud-early-config script

[daan Hoogland]

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



systemvm/patches/debian/config/etc/init.d/cloud-early-config


wouldn't 2>/dev/null be more appropriate for the described objective?


- daan Hoogland


On May 21, 2014, 3:05 p.m., Joris van Lieshout wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/21771/
> ---
> 
> (Updated May 21, 2014, 3:05 p.m.)
> 
> 
> Review request for cloudstack, Chiradeep Vittal, daan Hoogland, Rajesh 
> Battala, Hugo Trippaers, and Sheng Yang.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> 1. On start hv_kvp_daemon if it exists. Currently trows an error on the 
> console during boot.
> 2. By adding -f to the rm of boot_up_done it will be silent if it does not 
> exist. Currently also trows an error during bootup.
> 3. Use log_action_msg instead of log_action_begin_msg will make the console 
> look cleaner.
> 
> 
> Diffs
> -
> 
>   systemvm/patches/debian/config/etc/init.d/cloud-early-config ffb23ec 
> 
> Diff: https://reviews.apache.org/r/21771/diff/
> 
> 
> Testing
> ---
> 
> We are running these fixes in our beta and prod env for a while allready
> 
> 
> Thanks,
> 
> Joris van Lieshout
> 
>

Re: Review Request 21772: dnsmasq stops logging if logrotate creates the file

[daan Hoogland]

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

Ship it!


c54ce3cafbc51febe71fb2a997dbfc8ac9167fb0

- daan Hoogland


On May 21, 2014, 3:12 p.m., Joris van Lieshout wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/21772/
> ---
> 
> (Updated May 21, 2014, 3:12 p.m.)
> 
> 
> Review request for cloudstack, Chiradeep Vittal, daan Hoogland, and Hugo 
> Trippaers.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> If for some reason dnsmasq.log does not exist anymore logrotate will create 
> it with nobody as owner. This will prevent dnsmasq deamon from logging to 
> that file.
> 
> -rw-r-  1 nobody  root  0 May 16 06:25 dnsmasq.log
> -rw-r-  1 dnsmasq root   6236 Apr 18 12:17 dnsmasq.log-20140419
> -rw-r-  1 dnsmasq root  31673 May 13 22:51 dnsmasq.log-20140514
> -rw-r-  1 dnsmasq root  15739 May 14 18:05 dnsmasq.log-20140515
> -rw-r-  1 dnsmasq root  16831 May 15 21:11 dnsmasq.log-20140516
> 
> 
> Diffs
> -
> 
>   systemvm/patches/debian/config/etc/logrotate.d/dnsmasq 838415d3 
> 
> Diff: https://reviews.apache.org/r/21772/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Joris van Lieshout
> 
>

Re: Review Request 21808: xenstore-utils on debian wheezy does not have /usr/sbin/xenstore so these commands file. It does have xenstore-write and xenstore-rm so by adding a - this is fixed easily.

[daan Hoogland]

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

Ship it!


2e83baaca2c998cfdda281301dffb09a1a20aa5c

- daan Hoogland


On May 22, 2014, 1:38 p.m., Joris van Lieshout wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/21808/
> ---
> 
> (Updated May 22, 2014, 1:38 p.m.)
> 
> 
> Review request for cloudstack, Chiradeep Vittal, daan Hoogland, and Hugo 
> Trippaers.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> The xenstore-utils package for debian wheezy does not have /usr/sbin/xenstore 
> (https://packages.debian.org/wheezy/i386/xenstore-utils/filelist) but it does 
> have xenstore-rm and xenstore-write so by adding a - in-between this is fixed 
> easily.
> 
> 
> Diffs
> -
> 
>   systemvm/patches/debian/xe/xe-update-guest-attrs 30a4498 
> 
> Diff: https://reviews.apache.org/r/21808/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Joris van Lieshout
> 
>

Re: hackathon CCCEU14

[Daan Hoogland]

Great Rohit,

Feel free to edit the schedule on the wiki

On Tue, Jun 10, 2014 at 3:02 PM, Rohit Yadav  wrote:
> Hi Daan,
>
> I'm up for the new (restful/hateoas) API redesign and unit tests!
>
> Regards.
>
>
> On Tue, Jun 10, 2014 at 6:05 PM, Daan Hoogland 
> wrote:
>
>> Hello everybody,
>>
>> Do we still want to have a Hackathon next CCC? we need to plan for the
>> resources (noticably the room) pretty soon.
>>
>> On Thu, Jun 5, 2014 at 12:01 PM, Daan Hoogland
>>  wrote:
>> > People,
>> >
>> > I added two more hackathon subjects at
>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/CloudStack+Collaboration+Conference+EU
>> > In doing so I saw no moderators on the hackathons that were already
>> announced. We need moderators to have successful hackathons. If  you feel a
>> hackathon subject is important enough to go through, please add your name
>> in the wiki. Only hackathons with enough attendance will have resources
>> assigned at the conference.
>> >
>> > \DaanH
>> >
>>
>>
>>
>> --
>> Daan
>>



-- 
Daan

Re: hackathon CCCEU14

[Pierre-Luc Dion]

I don't know for others but I can't edit to page to add my name to the docs
subject.



Pierre-Luc Dion
Architecte de Solution Cloud | Cloud Solutions Architect
855-OK-CLOUD (855-652-5683) x1101
- - -

*CloudOps*420 rue Guy
Montréal QC  H3J 1S6
www.cloudops.com
@CloudOps_


On Tue, Jun 10, 2014 at 8:35 AM, Daan Hoogland 
wrote:

> Hello everybody,
>
> Do we still want to have a Hackathon next CCC? we need to plan for the
> resources (noticably the room) pretty soon.
>
> On Thu, Jun 5, 2014 at 12:01 PM, Daan Hoogland
>  wrote:
> > People,
> >
> > I added two more hackathon subjects at
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/CloudStack+Collaboration+Conference+EU
> > In doing so I saw no moderators on the hackathons that were already
> announced. We need moderators to have successful hackathons. If  you feel a
> hackathon subject is important enough to go through, please add your name
> in the wiki. Only hackathons with enough attendance will have resources
> assigned at the conference.
> >
> > \DaanH
> >
>
>
>
> --
> Daan
>

Re: [ANNOUNCE] Pierre-Luc Dion as a committer

[Chip Childers]

On Tue, Jun 10, 2014 at 01:45:36PM +0200, sebgoa wrote:
> The Project Management Committee (PMC) for Apache CloudStack has
> asked Pierre-Luc Dion to become a committer and we are pleased to announce
> that he has accepted.
> 
> Being a committer allows many contributors to contribute more autonomously. 
> For
> developers, it makes it easier to submit changes and eliminates the need to
> have contributions reviewed via the patch submission process. Whether
> contributions are development-related or otherwise, it is a recognition of a
> contributor's participation in the project and commitment to the project and
> the Apache Way.
> 
> Please join me in congratulating Pierre-Luc!
> 
> PS: Nice work on the documentation
> 
> -Sebastien, on behalf of the CloudStack PMC

Yay Pierre-Luc!

Re: hackathon CCCEU14

[Chip Childers]

On Tue, Jun 10, 2014 at 10:39:39AM -0400, Pierre-Luc Dion wrote:
> I don't know for others but I can't edit to page to add my name to the docs
> subject.

What's your Confluence user ID?

Re: hackathon CCCEU14

[Daan Hoogland]

you do have rights on the wiki, no?

On Tue, Jun 10, 2014 at 4:39 PM, Pierre-Luc Dion  wrote:
> I don't know for others but I can't edit to page to add my name to the docs
> subject.
>
>
>
> Pierre-Luc Dion
> Architecte de Solution Cloud | Cloud Solutions Architect
> 855-OK-CLOUD (855-652-5683) x1101
> - - -
>
> *CloudOps*420 rue Guy
> Montréal QC  H3J 1S6
> www.cloudops.com
> @CloudOps_
>
>
> On Tue, Jun 10, 2014 at 8:35 AM, Daan Hoogland 
> wrote:
>
>> Hello everybody,
>>
>> Do we still want to have a Hackathon next CCC? we need to plan for the
>> resources (noticably the room) pretty soon.
>>
>> On Thu, Jun 5, 2014 at 12:01 PM, Daan Hoogland
>>  wrote:
>> > People,
>> >
>> > I added two more hackathon subjects at
>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/CloudStack+Collaboration+Conference+EU
>> > In doing so I saw no moderators on the hackathons that were already
>> announced. We need moderators to have successful hackathons. If  you feel a
>> hackathon subject is important enough to go through, please add your name
>> in the wiki. Only hackathons with enough attendance will have resources
>> assigned at the conference.
>> >
>> > \DaanH
>> >
>>
>>
>>
>> --
>> Daan
>>



-- 
Daan

Re: [ANNOUNCE] Pierre-Luc Dion as a committer

[Hugo Trippaers]

Congrats Pierre-Luc!

Cheers,

Hugo


On 10 jun. 2014, at 16:40, Chip Childers  wrote:

> On Tue, Jun 10, 2014 at 01:45:36PM +0200, sebgoa wrote:
>> The Project Management Committee (PMC) for Apache CloudStack has
>> asked Pierre-Luc Dion to become a committer and we are pleased to announce
>> that he has accepted.
>> 
>> Being a committer allows many contributors to contribute more autonomously. 
>> For
>> developers, it makes it easier to submit changes and eliminates the need to
>> have contributions reviewed via the patch submission process. Whether
>> contributions are development-related or otherwise, it is a recognition of a
>> contributor's participation in the project and commitment to the project and
>> the Apache Way.
>> 
>> Please join me in congratulating Pierre-Luc!
>> 
>> PS: Nice work on the documentation
>> 
>> -Sebastien, on behalf of the CloudStack PMC
> 
> Yay Pierre-Luc!

Re: Review Request 19616: Added check for null return.

[daan Hoogland]

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


is this still a valid patch? should it be deleted?

- daan Hoogland


On April 15, 2014, 10:18 a.m., Alex Hitchins wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/19616/
> ---
> 
> (Updated April 15, 2014, 10:18 a.m.)
> 
> 
> Review request for cloudstack and daan Hoogland.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Added check for returned null, if received then throw exception.
> 
> Amendments made as per dev mailing list comments.
> 
> 
> Diffs
> -
> 
>   server/src/com/cloud/storage/VolumeApiServiceImpl.java 680cd2e 
> 
> Diff: https://reviews.apache.org/r/19616/diff/
> 
> 
> Testing
> ---
> 
> Compiled & ran.
> 
> 
> Thanks,
> 
> Alex Hitchins
> 
>

Re: Review Request 19616: Added check for null return.

[Alex Hitchins]

I believe it to be valid still. I'll review later and confirm. I know you had 
comments on the patch which I had addressed.




> On 10 Jun 2014, at 15:50, "daan Hoogland"  wrote:
> 
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/19616/#review45234
> ---
> 
> 
> is this still a valid patch? should it be deleted?
> 
> - daan Hoogland
> 
> 
>> On April 15, 2014, 10:18 a.m., Alex Hitchins wrote:
>> 
>> ---
>> This is an automatically generated e-mail. To reply, visit:
>> https://reviews.apache.org/r/19616/
>> ---
>> 
>> (Updated April 15, 2014, 10:18 a.m.)
>> 
>> 
>> Review request for cloudstack and daan Hoogland.
>> 
>> 
>> Repository: cloudstack-git
>> 
>> 
>> Description
>> ---
>> 
>> Added check for returned null, if received then throw exception.
>> 
>> Amendments made as per dev mailing list comments.
>> 
>> 
>> Diffs
>> -
>> 
>>  server/src/com/cloud/storage/VolumeApiServiceImpl.java 680cd2e 
>> 
>> Diff: https://reviews.apache.org/r/19616/diff/
>> 
>> 
>> Testing
>> ---
>> 
>> Compiled & ran.
>> 
>> 
>> Thanks,
>> 
>> Alex Hitchins
> 

Re: Review Request 19616: Added check for null return.

[Daan Hoogland]

it wasn't addressed in the uploaded patch.

On Tue, Jun 10, 2014 at 4:59 PM, Alex Hitchins  wrote:
> I believe it to be valid still. I'll review later and confirm. I know you had 
> comments on the patch which I had addressed.
>
>
>
>
>> On 10 Jun 2014, at 15:50, "daan Hoogland"  wrote:
>>
>>
>> ---
>> This is an automatically generated e-mail. To reply, visit:
>> https://reviews.apache.org/r/19616/#review45234
>> ---
>>
>>
>> is this still a valid patch? should it be deleted?
>>
>> - daan Hoogland
>>
>>
>>> On April 15, 2014, 10:18 a.m., Alex Hitchins wrote:
>>>
>>> ---
>>> This is an automatically generated e-mail. To reply, visit:
>>> https://reviews.apache.org/r/19616/
>>> ---
>>>
>>> (Updated April 15, 2014, 10:18 a.m.)
>>>
>>>
>>> Review request for cloudstack and daan Hoogland.
>>>
>>>
>>> Repository: cloudstack-git
>>>
>>>
>>> Description
>>> ---
>>>
>>> Added check for returned null, if received then throw exception.
>>>
>>> Amendments made as per dev mailing list comments.
>>>
>>>
>>> Diffs
>>> -
>>>
>>>  server/src/com/cloud/storage/VolumeApiServiceImpl.java 680cd2e
>>>
>>> Diff: https://reviews.apache.org/r/19616/diff/
>>>
>>>
>>> Testing
>>> ---
>>>
>>> Compiled & ran.
>>>
>>>
>>> Thanks,
>>>
>>> Alex Hitchins
>>



-- 
Daan

Re: hackathon CCCEU14

[Chip Childers]

On Tue, Jun 10, 2014 at 10:39:39AM -0400, Pierre-Luc Dion wrote:
> I don't know for others but I can't edit to page to add my name to the docs
> subject.

I found your account and have given you edit perms.

-chip

RE: Review Request 19616: Added check for null return.

[Alex Hitchins]

I will take a look later tonight.


Alex Hitchins | 07788 423 969 | 01892 523 587

-Original Message-
From: Daan Hoogland [mailto:daan.hoogl...@gmail.com] 
Sent: 10 June 2014 16:01
To: dev
Subject: Re: Review Request 19616: Added check for null return.

it wasn't addressed in the uploaded patch.

On Tue, Jun 10, 2014 at 4:59 PM, Alex Hitchins  wrote:
> I believe it to be valid still. I'll review later and confirm. I know you had 
> comments on the patch which I had addressed.
>
>
>
>
>> On 10 Jun 2014, at 15:50, "daan Hoogland"  wrote:
>>
>>
>> ---
>> This is an automatically generated e-mail. To reply, visit:
>> https://reviews.apache.org/r/19616/#review45234
>> ---
>>
>>
>> is this still a valid patch? should it be deleted?
>>
>> - daan Hoogland
>>
>>
>>> On April 15, 2014, 10:18 a.m., Alex Hitchins wrote:
>>>
>>> ---
>>> This is an automatically generated e-mail. To reply, visit:
>>> https://reviews.apache.org/r/19616/
>>> ---
>>>
>>> (Updated April 15, 2014, 10:18 a.m.)
>>>
>>>
>>> Review request for cloudstack and daan Hoogland.
>>>
>>>
>>> Repository: cloudstack-git
>>>
>>>
>>> Description
>>> ---
>>>
>>> Added check for returned null, if received then throw exception.
>>>
>>> Amendments made as per dev mailing list comments.
>>>
>>>
>>> Diffs
>>> -
>>>
>>>  server/src/com/cloud/storage/VolumeApiServiceImpl.java 680cd2e
>>>
>>> Diff: https://reviews.apache.org/r/19616/diff/
>>>
>>>
>>> Testing
>>> ---
>>>
>>> Compiled & ran.
>>>
>>>
>>> Thanks,
>>>
>>> Alex Hitchins
>>



-- 
Daan

Re: [ANNOUNCE] Pierre-Luc Dion as a committer

[Mike Tutkowski]

Congratulations!

On Tuesday, June 10, 2014, Hugo Trippaers  wrote:

> Congrats Pierre-Luc!
>
> Cheers,
>
> Hugo
>
>
> On 10 jun. 2014, at 16:40, Chip Childers  > wrote:
>
> > On Tue, Jun 10, 2014 at 01:45:36PM +0200, sebgoa wrote:
> >> The Project Management Committee (PMC) for Apache CloudStack has
> >> asked Pierre-Luc Dion to become a committer and we are pleased to
> announce
> >> that he has accepted.
> >>
> >> Being a committer allows many contributors to contribute more
> autonomously. For
> >> developers, it makes it easier to submit changes and eliminates the
> need to
> >> have contributions reviewed via the patch submission process. Whether
> >> contributions are development-related or otherwise, it is a recognition
> of a
> >> contributor's participation in the project and commitment to the
> project and
> >> the Apache Way.
> >>
> >> Please join me in congratulating Pierre-Luc!
> >>
> >> PS: Nice work on the documentation
> >>
> >> -Sebastien, on behalf of the CloudStack PMC
> >
> > Yay Pierre-Luc!
>
>

-- 
*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: feature : changing volume properties dynamically in 4.5

[Mike Tutkowski]

Hi Punith,

Yeah, I hear you about the number of permutations involved.

Traditionally Compute and Disk Offerings have been immutable. It makes it
easier from an accounting point of view for chargeback and billing.

You should definitely feel free to extend the CloudStack API. I think
NetApp did this for one of their storage features in the recent past. This
way vendor-specific capabilities can be more easily offered without making
it look like all vendors support those particular features.

I do not yet have any code in master related to generic keys/values. I'm
still designing this.

How does your schedule look for the 4.5 release? Do you think you might
have available cycles to help out with this generic key/value
implementation?

Talk to you later!
Mike


On Tue, Jun 10, 2014 at 7:09 AM, Punith S  wrote:

> hi mike,
>
> thanks for the reply, i like your approach which is a very generic way and
> also we only need to do a few changes to the current cloudstack,
>
> but on the other hand we are tying every property of the vendor to a disk
> offering through key/value pairs, since we offer lot of properties like i
> mentioned, this can create a lot of permutation combinations of disk
> offerings, for say if i need to turn deduplication On for a specific volume
> , should i have to create a new disk offering having current properties
> with deduplication On?
>
> is this approach already implemented in the current master ?
>
> and also like you mentioned about exposing a new api, is it okay if i
> expose our own api in my util by extending the PlugableService like in
> network plugins ?
>
> thanks.
>
>
> On Tue, Jun 10, 2014 at 1:17 AM, Mike Tutkowski <
> mike.tutkow...@solidfire.com> wrote:
>
>> Allow me to follow this up with more detail (with regards to what Chris
>> and I talked about):
>>
>> As you are aware, today the way you associate a Compute Offering (CO) or
>> a Disk Offering (DO) with a Primary Storage (PS) is via storage tagging.
>>
>> This has some benefits and drawbacks.
>>
>> One benefit is being able to have some level of vendor independence from
>> the point of view of the CO or DO. For example, if the storage tag of a DO
>> is "Fast", then this can be satisfied by PS that describes itself as
>> "Fast", regardless of vendor.
>>
>> A major drawback with the storage-tagging approach, however, is that you
>> are not easily able to leverage vendor-specific features, which is often
>> why you bought storage from the vendor in question to begin with.
>>
>> Ideally we do not want to add each vendor's features into the system as
>> properties that can be seen by the admin regardless of whether or not the
>> underlying storage he's actually using supports the feature in question.
>>
>> This coarse approach, however, was sort of business as usual when I
>> started in with CloudStack 1.5 years ago.
>>
>> That being the case, when I added QoS options to CS, I did so in a way
>> where the admin would see Min IOPS and Max IOPS options regardless of
>> whether or not his storage actually supported those controls (to mitigate
>> this a bit in the GUI, the admin has to explicitly select "Storage QoS"
>> from a combobox).
>>
>> We leverage the same use model with Hypervisor QoS: The admin sees these
>> options regardless of whether or not they actually apply on the hypervisor
>> where the VM gets deployed.
>>
>> Going forward, we want to implement a more fine-grain and generic
>> approach.
>>
>> We would like to have a storage provider field for the CO and DO windows
>> (this equates to the name of one and only one storage provider). If the
>> admin inputs a specific storage provider and does not use the storage tags
>> field, he can enter in an arbitrary number of key/value pairs in another
>> text field (perhaps we would provide a nice entry dialog to make this
>> easier in the GUI). These key value pairs can be passed into the storage
>> driver when it's asked to create (or update) a volume and the storage
>> driver can decide what each and every key/value pair means.
>>
>> What do you think about this approach?
>>
>> Thanks
>>
>>
>> On Mon, Jun 9, 2014 at 1:14 PM, Mike Tutkowski <
>> mike.tutkow...@solidfire.com> wrote:
>>
>>> Hi Punith,
>>>
>>> This kind of a feature is something Chris Suich and I discussed a while
>>> back.
>>>
>>> We talked about leveraging arbitrary key/value pairs to make this happen
>>> (OpenStack does something similar). The key/value pairs would be vendor
>>> specific.
>>>
>>> If we take a key/value approach, we might be able to make this all work
>>> the way things work today when the user wants to change an existing Compute
>>> Offering and/or Disk Offering.
>>>
>>> For example, the user would pick a new Compute Offering (with presumably
>>> has different key/value pairs) and CloudStack could inform the applicable
>>> storage provider, who could update the volume in question.
>>>
>>> This way we don't need to introduce a new API command and the use model
>>> for the user doesn'

Re: [ANNOUNCE] Pierre-Luc Dion as a committer

[Nguyen Anh Tu]

Congratulation, Pierre-Luc!

--Tuna


On Tue, Jun 10, 2014 at 10:34 PM, Mike Tutkowski <
mike.tutkow...@solidfire.com> wrote:

> Congratulations!
>
> On Tuesday, June 10, 2014, Hugo Trippaers  wrote:
>
> > Congrats Pierre-Luc!
> >
> > Cheers,
> >
> > Hugo
> >
> >
> > On 10 jun. 2014, at 16:40, Chip Childers  > > wrote:
> >
> > > On Tue, Jun 10, 2014 at 01:45:36PM +0200, sebgoa wrote:
> > >> The Project Management Committee (PMC) for Apache CloudStack has
> > >> asked Pierre-Luc Dion to become a committer and we are pleased to
> > announce
> > >> that he has accepted.
> > >>
> > >> Being a committer allows many contributors to contribute more
> > autonomously. For
> > >> developers, it makes it easier to submit changes and eliminates the
> > need to
> > >> have contributions reviewed via the patch submission process. Whether
> > >> contributions are development-related or otherwise, it is a
> recognition
> > of a
> > >> contributor's participation in the project and commitment to the
> > project and
> > >> the Apache Way.
> > >>
> > >> Please join me in congratulating Pierre-Luc!
> > >>
> > >> PS: Nice work on the documentation
> > >>
> > >> -Sebastien, on behalf of the CloudStack PMC
> > >
> > > Yay Pierre-Luc!
> >
> >
>
> --
> *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: feature : changing volume properties dynamically in 4.5

[Mike Tutkowski]

I plan to draw up a design document surrounding generic key/value pairs
today.

Perhaps you can take a look at it when you have time, Punith?


On Tue, Jun 10, 2014 at 10:06 AM, Mike Tutkowski <
mike.tutkow...@solidfire.com> wrote:

> Hi Punith,
>
> Yeah, I hear you about the number of permutations involved.
>
> Traditionally Compute and Disk Offerings have been immutable. It makes it
> easier from an accounting point of view for chargeback and billing.
>
> You should definitely feel free to extend the CloudStack API. I think
> NetApp did this for one of their storage features in the recent past. This
> way vendor-specific capabilities can be more easily offered without making
> it look like all vendors support those particular features.
>
> I do not yet have any code in master related to generic keys/values. I'm
> still designing this.
>
> How does your schedule look for the 4.5 release? Do you think you might
> have available cycles to help out with this generic key/value
> implementation?
>
> Talk to you later!
> Mike
>
>
> On Tue, Jun 10, 2014 at 7:09 AM, Punith S  wrote:
>
>> hi mike,
>>
>> thanks for the reply, i like your approach which is a very generic way
>> and also we only need to do a few changes to the current cloudstack,
>>
>> but on the other hand we are tying every property of the vendor to a disk
>> offering through key/value pairs, since we offer lot of properties like i
>> mentioned, this can create a lot of permutation combinations of disk
>> offerings, for say if i need to turn deduplication On for a specific volume
>> , should i have to create a new disk offering having current properties
>> with deduplication On?
>>
>> is this approach already implemented in the current master ?
>>
>> and also like you mentioned about exposing a new api, is it okay if i
>> expose our own api in my util by extending the PlugableService like in
>> network plugins ?
>>
>> thanks.
>>
>>
>> On Tue, Jun 10, 2014 at 1:17 AM, Mike Tutkowski <
>> mike.tutkow...@solidfire.com> wrote:
>>
>>> Allow me to follow this up with more detail (with regards to what Chris
>>> and I talked about):
>>>
>>> As you are aware, today the way you associate a Compute Offering (CO) or
>>> a Disk Offering (DO) with a Primary Storage (PS) is via storage tagging.
>>>
>>> This has some benefits and drawbacks.
>>>
>>> One benefit is being able to have some level of vendor independence from
>>> the point of view of the CO or DO. For example, if the storage tag of a DO
>>> is "Fast", then this can be satisfied by PS that describes itself as
>>> "Fast", regardless of vendor.
>>>
>>> A major drawback with the storage-tagging approach, however, is that you
>>> are not easily able to leverage vendor-specific features, which is often
>>> why you bought storage from the vendor in question to begin with.
>>>
>>> Ideally we do not want to add each vendor's features into the system as
>>> properties that can be seen by the admin regardless of whether or not the
>>> underlying storage he's actually using supports the feature in question.
>>>
>>> This coarse approach, however, was sort of business as usual when I
>>> started in with CloudStack 1.5 years ago.
>>>
>>> That being the case, when I added QoS options to CS, I did so in a way
>>> where the admin would see Min IOPS and Max IOPS options regardless of
>>> whether or not his storage actually supported those controls (to mitigate
>>> this a bit in the GUI, the admin has to explicitly select "Storage QoS"
>>> from a combobox).
>>>
>>> We leverage the same use model with Hypervisor QoS: The admin sees these
>>> options regardless of whether or not they actually apply on the hypervisor
>>> where the VM gets deployed.
>>>
>>> Going forward, we want to implement a more fine-grain and generic
>>> approach.
>>>
>>> We would like to have a storage provider field for the CO and DO windows
>>> (this equates to the name of one and only one storage provider). If the
>>> admin inputs a specific storage provider and does not use the storage tags
>>> field, he can enter in an arbitrary number of key/value pairs in another
>>> text field (perhaps we would provide a nice entry dialog to make this
>>> easier in the GUI). These key value pairs can be passed into the storage
>>> driver when it's asked to create (or update) a volume and the storage
>>> driver can decide what each and every key/value pair means.
>>>
>>> What do you think about this approach?
>>>
>>> Thanks
>>>
>>>
>>> On Mon, Jun 9, 2014 at 1:14 PM, Mike Tutkowski <
>>> mike.tutkow...@solidfire.com> wrote:
>>>
 Hi Punith,

 This kind of a feature is something Chris Suich and I discussed a while
 back.

 We talked about leveraging arbitrary key/value pairs to make this
 happen (OpenStack does something similar). The key/value pairs would be
 vendor specific.

 If we take a key/value approach, we might be able to make this all work
 the way things work today when the user wants to change an existing Compu

installing cloudstack development environment with eclipse

[Elapavuluri, Jaya]

Hello,

I am trying to setup cloudstack development environment using eclipse. These 
are the errors I am encountering, Could someone help me out to resolve these?

Plugin execution not covered by lifecycle configuration: 
org.apache.maven.plugins:maven-checkstyle-plugin:2.11:check (execution: 
cloudstack-checkstyle, phase: validate)  pom.xml  
/cloud-framework-spring-lifecycle   line 16   Maven Project Build 
Lifecycle Mapping Problem
Missing artifact com.netapp:jndmp:jar:3.0 pom.xml  
/cloud-plugin-api-netapp   line 268Maven Dependency Problem

Re: installing cloudstack development environment with eclipse

[Mike Tutkowski]

As for "Plugin execution not covered by lifecycle configuration", you can
ignore that one (there are probably many instances of this error). I think
m2eclipse doesn't currently support something in our POM files and that's
why this error is displayed.


On Tue, Jun 10, 2014 at 10:21 AM, Elapavuluri, Jaya <
jaya.elapavul...@netapp.com> wrote:

> Hello,
>
> I am trying to setup cloudstack development environment using eclipse.
> These are the errors I am encountering, Could someone help me out to
> resolve these?
>
> Plugin execution not covered by lifecycle configuration:
> org.apache.maven.plugins:maven-checkstyle-plugin:2.11:check (execution:
> cloudstack-checkstyle, phase: validate)  pom.xml
>  /cloud-framework-spring-lifecycle   line 16   Maven Project Build
> Lifecycle Mapping Problem
> Missing artifact com.netapp:jndmp:jar:3.0 pom.xml
>  /cloud-plugin-api-netapp   line 268Maven Dependency
> Problem
>



-- 
*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: [GSoC] [CLOUDSTACK-6114] Progress update

[Ian Duffy]

Cool! if you hit *any* issues do let me know. I've a feeling there may be
some around vagrant and berkshelf.

This almost completes design 1 - Running Cloudstack on Host machine with a
MySQL + NFS box supplied and a Hypervisor.
http://www.google-melange.com/gsoc/proposal/public/google/gsoc2014/imduffy15/5662278724616192

I just want to do some cleaning up around it and testing.





On 10 June 2014 08:55, Rohit Yadav  wrote:

> Hi Ian,
>
> Thanks for sharing, I was trying to do something miserably to make an
> appliance for testing xenserver/xenproject with ACS. Will try it in the
> evening.
>
> Cheers.
>
>
> On Tue, Jun 10, 2014 at 1:50 AM, Ian Duffy  wrote:
>
> > Hi All,
> >
> > Started making some fast progress on this.
> >
> > I uploaded the xenserver box[1] to vagrant cloud. This means people can
> > easily get a xenserver VM by executing vagrant init duffy/xenserver &&
> > vagrant up.
> >
> > I adjusted the configuration on the box to allow for multiple xenserver
> > boxes to be brought up by one vagrant file. In order to allow this I had
> to
> > remove the host-only network configuration from the packaged box into an
> > external script [2]. It can be used as follows:
> >
> >   config.vm.define "xenserver" do |xenserver|
> > xenserver.vm.box = "duffy/xenserver"
> >
> > xenserver.vm.provision "shell" do |s|
> >   s.path = "xenserver/reset-network.sh"
> >   s.args = ["eth1", "192.168.56.10", "255.255.255.0"]
> > end
> >   end
> >
> >
> > I created a skeleton for the chef cookbook [3]. At the moment it include
> > calls to the MySQL, NFS and IPTables gateway recipes with default
> > attributes specified for the included devcloud.cfg. Along with this I
> wrote
> > a systemvm downloading recipe which reads an array of systemvms from the
> > cookbooks attributes file and downloads/installed them accordingly. It
> uses
> > the -t switch to on the cloud-install-sys-tmplt script to avoid querying
> > the MySQL db for information.
> >
> > I added some brief usage documentation too [4]
> >
> >
> > [1] https://github.com/imduffy15/packer-xenserver
> > [2]
> >
> >
> https://github.com/imduffy15/GSoC-2014/blob/master/MySql_NFS_XenServer/xenserver/reset-network.sh
> > [3] https://github.com/imduffy15/cookbook_cloudstack
> > [4] https://github.com/imduffy15/GSoC-2014/blob/master/README.md
> >
>

Re: hackathon CCCEU14

[Pierre-Luc Dion]

Thanks!


Pierre-Luc Dion
Architecte de Solution Cloud | Cloud Solutions Architect
855-OK-CLOUD (855-652-5683) x1101
- - -

*CloudOps*420 rue Guy
Montréal QC  H3J 1S6
www.cloudops.com
@CloudOps_


On Tue, Jun 10, 2014 at 11:23 AM, Chip Childers 
wrote:

> On Tue, Jun 10, 2014 at 10:39:39AM -0400, Pierre-Luc Dion wrote:
> > I don't know for others but I can't edit to page to add my name to the
> docs
> > subject.
>
> I found your account and have given you edit perms.
>
> -chip
>

Re: Review Request 21973: CLOUDSTACK-6780: Resolved cleanup issue in portable ip test cases

[Santhosh Edukulla]

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

Ship it!


Ship It!

- Santhosh Edukulla


On June 10, 2014, 11:16 a.m., Ashutosh Kelkar wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/21973/
> ---
> 
> (Updated June 10, 2014, 11:16 a.m.)
> 
> 
> Review request for cloudstack, Girish Shilamkar and Santhosh Edukulla.
> 
> 
> Bugs: CLOUDSTACK-6780
> https://issues.apache.org/jira/browse/CLOUDSTACK-6780
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Portable IP address was not getting disassociated. Added it to finally block 
> so that it will get associated always and portable ip range gets cleaned up 
> properly during cleanup.
> 
> 
> Diffs
> -
> 
>   test/integration/component/test_portable_ip.py 847bb4a 
> 
> Diff: https://reviews.apache.org/r/21973/diff/
> 
> 
> Testing
> ---
> 
> Test disassociating portable ip ... === TestName: 
> test_disassociate_ip_address_no_services | Status : SUCCESS ===
> ok
> Test disassociating portable IP with non-owner account ... === TestName: 
> test_disassociate_ip_address_other_account | Status : SUCCESS ===
> ok
> Test disassociating portable ip ... === TestName: 
> test_disassociate_ip_address_services_enabled | Status : SUCCESS ===
> ok
> 
> --
> Ran 3 tests in 263.215s
> 
> OK
> 
> 
> Thanks,
> 
> Ashutosh Kelkar
> 
>

Re: VPC's VR missing public NIC eth1

[Marcus]

If we get the 4.3.0 to 4.3.1 in then there is no need for my previous
comment. I was concerned it would not happen.


On Wed, Jun 4, 2014 at 9:20 AM, Daan Hoogland 
wrote:

> On Wed, Jun 4, 2014 at 4:27 PM, Marcus  wrote:
> > Regarding 5e80e5d33d9a295b91cdba9377f52d9d963d802a, we should probably do
> > that for IpAssocCommand as well.
>
>
> I am feeling like in a spiral down. If the user input is fixed up
> coming in it should probably be fixed down going out. when we save a
> uri in the db we could still present the user with an id. Not when the
> id can actually be an non vlan uri, however. This is going to take a
> lot of work to get right. I doubt ipAssocCommand is going to be the
> last one.
>
> --
> Daan
>

Re: VPC's VR missing public NIC eth1

[Marcus]

That would be a good idea


On Wed, Jun 4, 2014 at 9:16 AM, Daan Hoogland 
wrote:

> Marcus,
>
> I didn't do the db thing for 4.3 but it is idem-potent and can go in a
> Upgrade430to431.java as well. This one doesn't exist yet.
>
> On Wed, Jun 4, 2014 at 4:27 PM, Marcus  wrote:
> > That wasn't the patch I thought it was. Regarding
> > 5e80e5d33d9a295b91cdba9377f52d9d963d802a, we should probably do that for
> > IpAssocCommand as well. I'm not sure we have the db fix in 4.3 yet, and
> so a
> > fix like this would be required for IpAssocCommand (and perhaps other
> > unfound things).
> >
> >
> > On Tue, Jun 3, 2014 at 3:22 PM, Marcus  wrote:
> >>
> >> Hmm.. ok. I guess we can apply the bandaid patch as well
> >>
> >>
> >> On Tue, Jun 3, 2014 at 12:16 PM, Edison Su 
> wrote:
> >>>
> >>> I checked in a commit: 5e80e5d33d9a295b91cdba9377f52d9d963d802a, which
> >>> will fix some of the mess of vlan id.
> >>>
> >>> > -Original Message-
> >>> > From: Marcus [mailto:shadow...@gmail.com]
> >>> > Sent: Tuesday, June 03, 2014 9:57 AM
> >>> > To: Daan Hoogland
> >>> > Cc: dev
> >>> > Subject: Re: VPC's VR missing public NIC eth1
> >>> >
> >>> > Ok, thanks. It seems there are other cases where the Command being
> >>> > passed from the mgmt server has inconsistent broadcastUri as well,
> this
> >>> > should blanket fix them. In the meantime there's a growing group of
> 4.3
> >>> > upgraders who are getting pitchforks out over at CLOUDSTACK-6464, so
> we
> >>> > may want to have something in 4.3.1 too.
> >>> >
> >>> >
> >>> > On Tue, Jun 3, 2014 at 12:30 AM, Daan Hoogland
> >>> > 
> >>> > wrote:
> >>> >
> >>> > > one clarification, I was not suggesting changing vlan://x back to
> x,
> >>> > > just the case where x==untagged. I had a little analog discussion
> >>> > > with
> >>> > > Hugo and he convinced me that untagged has no special meaning in
> SDN
> >>> > > cases, maybe for vxlan. So the problem I saw is at least smaller
> then
> >>> > > in my mind.
> >>> > >
> >>> > > I have committed the db change to update 4.3.0 to 4.4.0. It will
> need
> >>> > > heavy testing. And I didn't extensively look into other tables that
> >>> > > need such a change. networks is the likely candidate but there may
> be
> >>> > > others.
> >>> > >
> >>> > >
> >>> > > On Mon, Jun 2, 2014 at 6:38 PM, Marcus 
> wrote:
> >>> > > > Just to recap... I was trying to review the issue in my head and
> >>> > > > thought
> >>> > > it
> >>> > > > might be useful to write it down.
> >>> > > >
> >>> > > > in 4.3 we got the BroadcastDomainType enum introduced, and many
> >>> > > > parts of
> >>> > > the
> >>> > > > code were changed to use that when dealing with the vlan id. This
> >>> > > > code, among other things, returns a vlan id in URI format,
> >>> > > > describing both the technology used to provide the virtual lan,
> >>> > > > along with the id. Along the
> >>> > > way
> >>> > > > this seems to have caused the value itself to be stored as a URI
> >>> > > > (still
> >>> > > not
> >>> > > > sure where, by whom, or if it was intentional). That was fine and
> >>> > > > seemed
> >>> > > to
> >>> > > > work after some fixing, until there was an upgrade done where the
> >>> > > existing
> >>> > > > database value was NOT in URI format. We had a few places where
> the
> >>> > > > code
> >>> > > was
> >>> > > > never changed to use BroadcastDomainType to 'normalize' the info
> >>> > > > from the database (e.g. the IpAssocVpcCommand the mgmt server
> >>> > > > constructs), so upgrades are broken.
> >>> > > >
> >>> > > > Most places in the code as it is now are working with a live
> value
> >>> > > > of 'vlan://x', regardless of whether the database has 'vlan://x'
> or
> >>> > > > just
> >>> > > 'x',
> >>> > > > thanks to this code it returns the same 'vlan://' for either
> stored
> >>> > > value.
> >>> > > > For these places it shouldn't matter if we fix the old databases
> to
> >>> > > > store 'vlan://x' or the 4.3 installs to go back to 'x'.
> >>> > > >
> >>> > > > However, there are a few places that are broken, like this
> >>> > > IpAssocVpcCommand
> >>> > > > the mgmt server creates and CLOUDSTACK-5505. If we switch the db
> >>> > > > value
> >>> > > back,
> >>> > > > we have to identify all of the outstanding ones and fix them. In
> >>> > > addition,
> >>> > > > new code since then may have perhaps assumed that the db value is
> >>> > > 'vlan://',
> >>> > > > and might have bothered to pass through the interpolation, so
> they
> >>> > > > may
> >>> > > break
> >>> > > > as well. If we had full coverage on the test suite it would be
> easy
> >>> > > > to change the value back in the DB of a 4.3 or 4.4 install and
> see
> >>> > > > what
> >>> > > breaks.
> >>> > > >
> >>> > > > If we don't switch the value back, and instead update old
> databases
> >>> > > > to
> >>> > > the
> >>> > > > current way, it fixes the immediate issue but we end up with code
> >>> > > > doing
> >>> > > the
> >>> > > > same thing in two different ways. Some places will b

Re: [ANNOUNCE] Pierre-Luc Dion as a committer

[Ian Duffy]

Congrats Pierre-Luc!


On 10 June 2014 17:07, Nguyen Anh Tu  wrote:

> Congratulation, Pierre-Luc!
>
> --Tuna
>
>
> On Tue, Jun 10, 2014 at 10:34 PM, Mike Tutkowski <
> mike.tutkow...@solidfire.com> wrote:
>
> > Congratulations!
> >
> > On Tuesday, June 10, 2014, Hugo Trippaers  wrote:
> >
> > > Congrats Pierre-Luc!
> > >
> > > Cheers,
> > >
> > > Hugo
> > >
> > >
> > > On 10 jun. 2014, at 16:40, Chip Childers  > > > wrote:
> > >
> > > > On Tue, Jun 10, 2014 at 01:45:36PM +0200, sebgoa wrote:
> > > >> The Project Management Committee (PMC) for Apache CloudStack has
> > > >> asked Pierre-Luc Dion to become a committer and we are pleased to
> > > announce
> > > >> that he has accepted.
> > > >>
> > > >> Being a committer allows many contributors to contribute more
> > > autonomously. For
> > > >> developers, it makes it easier to submit changes and eliminates the
> > > need to
> > > >> have contributions reviewed via the patch submission process.
> Whether
> > > >> contributions are development-related or otherwise, it is a
> > recognition
> > > of a
> > > >> contributor's participation in the project and commitment to the
> > > project and
> > > >> the Apache Way.
> > > >>
> > > >> Please join me in congratulating Pierre-Luc!
> > > >>
> > > >> PS: Nice work on the documentation
> > > >>
> > > >> -Sebastien, on behalf of the CloudStack PMC
> > > >
> > > > Yay Pierre-Luc!
> > >
> > >
> >
> > --
> > *Mike Tutkowski*
> > *Senior CloudStack Developer, SolidFire Inc.*
> > e: mike.tutkow...@solidfire.com
> > o: 303.746.7302
> > Advancing the way the world uses the cloud
> > *™*
> >
>

NetworkOrchestrator selects 2 NetworkGurus at one time....

[Ritu Sabharwal]

Hi,

I am writing a Network Guru for automatically orchestrating Brocade VDX 
switches to provide tenant isolation via VLAN. In my NetworkGuru, I have 
implemented the canHandle() method for Guest isolated network in Advanced zone 
using VLAN isolation. When the NetworkOrchestrator selects the NetworkGuru, it 
selects my NetworkGuru and the ExternalGuestNetworkGuru also and I see 2 
networks created. How do I make sure that ExternalGuestNetworkGuru is not 
selected by NetworkOrchestrator.

Thanks & Regards,
Ritu S.

Re: ssvm logs

[Nitin Mehta]

Refer to NfsSecondaryStorageResource.java. This file is the agent code
that takes all the commands from CS Management server and executes them.
You can see what all logs it writes. It would be great if you could write
a wiki as well pointing what all logs can be expected. I can help you make
it comprehensive. Please also feel free to log bugs in cases where you
find insufficient logging.

Thanks,
-Nitin

On 08/06/14 12:12 AM, "Ekta Agrawal"  wrote:

>HI,
>
>I need logs for all functioning of ssvm, can somebody send the logs
>showing
>all function which are happening properly.
>
>if somebody can point the code of cloudstack , I  want  to understand logs
>written for process of management and functioning done by ssvm .
>
>Please help me if you can.
>
>
>Regards,
>Ekta

[PROPOSAL] Brocade network plugin to orchestrate Brocade VDX Switches for CloudStack 4.5

[Ritu Sabharwal]

Hi CS Developers,

I have added the Design document for the Plugin in the wiki.  Here is the link 
: 
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Brocade+Network+Plugin+to+Orchestrate+Brocade+VDX+Switches

Please review it and provide your comments.

Thanks & Regards,
Ritu S.

Re: redundant virtual routers for VPCs

[Daan Hoogland]

We are on #cloudstack-meeting to start discussing the redundant vpc vr.

Please all feel welcome to join in.

On Tue, Jun 10, 2014 at 3:32 PM, Daan Hoogland  wrote:
> ok, write you then.
>
> On Tue, Jun 10, 2014 at 2:52 PM, Karl Harris  
> wrote:
>> 20:00 utc ;-) missed the last change in time!
>>
>>
>> Karl
>>
>>
>> On Tuesday, June 10, 2014, Daan Hoogland 
>> wrote:
>>>
>>> Karl, That’s midnight over here! :(
>>>
>>>
>>>
>>> \DaanH
>>>
>>>
>>>
>>> From: Karl Harris [mailto:karl.har...@sungardas.com]
>>> Sent: dinsdag 10 juni 2014 2:43
>>> To: Daan Hoogland
>>> Cc: Hugo Trippaers; dev; Sheng Yang; Sander Botman; Alena Prokharchyk;
>>> kis...@cloud.com; Christopher Litsinger; Hugo Trippaers; int-toolkit
>>> Subject: Re: redundant virtual routers for VPCs
>>>
>>>
>>>
>>> Recovering from a laptop hard disk crash should be back online by 22:00
>>> UTC!
>>>
>>>
>>>
>>> Karl
>>>
>>>
>>>
>>> On Tuesday, June 10, 2014, Daan Hoogland  wrote:
>>>
>>> I would like to have Hugo in the meeting So let's make it 20:00 UTC
>>>
>>> I would suggest #cloudstack-meeting
>>>
>>> On Tue, Jun 10, 2014 at 10:29 AM, Hugo Trippaers 
>>> wrote:
>>> >
>>> > I can’t make 15:00, but 22:00 could work.
>>> >
>>> > Cheers,
>>> >
>>> > Hugo
>>> >
>>> >
>>> > On 10 jun. 2014, at 10:14, Daan Hoogland 
>>> > wrote:
>>> >
>>> >> Quite right:
>>> >>
>>> >>
>>> >> -  Feasibility experiment plans by Schuberg Philis
>>> >>
>>> >> -  Reusable work by Karl
>>> >>
>>> >> -  Problems Citrix encountered with the regular redundant
>>> >> router (and how to avoid them)
>>> >>
>>> >> -  Work division
>>> >>
>>> >> -  (next meeting needed?)
>>> >>
>>> >> Any additions?
>>> >>
>>> >> \DaanH
>>> >>
>>> >> From: Sheng Yang [mailto:sh...@yasker.org]
>>> >> Sent: dinsdag 10 juni 2014 1:39
>>> >> To: Sander Botman
>>> >> Cc: Daan Hoogland; Karl Harris; dev; Alena Prokharchyk;
>>> >> kis...@cloud.com; Christopher Litsinger; Hugo Trippaers; int-toolkit
>>> >> Subject: Re: redundant virtual routers for VPCs
>>> >>
>>> >> BTW, do we have an agenda or some topics we want to discuss for the
>>> >> meeting? I just want to make sure it's efficient.
>>> >>
>>> >> --Sheng
>>> >>
>>> >> On Mon, Jun 9, 2014 at 1:14 PM, Sander Botman
>>> >> mailto:sbot...@schubergphilis.com>> wrote:
>>> >> Hi all
>>> >>
>>> >> I can make 15:00.
>>> >>
>>> >> Cannon join at 20:00.
>>> >>
>>> >> Cheers Sander
>>> >>
>>> >> Verstuurd vanaf mijn iPhone
>>> >>
>>> >>> Op 9 jun. 2014 om 21:31 heeft "Daan Hoogland"
>>> >>> mailto:daan.hoogl...@gmail.com>> het volgende
>>> >>> geschreven:
>>> >>>
>>> >>> nice,
>>> >>>
>>> >>> so given pacific time I can have a meeting at 15:00 utc or at 20:00
>>> >>> utc (8 am or 2 pm if I'm correct). Given office hours in Holland 17:00
>>> >>> (15:00 utc) would be best but if you're not in it could be later. As
>>> >>> the person calling the meeting I would like to participate but if the
>>> >>> highest attendance can be found only between 16 and 22 utc thats fine
>>> >>> as well.
>>> >>>
>>>  On Mon, Jun 9, 2014 at 8:35 PM, Karl Harris
>>>  mailto:karl.har...@sungardas.com>> wrote:
>>>  I will be happy to join!
>>> 
>>> 
>>> 
>>> > On Saturday, June 7, 2014, Daan Hoogland
>>> > mailto:daan.hoogl...@gmail.com>> wrote:
>>> >
>>> > At Schuberg Philis, the urge to have virtual routers in a redundant
>>> > way is getting to be pressing. It seems Citrix wants to move away
>>> > from
>>> > it entirely and Sungard is working on it but has to little resources
>>> > for it. Withing our dev group we are now planning a sprint to
>>> > experiment with this subject and then implement or fix the present
>>> > routers to support this. However we would very much like input from
>>> > the people who have already worked on this and are also
>
>
>
> --
> Daan



-- 
Daan

Re: feature : changing volume properties dynamically in 4.5

[Mike Tutkowski]

Here is that design document I was referring to, Punith:

https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=42566111

I've been working with a student in Tunisia who is participating in Google
Summer of Code (GSoC) (I'm his mentor).

He'll be working on part of this as will I. (He is also working on another
related task not listed here.)

Feel free to join us, if you have time available, as we can divide out
coding and testing among the three of us.

Talk to you later!
Mike


On Tue, Jun 10, 2014 at 10:18 AM, Mike Tutkowski <
mike.tutkow...@solidfire.com> wrote:

> I plan to draw up a design document surrounding generic key/value pairs
> today.
>
> Perhaps you can take a look at it when you have time, Punith?
>
>
> On Tue, Jun 10, 2014 at 10:06 AM, Mike Tutkowski <
> mike.tutkow...@solidfire.com> wrote:
>
>> Hi Punith,
>>
>> Yeah, I hear you about the number of permutations involved.
>>
>> Traditionally Compute and Disk Offerings have been immutable. It makes it
>> easier from an accounting point of view for chargeback and billing.
>>
>> You should definitely feel free to extend the CloudStack API. I think
>> NetApp did this for one of their storage features in the recent past. This
>> way vendor-specific capabilities can be more easily offered without making
>> it look like all vendors support those particular features.
>>
>> I do not yet have any code in master related to generic keys/values. I'm
>> still designing this.
>>
>> How does your schedule look for the 4.5 release? Do you think you might
>> have available cycles to help out with this generic key/value
>> implementation?
>>
>> Talk to you later!
>> Mike
>>
>>
>> On Tue, Jun 10, 2014 at 7:09 AM, Punith S  wrote:
>>
>>> hi mike,
>>>
>>> thanks for the reply, i like your approach which is a very generic way
>>> and also we only need to do a few changes to the current cloudstack,
>>>
>>> but on the other hand we are tying every property of the vendor to a
>>> disk offering through key/value pairs, since we offer lot of properties
>>> like i mentioned, this can create a lot of permutation combinations of disk
>>> offerings, for say if i need to turn deduplication On for a specific volume
>>> , should i have to create a new disk offering having current properties
>>> with deduplication On?
>>>
>>> is this approach already implemented in the current master ?
>>>
>>> and also like you mentioned about exposing a new api, is it okay if i
>>> expose our own api in my util by extending the PlugableService like in
>>> network plugins ?
>>>
>>> thanks.
>>>
>>>
>>> On Tue, Jun 10, 2014 at 1:17 AM, Mike Tutkowski <
>>> mike.tutkow...@solidfire.com> wrote:
>>>
 Allow me to follow this up with more detail (with regards to what Chris
 and I talked about):

 As you are aware, today the way you associate a Compute Offering (CO)
 or a Disk Offering (DO) with a Primary Storage (PS) is via storage tagging.

 This has some benefits and drawbacks.

 One benefit is being able to have some level of vendor independence
 from the point of view of the CO or DO. For example, if the storage tag of
 a DO is "Fast", then this can be satisfied by PS that describes itself as
 "Fast", regardless of vendor.

 A major drawback with the storage-tagging approach, however, is that
 you are not easily able to leverage vendor-specific features, which is
 often why you bought storage from the vendor in question to begin with.

 Ideally we do not want to add each vendor's features into the system as
 properties that can be seen by the admin regardless of whether or not the
 underlying storage he's actually using supports the feature in question.

 This coarse approach, however, was sort of business as usual when I
 started in with CloudStack 1.5 years ago.

 That being the case, when I added QoS options to CS, I did so in a way
 where the admin would see Min IOPS and Max IOPS options regardless of
 whether or not his storage actually supported those controls (to mitigate
 this a bit in the GUI, the admin has to explicitly select "Storage QoS"
 from a combobox).

 We leverage the same use model with Hypervisor QoS: The admin sees
 these options regardless of whether or not they actually apply on the
 hypervisor where the VM gets deployed.

 Going forward, we want to implement a more fine-grain and generic
 approach.

 We would like to have a storage provider field for the CO and DO
 windows (this equates to the name of one and only one storage provider). If
 the admin inputs a specific storage provider and does not use the storage
 tags field, he can enter in an arbitrary number of key/value pairs in
 another text field (perhaps we would provide a nice entry dialog to make
 this easier in the GUI). These key value pairs can be passed into the
 storage driver when it's asked to create (or update) a volume 

Re: [ANNOUNCE] Pierre-Luc Dion as a committer

[Tim Mackey]

Félicitations mon ami!


On Tue, Jun 10, 2014 at 1:46 PM, Ian Duffy  wrote:

> Congrats Pierre-Luc!
>
>
> On 10 June 2014 17:07, Nguyen Anh Tu  wrote:
>
> > Congratulation, Pierre-Luc!
> >
> > --Tuna
> >
> >
> > On Tue, Jun 10, 2014 at 10:34 PM, Mike Tutkowski <
> > mike.tutkow...@solidfire.com> wrote:
> >
> > > Congratulations!
> > >
> > > On Tuesday, June 10, 2014, Hugo Trippaers  wrote:
> > >
> > > > Congrats Pierre-Luc!
> > > >
> > > > Cheers,
> > > >
> > > > Hugo
> > > >
> > > >
> > > > On 10 jun. 2014, at 16:40, Chip Childers  > > > > wrote:
> > > >
> > > > > On Tue, Jun 10, 2014 at 01:45:36PM +0200, sebgoa wrote:
> > > > >> The Project Management Committee (PMC) for Apache CloudStack has
> > > > >> asked Pierre-Luc Dion to become a committer and we are pleased to
> > > > announce
> > > > >> that he has accepted.
> > > > >>
> > > > >> Being a committer allows many contributors to contribute more
> > > > autonomously. For
> > > > >> developers, it makes it easier to submit changes and eliminates
> the
> > > > need to
> > > > >> have contributions reviewed via the patch submission process.
> > Whether
> > > > >> contributions are development-related or otherwise, it is a
> > > recognition
> > > > of a
> > > > >> contributor's participation in the project and commitment to the
> > > > project and
> > > > >> the Apache Way.
> > > > >>
> > > > >> Please join me in congratulating Pierre-Luc!
> > > > >>
> > > > >> PS: Nice work on the documentation
> > > > >>
> > > > >> -Sebastien, on behalf of the CloudStack PMC
> > > > >
> > > > > Yay Pierre-Luc!
> > > >
> > > >
> > >
> > > --
> > > *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: [ANNOUNCE] Pierre-Luc Dion as a committer

[Nux!]

On 10.06.2014 12:45, sebgoa wrote:

The Project Management Committee (PMC) for Apache CloudStack has
asked Pierre-Luc Dion to become a committer and we are pleased to 
announce

that he has accepted.

Being a committer allows many contributors to contribute more 
autonomously. For
developers, it makes it easier to submit changes and eliminates the 
need to

have contributions reviewed via the patch submission process. Whether
contributions are development-related or otherwise, it is a 
recognition of a
contributor's participation in the project and commitment to the 
project and

the Apache Way.

Please join me in congratulating Pierre-Luc!

PS: Nice work on the documentation

-Sebastien, on behalf of the CloudStack PMC


Congratulations! :-)

Lucian

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

Re: [ANNOUNCE] Pierre-Luc Dion as a committer

[Daan Hoogland]

Welcome to the family Pierre-Luc (though you were long in, of course)

On Tue, Jun 10, 2014 at 11:49 PM, Nux!  wrote:
> On 10.06.2014 12:45, sebgoa wrote:
>>
>> The Project Management Committee (PMC) for Apache CloudStack has
>> asked Pierre-Luc Dion to become a committer and we are pleased to announce
>> that he has accepted.
>>
>> Being a committer allows many contributors to contribute more
>> autonomously. For
>> developers, it makes it easier to submit changes and eliminates the need
>> to
>> have contributions reviewed via the patch submission process. Whether
>> contributions are development-related or otherwise, it is a recognition of
>> a
>> contributor's participation in the project and commitment to the project
>> and
>> the Apache Way.
>>
>> Please join me in congratulating Pierre-Luc!
>>
>> PS: Nice work on the documentation
>>
>> -Sebastien, on behalf of the CloudStack PMC
>
>
> Congratulations! :-)
>
> Lucian
>
> --
> Sent from the Delta quadrant using Borg technology!
>
> Nux!
> www.nux.ro



-- 
Daan

Re: feature : changing volume properties dynamically in 4.5

[Mike Tutkowski]

I'll send out a [PROPOSAL] e-mail so others who may not be following this
e-mail thread have a better chance to comment on the feature.


On Tue, Jun 10, 2014 at 2:58 PM, Mike Tutkowski <
mike.tutkow...@solidfire.com> wrote:

> Here is that design document I was referring to, Punith:
>
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=42566111
>
> I've been working with a student in Tunisia who is participating in Google
> Summer of Code (GSoC) (I'm his mentor).
>
> He'll be working on part of this as will I. (He is also working on another
> related task not listed here.)
>
> Feel free to join us, if you have time available, as we can divide out
> coding and testing among the three of us.
>
> Talk to you later!
> Mike
>
>
> On Tue, Jun 10, 2014 at 10:18 AM, Mike Tutkowski <
> mike.tutkow...@solidfire.com> wrote:
>
>> I plan to draw up a design document surrounding generic key/value pairs
>> today.
>>
>> Perhaps you can take a look at it when you have time, Punith?
>>
>>
>> On Tue, Jun 10, 2014 at 10:06 AM, Mike Tutkowski <
>> mike.tutkow...@solidfire.com> wrote:
>>
>>> Hi Punith,
>>>
>>> Yeah, I hear you about the number of permutations involved.
>>>
>>> Traditionally Compute and Disk Offerings have been immutable. It makes
>>> it easier from an accounting point of view for chargeback and billing.
>>>
>>> You should definitely feel free to extend the CloudStack API. I think
>>> NetApp did this for one of their storage features in the recent past. This
>>> way vendor-specific capabilities can be more easily offered without making
>>> it look like all vendors support those particular features.
>>>
>>> I do not yet have any code in master related to generic keys/values. I'm
>>> still designing this.
>>>
>>> How does your schedule look for the 4.5 release? Do you think you might
>>> have available cycles to help out with this generic key/value
>>> implementation?
>>>
>>> Talk to you later!
>>> Mike
>>>
>>>
>>> On Tue, Jun 10, 2014 at 7:09 AM, Punith S 
>>> wrote:
>>>
 hi mike,

 thanks for the reply, i like your approach which is a very generic way
 and also we only need to do a few changes to the current cloudstack,

 but on the other hand we are tying every property of the vendor to a
 disk offering through key/value pairs, since we offer lot of properties
 like i mentioned, this can create a lot of permutation combinations of disk
 offerings, for say if i need to turn deduplication On for a specific volume
 , should i have to create a new disk offering having current properties
 with deduplication On?

 is this approach already implemented in the current master ?

 and also like you mentioned about exposing a new api, is it okay if i
 expose our own api in my util by extending the PlugableService like in
 network plugins ?

 thanks.


 On Tue, Jun 10, 2014 at 1:17 AM, Mike Tutkowski <
 mike.tutkow...@solidfire.com> wrote:

> Allow me to follow this up with more detail (with regards to what
> Chris and I talked about):
>
> As you are aware, today the way you associate a Compute Offering (CO)
> or a Disk Offering (DO) with a Primary Storage (PS) is via storage 
> tagging.
>
> This has some benefits and drawbacks.
>
> One benefit is being able to have some level of vendor independence
> from the point of view of the CO or DO. For example, if the storage tag of
> a DO is "Fast", then this can be satisfied by PS that describes itself as
> "Fast", regardless of vendor.
>
> A major drawback with the storage-tagging approach, however, is that
> you are not easily able to leverage vendor-specific features, which is
> often why you bought storage from the vendor in question to begin with.
>
> Ideally we do not want to add each vendor's features into the system
> as properties that can be seen by the admin regardless of whether or not
> the underlying storage he's actually using supports the feature in 
> question.
>
> This coarse approach, however, was sort of business as usual when I
> started in with CloudStack 1.5 years ago.
>
> That being the case, when I added QoS options to CS, I did so in a way
> where the admin would see Min IOPS and Max IOPS options regardless of
> whether or not his storage actually supported those controls (to mitigate
> this a bit in the GUI, the admin has to explicitly select "Storage QoS"
> from a combobox).
>
> We leverage the same use model with Hypervisor QoS: The admin sees
> these options regardless of whether or not they actually apply on the
> hypervisor where the VM gets deployed.
>
> Going forward, we want to implement a more fine-grain and generic
> approach.
>
> We would like to have a storage provider field for the CO and DO
> windows (this equates to the name of one and only one storage provider). 
>>>

[PROPOSAL] Collect and provide generic key/value pairs to storage plug-ins

[Mike Tutkowski]

Hi,

Please feel free to review the following proposal for 4.5:

https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=42566111

Here is the summary:

Today the way you associate a Compute Offering (CO) or a Disk Offering (DO)
with a Primary Storage (PS) is via storage tagging.

This has some benefits and drawbacks.

One benefit is being able to have some level of vendor independence from
the point of view of the CO or DO. For example, if the storage tag of a DO
is "Fast", then this can be satisfied by PS that describes itself as
"Fast", regardless of vendor.

A major drawback with the storage-tagging approach, however, is that you
are not easily able to leverage vendor-specific features, which is often
why you bought storage from the vendor in question to begin with.

Ideally we do not want to add each vendor's features into the system as
properties that can be seen by the admin regardless of whether or not the
underlying storage he's actually using supports the feature in question.
Traditionally, however, this has been business as usual in the CloudStack
codebase.

Going forward, we want to implement a more fine-grain and generic approach.

For example, in the GUI we would like to have a storage provider field for
the CO and DO windows (this equates to the name of one and only one storage
provider). If the admin inputs a specific storage provider, he can enter in
an arbitrary number of key/value pairs in another text field (perhaps we
would provide a nice entry dialog to make this easier in the GUI). These
key value pairs can be passed into the storage driver when it's asked to
create (or update) a volume and the storage driver can decide what each and
every key/value pair means, if anything.

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: [DISCUSS] Introducing Gerrit for quality? was: [PROPOSAL] Using continuous integration to maintain our code quality...

[Sheng Yang]

Hi Hugo,

The main point I want to bring up an automation tool here is, enforce
mandatory review process and test(regression test probably) to happen
before commit. That would slow down the process of course, but it should
greatly help on code quality.

Even committers would make mistakes from time to time. By adding and
enforce the review process, we would able to a. reduce the obvious bugs or
potential impact on issues author didn't know about, b. transfer the
knowledge for the project. I really think CloudStack would going to be a
more mature project in the future, but our current develop process is too
random and fail to take the whole control of the quality. By specifying
people in the area to review we should able to spot error better in the
early stage.

I know integrating the tool would change how people working on project,
since review and testing would be a necessary part of it. The problem now
is a. committers can still push bad commits without reviewing by experts in
the subsystem, b. current reviewboard is too primitive and overhead for
uploading, updating and applying the patch is too big, and c. reviewboard
is not mandatory. I would like to have devs spend more time on reviewing,
by this way at least we can gain a kind of control over the code base we're
working on.

And correct tool would be important to cut the overhead of our development
process, which can make people more focus on real work.

In conclusion, I'd like to advocate the enforced(by tool) mandatory
review(and testing integration of course) for every commits, and I think
the correct tool is important in this case.

--Sheng


On Mon, Jun 9, 2014 at 11:22 PM, Hugo Trippaers  wrote:

> Hey,
>
> I’m all for automated solutions. I’m a happy gerrit user on some other
> projects and quite fond of working with Github pull requests as well.
> However there is one important point that makes working with those tools
> work and that is a willingness by the committers to review requests. Both
> systems rely on either a well functioning and fast CI system or committers
> that consistently and rapidly review requests. Where the latter is actually
> the most important one.
>
> Both gerrit and pull requests do not improve quality. They are just tools
> to facilitate a certain way of working. If we want to improve quality we
> have to do it ourselves, no amount of automated tooling is going to solve
> it for us. As committers it is our job to review commits and make sure that
> quality is maintained. It is also our job to make sure that automated tests
> exist that will catch problems.
>
> At the moment we have a 433,412 line codebase with on average 3.91
> potential defects per line of code (according to coverity). We have a very
> small amount of unit test coverage on our core code and no real idea how
> much or what code is covered by functional testing. If we want to improve
> quality i think that is the place to start.
>
> Of course it is also wise to see if we can improve the quality of the
> incoming commits, but that is easily done by taking a few moments during
> the day to review everything that was pushed to master and fix, revert and
> add unit tests where required. Coach committers/contributors that
> consistently have trouble with adding testing cases on how to do it. That
> part is the responsibility of being a committer, not just the bit that
> allows access to the repo.
>
> If we are able to get this bit going, i’ll happily jump on any barricade
> and start a revolution to get whatever automated tooling we need to support
> this process.
>
> Cheers,
>
> Hugo
>
>
>
> On 10 jun. 2014, at 06:15, Rajani Karuturi 
> wrote:
>
> > +1 for github pull requests. They are much better and cleaner than
> review board.
> >
> > ~Rajani
> >
> >
> >
> > On 09-Jun-2014, at 9:17 pm, David Nalley  da...@gnsa.us>> wrote:
> >
> > On Fri, Jun 6, 2014 at 7:26 PM, Sheng Yang  sh...@yasker.org>> wrote:
> > Hi all,
> >
> > Seems it's a good timing to bring back the discussion about the gerrit.
> >
> > We want to do CI, and improve our code quality. One obvious way of doing
> > and reduce the workload of devs is introduce a tool to enforce the
> process.
> >
> > I've checked out quite a few projects using gerrit, which would force you
> > to ask for review, and validation before the code can be committed to the
> > repo. Looks it's really a easier way for devs according what I've heard.
> >
> > Even our competitor laid out a very detail workflow based on the use of
> > gerrit( https://wiki.openstack.org/wiki/Gerrit_Workflow ). I guess it
> can
> > make a good reference.
> >
> > Well, gerrit has been brought up a few times before. And now the new
> > process we want to enforce just fits what gerrit(or other automation
> > review/test/commit software) is for.
> >
> > Maybe it's the time for us to review the possibility of using a tool to
> > enforce our commits and improve our code quality(as well as transfer
> > knowledge) again?
> >
> > --Sheng
> >
> >
> >

Re: unused private methods in VirtualMachinManagerImpl

[Kelven Yang]

The usage of these private methods are through reflection, making it
private is to avoid exposing unnecessary internal structures to outside.

Kelven

On 6/10/14, 2:46 AM, "Rajani Karuturi"  wrote:

>Hi Kelven,
>while fixing some of the issues reported by coverity I encountered some
>unused private methods in VirtualMachineManagerImpl.java
>(https://reviews.apache.org/r/22364 ) and removed them. Koushik pointed
>that they are getting used by the job framework.
>Looks like these are used by the job framework by making them public
>through reflection and following some convention for the function names.
>
>Its very difficult to find the usages or refactor which can have some
>unforeseen consequences.
>
>Can you share some details about them? probably some javadoc?
>
>
>~Rajani
>
>
>
>On 10-Jun-2014, at 12:37 pm, Koushik Das  wrote:
>
>> 
>> ---
>> This is an automatically generated e-mail. To reply, visit:
>> https://reviews.apache.org/r/22364/#review45200
>> ---
>> 
>> 
>> 
>> engine/orchestration/src/com/cloud/vm/VirtualMachineManagerImpl.java
>> 
>> 
>>These methods are getting used by the job framework. Check
>>handleVmWorkJob() method in the same java file.
>> 
>> 
>> - Koushik Das
>> 
>> 
>> On June 10, 2014, 4:06 a.m., Rajani Karuturi wrote:
>>> 
>>> ---
>>> This is an automatically generated e-mail. To reply, visit:
>>> https://reviews.apache.org/r/22364/
>>> ---
>>> 
>>> (Updated June 10, 2014, 4:06 a.m.)
>>> 
>>> 
>>> Review request for cloudstack, daan Hoogland, Kelven Yang, Koushik
>>>Das, and Santhosh Edukulla.
>>> 
>>> 
>>> Repository: cloudstack-git
>>> 
>>> 
>>> Description
>>> ---
>>> 
>>> NPEs, unused code or dead code, unwritten field access and self
>>>assignment
>>> 
>>> 
>>> Diffs
>>> -
>>> 
>>>  engine/orchestration/src/com/cloud/vm/VirtualMachineManagerImpl.java
>>>25c67db 
>>> 
>>> Diff: https://reviews.apache.org/r/22364/diff/
>>> 
>>> 
>>> Testing
>>> ---
>>> 
>>> 
>>> Thanks,
>>> 
>>> Rajani Karuturi
>>> 
>>> 
>> 
>

Re: unused private methods in VirtualMachinManagerImpl

[Mike Tutkowski]

I haven't looked, but perhaps we should provide sufficient comments in each
of these cases so no one removes the fields thinking that they are old and
no longer in use.


On Tue, Jun 10, 2014 at 5:13 PM, Kelven Yang  wrote:

> The usage of these private methods are through reflection, making it
> private is to avoid exposing unnecessary internal structures to outside.
>
> Kelven
>
> On 6/10/14, 2:46 AM, "Rajani Karuturi"  wrote:
>
> >Hi Kelven,
> >while fixing some of the issues reported by coverity I encountered some
> >unused private methods in VirtualMachineManagerImpl.java
> >(https://reviews.apache.org/r/22364 ) and removed them. Koushik pointed
> >that they are getting used by the job framework.
> >Looks like these are used by the job framework by making them public
> >through reflection and following some convention for the function names.
> >
> >Its very difficult to find the usages or refactor which can have some
> >unforeseen consequences.
> >
> >Can you share some details about them? probably some javadoc?
> >
> >
> >~Rajani
> >
> >
> >
> >On 10-Jun-2014, at 12:37 pm, Koushik Das  wrote:
> >
> >>
> >> ---
> >> This is an automatically generated e-mail. To reply, visit:
> >> https://reviews.apache.org/r/22364/#review45200
> >> ---
> >>
> >>
> >>
> >> engine/orchestration/src/com/cloud/vm/VirtualMachineManagerImpl.java
> >> 
> >>
> >>These methods are getting used by the job framework. Check
> >>handleVmWorkJob() method in the same java file.
> >>
> >>
> >> - Koushik Das
> >>
> >>
> >> On June 10, 2014, 4:06 a.m., Rajani Karuturi wrote:
> >>>
> >>> ---
> >>> This is an automatically generated e-mail. To reply, visit:
> >>> https://reviews.apache.org/r/22364/
> >>> ---
> >>>
> >>> (Updated June 10, 2014, 4:06 a.m.)
> >>>
> >>>
> >>> Review request for cloudstack, daan Hoogland, Kelven Yang, Koushik
> >>>Das, and Santhosh Edukulla.
> >>>
> >>>
> >>> Repository: cloudstack-git
> >>>
> >>>
> >>> Description
> >>> ---
> >>>
> >>> NPEs, unused code or dead code, unwritten field access and self
> >>>assignment
> >>>
> >>>
> >>> Diffs
> >>> -
> >>>
> >>>  engine/orchestration/src/com/cloud/vm/VirtualMachineManagerImpl.java
> >>>25c67db
> >>>
> >>> Diff: https://reviews.apache.org/r/22364/diff/
> >>>
> >>>
> >>> Testing
> >>> ---
> >>>
> >>>
> >>> Thanks,
> >>>
> >>> Rajani Karuturi
> >>>
> >>>
> >>
> >
>
>


-- 
*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: [PROPOSAL] Brocade network plugin to orchestrate Brocade VDX Switches for CloudStack 4.5

[Chiradeep Vittal]

Well done.
Question: How do you figure out the VLAN –to- Brocade switch port mapping? By 
using the mac address of the VM nic?
Comment: It looks like you are creating a table (BrocadeNetworkHostMapping). 
Could you add details of this table (schema). Make sure this table appears in 
any upgrade scripts from previous releases.

From: Ritu Sabharwal mailto:rsabh...@brocade.com>>
Reply-To: "dev@cloudstack.apache.org" 
mailto:dev@cloudstack.apache.org>>
Date: Tuesday, June 10, 2014 at 11:51 AM
To: "dev@cloudstack.apache.org" 
mailto:dev@cloudstack.apache.org>>
Cc: Prakash Kaligotla mailto:pkali...@brocade.com>>, 
Nagendra Jaladanki mailto:njala...@brocade.com>>
Subject: [PROPOSAL] Brocade network plugin to orchestrate Brocade VDX Switches 
for CloudStack 4.5

Hi CS Developers,

I have added the Design document for the Plugin in the wiki.  Here is the link 
: 
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Brocade+Network+Plugin+to+Orchestrate+Brocade+VDX+Switches

Please review it and provide your comments.

Thanks & Regards,
Ritu S.

Re: [CS 4.3 | XenServer] Unable to start Virtual Router (com.cloud.exception.AgentUnavailableException)

[Chiradeep Vittal]

Found this after some googling.
http://comments.gmane.org/gmane.comp.apache.cloudstack.devel/22230

From: Florin Dumitrascu 
mailto:florin.dumitra...@intunenetworks.com>>
Reply-To: "dev@cloudstack.apache.org" 
mailto:dev@cloudstack.apache.org>>
Date: Tuesday, June 10, 2014 at 6:23 AM
To: "dev@cloudstack.apache.org" 
mailto:dev@cloudstack.apache.org>>
Subject: [CS 4.3 | XenServer] Unable to start Virtual Router 
(com.cloud.exception.AgentUnavailableException)

due to: getDomRVersionCmd failed

Re: KVM + LXC on the same host

[Chiradeep Vittal]

I thought the LXC 2.0 project uses KVM system vms on the same host as LXC 
containers?
https://cwiki.apache.org/confluence/x/oJNMAg

From: Kishan Kavala mailto:kishan.kav...@citrix.com>>
Reply-To: "dev@cloudstack.apache.org" 
mailto:dev@cloudstack.apache.org>>
Date: Sunday, June 8, 2014 at 11:59 PM
To: "dev@cloudstack.apache.org" 
mailto:dev@cloudstack.apache.org>>
Subject: RE: KVM + LXC on the same host



-Original Message-
From: ilya musayev [mailto:ilya.mailing.li...@gmail.com]
Sent: Saturday, 7 June 2014 1:50 AM
To: dev@cloudstack.apache.org
Subject: Re: KVM + LXC on the same host
Tuna
Thanks for the feedback, conceptually, i was not trying to address the issue of
sysvms not running on LXC.
Here is the use case as i see it.
Assume you roll out a farm of  10 KVM servers and your density with KVM is
200 virtual machines. Most of these VMs dont require independent kernel
and additional layers of virtualization abstraction. As the result, you can 
place
400 LXC machines and 20 fully virtualized Linux or even Windows Servers. If
you do chargeback, you can offer the LXC machines for much lower price point
since we can place more LXC containers.
Your density becomes much greater with LXC and yet you still cover the
corner case when end-user needs KVM instance.
Pierre-Luc
If I will get to try this scenario - i may have to alter the KVM/LXC agent
somewhat to make it work with CloudStack, i will let you know.
Ilya,
Some minor changes to KVM/LXC agent will be required to make this work. Below 
piece of code in createVMFromSpec (LibvirtComputingResource), deploys systems 
Vms in KVM and user Vms in LXC.
If we include some flag in VirtualMachineTO, it should be possible to specify 
which userVm has to be deployed (KVM/LXC).

if (HypervisorType.LXC == _hypervisorType && VirtualMachine.Type.User 
== vmTO.getType()) {
// LXC domain is only valid for user VMs. Use KVM for system VMs.
guest.setGuestType(GuestDef.guestType.LXC);
vm.setHvsType(HypervisorType.LXC.toString().toLowerCase());
} else {
guest.setGuestType(GuestDef.guestType.KVM);
vm.setHvsType(HypervisorType.KVM.toString().toLowerCase());
vm.setLibvirtVersion(_hypervisorLibvirtVersion);
vm.setQemuVersion(_hypervisorQemuVersion);
}



Alternative solution would be to run separate LXC and KVM clusters, which is
also a possibility - but usage and distribution will be uneven.
Regards
ilya
The concept of combining both technologies under one hypervisor On 6/6/14,
8:42 AM, Pierre-Luc Dion wrote:
> ilya,
>
> Let us know how it goes your hybrid of LXC+KVM. I'm interested to know
> how it's going,  I might try that too on the side.
>
>
>
>
> Pierre-Luc Dion
> Architecte de Solution Cloud | Cloud Solutions Architect 855-OK-CLOUD
> (855-652-5683) x1101
> - - -
>
> *CloudOps*420 rue Guy
> Montréal QC  H3J 1S6
> www.cloudops.com
> @CloudOps_
>
>
> On Fri, Jun 6, 2014 at 10:53 AM, Nguyen Anh Tu 
> mailto:t...@apache.org>> wrote:
>
>> That should be a good idea, Ilya. At that moment, i'm working on
>> Docker support. When it's done, we can run only Docker hosts, no need
>> to use KVM for hosting system vms.
>>
>> Cheers,
>> --Tuna
>>
>> Sent from my GT-N7000
>> On Jun 5, 2014 7:58 AM, "ilya musayev" 
>> mailto:ilya.mailing.li...@gmail.com>>
>> wrote:
>>
>>> We are considering running KVM and LXC on the same host and
>>> hopefully control both through cloudstack.
>>>
>>> I know there are agents involved for each component, i dont know if
>>> we
>> can
>>> have a hybrid of LXC+KVM.
>>>
>>> The use case is simple, we would like the end user to pick
>>> LXC/Docker for performance, or KVM instance if he really needed all
>>> bells and whistles
>> of
>>> dedicated kernel in fully virtualized environment.
>>>
>>> Is anyone aware why we should not mix 2 workloads on the same host?
>>> Is it possible at this point in time to mix LXC, KVM and CloudStack,
>>> i assume
>> the
>>> answer is no, but perhaps there is a hack i can try.
>>>
>>> Thanks
>>> ilya
>>>

[DISCUSS] continuous integration for plugins requiring proprietary / hardware infra

[Chiradeep Vittal]

Hi,

Since the Nuage VSP and Brocade plugins have been proposed recently, I was
wondering what is the mechanism to ensure that CI will test their plugins?

Thanks
‹
Chiradeep

Re: [Proposal] NuageVsp Network Plugin

[Chiradeep Vittal]

Can you describe any tables being added / modified? Do you intend to write to 
any existing tables?
How do you plan to test this? Will you be contributing any continuous 
integration resources for this?
Are you using any 3rd party libraries / source and what is the license?


From: Suresh Ramamurthy 
mailto:suresh.ramamur...@nuagenetworks.net>>
Reply-To: "dev@cloudstack.apache.org" 
mailto:dev@cloudstack.apache.org>>
Date: Sunday, June 8, 2014 at 5:41 AM
To: "dev@cloudstack.apache.org" 
mailto:dev@cloudstack.apache.org>>
Subject: Re: [Proposal] NuageVsp Network Plugin

Hi Ilya,

We have plans to support KVM too. We are working on it.

Thanks,
Suresh


On Wed, Jun 4, 2014 at 9:19 PM, ilya musayev 
mailto:ilya.mailing.li...@gmail.com>>
wrote:

Hi Suresh

Hope all is well,

Are there any plans to support KVM or is it just XEN?

Thanks
ilya

On 6/4/14, 9:08 PM, Suresh Ramamurthy wrote:

Hi Dev Team,

Thanks for allowing us to submit NuageVsp Network Plugin support to
CloudStack.

I have added the design specification in the wiki. Please find the link
below

https://cwiki.apache.org/confluence/display/CLOUDSTACK/
NuageVsp+Network+Plugin

Please review it and let me know if I need to provide more information in
the spec.

Could you please point me to any link that describes about the branching
strategy that we need to followed to add our code.

Thanks,
Suresh

Re: Anybody addressing this bug ? Overlaping IP subnets across different vlans

[Chiradeep Vittal]

Not sure what this has to do with Portable IP. But I agree that the check 
should be removed.

From: ilya musayev 
mailto:ilya.mailing.li...@gmail.com>>
Reply-To: "dev@cloudstack.apache.org" 
mailto:dev@cloudstack.apache.org>>
Date: Friday, June 6, 2014 at 10:38 AM
To: "dev@cloudstack.apache.org" 
mailto:dev@cloudstack.apache.org>>
Subject: Re: Anybody addressing this bug ? Overlaping IP subnets across 
different vlans

Andrija

I dont know if we can qualify this as a bug, this check was placed with
some purpose in mind - yet its not clear what it is and why would
someone think its bad.

https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=commit;h=a3b1a49c303a929c754561ca07fd8a9ed84e0382

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

Chime in on the discussion in thread above,

Regards,
ilya


On 6/6/14, 5:48 AM, Andrija Panic wrote:
Hi,
aftger upgrade to 4.3, I reported a bug where CS will not let me add
additional IP ranges when there are 2 vlans using same IP range - I
don't see point comparing IP ranges across two separate broadcast domains...

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

Thanks,

Re: unused private methods in VirtualMachinManagerImpl

[Kelven Yang]

Maybe utilizing special java annotation would get developer heads-up?
Content in comments text is easily skipped as it is not usually considered
as mandatory language constructs

Kelven   

On 6/10/14, 4:25 PM, "Mike Tutkowski"  wrote:

>I haven't looked, but perhaps we should provide sufficient comments in
>each
>of these cases so no one removes the fields thinking that they are old and
>no longer in use.
>
>
>On Tue, Jun 10, 2014 at 5:13 PM, Kelven Yang 
>wrote:
>
>> The usage of these private methods are through reflection, making it
>> private is to avoid exposing unnecessary internal structures to outside.
>>
>> Kelven
>>
>> On 6/10/14, 2:46 AM, "Rajani Karuturi" 
>>wrote:
>>
>> >Hi Kelven,
>> >while fixing some of the issues reported by coverity I encountered some
>> >unused private methods in VirtualMachineManagerImpl.java
>> >(https://reviews.apache.org/r/22364 ) and removed them. Koushik pointed
>> >that they are getting used by the job framework.
>> >Looks like these are used by the job framework by making them public
>> >through reflection and following some convention for the function
>>names.
>> >
>> >Its very difficult to find the usages or refactor which can have some
>> >unforeseen consequences.
>> >
>> >Can you share some details about them? probably some javadoc?
>> >
>> >
>> >~Rajani
>> >
>> >
>> >
>> >On 10-Jun-2014, at 12:37 pm, Koushik Das 
>>wrote:
>> >
>> >>
>> >> ---
>> >> This is an automatically generated e-mail. To reply, visit:
>> >> https://reviews.apache.org/r/22364/#review45200
>> >> ---
>> >>
>> >>
>> >>
>> >> engine/orchestration/src/com/cloud/vm/VirtualMachineManagerImpl.java
>> >> 
>> >>
>> >>These methods are getting used by the job framework. Check
>> >>handleVmWorkJob() method in the same java file.
>> >>
>> >>
>> >> - Koushik Das
>> >>
>> >>
>> >> On June 10, 2014, 4:06 a.m., Rajani Karuturi wrote:
>> >>>
>> >>> ---
>> >>> This is an automatically generated e-mail. To reply, visit:
>> >>> https://reviews.apache.org/r/22364/
>> >>> ---
>> >>>
>> >>> (Updated June 10, 2014, 4:06 a.m.)
>> >>>
>> >>>
>> >>> Review request for cloudstack, daan Hoogland, Kelven Yang, Koushik
>> >>>Das, and Santhosh Edukulla.
>> >>>
>> >>>
>> >>> Repository: cloudstack-git
>> >>>
>> >>>
>> >>> Description
>> >>> ---
>> >>>
>> >>> NPEs, unused code or dead code, unwritten field access and self
>> >>>assignment
>> >>>
>> >>>
>> >>> Diffs
>> >>> -
>> >>>
>> >>>  
>>engine/orchestration/src/com/cloud/vm/VirtualMachineManagerImpl.java
>> >>>25c67db
>> >>>
>> >>> Diff: https://reviews.apache.org/r/22364/diff/
>> >>>
>> >>>
>> >>> Testing
>> >>> ---
>> >>>
>> >>>
>> >>> Thanks,
>> >>>
>> >>> Rajani Karuturi
>> >>>
>> >>>
>> >>
>> >
>>
>>
>
>
>-- 
>*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: NetworkOrchestrator selects 2 NetworkGurus at one time....

[Chiradeep Vittal]

That is strange. Looks like a bug to me. That is because the 
ExternalGuestNetworkGuru returns ‘true’ for canHandle.

From: Ritu Sabharwal mailto:rsabh...@brocade.com>>
Reply-To: "dev@cloudstack.apache.org" 
mailto:dev@cloudstack.apache.org>>
Date: Tuesday, June 10, 2014 at 11:02 AM
To: "dev@cloudstack.apache.org" 
mailto:dev@cloudstack.apache.org>>
Subject: NetworkOrchestrator selects 2 NetworkGurus at one time

Hi,

I am writing a Network Guru for automatically orchestrating Brocade VDX 
switches to provide tenant isolation via VLAN. In my NetworkGuru, I have 
implemented the canHandle() method for Guest isolated network in Advanced zone 
using VLAN isolation. When the NetworkOrchestrator selects the NetworkGuru, it 
selects my NetworkGuru and the ExternalGuestNetworkGuru also and I see 2 
networks created. How do I make sure that ExternalGuestNetworkGuru is not 
selected by NetworkOrchestrator.

Thanks & Regards,
Ritu S.

Re: unused private methods in VirtualMachinManagerImpl

[Mike Tutkowski]

Good idea

On Tuesday, June 10, 2014, Kelven Yang  wrote:

> Maybe utilizing special java annotation would get developer heads-up?
> Content in comments text is easily skipped as it is not usually considered
> as mandatory language constructs
>
> Kelven
>
> On 6/10/14, 4:25 PM, "Mike Tutkowski" 
> wrote:
>
> >I haven't looked, but perhaps we should provide sufficient comments in
> >each
> >of these cases so no one removes the fields thinking that they are old and
> >no longer in use.
> >
> >
> >On Tue, Jun 10, 2014 at 5:13 PM, Kelven Yang 
> >wrote:
> >
> >> The usage of these private methods are through reflection, making it
> >> private is to avoid exposing unnecessary internal structures to outside.
> >>
> >> Kelven
> >>
> >> On 6/10/14, 2:46 AM, "Rajani Karuturi" 
> >>wrote:
> >>
> >> >Hi Kelven,
> >> >while fixing some of the issues reported by coverity I encountered some
> >> >unused private methods in VirtualMachineManagerImpl.java
> >> >(https://reviews.apache.org/r/22364 ) and removed them. Koushik
> pointed
> >> >that they are getting used by the job framework.
> >> >Looks like these are used by the job framework by making them public
> >> >through reflection and following some convention for the function
> >>names.
> >> >
> >> >Its very difficult to find the usages or refactor which can have some
> >> >unforeseen consequences.
> >> >
> >> >Can you share some details about them? probably some javadoc?
> >> >
> >> >
> >> >~Rajani
> >> >
> >> >
> >> >
> >> >On 10-Jun-2014, at 12:37 pm, Koushik Das 
> >>wrote:
> >> >
> >> >>
> >> >> ---
> >> >> This is an automatically generated e-mail. To reply, visit:
> >> >> https://reviews.apache.org/r/22364/#review45200
> >> >> ---
> >> >>
> >> >>
> >> >>
> >> >> engine/orchestration/src/com/cloud/vm/VirtualMachineManagerImpl.java
> >> >> 
> >> >>
> >> >>These methods are getting used by the job framework. Check
> >> >>handleVmWorkJob() method in the same java file.
> >> >>
> >> >>
> >> >> - Koushik Das
> >> >>
> >> >>
> >> >> On June 10, 2014, 4:06 a.m., Rajani Karuturi wrote:
> >> >>>
> >> >>> ---
> >> >>> This is an automatically generated e-mail. To reply, visit:
> >> >>> https://reviews.apache.org/r/22364/
> >> >>> ---
> >> >>>
> >> >>> (Updated June 10, 2014, 4:06 a.m.)
> >> >>>
> >> >>>
> >> >>> Review request for cloudstack, daan Hoogland, Kelven Yang, Koushik
> >> >>>Das, and Santhosh Edukulla.
> >> >>>
> >> >>>
> >> >>> Repository: cloudstack-git
> >> >>>
> >> >>>
> >> >>> Description
> >> >>> ---
> >> >>>
> >> >>> NPEs, unused code or dead code, unwritten field access and self
> >> >>>assignment
> >> >>>
> >> >>>
> >> >>> Diffs
> >> >>> -
> >> >>>
> >> >>>
> >>engine/orchestration/src/com/cloud/vm/VirtualMachineManagerImpl.java
> >> >>>25c67db
> >> >>>
> >> >>> Diff: https://reviews.apache.org/r/22364/diff/
> >>*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
*™*

[ACS4.4]Cherry-pick 09a357fb90b48ed6e2725ea60e632a2ad5529f79

[Min Chen]

Hi Daan,

Would you please cherry-pick the following commit from 4.4-forward to 4.4?

Commit: 09a357fb90b48ed6e2725ea60e632a2ad5529f79
CLOUDSTACK-6890:createVPC invoked by admin does not observe start flag.

Thanks
-min

Re: Review Request 22356: Fixed few coverity issues reported

[Rajani Karuturi]

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



framework/db/src/com/cloud/utils/db/TransactionLegacy.java


string values compared using '==' and not equals()

There are many such instances in the file which does == for type which is a 
string. It may be a good idea to fix them all to use equals.


- Rajani Karuturi


On June 10, 2014, 4:43 a.m., Santhosh Edukulla wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/22356/
> ---
> 
> (Updated June 10, 2014, 4:43 a.m.)
> 
> 
> Review request for cloudstack and daan Hoogland.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Fixed few coverity issues reported for resource leak, value comparison, 
> invalid loop check for result set.
> 
> 
> Diffs
> -
> 
>   engine/schema/src/com/cloud/upgrade/DatabaseCreator.java 91ef318 
>   engine/schema/src/com/cloud/upgrade/DatabaseIntegrityChecker.java c20a418 
>   engine/schema/src/com/cloud/upgrade/DatabaseUpgradeChecker.java 0761c9f 
>   framework/db/src/com/cloud/utils/crypt/EncryptionSecretKeyChanger.java 
> 58584f9 
>   framework/db/src/com/cloud/utils/db/Merovingian2.java 6eeea9f 
>   framework/db/src/com/cloud/utils/db/ScriptRunner.java 6614527 
>   framework/db/src/com/cloud/utils/db/TransactionLegacy.java ac0ea21 
>   server/src/com/cloud/test/IPRangeConfig.java 1d56471 
>   usage/src/com/cloud/usage/UsageSanityChecker.java 5e6123b 
>   utils/src/com/cloud/utils/crypt/EncryptionSecretKeySender.java 086e8a8 
> 
> Diff: https://reviews.apache.org/r/22356/diff/
> 
> 
> Testing
> ---
> 
> 1.Built the code and found no issues.
> 2.Built the simulator and ran a deploy datacenter with the changes.
> 
> 
> Thanks,
> 
> Santhosh Edukulla
> 
>

Review Request 22415: CLOUDSTACK-6867: added the option for vhdx image format in upload volume

[Anshul Gangwar]

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

Review request for cloudstack, Devdeep Singh and Rajesh Battala.


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


Repository: cloudstack-git


Description
---

added the option for vhdx image format in upload volume


Diffs
-

  ui/scripts/storage.js 604f09d 

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


Testing
---

verified by opening the upload volume dialog in UI


Thanks,

Anshul Gangwar

Re: Review Request 21973: CLOUDSTACK-6780: Resolved cleanup issue in portable ip test cases

[ASF Subversion and Git Services]

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


Commit 0190c936689fc252e51b7c412283c128b5386b24 in cloudstack's branch 
refs/heads/4.4-forward from Ashutosh K
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=0190c93 ]

CLOUDSTACK-6780: Resolved cleanup issue in portable ip test cases


- ASF Subversion and Git Services


On June 10, 2014, 11:16 a.m., Ashutosh Kelkar wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/21973/
> ---
> 
> (Updated June 10, 2014, 11:16 a.m.)
> 
> 
> Review request for cloudstack, Girish Shilamkar and Santhosh Edukulla.
> 
> 
> Bugs: CLOUDSTACK-6780
> https://issues.apache.org/jira/browse/CLOUDSTACK-6780
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Portable IP address was not getting disassociated. Added it to finally block 
> so that it will get associated always and portable ip range gets cleaned up 
> properly during cleanup.
> 
> 
> Diffs
> -
> 
>   test/integration/component/test_portable_ip.py 847bb4a 
> 
> Diff: https://reviews.apache.org/r/21973/diff/
> 
> 
> Testing
> ---
> 
> Test disassociating portable ip ... === TestName: 
> test_disassociate_ip_address_no_services | Status : SUCCESS ===
> ok
> Test disassociating portable IP with non-owner account ... === TestName: 
> test_disassociate_ip_address_other_account | Status : SUCCESS ===
> ok
> Test disassociating portable ip ... === TestName: 
> test_disassociate_ip_address_services_enabled | Status : SUCCESS ===
> ok
> 
> --
> Ran 3 tests in 263.215s
> 
> OK
> 
> 
> Thanks,
> 
> Ashutosh Kelkar
> 
>

Re: Review Request 22260: [Windows] Due to progress bar changes mysql bin path was not getting read from the Path environment variable, fixing the same

[Abhinandan Prateek]

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

Ship it!


Ship It!

- Abhinandan Prateek


On June 5, 2014, 10:21 a.m., Damodar Reddy Talakanti wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/22260/
> ---
> 
> (Updated June 5, 2014, 10:21 a.m.)
> 
> 
> Review request for cloudstack, Abhinandan Prateek and Murali Reddy.
> 
> 
> Bugs: https://issues.apache.org/jira/browse/CLOUDSTACK-6702
> 
> https://issues.apache.org/jira/browse/https://issues.apache.org/jira/browse/CLOUDSTACK-6702
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> While doing changes to enable progress bar messages during msi installation, 
> we changed the Action Execute to deferred mode which will not read the latest 
> changes done to environment variables. this was causing not to execute mysql 
> files. Fixed the same issue
> 
> 
> Diffs
> -
> 
>   scripts/installer/windows/acs.wxs 58af650 
>   setup/bindir/cloud-setup-databases.in d9dc54f 
> 
> Diff: https://reviews.apache.org/r/22260/diff/
> 
> 
> Testing
> ---
> 
> Testing is done on Windows R2 Server as well as Linux environments.
> 
> 
> Thanks,
> 
> Damodar Reddy Talakanti
> 
>

Re: NetworkOrchestrator selects 2 NetworkGurus at one time....

[Murali Reddy]

This is know design issue. Unlike service orchestration (which has prescriptive 
way to tell which network elements to be called for with network offerings ) 
there is no such logic for network design. Orchestrator just loops through all 
the network guru's asking to design the network which can results in one or 
more networks. Hugo did a cleanup [1] but I believe it was not merged as there 
was no consensus. There is 1-1 mapping between isolation type and Guru but In 
this case both Brocade Guru and ExternalNetworkGuru will attempt to design the 
VLAN isolated networks.

One in-elegent solution is to hard code ExternalGuestNetworu guru to skip 
network deign when Brocade plug-in is supposed to do design the network. Other 
option could be exclude ExternalNetworkGuru bean from spring class loader.

[1] https://www.mail-archive.com/dev@cloudstack.apache.org/msg17344.html

From: Chiradeep Vittal 
mailto:chiradeep.vit...@citrix.com>>
Date: Wednesday, 11 June 2014 6:24 AM
To: "dev@cloudstack.apache.org" 
mailto:dev@cloudstack.apache.org>>
Cc: Sheng Yang mailto:sheng.y...@citrix.com>>, Murali 
Reddy mailto:murali.re...@citrix.com>>, Jayapal Reddy 
Uradi mailto:jayapalreddy.ur...@citrix.com>>, 
Alena Prokharchyk 
mailto:alena.prokharc...@citrix.com>>
Subject: Re: NetworkOrchestrator selects 2 NetworkGurus at one time

That is strange. Looks like a bug to me. That is because the 
ExternalGuestNetworkGuru returns ‘true’ for canHandle.

From: Ritu Sabharwal mailto:rsabh...@brocade.com>>
Reply-To: "dev@cloudstack.apache.org" 
mailto:dev@cloudstack.apache.org>>
Date: Tuesday, June 10, 2014 at 11:02 AM
To: "dev@cloudstack.apache.org" 
mailto:dev@cloudstack.apache.org>>
Subject: NetworkOrchestrator selects 2 NetworkGurus at one time

Hi,

I am writing a Network Guru for automatically orchestrating Brocade VDX 
switches to provide tenant isolation via VLAN. In my NetworkGuru, I have 
implemented the canHandle() method for Guest isolated network in Advanced zone 
using VLAN isolation. When the NetworkOrchestrator selects the NetworkGuru, it 
selects my NetworkGuru and the ExternalGuestNetworkGuru also and I see 2 
networks created. How do I make sure that ExternalGuestNetworkGuru is not 
selected by NetworkOrchestrator.

Thanks & Regards,
Ritu S.

RE: Unable to upload SSL certificate

[Saksham Srivastava]

Fixed the issue in CLOUDSTACK-6864
Now we should not require double encoding in the API.

Thanks,
Saksham

-Original Message-
From: Saksham Srivastava 
Sent: Thursday, June 5, 2014 7:54 PM
To: 'Syed Ahmed'
Cc: Vijay Venkatachalam; dev@cloudstack.apache.org
Subject: RE: Unable to upload SSL certificate

Syed,

The certificate in the mentioned call is already UTF-8 encoded of the raw 
plain-text certificate.
To make the api work I had to doubly encode the cert and key .

I guess it will be good to have this mentioned in the FS/docs as there is no UI 
for this and also a sample api call can help a lot.

Thanks,
Saksham 

-Original Message-
From: Syed Ahmed [mailto:sah...@cloudops.com]
Sent: Thursday, June 5, 2014 6:23 AM
To: Saksham Srivastava
Cc: Vijay Venkatachalam; dev@cloudstack.apache.org
Subject: Re: Unable to upload SSL certificate

Can you try to encode the certificate before passing it as the param?

-Syed

On Wed 04 Jun 2014 09:01:19 AM EDT, Saksham Srivastava wrote:
> Adding Syed,
>
> I debugged the issue and here are my findings:
>
> The api is failing at CertServiceimpl: parseCertificate()
>
> return (Certificate) certPem.readObject();
>
> readObject method is failing.
>
> I tried to use the certificate used in the test 
> runUploadSslCertSelfSignedWithPassword and other tests in 
> CertServiceTest.java The following is the api call:
>
> http://10.x.x.x:8096/client/api?command=uploadSslCert&certificate=
> -BEGIN+CERTIFICATE-%0AMIIDBjCCAe4CCQD5Q6qF5dVV0jANBgkqhkiG9w0BAQUF
> ADBFMQswCQYDVQQGEwJB%0AVTETMBEGA1UECAwKU29tZS1TdGF0ZTEhMB8GA1UECgwYSW5
> 0ZXJuZXQgV2lkZ2l0%0AcyBQdHkgTHRkMB4XDTEzMTAyMTEzNTgwNFoXDTE0MTAyMTEzNT
> gwNFowRTELMAkG%0AA1UEBhMCQVUxEzARBgNVBAgMClNvbWUtU3RhdGUxITAfBgNVBAoMG
> EludGVybmV0%0AIFdpZGdpdHMgUHR5IEx0ZDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC
> AQoCggEB%0AAN%2F7lJtiEs68IC1ZPxY9NA34z9T4AU4LPS%2FkbQtuxx4X72XOBy%2By0
> cB%2FqdMD7JNV%0Ah8Mq4URDljhSDyVPdH%2F%2BjQr%2B7kWx2gNe2R%2FDCnd%2FmeVw
> wU30JJvpGVZXt%2BMTef5N%0AQAbSfDMsuT4FaUY80InbDd24HelrjwunPdY9wwKXO6zL2
> fLjyDRediiydxcx18Vb%0ADq1cm7DRi4mNkmA3RwBQMhxGp3VsfXJ4Hy2WTRCCCxWHZphA
> h3EUJGK3idum6%2F7j%0AHbAwpM%2Ft1kNWN8PZiYDZ1HbccgjmqB7Cub10BfB9g1RByiQ
> %2FC87o5cKtQha3uuXR%0AiBcHISoDydQrgxKgUpiqEF0CAwEAATANBgkqhkiG9w0BAQUF
> AAOCAQEASvulIaVb%0Azh8z2TysE6RFoYTAYIRXghFrmqCUyyQmUVTvs6vN8iaSXr%2BWM
> QJcpgXewWcFrDhr%0AmIcyRCvF91ZYb7q6lMZFSpE6u%2FSUGIEtxGUDAfbkbQdKYmrMcb
> ggUUIvSzgUFisO%0A
Kr0H9PEO4AWtCCrtOJFc7jgu03Sv06wDxn9ghkyiBRnVkbAhoKfKnI179yKruJWR%0AA3ieEj0eFoUbeSH8hDkToj4ynpkAvEGoHjHG9j%2B8FJxy%2FPTjkyVPl1ykTs%2B2Jc1B%0ASnx8f2afdTenPWyyBm3wFuRZjEAJJLUO0kxM7E8hAwhGsr%2BXYanwcr1oA1dz6M3f%0Acq26lpjTH5ITwQ%3D%3D%0A-END+CERTIFICATE-%0A&privatekey=-BEGIN+RSA+PRIVATE+KEY-%0AProc-Type%3A+4%2CENCRYPTED%0ADEK-Info%3A+DES-EDE3-CBC%2CCCA6E4CB4C4039DD%0A%0ATaVCJtB0dE9xTZbX7GOaGJwwGHVAMjU1GbRIHf0jODdP%2BquZvbjklNqsw8Ozlia9%0Aq%2FG%2BUqtRJGlIPPLpce0YCrTo0P3eixZdMs0%2BhioAEJ4OLtL0SAC6b8q%2FgB6HRfAx%0ABvNg%2BumTqeF9YB68Tcuv%2F2g4VGKiaePQACyOzMdf7lGY7ojxoJCYZa1mfKb7jWrg%0AFLwmTtLLhNjb6CnOKo3klIef3A6zdutpgxF1gARzdRyXg4qCA3boYnwEptTOlJFu%0AovxbhDG9iuYYr4gXYSs1pLYptEC8J6iWpG%2Fqzkwfr4l5Cfg5uF00bbxQE5%2BWeRaj%0AYFicvXjB%2FkcoFZuCL7M%2FYRXYxkJ%2FEZ19xI9HZNBQ4L738StkSBKL4OhpF%2FqgYZ2y%0AZLRV6XT4AijUA0Ef7YTuUsTL7Qt9drj09gCtAzXTA7gpZBn5SqT9kWhuwSzY302l%0AKF8DIC6A52igk2QKPLbleM%2FV8eCu6n%2BJ4uF%2B0GwVRROuG7ThxAQiUlJKhoEYrndL%0AnzT7jHVLftjilhVWFu2On62bRf5t1QZuob%2B1AdK0ukvEI
VsYnN4bnlAkc99Wi6C0%0AZJd9qW5L4A9XAC2gcjr3m0Rzw3RO%2Bk17faR8YfmTuJvGyBf5fnrSFoNkrninXQXp%0Ask0ajRi4PJ4XTswLyxjWRSt3egNsZBSKnVCibca%2FQoDEdZHSKXo2FlYiUYx8JHQX%0ASPUsLl9OQKC1W8%2F%2BReryqBLHCkiGEsvT8gVaXga0uhVaqe%2BPaVur2tbOHl4yCysC%0A%2BZlnKwsC84LQsUvpENdCh%2BD7E1I1Rao9IJMR6q9azKq8Ck63cOJ1fA9xSnxJGoCA%0AIlGLttlXrR32EtzYwEnlqf1nI%2FIqNQrAXQKrP5VPzHsgMFu5uD4OEZa92Q5cVTsz%0Aap%2F1UEqiJVYUt6nuA%2BaqOUlyjC0oNtYL%2FVO4DbHTFcHa8SI2cPSS6ebPMWPGHjUm%0Al9bWa6Q9iyplCYS6hinAVsAaLVjPi1Eu9Pc8rxFCmoiJYJju5NZuGI5UBK64dqcX%0AT6trWl0kB8QY63JtnrZaoStoSPImV5KVseUKDV8TM3Y76h1nLV3MSmAD1ivk9oKs%0AVKeVrDhZBWUq9Dqre%2F%2BlVGO0a2wo5VTR8hfpf8QkODPLeyNZNdfGKzkkFLuXa8V5%0AELhLQJ3FnbEU3NEvMwikV9MhP%2FELPTkZwJr%2FNKv%2B9JLs9eXtwz29I%2FQ8byQVrCCs%0AhAuDl0zHGRnqdpdSImeS2EXGx631zGMwSe8fhKelni5h6hXrXz52asr0k30BxWjf%0AWUn1uTInwVjWGy9B5j3mZlVDotFbvVAZgtR0IoFwihPl4VZd9oS13l%2BhMfrTy1YZ%0A8xFNg8ZqUQ0lSmKfOVqSBT0lP8tM8LuGxgY4cWluhsAQxR5Nl7wkundnqjcwEDDu%0AJz2rD54St1EZYGLDJZSfC7mpG2PgodsdeopQCTyFhHWa8s3caZ40GFOwaR%2B%2F5%2BYF
%0A1oRvkR1Yr4qIS7KbX4xsaFfAA5b8QfLA74L05PAgDwKofam2GFAlAKHOcI6mexPq%0AaySON9MNdnXBNxs16mBJLzCX5ljQb0ilJildVEI3aVmABptM4ehEiw%3D%3D%0A-END+RSA+PRIVATE+KEY-%0A&password=test
>
> and the api fails with "Invalid Certificate format. Expected X509 certificate"
>
> Since all the tests pass, I am assuming a problem with the api encoding 
> format.
> Can someone point to a working api call for the same.
>
> Thanks,
> Saksham
>
>
> -Original Message-
> From: Sujaya Maiyya (Intern) [mailto:sujaya.mai...@citrix.com]
> Sent: Tuesday, June 3, 2014 2:36 PM
> To: dev

Re: Review Request 22377: tagging the test case test_01_sys_vm_start with the bugId.

[Abhinandan Prateek]

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

Ship it!


Ship It!

- Abhinandan Prateek


On June 9, 2014, 1:30 p.m., bharat kumar wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/22377/
> ---
> 
> (Updated June 9, 2014, 1:30 p.m.)
> 
> 
> Review request for cloudstack and Abhinandan Prateek.
> 
> 
> Bugs: CLOUDSTACK-6877
> https://issues.apache.org/jira/browse/CLOUDSTACK-6877
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> The test case test_01_sys_vm_start is failing. we have logged a bug 
> CLOUDSTACK-6877 to track this.
> this patch tags the test case with the above mentioned bugId.
> 
> 
> Diffs
> -
> 
>   test/integration/smoke/test_secondary_storage.py 481d907 
> 
> Diff: https://reviews.apache.org/r/22377/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> bharat kumar
> 
>

Re: Review Request 22375: tagging the test case test_deploy_vgpu_enabled_vm with the bugId.

[Abhinandan Prateek]

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

Ship it!


Ship It!

- Abhinandan Prateek


On June 9, 2014, 1:40 p.m., bharat kumar wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/22375/
> ---
> 
> (Updated June 9, 2014, 1:40 p.m.)
> 
> 
> Review request for cloudstack and Abhinandan Prateek.
> 
> 
> Bugs: CLOUDSTACK-6876
> https://issues.apache.org/jira/browse/CLOUDSTACK-6876
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> The test case test_deploy_vgpu_enabled_vm is failing. we have logged a bug 
> CLOUDSTACK-6876 to track this.
> this patch tags the test case with the above mentioned bugId.
> 
> 
> Diffs
> -
> 
>   test/integration/smoke/test_deploy_vgpu_enabled_vm.py 13fad61 
> 
> Diff: https://reviews.apache.org/r/22375/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> bharat kumar
> 
>

Re: Review Request 21973: CLOUDSTACK-6780: Resolved cleanup issue in portable ip test cases

[ASF Subversion and Git Services]

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


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

CLOUDSTACK-6780: Resolved cleanup issue in portable ip test cases


- ASF Subversion and Git Services


On June 10, 2014, 11:16 a.m., Ashutosh Kelkar wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/21973/
> ---
> 
> (Updated June 10, 2014, 11:16 a.m.)
> 
> 
> Review request for cloudstack, Girish Shilamkar and Santhosh Edukulla.
> 
> 
> Bugs: CLOUDSTACK-6780
> https://issues.apache.org/jira/browse/CLOUDSTACK-6780
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Portable IP address was not getting disassociated. Added it to finally block 
> so that it will get associated always and portable ip range gets cleaned up 
> properly during cleanup.
> 
> 
> Diffs
> -
> 
>   test/integration/component/test_portable_ip.py 847bb4a 
> 
> Diff: https://reviews.apache.org/r/21973/diff/
> 
> 
> Testing
> ---
> 
> Test disassociating portable ip ... === TestName: 
> test_disassociate_ip_address_no_services | Status : SUCCESS ===
> ok
> Test disassociating portable IP with non-owner account ... === TestName: 
> test_disassociate_ip_address_other_account | Status : SUCCESS ===
> ok
> Test disassociating portable ip ... === TestName: 
> test_disassociate_ip_address_services_enabled | Status : SUCCESS ===
> ok
> 
> --
> Ran 3 tests in 263.215s
> 
> OK
> 
> 
> Thanks,
> 
> Ashutosh Kelkar
> 
>

Re: Review Request 22378: tagging the test case test_01_snapshot_root_disk with the bugId.

[Abhinandan Prateek]

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

Ship it!


Ship It!

- Abhinandan Prateek


On June 9, 2014, 1:36 p.m., bharat kumar wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/22378/
> ---
> 
> (Updated June 9, 2014, 1:36 p.m.)
> 
> 
> Review request for cloudstack and Abhinandan Prateek.
> 
> 
> Bugs: CLOUDSTACK-6878
> https://issues.apache.org/jira/browse/CLOUDSTACK-6878
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> The test case test_01_snapshot_root_disk is failing. we have logged a bug 
> CLOUDSTACK-6876 to track this.
> this patch tags the test case with the above mentioned bugId.
> 
> 
> Diffs
> -
> 
>   test/integration/smoke/test_snapshots.py a960e70 
> 
> Diff: https://reviews.apache.org/r/22378/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> bharat kumar
> 
>

Re: Review Request 22376: tagging the test case test_09_delete_detached_volume with the bugId.

[Abhinandan Prateek]

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

Ship it!


Ship It!

- Abhinandan Prateek


On June 9, 2014, 1:24 p.m., bharat kumar wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/22376/
> ---
> 
> (Updated June 9, 2014, 1:24 p.m.)
> 
> 
> Review request for cloudstack and Abhinandan Prateek.
> 
> 
> Bugs: CLOUDSTACK-6875
> https://issues.apache.org/jira/browse/CLOUDSTACK-6875
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> The test case test_09_delete_detached_volume is failing. we have logged a bug 
> CLOUDSTACK-6875 to track this.
> this patch tags the test case with the above mentioned bugId.
> 
> 
> Diffs
> -
> 
>   test/integration/smoke/test_volumes.py 73c2722 
> 
> Diff: https://reviews.apache.org/r/22376/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> bharat kumar
> 
>

Re: Review Request 22379: tagging the test case test_vpc_site2site_vpn with the bugId.

[Abhinandan Prateek]

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

Ship it!


Ship It!

- Abhinandan Prateek


On June 9, 2014, 1:39 p.m., bharat kumar wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/22379/
> ---
> 
> (Updated June 9, 2014, 1:39 p.m.)
> 
> 
> Review request for cloudstack and Abhinandan Prateek.
> 
> 
> Bugs: CLOUDSTACK-6879
> https://issues.apache.org/jira/browse/CLOUDSTACK-6879
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> The test case test_vpc_site2site_vpn is failing. we have logged a bug 
> CLOUDSTACK-6876 to track this.
> this patch tags the test case with the above mentioned bugId.
> 
> 
> Diffs
> -
> 
>   test/integration/smoke/test_vpc_vpn.py 03826e9 
> 
> Diff: https://reviews.apache.org/r/22379/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> bharat kumar
> 
>