Re: Review Request: add state change in createVolume back to Allocated if anything fails

[Nitin Mehta]

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

Ship it!


Ship It!

- Nitin Mehta


On April 19, 2013, 4:59 a.m., Marcus Sorensen wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/10623/
> ---
> 
> (Updated April 19, 2013, 4:59 a.m.)
> 
> 
> Review request for cloudstack and Chip Childers.
> 
> 
> Description
> ---
> 
> createVolume changes the volume state from 'Allocated' to 'Creating', but has 
> no code to change it back to 'Allocated' if anything goes wrong, despite 
> there already being a path from 'Creating' to 'Allocated' for volumes, via 
> the OperationFailed event. Adding this in fixes the issue and avoids leaving 
> disks in an unusable state.
> 
> 
> This addresses bug CLOUDSTACK-2104.
> 
> 
> Diffs
> -
> 
>   server/src/com/cloud/storage/StorageManagerImpl.java 624361f 
> 
> Diff: https://reviews.apache.org/r/10623/diff/
> 
> 
> Testing
> ---
> 
> Tested in devcloud-kvm, volume that was larger than primary storage failed to 
> attack, and went back to 'Allocated' from 'Creating' upon the failure. I was 
> then able to retry, and delete the disk.
> 
> 
> Thanks,
> 
> Marcus Sorensen
> 
>

Re: Review Request: Storage motion changes for xenserver

[Abhinandan Prateek]

> On April 19, 2013, 6:05 a.m., Abhinandan Prateek wrote:
> > Ship It!

commit 21ce3befc8ea9e1a6de449a21499a50ff141a183
Author: Devdeep Singh 
Date:   Mon Apr 15 11:42:18 2013 +0530


- Abhinandan


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


On April 15, 2013, 7:24 a.m., Devdeep Singh wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/10196/
> ---
> 
> (Updated April 15, 2013, 7:24 a.m.)
> 
> 
> Review request for cloudstack, Abhinandan Prateek, edison su, Alex Huang, and 
> anthony xu.
> 
> 
> Description
> ---
> 
> Storage motion for Xenserver. FS for the feature 
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Enabling+Storage+XenMotion+for+XenServer
> 1. Implemented Api findStoragePoolsForMigration. Added a new response 
> objects to list storage pools available for migration.
> 2. Updated migrateVolume api for allowing migrating volumes of running 
> vms. These changes are integrated into the latest storage refactoring changes.
> 3. Added the implementation for findHostsForMigration api. It lists the 
> hosts to which an instance can be migrated, including hosts from within and 
> across clusters to which an instance may be migrated with storage motion. The 
> work of migrating a volume of a running vm is also done in copyAsync.
> 4. Updated the listHosts api for backward compatibility.
> 5. Added the implementation for migrateVirtualMachineWithVolume api. It 
> migrates an instance with its volumes within a cluster and also across 
> clusters. Also introduced a new XenServerStorageMotionStrategy for migrating 
> volumes of a vm. When a vm is being migrated with its volumes, the vm is put 
> in migrating state and a request is send to the volume manager to migrate the 
> vm and its volumes. Volume manager calls into the volume service which 
> forwards the request to data motion service after moving all the volumes to 
> migrating state. Data motion service enumerates the strategies and the 
> request reaches the XenServerStorageMotionStrategy. It calls in to the 
> resource to complete the operation.
> 6. Resolved an issue where storage xenmotion of 2nd VM created from the 
> same template to a host was failing with duplicate_vm exception. Made changes 
> to remove the mac_seed key value pair from other_config when vms are created. 
> This is was storage motion to fail.
> 7. Updated the db upgrade schema script.
> 8. Added the right permissions in commands.properties
> 9. Marvin tests for testing storage motion. Following scenarios are 
> tested.
> 9.1. A virtual machine is migrated to another host. Its volumes are also 
> migrated to another storage pool.
> 9.2. Just the volumes of a vm are migrated to another storage pool while 
> the vm continues to run on the same host.
> 10. Unit tests for testing migration of a vm with its volumes.
> 
> 
> This addresses bug https://issues.apache.org/jira/browse/CLOUDSTACK-659.
> 
> 
> Diffs
> -
> 
>   api/src/com/cloud/agent/api/MigrateWithStorageAnswer.java PRE-CREATION 
>   api/src/com/cloud/agent/api/MigrateWithStorageCommand.java PRE-CREATION 
>   api/src/com/cloud/agent/api/MigrateWithStorageCompleteAnswer.java 
> PRE-CREATION 
>   api/src/com/cloud/agent/api/MigrateWithStorageCompleteCommand.java 
> PRE-CREATION 
>   api/src/com/cloud/agent/api/MigrateWithStorageReceiveAnswer.java 
> PRE-CREATION 
>   api/src/com/cloud/agent/api/MigrateWithStorageReceiveCommand.java 
> PRE-CREATION 
>   api/src/com/cloud/agent/api/MigrateWithStorageSendAnswer.java PRE-CREATION 
>   api/src/com/cloud/agent/api/MigrateWithStorageSendCommand.java PRE-CREATION 
>   api/src/com/cloud/agent/api/storage/MigrateVolumeAnswer.java PRE-CREATION 
>   api/src/com/cloud/agent/api/storage/MigrateVolumeCommand.java PRE-CREATION 
>   api/src/com/cloud/hypervisor/HypervisorCapabilities.java aff81b0 
>   api/src/com/cloud/server/ManagementService.java 6e6dbc3 
>   api/src/com/cloud/vm/UserVmService.java d963b74 
>   api/src/org/apache/cloudstack/api/ApiConstants.java b08e992 
>   api/src/org/apache/cloudstack/api/ResponseGenerator.java c0dd57e 
>   
> api/src/org/apache/cloudstack/api/command/admin/host/FindHostsForMigrationCmd.java
>  PRE-CREATION 
>   api/src/org/apache/cloudstack/api/command/admin/host/ListHostsCmd.java 
> 29844c3 
>   
> api/src/org/apache/cloudstack/api/command/admin/storage/FindStoragePoolsForMigrationCmd.java
>  PRE-CREATION 
>   
> api/src/org/apache/cloudstack/api/command/admin/vm/MigrateVirtualMachineWithVolumeCmd.java
>  PRE-CREATION 
>   api/src/org/apache/cloudstack/api/command/user/volume/MigrateVolumeCmd.java 
> 287241a 
>   api/src/org/apach

Re: Review Request: Storage motion changes for xenserver

[Abhinandan Prateek]

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

Ship it!


Ship It!

- Abhinandan Prateek


On April 15, 2013, 7:24 a.m., Devdeep Singh wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/10196/
> ---
> 
> (Updated April 15, 2013, 7:24 a.m.)
> 
> 
> Review request for cloudstack, Abhinandan Prateek, edison su, Alex Huang, and 
> anthony xu.
> 
> 
> Description
> ---
> 
> Storage motion for Xenserver. FS for the feature 
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Enabling+Storage+XenMotion+for+XenServer
> 1. Implemented Api findStoragePoolsForMigration. Added a new response 
> objects to list storage pools available for migration.
> 2. Updated migrateVolume api for allowing migrating volumes of running 
> vms. These changes are integrated into the latest storage refactoring changes.
> 3. Added the implementation for findHostsForMigration api. It lists the 
> hosts to which an instance can be migrated, including hosts from within and 
> across clusters to which an instance may be migrated with storage motion. The 
> work of migrating a volume of a running vm is also done in copyAsync.
> 4. Updated the listHosts api for backward compatibility.
> 5. Added the implementation for migrateVirtualMachineWithVolume api. It 
> migrates an instance with its volumes within a cluster and also across 
> clusters. Also introduced a new XenServerStorageMotionStrategy for migrating 
> volumes of a vm. When a vm is being migrated with its volumes, the vm is put 
> in migrating state and a request is send to the volume manager to migrate the 
> vm and its volumes. Volume manager calls into the volume service which 
> forwards the request to data motion service after moving all the volumes to 
> migrating state. Data motion service enumerates the strategies and the 
> request reaches the XenServerStorageMotionStrategy. It calls in to the 
> resource to complete the operation.
> 6. Resolved an issue where storage xenmotion of 2nd VM created from the 
> same template to a host was failing with duplicate_vm exception. Made changes 
> to remove the mac_seed key value pair from other_config when vms are created. 
> This is was storage motion to fail.
> 7. Updated the db upgrade schema script.
> 8. Added the right permissions in commands.properties
> 9. Marvin tests for testing storage motion. Following scenarios are 
> tested.
> 9.1. A virtual machine is migrated to another host. Its volumes are also 
> migrated to another storage pool.
> 9.2. Just the volumes of a vm are migrated to another storage pool while 
> the vm continues to run on the same host.
> 10. Unit tests for testing migration of a vm with its volumes.
> 
> 
> This addresses bug https://issues.apache.org/jira/browse/CLOUDSTACK-659.
> 
> 
> Diffs
> -
> 
>   api/src/com/cloud/agent/api/MigrateWithStorageAnswer.java PRE-CREATION 
>   api/src/com/cloud/agent/api/MigrateWithStorageCommand.java PRE-CREATION 
>   api/src/com/cloud/agent/api/MigrateWithStorageCompleteAnswer.java 
> PRE-CREATION 
>   api/src/com/cloud/agent/api/MigrateWithStorageCompleteCommand.java 
> PRE-CREATION 
>   api/src/com/cloud/agent/api/MigrateWithStorageReceiveAnswer.java 
> PRE-CREATION 
>   api/src/com/cloud/agent/api/MigrateWithStorageReceiveCommand.java 
> PRE-CREATION 
>   api/src/com/cloud/agent/api/MigrateWithStorageSendAnswer.java PRE-CREATION 
>   api/src/com/cloud/agent/api/MigrateWithStorageSendCommand.java PRE-CREATION 
>   api/src/com/cloud/agent/api/storage/MigrateVolumeAnswer.java PRE-CREATION 
>   api/src/com/cloud/agent/api/storage/MigrateVolumeCommand.java PRE-CREATION 
>   api/src/com/cloud/hypervisor/HypervisorCapabilities.java aff81b0 
>   api/src/com/cloud/server/ManagementService.java 6e6dbc3 
>   api/src/com/cloud/vm/UserVmService.java d963b74 
>   api/src/org/apache/cloudstack/api/ApiConstants.java b08e992 
>   api/src/org/apache/cloudstack/api/ResponseGenerator.java c0dd57e 
>   
> api/src/org/apache/cloudstack/api/command/admin/host/FindHostsForMigrationCmd.java
>  PRE-CREATION 
>   api/src/org/apache/cloudstack/api/command/admin/host/ListHostsCmd.java 
> 29844c3 
>   
> api/src/org/apache/cloudstack/api/command/admin/storage/FindStoragePoolsForMigrationCmd.java
>  PRE-CREATION 
>   
> api/src/org/apache/cloudstack/api/command/admin/vm/MigrateVirtualMachineWithVolumeCmd.java
>  PRE-CREATION 
>   api/src/org/apache/cloudstack/api/command/user/volume/MigrateVolumeCmd.java 
> 287241a 
>   api/src/org/apache/cloudstack/api/response/HostForMigrationResponse.java 
> PRE-CREATION 
>   api/src/org/apache/cloudstack/api/response/HostResponse.java f5aa8f9 
>   
> api

Re: Review Request: CLOUDSTACK-741: Granular Global Parameters

[Abhinandan Prateek]

> On April 19, 2013, 5:06 a.m., Abhinandan Prateek wrote:
> > Ship It!

This commit makes framework level changes to define scope for parameters. This 
will be used to actually granularize required params.


- Abhinandan


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


On April 19, 2013, 4:07 a.m., Harikrishna Patnala wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/10548/
> ---
> 
> (Updated April 19, 2013, 4:07 a.m.)
> 
> 
> Review request for cloudstack, Abhinandan Prateek, Kishan Kavala, and Nitin 
> Mehta.
> 
> 
> Description
> ---
> 
> CLOUDSTACK-741: Granular Global Parameters
> 
> Modified UpdateConfiguration API and ListConfiguration API by adding 
> additional parameter scope and resource id (zone/cluster/pool/account).
> Scope decides the parameter which level we can update the value and id is the 
> corresponding id based on the scope.
> This scope is defined in the config.java file where we are creating groups 
> for each level(zone/cluster/pool/account).
> Currently submitted the patch for the zone level parameter use.external.dns.
> 
> Included unit tests and marvin tests.
> 
> 
> This addresses bug CLOUDSTACK-741.
> 
> 
> Diffs
> -
> 
>   api/src/org/apache/cloudstack/api/command/admin/config/ListCfgsByCmd.java 
> aabfd4a 
>   api/src/org/apache/cloudstack/api/command/admin/config/UpdateCfgCmd.java 
> ffeb586 
>   api/src/org/apache/cloudstack/api/response/ConfigurationResponse.java 
> 95b8af2 
>   api/test/org/apache/cloudstack/api/command/test/ListCfgCmdTest.java 
> PRE-CREATION 
>   api/test/org/apache/cloudstack/api/command/test/UpdateCfgCmdTest.java 
> PRE-CREATION 
>   
> engine/api/src/org/apache/cloudstack/storage/datastore/db/StoragePoolDetailsDao.java
>  be71670 
>   server/src/com/cloud/configuration/Config.java 2993966 
>   server/src/com/cloud/configuration/ConfigurationManager.java afaf0d6 
>   server/src/com/cloud/configuration/ConfigurationManagerImpl.java 4fc2db7 
>   server/src/com/cloud/configuration/dao/ConfigurationDao.java c86c024 
>   server/src/com/cloud/network/router/VirtualNetworkApplianceManagerImpl.java 
> ab91059 
>   server/src/com/cloud/server/ConfigurationServer.java f441b1f 
>   server/src/com/cloud/server/ConfigurationServerImpl.java c4da1ab 
>   server/src/com/cloud/server/ManagementServerImpl.java 98f789a 
>   server/src/com/cloud/storage/dao/StoragePoolDetailsDaoImpl.java 0d797ed 
>   server/test/com/cloud/vpc/MockConfigurationManagerImpl.java 9443815 
>   test/integration/smoke/test_UpdateCfg.py PRE-CREATION 
> 
> Diff: https://reviews.apache.org/r/10548/diff/
> 
> 
> Testing
> ---
> 
> Tested locally
> - tested the modified UpdateConfiguration API and ListConfiguration API by 
> providing the zone scope and zone id
> - tested the modified parameter to take the updated value at zone level(after 
> updation).
> 
> 
> Thanks,
> 
> Harikrishna Patnala
> 
>

Re: Review Request: CLOUDSTACK-741: Granular Global Parameters

[ASF Subversion and Git Services]

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


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

CLOUDSTACK-741: Granular Global Parameters

Signed-off-by: Abhinandan Prateek 


- ASF Subversion and Git Services


On April 19, 2013, 4:07 a.m., Harikrishna Patnala wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/10548/
> ---
> 
> (Updated April 19, 2013, 4:07 a.m.)
> 
> 
> Review request for cloudstack, Abhinandan Prateek, Kishan Kavala, and Nitin 
> Mehta.
> 
> 
> Description
> ---
> 
> CLOUDSTACK-741: Granular Global Parameters
> 
> Modified UpdateConfiguration API and ListConfiguration API by adding 
> additional parameter scope and resource id (zone/cluster/pool/account).
> Scope decides the parameter which level we can update the value and id is the 
> corresponding id based on the scope.
> This scope is defined in the config.java file where we are creating groups 
> for each level(zone/cluster/pool/account).
> Currently submitted the patch for the zone level parameter use.external.dns.
> 
> Included unit tests and marvin tests.
> 
> 
> This addresses bug CLOUDSTACK-741.
> 
> 
> Diffs
> -
> 
>   api/src/org/apache/cloudstack/api/command/admin/config/ListCfgsByCmd.java 
> aabfd4a 
>   api/src/org/apache/cloudstack/api/command/admin/config/UpdateCfgCmd.java 
> ffeb586 
>   api/src/org/apache/cloudstack/api/response/ConfigurationResponse.java 
> 95b8af2 
>   api/test/org/apache/cloudstack/api/command/test/ListCfgCmdTest.java 
> PRE-CREATION 
>   api/test/org/apache/cloudstack/api/command/test/UpdateCfgCmdTest.java 
> PRE-CREATION 
>   
> engine/api/src/org/apache/cloudstack/storage/datastore/db/StoragePoolDetailsDao.java
>  be71670 
>   server/src/com/cloud/configuration/Config.java 2993966 
>   server/src/com/cloud/configuration/ConfigurationManager.java afaf0d6 
>   server/src/com/cloud/configuration/ConfigurationManagerImpl.java 4fc2db7 
>   server/src/com/cloud/configuration/dao/ConfigurationDao.java c86c024 
>   server/src/com/cloud/network/router/VirtualNetworkApplianceManagerImpl.java 
> ab91059 
>   server/src/com/cloud/server/ConfigurationServer.java f441b1f 
>   server/src/com/cloud/server/ConfigurationServerImpl.java c4da1ab 
>   server/src/com/cloud/server/ManagementServerImpl.java 98f789a 
>   server/src/com/cloud/storage/dao/StoragePoolDetailsDaoImpl.java 0d797ed 
>   server/test/com/cloud/vpc/MockConfigurationManagerImpl.java 9443815 
>   test/integration/smoke/test_UpdateCfg.py PRE-CREATION 
> 
> Diff: https://reviews.apache.org/r/10548/diff/
> 
> 
> Testing
> ---
> 
> Tested locally
> - tested the modified UpdateConfiguration API and ListConfiguration API by 
> providing the zone scope and zone id
> - tested the modified parameter to take the updated value at zone level(after 
> updation).
> 
> 
> Thanks,
> 
> Harikrishna Patnala
> 
>

Re: Review Request: CLOUDSTACK-741: Granular Global Parameters

[Abhinandan Prateek]

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

Ship it!


Ship It!

- Abhinandan Prateek


On April 19, 2013, 4:07 a.m., Harikrishna Patnala wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/10548/
> ---
> 
> (Updated April 19, 2013, 4:07 a.m.)
> 
> 
> Review request for cloudstack, Abhinandan Prateek, Kishan Kavala, and Nitin 
> Mehta.
> 
> 
> Description
> ---
> 
> CLOUDSTACK-741: Granular Global Parameters
> 
> Modified UpdateConfiguration API and ListConfiguration API by adding 
> additional parameter scope and resource id (zone/cluster/pool/account).
> Scope decides the parameter which level we can update the value and id is the 
> corresponding id based on the scope.
> This scope is defined in the config.java file where we are creating groups 
> for each level(zone/cluster/pool/account).
> Currently submitted the patch for the zone level parameter use.external.dns.
> 
> Included unit tests and marvin tests.
> 
> 
> This addresses bug CLOUDSTACK-741.
> 
> 
> Diffs
> -
> 
>   api/src/org/apache/cloudstack/api/command/admin/config/ListCfgsByCmd.java 
> aabfd4a 
>   api/src/org/apache/cloudstack/api/command/admin/config/UpdateCfgCmd.java 
> ffeb586 
>   api/src/org/apache/cloudstack/api/response/ConfigurationResponse.java 
> 95b8af2 
>   api/test/org/apache/cloudstack/api/command/test/ListCfgCmdTest.java 
> PRE-CREATION 
>   api/test/org/apache/cloudstack/api/command/test/UpdateCfgCmdTest.java 
> PRE-CREATION 
>   
> engine/api/src/org/apache/cloudstack/storage/datastore/db/StoragePoolDetailsDao.java
>  be71670 
>   server/src/com/cloud/configuration/Config.java 2993966 
>   server/src/com/cloud/configuration/ConfigurationManager.java afaf0d6 
>   server/src/com/cloud/configuration/ConfigurationManagerImpl.java 4fc2db7 
>   server/src/com/cloud/configuration/dao/ConfigurationDao.java c86c024 
>   server/src/com/cloud/network/router/VirtualNetworkApplianceManagerImpl.java 
> ab91059 
>   server/src/com/cloud/server/ConfigurationServer.java f441b1f 
>   server/src/com/cloud/server/ConfigurationServerImpl.java c4da1ab 
>   server/src/com/cloud/server/ManagementServerImpl.java 98f789a 
>   server/src/com/cloud/storage/dao/StoragePoolDetailsDaoImpl.java 0d797ed 
>   server/test/com/cloud/vpc/MockConfigurationManagerImpl.java 9443815 
>   test/integration/smoke/test_UpdateCfg.py PRE-CREATION 
> 
> Diff: https://reviews.apache.org/r/10548/diff/
> 
> 
> Testing
> ---
> 
> Tested locally
> - tested the modified UpdateConfiguration API and ListConfiguration API by 
> providing the zone scope and zone id
> - tested the modified parameter to take the updated value at zone level(after 
> updation).
> 
> 
> Thanks,
> 
> Harikrishna Patnala
> 
>

Review Request: add state change in createVolume back to Allocated if anything fails

[Marcus Sorensen]

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

Review request for cloudstack and Chip Childers.


Description
---

createVolume changes the volume state from 'Allocated' to 'Creating', but has 
no code to change it back to 'Allocated' if anything goes wrong, despite there 
already being a path from 'Creating' to 'Allocated' for volumes, via the 
OperationFailed event. Adding this in fixes the issue and avoids leaving disks 
in an unusable state.


This addresses bug CLOUDSTACK-2104.


Diffs
-

  server/src/com/cloud/storage/StorageManagerImpl.java 624361f 

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


Testing
---

Tested in devcloud-kvm, volume that was larger than primary storage failed to 
attack, and went back to 'Allocated' from 'Creating' upon the failure. I was 
then able to retry, and delete the disk.


Thanks,

Marcus Sorensen

Re: no tinyLinux template

[Mike Tutkowski]

It's strange...I deleted my entire cloud and re-created it this way:

mvn -pl developer,tools/devcloud -Ddeploydb -P developer

cd tools/devcloud ; python ../marvin/marvin/deployDataCenter.py -i
devcloud.cfg

but still no tinyLinux template (even though it is in the cloud.vm_template
table).


On Thu, Apr 18, 2013 at 10:05 PM, Mike Tutkowski <
mike.tutkow...@solidfire.com> wrote:

> Here is what I used to deploy the DB:
>
> mvn -pl developer,tools/devcloud -Ddeploydb -P developer
>
> Also, cloud.vm_template has this row:
>
> '5', 'tiny Linux', 'tiny Linux', '2a182234-a87b-11e2-84ee-e322fe93e6c9',
> '1', '1', 'BUILTIN', '0', '64', '
> http://people.apache.org/~bhaisaab/vms/ttylinux_pv.vhd', 'VHD',
> '2013-04-18 16:56:11', NULL, '1', '046e134e642e6d344b34648223ba4bc1', 'tiny
> Linux', '0', '0', '12', '1', '0', '1', '1', 'XenServer', NULL, NULL, '0',
> NULL, NULL, NULL, NULL, '1'
>
>
>
> On Thu, Apr 18, 2013 at 9:39 PM, Rohit Yadav  wrote:
>
>> On Fri, Apr 19, 2013 at 8:26 AM, Mike Tutkowski <
>> mike.tutkow...@solidfire.com> wrote:
>>
>> > Hi,
>> >
>> > I've switched back to 4.2 (from 4.1), cleaned out my database,
>> re-created
>> > my DevCloud2 environment and all looks good with the exception that I do
>> > not have a tinyLinux template.
>> >
>> > My SSVM is up and running.
>> >
>> > Any thoughts on what I should do here?
>> >
>>
>> Did you forgot to deploydb with -P tools/devcloud? Looks like db does
>> not know about ttylinux; check in cloud.vm_templates etc?
>>
>> Cheers.
>>
>>
>> >
>> > Thanks!
>> >
>> > --
>> > *Mike Tutkowski*
>> > *Senior CloudStack Developer, SolidFire Inc.*
>> > e: mike.tutkow...@solidfire.com
>> > o: 303.746.7302
>> > Advancing the way the world uses the
>> > cloud
>> > *™*
>> >
>>
>
>
>
> --
> *Mike Tutkowski*
> *Senior CloudStack Developer, SolidFire Inc.*
> e: mike.tutkow...@solidfire.com
> o: 303.746.7302
> Advancing the way the world uses the 
> cloud
> *™*
>



-- 
*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: CS 4.0.1 | KVM | CentOS 6.3

[Ahmad Emneina]

I'd make a backup of the db, and delete the entries where the MS is down. 
Hopefully that'll clear up your logs.

Ahmad

On Apr 18, 2013, at 7:59 PM, Maurice Lawler  wrote:

> I'm 100% sure it's user error! As always *grin*  Of course I removed my IP 
> address / hostname.
> 
> - Maurice
> 
> The output is: 
> 
> mysql> SELECT * FROM mshost\G;
> *** 1. row ***
>   id: 1
> msid: 219948120943996
>runid: 1366256187370
> name: myhostname.domain.com
>state: Down
>  version: 4.0.1.20130201075054
>   service_ip: myipaddress
> service_port: 9090
>  last_update: 2013-04-19 01:49:19
>  removed: NULL
>  alert_count: 0
> *** 2. row ***
>   id: 2
> msid: 279278805451357
>runid: 1366250623758
> name: myhostname.domain.com
>state: Down
>  version: 4.0.1.20130201075054
>   service_ip: myipaddress
> service_port: 9090
>  last_update: 2013-04-18 03:32:29
>  removed: NULL
>  alert_count: 0
> *** 3. row ***
>   id: 3
> msid: 279278805450862
>runid: 1366337908232
> name: myhostname.domain.com
>state: Up
>  version: 4.0.1.20130201075054
>   service_ip: myipaddress
> service_port: 9090
>  last_update: 2013-04-19 02:57:12
>  removed: NULL
>  alert_count: 0
> 3 rows in set (0.00 sec)
> 
> 
> 
> On Apr 18, 2013, at 02:11 PM, Chiradeep Vittal  
> wrote:
> 
>> Maurice, it appears to be something specific to the sequence of actions
>> you took or your environment.
>> 
>> Developers and QA kill and restart their management servers dozens of
>> times a day and have (AFAIK) never seen this issue.
>> 
>> What are the entries in the mshost table?
>> 
>> 
>> On 4/17/13 11:20 PM, "Maurice Lawler"  wrote:
>> 
>> >Thank you. How would I correct this and why would the table state
>> >something other then what I have setup, what would have caused that?
>> >
>> >
>> >On Apr 18, 2013, at 12:27 AM, Chiradeep Vittal
>> > wrote:
>> >
>> >> That's probably not what the mshost table thinks?
>> >> 
>> >> On 4/17/13 11:00 AM, "Maurice Lawler"  wrote:
>> >> 
>> >>> No. I have ONE server running.
>> >>> 
>> >>> One MS - One Install of CS - One of everything. All on the same IP
>> >>> address. 
>> >>> 
>> >>> 
>> >>> On Apr 17, 2013, at 12:05 PM, Chiradeep Vittal
>> >>>  wrote:
>> >>> 
>>  You probably have another MS connecting to the same database?
>>  
>>  On 4/17/13 9:49 AM, "Maurice Lawler"  wrote:
>>  
>> > No the management IP hasn't changed. My question is why when
>> >restarting
>> > Cloud Management the issue is cleared up. Then almost an hour later,
>> >it
>> > starts in again; how do I correct this issue?
>> > 
>> > 
>> > On Apr 17, 2013, at 12:23 AM, Chiradeep Vittal
>> >  wrote:
>> > 
>> >> Did the management server ip change? It somehow thinks there's 2
>> >> management servers.
>> >> 
>> >> On 4/16/13 7:00 PM, "Maurice Lawler"  wrote:
>> >> 
>> >>> Greetings,
>> >>> 
>> >>> I am having this FLOOD my log. I will have you know, this is ONE
>> >>> server
>> >>> ONE HOST. KVM | CentOS 6.3 | Cloudstack 4.0.1
>> >>> 
>> >>> I have found restarting cloud management solves the issue for
>> >>>awhile,
>> >>> then it starts again.
>> >>> 
>> >>> Please advise.
>> >>> 
>> >>> - Maurice
>> >>> 
>> >>>  Eror Log 
>> >>> 
>> >>> 2013-04-16 20:58:38,993 DEBUG
>> >>> [cloud.consoleproxy.ConsoleProxyManagerImpl] (consoleproxy-1:null)
>> >>> Zone 1
>> >>> is ready to launch console proxy
>> >>> 2013-04-16 20:58:39,137 DEBUG [cloud.cluster.ClusterManagerImpl]
>> >>> (Cluster-Heartbeat-1:null) Detected management node left, id:1,
>> >>> nodeIP:MYIPADDRESSHERE
>> >>> 2013-04-16 20:58:39,137 INFO [cloud.cluster.ClusterManagerImpl]
>> >>> (Cluster-Heartbeat-1:null) Trying to connect to MYIPADDRESSHERE
>> >>> 2013-04-16 20:58:39,138 INFO [cloud.cluster.ClusterManagerImpl]
>> >>> (Cluster-Heartbeat-1:null) Management node 1 is detected inactive
>> >>>by
>> >>> timestamp but is pingable
>> >>> 2013-04-16 20:58:39,264 DEBUG
>> >>> [network.router.VirtualNetworkApplianceManagerImpl]
>> >>> (RouterStatusMonitor-1:null) Found 0 routers.
>> >>> 2013-04-16 20:58:40,637 DEBUG [cloud.cluster.ClusterManagerImpl]
>> >>> (Cluster-Heartbeat-1:null) Detected management node left, id:1,
>> >>> nodeIP:MYIPADDRESSHERE
>> >>> 2013-04-16 20:58:40,637 INFO [cloud.cluster.ClusterManagerImpl]
>> >>> (Cluster-Heartbeat-1:null) Trying to connect to MYIPADDRESSHERE
>> >>> 2013-04-16 20:58:40,637 INFO [cloud.cluster.ClusterManagerImpl]
>> >>> (Cluster-Heartbeat-1:null) Management node 1 is detected inactive
>> >>>by
>> >>> timestamp but is pingable
>> >>> 2013-0

Network Interfaces

[Maurice Lawler]

Hello:I have an odd ball question, upon rebooting the server I have noticed typically the interface eth0 would come online on system boot. However, with Cloud Stack being installed cloudbr0 is the master whereas eht0 is the slave. Cloudbr0 has the IP addresses and eth0 has nothing.My question is this, I have enabled cloudbr0 to come online on boot, but yet it does not. Is there something I can do in /etc/udev/ to set a rule to make sure this interface comes online at boot?Please advise.THANKS!- Maurice

Re: New Committer: Go Chiba

[prasanna]

Congratulations Go!

On 18 April 2013 12:26, Sebastien Goasguen  wrote:
> The Project Management Committee (PMC) for Apache CloudStack has asked Go 
> Chiba to become a committer and we are pleased to announced that they have 
> accepted.
>
> Go has contributed tremendously to the Japanese translations of the 
> documentation (runbook, UI and docs).
> 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 Go,
>
> -Sebastien, on behalf of  the Apache CloudStack PMC
>

Re: Review Request: CLOUDSTACK-741: Granular Global Parameters

[Harikrishna Patnala]

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

(Updated April 19, 2013, 4:07 a.m.)


Review request for cloudstack, Abhinandan Prateek, Kishan Kavala, and Nitin 
Mehta.


Description
---

CLOUDSTACK-741: Granular Global Parameters

Modified UpdateConfiguration API and ListConfiguration API by adding additional 
parameter scope and resource id (zone/cluster/pool/account).
Scope decides the parameter which level we can update the value and id is the 
corresponding id based on the scope.
This scope is defined in the config.java file where we are creating groups for 
each level(zone/cluster/pool/account).
Currently submitted the patch for the zone level parameter use.external.dns.

Included unit tests and marvin tests.


This addresses bug CLOUDSTACK-741.


Diffs (updated)
-

  api/src/org/apache/cloudstack/api/command/admin/config/ListCfgsByCmd.java 
aabfd4a 
  api/src/org/apache/cloudstack/api/command/admin/config/UpdateCfgCmd.java 
ffeb586 
  api/src/org/apache/cloudstack/api/response/ConfigurationResponse.java 95b8af2 
  api/test/org/apache/cloudstack/api/command/test/ListCfgCmdTest.java 
PRE-CREATION 
  api/test/org/apache/cloudstack/api/command/test/UpdateCfgCmdTest.java 
PRE-CREATION 
  
engine/api/src/org/apache/cloudstack/storage/datastore/db/StoragePoolDetailsDao.java
 be71670 
  server/src/com/cloud/configuration/Config.java 2993966 
  server/src/com/cloud/configuration/ConfigurationManager.java afaf0d6 
  server/src/com/cloud/configuration/ConfigurationManagerImpl.java 4fc2db7 
  server/src/com/cloud/configuration/dao/ConfigurationDao.java c86c024 
  server/src/com/cloud/network/router/VirtualNetworkApplianceManagerImpl.java 
ab91059 
  server/src/com/cloud/server/ConfigurationServer.java f441b1f 
  server/src/com/cloud/server/ConfigurationServerImpl.java c4da1ab 
  server/src/com/cloud/server/ManagementServerImpl.java 98f789a 
  server/src/com/cloud/storage/dao/StoragePoolDetailsDaoImpl.java 0d797ed 
  server/test/com/cloud/vpc/MockConfigurationManagerImpl.java 9443815 
  test/integration/smoke/test_UpdateCfg.py PRE-CREATION 

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


Testing
---

Tested locally
- tested the modified UpdateConfiguration API and ListConfiguration API by 
providing the zone scope and zone id
- tested the modified parameter to take the updated value at zone level(after 
updation).


Thanks,

Harikrishna Patnala

Re: no tinyLinux template

[Mike Tutkowski]

Here is what I used to deploy the DB:

mvn -pl developer,tools/devcloud -Ddeploydb -P developer

Also, cloud.vm_template has this row:

'5', 'tiny Linux', 'tiny Linux', '2a182234-a87b-11e2-84ee-e322fe93e6c9',
'1', '1', 'BUILTIN', '0', '64', '
http://people.apache.org/~bhaisaab/vms/ttylinux_pv.vhd', 'VHD', '2013-04-18
16:56:11', NULL, '1', '046e134e642e6d344b34648223ba4bc1', 'tiny Linux',
'0', '0', '12', '1', '0', '1', '1', 'XenServer', NULL, NULL, '0', NULL,
NULL, NULL, NULL, '1'



On Thu, Apr 18, 2013 at 9:39 PM, Rohit Yadav  wrote:

> On Fri, Apr 19, 2013 at 8:26 AM, Mike Tutkowski <
> mike.tutkow...@solidfire.com> wrote:
>
> > Hi,
> >
> > I've switched back to 4.2 (from 4.1), cleaned out my database, re-created
> > my DevCloud2 environment and all looks good with the exception that I do
> > not have a tinyLinux template.
> >
> > My SSVM is up and running.
> >
> > Any thoughts on what I should do here?
> >
>
> Did you forgot to deploydb with -P tools/devcloud? Looks like db does
> not know about ttylinux; check in cloud.vm_templates etc?
>
> Cheers.
>
>
> >
> > Thanks!
> >
> > --
> > *Mike Tutkowski*
> > *Senior CloudStack Developer, SolidFire Inc.*
> > e: mike.tutkow...@solidfire.com
> > o: 303.746.7302
> > Advancing the way the world uses the
> > cloud
> > *™*
> >
>



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

Re: git commit: updated refs/heads/master to 81e1ba3

[Marcus Sorensen]

Er, I guess you're asking about the mkdir specifically. I have no idea why
we'd be doing that in the first place, I'd also be interested in knowing
that.
On Apr 18, 2013 9:51 PM, "Marcus Sorensen"  wrote:

> Those udev rules are often a pain when using VM templates. Their purpose
> is to tie a specific MAC address to an eth# dev, so for example if you
> configure an IP address for eth0 and then change the mac address (via VM
> clone or some such), you suddenly have no IP at all, no eth0, and an eth1
> tied to the new MAC.
>
> The rule in /etc has the MAC to eth# mappings, and the one in /lib creates
> the one in /etc.
> On Apr 18, 2013 9:41 PM, "Chip Childers" 
> wrote:
>
>>
>> Hey Rohit,
>>
>> Can you explain the change below?  I'm mostly curious.
>>
>> On Fri, Apr 19, 2013 at 03:36:36AM +, bhais...@apache.org wrote:
>> > Updated Branches:
>> >   refs/heads/master ca6873a9d -> 81e1ba3bb
>> >
>> >
>> > appliance: Don't mkdir 70-persistent-net.rules for systemvms
>> >
>> > Signed-off-by: Rohit Yadav 
>> >
>> >
>> > Project: http://git-wip-us.apache.org/repos/asf/cloudstack/repo
>> > Commit:
>> http://git-wip-us.apache.org/repos/asf/cloudstack/commit/81e1ba3b
>> > Tree: http://git-wip-us.apache.org/repos/asf/cloudstack/tree/81e1ba3b
>> > Diff: http://git-wip-us.apache.org/repos/asf/cloudstack/diff/81e1ba3b
>> >
>> > Branch: refs/heads/master
>> > Commit: 81e1ba3bb406f9546f0d46ccbfa3fbbb35b762e2
>> > Parents: ca6873a
>> > Author: Rohit Yadav 
>> > Authored: Fri Apr 19 09:05:42 2013 +0530
>> > Committer: Rohit Yadav 
>> > Committed: Fri Apr 19 09:05:42 2013 +0530
>> >
>> > --
>> >  .../definitions/systemvmtemplate/cleanup.sh|1 -
>> >  .../definitions/systemvmtemplate64/cleanup.sh  |1 -
>> >  2 files changed, 0 insertions(+), 2 deletions(-)
>> > --
>> >
>> >
>> >
>> http://git-wip-us.apache.org/repos/asf/cloudstack/blob/81e1ba3b/tools/appliance/definitions/systemvmtemplate/cleanup.sh
>> > --
>> > diff --git a/tools/appliance/definitions/systemvmtemplate/cleanup.sh
>> b/tools/appliance/definitions/systemvmtemplate/cleanup.sh
>> > index 9e98ab0..701d8d8 100644
>> > --- a/tools/appliance/definitions/systemvmtemplate/cleanup.sh
>> > +++ b/tools/appliance/definitions/systemvmtemplate/cleanup.sh
>> > @@ -12,7 +12,6 @@ rm /var/lib/dhcp/*
>> >  # Make sure Udev doesn't block our network
>> >  echo "cleaning up udev rules"
>> >  rm /etc/udev/rules.d/70-persistent-net.rules
>> > -mkdir /etc/udev/rules.d/70-persistent-net.rules
>> >  rm -rf /dev/.udev/
>> >  rm /lib/udev/rules.d/75-persistent-net-generator.rules
>> >
>> >
>> >
>> http://git-wip-us.apache.org/repos/asf/cloudstack/blob/81e1ba3b/tools/appliance/definitions/systemvmtemplate64/cleanup.sh
>> > --
>> > diff --git a/tools/appliance/definitions/systemvmtemplate64/cleanup.sh
>> b/tools/appliance/definitions/systemvmtemplate64/cleanup.sh
>> > index 9e98ab0..701d8d8 100644
>> > --- a/tools/appliance/definitions/systemvmtemplate64/cleanup.sh
>> > +++ b/tools/appliance/definitions/systemvmtemplate64/cleanup.sh
>> > @@ -12,7 +12,6 @@ rm /var/lib/dhcp/*
>> >  # Make sure Udev doesn't block our network
>> >  echo "cleaning up udev rules"
>> >  rm /etc/udev/rules.d/70-persistent-net.rules
>> > -mkdir /etc/udev/rules.d/70-persistent-net.rules
>> >  rm -rf /dev/.udev/
>> >  rm /lib/udev/rules.d/75-persistent-net-generator.rules
>> >
>> >
>> >
>>
>

Re: git commit: updated refs/heads/master to 81e1ba3

[Marcus Sorensen]

Those udev rules are often a pain when using VM templates. Their purpose is
to tie a specific MAC address to an eth# dev, so for example if you
configure an IP address for eth0 and then change the mac address (via VM
clone or some such), you suddenly have no IP at all, no eth0, and an eth1
tied to the new MAC.

The rule in /etc has the MAC to eth# mappings, and the one in /lib creates
the one in /etc.
On Apr 18, 2013 9:41 PM, "Chip Childers"  wrote:

>
> Hey Rohit,
>
> Can you explain the change below?  I'm mostly curious.
>
> On Fri, Apr 19, 2013 at 03:36:36AM +, bhais...@apache.org wrote:
> > Updated Branches:
> >   refs/heads/master ca6873a9d -> 81e1ba3bb
> >
> >
> > appliance: Don't mkdir 70-persistent-net.rules for systemvms
> >
> > Signed-off-by: Rohit Yadav 
> >
> >
> > Project: http://git-wip-us.apache.org/repos/asf/cloudstack/repo
> > Commit:
> http://git-wip-us.apache.org/repos/asf/cloudstack/commit/81e1ba3b
> > Tree: http://git-wip-us.apache.org/repos/asf/cloudstack/tree/81e1ba3b
> > Diff: http://git-wip-us.apache.org/repos/asf/cloudstack/diff/81e1ba3b
> >
> > Branch: refs/heads/master
> > Commit: 81e1ba3bb406f9546f0d46ccbfa3fbbb35b762e2
> > Parents: ca6873a
> > Author: Rohit Yadav 
> > Authored: Fri Apr 19 09:05:42 2013 +0530
> > Committer: Rohit Yadav 
> > Committed: Fri Apr 19 09:05:42 2013 +0530
> >
> > --
> >  .../definitions/systemvmtemplate/cleanup.sh|1 -
> >  .../definitions/systemvmtemplate64/cleanup.sh  |1 -
> >  2 files changed, 0 insertions(+), 2 deletions(-)
> > --
> >
> >
> >
> http://git-wip-us.apache.org/repos/asf/cloudstack/blob/81e1ba3b/tools/appliance/definitions/systemvmtemplate/cleanup.sh
> > --
> > diff --git a/tools/appliance/definitions/systemvmtemplate/cleanup.sh
> b/tools/appliance/definitions/systemvmtemplate/cleanup.sh
> > index 9e98ab0..701d8d8 100644
> > --- a/tools/appliance/definitions/systemvmtemplate/cleanup.sh
> > +++ b/tools/appliance/definitions/systemvmtemplate/cleanup.sh
> > @@ -12,7 +12,6 @@ rm /var/lib/dhcp/*
> >  # Make sure Udev doesn't block our network
> >  echo "cleaning up udev rules"
> >  rm /etc/udev/rules.d/70-persistent-net.rules
> > -mkdir /etc/udev/rules.d/70-persistent-net.rules
> >  rm -rf /dev/.udev/
> >  rm /lib/udev/rules.d/75-persistent-net-generator.rules
> >
> >
> >
> http://git-wip-us.apache.org/repos/asf/cloudstack/blob/81e1ba3b/tools/appliance/definitions/systemvmtemplate64/cleanup.sh
> > --
> > diff --git a/tools/appliance/definitions/systemvmtemplate64/cleanup.sh
> b/tools/appliance/definitions/systemvmtemplate64/cleanup.sh
> > index 9e98ab0..701d8d8 100644
> > --- a/tools/appliance/definitions/systemvmtemplate64/cleanup.sh
> > +++ b/tools/appliance/definitions/systemvmtemplate64/cleanup.sh
> > @@ -12,7 +12,6 @@ rm /var/lib/dhcp/*
> >  # Make sure Udev doesn't block our network
> >  echo "cleaning up udev rules"
> >  rm /etc/udev/rules.d/70-persistent-net.rules
> > -mkdir /etc/udev/rules.d/70-persistent-net.rules
> >  rm -rf /dev/.udev/
> >  rm /lib/udev/rules.d/75-persistent-net-generator.rules
> >
> >
> >
>

Re: New Committer: Go Chiba

[Joe Brockmeier]

On 04/18/2013 01:56 AM, Sebastien Goasguen wrote:

The Project Management Committee (PMC) for Apache CloudStack has asked Go Chiba 
to become a committer and we are pleased to announced that they have accepted.

Go has contributed tremendously to the Japanese translations of the 
documentation (runbook, UI and docs).
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 Go,


Congratulations, Go!

Re: CLOUDSTACK-1876

[Chip Childers]

On Fri, Apr 19, 2013 at 09:08:51AM +0530, Rohit Yadav wrote:
> On Fri, Apr 19, 2013 at 7:34 AM, Abhinandan Prateek  > wrote:
> 
> >
> >
> > On 18/04/13 10:02 PM, "Rohit Yadav"  wrote:
> >
> > >On Thu, Apr 18, 2013 at 7:47 PM, Abhinandan Prateek
> > > > >> wrote:
> > >
> > >>
> > >> While debugging the VMWare system template fixed the cd rom device name
> > >> that was causing the systemvm.iso not to load.
> > >> After this the SSVM and CPVM are coming up fine.
> > >>
> > >> On router VM creation though it failed as this file
> > >> /etc/udev/rules.d/70-persistent-net.rules  was present in the template
> > >>as
> > >> a directory !
> > >> This file is recreated on reboot so I have created another template
> > >>after
> > >> removing this directory.
> > >>
> > >>
> > >Oh man! Yes Abhi we don't need this file. I remember removing this file
> > >which is done in cleanup.sh:
> > >
> > https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=blob;f=tools/ap
> > >pliance/definitions/systemvmtemplate/cleanup.sh;h=9e98ab03531f0c8fee6c0402
> > >31e5d0f4871ae777;hb=f4240e1cea58be0ea7b50c77a018d7c63e3faf15
> > >
> > >Maybe I missed it while manually installing vmware-tools via vmware
> > >fusion.
> > >The open-vm-tools based appliance won't have this issue:
> > >
> > http://people.apache.org/~bhaisaab/cloudstack/systemvmtemplates/systemvmte
> > >mplate-openvmtools-vmware.ova
> >
> > Yes, the template in general works fine. But due to presence of that
> > directory the cloud-early-config that checks for sanity of that file
> > continues to reboot. Do make that change in the script and generate a new
> > set.
> >
> 
> Cool! Fixed on master: 81e1ba3bb406f9546f0d46ccbfa3fbbb35b762e2
> Fired up a new systemvm build:
> http://jenkins.cloudstack.org/job/build-systemvm-master/143/

Ignore my question about the commit in the last email I sent.  I
obviously see the context now!

Re: git commit: updated refs/heads/master to 81e1ba3

[Chip Childers]

Hey Rohit,

Can you explain the change below?  I'm mostly curious.

On Fri, Apr 19, 2013 at 03:36:36AM +, bhais...@apache.org wrote:
> Updated Branches:
>   refs/heads/master ca6873a9d -> 81e1ba3bb
> 
> 
> appliance: Don't mkdir 70-persistent-net.rules for systemvms
> 
> Signed-off-by: Rohit Yadav 
> 
> 
> Project: http://git-wip-us.apache.org/repos/asf/cloudstack/repo
> Commit: http://git-wip-us.apache.org/repos/asf/cloudstack/commit/81e1ba3b
> Tree: http://git-wip-us.apache.org/repos/asf/cloudstack/tree/81e1ba3b
> Diff: http://git-wip-us.apache.org/repos/asf/cloudstack/diff/81e1ba3b
> 
> Branch: refs/heads/master
> Commit: 81e1ba3bb406f9546f0d46ccbfa3fbbb35b762e2
> Parents: ca6873a
> Author: Rohit Yadav 
> Authored: Fri Apr 19 09:05:42 2013 +0530
> Committer: Rohit Yadav 
> Committed: Fri Apr 19 09:05:42 2013 +0530
> 
> --
>  .../definitions/systemvmtemplate/cleanup.sh|1 -
>  .../definitions/systemvmtemplate64/cleanup.sh  |1 -
>  2 files changed, 0 insertions(+), 2 deletions(-)
> --
> 
> 
> http://git-wip-us.apache.org/repos/asf/cloudstack/blob/81e1ba3b/tools/appliance/definitions/systemvmtemplate/cleanup.sh
> --
> diff --git a/tools/appliance/definitions/systemvmtemplate/cleanup.sh 
> b/tools/appliance/definitions/systemvmtemplate/cleanup.sh
> index 9e98ab0..701d8d8 100644
> --- a/tools/appliance/definitions/systemvmtemplate/cleanup.sh
> +++ b/tools/appliance/definitions/systemvmtemplate/cleanup.sh
> @@ -12,7 +12,6 @@ rm /var/lib/dhcp/*
>  # Make sure Udev doesn't block our network
>  echo "cleaning up udev rules"
>  rm /etc/udev/rules.d/70-persistent-net.rules
> -mkdir /etc/udev/rules.d/70-persistent-net.rules
>  rm -rf /dev/.udev/
>  rm /lib/udev/rules.d/75-persistent-net-generator.rules
>  
> 
> http://git-wip-us.apache.org/repos/asf/cloudstack/blob/81e1ba3b/tools/appliance/definitions/systemvmtemplate64/cleanup.sh
> --
> diff --git a/tools/appliance/definitions/systemvmtemplate64/cleanup.sh 
> b/tools/appliance/definitions/systemvmtemplate64/cleanup.sh
> index 9e98ab0..701d8d8 100644
> --- a/tools/appliance/definitions/systemvmtemplate64/cleanup.sh
> +++ b/tools/appliance/definitions/systemvmtemplate64/cleanup.sh
> @@ -12,7 +12,6 @@ rm /var/lib/dhcp/*
>  # Make sure Udev doesn't block our network
>  echo "cleaning up udev rules"
>  rm /etc/udev/rules.d/70-persistent-net.rules
> -mkdir /etc/udev/rules.d/70-persistent-net.rules
>  rm -rf /dev/.udev/
>  rm /lib/udev/rules.d/75-persistent-net-generator.rules
>  
> 
> 

Re: no tinyLinux template

[Rohit Yadav]

On Fri, Apr 19, 2013 at 8:26 AM, Mike Tutkowski <
mike.tutkow...@solidfire.com> wrote:

> Hi,
>
> I've switched back to 4.2 (from 4.1), cleaned out my database, re-created
> my DevCloud2 environment and all looks good with the exception that I do
> not have a tinyLinux template.
>
> My SSVM is up and running.
>
> Any thoughts on what I should do here?
>

Did you forgot to deploydb with -P tools/devcloud? Looks like db does
not know about ttylinux; check in cloud.vm_templates etc?

Cheers.


>
> 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: CLOUDSTACK-1876

[Rohit Yadav]

On Fri, Apr 19, 2013 at 7:34 AM, Abhinandan Prateek  wrote:

>
>
> On 18/04/13 10:02 PM, "Rohit Yadav"  wrote:
>
> >On Thu, Apr 18, 2013 at 7:47 PM, Abhinandan Prateek
> > >> wrote:
> >
> >>
> >> While debugging the VMWare system template fixed the cd rom device name
> >> that was causing the systemvm.iso not to load.
> >> After this the SSVM and CPVM are coming up fine.
> >>
> >> On router VM creation though it failed as this file
> >> /etc/udev/rules.d/70-persistent-net.rules  was present in the template
> >>as
> >> a directory !
> >> This file is recreated on reboot so I have created another template
> >>after
> >> removing this directory.
> >>
> >>
> >Oh man! Yes Abhi we don't need this file. I remember removing this file
> >which is done in cleanup.sh:
> >
> https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=blob;f=tools/ap
> >pliance/definitions/systemvmtemplate/cleanup.sh;h=9e98ab03531f0c8fee6c0402
> >31e5d0f4871ae777;hb=f4240e1cea58be0ea7b50c77a018d7c63e3faf15
> >
> >Maybe I missed it while manually installing vmware-tools via vmware
> >fusion.
> >The open-vm-tools based appliance won't have this issue:
> >
> http://people.apache.org/~bhaisaab/cloudstack/systemvmtemplates/systemvmte
> >mplate-openvmtools-vmware.ova
>
> Yes, the template in general works fine. But due to presence of that
> directory the cloud-early-config that checks for sanity of that file
> continues to reboot. Do make that change in the script and generate a new
> set.
>

Cool! Fixed on master: 81e1ba3bb406f9546f0d46ccbfa3fbbb35b762e2
Fired up a new systemvm build:
http://jenkins.cloudstack.org/job/build-systemvm-master/143/



>
> >
> >
> >> Please, confirm if that is right. I will publish the template soon as it
> >> is still uploading.
> >>
> >
> >Cool, Abhi did you reuse the appliance I had shared or created your own?
> >Share any special steps that were needed to be done.
>
> I started with the one generated by jenkins that you setup. There were
> some issues to make it work with cloudstack.
> Once we have a fully functional appliance I will list down the additional
> steps. Some of them can be then fixed in the scripts.
>


Sure, thanks.

Cheers.


> >
> >Cheers.
> >
> >
> >>
> >> -abhi
> >>
> >>
>
>
>

Re: [ASFCS42] Proposed schedule for our next release

[Chip Childers]

On Thu, Apr 18, 2013 at 11:29:46PM -0400, David Nalley wrote:
> > I disagree. You might take a hit in the short term as people get
> > acclimated, but I've accelerated multiple projects' output by being
> > exceptionally focused on automated quality checks (unit, integration,
> > regression, etc...). Feature dev is faster if your base is stable.
> > Release QA is easier with higher quality prior to a merge. Refactoring
> > is easier. Teams can be larger and more distributed. Etc...
> >
> 
> I agree with you, sorry if it came across differently.

I get what you were saying...  I was disagreeing with the general
thought that it would "slow us down".

> In the short term however we don't have that highly automated base
> today, so we can continue on our rapid feature pace with few people
> focused on automated testing (esp holistically) but that isn't
> sustainable. We do have to take the short term hit IMO and pay the
> piper and get rid of our technical debt (though I am not talking about
> our bug backlog.)

That's correct.  You always have to take that hit to reap the reward of
speed and scale later on.

Re: Review Request: Re-enable baremetal components

[David Nalley]

On Thu, Apr 18, 2013 at 11:22 PM, Parth Jagirdar
 wrote:
> I think original consensus was to disable Baremetal for 4.1 only.
>
> ŠParth

If my earlier message wasn't clear enough, please consider this my
veto on baremetal being enabled without tests coming in around it.

--David

Re: [ASFCS42] Proposed schedule for our next release

[David Nalley]

On Thu, Apr 18, 2013 at 10:51 PM, Chip Childers
 wrote:
> On Apr 18, 2013, at 10:29 PM, David Nalley  wrote:
>
>> On Thu, Apr 18, 2013 at 10:26 PM, Chiradeep Vittal
>>  wrote:
>>>
>>>
>>> On 4/18/13 6:41 PM, "David Nalley"  wrote:
>>>
 On Thu, Apr 18, 2013 at 6:26 PM, Will Chan  wrote:
>
>> -Original Message-
>> From: Chip Childers [mailto:chip.child...@sungard.com]
>> Sent: Monday, April 15, 2013 7:22 AM
>> To: dev@cloudstack.apache.org
>> Cc: cloudstack-...@incubator.apache.org
>> Subject: Re: [ASFCS42] Proposed schedule for our next release
>>
>> On Thu, Apr 11, 2013 at 02:50:02PM -0700, Animesh Chaturvedi wrote:
>>>
>>> I want to call out my concern on technical debt we have accumulated
> so
>> far.
>>>
>>> I did an analysis on JIRA bugs yesterday night PST on "Affects
>>> Version = 4.1" and created since Dec 2012
>>>
>>> Total records : 429
>>> Resolution Type (Invalid, Duplicate, Cannot reproduce etc.) : 87 (30
>>> Blockers, 27 Critical, 27 Major, 4 Minor) Valid Defects  : 429-87=
> 342
>>> Fixed : 246 (60 Blockers, 70 Critical, 99 Majors) out of which 217
>>> were fixed since Feb Unresolved : 96 (1 Blocker, 8 Critical, 64
> Major)
>>>
>>> With this data it looks like we have fixed 2/3 of valid defects in
> little over
>> 2 months and pretty much deferring around 1/3 rd of issues for future
>> release.
>>>
>>> I also looked at overall backlog of bugs (Critical, Major and
> Blockers only)
>> as of 4/10/2013 - 10:0PM PST.
>>>
>>> 284 open (18 Blocker, 38 Critical, 228 Major) ; By Fix version
>>>-  Release 4.0.x and prior: 13
>>>-  4.1: 70
>>>-  4.2 : 97
>>>-  Future: 8
>>>-  No version: 107
>>>
>>> Looking at that we fixed 217 bugs in roughly 2 months during 4.1
> cycle,
>> fixing the backlog of bug  will probably take us 2 months.  Should we
> extend
>> the 4.2 test cycle by 2 months [Original Schedule: 6/1 - 7/22,
> Extended
>> Schedule: 6/1-9/22] to reduce the technical debt significantly? I
> would like
>> to hear how community wants to address technical debt. Based on the
>> input and consensus I will publish the agreed schedule next week.
>>
>> I don't think that an extension of time changes bug counts really.
> IMO, we
>> need to pull together to have some bug-fix focused effort applied to
> the
>> code-base.  It's also another reason that I'm so big on making sure
> that
>> automated tests come in with the new features.  That doesn't address
> test
>> scenarios that human testers can come up with, but if a developer
> spends
>> the time to think about testing the basic feature and codifies that,
> we
>> should at least avoid the "this actually doesn't work at all" types
> of bugs.
>>
>> There's a school of thought that says, don't build another feature
> until you
>> have sorted out the known bugs in the current features.  I don't
> think we
>> could really pull that off, but perhaps a different thread to rally
> people
>> around the bug backlog is in order?
>>
>> -chip
>
> Sorry to chime in so late to this thread as I've been offsite for the
> better part of this week.  I was one of the original 4 month release
> crowd but after the recent two releases of ACS, I'm starting to wonder
> if we shouldn't start moving this to a 6 month cycle instead of two.
> Here are some high level observations based on the previous two releases:
>
> 1. It doesn't seem like we are on a true 4 month time based release
> schedule.  Both 4.0 and 4.1 were delayed more than several weeks past the
> original proposed GA date.  4.0 was released 11/6 and let's assume that
> 4.1 will ship within a week or two.  That's almost a 6 month release
> cycle.

 So both 4.0 and 4.1 strike me as extraordinary. 4.0 was our first
 release - and we had lots of issues to resolve. 4.1 introduced a ton
 of packaging and name changes that I also consider to be hopefully one
 time. Really - we've only been through our release cycle once, so I am
 not ready to declare it perpetually behind schedule.


> Every release incurs a fixed cost of release notes, upgrade testing,
> etc. that I suspect at least eats a month worth of time depending on
> people's
> schedule.  That's 3 months out of the year rather than two if we can
> get a 6 months cycle.  We can use that extra month for other purposes if
> need
> be.  I suppose if we want to continue to release past the proposed hard
> GA date, then I guess it doesn't matter if it's 4 or 6 months.  It's
> basically a
> release when the release mgmt. team feels it's right to release based
> on current bugs, etc.

 Having seen the point releas

Re: Review Request: Re-enable baremetal components

[Chip Childers]

On Fri, Apr 19, 2013 at 03:22:51AM +, Parth Jagirdar wrote:
> I think original consensus was to disable Baremetal for 4.1 only.

Correct, due to the quality issues with the feature and some (probably
well deserved) vacation time requiring that we disable it.  

Now's a good time to ask about automated tests though.  Wouldn't they help 
ensure (1) the quality of the feature before re-enabling it and (2) that we 
have a way to regression test it easily?

-chip

Re: Review Request: Re-enable baremetal components

[Parth Jagirdar]

I think original consensus was to disable Baremetal for 4.1 only.

ŠParth

On 4/18/13 6:56 PM, "David Nalley"  wrote:

>
>---
>This is an automatically generated e-mail. To reply, visit:
>https://reviews.apache.org/r/10616/#review19428
>---
>
>
>Baremetal seems to be suffering from a significant lack of unit tests and
>integration tests for marvin to consume. Let's get those in place before
>we consider re-enabling this.
>
>- David Nalley
>
>
>On April 19, 2013, 1:33 a.m., Venkata Siva Vijayendra Bhamidipati wrote:
>> 
>> ---
>> This is an automatically generated e-mail. To reply, visit:
>> https://reviews.apache.org/r/10616/
>> ---
>> 
>> (Updated April 19, 2013, 1:33 a.m.)
>> 
>> 
>> Review request for cloudstack, Chip Childers, Kelven Yang, and Frank
>>Zhang.
>> 
>> 
>> Description
>> ---
>> 
>> Baremetal provisioning components were commented out on master -
>>uncommenting them again to allow creation of baremetal clusters.
>> 
>> 
>> This addresses bug CLOUDSTACK-2101.
>> 
>> 
>> Diffs
>> -
>> 
>>   client/tomcatconf/applicationContext.xml.in 7487a5e
>>   client/tomcatconf/componentContext.xml.in 7a46981
>>   client/tomcatconf/nonossComponentContext.xml.in 2359ba8
>> 
>> Diff: https://reviews.apache.org/r/10616/diff/
>> 
>> 
>> Testing
>> ---
>> 
>> Creation of a cluster of hypervisor type baremetal succeeds with these
>>changes in.
>> 
>> 
>> Thanks,
>> 
>> Venkata Siva Vijayendra Bhamidipati
>> 
>>
>

Re: [VOTE][ACS402] Apache CloudStack 4.0.2 (Second Round)

[Chip Childers]

+1 (binding)

I tested based on the procedure outlined in the test document (after
editing it a bit).  I did not test the EC2 functionality, but I did
explore outside of the standard functional path.

RE: no tinyLinux template

[Rajesh Battala]

Can you login to ssvm and check cloud process is running and able to connect to 
mgmt server? . from Global Settings check the host ip. It should be starting 
with 192.* instead of 10.* 
if it is 10.* then ssvm won't be able to connect to mgmt server with that ip, 
and same will be reported in the ssvm log.  Change the ip in the global 
settings and recreated the ssvm then you would be able to see the tiny linx 
template. 

Thanks
Rajesh Battala
> -Original Message-
> From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com]
> Sent: Friday, April 19, 2013 8:27 AM
> To: cloudstack-...@incubator.apache.org
> Subject: no tinyLinux template
> 
> Hi,
> 
> I've switched back to 4.2 (from 4.1), cleaned out my database, re-created my
> DevCloud2 environment and all looks good with the exception that I do not
> have a tinyLinux template.
> 
> My SSVM is up and running.
> 
> Any thoughts on what I should do here?
> 
> Thanks!
> 
> --
> *Mike Tutkowski*
> *Senior CloudStack Developer, SolidFire Inc.*
> e: mike.tutkow...@solidfire.com
> o: 303.746.7302
> Advancing the way the world uses the
> cloud
> *(tm)*

Re: CS 4.0.1 | KVM | CentOS 6.3

[Maurice Lawler]

I'm 100% sure it's user error! As always *grin*  Of course I removed my IP address / hostname.- MauriceThe output is: mysql> SELECT * FROM mshost\G;*** 1. row ***  id: 1    msid: 219948120943996   runid: 1366256187370    name:  myhostname.domain.com   state: Down version: 4.0.1.20130201075054  service_ip: myipaddressservice_port: 9090 last_update: 2013-04-19 01:49:19 removed: NULL alert_count: 0*** 2. row ***  id: 2    msid: 279278805451357   runid: 1366250623758    name:  myhostname.domain.com   state: Down version: 4.0.1.20130201075054  service_ip: myipaddressservice_port: 9090 last_update: 2013-04-18 03:32:29 removed: NULL alert_count: 0*** 3. row ***  id: 3    msid: 279278805450862   runid: 1366337908232    name: myhostname.domain.com   state: Up version: 4.0.1.20130201075054  service_ip: myipaddressservice_port: 9090 last_update: 2013-04-19 02:57:12 removed: NULL alert_count: 03 rows in set (0.00 sec)On Apr 18, 2013, at 02:11 PM, Chiradeep Vittal  wrote:Maurice, it appears to be something specific to the sequence of actions you took or your environment.  Developers and QA kill and restart their management servers dozens of times a day and have (AFAIK) never seen this issue.  What are the entries in the mshost table?   On 4/17/13 11:20 PM, "Maurice Lawler"  wrote:  >Thank you. How would I correct this and why would the table state >something other then what I have setup, what would have caused that? > > >On Apr 18, 2013, at 12:27 AM, Chiradeep Vittal > wrote: > >> That's probably not what the mshost table thinks? >>  >> On 4/17/13 11:00 AM, "Maurice Lawler"  wrote: >>  >>> No. I have ONE server running. >>>  >>> One MS - One Install of CS - One of everything. All on the same IP >>> address.  >>>  >>>  >>> On Apr 17, 2013, at 12:05 PM, Chiradeep Vittal >>>  wrote: >>>   You probably have another MS connecting to the same database?    On 4/17/13 9:49 AM, "Maurice Lawler"  wrote:   > No the management IP hasn't changed. My question is why when >restarting > Cloud Management the issue is cleared up. Then almost an hour later, >it > starts in again; how do I correct this issue? >  >  > On Apr 17, 2013, at 12:23 AM, Chiradeep Vittal >  wrote: >  >> Did the management server ip change? It somehow thinks there's 2 >> management servers. >>  >> On 4/16/13 7:00 PM, "Maurice Lawler"  wrote: >>  >>> Greetings, >>>  >>> I am having this FLOOD my log. I will have you know, this is ONE >>> server >>> ONE HOST. KVM | CentOS 6.3 | Cloudstack 4.0.1 >>>  >>> I have found restarting cloud management solves the issue for >>>awhile, >>> then it starts again. >>>  >>> Please advise. >>>  >>> - Maurice >>>  >>>  Eror Log  >>>  >>> 2013-04-16 20:58:38,993 DEBUG >>> [cloud.consoleproxy.ConsoleProxyManagerImpl] (consoleproxy-1:null) >>> Zone 1 >>> is ready to launch console proxy >>> 2013-04-16 20:58:39,137 DEBUG [cloud.cluster.ClusterManagerImpl] >>> (Cluster-Heartbeat-1:null) Detected management node left, id:1, >>> nodeIP:MYIPADDRESSHERE >>> 2013-04-16 20:58:39,137 INFO [cloud.cluster.ClusterManagerImpl] >>> (Cluster-Heartbeat-1:null) Trying to connect to MYIPADDRESSHERE >>> 2013-04-16 20:58:39,138 INFO [cloud.cluster.ClusterManagerImpl] >>> (Cluster-Heartbeat-1:null) Management node 1 is detected inactive >>>by >>> timestamp but is pingable >>> 2013-04-16 20:58:39,264 DEBUG >>> [network.router.VirtualNetworkApplianceManagerImpl] >>> (RouterStatusMonitor-1:null) Found 0 routers. >>> 2013-04-16 20:58:40,637 DEBUG [cloud.cluster.ClusterManagerImpl] >>> (Cluster-Heartbeat-1:null) Detected management node left, id:1, >>> nodeIP:MYIPADDRESSHERE >>> 2013-04-16 20:58:40,637 INFO [cloud.cluster.ClusterManagerImpl] >>> (Cluster-Heartbeat-1:null) Trying to connect to MYIPADDRESSHERE >>> 2013-04-16 20:58:40,637 INFO [cloud.cluster.ClusterManagerImpl] >>> (Cluster-Heartbeat-1:null) Management node 1 is detected inactive >>>by >>> timestamp but is pingable >>> 2013-04-16 20:58:42,062 DEBUG [agent.manager.AgentManagerImpl] >>> (AgentManager-Handler-13:null) Ping from 3 >>> 2013-04-16 20:58:42,063 DEBUG [agent.manager.AgentManagerImpl] >>> (AgentManager-Handler-14:null) Ping from 4 >>> 2013-04-16 20:58:42,138 DEBUG [cloud.cluster.ClusterManagerImpl] >>> (Cluster-Heartbeat-1:null) Detected management node left, id:1, >>> nodeIP:MYIPADDRESSHERE >>> 2013-04-

no tinyLinux template

[Mike Tutkowski]

Hi,

I've switched back to 4.2 (from 4.1), cleaned out my database, re-created
my DevCloud2 environment and all looks good with the exception that I do
not have a tinyLinux template.

My SSVM is up and running.

Any thoughts on what I should do here?

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: [ASFCS42] Proposed schedule for our next release

[Chip Childers]

On Apr 18, 2013, at 10:29 PM, David Nalley  wrote:

> On Thu, Apr 18, 2013 at 10:26 PM, Chiradeep Vittal
>  wrote:
>>
>>
>> On 4/18/13 6:41 PM, "David Nalley"  wrote:
>>
>>> On Thu, Apr 18, 2013 at 6:26 PM, Will Chan  wrote:

> -Original Message-
> From: Chip Childers [mailto:chip.child...@sungard.com]
> Sent: Monday, April 15, 2013 7:22 AM
> To: dev@cloudstack.apache.org
> Cc: cloudstack-...@incubator.apache.org
> Subject: Re: [ASFCS42] Proposed schedule for our next release
>
> On Thu, Apr 11, 2013 at 02:50:02PM -0700, Animesh Chaturvedi wrote:
>>
>> I want to call out my concern on technical debt we have accumulated
 so
> far.
>>
>> I did an analysis on JIRA bugs yesterday night PST on "Affects
>> Version = 4.1" and created since Dec 2012
>>
>> Total records : 429
>> Resolution Type (Invalid, Duplicate, Cannot reproduce etc.) : 87 (30
>> Blockers, 27 Critical, 27 Major, 4 Minor) Valid Defects  : 429-87=
 342
>> Fixed : 246 (60 Blockers, 70 Critical, 99 Majors) out of which 217
>> were fixed since Feb Unresolved : 96 (1 Blocker, 8 Critical, 64
 Major)
>>
>> With this data it looks like we have fixed 2/3 of valid defects in
 little over
> 2 months and pretty much deferring around 1/3 rd of issues for future
> release.
>>
>> I also looked at overall backlog of bugs (Critical, Major and
 Blockers only)
> as of 4/10/2013 - 10:0PM PST.
>>
>> 284 open (18 Blocker, 38 Critical, 228 Major) ; By Fix version
>>-  Release 4.0.x and prior: 13
>>-  4.1: 70
>>-  4.2 : 97
>>-  Future: 8
>>-  No version: 107
>>
>> Looking at that we fixed 217 bugs in roughly 2 months during 4.1
 cycle,
> fixing the backlog of bug  will probably take us 2 months.  Should we
 extend
> the 4.2 test cycle by 2 months [Original Schedule: 6/1 - 7/22,
 Extended
> Schedule: 6/1-9/22] to reduce the technical debt significantly? I
 would like
> to hear how community wants to address technical debt. Based on the
> input and consensus I will publish the agreed schedule next week.
>
> I don't think that an extension of time changes bug counts really.
 IMO, we
> need to pull together to have some bug-fix focused effort applied to
 the
> code-base.  It's also another reason that I'm so big on making sure
 that
> automated tests come in with the new features.  That doesn't address
 test
> scenarios that human testers can come up with, but if a developer
 spends
> the time to think about testing the basic feature and codifies that,
 we
> should at least avoid the "this actually doesn't work at all" types
 of bugs.
>
> There's a school of thought that says, don't build another feature
 until you
> have sorted out the known bugs in the current features.  I don't
 think we
> could really pull that off, but perhaps a different thread to rally
 people
> around the bug backlog is in order?
>
> -chip

 Sorry to chime in so late to this thread as I've been offsite for the
 better part of this week.  I was one of the original 4 month release
 crowd but after the recent two releases of ACS, I'm starting to wonder
 if we shouldn't start moving this to a 6 month cycle instead of two.
 Here are some high level observations based on the previous two releases:

 1. It doesn't seem like we are on a true 4 month time based release
 schedule.  Both 4.0 and 4.1 were delayed more than several weeks past the
 original proposed GA date.  4.0 was released 11/6 and let's assume that
 4.1 will ship within a week or two.  That's almost a 6 month release
 cycle.
>>>
>>> So both 4.0 and 4.1 strike me as extraordinary. 4.0 was our first
>>> release - and we had lots of issues to resolve. 4.1 introduced a ton
>>> of packaging and name changes that I also consider to be hopefully one
>>> time. Really - we've only been through our release cycle once, so I am
>>> not ready to declare it perpetually behind schedule.
>>>
>>>
 Every release incurs a fixed cost of release notes, upgrade testing,
 etc. that I suspect at least eats a month worth of time depending on
 people's
 schedule.  That's 3 months out of the year rather than two if we can
 get a 6 months cycle.  We can use that extra month for other purposes if
 need
 be.  I suppose if we want to continue to release past the proposed hard
 GA date, then I guess it doesn't matter if it's 4 or 6 months.  It's
 basically a
 release when the release mgmt. team feels it's right to release based
 on current bugs, etc.
>>>
>>> Having seen the point releases twice now, which still need upgrade
>>> testing, release notes, etc I don't get the feeling that the
>>> 'overhread' referred to above is the problem. Joe may disagree with

Re: [ASFCS42] Proposed schedule for our next release

[Joe Brockmeier]

On Thu, Apr 18, 2013, at 08:41 PM, David Nalley wrote:
> Having seen the point releases twice now, which still need upgrade
> testing, release notes, etc I don't get the feeling that the
> 'overhread' referred to above is the problem. Joe may disagree with
> me.

I do, to a degree.

- Point releases require *far* less revision for release notes, etc.,
and should require only fixes to documentation - not wholesale creation
of new docs for new features, etc. 

- Time spent on release notes, etc. is time *not* spent doing more than
the bare minimum for documentation. 

- The time and effort for *promoting* a major release is a fixed cost,
and may have diminishing returns. (e.g. two releases a year are spaced
out far enough to be newsworthy, three *may* invite press fatigue.) 

I tend to lean more towards a six-month schedule, but I understand the
reasons for wanting to release more frequently. 

David does make a good point as well - 4.0.0 was a first effort and
isn't really usable as a baseline for what a release cycle should look
like. 4.1.0 involved huge amounts of churn in the toolchain, etc. and we
also had a slight disruption at the tail-end of the cycle with
graduation. 

My suggestion for now would be that we get 4.1.0 out the door and do a
post-mortem immediately after the release to look how we might keep to
an aggressive release cycle. 

Best,

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

Re: [ASFCS42] Proposed schedule for our next release

[David Nalley]

On Thu, Apr 18, 2013 at 10:26 PM, Chiradeep Vittal
 wrote:
>
>
> On 4/18/13 6:41 PM, "David Nalley"  wrote:
>
>>On Thu, Apr 18, 2013 at 6:26 PM, Will Chan  wrote:
>>>
>>> > -Original Message-
>>> > From: Chip Childers [mailto:chip.child...@sungard.com]
>>> > Sent: Monday, April 15, 2013 7:22 AM
>>> > To: dev@cloudstack.apache.org
>>> > Cc: cloudstack-...@incubator.apache.org
>>> > Subject: Re: [ASFCS42] Proposed schedule for our next release
>>> >
>>> > On Thu, Apr 11, 2013 at 02:50:02PM -0700, Animesh Chaturvedi wrote:
>>> > >
>>> > > I want to call out my concern on technical debt we have accumulated
>>>so
>>> > far.
>>> > >
>>> > >  I did an analysis on JIRA bugs yesterday night PST on "Affects
>>> > > Version = 4.1" and created since Dec 2012
>>> > >
>>> > > Total records : 429
>>> > > Resolution Type (Invalid, Duplicate, Cannot reproduce etc.) : 87 (30
>>> > > Blockers, 27 Critical, 27 Major, 4 Minor) Valid Defects  : 429-87=
>>>342
>>> > > Fixed : 246 (60 Blockers, 70 Critical, 99 Majors) out of which 217
>>> > > were fixed since Feb Unresolved : 96 (1 Blocker, 8 Critical, 64
>>>Major)
>>> > >
>>> > > With this data it looks like we have fixed 2/3 of valid defects in
>>>little over
>>> > 2 months and pretty much deferring around 1/3 rd of issues for future
>>> > release.
>>> > >
>>> > > I also looked at overall backlog of bugs (Critical, Major and
>>>Blockers only)
>>> > as of 4/10/2013 - 10:0PM PST.
>>> > >
>>> > > 284 open (18 Blocker, 38 Critical, 228 Major) ; By Fix version
>>> > > -  Release 4.0.x and prior: 13
>>> > > -  4.1: 70
>>> > > -  4.2 : 97
>>> > > -  Future: 8
>>> > > -  No version: 107
>>> > >
>>> > > Looking at that we fixed 217 bugs in roughly 2 months during 4.1
>>>cycle,
>>> > fixing the backlog of bug  will probably take us 2 months.  Should we
>>>extend
>>> > the 4.2 test cycle by 2 months [Original Schedule: 6/1 - 7/22,
>>>Extended
>>> > Schedule: 6/1-9/22] to reduce the technical debt significantly? I
>>>would like
>>> > to hear how community wants to address technical debt. Based on the
>>> > input and consensus I will publish the agreed schedule next week.
>>> > >
>>> > >
>>> >
>>> > I don't think that an extension of time changes bug counts really.
>>>IMO, we
>>> > need to pull together to have some bug-fix focused effort applied to
>>>the
>>> > code-base.  It's also another reason that I'm so big on making sure
>>>that
>>> > automated tests come in with the new features.  That doesn't address
>>>test
>>> > scenarios that human testers can come up with, but if a developer
>>>spends
>>> > the time to think about testing the basic feature and codifies that,
>>>we
>>> > should at least avoid the "this actually doesn't work at all" types
>>>of bugs.
>>> >
>>> > There's a school of thought that says, don't build another feature
>>>until you
>>> > have sorted out the known bugs in the current features.  I don't
>>>think we
>>> > could really pull that off, but perhaps a different thread to rally
>>>people
>>> > around the bug backlog is in order?
>>> >
>>> > -chip
>>>
>>> Sorry to chime in so late to this thread as I've been offsite for the
>>>better part of this week.  I was one of the original 4 month release
>>>crowd but after the recent two releases of ACS, I'm starting to wonder
>>>if we shouldn't start moving this to a 6 month cycle instead of two.
>>>Here are some high level observations based on the previous two releases:
>>>
>>> 1. It doesn't seem like we are on a true 4 month time based release
>>>schedule.  Both 4.0 and 4.1 were delayed more than several weeks past the
>>> original proposed GA date.  4.0 was released 11/6 and let's assume that
>>>4.1 will ship within a week or two.  That's almost a 6 month release
>>>cycle.
>>
>>So both 4.0 and 4.1 strike me as extraordinary. 4.0 was our first
>>release - and we had lots of issues to resolve. 4.1 introduced a ton
>>of packaging and name changes that I also consider to be hopefully one
>>time. Really - we've only been through our release cycle once, so I am
>>not ready to declare it perpetually behind schedule.
>>
>>
>>> Every release incurs a fixed cost of release notes, upgrade testing,
>>>etc. that I suspect at least eats a month worth of time depending on
>>>people's
>>> schedule.  That's 3 months out of the year rather than two if we can
>>>get a 6 months cycle.  We can use that extra month for other purposes if
>>>need
>>> be.  I suppose if we want to continue to release past the proposed hard
>>>GA date, then I guess it doesn't matter if it's 4 or 6 months.  It's
>>>basically a
>>> release when the release mgmt. team feels it's right to release based
>>>on current bugs, etc.
>>>
>>
>>Having seen the point releases twice now, which still need upgrade
>>testing, release notes, etc I don't get the feeling that the
>>'overhread' referred to above is the problem. Joe may disagree with
>>me.
>>
>>> 2. As more and more features/development go in, it just means more
>>>destabilization of the c

Re: Review Request: (CLOUDSTACK-1638) Network plugins won't be notified VM migration.

[Chiradeep Vittal]

> On April 18, 2013, 10:45 p.m., Chiradeep Vittal wrote:
> > Looks good.  Is this the final?
> 
> Hiroaki Kawai wrote:
> Yes. :-)
> 
> Ready to ship? Any comments from anybody else?
> 
> Chiradeep Vittal wrote:
> Any tests?
> 
> Hiroaki Kawai wrote:
> Tested functional with our private plugin, which will be public.

Can you add a unit test or a MockMigrationListener or something so that we know 
it works


- Chiradeep


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


On April 11, 2013, 7:22 a.m., Hiroaki Kawai wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/9871/
> ---
> 
> (Updated April 11, 2013, 7:22 a.m.)
> 
> 
> Review request for cloudstack, Hugo Trippaers and Chiradeep Vittal.
> 
> 
> Description
> ---
> 
> The location of the virtual machine is provided by DeployDestination, which 
> will be passed in NetworkGuru#reserve and NetworkElement#prepare. 
> 
> During the virtual machine migration, it actually changes DeployDestination 
> and it looks like that it will tell that event to network components as it 
> has NetworkManager#prepareNicForMigration. The problem is that althogh the 
> interface has that method, NetworkManagerImpl does not tell the 
> DeployDestination changes to network components. 
> 
> So IMHO, we need to add calls of NetworkGuru#reserve and 
> NetworkElement#prepare in NetworkManagerImpl#prepareNicForMigration . And 
> then, we also need to add calls NetworkGuru#release and 
> NetworkElement#release after the migration, otherwise the network resources 
> that plugin reserved will be kept even when the vm leaves off.
> 
> Created a first minimum patch to show the concept.
> 
> 
> This addresses bug CLOUDSTACK-1638.
> 
> 
> Diffs
> -
> 
>   api/src/com/cloud/network/NetworkMigrationResponder.java PRE-CREATION 
>   server/src/com/cloud/network/NetworkManager.java 4124b19 
>   server/src/com/cloud/network/NetworkManagerImpl.java a98bdd4 
>   server/src/com/cloud/vm/VirtualMachineManagerImpl.java 9230f4a 
> 
> Diff: https://reviews.apache.org/r/9871/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Hiroaki Kawai
> 
>

Re: [ASFCS42] Proposed schedule for our next release

[Chiradeep Vittal]

On 4/18/13 6:41 PM, "David Nalley"  wrote:

>On Thu, Apr 18, 2013 at 6:26 PM, Will Chan  wrote:
>>
>> > -Original Message-
>> > From: Chip Childers [mailto:chip.child...@sungard.com]
>> > Sent: Monday, April 15, 2013 7:22 AM
>> > To: dev@cloudstack.apache.org
>> > Cc: cloudstack-...@incubator.apache.org
>> > Subject: Re: [ASFCS42] Proposed schedule for our next release
>> >
>> > On Thu, Apr 11, 2013 at 02:50:02PM -0700, Animesh Chaturvedi wrote:
>> > >
>> > > I want to call out my concern on technical debt we have accumulated
>>so
>> > far.
>> > >
>> > >  I did an analysis on JIRA bugs yesterday night PST on "Affects
>> > > Version = 4.1" and created since Dec 2012
>> > >
>> > > Total records : 429
>> > > Resolution Type (Invalid, Duplicate, Cannot reproduce etc.) : 87 (30
>> > > Blockers, 27 Critical, 27 Major, 4 Minor) Valid Defects  : 429-87=
>>342
>> > > Fixed : 246 (60 Blockers, 70 Critical, 99 Majors) out of which 217
>> > > were fixed since Feb Unresolved : 96 (1 Blocker, 8 Critical, 64
>>Major)
>> > >
>> > > With this data it looks like we have fixed 2/3 of valid defects in
>>little over
>> > 2 months and pretty much deferring around 1/3 rd of issues for future
>> > release.
>> > >
>> > > I also looked at overall backlog of bugs (Critical, Major and
>>Blockers only)
>> > as of 4/10/2013 - 10:0PM PST.
>> > >
>> > > 284 open (18 Blocker, 38 Critical, 228 Major) ; By Fix version
>> > > -  Release 4.0.x and prior: 13
>> > > -  4.1: 70
>> > > -  4.2 : 97
>> > > -  Future: 8
>> > > -  No version: 107
>> > >
>> > > Looking at that we fixed 217 bugs in roughly 2 months during 4.1
>>cycle,
>> > fixing the backlog of bug  will probably take us 2 months.  Should we
>>extend
>> > the 4.2 test cycle by 2 months [Original Schedule: 6/1 - 7/22,
>>Extended
>> > Schedule: 6/1-9/22] to reduce the technical debt significantly? I
>>would like
>> > to hear how community wants to address technical debt. Based on the
>> > input and consensus I will publish the agreed schedule next week.
>> > >
>> > >
>> >
>> > I don't think that an extension of time changes bug counts really.
>>IMO, we
>> > need to pull together to have some bug-fix focused effort applied to
>>the
>> > code-base.  It's also another reason that I'm so big on making sure
>>that
>> > automated tests come in with the new features.  That doesn't address
>>test
>> > scenarios that human testers can come up with, but if a developer
>>spends
>> > the time to think about testing the basic feature and codifies that,
>>we
>> > should at least avoid the "this actually doesn't work at all" types
>>of bugs.
>> >
>> > There's a school of thought that says, don't build another feature
>>until you
>> > have sorted out the known bugs in the current features.  I don't
>>think we
>> > could really pull that off, but perhaps a different thread to rally
>>people
>> > around the bug backlog is in order?
>> >
>> > -chip
>>
>> Sorry to chime in so late to this thread as I've been offsite for the
>>better part of this week.  I was one of the original 4 month release
>>crowd but after the recent two releases of ACS, I'm starting to wonder
>>if we shouldn't start moving this to a 6 month cycle instead of two.
>>Here are some high level observations based on the previous two releases:
>>
>> 1. It doesn't seem like we are on a true 4 month time based release
>>schedule.  Both 4.0 and 4.1 were delayed more than several weeks past the
>> original proposed GA date.  4.0 was released 11/6 and let's assume that
>>4.1 will ship within a week or two.  That's almost a 6 month release
>>cycle.
>
>So both 4.0 and 4.1 strike me as extraordinary. 4.0 was our first
>release - and we had lots of issues to resolve. 4.1 introduced a ton
>of packaging and name changes that I also consider to be hopefully one
>time. Really - we've only been through our release cycle once, so I am
>not ready to declare it perpetually behind schedule.
>
>
>> Every release incurs a fixed cost of release notes, upgrade testing,
>>etc. that I suspect at least eats a month worth of time depending on
>>people's
>> schedule.  That's 3 months out of the year rather than two if we can
>>get a 6 months cycle.  We can use that extra month for other purposes if
>>need
>> be.  I suppose if we want to continue to release past the proposed hard
>>GA date, then I guess it doesn't matter if it's 4 or 6 months.  It's
>>basically a
>> release when the release mgmt. team feels it's right to release based
>>on current bugs, etc.
>>
>
>Having seen the point releases twice now, which still need upgrade
>testing, release notes, etc I don't get the feeling that the
>'overhread' referred to above is the problem. Joe may disagree with
>me.
>
>> 2. As more and more features/development go in, it just means more
>>destabilization of the code.  4.0 was delayed and the majority of that
>>work was
>> licensing files.  4.1 got just a bit more complicated with new feature
>>development and the delay is now much longer.  No

Re: Review Request: (CLOUDSTACK-1638) Network plugins won't be notified VM migration.

[Hiroaki Kawai]

> On April 18, 2013, 10:45 p.m., Chiradeep Vittal wrote:
> > Looks good.  Is this the final?
> 
> Hiroaki Kawai wrote:
> Yes. :-)
> 
> Ready to ship? Any comments from anybody else?
> 
> Chiradeep Vittal wrote:
> Any tests?

Tested functional with our private plugin, which will be public.


- Hiroaki


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


On April 11, 2013, 7:22 a.m., Hiroaki Kawai wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/9871/
> ---
> 
> (Updated April 11, 2013, 7:22 a.m.)
> 
> 
> Review request for cloudstack, Hugo Trippaers and Chiradeep Vittal.
> 
> 
> Description
> ---
> 
> The location of the virtual machine is provided by DeployDestination, which 
> will be passed in NetworkGuru#reserve and NetworkElement#prepare. 
> 
> During the virtual machine migration, it actually changes DeployDestination 
> and it looks like that it will tell that event to network components as it 
> has NetworkManager#prepareNicForMigration. The problem is that althogh the 
> interface has that method, NetworkManagerImpl does not tell the 
> DeployDestination changes to network components. 
> 
> So IMHO, we need to add calls of NetworkGuru#reserve and 
> NetworkElement#prepare in NetworkManagerImpl#prepareNicForMigration . And 
> then, we also need to add calls NetworkGuru#release and 
> NetworkElement#release after the migration, otherwise the network resources 
> that plugin reserved will be kept even when the vm leaves off.
> 
> Created a first minimum patch to show the concept.
> 
> 
> This addresses bug CLOUDSTACK-1638.
> 
> 
> Diffs
> -
> 
>   api/src/com/cloud/network/NetworkMigrationResponder.java PRE-CREATION 
>   server/src/com/cloud/network/NetworkManager.java 4124b19 
>   server/src/com/cloud/network/NetworkManagerImpl.java a98bdd4 
>   server/src/com/cloud/vm/VirtualMachineManagerImpl.java 9230f4a 
> 
> Diff: https://reviews.apache.org/r/9871/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Hiroaki Kawai
> 
>

Re: Review Request: (CLOUDSTACK-1638) Network plugins won't be notified VM migration.

[Chiradeep Vittal]

> On April 18, 2013, 10:45 p.m., Chiradeep Vittal wrote:
> > Looks good.  Is this the final?
> 
> Hiroaki Kawai wrote:
> Yes. :-)
> 
> Ready to ship? Any comments from anybody else?

Any tests?


- Chiradeep


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


On April 11, 2013, 7:22 a.m., Hiroaki Kawai wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/9871/
> ---
> 
> (Updated April 11, 2013, 7:22 a.m.)
> 
> 
> Review request for cloudstack, Hugo Trippaers and Chiradeep Vittal.
> 
> 
> Description
> ---
> 
> The location of the virtual machine is provided by DeployDestination, which 
> will be passed in NetworkGuru#reserve and NetworkElement#prepare. 
> 
> During the virtual machine migration, it actually changes DeployDestination 
> and it looks like that it will tell that event to network components as it 
> has NetworkManager#prepareNicForMigration. The problem is that althogh the 
> interface has that method, NetworkManagerImpl does not tell the 
> DeployDestination changes to network components. 
> 
> So IMHO, we need to add calls of NetworkGuru#reserve and 
> NetworkElement#prepare in NetworkManagerImpl#prepareNicForMigration . And 
> then, we also need to add calls NetworkGuru#release and 
> NetworkElement#release after the migration, otherwise the network resources 
> that plugin reserved will be kept even when the vm leaves off.
> 
> Created a first minimum patch to show the concept.
> 
> 
> This addresses bug CLOUDSTACK-1638.
> 
> 
> Diffs
> -
> 
>   api/src/com/cloud/network/NetworkMigrationResponder.java PRE-CREATION 
>   server/src/com/cloud/network/NetworkManager.java 4124b19 
>   server/src/com/cloud/network/NetworkManagerImpl.java a98bdd4 
>   server/src/com/cloud/vm/VirtualMachineManagerImpl.java 9230f4a 
> 
> Diff: https://reviews.apache.org/r/9871/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Hiroaki Kawai
> 
>

Re: DevCloud

[Mike Tutkowski]

OK...no problem :) I just wanted to make sure I wasn't missing something in
the Wiki.


On Thu, Apr 18, 2013 at 7:42 PM, Prasanna Santhanam <
prasanna.santha...@citrix.com> wrote:

> Sorry Mike, I just changed it couple of days ago. I will document this.
> Python tools for the java lobby are going to be problematic. :)
>
>
> --
> Prasanna.,
>
> - Original Message -
> From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com]
> Sent: Friday, April 19, 2013 09:36 AM
> To: dev@cloudstack.apache.org 
> Subject: Re: DevCloud
>
> Thanks!  That worked perfectly.
>
> So...I've been doing Java for about a dozen years now, but am new to
> Python.  Do we have any documentation that you know of which would have
> helped me with this problem?  For example, is this pip solution documented
> alongside DevCloud2?  I didn't see any, so was curious if I just missed it.
>
> Thanks again!
>
>
> On Thu, Apr 18, 2013 at 6:54 PM, Prasanna Santhanam <
> prasanna.santha...@citrix.com> wrote:
>
> > pip install requests
> >
> > That'll fix it.
> >
> >
> > --
> > Prasanna.,
> >
> > - Original Message -
> > From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com]
> > Sent: Friday, April 19, 2013 05:57 AM
> > To: dev@cloudstack.apache.org 
> > Subject: Re: DevCloud
> >
> > I tried
> >
> > port install py27-requests
> >
> > (MacPorts), but it didn't change the behavior of running
> >
> > python ../marvin/marvin/deployDataCenter.py -i devcloud.cfg
> >
> > Still claims to be unable to find the requests module (for CS 4.2).
> >
> >
> > On Thu, Apr 18, 2013 at 3:45 PM, Mike Tutkowski <
> > mike.tutkow...@solidfire.com> wrote:
> >
> > > Perhaps I'm using the wrong version of Python?  I'm on 2.7.
> > >
> > >
> > > On Thu, Apr 18, 2013 at 11:59 AM, Mike Tutkowski <
> > > mike.tutkow...@solidfire.com> wrote:
> > >
> > >> I have a related issue.  I sent it out under a different thread, but
> > >> should put it here, too.
> > >>
> > >> This is my issue.  I'm not sure how to get around it.  Thanks!!
> > >>
> > >> mtutkowski-LT:devcloud mtutkowski$ python
> > >> ../marvin/marvin/deployDataCenter.py -i devcloud.cfg
> > >> Traceback (most recent call last):
> > >>   File "../marvin/marvin/deployDataCenter.py", line 21, in 
> > >> import cloudstackTestClient
> > >>   File
> > >>
> >
> "/Users/mtutkowski/Documents/CloudStack/src/incubator-cloudstack/tools/marvin/marvin/cloudstackTestClient.py",
> > >> line 18, in 
> > >> import cloudstackConnection
> > >>   File
> > >>
> >
> "/Users/mtutkowski/Documents/CloudStack/src/incubator-cloudstack/tools/marvin/marvin/cloudstackConnection.py",
> > >> line 18, in 
> > >> import requests
> > >> ImportError: No module named requests
> > >>
> > >>
> > >> On Thu, Apr 18, 2013 at 11:51 AM, Rohit Yadav  > >wrote:
> > >>
> > >>> On Thu, Apr 18, 2013 at 10:17 PM, Aaron Paradowski
> > >>> wrote:
> > >>>
> > >>> > Hi Rohit,
> > >>> >
> > >>> > ** **
> > >>> >
> > >>> > I’m having some problems deploying DevCloud2 and wonder if you
> could
> > >>> help
> > >>> > please. So far I have done the following
> > >>> >
> > >>> > ** **
> > >>> >
> > >>> > **1.   **Downloaded and imported the DevCloud2 image into
> > >>> VirtualBox
> > >>> > – ensured network settings were correct etc.
> > >>> >
> > >>> > **2.   **Used PuTTY to SSH to the machine at 192.168.56.10 and
> > >>> logged
> > >>> > in with root and password for username and password
> > >>> >
> > >>> > **3.   **cd to /opt/cloudstack
> > >>> >
> > >>> > **4.   **git cloned into the source code for incubator
> > >>> cloudstack
> > >>> >
> > >>> > **5.   **once that had completed I cd’d to the
> > incubator-cloudstack
> > >>> > directory
> > >>> >
> > >>> > **6.   **Ran mvn clean install –P developer,systemvm
> > >>> >
> > >>> > **7.   **Changedthe host value in devcloud.sql to 192.168.56.10
> > as
> > >>> I
> > >>> > want everything to run inside this one VM
> > >>> >
> > >>> > **8.   **Ran mvn –pl developer,tools/devloud –Deploydb –P
> > developer
> > >>> >
> > >>>
> > >>> Hi Aaron,
> > >>>
> > >>> The best way is to reach to the whole community and cc any particular
> > >>> person whose attention you may be seeking.
> > >>>
> > >>> 1-8: So far so good, ignoring the -Ddeploydb typo.
> > >>>
> > >>>
> > >>> > 
> > >>> >
> > >>> > 9.   Then ran mvn-pl client jetty:run and this is where
> > everything
> > >>> > goes wrong. It hangs on the below screen for ages then it goes
> > through
> > >>> lots
> > >>> > of warnings and errors such as “WARN [apache.cloudstack.alerts]
> > (HA-3:)
> > >>> > alertType:: 13” – I left it for 19 hours overnight last night and
> > those
> > >>> > types of errors just kept going round in cycles?
> > >>> >
> > >>> Looks like CloudStack issue? Did you try exporting maven opts,
> checkout
> > >>> the
> > >>> building on master on cwiki.apache.org / cloudstack and try again?
> > >>>
> > >>> If you're just able to login inside DevCloud2 and run some

Re: CLOUDSTACK-1876

[Abhinandan Prateek]

On 18/04/13 10:02 PM, "Rohit Yadav"  wrote:

>On Thu, Apr 18, 2013 at 7:47 PM, Abhinandan Prateek
>> wrote:
>
>>
>> While debugging the VMWare system template fixed the cd rom device name
>> that was causing the systemvm.iso not to load.
>> After this the SSVM and CPVM are coming up fine.
>>
>> On router VM creation though it failed as this file
>> /etc/udev/rules.d/70-persistent-net.rules  was present in the template
>>as
>> a directory !
>> This file is recreated on reboot so I have created another template
>>after
>> removing this directory.
>>
>>
>Oh man! Yes Abhi we don't need this file. I remember removing this file
>which is done in cleanup.sh:
>https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=blob;f=tools/ap
>pliance/definitions/systemvmtemplate/cleanup.sh;h=9e98ab03531f0c8fee6c0402
>31e5d0f4871ae777;hb=f4240e1cea58be0ea7b50c77a018d7c63e3faf15
>
>Maybe I missed it while manually installing vmware-tools via vmware
>fusion.
>The open-vm-tools based appliance won't have this issue:
>http://people.apache.org/~bhaisaab/cloudstack/systemvmtemplates/systemvmte
>mplate-openvmtools-vmware.ova

Yes, the template in general works fine. But due to presence of that
directory the cloud-early-config that checks for sanity of that file
continues to reboot. Do make that change in the script and generate a new
set.

>
>
>> Please, confirm if that is right. I will publish the template soon as it
>> is still uploading.
>>
>
>Cool, Abhi did you reuse the appliance I had shared or created your own?
>Share any special steps that were needed to be done.

I started with the one generated by jenkins that you setup. There were
some issues to make it work with cloudstack.
Once we have a fully functional appliance I will list down the additional
steps. Some of them can be then fixed in the scripts.

>
>Cheers.
>
>
>>
>> -abhi
>>
>>

Re: Review Request: Re-enable baremetal components

[David Nalley]

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


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

- David Nalley


On April 19, 2013, 1:33 a.m., Venkata Siva Vijayendra Bhamidipati wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/10616/
> ---
> 
> (Updated April 19, 2013, 1:33 a.m.)
> 
> 
> Review request for cloudstack, Chip Childers, Kelven Yang, and Frank Zhang.
> 
> 
> Description
> ---
> 
> Baremetal provisioning components were commented out on master - uncommenting 
> them again to allow creation of baremetal clusters.
> 
> 
> This addresses bug CLOUDSTACK-2101.
> 
> 
> Diffs
> -
> 
>   client/tomcatconf/applicationContext.xml.in 7487a5e 
>   client/tomcatconf/componentContext.xml.in 7a46981 
>   client/tomcatconf/nonossComponentContext.xml.in 2359ba8 
> 
> Diff: https://reviews.apache.org/r/10616/diff/
> 
> 
> Testing
> ---
> 
> Creation of a cluster of hypervisor type baremetal succeeds with these 
> changes in.
> 
> 
> Thanks,
> 
> Venkata Siva Vijayendra Bhamidipati
> 
>

Re: DevCloud

[Prasanna Santhanam]

Sorry Mike, I just changed it couple of days ago. I will document this. Python 
tools for the java lobby are going to be problematic. :)


--
Prasanna.,

- Original Message -
From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com]
Sent: Friday, April 19, 2013 09:36 AM
To: dev@cloudstack.apache.org 
Subject: Re: DevCloud

Thanks!  That worked perfectly.

So...I've been doing Java for about a dozen years now, but am new to
Python.  Do we have any documentation that you know of which would have
helped me with this problem?  For example, is this pip solution documented
alongside DevCloud2?  I didn't see any, so was curious if I just missed it.

Thanks again!


On Thu, Apr 18, 2013 at 6:54 PM, Prasanna Santhanam <
prasanna.santha...@citrix.com> wrote:

> pip install requests
>
> That'll fix it.
>
>
> --
> Prasanna.,
>
> - Original Message -
> From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com]
> Sent: Friday, April 19, 2013 05:57 AM
> To: dev@cloudstack.apache.org 
> Subject: Re: DevCloud
>
> I tried
>
> port install py27-requests
>
> (MacPorts), but it didn't change the behavior of running
>
> python ../marvin/marvin/deployDataCenter.py -i devcloud.cfg
>
> Still claims to be unable to find the requests module (for CS 4.2).
>
>
> On Thu, Apr 18, 2013 at 3:45 PM, Mike Tutkowski <
> mike.tutkow...@solidfire.com> wrote:
>
> > Perhaps I'm using the wrong version of Python?  I'm on 2.7.
> >
> >
> > On Thu, Apr 18, 2013 at 11:59 AM, Mike Tutkowski <
> > mike.tutkow...@solidfire.com> wrote:
> >
> >> I have a related issue.  I sent it out under a different thread, but
> >> should put it here, too.
> >>
> >> This is my issue.  I'm not sure how to get around it.  Thanks!!
> >>
> >> mtutkowski-LT:devcloud mtutkowski$ python
> >> ../marvin/marvin/deployDataCenter.py -i devcloud.cfg
> >> Traceback (most recent call last):
> >>   File "../marvin/marvin/deployDataCenter.py", line 21, in 
> >> import cloudstackTestClient
> >>   File
> >>
> "/Users/mtutkowski/Documents/CloudStack/src/incubator-cloudstack/tools/marvin/marvin/cloudstackTestClient.py",
> >> line 18, in 
> >> import cloudstackConnection
> >>   File
> >>
> "/Users/mtutkowski/Documents/CloudStack/src/incubator-cloudstack/tools/marvin/marvin/cloudstackConnection.py",
> >> line 18, in 
> >> import requests
> >> ImportError: No module named requests
> >>
> >>
> >> On Thu, Apr 18, 2013 at 11:51 AM, Rohit Yadav  >wrote:
> >>
> >>> On Thu, Apr 18, 2013 at 10:17 PM, Aaron Paradowski
> >>> wrote:
> >>>
> >>> > Hi Rohit,
> >>> >
> >>> > ** **
> >>> >
> >>> > I’m having some problems deploying DevCloud2 and wonder if you could
> >>> help
> >>> > please. So far I have done the following
> >>> >
> >>> > ** **
> >>> >
> >>> > **1.   **Downloaded and imported the DevCloud2 image into
> >>> VirtualBox
> >>> > – ensured network settings were correct etc.
> >>> >
> >>> > **2.   **Used PuTTY to SSH to the machine at 192.168.56.10 and
> >>> logged
> >>> > in with root and password for username and password
> >>> >
> >>> > **3.   **cd to /opt/cloudstack
> >>> >
> >>> > **4.   **git cloned into the source code for incubator
> >>> cloudstack
> >>> >
> >>> > **5.   **once that had completed I cd’d to the
> incubator-cloudstack
> >>> > directory
> >>> >
> >>> > **6.   **Ran mvn clean install –P developer,systemvm
> >>> >
> >>> > **7.   **Changedthe host value in devcloud.sql to 192.168.56.10
> as
> >>> I
> >>> > want everything to run inside this one VM
> >>> >
> >>> > **8.   **Ran mvn –pl developer,tools/devloud –Deploydb –P
> developer
> >>> >
> >>>
> >>> Hi Aaron,
> >>>
> >>> The best way is to reach to the whole community and cc any particular
> >>> person whose attention you may be seeking.
> >>>
> >>> 1-8: So far so good, ignoring the -Ddeploydb typo.
> >>>
> >>>
> >>> > 
> >>> >
> >>> > 9.   Then ran mvn-pl client jetty:run and this is where
> everything
> >>> > goes wrong. It hangs on the below screen for ages then it goes
> through
> >>> lots
> >>> > of warnings and errors such as “WARN [apache.cloudstack.alerts]
> (HA-3:)
> >>> > alertType:: 13” – I left it for 19 hours overnight last night and
> those
> >>> > types of errors just kept going round in cycles?
> >>> >
> >>> Looks like CloudStack issue? Did you try exporting maven opts, checkout
> >>> the
> >>> building on master on cwiki.apache.org / cloudstack and try again?
> >>>
> >>> If you're just able to login inside DevCloud2 and run something like xe
> >>> vm-list and it outputs something we're good at least from DevCloud's
> >>> side :)
> >>>
> >>> Anyone from community?
> >>>
> >>> Cheers.
> >>>
> >>>
> >>> > 
> >>> >
> >>> > 
> >>> >
> >>> > ** **
> >>> >
> >>> > Any help would be greatly appreciated! Many thanks in advance.
> >>> >
> >>> > ** **
> >>> >
> >>> > Kind Regards,
> >>> >
> >>> > ** **
> >>> >
> >>> > *Aaron Paradowski*
> >>> >
> >>> > ** **
> >>> >
> >>>
> >>
> >>
> >>
> >> --
> >>

Re: [ASFCS42] Proposed schedule for our next release

[David Nalley]

On Thu, Apr 18, 2013 at 6:26 PM, Will Chan  wrote:
>
> > -Original Message-
> > From: Chip Childers [mailto:chip.child...@sungard.com]
> > Sent: Monday, April 15, 2013 7:22 AM
> > To: dev@cloudstack.apache.org
> > Cc: cloudstack-...@incubator.apache.org
> > Subject: Re: [ASFCS42] Proposed schedule for our next release
> >
> > On Thu, Apr 11, 2013 at 02:50:02PM -0700, Animesh Chaturvedi wrote:
> > >
> > > I want to call out my concern on technical debt we have accumulated so
> > far.
> > >
> > >  I did an analysis on JIRA bugs yesterday night PST on "Affects
> > > Version = 4.1" and created since Dec 2012
> > >
> > > Total records : 429
> > > Resolution Type (Invalid, Duplicate, Cannot reproduce etc.) : 87 (30
> > > Blockers, 27 Critical, 27 Major, 4 Minor) Valid Defects  : 429-87= 342
> > > Fixed : 246 (60 Blockers, 70 Critical, 99 Majors) out of which 217
> > > were fixed since Feb Unresolved : 96 (1 Blocker, 8 Critical, 64 Major)
> > >
> > > With this data it looks like we have fixed 2/3 of valid defects in little 
> > > over
> > 2 months and pretty much deferring around 1/3 rd of issues for future
> > release.
> > >
> > > I also looked at overall backlog of bugs (Critical, Major and Blockers 
> > > only)
> > as of 4/10/2013 - 10:0PM PST.
> > >
> > > 284 open (18 Blocker, 38 Critical, 228 Major) ; By Fix version
> > > -  Release 4.0.x and prior: 13
> > > -  4.1: 70
> > > -  4.2 : 97
> > > -  Future: 8
> > > -  No version: 107
> > >
> > > Looking at that we fixed 217 bugs in roughly 2 months during 4.1 cycle,
> > fixing the backlog of bug  will probably take us 2 months.  Should we extend
> > the 4.2 test cycle by 2 months [Original Schedule: 6/1 - 7/22, Extended
> > Schedule: 6/1-9/22] to reduce the technical debt significantly? I would like
> > to hear how community wants to address technical debt. Based on the
> > input and consensus I will publish the agreed schedule next week.
> > >
> > >
> >
> > I don't think that an extension of time changes bug counts really.  IMO, we
> > need to pull together to have some bug-fix focused effort applied to the
> > code-base.  It's also another reason that I'm so big on making sure that
> > automated tests come in with the new features.  That doesn't address test
> > scenarios that human testers can come up with, but if a developer spends
> > the time to think about testing the basic feature and codifies that, we
> > should at least avoid the "this actually doesn't work at all" types of bugs.
> >
> > There's a school of thought that says, don't build another feature until you
> > have sorted out the known bugs in the current features.  I don't think we
> > could really pull that off, but perhaps a different thread to rally people
> > around the bug backlog is in order?
> >
> > -chip
>
> Sorry to chime in so late to this thread as I've been offsite for the better 
> part of this week.  I was one of the original 4 month release crowd but after 
> the recent two releases of ACS, I'm starting to wonder if we shouldn't start 
> moving this to a 6 month cycle instead of two.  Here are some high level 
> observations based on the previous two releases:
>
> 1. It doesn't seem like we are on a true 4 month time based release schedule. 
>  Both 4.0 and 4.1 were delayed more than several weeks past the
> original proposed GA date.  4.0 was released 11/6 and let's assume that 4.1 
> will ship within a week or two.  That's almost a 6 month release cycle.

So both 4.0 and 4.1 strike me as extraordinary. 4.0 was our first
release - and we had lots of issues to resolve. 4.1 introduced a ton
of packaging and name changes that I also consider to be hopefully one
time. Really - we've only been through our release cycle once, so I am
not ready to declare it perpetually behind schedule.


> Every release incurs a fixed cost of release notes, upgrade testing, etc. 
> that I suspect at least eats a month worth of time depending on people's
> schedule.  That's 3 months out of the year rather than two if we can get a 6 
> months cycle.  We can use that extra month for other purposes if need
> be.  I suppose if we want to continue to release past the proposed hard GA 
> date, then I guess it doesn't matter if it's 4 or 6 months.  It's basically a
> release when the release mgmt. team feels it's right to release based on 
> current bugs, etc.
>

Having seen the point releases twice now, which still need upgrade
testing, release notes, etc I don't get the feeling that the
'overhread' referred to above is the problem. Joe may disagree with
me.

> 2. As more and more features/development go in, it just means more 
> destabilization of the code.  4.0 was delayed and the majority of that work 
> was
> licensing files.  4.1 got just a bit more complicated with new feature 
> development and the delay is now much longer.  Not all features are created
> equal in terms of testing.  Some may require more time to develop but may not 
> impact the entire system like for examp

Re: DevCloud

[Mike Tutkowski]

Thanks!  That worked perfectly.

So...I've been doing Java for about a dozen years now, but am new to
Python.  Do we have any documentation that you know of which would have
helped me with this problem?  For example, is this pip solution documented
alongside DevCloud2?  I didn't see any, so was curious if I just missed it.

Thanks again!


On Thu, Apr 18, 2013 at 6:54 PM, Prasanna Santhanam <
prasanna.santha...@citrix.com> wrote:

> pip install requests
>
> That'll fix it.
>
>
> --
> Prasanna.,
>
> - Original Message -
> From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com]
> Sent: Friday, April 19, 2013 05:57 AM
> To: dev@cloudstack.apache.org 
> Subject: Re: DevCloud
>
> I tried
>
> port install py27-requests
>
> (MacPorts), but it didn't change the behavior of running
>
> python ../marvin/marvin/deployDataCenter.py -i devcloud.cfg
>
> Still claims to be unable to find the requests module (for CS 4.2).
>
>
> On Thu, Apr 18, 2013 at 3:45 PM, Mike Tutkowski <
> mike.tutkow...@solidfire.com> wrote:
>
> > Perhaps I'm using the wrong version of Python?  I'm on 2.7.
> >
> >
> > On Thu, Apr 18, 2013 at 11:59 AM, Mike Tutkowski <
> > mike.tutkow...@solidfire.com> wrote:
> >
> >> I have a related issue.  I sent it out under a different thread, but
> >> should put it here, too.
> >>
> >> This is my issue.  I'm not sure how to get around it.  Thanks!!
> >>
> >> mtutkowski-LT:devcloud mtutkowski$ python
> >> ../marvin/marvin/deployDataCenter.py -i devcloud.cfg
> >> Traceback (most recent call last):
> >>   File "../marvin/marvin/deployDataCenter.py", line 21, in 
> >> import cloudstackTestClient
> >>   File
> >>
> "/Users/mtutkowski/Documents/CloudStack/src/incubator-cloudstack/tools/marvin/marvin/cloudstackTestClient.py",
> >> line 18, in 
> >> import cloudstackConnection
> >>   File
> >>
> "/Users/mtutkowski/Documents/CloudStack/src/incubator-cloudstack/tools/marvin/marvin/cloudstackConnection.py",
> >> line 18, in 
> >> import requests
> >> ImportError: No module named requests
> >>
> >>
> >> On Thu, Apr 18, 2013 at 11:51 AM, Rohit Yadav  >wrote:
> >>
> >>> On Thu, Apr 18, 2013 at 10:17 PM, Aaron Paradowski
> >>> wrote:
> >>>
> >>> > Hi Rohit,
> >>> >
> >>> > ** **
> >>> >
> >>> > I’m having some problems deploying DevCloud2 and wonder if you could
> >>> help
> >>> > please. So far I have done the following
> >>> >
> >>> > ** **
> >>> >
> >>> > **1.   **Downloaded and imported the DevCloud2 image into
> >>> VirtualBox
> >>> > – ensured network settings were correct etc.
> >>> >
> >>> > **2.   **Used PuTTY to SSH to the machine at 192.168.56.10 and
> >>> logged
> >>> > in with root and password for username and password
> >>> >
> >>> > **3.   **cd to /opt/cloudstack
> >>> >
> >>> > **4.   **git cloned into the source code for incubator
> >>> cloudstack
> >>> >
> >>> > **5.   **once that had completed I cd’d to the
> incubator-cloudstack
> >>> > directory
> >>> >
> >>> > **6.   **Ran mvn clean install –P developer,systemvm
> >>> >
> >>> > **7.   **Changedthe host value in devcloud.sql to 192.168.56.10
> as
> >>> I
> >>> > want everything to run inside this one VM
> >>> >
> >>> > **8.   **Ran mvn –pl developer,tools/devloud –Deploydb –P
> developer
> >>> >
> >>>
> >>> Hi Aaron,
> >>>
> >>> The best way is to reach to the whole community and cc any particular
> >>> person whose attention you may be seeking.
> >>>
> >>> 1-8: So far so good, ignoring the -Ddeploydb typo.
> >>>
> >>>
> >>> > 
> >>> >
> >>> > 9.   Then ran mvn-pl client jetty:run and this is where
> everything
> >>> > goes wrong. It hangs on the below screen for ages then it goes
> through
> >>> lots
> >>> > of warnings and errors such as “WARN [apache.cloudstack.alerts]
> (HA-3:)
> >>> > alertType:: 13” – I left it for 19 hours overnight last night and
> those
> >>> > types of errors just kept going round in cycles?
> >>> >
> >>> Looks like CloudStack issue? Did you try exporting maven opts, checkout
> >>> the
> >>> building on master on cwiki.apache.org / cloudstack and try again?
> >>>
> >>> If you're just able to login inside DevCloud2 and run something like xe
> >>> vm-list and it outputs something we're good at least from DevCloud's
> >>> side :)
> >>>
> >>> Anyone from community?
> >>>
> >>> Cheers.
> >>>
> >>>
> >>> > 
> >>> >
> >>> > 
> >>> >
> >>> > ** **
> >>> >
> >>> > Any help would be greatly appreciated! Many thanks in advance.
> >>> >
> >>> > ** **
> >>> >
> >>> > Kind Regards,
> >>> >
> >>> > ** **
> >>> >
> >>> > *Aaron Paradowski*
> >>> >
> >>> > ** **
> >>> >
> >>>
> >>
> >>
> >>
> >> --
> >> *Mike Tutkowski*
> >>  *Senior CloudStack Developer, SolidFire Inc.*
> >> e: mike.tutkow...@solidfire.com
> >> o: 303.746.7302
> >> Advancing the way the world uses the cloud<
> http://solidfire.com/solution/overview/?video=play>
> >> *™*
> >>
> >
> >
> >
> > --
> > *Mike Tutkowski*
> > *Senior CloudStack Developer, SolidFire Inc.*

Review Request: Re-enable baremetal components

[Venkata Siva Vijayendra Bhamidipati]

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

Review request for cloudstack, Chip Childers, Kelven Yang, and Frank Zhang.


Description
---

Baremetal provisioning components were commented out on master - uncommenting 
them again to allow creation of baremetal clusters.


This addresses bug CLOUDSTACK-2101.


Diffs
-

  client/tomcatconf/applicationContext.xml.in 7487a5e 
  client/tomcatconf/componentContext.xml.in 7a46981 
  client/tomcatconf/nonossComponentContext.xml.in 2359ba8 

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


Testing
---

Creation of a cluster of hypervisor type baremetal succeeds with these changes 
in.


Thanks,

Venkata Siva Vijayendra Bhamidipati

Re: Review Request: (CLOUDSTACK-1638) Network plugins won't be notified VM migration.

[Hiroaki Kawai]

> On April 18, 2013, 10:45 p.m., Chiradeep Vittal wrote:
> > Looks good.  Is this the final?

Yes. :-)

Ready to ship? Any comments from anybody else?


- Hiroaki


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


On April 11, 2013, 7:22 a.m., Hiroaki Kawai wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/9871/
> ---
> 
> (Updated April 11, 2013, 7:22 a.m.)
> 
> 
> Review request for cloudstack, Hugo Trippaers and Chiradeep Vittal.
> 
> 
> Description
> ---
> 
> The location of the virtual machine is provided by DeployDestination, which 
> will be passed in NetworkGuru#reserve and NetworkElement#prepare. 
> 
> During the virtual machine migration, it actually changes DeployDestination 
> and it looks like that it will tell that event to network components as it 
> has NetworkManager#prepareNicForMigration. The problem is that althogh the 
> interface has that method, NetworkManagerImpl does not tell the 
> DeployDestination changes to network components. 
> 
> So IMHO, we need to add calls of NetworkGuru#reserve and 
> NetworkElement#prepare in NetworkManagerImpl#prepareNicForMigration . And 
> then, we also need to add calls NetworkGuru#release and 
> NetworkElement#release after the migration, otherwise the network resources 
> that plugin reserved will be kept even when the vm leaves off.
> 
> Created a first minimum patch to show the concept.
> 
> 
> This addresses bug CLOUDSTACK-1638.
> 
> 
> Diffs
> -
> 
>   api/src/com/cloud/network/NetworkMigrationResponder.java PRE-CREATION 
>   server/src/com/cloud/network/NetworkManager.java 4124b19 
>   server/src/com/cloud/network/NetworkManagerImpl.java a98bdd4 
>   server/src/com/cloud/vm/VirtualMachineManagerImpl.java 9230f4a 
> 
> Diff: https://reviews.apache.org/r/9871/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Hiroaki Kawai
> 
>

Re: DevCloud

[Prasanna Santhanam]

pip install requests

That'll fix it.


--
Prasanna.,

- Original Message -
From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com]
Sent: Friday, April 19, 2013 05:57 AM
To: dev@cloudstack.apache.org 
Subject: Re: DevCloud

I tried

port install py27-requests

(MacPorts), but it didn't change the behavior of running

python ../marvin/marvin/deployDataCenter.py -i devcloud.cfg

Still claims to be unable to find the requests module (for CS 4.2).


On Thu, Apr 18, 2013 at 3:45 PM, Mike Tutkowski <
mike.tutkow...@solidfire.com> wrote:

> Perhaps I'm using the wrong version of Python?  I'm on 2.7.
>
>
> On Thu, Apr 18, 2013 at 11:59 AM, Mike Tutkowski <
> mike.tutkow...@solidfire.com> wrote:
>
>> I have a related issue.  I sent it out under a different thread, but
>> should put it here, too.
>>
>> This is my issue.  I'm not sure how to get around it.  Thanks!!
>>
>> mtutkowski-LT:devcloud mtutkowski$ python
>> ../marvin/marvin/deployDataCenter.py -i devcloud.cfg
>> Traceback (most recent call last):
>>   File "../marvin/marvin/deployDataCenter.py", line 21, in 
>> import cloudstackTestClient
>>   File
>> "/Users/mtutkowski/Documents/CloudStack/src/incubator-cloudstack/tools/marvin/marvin/cloudstackTestClient.py",
>> line 18, in 
>> import cloudstackConnection
>>   File
>> "/Users/mtutkowski/Documents/CloudStack/src/incubator-cloudstack/tools/marvin/marvin/cloudstackConnection.py",
>> line 18, in 
>> import requests
>> ImportError: No module named requests
>>
>>
>> On Thu, Apr 18, 2013 at 11:51 AM, Rohit Yadav wrote:
>>
>>> On Thu, Apr 18, 2013 at 10:17 PM, Aaron Paradowski
>>> wrote:
>>>
>>> > Hi Rohit,
>>> >
>>> > ** **
>>> >
>>> > I’m having some problems deploying DevCloud2 and wonder if you could
>>> help
>>> > please. So far I have done the following
>>> >
>>> > ** **
>>> >
>>> > **1.   **Downloaded and imported the DevCloud2 image into
>>> VirtualBox
>>> > – ensured network settings were correct etc.
>>> >
>>> > **2.   **Used PuTTY to SSH to the machine at 192.168.56.10 and
>>> logged
>>> > in with root and password for username and password
>>> >
>>> > **3.   **cd to /opt/cloudstack
>>> >
>>> > **4.   **git cloned into the source code for incubator
>>> cloudstack
>>> >
>>> > **5.   **once that had completed I cd’d to the incubator-cloudstack
>>> > directory
>>> >
>>> > **6.   **Ran mvn clean install –P developer,systemvm
>>> >
>>> > **7.   **Changedthe host value in devcloud.sql to 192.168.56.10 as
>>> I
>>> > want everything to run inside this one VM
>>> >
>>> > **8.   **Ran mvn –pl developer,tools/devloud –Deploydb –P developer
>>> >
>>>
>>> Hi Aaron,
>>>
>>> The best way is to reach to the whole community and cc any particular
>>> person whose attention you may be seeking.
>>>
>>> 1-8: So far so good, ignoring the -Ddeploydb typo.
>>>
>>>
>>> > 
>>> >
>>> > 9.   Then ran mvn-pl client jetty:run and this is where everything
>>> > goes wrong. It hangs on the below screen for ages then it goes through
>>> lots
>>> > of warnings and errors such as “WARN [apache.cloudstack.alerts] (HA-3:)
>>> > alertType:: 13” – I left it for 19 hours overnight last night and those
>>> > types of errors just kept going round in cycles?
>>> >
>>> Looks like CloudStack issue? Did you try exporting maven opts, checkout
>>> the
>>> building on master on cwiki.apache.org / cloudstack and try again?
>>>
>>> If you're just able to login inside DevCloud2 and run something like xe
>>> vm-list and it outputs something we're good at least from DevCloud's
>>> side :)
>>>
>>> Anyone from community?
>>>
>>> Cheers.
>>>
>>>
>>> > 
>>> >
>>> > 
>>> >
>>> > ** **
>>> >
>>> > Any help would be greatly appreciated! Many thanks in advance.
>>> >
>>> > ** **
>>> >
>>> > Kind Regards,
>>> >
>>> > ** **
>>> >
>>> > *Aaron Paradowski*
>>> >
>>> > ** **
>>> >
>>>
>>
>>
>>
>> --
>> *Mike Tutkowski*
>>  *Senior CloudStack Developer, SolidFire Inc.*
>> e: mike.tutkow...@solidfire.com
>> o: 303.746.7302
>> Advancing the way the world uses the 
>> cloud
>> *™*
>>
>
>
>
> --
> *Mike Tutkowski*
> *Senior CloudStack Developer, SolidFire Inc.*
> e: mike.tutkow...@solidfire.com
> o: 303.746.7302
> Advancing the way the world uses the 
> cloud
> *™*
>



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

Re: [VOTE][ACS402] Apache CloudStack 4.0.2 (Second Round)

[Chip Childers]

On Thu, Apr 18, 2013 at 03:17:21PM -0500, Joe Brockmeier wrote:
> Hi All,
> 
> I've created a 4.0.2 release, and am asking for you to test the
> artifacts and
> *after* testing, please submit a vote. Suggested testing procedure here:
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/CloudStack+4.0+test+procedure

I've updated the instructions above to be accurate to this release
(removed incubating / incubator text where appropriate and included a
step to switch DevCloud's local git repo to the new URL).

DnsNotifier Example

[Soheil Eizadi]

I am trying to run the DnsNotifier example in my CloudStack Environment, I am 
having trouble with the Spring wiring. I modified the DnsNotifier.java file to 
add @Component annotation and modified the two files componentContext.xml.in 
and nonossComponentContext.xml.in to add reference to the DnsNotifier. I get 
everything to build but the Spring Class Loader can not find DnsNotifier Class 
to load, what more needs to be done to get this to run?
-Soheil

ovider,databaseUpgradeChecker,configurationDaoImpl,GlobalLoadBalancingRulesServiceImpl,DnsNotifier,niciraNvpDaoImpl,niciraNvpNicMappingDaoImpl,niciraNvpRouterMappingDaoImpl,NiciraNvpGuestNetworkGuru,NiciraNvp,MidoNetGuestNetworkGuru,MidoNetElement,userAuthenticators,userPasswordEncoders,securityCheckers,resourceDiscoverers,haInvestigators,haFenceBuilders,deploymentPlanners,podAllocators,hostAllocators,storagePoolAllocators,ipDeployers,dhcpProviders,networkGurus,networkElements,org.springframework.context.annotation.ConfigurationClassPostProcessor$ImportAwareBeanPostProcessor#0];
 root of factory hierarchy
ERROR [web.context.ContextLoader] (main:) Context initialization failed
org.springframework.beans.factory.BeanCreationException: Error creating bean 
with name 'actionEventUtils': Injection of autowired dependencies failed; 
nested exception is org.springframework.beans.factory.BeanCreationException: 
Could not autowire field: com.cloud.event.dao.EventDao 
com.cloud.event.ActionEventUtils.eventDao; nested exception is 
org.springframework.beans.factory.CannotLoadBeanClassException: Cannot find 
class [org.apache.cloudstack.network.element.DnsNotifier] for bean with name 
'DnsNotifier' defined in class path resource [componentContext.xml]; nested 
exception is java.lang.ClassNotFoundException: 
org.apache.cloudstack.network.element.DnsNotifier

Administrators-MacBook-Pro-7:cloudstack seizadi$ find . -name DnsNotifier.class
./plugins/network-elements/dns-notifier/target/classes/org/apache/cloudstack/network/element/DnsNotifier.class

diff --git 
a/plugins/network-elements/dns-notifier/src/org/apache/cloudstack/network/element/DnsNotifier.java
 
b/plugins/network-elements/dns-notifier/src/org/apache/cloudstack/network/element/DnsNotifier.java
index c421344..8f8986d 100644
--- 
a/plugins/network-elements/dns-notifier/src/org/apache/cloudstack/network/element/DnsNotifier.java
+++ 
b/plugins/network-elements/dns-notifier/src/org/apache/cloudstack/network/element/DnsNotifier.java
@@ -22,7 +22,9 @@ import java.util.Map;
 import java.util.Set;

 import javax.ejb.Local;
-import javax.naming.ConfigurationException;
+
+import org.apache.log4j.Logger;
+import org.springframework.stereotype.Component;

 import com.cloud.deploy.DeployDestination;
 import com.cloud.exception.ConcurrentOperationException;
@@ -45,13 +47,17 @@ import com.cloud.vm.VirtualMachineProfile;
  * @author ahuang
  *
  */
+
+@Component
 @Local(NetworkElement.class)
 public class DnsNotifier extends AdapterBase implements NetworkElement {


diff --git a/client/tomcatconf/componentContext.xml.in 
b/client/tomcatconf/componentContext.xml.in
index bea2f78..202a998 100644
--- a/client/tomcatconf/componentContext.xml.in
+++ b/client/tomcatconf/componentContext.xml.in
@@ -46,6 +46,14 @@
   

   
+
+  
+
+  
+

   
   
@@ -331,6 +338,8 @@
   
   
   
+  
 

RE: [PROPOSAL] [CLOUDSTACK-2056] DeploymentPlanner choice via ServiceOffering

[Prachi Damle]

I think currently how the data disks are allocated is still governed by the 
same flag vm.allocation.algorithm - as are the hosts - and it will stay the 
same right now.

Thanks,
Prachi
-Original Message-
From: Nitin Mehta [mailto:nitin.me...@citrix.com] 
Sent: Wednesday, April 17, 2013 11:55 PM
To: dev@cloudstack.apache.org
Subject: Re: [PROPOSAL] [CLOUDSTACK-2056] DeploymentPlanner choice via 
ServiceOffering

Prachi thanks for your responses. Makes it pretty clear.
Do we also put this in the disk offering as well for governing how the Data 
disks will be allocated ?

Hari's FS is @
https://cwiki.apache.org/confluence/display/CLOUDSTACK/FS+for+Granular+Glob
al+Configuration+Parameters. Just search for vm.allocation

Thanks,
-Nitin

On 18/04/13 12:16 AM, "Prachi Damle"  wrote:

>Hi Nitin,
>
>Thanks for the feedback. I have added comments inline.
>
>-Prachi
>
>-Original Message-
>From: Nitin Mehta [mailto:nitin.me...@citrix.com]
>Sent: Wednesday, April 17, 2013 1:42 AM
>To: dev@cloudstack.apache.org
>Subject: Re: [PROPOSAL] [CLOUDSTACK-2056] DeploymentPlanner choice via
>ServiceOffering
>
>Thanks for sharing this with the community Prachi. I read the wiki and
>had a few questions.
>
>Is there a requirement doc for this ? I wanted to understand the use
>cases for this.
>>>This is more of refactoring proposal in order to give more flexibility
>>>to the admin  around deployment decisions.
>>>The typical use-case will be when Admin wants to facilitate dispersion
>>>of VMs only for some accounts that need it while for any other accounts
>>>that do not care where their VMs land,  keep the deployment
>>>random/firstfit.
>>>Since currently planning choice is governed by the global config
>>>vm.allocation.algorithms, Admin cannot make use of the varied
>>>deployment heuristics per account needs.
>>>In the above case, if admin sets this config to 'userdispersion' then
>>>the UserDispersingPlanner gets selected for the entire CS deployment,
>>>across all accounts.
>
>>>Exposing the choice in ServiceOffering, also lets Admin take care of
>>>applying any custom pricing for say user-dispersion or
>>>user-concentrated Vs random/firstfit
>
>Since all the attributes are visible in service offering to the end user
>what is it we are trying to do here ? Give the flexibility to the end
>user ? Ideally it should give more flexibility to the admin right ?
>>> Right, Flexibility to the admin. This is not for end-user usage.
>
>You talked about the vm.allocation.algorithms but talking about the
>planners so I am little confused what is that we are trying to do here.
>>> This is the config that selects the planner currently. If we refactor
>>>the planner choice to ServiceOffering, we do not need this variable for
>>>choosing a planner
>>>We might have to keep this config around in order to provide the choice
>>>for host/pool allocation.
>
>I see that Hari also proposed changing vm allocation config to zone level.
>Is that required any more with this change ?
>>>I think so, at least not needed to choose a planner since we bring the
>>>planner choice to ServiceOffering level rather than Zone.
>>>Can you please point me to that Proposal? Thanks!
>
>I didn't understand "in a CS deployment multiple planners will have to
>co-exist." bit can you please elaborate with an example here ?
>>> After exposing the planners in Svc Offering, some offerings might
>>>choose 'FirstFitPlanner', while some other might choose
>>>'UserDispersingPlanner'.
>>>Thus all planners can get used in the same CS deployment - since the
>>>choice will no longer be global. All such planners will apply
>>>heuristics to the same set of resources - hence they might conflict.
>
>Thanks,
>-Nitin
>
>On 17/04/13 5:10 AM, "Prachi Damle"  wrote:
>
>>I would like to propose a new feature - DeploymentPlanner choice via
>>ServiceOffering
>>
>>Jira ticket created:
>>https://issues.apache.org/jira/browse/CLOUDSTACK-2056
>>
>>This is to expose the choice of Deployment Planner via Service Offering
>>and let Admin use a mix of Planners in a CS deployment.
>>
>>The initial draft of the FS is here
>>https://cwiki.apache.org/confluence/display/CLOUDSTACK/DeploymentPlanne
>>r+c
>>hoice+via+ServiceOffering
>>
>>Please review and comment.
>>
>>Thanks,
>>Prachi
>

RE: [PROPOSAL] [CLOUDSTACK-2056] DeploymentPlanner choice via ServiceOffering

[Prachi Damle]

On 18/04/13 11:01 AM, "Koushik Das"  wrote:

>I have some comments inline
>
>> -Original Message-
>> From: Prachi Damle [mailto:prachi.da...@citrix.com]
>> Sent: Thursday, April 18, 2013 12:17 AM
>> To: dev@cloudstack.apache.org
>> Subject: RE: [PROPOSAL] [CLOUDSTACK-2056] DeploymentPlanner choice 
>> via ServiceOffering
>> 
>> Hi Nitin,
>> 
>> Thanks for the feedback. I have added comments inline.
>> 
>> -Prachi
>> 
>> -Original Message-
>> From: Nitin Mehta [mailto:nitin.me...@citrix.com]
>> Sent: Wednesday, April 17, 2013 1:42 AM
>> To: dev@cloudstack.apache.org
>> Subject: Re: [PROPOSAL] [CLOUDSTACK-2056] DeploymentPlanner choice 
>> via ServiceOffering
>> 
>> Thanks for sharing this with the community Prachi. I read the wiki 
>>and had a  few questions.
>> 
>> Is there a requirement doc for this ? I wanted to understand the use 
>>cases  for this.
>> >>This is more of refactoring proposal in order to give more
>>flexibility to the
>> admin  around deployment decisions.
>> >>The typical use-case will be when Admin wants to facilitate
>>dispersion of
>> VMs only for some accounts that need it while for any other accounts 
>>that do  not care where their VMs land,  keep the deployment 
>>random/firstfit.
>> >>Since currently planning choice is governed by the global config
>> vm.allocation.algorithms, Admin cannot make use of the varied 
>> deployment heuristics per account needs.
>> >>In the above case, if admin sets this config to 'userdispersion' 
>> >>then
>>the
>> UserDispersingPlanner gets selected for the entire CS deployment, 
>>across all  accounts.
>> 
>> >>Exposing the choice in ServiceOffering, also lets Admin take care 
>> >>of applying any custom pricing for say user-dispersion or 
>> >>user-concentrated Vs random/firstfit
>> 
>
>[Koushik] Isn't all the different planning strategies best-effort? In 
>that case does it make sense to have custom pricing?
>Also since all the planners are active simultaneously on the same set 
>of resources it may result in some randomness. For e.g. if initially 
>the firstfit planner is used for allocation of VMs and say it consumes 
>50% of the total resources, after that if userdispersing planner is 
>used then it can only disperse VMs within the remaining 50%. Is it ok 
>from admin perspective to have this kind of randomness?


Its not best effort. It always applies the algo no matter what but yes the user 
might not get the desired results. Or do they both mean the same :).
We are guaranteeing him the algo but not making explicit promise that the users 
vm will never be say on the same host. The algo will always be applied is what 
we promise.
Example - there are 2 hosts each with 1 user vm and you say user dispersing 
planner then it doesn't make much sense using this does it - but he still pays 
premium :)

What would be great is say the vm is stopped and there is a 3rd host added 
during this time and then when its started back on the 3rd host.

[Prachi] Correct, the offering will guarantee that CS will apply the offered 
heuristic to choose resources in the 'available' set. 

>
>> Since all the attributes are visible in service offering to the end 
>>user what is it  we are trying to do here ? Give the flexibility to 
>>the end user ?
>>Ideally it
>> should give more flexibility to the admin right ?
>> >> Right, Flexibility to the admin. This is not for end-user usage.
>> 
>> You talked about the vm.allocation.algorithms but talking about the 
>>planners  so I am little confused what is that we are trying to do 
>>here.
>> >> This is the config that selects the planner currently. If we 
>> >>refactor the planner choice to ServiceOffering, we do not need this 
>> >>variable
>>for
>> choosing a planner We might have to keep this config around in order 
>>to  provide the choice for host/pool allocation.
>> 
>> I see that Hari also proposed changing vm allocation config to zone 
>>level.
>> Is that required any more with this change ?
>> >>I think so, at least not needed to choose a planner since we bring 
>> >>the
>> planner choice to ServiceOffering level rather than Zone.
>> >>Can you please point me to that Proposal? Thanks!
>> 
>> I didn't understand "in a CS deployment multiple planners will have 
>>to
>>co-
>> exist." bit can you please elaborate with an example here ?
>> >> After exposing the planners in Svc Offering, some offerings might
>>choose
>> 'FirstFitPlanner', while some other might choose 
>>'UserDispersingPlanner'.
>> >>Thus all planners can get used in the same CS deployment - since 
>> >>the
>> choice will no longer be global. All such planners will apply 
>>heuristics to the  same set of resources - hence they might conflict.
>> 
>> Thanks,
>> -Nitin
>> 
>> On 17/04/13 5:10 AM, "Prachi Damle"  wrote:
>> 
>> >I would like to propose a new feature - DeploymentPlanner choice via 
>> >ServiceOffering
>> >
>> >Jira ticket created:
>> >https://issues.apache.org/jira/browse/CLOUDSTACK-2056
>> >
>> >This is to expose the choi

Re: Review Request: CLOUDSTACK-2053: Fix bash if/else logic to avoid redundant entries in htaccess file, fixed boto/cloud-init support by adding metadata RewriteRules

[Chiradeep Vittal]

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


Is the fundamental problem that the data is available under /latest/metadata 
instead of /latest/meta-data ?



patches/systemvm/debian/config/root/userdata.sh


why is this needed? shouldn't the first rewrite rule be sufficient?



- Chiradeep Vittal


On April 18, 2013, 11:02 p.m., ilya musayev wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/10614/
> ---
> 
> (Updated April 18, 2013, 11:02 p.m.)
> 
> 
> Review request for cloudstack and Chiradeep Vittal.
> 
> 
> Description
> ---
> 
> Addressed 2 issues:
> Rewrote the bash if/else check to fix redundant entries
> Added RewriteRules to support boto/cloud-init - as per Chiradeep - this would 
> only affect VMWare deployments, as this userdata.sh script is only used with 
> vmware system router vms
> 
> 
> This addresses bug CLOUDSTACK-2053.
> 
> 
> Diffs
> -
> 
>   patches/systemvm/debian/config/root/userdata.sh e5d170b 
> 
> Diff: https://reviews.apache.org/r/10614/diff/
> 
> 
> Testing
> ---
> 
> ACS4.1
> 
> 
> Thanks,
> 
> ilya musayev
> 
>

RE: Review Request: CLOUDSTACK-2053: Fix bash if/else logic to avoid redundant entries in htaccess file, fixed boto/cloud-init support by adding metadata RewriteRules

[Musayev, Ilya]

Hi Chiradeep,

I've reposted the patch.

Thanks
ilya

> -Original Message-
> From: ilya musayev [mailto:nore...@reviews.apache.org] On Behalf Of ilya
> musayev
> Sent: Thursday, April 18, 2013 7:03 PM
> To: Chiradeep Vittal
> Cc: ilya musayev; cloudstack
> Subject: Review Request: CLOUDSTACK-2053: Fix bash if/else logic to avoid
> redundant entries in htaccess file, fixed boto/cloud-init support by adding
> metadata RewriteRules
> 
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/10614/
> ---
> 
> Review request for cloudstack and Chiradeep Vittal.
> 
> 
> Description
> ---
> 
> Addressed 2 issues:
> Rewrote the bash if/else check to fix redundant entries Added RewriteRules
> to support boto/cloud-init - as per Chiradeep - this would only affect
> VMWare deployments, as this userdata.sh script is only used with vmware
> system router vms
> 
> 
> This addresses bug CLOUDSTACK-2053.
> 
> 
> Diffs
> -
> 
>   patches/systemvm/debian/config/root/userdata.sh e5d170b
> 
> Diff: https://reviews.apache.org/r/10614/diff/
> 
> 
> Testing
> ---
> 
> ACS4.1
> 
> 
> Thanks,
> 
> ilya musayev

Review Request: CLOUDSTACK-2053: Fix bash if/else logic to avoid redundant entries in htaccess file, fixed boto/cloud-init support by adding metadata RewriteRules

[ilya musayev]

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

Review request for cloudstack and Chiradeep Vittal.


Description
---

Addressed 2 issues:
Rewrote the bash if/else check to fix redundant entries
Added RewriteRules to support boto/cloud-init - as per Chiradeep - this would 
only affect VMWare deployments, as this userdata.sh script is only used with 
vmware system router vms


This addresses bug CLOUDSTACK-2053.


Diffs
-

  patches/systemvm/debian/config/root/userdata.sh e5d170b 

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


Testing
---

ACS4.1


Thanks,

ilya musayev

Re: Could use a little DevCloud/Python help

[Ron Young]

Your message dated: Thu, 18 Apr 2013 16:30:56 -0600


Hi:

I ran across this same problem this morning...

I stumbled on the solution:   pip install requests

-ron

> 
> Hi,
> 
> Running the Python script to create a DevCloud environment in 4.1 works
> fine for me, but I get this error in 4.2:
> 
> mtutkowski-LT:devcloud mtutkowski$ python
> ../marvin/marvin/deployDataCenter.py -i devcloud.cfg
> Traceback (most recent call last):
>   File "../marvin/marvin/deployDataCenter.py", line 21, in 
> import cloudstackTestClient
>   File
> "/Users/mtutkowski/Documents/CloudStack/src/incubator-cloudstack/tools/marv=
> in/marvin/cloudstackTestClient.py",
> line 18, in 
> import cloudstackConnection
>   File "/Users/mtutkowski/Documents/CloudStack/src/incubator-cloudstack/too=
> ls/marvin/marvin/cloudstackConnection.py",
> line 18, in 
> import requests
> ImportError: No module named requests
> 
> I see this requests module is now being used (didn't seem like it was in
> 4.1).  Do I have to do something to make this module visible so this script
> will run again?
> 
> Thanks!
> 
> --=20
> *Mike Tutkowski*
> *Senior CloudStack Developer, SolidFire Inc.*
> e: mike.tutkow...@solidfire.com
> o: 303.746.7302
> Advancing the way the world uses the
> cloud
> *=99*
> 
> --f46d0444e835f9e6b704daaa271d--

===
Ron Young, Research Support Analyst
National Supercomputing Center for Energy and the Environment
4505 Maryland Parkway, Box 454028, Las Vegas, NV 89154-4028
v (702) 895-4017 / f (702) 895-4156 / email: ron.yo...@nscee.edu

Wizard to create cloud broken?

[Mike Tutkowski]

Hi,

Since the DevCloud script wasn't working for me, I decided to use the
wizard to create a cloud from scratch (using info in DevCloud's
devcloud.cfg file).

I think there is a problem with zone-wide versus cluster-wide storage?

Now building your cloud...
Creating primary storage

Something went wrong; you may go back and correct any errors:
invalid scopeundefined
What do you think?

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: Review Request: (CLOUDSTACK-1638) Network plugins won't be notified VM migration.

[Chiradeep Vittal]

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


Looks good.  Is this the final?

- Chiradeep Vittal


On April 11, 2013, 7:22 a.m., Hiroaki Kawai wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/9871/
> ---
> 
> (Updated April 11, 2013, 7:22 a.m.)
> 
> 
> Review request for cloudstack, Hugo Trippaers and Chiradeep Vittal.
> 
> 
> Description
> ---
> 
> The location of the virtual machine is provided by DeployDestination, which 
> will be passed in NetworkGuru#reserve and NetworkElement#prepare. 
> 
> During the virtual machine migration, it actually changes DeployDestination 
> and it looks like that it will tell that event to network components as it 
> has NetworkManager#prepareNicForMigration. The problem is that althogh the 
> interface has that method, NetworkManagerImpl does not tell the 
> DeployDestination changes to network components. 
> 
> So IMHO, we need to add calls of NetworkGuru#reserve and 
> NetworkElement#prepare in NetworkManagerImpl#prepareNicForMigration . And 
> then, we also need to add calls NetworkGuru#release and 
> NetworkElement#release after the migration, otherwise the network resources 
> that plugin reserved will be kept even when the vm leaves off.
> 
> Created a first minimum patch to show the concept.
> 
> 
> This addresses bug CLOUDSTACK-1638.
> 
> 
> Diffs
> -
> 
>   api/src/com/cloud/network/NetworkMigrationResponder.java PRE-CREATION 
>   server/src/com/cloud/network/NetworkManager.java 4124b19 
>   server/src/com/cloud/network/NetworkManagerImpl.java a98bdd4 
>   server/src/com/cloud/vm/VirtualMachineManagerImpl.java 9230f4a 
> 
> Diff: https://reviews.apache.org/r/9871/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Hiroaki Kawai
> 
>

Could use a little DevCloud/Python help

[Mike Tutkowski]

Hi,

Running the Python script to create a DevCloud environment in 4.1 works
fine for me, but I get this error in 4.2:

mtutkowski-LT:devcloud mtutkowski$ python
../marvin/marvin/deployDataCenter.py -i devcloud.cfg
Traceback (most recent call last):
  File "../marvin/marvin/deployDataCenter.py", line 21, in 
import cloudstackTestClient
  File
"/Users/mtutkowski/Documents/CloudStack/src/incubator-cloudstack/tools/marvin/marvin/cloudstackTestClient.py",
line 18, in 
import cloudstackConnection
  File 
"/Users/mtutkowski/Documents/CloudStack/src/incubator-cloudstack/tools/marvin/marvin/cloudstackConnection.py",
line 18, in 
import requests
ImportError: No module named requests

I see this requests module is now being used (didn't seem like it was in
4.1).  Do I have to do something to make this module visible so this script
will run again?

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: Supported Source NAT Type?

[Will Stevens]

Great.  Thanks again, this is very helpful.

So the way I am doing it is good for now.  If IP space becomes an issue
(when people are actually using it), I could implement the 'per zone'
approach as well.

In the per zone approach, the firewall would be initially configured with a
public IP and a generic source nat rule which would map the entire guest
network range in the trusted zone to the preconfigured public IP in the
untrusted zone.  I understand how this works now and why the source nat
rules will not need to be managed by cloudstack.

Thanks again for the explanation.


On Thu, Apr 18, 2013 at 6:12 PM, Sheng Yang  wrote:

> Hi Will,
>
> "per account" is perfectly fine in your case. "per zone" can be used if
> user want to preserve some public IPs. And with "per zone", CloudStack just
> won't care about source nat ip allocation etc any more, it would assume
> that the firewall should already has taken care of that. Source NAT IP
> would be blank in Cloudstack(a.k.a. isolated network without source nat
> ip).
>
> It's not requirement to support "per zone". In fact as long as your device
> can support of the source nat mechanism then it's fine. But I don't think
> you need to handle source nat rules if you use "per zone" mode(from CS's
> perspective). E.g. Juniper SRX has such a configuration:
>
> nat {
> source {
> pool inat-pool {
> address {
> 10.223.161.18/32;
> }
> }
> rule-set trust {
> from zone trust;
> to zone untrust;
> rule i-nat {
> match {
> source-address 10.0.0.0/8;
> }
> then {
> source-nat {
> pool {
> inat-pool;
> }
> }
> }
> }
> }
> }
> }
>
> This one would fit all traffic from "trust" zone(every newly created
> isolated network would be in trust zone) to "untrust" zone(public network),
> using source nat.
>
> --Sheng
>
> On Thu, Apr 18, 2013 at 2:50 PM, Will Stevens 
> wrote:
>
> > Thanks for the answer Sheng.
> >
> > I currently have the Palo Alto firewall using the 'per account' method
> and
> > when 'IpAssocCommand' is run (when the first VM is added to a palo alto
> > network ), I am dynamically creating a public sub-interface and
> assigning a
> > public IP (provided by cloudstack).  I am also creating a private
> > sub-interface on the PA which I am using the the gateway for the CS
> > network.  I am dynamically creating/deleting the SourceNat rules between
> > the two sub-interfaces (gateway/cidr# -> public_ip/32) on implement and
> > shutdown.
> >
> > In your eyes, is this the best way to handle this?  If I was to use the
> > 'per zone' option, how would the Source Nat IP get set in Cloudstack?  So
> > there would be one public IP per zone which all the public traffic would
> go
> > through for all networks?  I would still have to handle the source nat
> > rules from each CS network to that single public IP I believe.
> >
> > I am slowly getting this all documented at:
> >
> >
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Palo+Alto+Firewall+Integration
> >
> > Thanks...
> >
> >
> > On Thu, Apr 18, 2013 at 5:19 PM, Sheng Yang  wrote:
> >
> > > Hi Will,
> > >
> > > "Per zone" is mostly for external network devices(e.g. SRX). We can
> > > configure one public network address on SRX, and use that one(which is
> > out
> > > of Cloudstack's control) for all the public traffic go through the
> > device.
> > > That's "Per zone".
> > >
> > > "Per account" is the other way, used by VR in CloudStack. It would
> > acquire
> > > one public ip from public ip pool in the zone for each isolated
> network,
> > > and make it source nat IP for the network. The name "per account"
> because
> > > in the past one user would have only one isolated network, so the
> network
> > > is de facto per account. It's not necessary true now, but the name
> > remained
> > > I think.
> > >
> > > There are probably bad names, we should get better name than them...
> > >
> > > --Sheng
> > >
> > >
> > > On Thu, Apr 18, 2013 at 2:07 PM, Will Stevens 
> > > wrote:
> > >
> > > > Oh, my bad.  I forgot about that.
> > > >
> > > > On the 'create network service offering' overlay, if you select
> > > 'SourceNat'
> > > > in Supported Services, there is a drop down which get added.  The
> drop
> > > down
> > > > has the title of 'Supported Source Nat Type' and has two options:
> 'Per
> > > > zone' and 'Per account'
> > > >
> > > > Thanks,
> > > >
> > > > Will
> > > >
> > > >
> > > > On Thu, Apr 18, 2013 at 4:09 PM, Chip Childers <
> > > chip.child...@sungard.com
> > > > >wrote:
> > > >
> > > > > Will,
> > > > >
> > > > > Images and other attachments are stripped on this list (text only
> >

RE: [ASFCS42] Proposed schedule for our next release

[Will Chan]

> -Original Message-
> From: Chip Childers [mailto:chip.child...@sungard.com]
> Sent: Monday, April 15, 2013 7:22 AM
> To: dev@cloudstack.apache.org
> Cc: cloudstack-...@incubator.apache.org
> Subject: Re: [ASFCS42] Proposed schedule for our next release
> 
> On Thu, Apr 11, 2013 at 02:50:02PM -0700, Animesh Chaturvedi wrote:
> >
> > I want to call out my concern on technical debt we have accumulated so
> far.
> >
> >  I did an analysis on JIRA bugs yesterday night PST on "Affects
> > Version = 4.1" and created since Dec 2012
> >
> > Total records : 429
> > Resolution Type (Invalid, Duplicate, Cannot reproduce etc.) : 87 (30
> > Blockers, 27 Critical, 27 Major, 4 Minor) Valid Defects  : 429-87= 342
> > Fixed : 246 (60 Blockers, 70 Critical, 99 Majors) out of which 217
> > were fixed since Feb Unresolved : 96 (1 Blocker, 8 Critical, 64 Major)
> >
> > With this data it looks like we have fixed 2/3 of valid defects in little 
> > over
> 2 months and pretty much deferring around 1/3 rd of issues for future
> release.
> >
> > I also looked at overall backlog of bugs (Critical, Major and Blockers only)
> as of 4/10/2013 - 10:0PM PST.
> >
> > 284 open (18 Blocker, 38 Critical, 228 Major) ; By Fix version
> > -  Release 4.0.x and prior: 13
> > -  4.1: 70
> > -  4.2 : 97
> > -  Future: 8
> > -  No version: 107
> >
> > Looking at that we fixed 217 bugs in roughly 2 months during 4.1 cycle,
> fixing the backlog of bug  will probably take us 2 months.  Should we extend
> the 4.2 test cycle by 2 months [Original Schedule: 6/1 - 7/22, Extended
> Schedule: 6/1-9/22] to reduce the technical debt significantly? I would like
> to hear how community wants to address technical debt. Based on the
> input and consensus I will publish the agreed schedule next week.
> >
> >
> 
> I don't think that an extension of time changes bug counts really.  IMO, we
> need to pull together to have some bug-fix focused effort applied to the
> code-base.  It's also another reason that I'm so big on making sure that
> automated tests come in with the new features.  That doesn't address test
> scenarios that human testers can come up with, but if a developer spends
> the time to think about testing the basic feature and codifies that, we
> should at least avoid the "this actually doesn't work at all" types of bugs.
> 
> There's a school of thought that says, don't build another feature until you
> have sorted out the known bugs in the current features.  I don't think we
> could really pull that off, but perhaps a different thread to rally people
> around the bug backlog is in order?
> 
> -chip

Sorry to chime in so late to this thread as I've been offsite for the better 
part of this week.  I was one of the original 4 month release crowd but after 
the recent two releases of ACS, I'm starting to wonder if we shouldn't start 
moving this to a 6 month cycle instead of two.  Here are some high level 
observations based on the previous two releases:

1. It doesn't seem like we are on a true 4 month time based release schedule.  
Both 4.0 and 4.1 were delayed more than several weeks past the original 
proposed GA date.  4.0 was released 11/6 and let's assume that 4.1 will ship 
within a week or two.  That's almost a 6 month release cycle.  Every release 
incurs a fixed cost of release notes, upgrade testing, etc. that I suspect at 
least eats a month worth of time depending on people's schedule.  That's 3 
months out of the year rather than two if we can get a 6 months cycle.  We can 
use that extra month for other purposes if need be.  I suppose if we want to 
continue to release past the proposed hard GA date, then I guess it doesn't 
matter if it's 4 or 6 months.  It's basically a release when the release mgmt. 
team feels it's right to release based on current bugs, etc.

2. As more and more features/development go in, it just means more 
destabilization of the code.  4.0 was delayed and the majority of that work was 
licensing files.  4.1 got just a bit more complicated with new feature 
development and the delay is now much longer.  Not all features are created 
equal in terms of testing.  Some may require more time to develop but may not 
impact the entire system like for example, adding a new hypervisor.  However, 
work like refactoring vm sync or other more internal code could affect the 
entire stack and require more QA time.  We need extra time for new code to 
settle in.

3. ACS is still dependent largely on manual QA.  Let's face it, our automated 
testing/unit testing isn't mature enough quite yet and we cannot always expect 
manual QA to be there and on ACS schedule.  CloudStack releases have some type 
of quality expectations as well as support for upgrades.  Upgrades and 
migration scripts aren't that easily automatable.  Chip and others have been 
very diligent on ensuring that code check in has the appropriate tests but it's 
not there yet.  

4. ACS development is based on volunteer work and many of us h

Ifocnfig - Question.

[Maurice Lawler]

Hello -- Previously it was told to me that this cloud0 being first in ifconfig is and would cause an issue, is this the case; as anyone had issues. Seems as though eth0 is passing most traffic, where as previously it was cloud0. Unsure if this is the case, or an issue.- Mauricecloud0    Link encap:Ethernet  HWaddr FE:00:A9:FE:00:6E    inet addr:169.254.0.1  Bcast:169.254.255.255  Mask:255.255.0.0  inet6 addr: fe80::78e1:9cff:fe8f:b4ce/64 Scope:Link  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1  RX packets:4773 errors:0 dropped:0 overruns:0 frame:0  TX packets:4926 errors:0 dropped:0 overruns:0 carrier:0  collisions:0 txqueuelen:0   RX bytes:826161 (806.7 KiB)  TX bytes:924710 (903.0 KiB)cloudbr0  Link encap:Ethernet  HWaddr C8:0A:A9:9E:2D:7C    inet addr:MYIPADDRESS  Bcast:MYBCASTIP  Mask:255.255.255.224  inet6 addr: ipv6ip Scope:Link  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1  RX packets:3294154 errors:0 dropped:0 overruns:0 frame:0  TX packets:2603043 errors:0 dropped:0 overruns:0 carrier:0  collisions:0 txqueuelen:0   RX bytes:3403672766 (3.1 GiB)  TX bytes:6436244592 (5.9 GiB)eth0  Link encap:Ethernet  HWaddr C8:0A:A9:9E:2D:7C    inet6 addr: fe80::ca0a:a9ff:fe9e:2d7c/64 Scope:Link  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1  RX packets:8295350 errors:0 dropped:0 overruns:0 frame:0  TX packets:3563786 errors:0 dropped:0 overruns:0 carrier:0  collisions:0 txqueuelen:1000   RX bytes:11653818769 (10.8 GiB)  TX bytes:274441470 (261.7 MiB)  Memory:df6e-df70 

Re: Supported Source NAT Type?

[Sheng Yang]

Hi Will,

"per account" is perfectly fine in your case. "per zone" can be used if
user want to preserve some public IPs. And with "per zone", CloudStack just
won't care about source nat ip allocation etc any more, it would assume
that the firewall should already has taken care of that. Source NAT IP
would be blank in Cloudstack(a.k.a. isolated network without source nat ip).

It's not requirement to support "per zone". In fact as long as your device
can support of the source nat mechanism then it's fine. But I don't think
you need to handle source nat rules if you use "per zone" mode(from CS's
perspective). E.g. Juniper SRX has such a configuration:

nat {
source {
pool inat-pool {
address {
10.223.161.18/32;
}
}
rule-set trust {
from zone trust;
to zone untrust;
rule i-nat {
match {
source-address 10.0.0.0/8;
}
then {
source-nat {
pool {
inat-pool;
}
}
}
}
}
}
}

This one would fit all traffic from "trust" zone(every newly created
isolated network would be in trust zone) to "untrust" zone(public network),
using source nat.

--Sheng

On Thu, Apr 18, 2013 at 2:50 PM, Will Stevens  wrote:

> Thanks for the answer Sheng.
>
> I currently have the Palo Alto firewall using the 'per account' method and
> when 'IpAssocCommand' is run (when the first VM is added to a palo alto
> network ), I am dynamically creating a public sub-interface and assigning a
> public IP (provided by cloudstack).  I am also creating a private
> sub-interface on the PA which I am using the the gateway for the CS
> network.  I am dynamically creating/deleting the SourceNat rules between
> the two sub-interfaces (gateway/cidr# -> public_ip/32) on implement and
> shutdown.
>
> In your eyes, is this the best way to handle this?  If I was to use the
> 'per zone' option, how would the Source Nat IP get set in Cloudstack?  So
> there would be one public IP per zone which all the public traffic would go
> through for all networks?  I would still have to handle the source nat
> rules from each CS network to that single public IP I believe.
>
> I am slowly getting this all documented at:
>
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Palo+Alto+Firewall+Integration
>
> Thanks...
>
>
> On Thu, Apr 18, 2013 at 5:19 PM, Sheng Yang  wrote:
>
> > Hi Will,
> >
> > "Per zone" is mostly for external network devices(e.g. SRX). We can
> > configure one public network address on SRX, and use that one(which is
> out
> > of Cloudstack's control) for all the public traffic go through the
> device.
> > That's "Per zone".
> >
> > "Per account" is the other way, used by VR in CloudStack. It would
> acquire
> > one public ip from public ip pool in the zone for each isolated network,
> > and make it source nat IP for the network. The name "per account" because
> > in the past one user would have only one isolated network, so the network
> > is de facto per account. It's not necessary true now, but the name
> remained
> > I think.
> >
> > There are probably bad names, we should get better name than them...
> >
> > --Sheng
> >
> >
> > On Thu, Apr 18, 2013 at 2:07 PM, Will Stevens 
> > wrote:
> >
> > > Oh, my bad.  I forgot about that.
> > >
> > > On the 'create network service offering' overlay, if you select
> > 'SourceNat'
> > > in Supported Services, there is a drop down which get added.  The drop
> > down
> > > has the title of 'Supported Source Nat Type' and has two options: 'Per
> > > zone' and 'Per account'
> > >
> > > Thanks,
> > >
> > > Will
> > >
> > >
> > > On Thu, Apr 18, 2013 at 4:09 PM, Chip Childers <
> > chip.child...@sungard.com
> > > >wrote:
> > >
> > > > Will,
> > > >
> > > > Images and other attachments are stripped on this list (text only
> > > > please!)
> > > >
> > > > Can you post the image somewhere or describe the list?
> > > >
> > > > On Thu, Apr 18, 2013 at 04:05:36PM -0400, Will Stevens wrote:
> > > > > In the 'Create network service offering' flow there is this
> dropdown:
> > > > >
> > > > > [image: Inline image 1]
> > > > >
> > > > > What are the implications for picking one or the other?
> > > > >
> > > > > This code seems related in
> > > > >
> > > >
> > >
> >
> 'com.cloud.network.ExternalFirewallDeviceManagerImpl.manageGuestNetworkWithExternalFirewall()'
> > > > > :
> > > > > NetworkOffering offering =
> > > > > _networkOfferingDao.findById(network.getNetworkOfferingId());
> > > > > boolean sharedSourceNat = offering.getSharedSourceNat();
> > > > >
> > > > > IPAddressVO sourceNatIp = null;
> > > > > if (!sharedSourceNat) {
> > > > > // Get the source NAT IP address for this account
> > > > > List

RE: qa tests for nicira code in 4.1

[Rayees Namathponnan]

Hi Daan,

These test cases are in ASF repo ?

Regards,
Rayees 

-Original Message-
From: Daan Hoogland [mailto:dhoogl...@schubergphilis.com] 
Sent: Thursday, April 18, 2013 12:38 PM
To: dev@cloudstack.apache.org
Subject: qa tests for nicira code in 4.1

LS,

At Schuberg Philis we did some tests on the 4.1 code for the tests in the 
following table
Test Case ID  Test Description Results
   Infrastructure
NVP-001 Create NVP Element pass
NVP-002 Disable NVP Elementpass
NVP-003 Enable NVP Element pass
NVP-004 Delete NVP Element  pass
NVP-005 Create NVP Device   pass
NVP-006 Delete NVP Devicepass
   L2 Functions
NVP-101 Create Logical Switchpass
NVP-102 Create Logical Portpass
NVP-103 Check Connection Pass
NVP-104 Check Connection Pass
NVP-105 Delete Logical SwitchPass
NVP-106 Delete Logical Port Pass
   L3 Functions
NVP-201 Create Logical RouterPass
NVP-202 Create Source Nat rule  Pass
NVP-203 Create Static Nat rulePass
NVP-204 Create Port FW rule   Pass
NVP-205 Check Source Nat rule  Pass
NVP-206 Check Static Nat rule Pass
NVP-207 Check Port FW rule   Pass
NVP-208 Delete Source Nat rule  Pass
NVP-209 Delete Static Nat rule Fail
NVP-210 Delete Port FW rule   Pass
NVP-211 Delete Logical RouterPass

The tests where partly done aith scripts but these are not yet complete and the 
remainder of functionality was done by hand.
For the failed test, NVP-209 a ticket was created, 'CLOUDSTACK-2092'. The 
problem in this case was that deleting the static rule did not result in the 
deletion of the ip adres from the logical router.

Kind regards,
Daan Hoogland

Re: DevCloud

[Mike Tutkowski]

I tried

port install py27-requests

(MacPorts), but it didn't change the behavior of running

python ../marvin/marvin/deployDataCenter.py -i devcloud.cfg

Still claims to be unable to find the requests module (for CS 4.2).


On Thu, Apr 18, 2013 at 3:45 PM, Mike Tutkowski <
mike.tutkow...@solidfire.com> wrote:

> Perhaps I'm using the wrong version of Python?  I'm on 2.7.
>
>
> On Thu, Apr 18, 2013 at 11:59 AM, Mike Tutkowski <
> mike.tutkow...@solidfire.com> wrote:
>
>> I have a related issue.  I sent it out under a different thread, but
>> should put it here, too.
>>
>> This is my issue.  I'm not sure how to get around it.  Thanks!!
>>
>> mtutkowski-LT:devcloud mtutkowski$ python
>> ../marvin/marvin/deployDataCenter.py -i devcloud.cfg
>> Traceback (most recent call last):
>>   File "../marvin/marvin/deployDataCenter.py", line 21, in 
>> import cloudstackTestClient
>>   File
>> "/Users/mtutkowski/Documents/CloudStack/src/incubator-cloudstack/tools/marvin/marvin/cloudstackTestClient.py",
>> line 18, in 
>> import cloudstackConnection
>>   File
>> "/Users/mtutkowski/Documents/CloudStack/src/incubator-cloudstack/tools/marvin/marvin/cloudstackConnection.py",
>> line 18, in 
>> import requests
>> ImportError: No module named requests
>>
>>
>> On Thu, Apr 18, 2013 at 11:51 AM, Rohit Yadav wrote:
>>
>>> On Thu, Apr 18, 2013 at 10:17 PM, Aaron Paradowski
>>> wrote:
>>>
>>> > Hi Rohit,
>>> >
>>> > ** **
>>> >
>>> > I’m having some problems deploying DevCloud2 and wonder if you could
>>> help
>>> > please. So far I have done the following
>>> >
>>> > ** **
>>> >
>>> > **1.   **Downloaded and imported the DevCloud2 image into
>>> VirtualBox
>>> > – ensured network settings were correct etc.
>>> >
>>> > **2.   **Used PuTTY to SSH to the machine at 192.168.56.10 and
>>> logged
>>> > in with root and password for username and password
>>> >
>>> > **3.   **cd to /opt/cloudstack
>>> >
>>> > **4.   **git cloned into the source code for incubator
>>> cloudstack
>>> >
>>> > **5.   **once that had completed I cd’d to the incubator-cloudstack
>>> > directory
>>> >
>>> > **6.   **Ran mvn clean install –P developer,systemvm
>>> >
>>> > **7.   **Changedthe host value in devcloud.sql to 192.168.56.10 as
>>> I
>>> > want everything to run inside this one VM
>>> >
>>> > **8.   **Ran mvn –pl developer,tools/devloud –Deploydb –P developer
>>> >
>>>
>>> Hi Aaron,
>>>
>>> The best way is to reach to the whole community and cc any particular
>>> person whose attention you may be seeking.
>>>
>>> 1-8: So far so good, ignoring the -Ddeploydb typo.
>>>
>>>
>>> > 
>>> >
>>> > 9.   Then ran mvn-pl client jetty:run and this is where everything
>>> > goes wrong. It hangs on the below screen for ages then it goes through
>>> lots
>>> > of warnings and errors such as “WARN [apache.cloudstack.alerts] (HA-3:)
>>> > alertType:: 13” – I left it for 19 hours overnight last night and those
>>> > types of errors just kept going round in cycles?
>>> >
>>> Looks like CloudStack issue? Did you try exporting maven opts, checkout
>>> the
>>> building on master on cwiki.apache.org / cloudstack and try again?
>>>
>>> If you're just able to login inside DevCloud2 and run something like xe
>>> vm-list and it outputs something we're good at least from DevCloud's
>>> side :)
>>>
>>> Anyone from community?
>>>
>>> Cheers.
>>>
>>>
>>> > 
>>> >
>>> > 
>>> >
>>> > ** **
>>> >
>>> > Any help would be greatly appreciated! Many thanks in advance.
>>> >
>>> > ** **
>>> >
>>> > Kind Regards,
>>> >
>>> > ** **
>>> >
>>> > *Aaron Paradowski*
>>> >
>>> > ** **
>>> >
>>>
>>
>>
>>
>> --
>> *Mike Tutkowski*
>>  *Senior CloudStack Developer, SolidFire Inc.*
>> e: mike.tutkow...@solidfire.com
>> o: 303.746.7302
>> Advancing the way the world uses the 
>> cloud
>> *™*
>>
>
>
>
> --
> *Mike Tutkowski*
> *Senior CloudStack Developer, SolidFire Inc.*
> e: mike.tutkow...@solidfire.com
> o: 303.746.7302
> Advancing the way the world uses the 
> cloud
> *™*
>



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

Re: Supported Source NAT Type?

[Will Stevens]

Thanks for the answer Sheng.

I currently have the Palo Alto firewall using the 'per account' method and
when 'IpAssocCommand' is run (when the first VM is added to a palo alto
network ), I am dynamically creating a public sub-interface and assigning a
public IP (provided by cloudstack).  I am also creating a private
sub-interface on the PA which I am using the the gateway for the CS
network.  I am dynamically creating/deleting the SourceNat rules between
the two sub-interfaces (gateway/cidr# -> public_ip/32) on implement and
shutdown.

In your eyes, is this the best way to handle this?  If I was to use the
'per zone' option, how would the Source Nat IP get set in Cloudstack?  So
there would be one public IP per zone which all the public traffic would go
through for all networks?  I would still have to handle the source nat
rules from each CS network to that single public IP I believe.

I am slowly getting this all documented at:
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Palo+Alto+Firewall+Integration

Thanks...


On Thu, Apr 18, 2013 at 5:19 PM, Sheng Yang  wrote:

> Hi Will,
>
> "Per zone" is mostly for external network devices(e.g. SRX). We can
> configure one public network address on SRX, and use that one(which is out
> of Cloudstack's control) for all the public traffic go through the device.
> That's "Per zone".
>
> "Per account" is the other way, used by VR in CloudStack. It would acquire
> one public ip from public ip pool in the zone for each isolated network,
> and make it source nat IP for the network. The name "per account" because
> in the past one user would have only one isolated network, so the network
> is de facto per account. It's not necessary true now, but the name remained
> I think.
>
> There are probably bad names, we should get better name than them...
>
> --Sheng
>
>
> On Thu, Apr 18, 2013 at 2:07 PM, Will Stevens 
> wrote:
>
> > Oh, my bad.  I forgot about that.
> >
> > On the 'create network service offering' overlay, if you select
> 'SourceNat'
> > in Supported Services, there is a drop down which get added.  The drop
> down
> > has the title of 'Supported Source Nat Type' and has two options: 'Per
> > zone' and 'Per account'
> >
> > Thanks,
> >
> > Will
> >
> >
> > On Thu, Apr 18, 2013 at 4:09 PM, Chip Childers <
> chip.child...@sungard.com
> > >wrote:
> >
> > > Will,
> > >
> > > Images and other attachments are stripped on this list (text only
> > > please!)
> > >
> > > Can you post the image somewhere or describe the list?
> > >
> > > On Thu, Apr 18, 2013 at 04:05:36PM -0400, Will Stevens wrote:
> > > > In the 'Create network service offering' flow there is this dropdown:
> > > >
> > > > [image: Inline image 1]
> > > >
> > > > What are the implications for picking one or the other?
> > > >
> > > > This code seems related in
> > > >
> > >
> >
> 'com.cloud.network.ExternalFirewallDeviceManagerImpl.manageGuestNetworkWithExternalFirewall()'
> > > > :
> > > > NetworkOffering offering =
> > > > _networkOfferingDao.findById(network.getNetworkOfferingId());
> > > > boolean sharedSourceNat = offering.getSharedSourceNat();
> > > >
> > > > IPAddressVO sourceNatIp = null;
> > > > if (!sharedSourceNat) {
> > > > // Get the source NAT IP address for this account
> > > > List sourceNatIps =
> > > > _networkMgr.listPublicIpsAssignedToAccount(network.getAccountId(),
> > > > zoneId, true);
> > > >
> > > > if (sourceNatIps.size() != 1) {
> > > > String errorMsg = "External firewall was unable to find the
> > > source
> > > > NAT IP address for account "
> > > > + account.getAccountName();
> > > > s_logger.error(errorMsg);
> > > > return true;
> > > > } else {
> > > > sourceNatIp =
> > > _ipAddressDao.findById(sourceNatIps.get(0).getId());
> > > > }
> > > > }
> > > >
> > > > How does the 'sourceNatIp' get set if 'sharedSourceNat' is true?
> > > >
> > > > Thanks,
> > > >
> > > > Will
> > >
> > >
> >
>

Re: DevCloud

[Mike Tutkowski]

Perhaps I'm using the wrong version of Python?  I'm on 2.7.


On Thu, Apr 18, 2013 at 11:59 AM, Mike Tutkowski <
mike.tutkow...@solidfire.com> wrote:

> I have a related issue.  I sent it out under a different thread, but
> should put it here, too.
>
> This is my issue.  I'm not sure how to get around it.  Thanks!!
>
> mtutkowski-LT:devcloud mtutkowski$ python
> ../marvin/marvin/deployDataCenter.py -i devcloud.cfg
> Traceback (most recent call last):
>   File "../marvin/marvin/deployDataCenter.py", line 21, in 
> import cloudstackTestClient
>   File
> "/Users/mtutkowski/Documents/CloudStack/src/incubator-cloudstack/tools/marvin/marvin/cloudstackTestClient.py",
> line 18, in 
> import cloudstackConnection
>   File
> "/Users/mtutkowski/Documents/CloudStack/src/incubator-cloudstack/tools/marvin/marvin/cloudstackConnection.py",
> line 18, in 
> import requests
> ImportError: No module named requests
>
>
> On Thu, Apr 18, 2013 at 11:51 AM, Rohit Yadav  wrote:
>
>> On Thu, Apr 18, 2013 at 10:17 PM, Aaron Paradowski
>> wrote:
>>
>> > Hi Rohit,
>> >
>> > ** **
>> >
>> > I’m having some problems deploying DevCloud2 and wonder if you could
>> help
>> > please. So far I have done the following
>> >
>> > ** **
>> >
>> > **1.   **Downloaded and imported the DevCloud2 image into VirtualBox
>> > – ensured network settings were correct etc.
>> >
>> > **2.   **Used PuTTY to SSH to the machine at 192.168.56.10 and
>> logged
>> > in with root and password for username and password
>> >
>> > **3.   **cd to /opt/cloudstack
>> >
>> > **4.   **git cloned into the source code for incubator
>> cloudstack
>> >
>> > **5.   **once that had completed I cd’d to the incubator-cloudstack
>> > directory
>> >
>> > **6.   **Ran mvn clean install –P developer,systemvm
>> >
>> > **7.   **Changedthe host value in devcloud.sql to 192.168.56.10 as I
>> > want everything to run inside this one VM
>> >
>> > **8.   **Ran mvn –pl developer,tools/devloud –Deploydb –P developer
>> >
>>
>> Hi Aaron,
>>
>> The best way is to reach to the whole community and cc any particular
>> person whose attention you may be seeking.
>>
>> 1-8: So far so good, ignoring the -Ddeploydb typo.
>>
>>
>> > 
>> >
>> > 9.   Then ran mvn-pl client jetty:run and this is where everything
>> > goes wrong. It hangs on the below screen for ages then it goes through
>> lots
>> > of warnings and errors such as “WARN [apache.cloudstack.alerts] (HA-3:)
>> > alertType:: 13” – I left it for 19 hours overnight last night and those
>> > types of errors just kept going round in cycles?
>> >
>> Looks like CloudStack issue? Did you try exporting maven opts, checkout
>> the
>> building on master on cwiki.apache.org / cloudstack and try again?
>>
>> If you're just able to login inside DevCloud2 and run something like xe
>> vm-list and it outputs something we're good at least from DevCloud's side
>> :)
>>
>> Anyone from community?
>>
>> Cheers.
>>
>>
>> > 
>> >
>> > 
>> >
>> > ** **
>> >
>> > Any help would be greatly appreciated! Many thanks in advance.
>> >
>> > ** **
>> >
>> > Kind Regards,
>> >
>> > ** **
>> >
>> > *Aaron Paradowski*
>> >
>> > ** **
>> >
>>
>
>
>
> --
> *Mike Tutkowski*
> *Senior CloudStack Developer, SolidFire Inc.*
> e: mike.tutkow...@solidfire.com
> o: 303.746.7302
> Advancing the way the world uses the 
> cloud
> *™*
>



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

Re: Supported Source NAT Type?

[Sheng Yang]

Hi Will,

"Per zone" is mostly for external network devices(e.g. SRX). We can
configure one public network address on SRX, and use that one(which is out
of Cloudstack's control) for all the public traffic go through the device.
That's "Per zone".

"Per account" is the other way, used by VR in CloudStack. It would acquire
one public ip from public ip pool in the zone for each isolated network,
and make it source nat IP for the network. The name "per account" because
in the past one user would have only one isolated network, so the network
is de facto per account. It's not necessary true now, but the name remained
I think.

There are probably bad names, we should get better name than them...

--Sheng


On Thu, Apr 18, 2013 at 2:07 PM, Will Stevens  wrote:

> Oh, my bad.  I forgot about that.
>
> On the 'create network service offering' overlay, if you select 'SourceNat'
> in Supported Services, there is a drop down which get added.  The drop down
> has the title of 'Supported Source Nat Type' and has two options: 'Per
> zone' and 'Per account'
>
> Thanks,
>
> Will
>
>
> On Thu, Apr 18, 2013 at 4:09 PM, Chip Childers  >wrote:
>
> > Will,
> >
> > Images and other attachments are stripped on this list (text only
> > please!)
> >
> > Can you post the image somewhere or describe the list?
> >
> > On Thu, Apr 18, 2013 at 04:05:36PM -0400, Will Stevens wrote:
> > > In the 'Create network service offering' flow there is this dropdown:
> > >
> > > [image: Inline image 1]
> > >
> > > What are the implications for picking one or the other?
> > >
> > > This code seems related in
> > >
> >
> 'com.cloud.network.ExternalFirewallDeviceManagerImpl.manageGuestNetworkWithExternalFirewall()'
> > > :
> > > NetworkOffering offering =
> > > _networkOfferingDao.findById(network.getNetworkOfferingId());
> > > boolean sharedSourceNat = offering.getSharedSourceNat();
> > >
> > > IPAddressVO sourceNatIp = null;
> > > if (!sharedSourceNat) {
> > > // Get the source NAT IP address for this account
> > > List sourceNatIps =
> > > _networkMgr.listPublicIpsAssignedToAccount(network.getAccountId(),
> > > zoneId, true);
> > >
> > > if (sourceNatIps.size() != 1) {
> > > String errorMsg = "External firewall was unable to find the
> > source
> > > NAT IP address for account "
> > > + account.getAccountName();
> > > s_logger.error(errorMsg);
> > > return true;
> > > } else {
> > > sourceNatIp =
> > _ipAddressDao.findById(sourceNatIps.get(0).getId());
> > > }
> > > }
> > >
> > > How does the 'sourceNatIp' get set if 'sharedSourceNat' is true?
> > >
> > > Thanks,
> > >
> > > Will
> >
> >
>

Re: Supported Source NAT Type?

[Will Stevens]

Oh, my bad.  I forgot about that.

On the 'create network service offering' overlay, if you select 'SourceNat'
in Supported Services, there is a drop down which get added.  The drop down
has the title of 'Supported Source Nat Type' and has two options: 'Per
zone' and 'Per account'

Thanks,

Will


On Thu, Apr 18, 2013 at 4:09 PM, Chip Childers wrote:

> Will,
>
> Images and other attachments are stripped on this list (text only
> please!)
>
> Can you post the image somewhere or describe the list?
>
> On Thu, Apr 18, 2013 at 04:05:36PM -0400, Will Stevens wrote:
> > In the 'Create network service offering' flow there is this dropdown:
> >
> > [image: Inline image 1]
> >
> > What are the implications for picking one or the other?
> >
> > This code seems related in
> >
> 'com.cloud.network.ExternalFirewallDeviceManagerImpl.manageGuestNetworkWithExternalFirewall()'
> > :
> > NetworkOffering offering =
> > _networkOfferingDao.findById(network.getNetworkOfferingId());
> > boolean sharedSourceNat = offering.getSharedSourceNat();
> >
> > IPAddressVO sourceNatIp = null;
> > if (!sharedSourceNat) {
> > // Get the source NAT IP address for this account
> > List sourceNatIps =
> > _networkMgr.listPublicIpsAssignedToAccount(network.getAccountId(),
> > zoneId, true);
> >
> > if (sourceNatIps.size() != 1) {
> > String errorMsg = "External firewall was unable to find the
> source
> > NAT IP address for account "
> > + account.getAccountName();
> > s_logger.error(errorMsg);
> > return true;
> > } else {
> > sourceNatIp =
> _ipAddressDao.findById(sourceNatIps.get(0).getId());
> > }
> > }
> >
> > How does the 'sourceNatIp' get set if 'sharedSourceNat' is true?
> >
> > Thanks,
> >
> > Will
>
>

Re: DevCloud

[Ahmad Emneina]

Hey Aaron, the mailserver strips attachments. You'll need to use an
external image hosting provider to convey images.


On Thu, Apr 18, 2013 at 1:17 PM, Aaron Paradowski wrote:

> Hi All,
>
> ** **
>
> Updated screenshot of what happens once the “Notifying management server
> join event took 56ms” proceeds. This is where it just goes displays these
> types of messages continuously. It went for 19 hours before I stopped it
> last time.
>
> ** **
>
> 
>
> ** **
>
> *Aaron*
>
> ** **
>
> *From:* Aaron Paradowski
> *Sent:* 18 April 2013 19:46
> *To:* 'Rohit Yadav'
> *Cc:* dev@cloudstack.apache.org; us...@cloudstack.apache.org; 'Mike
> Tutkowski'
> *Subject:* RE: DevCloud
>
> ** **
>
> Hi,
>
> ** **
>
> I tried again. This time between steps 8 and 9 I ran the following command
> 
>
> ** **
>
> export MAVEN_OPTS="-Xmx1024m -XX:MaxPermSize=800m -Xdebug
> -Xrunjdwp:transport=dt_socket,address=8787,server=y,suspend=n"
>
> ** **
>
> It still hung again after running the mvn-pl client jetty:run command –
> see below. The command is still running so I am unable to do anything else
> unless I cancel it. Any ideas? Thanks in advance for your help again.
>
> ** **
>
> 
>
> ** **
>
> ** **
>
> *Aaron*
>
> ** **
>
> *From:* rohityada...@gmail.com 
> [mailto:rohityada...@gmail.com]
> *On Behalf Of *Rohit Yadav
> *Sent:* 18 April 2013 18:51
> *To:* Aaron Paradowski
> *Cc:* dev@cloudstack.apache.org; us...@cloudstack.apache.org
> *Subject:* Re: DevCloud
>
> ** **
>
> ** **
>
> On Thu, Apr 18, 2013 at 10:17 PM, Aaron Paradowski 
> wrote:
>
> Hi Rohit,
>
>  
>
> I’m having some problems deploying DevCloud2 and wonder if you could help
> please. So far I have done the following
>
>  
>
> 1.   Downloaded and imported the DevCloud2 image into VirtualBox –
> ensured network settings were correct etc.
>
> 2.   Used PuTTY to SSH to the machine at 192.168.56.10 and logged in
> with root and password for username and password
>
> 3.   cd to /opt/cloudstack
>
> 4.   git cloned into the source code for incubator cloudstack
>
> 5.   once that had completed I cd’d to the incubator-cloudstack
> directory
>
> 6.   Ran mvn clean install –P developer,systemvm
>
> 7.   Changedthe host value in devcloud.sql to 192.168.56.10 as I want
> everything to run inside this one VM
>
> 8.   Ran mvn –pl developer,tools/devloud –Deploydb –P developer
>
>
> Hi Aaron,
>
> The best way is to reach to the whole community and cc any particular
> person whose attention you may be seeking.
>
> 1-8: So far so good, ignoring the -Ddeploydb typo.
>  
>
> 9.   Then ran mvn-pl client jetty:run and this is where everything
> goes wrong. It hangs on the below screen for ages then it goes through lots
> of warnings and errors such as “WARN [apache.cloudstack.alerts] (HA-3:)
> alertType:: 13” – I left it for 19 hours overnight last night and those
> types of errors just kept going round in cycles?
>
> Looks like CloudStack issue? Did you try exporting maven opts, checkout
> the building on master on cwiki.apache.org / cloudstack and try again?
>
> If you're just able to login inside DevCloud2 and run something like xe
> vm-list and it outputs something we're good at least from DevCloud's side :)
>
> Anyone from community?
>
> Cheers.
>  
>
> ** **
>
>  
>
> Any help would be greatly appreciated! Many thanks in advance.
>
>  
>
> Kind Regards,
>
>  
>
> *Aaron Paradowski*
>
>  
>
> ** **
>

RE: DevCloud

[Aaron Paradowski]

Hi All,

Updated screenshot of what happens once the "Notifying management server join 
event took 56ms" proceeds. This is where it just goes displays these types of 
messages continuously. It went for 19 hours before I stopped it last time.

[cid:image002.png@01CE3C7A.EF547790]

Aaron

From: Aaron Paradowski
Sent: 18 April 2013 19:46
To: 'Rohit Yadav'
Cc: dev@cloudstack.apache.org; us...@cloudstack.apache.org; 'Mike Tutkowski'
Subject: RE: DevCloud

Hi,

I tried again. This time between steps 8 and 9 I ran the following command

export MAVEN_OPTS="-Xmx1024m -XX:MaxPermSize=800m -Xdebug 
-Xrunjdwp:transport=dt_socket,address=8787,server=y,suspend=n"

It still hung again after running the mvn-pl client jetty:run command - see 
below. The command is still running so I am unable to do anything else unless I 
cancel it. Any ideas? Thanks in advance for your help again.

[cid:image003.png@01CE3C7A.EF547790]


Aaron

From: rohityada...@gmail.com 
[mailto:rohityada...@gmail.com] On Behalf Of Rohit Yadav
Sent: 18 April 2013 18:51
To: Aaron Paradowski
Cc: dev@cloudstack.apache.org; 
us...@cloudstack.apache.org
Subject: Re: DevCloud


On Thu, Apr 18, 2013 at 10:17 PM, Aaron Paradowski 
mailto:aa...@paradowski.co.uk>> wrote:
Hi Rohit,

I'm having some problems deploying DevCloud2 and wonder if you could help 
please. So far I have done the following


1.   Downloaded and imported the DevCloud2 image into VirtualBox - ensured 
network settings were correct etc.

2.   Used PuTTY to SSH to the machine at 192.168.56.10 and logged in with 
root and password for username and password

3.   cd to /opt/cloudstack

4.   git cloned into the source code for incubator cloudstack

5.   once that had completed I cd'd to the incubator-cloudstack directory

6.   Ran mvn clean install -P developer,systemvm

7.   Changedthe host value in devcloud.sql to 192.168.56.10 as I want 
everything to run inside this one VM

8.   Ran mvn -pl developer,tools/devloud -Deploydb -P developer

Hi Aaron,

The best way is to reach to the whole community and cc any particular person 
whose attention you may be seeking.

1-8: So far so good, ignoring the -Ddeploydb typo.


9.   Then ran mvn-pl client jetty:run and this is where everything goes 
wrong. It hangs on the below screen for ages then it goes through lots of 
warnings and errors such as "WARN [apache.cloudstack.alerts] (HA-3:) 
alertType:: 13" - I left it for 19 hours overnight last night and those types 
of errors just kept going round in cycles?
Looks like CloudStack issue? Did you try exporting maven opts, checkout the 
building on master on cwiki.apache.org / cloudstack 
and try again?

If you're just able to login inside DevCloud2 and run something like xe vm-list 
and it outputs something we're good at least from DevCloud's side :)

Anyone from community?

Cheers.



Any help would be greatly appreciated! Many thanks in advance.

Kind Regards,

Aaron Paradowski

[VOTE][ACS402] Apache CloudStack 4.0.2 (Second Round)

[Joe Brockmeier]

Hi All,

I've created a 4.0.2 release, and am asking for you to test the
artifacts and
*after* testing, please submit a vote. Suggested testing procedure here:
https://cwiki.apache.org/confluence/display/CLOUDSTACK/CloudStack+4.0+test+procedure

(Please don't just +1 a release without any testing!)

The following artifacts up for a vote: 

Git Branch and Commit SH:
https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=shortlog;h=refs/heads/4.0
Commit: 570cb65703b795ffdeaf5a948991664f757c649a

List of changes:
https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=blob_plain;f=CHANGES;hb=4.0

Source release (checksums and signatures are available at the same
location):
http://people.apache.org/~jzb/cloudstack/dist/releases/4.0.2/

PGP release keys (signed using A0207CD4):
http://www.apache.org/dist/incubator/cloudstack/KEYS

Vote will be open for 72 hours.

For sanity in tallying the vote, can PMC members please be sure to
indicate "(binding)" with their vote?

[ ] +1  approve
[ ] +0  no opinion
[ ] -1  disapprove (and reason why)

Best,

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

RE: qa tests for nicira code in 4.1

[Sudha Ponnaganti]

Thanks Daan for posting test results !

I have created a place holder for you to update test results [1] - You can 
update it at your convenience. 
Does this execution cover both of these stories for Nicira [2], [3]. If it 
covers both of these stories, may be these can be closed. Looks like doc is 
also outstanding as per the JIRA status. 

[1] 
https://cwiki.apache.org/confluence/display/CLOUDSTACK/CloudStack+4.1+Test+Execution
[2] https://issues.apache.org/jira/browse/CLOUDSTACK-726
[3] https://issues.apache.org/jira/browse/CLOUDSTACK-727



Thanks
/Sudha

-Original Message-
From: Daan Hoogland [mailto:dhoogl...@schubergphilis.com] 
Sent: Thursday, April 18, 2013 12:38 PM
To: dev@cloudstack.apache.org
Subject: qa tests for nicira code in 4.1

LS,

At Schuberg Philis we did some tests on the 4.1 code for the tests in the 
following table
Test Case ID  Test Description Results
   Infrastructure
NVP-001 Create NVP Element pass
NVP-002 Disable NVP Elementpass
NVP-003 Enable NVP Element pass
NVP-004 Delete NVP Element  pass
NVP-005 Create NVP Device   pass
NVP-006 Delete NVP Devicepass
   L2 Functions
NVP-101 Create Logical Switchpass
NVP-102 Create Logical Portpass
NVP-103 Check Connection Pass
NVP-104 Check Connection Pass
NVP-105 Delete Logical SwitchPass
NVP-106 Delete Logical Port Pass
   L3 Functions
NVP-201 Create Logical RouterPass
NVP-202 Create Source Nat rule  Pass
NVP-203 Create Static Nat rulePass
NVP-204 Create Port FW rule   Pass
NVP-205 Check Source Nat rule  Pass
NVP-206 Check Static Nat rule Pass
NVP-207 Check Port FW rule   Pass
NVP-208 Delete Source Nat rule  Pass
NVP-209 Delete Static Nat rule Fail
NVP-210 Delete Port FW rule   Pass
NVP-211 Delete Logical RouterPass

The tests where partly done aith scripts but these are not yet complete and the 
remainder of functionality was done by hand.
For the failed test, NVP-209 a ticket was created, 'CLOUDSTACK-2092'. The 
problem in this case was that deleting the static rule did not result in the 
deletion of the ip adres from the logical router.

Kind regards,
Daan Hoogland

Re: Review Request: CLOUDSTACK-741: Granular Global Parameters

[Harikrishna Patnala]

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

(Updated April 18, 2013, 8:16 p.m.)


Review request for cloudstack, Abhinandan Prateek, Kishan Kavala, and Nitin 
Mehta.


Changes
---

updated patch with suggested changes


Description
---

CLOUDSTACK-741: Granular Global Parameters

Modified UpdateConfiguration API and ListConfiguration API by adding additional 
parameter scope and resource id (zone/cluster/pool/account).
Scope decides the parameter which level we can update the value and id is the 
corresponding id based on the scope.
This scope is defined in the config.java file where we are creating groups for 
each level(zone/cluster/pool/account).
Currently submitted the patch for the zone level parameter use.external.dns.

Included unit tests and marvin tests.


This addresses bug CLOUDSTACK-741.


Diffs (updated)
-

  api/src/org/apache/cloudstack/api/command/admin/config/ListCfgsByCmd.java 
aabfd4a 
  api/src/org/apache/cloudstack/api/command/admin/config/UpdateCfgCmd.java 
ffeb586 
  api/src/org/apache/cloudstack/api/response/ConfigurationResponse.java 95b8af2 
  api/test/org/apache/cloudstack/api/command/test/ListCfgCmdTest.java 
PRE-CREATION 
  api/test/org/apache/cloudstack/api/command/test/UpdateCfgCmdTest.java 
PRE-CREATION 
  
engine/api/src/org/apache/cloudstack/storage/datastore/db/StoragePoolDetailsDao.java
 be71670 
  server/src/com/cloud/configuration/Config.java 2993966 
  server/src/com/cloud/configuration/ConfigurationManager.java afaf0d6 
  server/src/com/cloud/configuration/ConfigurationManagerImpl.java 4fc2db7 
  server/src/com/cloud/configuration/dao/ConfigurationDao.java c86c024 
  server/src/com/cloud/network/router/VirtualNetworkApplianceManagerImpl.java 
ab91059 
  server/src/com/cloud/server/ConfigurationServer.java f441b1f 
  server/src/com/cloud/server/ConfigurationServerImpl.java c4da1ab 
  server/src/com/cloud/server/ManagementServerImpl.java 98f789a 
  server/src/com/cloud/storage/dao/StoragePoolDetailsDaoImpl.java 0d797ed 
  server/test/com/cloud/vpc/MockConfigurationManagerImpl.java 9443815 
  test/integration/smoke/test_UpdateCfg.py PRE-CREATION 

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


Testing
---

Tested locally
- tested the modified UpdateConfiguration API and ListConfiguration API by 
providing the zone scope and zone id
- tested the modified parameter to take the updated value at zone level(after 
updation).


Thanks,

Harikrishna Patnala

Re: [ACS402] CLOUDSTACK-528 needs love! (Failed to create secondary storage)

[Joe Brockmeier]

On Thu, Apr 18, 2013, at 03:04 PM, Chip Childers wrote:
> On Thu, Apr 18, 2013 at 03:02:03PM -0500, Joe Brockmeier wrote:
> > Bumping this. I'm about to put out another 4.0.2 for a VOTE and if
> > anyone is working on this, now would be a very good time to speak up. 
> 
> Joe, IMO we go forward without this for 4.0.2.

That's my plan - I just wanted to bump the thread in case someone
*might* be working on it, and have not updated Jira to reflect that. 

> If this is a problem for 4.1.0, then we can make it a critical bug for
> that release.  Waiting for feedback as to the impact against the 4.1.0
> code though...

Right. 

Best,

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

Re: Supported Source NAT Type?

[Chip Childers]

Will,

Images and other attachments are stripped on this list (text only
please!)

Can you post the image somewhere or describe the list?

On Thu, Apr 18, 2013 at 04:05:36PM -0400, Will Stevens wrote:
> In the 'Create network service offering' flow there is this dropdown:
> 
> [image: Inline image 1]
> 
> What are the implications for picking one or the other?
> 
> This code seems related in
> 'com.cloud.network.ExternalFirewallDeviceManagerImpl.manageGuestNetworkWithExternalFirewall()'
> :
> NetworkOffering offering =
> _networkOfferingDao.findById(network.getNetworkOfferingId());
> boolean sharedSourceNat = offering.getSharedSourceNat();
> 
> IPAddressVO sourceNatIp = null;
> if (!sharedSourceNat) {
> // Get the source NAT IP address for this account
> List sourceNatIps =
> _networkMgr.listPublicIpsAssignedToAccount(network.getAccountId(),
> zoneId, true);
> 
> if (sourceNatIps.size() != 1) {
> String errorMsg = "External firewall was unable to find the source
> NAT IP address for account "
> + account.getAccountName();
> s_logger.error(errorMsg);
> return true;
> } else {
> sourceNatIp = _ipAddressDao.findById(sourceNatIps.get(0).getId());
> }
> }
> 
> How does the 'sourceNatIp' get set if 'sharedSourceNat' is true?
> 
> Thanks,
> 
> Will

Re: New Committer: Go Chiba

[Ahmad Emneina]

Awesome news, good work Go!


On Thu, Apr 18, 2013 at 12:49 AM, Mice Xia wrote:

> Congrats!
>
> -Original Message-
> From: Sebastien Goasguen [mailto:run...@gmail.com]
> Sent: Thursday, April 18, 2013 2:56 PM
> To: dev@cloudstack.apache.org
> Subject: New Committer: Go Chiba
>
> The Project Management Committee (PMC) for Apache CloudStack has asked Go
> Chiba to become a committer and we are pleased to announced that they have
> accepted.
>
> Go has contributed tremendously to the Japanese translations of the
> documentation (runbook, UI and docs).
> 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 Go,
>
> -Sebastien, on behalf of  the Apache CloudStack PMC
>
>

Supported Source NAT Type?

[Will Stevens]

In the 'Create network service offering' flow there is this dropdown:

[image: Inline image 1]

What are the implications for picking one or the other?

This code seems related in
'com.cloud.network.ExternalFirewallDeviceManagerImpl.manageGuestNetworkWithExternalFirewall()'
:
NetworkOffering offering =
_networkOfferingDao.findById(network.getNetworkOfferingId());
boolean sharedSourceNat = offering.getSharedSourceNat();

IPAddressVO sourceNatIp = null;
if (!sharedSourceNat) {
// Get the source NAT IP address for this account
List sourceNatIps =
_networkMgr.listPublicIpsAssignedToAccount(network.getAccountId(),
zoneId, true);

if (sourceNatIps.size() != 1) {
String errorMsg = "External firewall was unable to find the source
NAT IP address for account "
+ account.getAccountName();
s_logger.error(errorMsg);
return true;
} else {
sourceNatIp = _ipAddressDao.findById(sourceNatIps.get(0).getId());
}
}

How does the 'sourceNatIp' get set if 'sharedSourceNat' is true?

Thanks,

Will

Re: [ACS402] CLOUDSTACK-528 needs love! (Failed to create secondary storage)

[Chip Childers]

On Thu, Apr 18, 2013 at 03:02:03PM -0500, Joe Brockmeier wrote:
> Bumping this. I'm about to put out another 4.0.2 for a VOTE and if
> anyone is working on this, now would be a very good time to speak up. 

Joe, IMO we go forward without this for 4.0.2.

If this is a problem for 4.1.0, then we can make it a critical bug for
that release.  Waiting for feedback as to the impact against the 4.1.0
code though...

-chip

> 
> On Wed, Apr 17, 2013, at 09:25 AM, Joe Brockmeier wrote:
> > Howdy all,
> > 
> > As noted in the previous thread, we've stopped the vote on 4.0.2 due to
> > another issue. I'm going to re-roll the release and start the vote again
> > tomorrow. 
> > 
> > In the meantime, CLOUDSTACK-528 is a problem for at least one user
> > trying to upgrade to 4.0.x. Can we get someone to take a look at this
> > and see if there's a fix we can put in before tomorrow? Thanks!
> > 
> > Best,
> > 
> > jzb
> > -- 
> > Joe Brockmeier
> > j...@zonker.net
> > Twitter: @jzb
> > http://www.dissociatedpress.net/
> 
> 
> Best,
> 
> jzb
> -- 
> Joe Brockmeier
> j...@zonker.net
> Twitter: @jzb
> http://www.dissociatedpress.net/
> 

Re: qa tests for nicira code in 4.1

[Chip Childers]

On Thu, Apr 18, 2013 at 07:38:13PM +, Daan Hoogland wrote:
> LS,
> 
> At Schuberg Philis we did some tests on the 4.1 code for the tests in the 
> following table
> Test Case ID  Test Description Results
>Infrastructure
> NVP-001 Create NVP Element pass
> NVP-002 Disable NVP Elementpass
> NVP-003 Enable NVP Element pass
> NVP-004 Delete NVP Element  pass
> NVP-005 Create NVP Device   pass
> NVP-006 Delete NVP Devicepass
>L2 Functions
> NVP-101 Create Logical Switchpass
> NVP-102 Create Logical Portpass
> NVP-103 Check Connection Pass
> NVP-104 Check Connection Pass
> NVP-105 Delete Logical SwitchPass
> NVP-106 Delete Logical Port Pass
>L3 Functions
> NVP-201 Create Logical RouterPass
> NVP-202 Create Source Nat rule  Pass
> NVP-203 Create Static Nat rulePass
> NVP-204 Create Port FW rule   Pass
> NVP-205 Check Source Nat rule  Pass
> NVP-206 Check Static Nat rule Pass
> NVP-207 Check Port FW rule   Pass
> NVP-208 Delete Source Nat rule  Pass
> NVP-209 Delete Static Nat rule Fail
> NVP-210 Delete Port FW rule   Pass
> NVP-211 Delete Logical RouterPass
> 
> The tests where partly done aith scripts but these are not yet complete and 
> the remainder of functionality was done by hand.
> For the failed test, NVP-209 a ticket was created, 'CLOUDSTACK-2092'. The 
> problem in this case was that deleting the static rule did not result in the 
> deletion of the ip adres from the logical router.
> 
> Kind regards,
> Daan Hoogland

Daan,

Fantastic work!

I've pinged Hugo to look at CLOUDSTACK-2092, and will block the release
until that's resolved.

Can you please put your test cases and results in the wiki (with the
other project testing material)?

-chip

Re: [ACS402] CLOUDSTACK-528 needs love! (Failed to create secondary storage)

[Joe Brockmeier]

Bumping this. I'm about to put out another 4.0.2 for a VOTE and if
anyone is working on this, now would be a very good time to speak up. 

On Wed, Apr 17, 2013, at 09:25 AM, Joe Brockmeier wrote:
> Howdy all,
> 
> As noted in the previous thread, we've stopped the vote on 4.0.2 due to
> another issue. I'm going to re-roll the release and start the vote again
> tomorrow. 
> 
> In the meantime, CLOUDSTACK-528 is a problem for at least one user
> trying to upgrade to 4.0.x. Can we get someone to take a look at this
> and see if there's a fix we can put in before tomorrow? Thanks!
> 
> Best,
> 
> jzb
> -- 
> Joe Brockmeier
> j...@zonker.net
> Twitter: @jzb
> http://www.dissociatedpress.net/


Best,

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

RE: devcloud hanging

[Daan Hoogland]

Running 32 bit macosx was the problem. I overlooked the line where it mentioned 
this from all the docs. Macosx 10.6 works fine.

-Original Message-
From: rohityada...@gmail.com [mailto:rohityada...@gmail.com] On Behalf Of Rohit 
Yadav
Sent: donderdag 18 april 2013 10:59
To: dev@cloudstack.apache.org
Subject: Re: devcloud hanging

On Thu, Apr 18, 2013 at 11:28 AM, Chiradeep Vittal < 
chiradeep.vit...@citrix.com> wrote:

> 32-bit dom0 but 64-bit hypervisor.
>

o.O As far as I remember and know, at the time of building DevCloud2, I had 
used 32-bit xen smp pae (xen-4.1-i386 from Debian Wheezy public repo) which is 
32-bit (and we've PAE turned on in vbox) so I guess it is 32-bit hypervisor 
with Debian Wheezy as 32-bit dom0 [1], unless I'm mistaken.

Cheers.

[1]
http://wiki.xen.org/wiki/Xen_4.0_Release_Notes#Requirements_for__running_Xen_4.0(should
apply for 4.1)


> On 4/17/13 7:02 PM, "Rohit Yadav"  wrote:
>
> >On Thu, Apr 18, 2013 at 12:38 AM, Chiradeep Vittal < 
> >chiradeep.vit...@citrix.com> wrote:
> >
> >> I mean 32-bit OSX on intel. DevCloud is 64-bit.
> >>
> >
> >?? DevCloud2 is 32-bit.
> >
> >Cheers.
> >
> >
> >>
> >> On 4/17/13 11:21 AM, "Rohit Yadav"  wrote:
> >>
> >> >On Wed, Apr 17, 2013 at 11:15 PM, Chiradeep Vittal < 
> >> >chiradeep.vit...@citrix.com> wrote:
> >> >
> >> >> It used to work for me (back in Jan). Now I'm on 10.8.
> >> >> Some old macbook's have the 32-bit version of OSX and I think 
> >> >>they cannot  run  DevCloud/DevCloud2
> >> >>
> >> >
> >> >DevCloud old and newer both are x86 based and can run on 
> >> >VirtualBox
> >>x86.
> >> >If
> >> >someone's old macbooks cannot run 'em then they can contribute by
> >>fixing
> >> >DevCloud/VBox or replace their laptop :)
> >> >
> >> >Cheers.
> >> >
> >> >
> >> >>
> >> >> From: Rohit Yadav 
> >> >> mailto:bhais...@apache.org>>
> >> >> Reply-To:
> >>"dev@cloudstack.apache.org"
> >> >><
> >> >> dev@cloudstack.apache.org>
> >> >> Date: Wednesday, April 17, 2013 6:20 AM
> >> >> To: 
> >> >>"dev@cloudstack.apache.org" <  
> >> >>dev@cloudstack.apache.org>
> >> >> Subject: Re: devcloud hanging
> >> >>
> >> >>
> >> >>
> >> >> On Wed, Apr 17, 2013 at 4:25 PM, Daan Hoogland
> >> >> >> > wrote:
> >> >> LS,
> >> >>
> >> >> I tried both the devcloud and devcloud2 images. both seem to 
> >> >> hang
> >>when
> >> >> started with the default (xen) kernel.
> >> >> I am running macosx 10.6.8 and virtualbox 4.2.12 I enabled pae
> >> >>
> >> >> Don't enable PAE, importing devcloud2 from the ova should set 
> >> >> all the necessary settings for you.
> >> >> Make sure you've 2G RAM given to it and installed the extension 
> >> >> pack
> >>for
> >> >> your version:
> >> >>
> >> >>
> >>
> >>
> http://download.virtualbox.org/virtualbox/4.2.12/Oracle_VM_VirtualBox_
> Ext
> >> >>ension_Pack-4.2.12-84980.vbox-extpack
> >> >>
> >> >> 10.6 is pretty old now, probably the processor is too. There may 
> >> >> be compatibility issues. May be nested virtualization has 
> >> >> issues. Won't
> >>be
> >> >> able to help you much as I don't have a 10.6 machine to test 
> >> >>against, can  someone in the community confirm running 
> >> >>DevCloud2/VirtualBox on 10.6/osx?
> >> >>
> >> >> Cheers.
> >> >>
> >> >>
> >> >> In both cases it hangs right after loading initial ramdisk.
> >> >>
> >> >> Is there any clue I am missing?
> >> >>
> >> >> thanks
> >> >> --
> >> >> [cid:part1.01020805.08000205@gmail.com]
> >> >>
> >> >>
> >>
> >>
>
>

qa tests for nicira code in 4.1

[Daan Hoogland]

LS,

At Schuberg Philis we did some tests on the 4.1 code for the tests in the 
following table
Test Case ID  Test Description Results
   Infrastructure
NVP-001 Create NVP Element pass
NVP-002 Disable NVP Elementpass
NVP-003 Enable NVP Element pass
NVP-004 Delete NVP Element  pass
NVP-005 Create NVP Device   pass
NVP-006 Delete NVP Devicepass
   L2 Functions
NVP-101 Create Logical Switchpass
NVP-102 Create Logical Portpass
NVP-103 Check Connection Pass
NVP-104 Check Connection Pass
NVP-105 Delete Logical SwitchPass
NVP-106 Delete Logical Port Pass
   L3 Functions
NVP-201 Create Logical RouterPass
NVP-202 Create Source Nat rule  Pass
NVP-203 Create Static Nat rulePass
NVP-204 Create Port FW rule   Pass
NVP-205 Check Source Nat rule  Pass
NVP-206 Check Static Nat rule Pass
NVP-207 Check Port FW rule   Pass
NVP-208 Delete Source Nat rule  Pass
NVP-209 Delete Static Nat rule Fail
NVP-210 Delete Port FW rule   Pass
NVP-211 Delete Logical RouterPass

The tests where partly done aith scripts but these are not yet complete and the 
remainder of functionality was done by hand.
For the failed test, NVP-209 a ticket was created, 'CLOUDSTACK-2092'. The 
problem in this case was that deleting the static rule did not result in the 
deletion of the ip adres from the logical router.

Kind regards,
Daan Hoogland

[ACS41] Nicira Blocker Bug - CLOUDSTACK-2092

[Chip Childers]

Hugo,

Mind looking into this one?  CLOUDSTACK-2092

-chip

RE: DevCloud

[Aaron Paradowski]

Hi,

I tried again. This time between steps 8 and 9 I ran the following command

export MAVEN_OPTS="-Xmx1024m -XX:MaxPermSize=800m -Xdebug 
-Xrunjdwp:transport=dt_socket,address=8787,server=y,suspend=n"

It still hung again after running the mvn-pl client jetty:run command - see 
below. The command is still running so I am unable to do anything else unless I 
cancel it. Any ideas? Thanks in advance for your help again.

[cid:image001.png@01CE3C6D.59D90620]


Aaron

From: rohityada...@gmail.com [mailto:rohityada...@gmail.com] On Behalf Of Rohit 
Yadav
Sent: 18 April 2013 18:51
To: Aaron Paradowski
Cc: dev@cloudstack.apache.org; us...@cloudstack.apache.org
Subject: Re: DevCloud


On Thu, Apr 18, 2013 at 10:17 PM, Aaron Paradowski 
mailto:aa...@paradowski.co.uk>> wrote:
Hi Rohit,

I'm having some problems deploying DevCloud2 and wonder if you could help 
please. So far I have done the following


1.   Downloaded and imported the DevCloud2 image into VirtualBox - ensured 
network settings were correct etc.

2.   Used PuTTY to SSH to the machine at 192.168.56.10 and logged in with 
root and password for username and password

3.   cd to /opt/cloudstack

4.   git cloned into the source code for incubator cloudstack

5.   once that had completed I cd'd to the incubator-cloudstack directory

6.   Ran mvn clean install -P developer,systemvm

7.   Changedthe host value in devcloud.sql to 192.168.56.10 as I want 
everything to run inside this one VM

8.   Ran mvn -pl developer,tools/devloud -Deploydb -P developer

Hi Aaron,

The best way is to reach to the whole community and cc any particular person 
whose attention you may be seeking.

1-8: So far so good, ignoring the -Ddeploydb typo.


9.   Then ran mvn-pl client jetty:run and this is where everything goes 
wrong. It hangs on the below screen for ages then it goes through lots of 
warnings and errors such as "WARN [apache.cloudstack.alerts] (HA-3:) 
alertType:: 13" - I left it for 19 hours overnight last night and those types 
of errors just kept going round in cycles?
Looks like CloudStack issue? Did you try exporting maven opts, checkout the 
building on master on cwiki.apache.org / cloudstack 
and try again?

If you're just able to login inside DevCloud2 and run something like xe vm-list 
and it outputs something we're good at least from DevCloud's side :)

Anyone from community?

Cheers.


Any help would be greatly appreciated! Many thanks in advance.

Kind Regards,

Aaron Paradowski

Re: [ACS41] API Compatibility Bug?

[Joe Brockmeier]

Thanks, Min! Checking now, much appreciated.

On Thu, Apr 18, 2013, at 01:35 PM, Min Chen wrote:
> Done. Commit number f797d450261d8a4d2734db2cfc7e40c67167cd14.
> 
> -min
> 
> On 4/18/13 11:20 AM, "Joe Brockmeier"  wrote:
> 
> >On Thu, Apr 18, 2013, at 01:15 PM, Min Chen wrote:
> >> I can provide a quick fix on 4.0 branch. For 4.0 branch, what is the
> >> process to commit a fix? Submit a patch for Joe to commit, or I can
> >> directly commit?
> >
> >I'd love a fix for this, yes.  You can commit directly, reverts are
> >easy. ;-) Thanks!
> >
> >Best,
> >
> >jzb
> >-- 
> >Joe Brockmeier
> >j...@zonker.net
> >Twitter: @jzb
> >http://www.dissociatedpress.net/
> 


Best,

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

Re: [ACS41] API Compatibility Bug?

[Min Chen]

Done. Commit number f797d450261d8a4d2734db2cfc7e40c67167cd14.

-min

On 4/18/13 11:20 AM, "Joe Brockmeier"  wrote:

>On Thu, Apr 18, 2013, at 01:15 PM, Min Chen wrote:
>> I can provide a quick fix on 4.0 branch. For 4.0 branch, what is the
>> process to commit a fix? Submit a patch for Joe to commit, or I can
>> directly commit?
>
>I'd love a fix for this, yes.  You can commit directly, reverts are
>easy. ;-) Thanks!
>
>Best,
>
>jzb
>-- 
>Joe Brockmeier
>j...@zonker.net
>Twitter: @jzb
>http://www.dissociatedpress.net/

Re: CS 4.0.0 - vpc deployment - why tier network limited to 200mb/s ?

[Chiradeep Vittal]

Really depends on 
 - your CPU configuration
 - your hypervisor
 - your physical network speed
 - noisy neighbors around the VR / around the physical network
 - how many ipsec vpns
 - how many LB
 - load on the LB
 - number of connections

If you just test the VR in isolation with a 512GB RAM/1core configuration
you should be able to get
 - 2 Gb/s forwarding / firewalling OR
 - 4 to 5k conn/s on the LB

You add the other factors and things can vary wildly


On 4/18/13 2:58 AM, "benoit lair"  wrote:

>Hello,
>
>
>Thanks for your response.
>
>However, do you know in production cases, what are the maximum bandwidth i
>can manage with a vpc vr ? Are there limitations or any recommendations
>(sizing limit in order to avoid performance loss) concerning provisionning
>of the vpc ?
>
>
>Thanks for your advices.
>
>Regards, Benoit.
>
>2013/4/17 benoit lair 
>
>> Hello guys,
>>
>>
>> I'm testing an preproduction environment with cs4.0.0 onto centos 5.3.
>>
>> I'm testing a vpc environment.
>>
>> I'm asking why does the tier networks are limited to 200mb/s (network
>> offering DefaultIsolatedNetworkOfferingForVpcNetworksNoLB) ?
>> So in xencenter, if i look at the network tab of my vpc vr vm, i got a
>>qos
>> of 25600 kbytes/sec.
>>
>> Is there a risk to create a different network offering with a 1000 mb/s
>> qos limit ? no limit ?
>>
>> What if i want to recreate a multi tier environnment with a no limit of
>> qos with a 500 mb/s troughput, a 1000mb/s troughput ?
>>
>> What do you think about vpc vr capabilities ? any deployment
>> recommendations ?
>>
>>
>> Thanks for any advice.
>>
>> Regards, Benoit Lair.
>>
>>
>>
>>

Re: [ACS41] API Compatibility Bug?

[Joe Brockmeier]

On Thu, Apr 18, 2013, at 01:15 PM, Min Chen wrote:
> I can provide a quick fix on 4.0 branch. For 4.0 branch, what is the
> process to commit a fix? Submit a patch for Joe to commit, or I can
> directly commit?

I'd love a fix for this, yes.  You can commit directly, reverts are
easy. ;-) Thanks!

Best,

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

Re: CS 4.0.0 - mysql server connections aborted

[Chiradeep Vittal]

There should be a way for MySQL to log the connections that get aborted.
At least it will tell you if it was the client that aborted the
connection. 


On 4/18/13 6:16 AM, "benoit lair"  wrote:

>Hello,
>
>
>I'm using a cs 4.0.0 preproduction server onto centos 5.3.
>
>I have launched a mysqltuner.pl onto the mysql server of the mgmt server.
>
>So it gives me connections aborted.
>
>Have you an explication why it show this ? How can i troubleshoot this ?
>
>Here is my mysqltuner.pl output :
>
>[root@cloudstack-master-server ~]# ./mysqltuner.pl
>
> >>  MySQLTuner 1.2.0 - Major Hayden 
> >>  Bug reports, feature requests, and downloads at
>http://mysqltuner.com/
> >>  Run with '--help' for additional options and output filtering
>Please enter your MySQL administrative login: root
>Please enter your MySQL administrative password:
>
> General Statistics
>--
>[--] Skipped version check for MySQLTuner script
>[OK] Currently running supported MySQL version 5.1.67-log
>[OK] Operating on 64-bit architecture
>
> Storage Engine Statistics
>---
>[--] Status: -Archive -BDB -Federated +InnoDB -ISAM -NDBCluster
>[--] Data in InnoDB tables: 23M (Tables: 166)
>[--] Data in MEMORY tables: 125K (Tables: 2)
>[!!] Total fragmented tables: 166
>
> Security Recommendations
>---
>[OK] All database users have passwords assigned
>
> Performance Metrics
>-
>[--] Up for: 7m 46s (79K q [169.689 qps], 16 conn, TX: 20M, RX: 6M)
>[--] Reads / Writes: 93% / 7%
>[--] Total buffers: 66.0M global + 3.6M per thread (350 max threads)
>[OK] Maximum possible memory usage: 1.3G (13% of installed RAM)
>[OK] Slow queries: 0% (0/79K)
>[OK] Highest usage of available connections: 2% (10/350)
>[OK] Key buffer size / total MyISAM indexes: 8.0M/92.0K
>[OK] Key buffer hit rate: 100.0% (24 cached / 0 reads)
>[OK] Query cache efficiency: 28.7% (7K cached / 25K selects)
>[OK] Query cache prunes per day: 0
>[OK] Sorts requiring temporary tables: 0% (0 temp sorts / 844 sorts)
>[!!] Joins performed without indexes: 35
>[OK] Temporary tables created on disk: 1% (12 on disk / 936 total)
>[!!] Thread cache hit rate: 37% (10 created / 16 connections)
>[OK] Table cache hit rate: 92% (128 open / 138 opened)
>[OK] Open file limit used: 0% (12/1K)
>[OK] Table locks acquired immediately: 100% (7K immediate / 7K locks)
>[!!] Connections aborted: 12%
>[OK] InnoDB data size / buffer pool: 23.1M/24.0M
>
> Recommendations
>-
>General recommendations:
>Run OPTIMIZE TABLE to defragment tables for better performance
>MySQL started within last 24 hours - recommendations may be inaccurate
>Enable the slow query log to troubleshoot bad queries
>Adjust your join queries to always utilize indexes
>Your applications are not closing MySQL connections properly
>Variables to adjust:
>join_buffer_size (> 1.0M, or always use indexes with joins)
>thread_cache_size (> 4)
>
>
>Thanks for any advice.
>
>
>Regards, Benoit.

Re: [ACS41] API Compatibility Bug?

[Min Chen]

I can provide a quick fix on 4.0 branch. For 4.0 branch, what is the
process to commit a fix? Submit a patch for Joe to commit, or I can
directly commit?

Thanks
-min

On 4/18/13 11:08 AM, "Chip Childers"  wrote:

>On Thu, Apr 18, 2013 at 11:07:18AM -0700, Alena Prokharchyk wrote:
>> On 4/18/13 11:02 AM, "Chip Childers"  wrote:
>> 
>> >On Thu, Apr 18, 2013 at 10:57:51AM -0700, Alena Prokharchyk wrote:
>> >> On 4/18/13 10:48 AM, "Chip Childers" 
>>wrote:
>> >> 
>> >> >On Thu, Apr 18, 2013 at 10:46:38AM -0700, Alena Prokharchyk wrote:
>> >> >> I would probably leave it for 4.2.0. And update the release notes
>>for
>> >> >>4.0
>> >> >> 
>> >> >> Chip, what do you think?
>> >> >
>> >> >Doesn't 4.1 actually have the right code in it already?
>> >> >
>> >> >I think Joe is asking about the 4.0 branch, since he's about to cut
>>the
>> >> >second RC for that code line.
>> >> 
>> >> 
>> >> 4.1 does have correct code. Chip, would you advise to patch 4.0? It
>> >>would
>> >> require java code changes - fixing annotations in the APIs. Then we
>>have
>> >> to generate new xml/html api docs.
>> >> 
>> >> -Alena.
>> >
>> >Joe's the RM for the 4.0.2 release.  I think he's asking about (1)
>> >impact, (2) risk and (3) how quick the fix will be.  We're about to
>> >start another round of voting for 4.0.2, and generating new API docs
>> >will be part of that release process anyway.  The question is really
>> >intended to get the code clean so that the (hopefully) last 4.0.x
>> >release has correct docs in it.
>> >
>> 
>> 
>> There is a minimal impact - only api docs will get affected, and the fix
>> should be relatively quick as all we have to do is to fix
>>@Implementation
>> parameter in 3 java classes.
>> 
>>
>
>I *think* joe would love a patch for the 4.0 branch for this!

Re: CS 4.0.1 | KVM | CentOS 6.3

[Chiradeep Vittal]

Maurice, it appears to be something specific to the sequence of actions
you took or your environment.

Developers and QA kill and restart their management servers dozens of
times a day and have (AFAIK) never seen this issue.

What are the entries in the mshost table?


On 4/17/13 11:20 PM, "Maurice Lawler"  wrote:

>Thank you. How would I correct this and why would the table state
>something other then what I have setup, what would have caused that?
>
>
>On Apr 18, 2013, at 12:27 AM, Chiradeep Vittal
> wrote:
>
>> That's probably not what the mshost table thinks?
>> 
>> On 4/17/13 11:00 AM, "Maurice Lawler"  wrote:
>> 
>>> No. I have ONE server running.
>>> 
>>> One MS - One Install of CS - One of everything. All on the same IP
>>> address. 
>>> 
>>> 
>>> On Apr 17, 2013, at 12:05 PM, Chiradeep Vittal
>>>  wrote:
>>> 
 You probably have another MS connecting to the same database?
 
 On 4/17/13 9:49 AM, "Maurice Lawler"  wrote:
 
> No the management IP hasn't changed. My question is why when
>restarting
> Cloud Management the issue is cleared up. Then almost an hour later,
>it
> starts in again; how do I correct this issue?
> 
> 
> On Apr 17, 2013, at 12:23 AM, Chiradeep Vittal
>  wrote:
> 
>> Did the management server ip change? It somehow thinks there's 2
>> management servers.
>> 
>> On 4/16/13 7:00 PM, "Maurice Lawler"  wrote:
>> 
>>> Greetings,
>>> 
>>> I am having this FLOOD my log. I will have you know, this is ONE
>>> server
>>> ONE HOST. KVM | CentOS 6.3 | Cloudstack 4.0.1
>>> 
>>> I have found restarting cloud management solves the issue for
>>>awhile,
>>> then it starts again.
>>> 
>>> Please advise.
>>> 
>>> - Maurice
>>> 
>>>  Eror Log 
>>> 
>>> 2013-04-16 20:58:38,993 DEBUG
>>> [cloud.consoleproxy.ConsoleProxyManagerImpl] (consoleproxy-1:null)
>>> Zone 1
>>> is ready to launch console proxy
>>> 2013-04-16 20:58:39,137 DEBUG [cloud.cluster.ClusterManagerImpl]
>>> (Cluster-Heartbeat-1:null) Detected management node left, id:1,
>>> nodeIP:MYIPADDRESSHERE
>>> 2013-04-16 20:58:39,137 INFO  [cloud.cluster.ClusterManagerImpl]
>>> (Cluster-Heartbeat-1:null) Trying to connect to MYIPADDRESSHERE
>>> 2013-04-16 20:58:39,138 INFO  [cloud.cluster.ClusterManagerImpl]
>>> (Cluster-Heartbeat-1:null) Management node 1 is detected inactive
>>>by
>>> timestamp but is pingable
>>> 2013-04-16 20:58:39,264 DEBUG
>>> [network.router.VirtualNetworkApplianceManagerImpl]
>>> (RouterStatusMonitor-1:null) Found 0 routers.
>>> 2013-04-16 20:58:40,637 DEBUG [cloud.cluster.ClusterManagerImpl]
>>> (Cluster-Heartbeat-1:null) Detected management node left, id:1,
>>> nodeIP:MYIPADDRESSHERE
>>> 2013-04-16 20:58:40,637 INFO  [cloud.cluster.ClusterManagerImpl]
>>> (Cluster-Heartbeat-1:null) Trying to connect to MYIPADDRESSHERE
>>> 2013-04-16 20:58:40,637 INFO  [cloud.cluster.ClusterManagerImpl]
>>> (Cluster-Heartbeat-1:null) Management node 1 is detected inactive
>>>by
>>> timestamp but is pingable
>>> 2013-04-16 20:58:42,062 DEBUG [agent.manager.AgentManagerImpl]
>>> (AgentManager-Handler-13:null) Ping from 3
>>> 2013-04-16 20:58:42,063 DEBUG [agent.manager.AgentManagerImpl]
>>> (AgentManager-Handler-14:null) Ping from 4
>>> 2013-04-16 20:58:42,138 DEBUG [cloud.cluster.ClusterManagerImpl]
>>> (Cluster-Heartbeat-1:null) Detected management node left, id:1,
>>> nodeIP:MYIPADDRESSHERE
>>> 2013-04-16 20:58:42,138 INFO  [cloud.cluster.ClusterManagerImpl]
>>> (Cluster-Heartbeat-1:null) Trying to connect to MYIPADDRESSHERE
>>> 2013-04-16 20:58:42,138 INFO  [cloud.cluster.ClusterManagerImpl]
>>> (Cluster-Heartbeat-1:null) Management node 1 is detected inactive
>>>by
>>> timestamp but is pingable
>>> 
>>> ===
>> 
> 
 
>>> 
>> 
>

Re: [ACS41] API Compatibility Bug?

[Chip Childers]

On Thu, Apr 18, 2013 at 11:07:18AM -0700, Alena Prokharchyk wrote:
> On 4/18/13 11:02 AM, "Chip Childers"  wrote:
> 
> >On Thu, Apr 18, 2013 at 10:57:51AM -0700, Alena Prokharchyk wrote:
> >> On 4/18/13 10:48 AM, "Chip Childers"  wrote:
> >> 
> >> >On Thu, Apr 18, 2013 at 10:46:38AM -0700, Alena Prokharchyk wrote:
> >> >> I would probably leave it for 4.2.0. And update the release notes for
> >> >>4.0
> >> >> 
> >> >> Chip, what do you think?
> >> >
> >> >Doesn't 4.1 actually have the right code in it already?
> >> >
> >> >I think Joe is asking about the 4.0 branch, since he's about to cut the
> >> >second RC for that code line.
> >> 
> >> 
> >> 4.1 does have correct code. Chip, would you advise to patch 4.0? It
> >>would
> >> require java code changes - fixing annotations in the APIs. Then we have
> >> to generate new xml/html api docs.
> >> 
> >> -Alena.
> >
> >Joe's the RM for the 4.0.2 release.  I think he's asking about (1)
> >impact, (2) risk and (3) how quick the fix will be.  We're about to
> >start another round of voting for 4.0.2, and generating new API docs
> >will be part of that release process anyway.  The question is really
> >intended to get the code clean so that the (hopefully) last 4.0.x
> >release has correct docs in it.
> >
> 
> 
> There is a minimal impact - only api docs will get affected, and the fix
> should be relatively quick as all we have to do is to fix @Implementation
> parameter in 3 java classes.
> 
>

I *think* joe would love a patch for the 4.0 branch for this!

Re: [ACS41] API Compatibility Bug?

[Alena Prokharchyk]

On 4/18/13 11:02 AM, "Chip Childers"  wrote:

>On Thu, Apr 18, 2013 at 10:57:51AM -0700, Alena Prokharchyk wrote:
>> On 4/18/13 10:48 AM, "Chip Childers"  wrote:
>> 
>> >On Thu, Apr 18, 2013 at 10:46:38AM -0700, Alena Prokharchyk wrote:
>> >> I would probably leave it for 4.2.0. And update the release notes for
>> >>4.0
>> >> 
>> >> Chip, what do you think?
>> >
>> >Doesn't 4.1 actually have the right code in it already?
>> >
>> >I think Joe is asking about the 4.0 branch, since he's about to cut the
>> >second RC for that code line.
>> 
>> 
>> 4.1 does have correct code. Chip, would you advise to patch 4.0? It
>>would
>> require java code changes - fixing annotations in the APIs. Then we have
>> to generate new xml/html api docs.
>> 
>> -Alena.
>
>Joe's the RM for the 4.0.2 release.  I think he's asking about (1)
>impact, (2) risk and (3) how quick the fix will be.  We're about to
>start another round of voting for 4.0.2, and generating new API docs
>will be part of that release process anyway.  The question is really
>intended to get the code clean so that the (hopefully) last 4.0.x
>release has correct docs in it.
>


There is a minimal impact - only api docs will get affected, and the fix
should be relatively quick as all we have to do is to fix @Implementation
parameter in 3 java classes.

Re: [ACS41] API Compatibility Bug?

[Chip Childers]

On Thu, Apr 18, 2013 at 10:57:51AM -0700, Alena Prokharchyk wrote:
> On 4/18/13 10:48 AM, "Chip Childers"  wrote:
> 
> >On Thu, Apr 18, 2013 at 10:46:38AM -0700, Alena Prokharchyk wrote:
> >> I would probably leave it for 4.2.0. And update the release notes for
> >>4.0
> >> 
> >> Chip, what do you think?
> >
> >Doesn't 4.1 actually have the right code in it already?
> >
> >I think Joe is asking about the 4.0 branch, since he's about to cut the
> >second RC for that code line.
> 
> 
> 4.1 does have correct code. Chip, would you advise to patch 4.0? It would
> require java code changes - fixing annotations in the APIs. Then we have
> to generate new xml/html api docs.
> 
> -Alena.

Joe's the RM for the 4.0.2 release.  I think he's asking about (1)
impact, (2) risk and (3) how quick the fix will be.  We're about to
start another round of voting for 4.0.2, and generating new API docs
will be part of that release process anyway.  The question is really
intended to get the code clean so that the (hopefully) last 4.0.x
release has correct docs in it.

Re: DevCloud

[Mike Tutkowski]

I have a related issue.  I sent it out under a different thread, but should
put it here, too.

This is my issue.  I'm not sure how to get around it.  Thanks!!

mtutkowski-LT:devcloud mtutkowski$ python
../marvin/marvin/deployDataCenter.py -i devcloud.cfg
Traceback (most recent call last):
  File "../marvin/marvin/deployDataCenter.py", line 21, in 
import cloudstackTestClient
  File
"/Users/mtutkowski/Documents/CloudStack/src/incubator-cloudstack/tools/marvin/marvin/cloudstackTestClient.py",
line 18, in 
import cloudstackConnection
  File
"/Users/mtutkowski/Documents/CloudStack/src/incubator-cloudstack/tools/marvin/marvin/cloudstackConnection.py",
line 18, in 
import requests
ImportError: No module named requests


On Thu, Apr 18, 2013 at 11:51 AM, Rohit Yadav  wrote:

> On Thu, Apr 18, 2013 at 10:17 PM, Aaron Paradowski
> wrote:
>
> > Hi Rohit,
> >
> > ** **
> >
> > I’m having some problems deploying DevCloud2 and wonder if you could help
> > please. So far I have done the following
> >
> > ** **
> >
> > **1.   **Downloaded and imported the DevCloud2 image into VirtualBox
> > – ensured network settings were correct etc.
> >
> > **2.   **Used PuTTY to SSH to the machine at 192.168.56.10 and logged
> > in with root and password for username and password
> >
> > **3.   **cd to /opt/cloudstack
> >
> > **4.   **git cloned into the source code for incubator cloudstack
> >
> > **5.   **once that had completed I cd’d to the incubator-cloudstack
> > directory
> >
> > **6.   **Ran mvn clean install –P developer,systemvm
> >
> > **7.   **Changedthe host value in devcloud.sql to 192.168.56.10 as I
> > want everything to run inside this one VM
> >
> > **8.   **Ran mvn –pl developer,tools/devloud –Deploydb –P developer
> >
>
> Hi Aaron,
>
> The best way is to reach to the whole community and cc any particular
> person whose attention you may be seeking.
>
> 1-8: So far so good, ignoring the -Ddeploydb typo.
>
>
> > 
> >
> > 9.   Then ran mvn-pl client jetty:run and this is where everything
> > goes wrong. It hangs on the below screen for ages then it goes through
> lots
> > of warnings and errors such as “WARN [apache.cloudstack.alerts] (HA-3:)
> > alertType:: 13” – I left it for 19 hours overnight last night and those
> > types of errors just kept going round in cycles?
> >
> Looks like CloudStack issue? Did you try exporting maven opts, checkout the
> building on master on cwiki.apache.org / cloudstack and try again?
>
> If you're just able to login inside DevCloud2 and run something like xe
> vm-list and it outputs something we're good at least from DevCloud's side
> :)
>
> Anyone from community?
>
> Cheers.
>
>
> > 
> >
> > 
> >
> > ** **
> >
> > Any help would be greatly appreciated! Many thanks in advance.
> >
> > ** **
> >
> > Kind Regards,
> >
> > ** **
> >
> > *Aaron Paradowski*
> >
> > ** **
> >
>



-- 
*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: [ACS41] API Compatibility Bug?

[Alena Prokharchyk]

On 4/18/13 10:48 AM, "Chip Childers"  wrote:

>On Thu, Apr 18, 2013 at 10:46:38AM -0700, Alena Prokharchyk wrote:
>> I would probably leave it for 4.2.0. And update the release notes for
>>4.0
>> 
>> Chip, what do you think?
>
>Doesn't 4.1 actually have the right code in it already?
>
>I think Joe is asking about the 4.0 branch, since he's about to cut the
>second RC for that code line.


4.1 does have correct code. Chip, would you advise to patch 4.0? It would
require java code changes - fixing annotations in the APIs. Then we have
to generate new xml/html api docs.

-Alena.


>
>> 
>> -Alena.
>> 
>> On 4/18/13 10:34 AM, "Joe Brockmeier"  wrote:
>> 
>> >On Thu, Apr 18, 2013, at 12:18 PM, Alena Prokharchyk wrote:
>> >> The same issue for DeleteUser. Basically there are no changes in the
>> >> commands, they were just documented wrong in 4.0.
>> >
>> >Would it be possible to do up a quick patch for this, or just leave it
>> >for 4.0.2?
>> >
>> >Best,
>> >
>> >jzb
>> >-- 
>> >Joe Brockmeier
>> >j...@zonker.net
>> >Twitter: @jzb
>> >http://www.dissociatedpress.net/
>> >
>> 
>> 
>> 
>

Re: deployDataCenter.py doesn't work for me on master

[Mike Tutkowski]

Is this similar to the problem you are now having?  I get the following
output from the python script to create DevCloud:

mtutkowski-LT:devcloud mtutkowski$ python
../marvin/marvin/deployDataCenter.py -i devcloud.cfg
Traceback (most recent call last):
  File "../marvin/marvin/deployDataCenter.py", line 21, in 
import cloudstackTestClient
  File
"/Users/mtutkowski/Documents/CloudStack/src/incubator-cloudstack/tools/marvin/marvin/cloudstackTestClient.py",
line 18, in 
import cloudstackConnection
  File
"/Users/mtutkowski/Documents/CloudStack/src/incubator-cloudstack/tools/marvin/marvin/cloudstackConnection.py",
line 18, in 
import requests
ImportError: No module named requests

Not sure how to get around this.


On Wed, Apr 17, 2013 at 10:56 AM, Soheil Eizadi wrote:

> I copied the vhd-util from
> http://download.cloud.com.s3.amazonaws.com/tools/vhd-util to
> scripts/vm/hypervisor/xenserver/vhd-util in the tree, but it did not
> resolve my issue. (The problem is not with the functionality of the
> vhd-util but a path problem. I get that the vhd-util should be updated and
> I have done that as well in my environment.)
>
> As I noted below the problem is that it is not getting copied to right
> place and also I find different versions of the higher level script i.e.
> copy_vhd_from_secondarystorage.sh in my tree which is strange. There is
> different vhd-util paths in them.
> -Soheil
>
>
> On 4/15/13 4:07 PM, "Anthony Xu"  wrote:
>
> >>>The XenServer (6.0.2) I am using already came bundled with vhd-util, I
> >>>did not have to download it. I have not read the detail of
> >
> >Hi Soheil,
> >
> >We added one function in vhd-util, which allows vhd-util specifiy parent
> >when do coalesce, basically you can coalesce a VHD file to other VHD
> >file.
> >CS uses this vhd-util function in API creating template/volume from
> >snapshot.  These APIs might not work with bundled vhd-util in XenServer.
> >
> >
> >Anthony
> >
> >
> >
> >-Original Message-
> >From: Soheil Eizadi [mailto:seiz...@infoblox.com]
> >Sent: Saturday, April 13, 2013 11:05 PM
> >To: dev@cloudstack.apache.org
> >Subject: Re: deployDataCenter.py doesn't work for me on master
> >
> >Downloaded the vhd-util to my environment and had the same problem. I
> >Debugged this further by running the copy_vhd_from_secondarystorage.sh on
> >the XenServer. It looks like the copy_vhd_from_secondarystorage.sh is
> >looking for vhd-util in /opt/xensource/bin/ rather than /usr/bin/
> >
> >I looked at this further and looks like what is built in the
> >client/target directory is not consistent with what is in the
> >./scripts/vm in my tree.
> >There are two versions of copy_vhd_from_secondarystorage.sh.
> >
> >I removed the client/target directory and rebuilt, but had the same files
> >appear again. I am not sure how they are getting pulled in to the
> >client/target directory. Any ideas why my build is broken and how to
> >proceed to fix this?
> >
> >For now I patched this on my XenServer and was able to get ssvm and
> >cproxyvm running and brought up my CloudStack zone completely.
> >-Soheil
> >
> >
> >Administrators-MacBook-Pro-7:cloudstack seizadi$ find . -name
> >copy_vhd_from_secondarystorage.sh
> >./client/target/cloud-client-ui-4.2.0-SNAPSHOT/WEB-INF/classes/scripts/vm/
> >h
> >ypervisor/xenserver/copy_vhd_from_secondarystorage.sh
> >./client/target/cloud-client-ui-4.2.0-SNAPSHOT/WEB-INF/classes/scripts/vm/
> >h
> >ypervisor/xenserver/xcposs/copy_vhd_from_secondarystorage.sh
> >./client/target/generated-webapp/WEB-INF/classes/scripts/vm/hypervisor/xen
> >s
> >erver/copy_vhd_from_secondarystorage.sh
> >./client/target/generated-webapp/WEB-INF/classes/scripts/vm/hypervisor/xen
> >s
> >erver/xcposs/copy_vhd_from_secondarystorage.sh
> >./scripts/vm/hypervisor/xenserver/copy_vhd_from_secondarystorage.sh
> >./scripts/vm/hypervisor/xenserver/xcposs/copy_vhd_from_secondarystorage.sh
> >
> >
> >Administrators-MacBook-Pro-7:cloudstack seizadi$ find . -name
> >copy_vhd_from_secondarystorage.sh -exec diff
> >./client/target/generated-webapp/WEB-INF/classes/scripts/vm/hypervisor/xen
> >s
> >erver/copy_vhd_from_secondarystorage.sh {} \;
> >92c92
> >< VHDUTIL="/opt/xensource/bin/vhd-util"
> >---
> >> VHDUTIL="/usr/bin/vhd-util"
> >113c113
> >< if [ $type != "nfs" -a $type != "ext" ]; then
> >---
> >> if [ $type != "nfs" -a $type != "ext" -a $type != "file" ]; then
> >143c143
> ><   desvhd=/var/run/sr-mount/$sruuid/$uuid.vhd
> >---
> >>   desvhd=/run/sr-mount/$sruuid/$uuid.vhd
> >160a161,166
> >> elif [ $type == "file" ]; then
> >>   pbd=`xe sr-param-list uuid=$sruuid |grep PBDs | awk '{print $3}'`
> >>   path=`xe pbd-param-list uuid=$pbd |grep device-config |awk '{print
> >>$4}'`
> >>   desvhd=$path/$uuid.vhd
> >>   copyvhd $desvhd $vhdfile 0 $type
> >>
> >92c92
> >< VHDUTIL="/opt/xensource/bin/vhd-util"
> >---
> >> VHDUTIL="/usr/bin/vhd-util"
> >113c113
> >< if [ $type != "nfs" -a $type != "ext" ]; then
> >---
> >> if [ $type != "nfs" -a $t

Re: Review Request: Documentation changes for VMware dvSwitch and Nexus dvSwitch

[Sateesh Chodapuneedi]

> On April 10, 2013, 7:42 a.m., Sateesh Chodapuneedi wrote:
> > Section 8.3.7.5 Removing Nexus Virtual Switch is specifying steps to delete 
> > VMware dvSwitch. This is not correct. There is no notion of deletion of 
> > VMware dvSwitch (please refer to FS for the feature) in CloudStack. Please 
> > remove section completely.
> > In page 109,  replace 'configuring' by 'orchestration of in the line 
> > "CloudStack supports configuring virtual networks in a deployment with"
> > In page 110, against the table entry "vCenter Host" - description should be 
> > vCenter host/ip. Presence of Nexus virtual switch is irrelevant for the 
> > vCenter here.
> > In page 110, against the table entry "Guest Traffic vSwitch Name" - 
> > description should be "Name of virtual switch to be used for guest traffic"
> > In page 110, against the table entry "Public Traffic vSwitch Name" - 
> > description should be "Name of virtual switch to be used for public traffic"
> > In page 109, use Distributed Virtual Switch instead of "Virtual Distributed 
> > Switch"
> > In page 109, instead of 'Nexus 1000v Virtual Switch' better to write 'Nexus 
> > 1000v Distributed Virtual Switch'
> > Add cluster parameters documented in page 62, is fine, reviewed.
> > As mentioned in FS, pre-requisites is to pre-provision dvSwitch in 
> > datacenter that is containing cluster being managed by cloudstack.
> > 
> >
> 
> Radhika PC wrote:
> Is pre-provisioning the dvSwitch in the datacenter is the only 
> prerequisite? do we have to note down any parameters, that could be later 
> used in CloudStack ? Please confirm.
> 
> Radhika PC wrote:
> The FS listed the following:
> 
> CloudStack does following,
> Create dvPortGroup over designated dvSwitch - How ? 
> Modify dvPortGroup over designated dvSwitch -How?
> Delete dvPortGroup over designated dvSwitch - How ? Is 
> deleting/creating/modifying dvPortGroup similar to deleting dvSwitch ? Could 
> you please clarify.
> 
> Radhika PC wrote:
> FS states:
> 
> Deployment requirements (fresh install vs. upgrade) if any
> 
> VMware dvSwitch must be already created/configured in the vCenter 
> datacenter deployment (understood!)
> 
> All the host/cluster resources should be added to dvSwitch before adding 
> the cluster to CloudStack's pod cluster. (it is not clear this step need to 
> be done on vCenter or CloudStack). It is very difficult to document such a 
> complex feature without a setup.
> 
> Radhika PC wrote:
> FS states:
> 
> Explain performance & scalability implications when feature is used from 
> small scale to large scale
> In case of vSphere 4.1 dvPortGroup need to be created with specific 
> number of dvPorts. In large scale deployment optimum use of dvPorts may not 
> be possible due to this pre-allocation. In case of vSphere 5.0 the autoexpand 
> feature helps in auto increment of number of dvPorts. (what is the specific 
> number here ?)
> 
> Network switches (including the vSwitch in ESXi host) keep a distinct 
> forwarding table for each VLAN; this could lead to an increased overhead in 
> packet forwarding when a considerable number of isolated networks, each one 
> with a significant number of virtual machines, is configured in a data 
> center. (Is this a limitation? should it be mentioned?) please clarify
> 
> Radhika PC wrote:
> The comments states:
> 
> In page 110, against the table entry "Guest Traffic vSwitch Name" - 
> description should be "Name of virtual switch to be used for guest traffic"
> In page 110, against the table entry "Public Traffic vSwitch Name" - 
> description should be "Name of virtual switch to be used for public traffic"
> 
> Question: From where do you pick up/ specify a name for the traffic ? Is 
> this something that we get from vCenter setup ? Or are we saying to mention 
> what type of switch to be used ?
> 
> Radhika PC wrote:
> Comment states:
> 
> In page 109, use Distributed Virtual Switch instead of "Virtual 
> Distributed Switch"
> 
> But in VMware terms it is "VMware vSphere Distributed Switch (VDS)" see  
> see http://blogs.vmware.com/vsphere/tag/distributed-switch
> 
> Shouldn't be we following similar terminology ?

>do we have to note down any parameters, that could be later used in CloudStack 
>? Please confirm.
User might want to specify name of dvSwitch in following places,
1) traffic label in physical network page of zone configuration wizard - This 
setting dictates name of vSwitch/dvSwitch to be used for virtual network 
orchestration later.
2) public/guest virtual switch na,e - This setting overrides the 
vSwitch/dvSwitch name in zone level configuration setting for traffic label. 
See (1) above.

>Is deleting/creating/modifying dvPortGroup similar to deleting dvSwitch ? 
>Could you please clarify.
No.

>All the host/cluster resources should be added to dvSwitch before adding the 
>cluster to CloudSt

Re: DevCloud

[Rohit Yadav]

On Thu, Apr 18, 2013 at 10:17 PM, Aaron Paradowski
wrote:

> Hi Rohit,
>
> ** **
>
> I’m having some problems deploying DevCloud2 and wonder if you could help
> please. So far I have done the following
>
> ** **
>
> **1.   **Downloaded and imported the DevCloud2 image into VirtualBox
> – ensured network settings were correct etc.
>
> **2.   **Used PuTTY to SSH to the machine at 192.168.56.10 and logged
> in with root and password for username and password
>
> **3.   **cd to /opt/cloudstack
>
> **4.   **git cloned into the source code for incubator cloudstack
>
> **5.   **once that had completed I cd’d to the incubator-cloudstack
> directory
>
> **6.   **Ran mvn clean install –P developer,systemvm
>
> **7.   **Changedthe host value in devcloud.sql to 192.168.56.10 as I
> want everything to run inside this one VM
>
> **8.   **Ran mvn –pl developer,tools/devloud –Deploydb –P developer
>

Hi Aaron,

The best way is to reach to the whole community and cc any particular
person whose attention you may be seeking.

1-8: So far so good, ignoring the -Ddeploydb typo.


> 
>
> 9.   Then ran mvn-pl client jetty:run and this is where everything
> goes wrong. It hangs on the below screen for ages then it goes through lots
> of warnings and errors such as “WARN [apache.cloudstack.alerts] (HA-3:)
> alertType:: 13” – I left it for 19 hours overnight last night and those
> types of errors just kept going round in cycles?
>
Looks like CloudStack issue? Did you try exporting maven opts, checkout the
building on master on cwiki.apache.org / cloudstack and try again?

If you're just able to login inside DevCloud2 and run something like xe
vm-list and it outputs something we're good at least from DevCloud's side :)

Anyone from community?

Cheers.


> 
>
> 
>
> ** **
>
> Any help would be greatly appreciated! Many thanks in advance.
>
> ** **
>
> Kind Regards,
>
> ** **
>
> *Aaron Paradowski*
>
> ** **
>

Re: [ACS41] API Compatibility Bug?

[Chip Childers]

On Thu, Apr 18, 2013 at 10:46:38AM -0700, Alena Prokharchyk wrote:
> I would probably leave it for 4.2.0. And update the release notes for 4.0
> 
> Chip, what do you think?

Doesn't 4.1 actually have the right code in it already?

I think Joe is asking about the 4.0 branch, since he's about to cut the
second RC for that code line.

> 
> -Alena.
> 
> On 4/18/13 10:34 AM, "Joe Brockmeier"  wrote:
> 
> >On Thu, Apr 18, 2013, at 12:18 PM, Alena Prokharchyk wrote:
> >> The same issue for DeleteUser. Basically there are no changes in the
> >> commands, they were just documented wrong in 4.0.
> >
> >Would it be possible to do up a quick patch for this, or just leave it
> >for 4.0.2?
> >
> >Best,
> >
> >jzb
> >-- 
> >Joe Brockmeier
> >j...@zonker.net
> >Twitter: @jzb
> >http://www.dissociatedpress.net/
> >
> 
> 
> 

[ACS41] CLOUDSTACK-2093 is a new critical bug for the storage-focused folks!

[Chip Childers]

Can someone please look at this (Edison, I CC'ed you, perhaps
inappropriately, with the hope that you would be able to look at this).

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

The reporter noted a very specific example of where the call to
create_privatetemplate_from_snapshot is passing the wrong parameter.

-chip

Re: [ACS41] API Compatibility Bug?

[Alena Prokharchyk]

I would probably leave it for 4.2.0. And update the release notes for 4.0

Chip, what do you think?

-Alena.

On 4/18/13 10:34 AM, "Joe Brockmeier"  wrote:

>On Thu, Apr 18, 2013, at 12:18 PM, Alena Prokharchyk wrote:
>> The same issue for DeleteUser. Basically there are no changes in the
>> commands, they were just documented wrong in 4.0.
>
>Would it be possible to do up a quick patch for this, or just leave it
>for 4.0.2?
>
>Best,
>
>jzb
>-- 
>Joe Brockmeier
>j...@zonker.net
>Twitter: @jzb
>http://www.dissociatedpress.net/
>