[GitHub] cloudstack pull request: Cloudstack 8612
GitHub user likitha opened a pull request: https://github.com/apache/cloudstack/pull/562 Cloudstack 8612 To ensure that setting a high timeout value for snapshot backup operation will not affect vCenter connections made for any other operations besides volume snapshot, split the existing vCenter session timeout configuration into two configurations, 1. To tune timeout value for CS's session vCenter during snapshot backup operation - 'vmware.snapshot.backup.session.timeout' (new; default: 20 minutes) 2. For all other operations - 'vmware.vcenter.session.timeout' (existing; default: 20 minutes) Additional change - Users could potentially run into a timeout issue while trying to snapshot large VMs. There is a timeout for async-jobs that ensures that any job that has been in process for too long is cancelled by CSMS. This timeout is configurable using a global configuration âjob.cancel.threshold.minutesâ and it defaults to 1 hour. Now for large volumes even though users configure other snapshot timeout values (âvmware.snapshot.backup.session.timeoutâ and âbackup.snapshot.waitâ) to a very high value, the snapshot operation will still fail because the job will be cancelled in 1 hour. Hence proposing a configuration that will allow admins to separate out the job cancellation timeout for âvolume snapshotâ jobs from other vm work jobs - 'volume.snapshot.job.cancel.threshold'. You can merge this pull request into a Git repository by running: $ git pull https://github.com/likitha/cloudstack CLOUDSTACK-8612 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/cloudstack/pull/562.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #562 commit 1093a9626e1d401ba3501882797c2ea2b0fd54c7 Author: Likitha Shetty Date: 2015-04-30T05:05:57Z CLOUDSTACK-8612. [VMware] Make vCenter session timeout configurable for volume snapshot. Separate out vmware vcenter session timeout config for volume snapshot backup operation. commit c8c9d81b0c2f08f506e828453efbed7911d9a517 Author: Likitha Shetty Date: 2015-05-05T08:29:49Z CLOUDSTACK-8612. [VMware] Make vCenter session timeout configurable for volume snapshot. Separate out async job timeout for volume snapshot job from other vm work jobs. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] cloudstack pull request: CLOUDSTACK-8611. CS waits indefinitely fo...
GitHub user likitha opened a pull request: https://github.com/apache/cloudstack/pull/561 CLOUDSTACK-8611. CS waits indefinitely for CheckS2SVpnConnectionsComm⦠â¦and to return. While remote executing commands through ssh, handle channel condition of EOF because we wait for the the condition. CheckS2SVpnConnectionsCommand execution involves executing a script (checkbatchs2svpn.sh) in the virtual router. Once CS has opened a session to a virtual router and executed a script in the router, it waits indefinitely till the session either times-out or the exit status of the remote process is available. But it is possible that an EOF is reached by the process in the router and the router never set the exit status. References - 1. Some servers never send the exist status, or occasionally "forget" to do so (http://grepcode.com/file/repo1.maven.org/maven2/org.jvnet.hudson/trilead-ssh2/build212-hudson-1/com/trilead/ssh2/ChannelCondition.java). 2. Get the exit code/status from the remote command - if available. Be careful - not all server implementations return this value - (http://grepcode.com/file/repo1.maven.org/maven2/org.jvnet.hudson/trilead-ssh2/build212-hudson-1/com/trilead/ssh2/Session.java#Session.waitForCondition%28int%2Clong%29). Hence if exit status is not set then the command will never return. You can merge this pull request into a Git repository by running: $ git pull https://github.com/likitha/cloudstack CLOUDSTACK-8611 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/cloudstack/pull/561.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #561 commit b9181c689e0e7b5f1e28c81d73710196dfabd0ba Author: Likitha Shetty Date: 2015-05-01T11:14:51Z CLOUDSTACK-8611. CS waits indefinitely for CheckS2SVpnConnectionsCommand to return. While remote executing commands through ssh, handle channel condition of EOF because we wait for the the condition. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] cloudstack pull request: CLOUDSTACK-8609. [VMware] VM is not acces...
GitHub user likitha opened a pull request: https://github.com/apache/cloudstack/pull/556 CLOUDSTACK-8609. [VMware] VM is not accessible after a migration acro⦠â¦ss clusters. Once a VM is successfully started, don't delete the files associated with the unregistered VM, if the files are in a storage that is being used by the new VM. Attempt to unregister a VM in another DC, only if there is a host associated with a VM. You can merge this pull request into a Git repository by running: $ git pull https://github.com/likitha/cloudstack CLOUDSTACK-8609 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/cloudstack/pull/556.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #556 commit a97a402f304303af78552777d5fde56abab902e5 Author: Likitha Shetty Date: 2015-05-15T08:44:37Z CLOUDSTACK-8609. [VMware] VM is not accessible after a migration across clusters. Once a VM is successfully started, don't delete the files associated with the unregistered VM, if the files are in a storage that is being used by the new VM. Attempt to unregister a VM in another DC, only if there is a host associated with a VM. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] cloudstack pull request: CLOUDSTACK-8608. System VM's failed to st...
GitHub user likitha opened a pull request: https://github.com/apache/cloudstack/pull/555 CLOUDSTACK-8608. System VM's failed to start due to permissions issue. â¦instance. You can merge this pull request into a Git repository by running: $ git pull https://github.com/likitha/cloudstack CLOUDSTACK-8608 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/cloudstack/pull/555.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #555 commit 7b87e8a4184c046917f71627db9a20871ae981b4 Author: Likitha Shetty Date: 2015-04-20T12:59:55Z CLOUDSTACK-8608. System VM's failed to start due to permissions issue. Provide permissions to template folder when mounted on management server. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] cloudstack pull request: CLOUDSTACK-8610. Unable to attach 7th Dis...
GitHub user likitha opened a pull request: https://github.com/apache/cloudstack/pull/554 CLOUDSTACK-8610. Unable to attach 7th Disk to Windows Server 2012 R2 ⦠â¦instance. During disk attach, while trying to obtain the controller key for SCSI controller, look for device with the generic SCSI controller type i.e. VirtualSCSIController. While trying to obtain the SCSI id to attach a disk to, CS should ignore the reserved SCSI id 7. But this is not being honored in case of VMs with SCSI controller of type 'VirtualLsiLogicSASController'. And so in case of Windows 2012 R2 VMs, CS chooses to attach the 7th disk on the reserved SCSI id and this fails on vCenter. You can merge this pull request into a Git repository by running: $ git pull https://github.com/likitha/cloudstack CLOUDSTACK-8610 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/cloudstack/pull/554.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #554 commit cbfcf7cccf75c54decdcfa0c1185c42cb69d0a7a Author: Likitha Shetty Date: 2015-06-01T08:53:56Z CLOUDSTACK-8610. Unable to attach 7th Disk to Windows Server 2012 R2 instance. During disk attach, while trying to obtain the controller key for SCSI controller, look for device with the generic SCSI controller type i.e. VirtualSCSIController. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] cloudstack pull request: CLOUDSTACK-8602. MigrateVirtualMachineWit...
GitHub user likitha opened a pull request: https://github.com/apache/cloudstack/pull/548 CLOUDSTACK-8602. MigrateVirtualMachineWithVolume leaves old chain dat⦠â¦a for volume. Update chain info of a volume after migration. You can merge this pull request into a Git repository by running: $ git pull https://github.com/likitha/cloudstack CLOUDSTACK-8602 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/cloudstack/pull/548.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #548 commit fc33dc35645d52caf5cdbed112101df83104feab Author: Likitha Shetty Date: 2015-04-17T18:33:26Z CLOUDSTACK-8602. MigrateVirtualMachineWithVolume leaves old chain data for volume. Update chain info of a volume after migration. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] cloudstack pull request: CLOUDSTACK-8597. Failed to migrate volume...
Github user likitha commented on the pull request: https://github.com/apache/cloudstack/pull/541#issuecomment-117559997 Thanks for taking the time to review @wilderrodrigues. I have updated the issue description. As far as 'StorageAction.DELETEVOLUME' is concerned I am not entirely sure if the same logic applies to HyperV, In case of VMware since we can't access volume managed object, we reconfigure the VM managed object to detach the volume and further delete it. And that is why we choose the endpoint based on the VM. I am not sure if we have the same problem in HyperV. In any case I will open a ticket to track it, that way we a HyperV expert can comment on it. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] cloudstack pull request: CLOUDSTACK-8597. Failed to migrate volume...
Github user likitha commented on the pull request: https://github.com/apache/cloudstack/pull/541#issuecomment-117526563 Yes, now in addition to HyperV, even in case of VMware we want CS to chose the host containing the VM as the endpoint when the storage actions is 'MIGRATEVOLUME'. Since the code to do that already exists because of HyperV, I simply added a check for VMware there. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] cloudstack pull request: CLOUDSTACK-8597. Failed to migrate volume...
Github user likitha commented on the pull request: https://github.com/apache/cloudstack/pull/541#issuecomment-117515627 @wilderrodrigues , Background - 1. When CS tries to live migrate a volume, it chooses a host endpoint to perform the migration by selecting any host that has the storage containing the volume mounted on it. Now when we attempt to migrate a volume that is on a zone wide storage, the endpoint could be any host in the zone because in case of zone wide storage, every host in the zone has the storage mounted on it. 2. During migration, vCenter expects the target datastore/storage pool to be mounted on the source host because the VM obviously needs to be able to access the target datastore. Now in the mentioned issue, say a host that doesn't contain the VM is chosen as the endpoint. As mentioned above, it could happen because today CS chooses any host that has the source storage mounted on it. In that case migration will fail because this host cant see the target datastore. By picking the host containing the volume's VM as endpoint we ensure that both the source and target storage pools are visible to the VM irrespective of the scope of the storage pool. Previously, similar fixes have been made for other operations like volume deletion, snapshot creation because in these cases as well the underlying resource needs the VM of the volume to be visible to the host endpoint. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] cloudstack pull request: CLOUDSTACK-8601. VMFS storage added as lo...
GitHub user likitha opened a pull request: https://github.com/apache/cloudstack/pull/547 CLOUDSTACK-8601. VMFS storage added as local storage can be re-added ⦠â¦as shared storage. Fail addition of a VMFS shared storage pool in case it has already been added as local storage in CS. You can merge this pull request into a Git repository by running: $ git pull https://github.com/likitha/cloudstack CLOUDSTACK-8601 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/cloudstack/pull/547.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #547 commit 13a98dd196c8b0f86e4fb68db357df41767535f9 Author: Likitha Shetty Date: 2015-04-17T13:17:23Z CLOUDSTACK-8601. VMFS storage added as local storage can be re-added as shared storage. Fail addition of a VMFS shared storage pool in case it has already been added as local storage in CS. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] cloudstack pull request: CLOUDSTACK-8600. Upon detaching a disk, d...
GitHub user likitha opened a pull request: https://github.com/apache/cloudstack/pull/545 CLOUDSTACK-8600. Upon detaching a disk, delete VM folder if empty. You can merge this pull request into a Git repository by running: $ git pull https://github.com/likitha/cloudstack CLOUDSTACK-8600 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/cloudstack/pull/545.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #545 commit b3f1d46294d54db2593205f1e6ee9653010ba12e Author: Likitha Shetty Date: 2015-04-16T08:52:13Z CLOUDSTACK-8600. Upon detaching a disk, delete VM folder if empty. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] cloudstack pull request: CLOUDSTACK-8598. CS reports migration as ...
Github user likitha commented on the pull request: https://github.com/apache/cloudstack/pull/542#issuecomment-117069118 Yes, since migration is only one of the many affected operations, it seemed appropriate to merge it with https://github.com/apache/cloudstack/pull/543. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] cloudstack pull request: CLOUDSTACK-8599. CS reports failure for a...
GitHub user likitha opened a pull request: https://github.com/apache/cloudstack/pull/544 CLOUDSTACK-8599. CS reports failure for a successful migration. While cancelling a vCenter task, check if the task is cancellable and wait for the task to complete. You can merge this pull request into a Git repository by running: $ git pull https://github.com/likitha/cloudstack CLOUDSTACK-8599 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/cloudstack/pull/544.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #544 commit cefe30238b2aab1d84c029e326e61ca3813d8c91 Author: Likitha Shetty Date: 2015-04-10T10:31:36Z CLOUDSTACK-8599. CS reports failure for a successful migration. While cancelling a vCenter task, check if the task is cancellable and wait for the task to complete. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] cloudstack pull request: CLOUDSTACK-8598. CS reports volume migrat...
GitHub user likitha opened a pull request: https://github.com/apache/cloudstack/pull/543 CLOUDSTACK-8598. CS reports volume migration as successful but the vo⦠â¦lume is not migrated in vCenter.. For the following disk operations - migration, snapshot creation, resize, detach and template creation, CS should do an exact disk match between volume path and vCenter disk name. If the exact matching fails to find a disk, CS should fall back to the old method of partial matching on a trimmed disk. You can merge this pull request into a Git repository by running: $ git pull https://github.com/likitha/cloudstack CLOUDSTACK-8598 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/cloudstack/pull/543.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #543 commit f5db6a81f83ee42e7a557c0c099ea3463857c554 Author: Likitha Shetty Date: 2015-04-09T05:25:12Z CLOUDSTACK-8598. CS reports volume migration as successful but the volume is not migrated in vCenter.. For the following disk operations - migration, snapshot creation, resize, detach and template creation, CS should do an exact disk match between volume path and vCenter disk name. If the exact matching fails to find a disk, CS should fall back to the old method of partial matching on a trimmed disk. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] cloudstack pull request: CLOUDSTACK-8598. CS reports migration as ...
Github user likitha closed the pull request at: https://github.com/apache/cloudstack/pull/542 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] cloudstack pull request: CLOUDSTACK-8598. CS reports migration as ...
GitHub user likitha opened a pull request: https://github.com/apache/cloudstack/pull/542 CLOUDSTACK-8598. CS reports migration as successful but the volume is⦠⦠not migrated in vCenter. During migration, CS should do an exact disk match between volume path and vCenter disk name. You can merge this pull request into a Git repository by running: $ git pull https://github.com/likitha/cloudstack CLOUDSTACK-8598 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/cloudstack/pull/542.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #542 commit 2c86dc31374d7d4a46a01af0200777f64ab99c1f Author: Likitha Shetty Date: 2015-04-09T05:25:12Z CLOUDSTACK-8598. CS reports migration as successful but the volume is not migrated in vCenter. During migration, CS should do an exact disk match between volume path and vCenter disk name. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] cloudstack pull request: CLOUDSTACK-8597. Failed to migrate volume...
GitHub user likitha opened a pull request: https://github.com/apache/cloudstack/pull/541 CLOUDSTACK-8597. Failed to migrate volume from zone-wide to cluster-w⦠â¦ide storage. While live migrating a volume, CS chooses the endpoint to perform the migration by selecting any host that has the storage containing the volume mounted on it. Instead, if the volume is attached to a running VM, the endpoint chosen by CS should be the host that contains the VM. You can merge this pull request into a Git repository by running: $ git pull https://github.com/likitha/cloudstack CLOUDSTACK-8597 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/cloudstack/pull/541.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #541 commit 8db51d958cab9ef46e47e9b01b3f90c9e374534f Author: Likitha Shetty Date: 2015-04-08T09:54:36Z CLOUDSTACK-8597. Failed to migrate volume from zone-wide to cluster-wide storage. While live migrating a volume, CS chooses the endpoint to perform the migration by selecting any host that has the storage containing the volume mounted on it. Instead, if the volume is attached to a running VM, the endpoint chosen by CS should be the host that contains the VM. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] cloudstack pull request: CLOUDSTACK-8415. SSVM shutdown during sna...
GitHub user likitha opened a pull request: https://github.com/apache/cloudstack/pull/540 CLOUDSTACK-8415. SSVM shutdown during snapshot operation leaves behin⦠â¦d partial unusable disks and VM snapshots in secondary storage. Enhance storage garbage collector to delete corresponding partial disks created in secondary storage and VM snapshots while expunging 'ERROR' snapshot. You can merge this pull request into a Git repository by running: $ git pull https://github.com/likitha/cloudstack CLOUDSTACK-8415 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/cloudstack/pull/540.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #540 commit da8f25e33ca41057aac26910fe6b667a41adcaa5 Author: Likitha Shetty Date: 2015-04-07T13:24:40Z CLOUDSTACK-8415. SSVM shutdown during snapshot operation leaves behind partial unusable disks and VM snapshots in secondary storage. Enhance storage garbage collector to delete corresponding partial disks created in secondary storage and VM snapshots while expunging 'ERROR' snapshot. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[CLOUDSTACK DAY SEATTLE] CFP Deadline extended to Friday, June 26.
CFP deadline for Seattle has been extended! The CFP will be held open till Friday, June 26th. So if you have a speaking proposal, please go ahead and submit it @ http://events.linuxfoundation.org/events/cloudstack-seattle/program/cfp. Thanks, Likitha
[CLOUDSTACK DAYS SEATTLE] Call for Volunteers
Last call for committers wanting to volunteer to review proposals submitted for CloudStack Day Seattle, 2015. If you want to help out, please reach out to me or Karen (cc'd). Thanks, Likitha
[CLOUDSTACK DAY SEATTLE] CFP Deadline June 12
Only ten days left until the proposal submission deadline for CloudStack Day Seattle! If you have a proposal you want to submit, please do so @ http://events.linuxfoundation.org/events/cloudstack-seattle/program/cfp. Thanks, Likitha
[CLOUDSTACK DAYS SEATTLE] Call for Volunteers
Hello CloudStack committers, If you would like to volunteer to help review proposals submitted for CloudStack Day Seattle and are a CloudStack Committer, please reach out to me or Karen (cc'd). We can start reviewing the submissions post the CFP deadline which is June 12th . Thanks, Likitha
CLOUDSTACK DAY SEATTLE] CFP Deadline June 12
Hi everyone, Just a friendly reminder that the deadline for submitting a proposal for CloudStack Day Seattle is Friday, June 12. You can submit your proposal @ http://events.linuxfoundation.org/events/cloudstack-seattle/program/cfp . Thanks, Likitha
[CLOUDSTACK DAY SEATTLE] CFP Deadline June 12
Hi everyone, As many of you are aware, CloudStack Day Seattle is going to be held the day after LinuxCon/CloudOpen North America 2015 on August 20th. The deadline for submitting a proposal for CloudStack Day Seattle is Friday, June 12. To submit a proposal visit: http://events.linuxfoundation.org/events/cloudstack-seattle/program/cfp. Thanks, Likitha
RE: Support OVA files with multiple disks for templates: CLOUDSTACK-4757
The feature is code complete and is present in feature branch (https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=shortlog;h=refs/heads/multiple-disk-ova ). But since it has been a while I don’t think it will be an easy merge into master. In any case, I will soon start working on the merge. Thanks, Likitha -Original Message- From: Abhinandan Prateek [mailto:abhinandan.prat...@shapeblue.com] Sent: Wednesday, May 6, 2015 12:28 PM To: CloudStack Dev Cc: Likitha Shetty; Sateesh Chodapuneedi Subject: Re: Support OVA files with multiple disks for templates: CLOUDSTACK-4757 Can anyone comment what state this feature is in ? > On 05-May-2015, at 11:58 am, Abhinandan Prateek > wrote: > > The work on support for ova with multiple disk was started last year. > Can someone update in what state it is in as the ticket shows that this is > still in progress ? > > FS: > https://cwiki.apache.org/confluence/display/CLOUDSTACK/Support+OVA+files+containing+multiple+disks > > <https://cwiki.apache.org/confluence/display/CLOUDSTACK/Support+OVA+files+containing+multiple+disks> > > -abhi Find out more about ShapeBlue and our range of CloudStack related services IaaS Cloud Design & Build<http://secure-web.cisco.com/18IPXeCxMuL0ZGsCjfo3x7938ovd8trrcZQ3f0WxzmuNeY5ssDccHvBBo_Z2Vu3BvLe8HGArqlk7dQ5Owav1FAi03yijmr9kgDlWeLCe-JPQTOUEA9VH0Q0knXZtDHrOMSIPNocelxhrplz180xrN_Aw_u0QPQDtH9VgrlmlHxM0bvn8NF407Uf1xkQ88GKqd/http%3A%2F%2Fshapeblue.com%2Fiaas-cloud-design-and-build%2F%2F> CSForge – rapid IaaS deployment framework<http://secure-web.cisco.com/1z27zdQXT0sqtwzAJRMsmbAvF4jnvvyiDarQcGzEW0L_b80Xh2SRRG0pSPS-gB5DLpmjza3rEULSdHr50euau0C836H0PRZMXhuoueRBM1btsZylOGr3QwPtRV5pSrzfBkiw0NGNJt5aLvxtww8_hr129cE5XVWnbozKsfLim1yVgKYgqGBWaP33PJ7oO7aOR/http%3A%2F%2Fshapeblue.com%2Fcsforge%2F> CloudStack Consulting<http://secure-web.cisco.com/1Pqr-yJu7fnoRJVFY5xhjRF8rnDNcT3cpHwUsdl1sU_bAZ8Et_4oaHPdN5KySeak5l9ej2HJjcFKiGBp9-qT89eCPloGedaXLdL4dTDGkpJg5kcymHfWIhwut2P0e-DAhZgJxu35u8Q3K5tYoOaeaveoi4LgpYtGZt2iVtbOEiEPdoP579T39kCA0DAMh8X8d/http%3A%2F%2Fshapeblue.com%2Fcloudstack-consultancy%2F> CloudStack Software Engineering<http://secure-web.cisco.com/1cOTTac79V0xUuX8MYnPy2tG5A45XPf06HDXeyZuAWIvG3uAigfNQjz_ZeHkBcWxiHXbUWExKVjwAO8BMs1f2ug1kF4nG0kMXpxzW__Im1D1ZCBFLtM2JmLctCcXKUalUbWhwaOvae8dZxoKjFeVUVKOoGZFBgqfNkG_0paIwnK0MguhWoX6mJu9Sx7D9lN1F/http%3A%2F%2Fshapeblue.com%2Fcloudstack-software-engineering%2F> CloudStack Infrastructure Support<http://secure-web.cisco.com/18DkP5kIP2TW2gdWkWCJ4u9ktfsBAyMjnYvSKzsIomqX84q2pE2DpDT6kgEcJjakCgJR7qWg-9VKWhZDxdWbElIQcou2X1BYXJOzm7qy_-ZpMSZ2Z23CFXdaTGVV9uzpM-t19kCM4FO0oj5tGqFufuCI0sWu3p7zEnkxHL0-XhxlJ0aTDdRgVYcw0yvN2agCn/http%3A%2F%2Fshapeblue.com%2Fcloudstack-infrastructure-support%2F> CloudStack Bootcamp Training Courses<http://secure-web.cisco.com/1myEW2ul7tEiy7AbKqaFo819HOXbHuU1vyqNuEpaJd-1K269PZHuoG4HobTzoCwjuqdKu89SB6fGoPoWb9VLYP5aEJbdixKIedc6DpoeK8S6efTtgiHw5nBN4WQvO2DSDRN1x2FO4sTI1n4tlag0DaAcUIHHEdtupa1zqmE0fewfLyh3BYbD6wUcFJsSAkxAO/http%3A%2F%2Fshapeblue.com%2Fcloudstack-training%2F> This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Shape Blue Ltd or related companies. If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error. Shape Blue Ltd is a company incorporated in England & Wales. ShapeBlue Services India LLP is a company incorporated in India and is operated under license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is a company registered by The Republic of South Africa and is traded under license from Shape Blue Ltd. ShapeBlue is a registered trademark.
RE: [VOTE] Accept the donation of ec2stack to apache cloudstack
+1. Thanks, Likitha -Original Message- From: Ian Duffy [mailto:i...@ianduffy.ie] Sent: Sunday, April 5, 2015 2:44 PM To: CloudStack Dev Cc: Sebastien Goasguen; Darren Brogan Subject: [VOTE] Accept the donation of ec2stack to apache cloudstack Hi All, As stated in a previous thread [1], myself, Sebastien and Darren are proposing the donation of ec2stack [2]. I would like to call a vote, so that we have formal consensus on accepting the code into the project. I suggest that it be accepted into a separate repository like we do with cloudmonkey. VOTING will be left open for 72 hours. Thanks, Ian [1] http://markmail.org/thread/g6iuceghdd37qpr7 [2] https://github.com/BroganD1993/ec2stack
RE: [VOTE] Accept the donation of gstack to apache cloudstack
+1 Thanks, Likitha -Original Message- From: Ian Duffy [mailto:i...@ianduffy.ie] Sent: Sunday, April 5, 2015 2:43 PM To: CloudStack Dev Cc: Darren Brogan; Sebastien Goasguen Subject: [VOTE] Accept the donation of gstack to apache cloudstack Hi All, As stated in a previous thread [1], myself, Sebastien and Darren are proposing the donation of gstack [2]. I would like to call a vote, so that we have formal consensus on accepting the code into the project. I suggest that it be accepted into a separate repository like we do with cloudmonkey. VOTING will be left open for 72 hours. Thanks, Ian [1] http://markmail.org/thread/g6iuceghdd37qpr7 [2] https://github.com/nopping/gstack
[GitHub] cloudstack pull request: Ovmsupport 3.2.1/3.3.x rebased and conden...
Github user likitha commented on the pull request: https://github.com/apache/cloudstack/pull/113#issuecomment-78435972 Seems to have caused the RAT check to fail. I do see the license headers in the new files, so I guess the format is not an exact match? (https://builds.apache.org/job/cloudstack-rat-master/6275/artifact/target/rat.txt) --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
RE: [ANNOUNCE] Rajani Karuturi as committer
Congratulations Rajani ! -Original Message- From: Prasanna Santhanam [mailto:t...@apache.org] Sent: Tuesday, July 22, 2014 11:53 AM To: CloudStack Dev Subject: [ANNOUNCE] Rajani Karuturi as committer The Project Management Committee (PMC) for Apache CloudStack has asked Rajani Karuturi to become a committer and we are pleased to announce that she has accepted. Being a committer allows many contributors to contribute more autonomously. For developers, it makes it easier to submit changes and eliminates the need to have contributions reviewed via the patch submission process. Whether contributions are development-related or otherwise, it is a recognition of a contributor's participation in the project and commitment to the project and the Apache Way. Please join me in congratulating Rajani -- Prasanna., on behalf of the CloudStack PMC Powered by BigRock.com
RE: "Bug" introduced by part of commit a600d8408ea86782318139c17cf346c8497943d0
Are you guys are referring to the update method that is throwing the error,
'update(long id, long runid, Date lastUpdate) ?. Agreed that this is just a
symptom.
But I was referring to the first update method in the file which is
'update(long id, long runid, String name, String version, String serviceIP, int
servicePort, Date lastUpdate)'.
>From what I understand this is the method that updates the MS runId when it is
>started. And the problem is that the transaction commit made in this update is
>getting rolled back, which is why we have a wrong runId in the DB for the MS.
>Since the second update method is based on the right runId it throws an
>exception.
And I suspect the original transaction is getting rolled back because we are
trying to close a transaction that is already closed.
Thanks,
Likitha
-Original Message-
From: Funs Kessen [mailto:fkes...@schubergphilis.com]
Sent: Thursday, July 10, 2014 5:10 PM
To: dev@cloudstack.apache.org
Subject: RE: "Bug" introduced by part of commit
a600d8408ea86782318139c17cf346c8497943d0
Hi Santhosh,
You're right indeed, it's the update statement in the update itself that adds
the runid in the where clause, it came in three years and three months ago by
the looks of it.
Cheers,
Funs
> -Original Message-
> From: Santhosh Edukulla [mailto:santhosh.eduku...@citrix.com]
> Sent: Thursday, July 10, 2014 1:22 PM
> To: dev@cloudstack.apache.org
> Subject: RE: "Bug" introduced by part of commit
> a600d8408ea86782318139c17cf346c8497943d0
>
> The mentioned issue by Funs was existing earlier as well but was
> hidden by just logging it when update was failed, now with new change,
> we resurfaced the problem by throwing it. Its not because of close
> though. We can see to fix the original problem.
>
> Santhosh
>
> From: Likitha Shetty [likitha.she...@citrix.com]
> Sent: Thursday, July 10, 2014 7:18 AM
> To: dev@cloudstack.apache.org
> Subject: RE: "Bug" introduced by part of commit
> a600d8408ea86782318139c17cf346c8497943d0
>
> Santhosh, I pulled the latest code and unfortunately the issue still exists.
>
> Looks like the problem is because we try to close the transaction
> after it has been committed (which implicitly closes the transaction)
> - /framework/cluster/src/com/cloud/cluster/dao/ManagementServerHostDao
> Impl.java
> txn.commit();
> } catch (RuntimeException e) {
> txn.rollback();
> s_logger.warn("Unexpected exception, ", e);
> throw new RuntimeException(e.getMessage(), e);
> }finally {
> txn.close();
> }
>
> Thanks,
> Likitha
>
> -Original Message-
> From: Funs Kessen [mailto:fkes...@schubergphilis.com]
> Sent: Thursday, July 10, 2014 2:38 PM
> To: dev@cloudstack.apache.org
> Subject: RE: "Bug" introduced by part of commit
> a600d8408ea86782318139c17cf346c8497943d0
>
> Yeah I see that Ipasted the wrong bit of code *doh*, it was update
> that was the problem from the same file:
>
> @@ -129,24 +133,29 @@
> @DB
> public void update(long id, long runid, Date lastUpdate) {
> TransactionLegacy txn = TransactionLegacy.currentTxn();
> -PreparedStatement pstmt = null;
> try {
> txn.start();
> +try( PreparedStatement pstmt =
> + txn.prepareStatement("update mshost
> set last_update=?, removed=null, alert_count=0 where id=? and
> runid=?");) {
> +pstmt.setString(1,
> DateUtil.getDateDisplayString(TimeZone.getTimeZone("GMT"),
> lastUpdate));
> +pstmt.setLong(2, id);
> +pstmt.setLong(3, runid);
>
> -pstmt = txn.prepareAutoCloseStatement("update mshost set
> last_update=?, removed=null, alert_count=0 where id=? and runid=?");
> -pstmt.setString(1,
> DateUtil.getDateDisplayString(TimeZone.getTimeZone("GMT"), lastUpdate));
> -pstmt.setLong(2, id);
> -pstmt.setLong(3, runid);
> +int count = pstmt.executeUpdate();
> +txn.commit();
>
> -int count = pstmt.executeUpdate();
> -txn.commit();
> -
> -if (count < 1) {
> -throw new CloudRuntimeException("Invalid cluster session
> detected", new ClusterInvalidSessionException("runid " + runid + " is
> no longer valid"));
> +if (count < 1) {
> +throw new CloudRuntimeException("Invalid cluster
> + session
> detected", new ClusterInvalidS
RE: "Bug" introduced by part of commit a600d8408ea86782318139c17cf346c8497943d0
Santhosh, I pulled the latest code and unfortunately the issue still exists.
Looks like the problem is because we try to close the transaction after it has
been committed (which implicitly closes the transaction) -
/framework/cluster/src/com/cloud/cluster/dao/ManagementServerHostDaoImpl.java
txn.commit();
} catch (RuntimeException e) {
txn.rollback();
s_logger.warn("Unexpected exception, ", e);
throw new RuntimeException(e.getMessage(), e);
}finally {
txn.close();
}
Thanks,
Likitha
-Original Message-
From: Funs Kessen [mailto:fkes...@schubergphilis.com]
Sent: Thursday, July 10, 2014 2:38 PM
To: dev@cloudstack.apache.org
Subject: RE: "Bug" introduced by part of commit
a600d8408ea86782318139c17cf346c8497943d0
Yeah I see that Ipasted the wrong bit of code *doh*, it was update that was the
problem from the same file:
@@ -129,24 +133,29 @@
@DB
public void update(long id, long runid, Date lastUpdate) {
TransactionLegacy txn = TransactionLegacy.currentTxn();
-PreparedStatement pstmt = null;
try {
txn.start();
+try( PreparedStatement pstmt = txn.prepareStatement("update mshost
set last_update=?, removed=null, alert_count=0 where id=? and runid=?");) {
+pstmt.setString(1,
DateUtil.getDateDisplayString(TimeZone.getTimeZone("GMT"), lastUpdate));
+pstmt.setLong(2, id);
+pstmt.setLong(3, runid);
-pstmt = txn.prepareAutoCloseStatement("update mshost set
last_update=?, removed=null, alert_count=0 where id=? and runid=?");
-pstmt.setString(1,
DateUtil.getDateDisplayString(TimeZone.getTimeZone("GMT"), lastUpdate));
-pstmt.setLong(2, id);
-pstmt.setLong(3, runid);
+int count = pstmt.executeUpdate();
+txn.commit();
-int count = pstmt.executeUpdate();
-txn.commit();
-
-if (count < 1) {
-throw new CloudRuntimeException("Invalid cluster session
detected", new ClusterInvalidSessionException("runid " + runid + " is no longer
valid"));
+if (count < 1) {
+throw new CloudRuntimeException("Invalid cluster session
detected", new ClusterInvalidSessionException("runid " + runid + " is no longer
valid"));
+}
+}catch (SQLException e) {
+throw new
+ CloudRuntimeException("update:Exception:"+e.getMessage(), e);
}
-} catch (Exception e) {
-s_logger.warn("Unexpected exception, ", e);
-throw new RuntimeException(e.getMessage(), e);
+} catch (RuntimeException e) {
+txn.rollback();
+s_logger.warn("update:Exception:"+e.getMessage(), e);
+throw new RuntimeException("update:Exception:"+e.getMessage(), e);
+}
+finally {
+txn.close();
}
}
> -Original Message-
> From: Trippie [mailto:trip...@gmail.com] On Behalf Of Hugo Trippaers
> Sent: Thursday, July 10, 2014 11:00 AM
> To: dev@cloudstack.apache.org
> Subject: Re: "Bug" introduced by part of commit
> a600d8408ea86782318139c17cf346c8497943d0
>
> Fixed already, good job Santosh
>
> Cheers,
>
> Hugo
>
> On 10 jul. 2014, at 10:58, Hugo Trippaers wrote:
>
> > Doesn't seem related to that particular commit, the function
> invalidateRunSession appears to be dead code.
> >
> > I'll do some digging.
> >
> >
> > Cheers,
> >
> > Hugo
> >
> > On 10 jul. 2014, at 10:40, Funs Kessen
> wrote:
> >
> >> Hi Devs,
> >>
> >> I recently noticed on master that after starting, stopping and
> >> starting the
> management server again I get stacktraces about every second.
> >> After some digging with Daan we found that part of the
> a600d8408ea86782318139c17cf346c84979943d0 commit causes this. The
> problem is however deeper rooted, as the code is supposed to update
> the mshost table, but because another Session ID (actually _runId from
> ClusterManagerImpl.java from the previous run) is already in there
> the update fails. The Session ID is based on time in milliseconds, and
> offcourse changes when you stop and start the management server again.
> >> Prior to the commit it failed silently, and has done so since the
> >> initial
> checkin it seems. The real question is what the original idea is
> behind the _runId, and is it something that requires fixing ?
> >>
> >> I've pasted part of the commit, sql and
RE: "Bug" introduced by part of commit a600d8408ea86782318139c17cf346c8497943d0
Funs, Santhosh fixed this problem yesterday.
https://issues.apache.org/jira/browse/CLOUDSTACK-7079 has more details.
Thanks,
Likitha
-Original Message-
From: Funs Kessen [mailto:fkes...@schubergphilis.com]
Sent: Thursday, July 10, 2014 2:10 PM
To: dev@cloudstack.apache.org
Cc: Daan Hoogland
Subject: "Bug" introduced by part of commit
a600d8408ea86782318139c17cf346c8497943d0
Hi Devs,
I recently noticed on master that after starting, stopping and starting the
management server again I get stacktraces about every second.
After some digging with Daan we found that part of the
a600d8408ea86782318139c17cf346c84979943d0 commit causes this. The problem is
however deeper rooted, as the code is supposed to update the mshost table, but
because another Session ID (actually _runId from ClusterManagerImpl.java from
the previous run) is already in there the update fails. The Session ID is
based on time in milliseconds, and offcourse changes when you stop and start
the management server again.
Prior to the commit it failed silently, and has done so since the initial
checkin it seems. The real question is what the original idea is behind the
_runId, and is it something that requires fixing ?
I've pasted part of the commit, sql and stacktrace below.
Cheers,
Funs
===
mysql> select * from mshost;
+++---+-+---+++--+-+-+-+
| id | msid | runid | name| state | version|
service_ip | service_port | last_update | removed | alert_count |
+++---+-+---+++--+-+-+-+
| 1 | 90520734207775 | 1404924979461 | cs-mgmt | Up| 4.5.0-SNAPSHOT |
127.0.0.1 | 9090 | 2014-07-09 16:58:07 | NULL| 0 |
+++---+-+---+++--+-+-+-+
1 row in set (0.00 sec)
===
commit a600d8408ea86782318139c17cf346c8497943d0
Author: Santhosh Edukulla 2014-07-02 10:38:16
Committer: Santhosh Edukulla 2014-07-04 12:47:58
Fixed Resource Leaks, null dereferences, few other issues reported by coverity
- framework/cluster/src/com/cloud/cluster/dao/ManagementServerHostDaoImpl.java
diff --git
a/framework/cluster/src/com/cloud/cluster/dao/ManagementServerHostDaoImpl.java
b/framework/cluster/src/com/cloud/cluster/dao/ManagementServerHostDaoImpl.java
index 3d0c3f5..89d7d27 100644
---
a/framework/cluster/src/com/cloud/cluster/dao/ManagementServerHostDaoImpl.java
+++
b/framework/cluster/src/com/cloud/cluster/dao/ManagementServerHostDaoImpl.java
@@ -53,15 +53,14 @@
@Override
public void invalidateRunSession(long id, long runid) {
TransactionLegacy txn = TransactionLegacy.currentTxn();
-PreparedStatement pstmt = null;
-try {
-pstmt = txn.prepareAutoCloseStatement("update mshost set runid=0,
state='Down' where id=? and runid=?");
-pstmt.setLong(1, id);
-pstmt.setLong(2, runid);
-
-pstmt.executeUpdate();
+try (PreparedStatement pstmt = txn.prepareStatement("update mshost set
runid=0, state='Down' where id=? and runid=?");){
+if(pstmt != null) {
+pstmt.setLong(1, id);
+pstmt.setLong(2, runid);
+pstmt.executeUpdate();
+}
} catch (SQLException e) {
-throw new CloudRuntimeException("DB exception on " +
pstmt.toString(), e);
+throw new CloudRuntimeException("invalidateRunSession:Exception:"+
e.getMessage(), e);
}
}
===
2014-07-09 18:45:06,541 WARN [c.c.c.d.ManagementServerHostDaoImpl]
(Cluster-Heartbeat-1:ctx-5f2f8ad5) update:Exception:Invalid cluster session
detected
com.cloud.utils.exception.CloudRuntimeException: Invalid cluster session
detected
at
com.cloud.cluster.dao.ManagementServerHostDaoImpl.update(ManagementServerHostDaoImpl.java:147)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
at
com.cloud.utils.db.TransactionContextInterceptor.invoke(TransactionContextInterceptor.java:34)
RE: [ANNOUNCE] Amogh Vasekar as committer
Congratulations Amogh! Regards, Likitha -Original Message- From: John Kinsella [mailto:j...@stratosec.co] Sent: Monday, June 2, 2014 11:44 PM To: Subject: [ANNOUNCE] Amogh Vasekar as committer The Project Management Committee (PMC) for Apache CloudStack has asked Amogh Vasekar to become a committer and we are pleased to announce that he has accepted. Being a committer allows many contributors to contribute more autonomously. For developers, it makes it easier to submit changes and eliminates the need to have contributions reviewed via the patch submission process. Whether contributions are development-related or otherwise, it is a recognition of a contributor's participation in the project and commitment to the project and the Apache Way. Please join me in congratulating Amogh! -John, on behalf of the CloudStack PMC
RE: [ANNOUNCE] Saksham Srivastava as committer
Many many congratulations Saksham! -Original Message- From: sebgoa [mailto:run...@gmail.com] Sent: Thursday, May 29, 2014 12:18 PM To: dev@cloudstack.apache.org Subject: [ANNOUNCE] Saksham Srivastava as committer The Project Management Committee (PMC) for Apache CloudStack has asked Saksham Srivastava to become a committer and we are pleased to announce that he has accepted. Being a committer allows many contributors to contribute more autonomously. For developers, it makes it easier to submit changes and eliminates the need to have contributions reviewed via the patch submission process. Whether contributions are development-related or otherwise, it is a recognition of a contributor's participation in the project and commitment to the project and the Apache Way. Please join me in congratulating Saksham, -Sebastien, on behalf of the CloudStack PMC
Re: Review Request 21629: CLOUDSTACK-4757. Support OVA files containing multiple disks.
Testing --- - Marvin test for this feature is available in patch Thanks, Likitha Shetty
Review Request 21629: CLOUDSTACK-4757. Support OVA files containing multiple disks.
available in patch Thanks, Likitha Shetty
[MERGE] [4.5] Support OVA files with multiple disks for templates
Would like to request the merge of feature 'Support for OVA containing multiple disks' into CloudStack. 1. JIRA ticket - https://issues.apache.org/jira/browse/CLOUDSTACK-4757 2. Functional spec - https://cwiki.apache.org/confluence/display/CLOUDSTACK/Support+OVA+files+containing+multiple+disks 3. Branch name - 'multiple-disk-ova' 3. Marvin test for this feature is available in feature branch @ commit - 3532ffe5af5553e558cfe6de2fef059b8d5e100e 4. Feature branch has been rebased with master branch up to commit - 155745e26c14799a77fb3987bc40bc578810748e 5. Verified that RAT test passes Thanks, Likitha
RE: [ANNOUNCE] New PMC Menber: Go Chiba
Congratulations! -Original Message- From: Trippie [mailto:trip...@gmail.com] On Behalf Of Hugo Trippaers Sent: Wednesday, April 23, 2014 12:52 AM To: Subject: [ANNOUNCE] New PMC Menber: Go Chiba The Project Management Committee (PMC) for Apache CloudStack has asked Go Chiba to join the PMC and we are pleased to announce that he has accepted. Join me in congratulating Go! -The CloudStack PMC
RE: [ANNOUNCE] New PMC Menber: Alena Prokharchyk
Congratulations Alena ! -Original Message- From: Daan Hoogland [mailto:daan.hoogl...@gmail.com] Sent: Wednesday, April 23, 2014 1:21 AM To: dev Subject: [ANNOUNCE] New PMC Menber: Alena Prokharchyk The Project Management Committee (PMC) for Apache CloudStack has asked Alena Prokharchyk to join the PMC and we are pleased to announce that he has accepted. Join me in congratulating Alena! -The CloudStack PMC
RE: Dynamic Scaling of VM
Tejas, you must be running into this error because Clone_VM vCenter task is taking more than 20 minutes to complete. To avoid this error use global configuration 'vmware.vcenter.session.timeout' to increase the default timeout value. In vCenter under Tasks and Events, check how long the CloneVM task takes to complete and increase the timeout value accordingly (refer - https://issues.apache.org/jira/browse/CLOUDSTACK-5069). Thanks, Likitha -Original Message- From: Tejas Gadaria [mailto:refond.g...@gmail.com] Sent: Tuesday, April 22, 2014 8:45 AM To: dev@cloudstack.apache.org Cc: us...@cloudstack.apache.org Subject: Re: Dynamic Scaling of VM Hi Nitin, you are right, I changed to *enable.dynamic.scale.vm = false* Created another centos template without dynamic scaling, still facing same issue. On management server it displaying same logs as above. I am using vCenter 5.5 and Esxi host 5.1 Regards, Tejas On Tue, Apr 22, 2014 at 12:25 AM, Nitin Mehta wrote: > Error doesn't seem to be coming from dynamic scaling. Change the > config below to false and see if you still hit the issue. > *enable.dynamic.scale.vm* = false > > > On 19/04/14 8:48 PM, "Tejas Gadaria" wrote: > > >Hi, > > > >I am trying to test dynamic scaling of vm on vmware with CS 4.3. > >I have CentOS 6.3 template with vmware tools installed. > > > >In global setting *enable.dynamic.scale.vm* = *true, * > > > > > >*mem.overprovisioning.factor =2 * > >while trying to deploy template, it's giving below error.. > > > >2014-04-20 09:06:31,808 DEBUG [c.c.h.v.u.VmwareClient] > >(DirectAgent-27:ctx-80068c4c 10.129.151.67) Cancelling vCenter task > >because task failed with java.net.SocketTimeoutException: Read timed > >out > >2014-04-20 09:06:32,354 ERROR [c.c.s.r.VmwareStorageProcessor] > >(DirectAgent-27:ctx-80068c4c 10.129.151.67) clone volume from base > >image failed due to Exception: java.lang.RuntimeException > >Message: vCenter task failed due to java.net.SocketTimeoutException: > >Read timed out > > > >java.lang.RuntimeException: vCenter task failed due to > >java.net.SocketTimeoutException: Read timed out > >at > >com.cloud.hypervisor.vmware.util.VmwareClient.waitForTask(VmwareClien > >t.jav > >a:341) > >at > >com.cloud.hypervisor.vmware.mo.VirtualMachineMO.createFullClone(Virtu > >alMac > >hineMO.java:619) > >at > >com.cloud.storage.resource.VmwareStorageProcessor.createVMFullClone(V > >mware > >StorageProcessor.java:266) > >at > >com.cloud.storage.resource.VmwareStorageProcessor.cloneVolumeFromBase > >Templ > >ate(VmwareStorageProcessor.java:338) > >at > >com.cloud.storage.resource.StorageSubsystemCommandHandlerBase.execute > >(Stor > >ageSubsystemCommandHandlerBase.java:78) > >at > >com.cloud.storage.resource.VmwareStorageSubsystemCommandHandler.execu > >te(Vm > >wareStorageSubsystemCommandHandler.java:171) > >at > >com.cloud.storage.resource.StorageSubsystemCommandHandlerBase.handleS > >torag > >eCommands(StorageSubsystemCommandHandlerBase.java:50) > >at > >com.cloud.hypervisor.vmware.resource.VmwareResource.executeRequest(Vm > >wareR > >esource.java:571) > >at > >com.cloud.agent.manager.DirectAgentAttache$Task.runInContext(DirectAg > >entAt > >tache.java:216) > >at > >org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(Ma > >naged > >ContextRunnable.java:49) > >at > >org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.ca > >ll(De > >faultManagedContext.java:56) > >at > >org.apache.cloudstack.managed.context.impl.DefaultManagedContext.call > >WithC > >ontext(DefaultManagedContext.java:103) > >at > >org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runW > >ithCo > >ntext(DefaultManagedContext.java:53) > >at > >org.apache.cloudstack.managed.context.ManagedContextRunnable.run(Mana > >gedCo > >ntextRunnable.java:46) > >at > >java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) > >at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) > >at java.util.concurrent.FutureTask.run(FutureTask.java:166) > >at > >java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask. > >acces > >s$101(ScheduledThreadPoolExecutor.java:165) > >at > >java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask. > >run(S > >cheduledThreadPoolExecutor.java:266) > >at > &
RE: Changing Template Ownership
Donal, today I don't think we can change the ownership of any resource besides Virtual Machine. And the FS for that can be found at https://cwiki.apache.org/confluence/display/CLOUDSTACK/Change+VM+ownership . Thanks, Likitha -Original Message- From: Donal Lafferty [mailto:donal.laffe...@citrix.com] Sent: Tuesday, April 8, 2014 4:06 PM To: dev@cloudstack.apache.org Subject: Changing Template Ownership The FS for changing ownership suggests it works with templates (see https://cwiki.apache.org/confluence/display/CLOUDSTACK/Change+account+membership). In that case, what is the template equivalent of https://cloudstack.apache.org/docs/api/apidocs-4.3/root_admin/assignVirtualMachine.html ? DL
RE: AWS api when running mvn jetty
Yes Chris, we need to run them separately. Thanks, Likitha >-Original Message- >From: chris snow [mailto:chsnow...@gmail.com] >Sent: Thursday, March 20, 2014 4:08 AM >To: dev@cloudstack.apache.org >Subject: Re: AWS api when running mvn jetty > >I did try this, but it only brings up the client ui, and not the awsapi: > > mvn -pl :cloud-client-ui -Pawsapi -pl :cloud-awsapi jetty:run > >Do I have to run the two targets as separate commands? e.g. > > mvn -pl :cloud-client-ui jetty:run & mvn -Pawsapi -pl :cloud-awsapi > jetty:run > >On Wed, Mar 19, 2014 at 7:22 AM, chris snow wrote: >> Hi Likitha, >> >> Is it possible to run both awsapi and client ui at the same time with jetty? >> E.g. something like this: >> >> mvn -pl :cloud-client-ui -pl :cloud-awsapi jetty:run >> >> Many thanks, >> >> Chris >> >> On 19 Mar 2014 06:29, "Likitha Shetty" wrote: >>> >>> Chris, >>> >>> 'mvn -pl :cloud-client-ui jetty:run' doesn't run awsapi. >>> To run awsapi you will have to run maven jetty goal 'mvn -Pawsapi >>> -pl :cloud-awsapi jetty:run'. Also, don't forget to use the awsapi >>> profile while building the code 'mvn clean install -P systemvm -P awsapi - >Dnoredist'. >>> >>> Thanks, >>> Likitha >>> >>> >-Original Message- >>> >From: chris snow [mailto:chsnow...@gmail.com] >>> >Sent: Wednesday, March 19, 2014 11:42 AM >>> >To: dev@cloudstack.apache.org >>> >Subject: AWS api when running mvn jetty >>> > >>> >Hi forum, >>> > >>> >Does the maven jetty goal "mvn -pl :cloud-client-ui jetty:run" also >>> >run the AWS api? >>> > >>> >I can't see anything running on port 7080 after starting jetty. >>> > >>> >Is it possible to run the AWS api from the maven jetty goal? How? >>> > >>> >Many thanks, >>> > >>> >Chris > > > >-- >Check out my professional profile and connect with me on LinkedIn. >http://lnkd.in/cw5k69
RE: AWS api when running mvn jetty
Chris, 'mvn -pl :cloud-client-ui jetty:run' doesn't run awsapi. To run awsapi you will have to run maven jetty goal 'mvn -Pawsapi -pl :cloud-awsapi jetty:run'. Also, don't forget to use the awsapi profile while building the code 'mvn clean install -P systemvm -P awsapi -Dnoredist'. Thanks, Likitha >-Original Message- >From: chris snow [mailto:chsnow...@gmail.com] >Sent: Wednesday, March 19, 2014 11:42 AM >To: dev@cloudstack.apache.org >Subject: AWS api when running mvn jetty > >Hi forum, > >Does the maven jetty goal "mvn -pl :cloud-client-ui jetty:run" also run the AWS >api? > >I can't see anything running on port 7080 after starting jetty. > >Is it possible to run the AWS api from the maven jetty goal? How? > >Many thanks, > >Chris
[4.3] [Cherry-pick] CLOUDSTACK-6146
Animesh, Can you cherry pick 8cb03ddb2387c7aebf20dc0aa011e41f227e9f68 and c652ff45dffaafa1cb0de29103e90fe936382028 from 4.3-forward to 4.3? Thanks, Likitha
[PROPOSAL] Support OVA files that contain multiple disks
Earlier we had a discussion about adding support for OVA files with multiple disks in CloudStack - http://mail-archives.apache.org/mod_mbox/cloudstack-dev/201309.mbox/browser . Based on that I have added a Functional Spec for this enhancement - https://cwiki.apache.org/confluence/display/CLOUDSTACK/FS+-+Support+OVA+files+containing+multiple+disks . Let me know if there are any concerns or comments. Thanks, Likitha
RE: EC2 Rest Servlet "domain cannot be null!!" Error In Advanced Networking Mode
Oh great! Yes, 4.4 is the current master. >-Original Message- >From: Jeff Hair [mailto:j...@greenqloud.com] >Sent: Friday, January 31, 2014 3:16 PM >To: dev@cloudstack.apache.org >Subject: Re: EC2 Rest Servlet "domain cannot be null!!" Error In Advanced >Networking Mode > >Hi Likitha, > >The fix you committed is actually the exact same way we wound up fixing it, >although we put ours on the mirror of the 4.2.1 branch that we have. Since you >said the EC2 REST/SOAP API hasn't been well-tested in advanced mode >networking, we may run into more issues like this. If we do, and we want to >submit our own fixes for review, should we submit against the 4.4 branch? > >Jeff > > >On Fri, Jan 31, 2014 at 5:24 AM, Likitha Shetty >wrote: > >> Jeff, what you have reported is a bug. Created an issue to track it in >> in JIRA - https://issues.apache.org/jira/browse/CLOUDSTACK-5998 . >> >> BTW you mentioned that you trying EC2 Query API against a setup with >> Advanced networking? I just want to point out that AFAIK, we have >> never tested EC2 REST/SOAP API compatibility in a setup with Advanced >networking. >> >> Thanks, >> Likitha >> >> >-Original Message- >> >From: Jeff Hair [mailto:j...@greenqloud.com] >> >Sent: Thursday, January 30, 2014 6:38 PM >> >To: dev@cloudstack.apache.org >> >Subject: EC2 Rest Servlet "domain cannot be null!!" Error In Advanced >> >Networking Mode >> > >> >Hi, >> > >> >We're trying to query the EC2 REST API. Most of it works, but we're >> running into >> >an issue when calling describe addresses. It returns a fault with >> >"domain >> cannot >> >be null!!" as the error text. I've traced this down to CloudStack not >> setting the >> >EC2 domain (standard or vpc) in the >> >EC2SoapServiceImpl#toDescribeAddressesResponse static method. The >> >domain property is not being set, and then it explodes on >> >serialization with the >> above >> >error. >> > >> >So, my questions are these: >> > >> >1. Is this a bug in CloudStack with the EC2 API and Advanced Networking? >> Or are >> >we missing some configuration/setting? >> >2. If this is actually a bug, what is the best way to work around it >> temporarily, >> >and also where to start fixing it for real in the CS codebase? >> > >> >Thanks, >> > >> >Jeff >>
RE: EC2 Rest Servlet "domain cannot be null!!" Error In Advanced Networking Mode
Jeff, what you have reported is a bug. Created an issue to track it in in JIRA - https://issues.apache.org/jira/browse/CLOUDSTACK-5998 . BTW you mentioned that you trying EC2 Query API against a setup with Advanced networking? I just want to point out that AFAIK, we have never tested EC2 REST/SOAP API compatibility in a setup with Advanced networking. Thanks, Likitha >-Original Message- >From: Jeff Hair [mailto:j...@greenqloud.com] >Sent: Thursday, January 30, 2014 6:38 PM >To: dev@cloudstack.apache.org >Subject: EC2 Rest Servlet "domain cannot be null!!" Error In Advanced >Networking Mode > >Hi, > >We're trying to query the EC2 REST API. Most of it works, but we're running >into >an issue when calling describe addresses. It returns a fault with "domain >cannot >be null!!" as the error text. I've traced this down to CloudStack not setting >the >EC2 domain (standard or vpc) in the >EC2SoapServiceImpl#toDescribeAddressesResponse static method. The domain >property is not being set, and then it explodes on serialization with the above >error. > >So, my questions are these: > >1. Is this a bug in CloudStack with the EC2 API and Advanced Networking? Or are >we missing some configuration/setting? >2. If this is actually a bug, what is the best way to work around it >temporarily, >and also where to start fixing it for real in the CS codebase? > >Thanks, > >Jeff
[ACS 4.3] Cherry pick request for CLOUDSTACK-5927
Please cherry pick commit 94ea2736f4a1614e45f4bc56388aad7adeb22a08 from 4.3-forward branch to 4.3 branch. Thanks, Likitha
RE: AWSAPI not working in 4.3
Seb, I am able to successfully use awsapi on my dev setup (4.3 latest). Did you by any chance forget to build using the awsapi profile -> mvn clean install -P systemvm -P awsapi -Dnoredist ? Thanks, Likitha >-Original Message- >From: Chandan Purushothama [mailto:chandan.purushoth...@citrix.com] >Sent: Tuesday, January 14, 2014 7:12 AM >To: dev@cloudstack.apache.org; Animesh Chaturvedi >Subject: RE: AWSAPI not working in 4.3 > >Hello, > >I am able to successfully use aws api on my test setup using the latest build. >Looks like the feature is intact since the previous release, > >Thank you, >Chandan. > >-Original Message- >From: Prachi Damle [mailto:prachi.da...@citrix.com] >Sent: Monday, January 13, 2014 12:12 PM >To: Animesh Chaturvedi; dev@cloudstack.apache.org >Subject: RE: AWSAPI not working in 4.3 > >There has been no code change to break anything newly; so this should be a >build problem. > >If anyone familiar with maven profiles can also take a look, it might be >quicker >to find out. > >Prachi > >-Original Message- >From: Animesh Chaturvedi >Sent: Monday, January 13, 2014 11:49 AM >To: dev@cloudstack.apache.org >Cc: Prachi Damle >Subject: RE: AWSAPI not working in 4.3 > >Copying Prachi to the thread. > >Animesh > >-Original Message- >From: sebgoa [mailto:run...@gmail.com] >Sent: Monday, January 13, 2014 7:01 AM >To: dev@cloudstack.apache.org >Subject: AWSAPI not working in 4.3 > >Hi, > >In 4.2 we can run the awsapi with: >mvn -Pawsapi -pl :cloud-awsapi jetty:run > >In the latest 4.3 branch, I can build successfully and run the mgt server, but >while trying to run the awsapi app I get: > > >[INFO] --- maven-compiler-plugin:2.5.1:testCompile (default-testCompile) @ >cloud-awsapi --- [INFO] Nothing to compile - all classes are up to date [INFO] >[INFO] <<< maven-jetty-plugin:6.1.26:run (default-cli) @ cloud-awsapi <<< >[INFO] [INFO] --- maven-jetty-plugin:6.1.26:run (default-cli) @ cloud-awsapi >--- >[INFO] Configuring Jetty for project: Apache CloudStack AWS API Bridge [INFO] >-- >-- >[INFO] BUILD FAILURE >[INFO] >[INFO] Total time: 12.662s >[INFO] Finished at: Mon Jan 13 15:59:04 CET 2014 [INFO] Final Memory: >32M/215M [INFO] > >[ERROR] Failed to execute goal org.mortbay.jetty:maven-jetty-plugin:6.1.26:run >(default-cli) on project cloud-awsapi: Webapp source directory >/Users/sebgoa/Documents/gitforks/cloudstack/awsapi/target/cloud-awsapi- >4.3.0-SNAPSHOT does not exist -> [Help 1] [ERROR] [ERROR] To see the full stack >trace of the errors, re-run Maven with the -e switch. >[ERROR] Re-run Maven using the -X switch to enable full debug logging. >[ERROR] >[ERROR] For more information about the errors and possible solutions, please >read the following articles: >[ERROR] [Help 1] >http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException > >Did something change in the profiles ? > >thanks, > >-Sebastien
RE: [ANNOUNCE] New Committer: Sanjay Tripathi
Sanjay, congratulations :) >-Original Message- >From: David Nalley [mailto:da...@gnsa.us] >Sent: Friday, January 10, 2014 4:23 AM >To: dev@cloudstack.apache.org >Subject: [ANNOUNCE] New Committer: Sanjay Tripathi > >The Project Management Committee (PMC) for Apache CloudStack has asked >Sanjay Tripathi to become a committer and we are pleased to announce that >they have accepted. > >Being a committer allows many contributors to contribute more autonomously. >For developers, it makes it easier to submit changes and eliminates the need to >have contributions reviewed via the patch submission process. Whether >contributions are development-related or otherwise, it is a recognition of a >contributor's participation in the project and commitment to the project and >the >Apache Way. > >Please join me in congratulating Sanjay! > >--David, >on behalf of the Apache CloudStack PMC
Re: Review Request 14905: Add global configuration parameters for SMTP timeout
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/14905/#review27455 --- Ship it! Ship It! - Likitha Shetty On Oct. 24, 2013, 10:57 a.m., Anshul Gangwar wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/14905/ > --- > > (Updated Oct. 24, 2013, 10:57 a.m.) > > > Review request for cloudstack, Devdeep Singh, Likitha Shetty, and Sateesh > Chodapuneedi. > > > Bugs: CLOUDSTACK-4909 > https://issues.apache.org/jira/browse/CLOUDSTACK-4909 > > > Repository: cloudstack-git > > > Description > --- > > This will make the SMTP timeout parameters configurable. Default timeout is > 30 seconds. > > > Diffs > - > > server/src/com/cloud/alert/AlertManagerImpl.java 3aa9695 > server/src/com/cloud/configuration/Config.java cefcdd5 > > Diff: https://reviews.apache.org/r/14905/diff/ > > > Testing > --- > > tested on local setup > > > Thanks, > > Anshul Gangwar > >
RE: [ANNOUNCE] New PMC member: Animesh Chaturvedi
Congratulations Animesh ! >-Original Message- >From: Animesh Chaturvedi [mailto:animesh.chaturv...@citrix.com] >Sent: Tuesday, October 22, 2013 10:19 PM >To: dev@cloudstack.apache.org >Subject: RE: [ANNOUNCE] New PMC member: Animesh Chaturvedi > >Thank you all. I am truly honoured > >Animesh > >From: chip.child...@sungard.com [chip.child...@sungard.com] on behalf of >Chip Childers [chipchild...@apache.org] >Sent: Monday, October 21, 2013 12:01 PM >To: >Subject: [ANNOUNCE] New PMC member: Animesh Chaturvedi > >The Project Management Committee (PMC) for Apache CloudStack has asked >Animesh Chaturvedi to join the PMC and we are pleased to announce that they >have accepted. > >Join me in congratulating Animesh! > >-The CloudStack PMC
Re: Review Request 14467: fix for Invalid SMTP breaks HA
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/14467/#review27181 --- Changes have been committed to 4.2. But the patch doesn't clean apply on master, can you please update it accordingly. - Likitha Shetty On Oct. 3, 2013, 11:31 a.m., Anshul Gangwar wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/14467/ > --- > > (Updated Oct. 3, 2013, 11:31 a.m.) > > > Review request for cloudstack and Devdeep Singh. > > > Bugs: https://issues.apache.org/jira/browse/CLOUDSTACK-4792 > > https://issues.apache.org/jira/browse/https://issues.apache.org/jira/browse/CLOUDSTACK-4792 > > > Repository: cloudstack-git > > > Description > --- > > added the connection and socket timeout parameters for SMTP and sending > message in new thread so that HA doesn't get blocked beacause of hang in > sending email alert > > > Diffs > - > > server/src/com/cloud/alert/AlertManagerImpl.java c437a8c > > Diff: https://reviews.apache.org/r/14467/diff/ > > > Testing > --- > > tested manually on my local setup > > > Thanks, > > Anshul Gangwar > >
Re: Review Request 14467: fix for Invalid SMTP breaks HA
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/14467/#review27180 --- Ship it! Ship It! - Likitha Shetty On Oct. 3, 2013, 11:31 a.m., Anshul Gangwar wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/14467/ > --- > > (Updated Oct. 3, 2013, 11:31 a.m.) > > > Review request for cloudstack and Devdeep Singh. > > > Bugs: https://issues.apache.org/jira/browse/CLOUDSTACK-4792 > > https://issues.apache.org/jira/browse/https://issues.apache.org/jira/browse/CLOUDSTACK-4792 > > > Repository: cloudstack-git > > > Description > --- > > added the connection and socket timeout parameters for SMTP and sending > message in new thread so that HA doesn't get blocked beacause of hang in > sending email alert > > > Diffs > - > > server/src/com/cloud/alert/AlertManagerImpl.java c437a8c > > Diff: https://reviews.apache.org/r/14467/diff/ > > > Testing > --- > > tested manually on my local setup > > > Thanks, > > Anshul Gangwar > >
Re: Review Request 14147: marvin tests for Persistent networks without running a VM
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/14147/#review27179 --- Ship it! Ship It! - Likitha Shetty On Oct. 18, 2013, 8:21 a.m., Anshul Gangwar wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/14147/ > --- > > (Updated Oct. 18, 2013, 8:21 a.m.) > > > Review request for cloudstack, Likitha Shetty, sailaja mada, and Prasanna > Santhanam. > > > Bugs: https://issues.apache.org/jira/browse/CLOUDSTACK-2232 > > https://issues.apache.org/jira/browse/https://issues.apache.org/jira/browse/CLOUDSTACK-2232 > > > Repository: cloudstack-git > > > Description > --- > > marvin tests for Persistent networks without running a VM > > > Diffs > - > > test/integration/component/test_persistent_networks.py PRE-CREATION > > Diff: https://reviews.apache.org/r/14147/diff/ > > > Testing > --- > > ran successfully on my local advanced zone setup > > > Thanks, > > Anshul Gangwar > >
Re: Review Request 14147: marvin tests for Persistent networks without running a VM
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/14147/#review27177 --- Please update the diff to remove the change made to base.py as it has already been checked in. Otherwise it looks good to me. Good test case coverage. - Likitha Shetty On Sept. 16, 2013, 11:26 a.m., Anshul Gangwar wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/14147/ > --- > > (Updated Sept. 16, 2013, 11:26 a.m.) > > > Review request for cloudstack, Likitha Shetty, sailaja mada, and Prasanna > Santhanam. > > > Bugs: https://issues.apache.org/jira/browse/CLOUDSTACK-2232 > > https://issues.apache.org/jira/browse/https://issues.apache.org/jira/browse/CLOUDSTACK-2232 > > > Repository: cloudstack-git > > > Description > --- > > marvin tests for Persistent networks without running a VM > > > Diffs > - > > test/integration/component/test_persistent_networks.py PRE-CREATION > tools/marvin/marvin/integration/lib/base.py 9e46065 > > Diff: https://reviews.apache.org/r/14147/diff/ > > > Testing > --- > > ran successfully on my local advanced zone setup > > > Thanks, > > Anshul Gangwar > >
RE: [PROPOSAL] Support OVA files with multiple disks for templates and uploaded volumes in VMWare
True, OVA can contain any disk image type. I specifically called out VMware because I was thinking about how today in CS this enhancement is of value only to VMware. But yes, as you pointed out, during implementation we should ensure this support is hypervisor agnostic. Thanks, Likitha >-Original Message- >From: Chip Childers [mailto:chipchild...@apache.org] >Sent: Monday, September 30, 2013 10:06 PM >To: dev@cloudstack.apache.org >Subject: Re: [PROPOSAL] Support OVA files with multiple disks for templates and >uploaded volumes in VMWare > >On Mon, Sep 30, 2013 at 03:26:54PM +, Likitha Shetty wrote: >> Chip, >> >> In Cloudstack, for Xen and KVM hypervisors since the files used for templates >and volumes are virtual disks (VHD, QCOW2) the current CS assumption of >template and volumes containing a single virtual disk seems fine. But since for >VMware the files used for templates and volumes are in OVA format which is an >archive that can contain multiple VMDKs this improvement seems appropriate >only for VMware? >> >> Thanks, >> Likitha > >Ok, I see why you are headed down a VMware only path now. That being said, >OVF/OVA are actually envelope specs which can contain any disk image type. >The key is to either use the native HV OVF/A import capabilities (VMware >obviously does this, as does XenServer IIRC), or use a tool like virt-tools to >make >the embedded meta-data about the included VM useful for the target HV. > >While I get doing this for VMware only, I'd ask that the implementation be >designed to potentially work with the other HVs. > >Make sense?
RE: [PROPOSAL] Support OVA files with multiple disks for templates and uploaded volumes in VMWare
Chip, In Cloudstack, for Xen and KVM hypervisors since the files used for templates and volumes are virtual disks (VHD, QCOW2) the current CS assumption of template and volumes containing a single virtual disk seems fine. But since for VMware the files used for templates and volumes are in OVA format which is an archive that can contain multiple VMDKs this improvement seems appropriate only for VMware? Thanks, Likitha >-Original Message- >From: Chip Childers [mailto:chip.child...@sungard.com] >Sent: Monday, September 30, 2013 7:42 PM >To: dev@cloudstack.apache.org >Subject: Re: [PROPOSAL] Support OVA files with multiple disks for templates and >uploaded volumes in VMWare > >On Mon, Sep 30, 2013 at 05:54:55AM +, Likitha Shetty wrote: >> Hi, >> >> Currently, Cloudstack only supports Template creation based on OVA files >containing a single disk. If a user creates a template from a OVA file >containing >more than 1 disk and launches an instance using this template, only the first >disk >is attached to the new instance and other disks are ignored. Similarly with >uploaded volumes, attaching an uploaded volume that contains multiple disks to >a VM will result in only one VMDK to being attached to the VM. >> >> This behavior needs to be improved in VMWare to support OVA files with >multiple disks for both templates and uploaded volumes. For e.g. If a user >creates a template from a OVA file containing more than 1 disk and launches an >instance using this template, the first disk should be attached to the new >instance as the ROOT disk, volumes should be created based on other VMDK >disks in the OVA file and should be attached to the instance. >> > >+1, but question. Why VMware only? > >> I will soon propose a Functional Spec for this improvement. >> >> The corresponding JIRA ticket can be found at >https://issues.apache.org/jira/browse/CLOUDSTACK-4757 . >> >> Thanks, >> Likitha >>
[PROPOSAL] Support OVA files with multiple disks for templates and uploaded volumes in VMWare
Hi, Currently, Cloudstack only supports Template creation based on OVA files containing a single disk. If a user creates a template from a OVA file containing more than 1 disk and launches an instance using this template, only the first disk is attached to the new instance and other disks are ignored. Similarly with uploaded volumes, attaching an uploaded volume that contains multiple disks to a VM will result in only one VMDK to being attached to the VM. This behavior needs to be improved in VMWare to support OVA files with multiple disks for both templates and uploaded volumes. For e.g. If a user creates a template from a OVA file containing more than 1 disk and launches an instance using this template, the first disk should be attached to the new instance as the ROOT disk, volumes should be created based on other VMDK disks in the OVA file and should be attached to the instance. I will soon propose a Functional Spec for this improvement. The corresponding JIRA ticket can be found at https://issues.apache.org/jira/browse/CLOUDSTACK-4757 . Thanks, Likitha
RE: [ANNOUNCE] A GCE interface to CloudStack
Nice work you guys ! Darren, our current AWS has support for both query and SOAP. Thanks, Likitha >-Original Message- >From: Darren Shepherd [mailto:darren.s.sheph...@gmail.com] >Sent: Wednesday, September 25, 2013 8:08 AM >To: dev@cloudstack.apache.org >Cc: dev@cloudstack.apache.org; Ian Duffy; Darren Brogan >Subject: Re: [ANNOUNCE] A GCE interface to CloudStack > >I got this running earlier today and was really impressed with it, good job! > >Our current AWS is just SOAP right? How about when we do the query api we do >it as a separate python project just like this. > >Darren > >> On Sep 24, 2013, at 11:40 AM, Frank Zhang wrote: >> >> Take a look at source. Clean and lightweight implementation. Awesome. >> I hope our AWS someday can go this way someday, a separate web server >> in separate repo and using some dynamically language which makes >> smaller code >> >> >>> -Original Message- >>> From: Musayev, Ilya [mailto:imusa...@webmd.net] >>> Sent: Tuesday, September 24, 2013 11:23 AM >>> To: dev@cloudstack.apache.org >>> Cc: Ian Duffy; Darren Brogan >>> Subject: RE: [ANNOUNCE] A GCE interface to CloudStack >>> >>> This looks awesome :) >>> >>>> -Original Message- >>>> From: Chiradeep Vittal [mailto:chiradeep.vit...@citrix.com] >>>> Sent: Tuesday, September 24, 2013 12:59 PM >>>> To: dev@cloudstack.apache.org >>>> Cc: Ian Duffy; Darren Brogan >>>> Subject: Re: [ANNOUNCE] A GCE interface to CloudStack >>>> >>>> Wow. Nice! >>>> >>>>> On 9/24/13 6:04 AM, "sebgoa" wrote: >>>>> >>>>> Hi, >>>>> >>>>> I am quite pumped to announce a Google Compute Engine (GCE) >>>>> interface to CloudStack. >>>>> >>>>> Ian Duffy, Darren Brogan and myself worked on this on github over >>>>> the last month. Our latest branch: >>>>> >>>>> https://github.com/NOPping/cloudstack-gce/tree/refactor >>>>> >>>>> Has been uploaded to pypi: >>>>> >>>>> https://pypi.python.org/pypi/gcloud >>>>> >>>>> A little virtualenv and a pip install gcloud will give you a Flask >>>>> application, with OAuth2 provider and REST routes that map to the >>>>> CloudStack API. >>>>> The routes are compliant with GCE API, which allows you to use the >>>>> Google gcutil cli to talk to your CloudStack cloud. >>>>> >>>>> Of course there are a few caveats that I will not mention, this is >>>>> release 0.0.1, feedback and pr welcome. >>>>> >>>>> Congrats to our two 20 year olds in ireland who are taking names up >>>>> in Dublin ! >>>>> >>>>> Have fun, >>>>> >>>>> -Sebastien >>
RE: Apache CloudStack 4.2.0 (fifth round)
+1 Tested VM life cycle with VMware in advanced zone and AWSAPI EC2 interface. Thanks, Likitha >-Original Message- >From: Animesh Chaturvedi [mailto:animesh.chaturv...@citrix.com] >Sent: Saturday, September 14, 2013 4:43 AM >To: dev@cloudstack.apache.org >Subject: Apache CloudStack 4.2.0 (fifth round) > > >I've created a 4.2.0 release, with 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.2 >Commit: c1e24ff89f6d14d6ae74d12dbca108c35449030f > >List of changes: >https://git-wip- >us.apache.org/repos/asf?p=cloudstack.git;a=blob_plain;f=CHANGES;hb=4.2 > >Source release (checksums and signatures are available at the same >location): >https://dist.apache.org/repos/dist/dev/cloudstack/4.2.0/ > >PGP release keys (signed using 94BE0D7C): >https://dist.apache.org/repos/dist/release/cloudstack/KEYS > >Testing instructions are here: >https://cwiki.apache.org/confluence/display/CLOUDSTACK/Release+test+proced >ure > >Vote will be open for 72 hours (Wednesday 9/18 End of Day PST). > >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)
RE: maven storage plugin project creation
See if this helps - https://cwiki.apache.org/confluence/display/CLOUDSTACK/CloudStack+API+Development . Thanks, Likitha >-Original Message- >From: Amit Das [mailto:amit@cloudbyte.com] >Sent: Thursday, September 05, 2013 7:17 PM >To: dev@cloudstack.apache.org >Subject: maven storage plugin project creation > >Hi folks, > >I am in the process of creating a new storage plugin maven module & need help >in doing so. > >Do we follow any maven based archetype for such maven module creation ? >Are there any links that prescribe the required steps ? > >I was looking at some of the pom files of default, sample & solidfire modules >present in plugins/storage/volume/ & found neither of them have a group-id. > >Is this the desired convention for a cloudstack module ? > > >Regards, >Amit >*CloudByte Inc.* <http://www.cloudbyte.com/>
RE: Issues with 4.2
Sebastien, are you referring to the installation guide? I noticed a few defects too. I have created - https://issues.apache.org/jira/browse/CLOUDSTACK-4602 and updated - https://issues.apache.org/jira/browse/CLOUDSTACK-829 to track them. Please update these bugs if you see any other gaps. Thanks, Likitha >-Original Message- >From: sebgoa [mailto:run...@gmail.com] >Sent: Tuesday, September 03, 2013 5:46 PM >To: dev@cloudstack.apache.org >Subject: Re: Issues with 4.2 > > >On Sep 3, 2013, at 1:45 PM, sebgoa wrote: > >> >> On Sep 2, 2013, at 7:58 PM, Sebastien Goasguen wrote: >> >>> >>> On 2 Sep 2013, at 19:27, Animesh Chaturvedi > wrote: >>> >>>> Sebastien >>>> >>>> DevCloud2 works with fix 1a333f36 for CLOUDSTACK-4559. The fix was >>>> put in 4.2-forward branch by Edison. I need to cherry pick this and >>>> few other critical issues to 4.2 branch for the next VOTE on Tuesday >>>> >>> >>> Ok i will try to cherry pick myself and test before you cut a new RC. >> >> I cherry picked it and got devcloud running. >> Instance started and I was able to ssh into it. >> >> Couple strange things struck my mind: >> >> 1-in the instance view you can take a snapshot. but the snapshot does not get >listed under >Storage. Only if you take a snapshot of the root disk from the >storage menu do you see the snapshot under >storage>view snapshots. >> >> 2-In the infrastructure view, under zone. If you click on the devcloud zone >> you >now see a 'Add VMware datacenter' icon. This triggers a 'Unknown API >command: listVmwareDCs' in the mgt server log. >> >> >> -sebastien > >The good news is that awsapi works fine (the bad is that the documentation for >it >is now wrong...) > > >> >>> >>> >>>> Animesh >>>> >>>> >>>> >>>>> -Original Message- >>>>> From: sebgoa [mailto:run...@gmail.com] >>>>> Sent: Monday, September 02, 2013 8:15 AM >>>>> To: dev@cloudstack.apache.org >>>>> Subject: Issues with 4.2 >>>>> >>>>> Hi, >>>>> >>>>> I spent some time testing 4.2 today: >>>>> >>>>> * Aside from the SNMP Tests errors during build time, >>>>> >>>>> * I got Devcloud up, configured the infrastructure with Marvin, >>>>> logged in on the UI all was well. >>>>> And then impossible to get the systemvm to start. >>>>> >>>>> Using DevCloud is our listed test procedure in the VOTE threads so >>>>> it has to work. >>>>> >>>>> *Got a fresh install of 4.2 on a ubuntu 12.04, got the server up >>>>> and running and then authentication failed with: >>>>> >>>>> WARN [server.auth.SHA256SaltedUserAuthenticator] (934430470@qtp- >>>>> 324730209-0:) The stored password for admin isn't in the right >>>>> format for this authenticator INFO [cloud.user.AccountManagerImpl] >>>>> (934430470@qtp-324730209-0:) User admin in domain ROOT is >>>>> disabled/locked (or account is disabled/locked) >>>>> >>>>> Anyone seeing this ? >>>>> thanks, >>>>> >>>>> -Sebastien >>
RE: [Doc] Please review: Granular configuration parameters doc
+Harikrishna >-Original Message- >From: Jessica Tomechak [mailto:jessica.tomec...@gmail.com] >Sent: Thursday, August 29, 2013 12:00 AM >To: dev@cloudstack.apache.org >Cc: us...@cloudstack.apache.org; Sudha Ponnaganti; Likitha Shetty >Subject: [Doc] Please review: Granular configuration parameters doc > >Hi, >Documentation on granular configuration parameters is ready for review. You >can view the updated text at the link below. This is checked in to both master >and 4.2-forward. > >Please provide your feedback. > >Diff: >https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=bdc87ab > >Bug: >https://issues.apache.org/jira/browse/CLOUDSTACK-2289 > >Regards, >Jessica T.
RE: [Doc] Please review: Change VM account ownership doc
Thanks Jessica , diff looks good to me. >-Original Message- >From: Jessica Tomechak [mailto:jessica.tomec...@gmail.com] >Sent: Wednesday, August 28, 2013 10:42 PM >To: dev@cloudstack.apache.org >Cc: us...@cloudstack.apache.org; Sudha Ponnaganti; Likitha Shetty >Subject: [Doc] Please review: Change VM account ownership doc > >Hi, >Documentation on the expanded capability for moving VMs from one account to >another is ready for review. You can view the updated text at the link below. >This is checked in to both master and 4.2-forward. > >Please provide your feedback. > >Diff: >https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=0d8ce41 > >Bug: >https://issues.apache.org/jira/browse/CLOUDSTACK-2405 > >Regards, >Jessica T.
RE: [ACS42] Cherry pick request for CLOUDSTACK-4471
Thanks Animesh. >-Original Message- >From: Animesh Chaturvedi >Sent: Wednesday, August 28, 2013 10:31 AM >To: Likitha Shetty; dev@cloudstack.apache.org >Subject: RE: [ACS42] Cherry pick request for CLOUDSTACK-4471 > >It was done in morning already while I was reviewing all commits to 4.2-forward >since the last RC build > >> -----Original Message- >> From: Likitha Shetty >> Sent: Tuesday, August 27, 2013 9:49 PM >> To: dev@cloudstack.apache.org >> Cc: Animesh Chaturvedi >> Subject: [ACS42] Cherry pick request for CLOUDSTACK-4471 >> >> Hi Animesh, >> >> Can you please cherry-pick 7cc8ccead541f6089ed48d9a1c335daa458b74fc >> from 4.2-forward branch as a fix for issue CLOUDSTACK-4471. >> >> Thanks, >> Likitha
[ACS42] Cherry pick request for CLOUDSTACK-4471
Hi Animesh, Can you please cherry-pick 7cc8ccead541f6089ed48d9a1c335daa458b74fc from 4.2-forward branch as a fix for issue CLOUDSTACK-4471. Thanks, Likitha
Review Request 13732: AWSAPI server fails to start because of error in bean creation
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/13732/ --- Review request for cloudstack, Kelven Yang and Prachi Damle. Bugs: CLOUDSTACK-4446 Repository: cloudstack-git Description --- Observation --- Bean creation failures during the start up of AWSAPI server. The different failures where - org.springframework.beans.factory.BeanCreationException: Could not autowire field: private com.cloud.user.AccountService com.cloud.user.UserContextInitializer._accountMgr org.springframework.beans.factory.BeanCreationException: Could not autowire field: com.cloud.user.AccountManager com.cloud.servlet.ConsoleProxyServlet._accountMgr Fix --- For AWSAPI restrict the components that are to be scanned to the AWSAPI package. Diffs - awsapi/conf/applicationContext.xml.in 8b3a022 Diff: https://reviews.apache.org/r/13732/diff/ Testing --- 1. Ran mvn -pl :cloud-client-ui jetty:run 2. Ran mvn -Pawsapi -pl :cloud-awsapi jetty:run 3. Using Boto tool tested basic EC2 calls for e.g. get_all_images() - Success (Returned the images present in CS) Thanks, Likitha Shetty
RE: Whats involved in adding an extra hypervisor
Ian, with AWS it’s the other way around. The package allows us to spin up VMs in CS using AWS EC2 API's. -Likitha >-Original Message- >From: Ian Duffy [mailto:i...@ianduffy.ie] >Sent: Friday, August 16, 2013 12:07 PM >To: CloudStack Dev >Subject: Re: Whats involved in adding an extra hypervisor > >Hi Donal and Chiradeep, > >Thanks for your comments. It was an interesting read. > >I might be missing something here but I will ask anyways. If I understand >correctly, at current with awsapi we are able to submit our aws api credentials >to Cloudstack and spin up VMs on aws correct? Is there a reason the >communication with aws could not be provided like a standard hypervisor? what >is the reasoning behind keeping it as an almost separate package? > >The reason I'm asking is because I'm wanting to do something Cloudstack based >for a college project next year. However there is a hard 1 month deadline. I >was >interested to see could a base(or something of demoable quality) for supporting >Google Compute Engine be completed in such a short deadline. > >On 15 August 2013 09:29, Donal Lafferty wrote: >> Definitely possible to add new Hypervisor types, if that's what you're >> asking. >> >> How easy it is depends on how much existing CloudStack infrastructure you >can exploit. Let me out line the task with the help of some planning >questions: >> >> 1. What will be your agent model? Will you talk directly to the hypervisor >(direct connect agent), or will you install a remote agent on the hypervisor >(connected agent). This comes down to whether the hypervisor exposes a high >level API remotely. >> >> 2. What will be your secondary storage model? Secondary storage provides >low IOPS storage accessible to all hypervisors in the zone. Thus, we store the >templates in secondary storage. IIRC, CloudStack supports NFS, S3 and Swift. >Does one of these options suit your data centre, or do you need to expand the >list? Will your agent be able to download disk images in secondary storage to >the hypervisor? >> >> 3. What will be your primary storage model? Typically, primary storage is >high IOPS storage specific to a hypervisor or cluster of hypervisors. The >easiest >to setup is local storage, which can be a hard disk or storage you mount >manually on the hypervisor. Alternatively, you may want to automate mounting >storage on the hypervisor. >> >> 4. What will be your system VM model? System VMs offload the following >functionality from the management server: VM console access, networking >services, and secondary storage (upload) service. You could skip system VMs >and run these services in the management server's host using QuickCloud. You >could run system VMs on an existing hypervisor type, or you could add a new >system VM type for your hypervisor. Keep in mind that QuickCloud can't run >your networking services. Also, if you want to create a new system VM type, >you >have to come up with VM image. >> >> The tricky bits: >> >> 5. What language will your agent use? A direct connect agent sits in the >CloudStack process, so it is written in Java. Alternatively, there is >infrastructure >for a Java-based remote agent, which handles all your communications. If you >need a non-Java remote agent, you are better off sending the kernel commands >over HTTP, which looks more like an RPC mechanism than REST. >> >> 6. How will you know what instructions to implement? You can look at an >existing ServerResource class for a hypervisor to know what command types >there are. The relevant pieces of data in each command can be found out from >existing hypervisor implementations. Alternatively, you can look at test logs, >which contain the data from each command. Eventually you'll want to try your >plugin with CloudStack itself. >> >> Chiradeep's comments relate to #6 above. >> >> >>> -Original Message- >>> From: Chiradeep Vittal [mailto:chiradeep.vit...@citrix.com] >>> Sent: 15 August 2013 02:51 >>> To: dev@cloudstack.apache.org >>> Subject: Re: Whats involved in adding an extra hypervisor >>> >>> Yes, it is a hypervisor plugin. While the extension method may be >>> simple, the impedance mismatch between the CloudStack virtual model >>> and the hypervisor API is what causes the most pain. >>> E.g., CloudStack will hand a VirtualMachineTO object (consisting of >>> cpu/mem/nic) and then you have to use the hypervisor API to construct it. >>> For XS, it involves calling a bunch of XS APIs to 'construct' the VM. >>> For
RE: Question: Has VolumeManager and VolumeManagerImpl been refactored/removed in master
The commit message reads - Moved volume related code into cloud-engine-orchestration. I am guessing the intention was to move the files and not remove them? Thanks, Likitha >-Original Message- >From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com] >Sent: Tuesday, August 13, 2013 10:32 AM >To: dev@cloudstack.apache.org >Subject: Question: Has VolumeManager and VolumeManagerImpl been >refactored/removed in master > >Hi, > >I was curious to learn more about VolumeManager and VolumeManagerImpl in >master. > >They appear to be gone and I was interested in learning how this code has been >refactored. > >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<http://solidfire.com/solution/overview/?video=play> >*(tm)*
RE: [ANNOUNCE] New Committer: Vijay Bhamidipati
Congratulations Vijay ! >-Original Message- >From: Prasanna Santhanam [mailto:t...@apache.org] >Sent: Saturday, August 10, 2013 10:32 AM >To: CloudStack Dev >Subject: [ANNOUNCE] New Committer: Vijay Bhamidipati > >The Project Management Committee (PMC) for Apache CloudStack has asked >Vijay Bhamidipati to become a committer and we are pleased to announce that >they have accepted. > >Being a committer allows many contributors to contribute more autonomously. >For developers, it makes it easier to submit changes and eliminates the need to >have contributions reviewed via the patch submission process. Whether >contributions are development-related or otherwise, it is a recognition of a >contributor's participation in the project and commitment to the project and >the >Apache Way. > >Please join me in congratulating Vijay! > >-- >Prasanna., >on behalf of the Apache CloudStack PMC > > >Powered by BigRock.com
Re: Review Request 13440: CLOUDSTACK-3842: G11N: SC: Some regression issues occurred on build#4.2-256.
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/13440/#review24917 --- Ship it! Ship It! - Likitha Shetty On Aug. 9, 2013, 11:32 a.m., Sanjay Tripathi wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/13440/ > --- > > (Updated Aug. 9, 2013, 11:32 a.m.) > > > Review request for cloudstack, Devdeep Singh and Likitha Shetty. > > > Bugs: CLOUDSTACK-3842 > > > Repository: cloudstack-git > > > Description > --- > > CLOUDSTACK-3842: G11N: SC: Some regression issues occurred on build#4.2-256. > > > Diffs > - > > client/WEB-INF/classes/resources/messages_ja.properties 6970058 > client/WEB-INF/classes/resources/messages_zh_CN.properties 2ea262d > ui/css/cloudstack3.css afebbd1 > > Diff: https://reviews.apache.org/r/13440/diff/ > > > Testing > --- > > Verified the fix locally on cloudstack setup. > > > Thanks, > > Sanjay Tripathi > >
Re: Review Request 13439: CLOUDSTACK-2909: Fix for EN-US keys. Keys are ' and ".
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/13439/#review24914 --- Ship it! Ship It! - Likitha Shetty On Aug. 9, 2013, 11:16 a.m., Sanjay Tripathi wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/13439/ > --- > > (Updated Aug. 9, 2013, 11:16 a.m.) > > > Review request for cloudstack, Devdeep Singh and Likitha Shetty. > > > Bugs: CLOUDSTACK-2909 > > > Repository: cloudstack-git > > > Description > --- > > CLOUDSTACK-2909: Fix for EN-US keys. Keys are ' and " > > > Diffs > - > > services/console-proxy/server/js/ajaxkeys.js 4e4d775 > > Diff: https://reviews.apache.org/r/13439/diff/ > > > Testing > --- > > Verified the fix locally on cloudstack setup. > > > Thanks, > > Sanjay Tripathi > >
RE: [Doc] Dedicated Resources: Public IPs and VLANs per Account is Ready
Looks good to me Radhika. Thank you! From: Radhika Puthiyetath Sent: Tuesday, August 06, 2013 11:04 AM To: Likitha Shetty; us...@cloudstack.apache.org; dev@cloudstack.apache.org; Abhinav Roy Subject: RE: [Doc] Dedicated Resources: Public IPs and VLANs per Account is Ready Hi, Thanks for the review, Likitha. I have incorporated them. The latest doc is attached at https://issues.apache.org/jira/browse/CLOUDSTACK-817. Abhinav, let me know if you have further comments. Thanks -Radhika From: Likitha Shetty Sent: Friday, August 02, 2013 11:42 AM To: Radhika Puthiyetath; us...@cloudstack.apache.org; dev@cloudstack.apache.org; Abhinav Roy Subject: RE: [Doc] Dedicated Resources: Public IPs and VLANs per Account is Ready I just have 2 comments, 1. Since this feature allows the admin to assign (and release) the IP addresses and VLANs only to an account, not both domain and account we need to modify the introduction accordingly. 2. And could you also add the following to section 15.8, If an account has consumed all the VLANs and IPs dedicated to it, the account can acquire the 2 resources from the system. Cloudstack provides the ROOT admin with 2 configuration parameter to modify this default behavior - use.system.public.ips and use.system.guest.vlans. The 2 global configs allow the ROOT admin to disallow an account from acquiring public IPs and guest VLANs from the system if the account has dedicated resources and these dedicated resources have all been consumed. Both these configurations are configurable at the account level too. (https://issues.apache.org/jira/browse/CLOUDSTACK-3011) Everything else looks good. Thanks, Likitha From: Radhika Puthiyetath Sent: Thursday, August 01, 2013 3:51 PM To: us...@cloudstack.apache.org<mailto:us...@cloudstack.apache.org>; dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org>; Abhinav Roy; Likitha Shetty Subject: [Doc] Dedicated Resources: Public IPs and VLANs per Account is Ready Hi, Dedicated Resources: Public IPs and VLANs per Account is Ready documentation is ready for review. The doc is attached at https://issues.apache.org/jira/browse/CLOUDSTACK-817 Please see section 15.8. Reserving Public IP Addresses and VLANs Per Account (132), and provide your feedback. Regards -Radhika
RE: [Doc] Dedicated Resources: Public IPs and VLANs per Account is Ready
I just have 2 comments, 1. Since this feature allows the admin to assign (and release) the IP addresses and VLANs only to an account, not both domain and account we need to modify the introduction accordingly. 2. And could you also add the following to section 15.8, If an account has consumed all the VLANs and IPs dedicated to it, the account can acquire the 2 resources from the system. Cloudstack provides the ROOT admin with 2 configuration parameter to modify this default behavior - use.system.public.ips and use.system.guest.vlans. The 2 global configs allow the ROOT admin to disallow an account from acquiring public IPs and guest VLANs from the system if the account has dedicated resources and these dedicated resources have all been consumed. Both these configurations are configurable at the account level too. (https://issues.apache.org/jira/browse/CLOUDSTACK-3011) Everything else looks good. Thanks, Likitha From: Radhika Puthiyetath Sent: Thursday, August 01, 2013 3:51 PM To: us...@cloudstack.apache.org; dev@cloudstack.apache.org; Abhinav Roy; Likitha Shetty Subject: [Doc] Dedicated Resources: Public IPs and VLANs per Account is Ready Hi, Dedicated Resources: Public IPs and VLANs per Account is Ready documentation is ready for review. The doc is attached at https://issues.apache.org/jira/browse/CLOUDSTACK-817 Please see section 15.8. Reserving Public IP Addresses and VLANs Per Account (132), and provide your feedback. Regards -Radhika
Re: Review Request 12905: Multiple VLAN range API need to accept a list rather than "add" or "remove" per command
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/12905/#review24330 --- Since you have changed the vnet range separator from ';' to ',' PhysicalNetworkVO -> getVnet needs to be updated. This method is referenced in quite a few places. If not already done, please open a bug to track the UI changes that will be needed once this change is checked in. - Likitha Shetty On July 31, 2013, 2:46 a.m., bharat kumar wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/12905/ > --- > > (Updated July 31, 2013, 2:46 a.m.) > > > Review request for cloudstack, Alena Prokharchyk and Sheng Yang. > > > Bugs: Cloudstack-3753 > > > Repository: cloudstack-git > > > Description > --- > > https://issues.apache.org/jira/browse/CLOUDSTACK-3753 > Multiple VLAN range API need to accept a list rather than "add" or "remove" > per command > > > Diffs > - > > api/src/com/cloud/network/NetworkService.java 59ccdbf > > api/src/org/apache/cloudstack/api/command/admin/network/UpdatePhysicalNetworkCmd.java > 333564e > engine/schema/src/com/cloud/dc/dao/DataCenterVnetDao.java e2e6b79 > engine/schema/src/com/cloud/dc/dao/DataCenterVnetDaoImpl.java ced2982 > server/src/com/cloud/network/NetworkServiceImpl.java f1f71ca > server/test/com/cloud/network/MockNetworkManagerImpl.java 4577d0a > server/test/com/cloud/network/UpdatePhysicalNetworkTest.java e3fc36a > server/test/com/cloud/vpc/MockNetworkManagerImpl.java fd61bc6 > > Diff: https://reviews.apache.org/r/12905/diff/ > > > Testing > --- > > Tested on master. > removed the removevlan parameter. > vlan parameter can be used for both addition and removal of valns. > instead of passing only a vlan range. user has to pass all the vlan ranges > that he wants to keep. > the vlan ranges missing in the input and present in the db (not allocated) > will be removed. > > > Thanks, > > bharat kumar > >
RE: [AWS-API] User registration failed with http error code: 404
To run AWSAPI app along with CS - mvn -Pawsapi -pl :cloud-awsapi jetty:run (https://cwiki.apache.org/confluence/display/CLOUDSTACK/How+to+build+on+master+branch). Hope that helps. Thanks, Likitha From: Dharmesh Kakadia [mailto:dhkaka...@gmail.com] Sent: Thursday, July 25, 2013 5:47 PM To: Likitha Shetty; dev; Sebastien Goasguen Subject: Re: [AWS-API] User registration failed with http error code: 404 There is nothing running on 7080 port on my machine ? how do I ensure that service is actually running. I enabled ec2 api from global settings and restarted mgmt server. On UI the property is listed as true. On Thu, Jul 25, 2013 at 5:29 PM, Likitha Shetty mailto:likitha.she...@citrix.com>> wrote: Dharmesh, awsapi service listens on port 7080. From: Dharmesh Kakadia [mailto:dhkaka...@gmail.com<mailto:dhkaka...@gmail.com>] Sent: Thursday, July 25, 2013 5:22 PM To: Likitha Shetty Subject: Re: [AWS-API] User registration failed with http error code: 404 I am trying localhost:8080/awsapi is that correct ? Thanks, Dharmesh On Thu, Jul 25, 2013 at 5:15 PM, Likitha Shetty mailto:likitha.she...@citrix.com>> wrote: Are you trying http://lcoalhost:7080/awsapi ? Thanks, Likitha From: Dharmesh Kakadia [mailto:dhkaka...@gmail.com<mailto:dhkaka...@gmail.com>] Sent: Thursday, July 25, 2013 5:06 PM To: dev; Likitha Shetty Cc: Sebastien Goasguen Subject: Re: [AWS-API] User registration failed with http error code: 404 Thanks for the quick reply. But I am seeing 404 on /awsapi URI. I am running this in devcloud setup on localhost. Is the region name "AmazonEC2" correct ? What I am missing ? Here is my code. import boto import boto.ec2 region = boto.ec2.regioninfo.RegionInfo(name="AmazonEC2", endpoint="localhost") conn = boto.connect_ec2(aws_access_key_id="DqZOJMYHZMn-UCJWYmeIfLElCM4QupmAPgD7Azh7itYZMtOgTqCbichKyxyBxn6qvnQtKURYd7DN-8KDbOMrhA", aws_secret_access_key="QpaT9QSyRLPTriqlf4yfvkxepyZMDmdx4z_4Bi6HFTBLnL_o0l3SDXifBIDwMc3qOM1uFA6pWJ6pl2_n6KnBOQ", is_secure=False, region=region, port=8080, path="/awsapi", api_version="2012-08-15") instance = conn.get_all_images() Thanks, Dharmesh On Thu, Jul 25, 2013 at 3:52 PM, Likitha Shetty mailto:likitha.she...@citrix.com>> wrote: Dharmesh, Since you are using the Boto client I presume you are trying to make EC2 Query API calls. To make Query API calls you don't need to register the user. See if this helps - https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=30736866. Thanks, Likitha >-Original Message- >From: Dharmesh Kakadia [mailto:dhkaka...@gmail.com<mailto:dhkaka...@gmail.com>] >Sent: Thursday, July 25, 2013 3:45 PM >To: dev; Sebastien Goasguen >Subject: [AWS-API] User registration failed with http error code: 404 > >Hi, > >I am trying to use aws-api with boto. > >I am following >http://www.slideshare.net/sebastiengoasguen/cloudstack-ec2-configuration. > >but on slide 8, the command reads "cloud-bridge-register". If I am >understanding >correctly, it should be "cloudstack-aws-api-register" as noted here : >http://cloudstack.apache.org/docs/en- >US/Apache_CloudStack/4.0.2/html/Installation_Guide/aws-ec2-user-setup.html >. > >But I while using the "cloudstack-aws-api-register" command I am getting "User >registration failed with http error code: 404". > >My mgmt server is running on localhost and the url I am using with above >command is "http://lcoalhost:8080/awsapi";. > >Any clue ? > >Thanks, >Dharmesh
RE: [AWS-API] User registration failed with http error code: 404
Are you trying http://lcoalhost:7080/awsapi ? Thanks, Likitha From: Dharmesh Kakadia [mailto:dhkaka...@gmail.com] Sent: Thursday, July 25, 2013 5:06 PM To: dev; Likitha Shetty Cc: Sebastien Goasguen Subject: Re: [AWS-API] User registration failed with http error code: 404 Thanks for the quick reply. But I am seeing 404 on /awsapi URI. I am running this in devcloud setup on localhost. Is the region name "AmazonEC2" correct ? What I am missing ? Here is my code. import boto import boto.ec2 region = boto.ec2.regioninfo.RegionInfo(name="AmazonEC2", endpoint="localhost") conn = boto.connect_ec2(aws_access_key_id="DqZOJMYHZMn-UCJWYmeIfLElCM4QupmAPgD7Azh7itYZMtOgTqCbichKyxyBxn6qvnQtKURYd7DN-8KDbOMrhA", aws_secret_access_key="QpaT9QSyRLPTriqlf4yfvkxepyZMDmdx4z_4Bi6HFTBLnL_o0l3SDXifBIDwMc3qOM1uFA6pWJ6pl2_n6KnBOQ", is_secure=False, region=region, port=8080, path="/awsapi", api_version="2012-08-15") instance = conn.get_all_images() Thanks, Dharmesh On Thu, Jul 25, 2013 at 3:52 PM, Likitha Shetty mailto:likitha.she...@citrix.com>> wrote: Dharmesh, Since you are using the Boto client I presume you are trying to make EC2 Query API calls. To make Query API calls you don't need to register the user. See if this helps - https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=30736866. Thanks, Likitha >-Original Message- >From: Dharmesh Kakadia [mailto:dhkaka...@gmail.com<mailto:dhkaka...@gmail.com>] >Sent: Thursday, July 25, 2013 3:45 PM >To: dev; Sebastien Goasguen >Subject: [AWS-API] User registration failed with http error code: 404 > >Hi, > >I am trying to use aws-api with boto. > >I am following >http://www.slideshare.net/sebastiengoasguen/cloudstack-ec2-configuration. > >but on slide 8, the command reads "cloud-bridge-register". If I am >understanding >correctly, it should be "cloudstack-aws-api-register" as noted here : >http://cloudstack.apache.org/docs/en- >US/Apache_CloudStack/4.0.2/html/Installation_Guide/aws-ec2-user-setup.html >. > >But I while using the "cloudstack-aws-api-register" command I am getting "User >registration failed with http error code: 404". > >My mgmt server is running on localhost and the url I am using with above >command is "http://lcoalhost:8080/awsapi";. > >Any clue ? > >Thanks, >Dharmesh
RE: [AWS-API] User registration failed with http error code: 404
Dharmesh, Since you are using the Boto client I presume you are trying to make EC2 Query API calls. To make Query API calls you don't need to register the user. See if this helps - https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=30736866. Thanks, Likitha >-Original Message- >From: Dharmesh Kakadia [mailto:dhkaka...@gmail.com] >Sent: Thursday, July 25, 2013 3:45 PM >To: dev; Sebastien Goasguen >Subject: [AWS-API] User registration failed with http error code: 404 > >Hi, > >I am trying to use aws-api with boto. > >I am following >http://www.slideshare.net/sebastiengoasguen/cloudstack-ec2-configuration. > >but on slide 8, the command reads "cloud-bridge-register". If I am >understanding >correctly, it should be "cloudstack-aws-api-register" as noted here : >http://cloudstack.apache.org/docs/en- >US/Apache_CloudStack/4.0.2/html/Installation_Guide/aws-ec2-user-setup.html >. > >But I while using the "cloudstack-aws-api-register" command I am getting "User >registration failed with http error code: 404". > >My mgmt server is running on localhost and the url I am using with above >command is "http://lcoalhost:8080/awsapi";. > >Any clue ? > >Thanks, >Dharmesh
Re: Review Request 12504: CLOUDSTACK-2757. Category not persisted when config items are added
> On July 12, 2013, 11:08 a.m., Kishan Kavala wrote: > > Looks good to me Thanks for reviewing Kishan. - Likitha --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/12504/#review23078 --- On July 12, 2013, 10:56 a.m., Likitha Shetty wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/12504/ > --- > > (Updated July 12, 2013, 10:56 a.m.) > > > Review request for cloudstack and Kishan Kavala. > > > Bugs: CLOUDSTACK-2757 > > > Repository: cloudstack-git > > > Description > --- > > Category is not being persisted when configuration items are added in > ConfigurationDaoImpl.getValueAndInitIfNotExist. > Hence it will be set to 'Advanced' which is the default which will lead to > encryption failures if encryption is enabled. > Also cleaned up the code to use VO/DAO instead of SQL. > > > Diffs > - > > engine/schema/src/com/cloud/configuration/dao/ConfigurationDaoImpl.java > fe5f5ae > > Diff: https://reviews.apache.org/r/12504/diff/ > > > Testing > --- > > > Thanks, > > Likitha Shetty > >
Review Request 12504: CLOUDSTACK-2757. Category not persisted when config items are added
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/12504/ --- Review request for cloudstack and Kishan Kavala. Bugs: CLOUDSTACK-2757 Repository: cloudstack-git Description --- Category is not being persisted when configuration items are added in ConfigurationDaoImpl.getValueAndInitIfNotExist. Hence it will be set to 'Advanced' which is the default which will lead to encryption failures if encryption is enabled. Also cleaned up the code to use VO/DAO instead of SQL. Diffs - engine/schema/src/com/cloud/configuration/dao/ConfigurationDaoImpl.java fe5f5ae Diff: https://reviews.apache.org/r/12504/diff/ Testing --- Thanks, Likitha Shetty
Re: Review Request 12364: Follow up fix for CLOUDSTACK-2777
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/12364/#review22908 --- Ship it! Ship It! - Likitha Shetty On July 9, 2013, 3:20 p.m., Rayees Namathponnan wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/12364/ > --- > > (Updated July 9, 2013, 3:20 p.m.) > > > Review request for cloudstack, Likitha Shetty and Prachi Damle. > > > Repository: cloudstack-git > > > Description > --- > > Followup fix for CLOUDSTACK-2777, crypto.properties and xes.keystore moved to > AWSAPI installation location and changed permission to 666 > > > Diffs > - > > packaging/centos63/cloud.spec f7eb629 > > Diff: https://reviews.apache.org/r/12364/diff/ > > > Testing > --- > > Tested > > > Thanks, > > Rayees Namathponnan > >
RE: Query about moving vms across domains
Hi Girish, Both your assumptions are right. And going by the first assumption the test cases that are failing need to be updated. Since the VM is being moved from a subdomain to another under the same domain, the move should be successful and not raise an exception. Thanks, Likitha From: Girish Shilamkar [mailto:gir...@clogeny.com] Sent: Monday, July 08, 2013 5:28 PM To: Likitha Shetty Cc: dev@cloudstack.apache.org Subject: Query about moving vms across domains Hello Likitha, Some of the regression tests for changing domain membership failed. http://jenkins.buildacloud.org/job/test-regression-matrix/34/suite=test_assign_vm/testReport/ Could you please confirm my following assumptions: A domain admin can move vms only amongst its subdomains or between the its domain and subdomain. And root admin can move vms across any domains/subdomains. Is that correct ? Regards, Girish
RE: master not perfect:(
In my case the discussed steps didn't resolve the issue (removing all the tags
from the host , cleaning up systemvm.iso from the codebase , ensuring the
systemvm profile is enabled during maven build and also ensuring the host has
the newly generated systemvm.iso).
Only once I rebooted the host was the issue resolved.
Thanks,
Likitha
>-Original Message-
>From: Hugo Trippaers [mailto:htrippa...@schubergphilis.com]
>Sent: Friday, July 05, 2013 3:23 PM
>To: dev@cloudstack.apache.org
>Subject: RE: master not perfect:(
>
>Hey guys,
>
>Did you use the latest systemvm.iso on the systemvm? This error might occur
>when the classes on the secondary storage vm are out of sync with the classes
>on the management server.
>
>If you are running from a maven build make sure that the systemvm profile is
>enabled to generate the systemvm.iso and that the file is properly
>uploaded/copied.
>
>Cheers,
>
>
>Hugo
>
>> -Original Message-
>> From: Abhinav Roy [mailto:abhinav@citrix.com]
>> Sent: Friday, July 05, 2013 11:44 AM
>> To: dev@cloudstack.apache.org
>> Subject: RE: master not perfect:(
>>
>> I faced the same issue, then I logged on to the xenserver host and
>> deleted the tags, restarted the MS but even after that i could see
>> these errors. Finally I rebooted the Xen Host and after that the error
>> was not seen. Filed a bug for the same,
>> https://issues.apache.org/jira/browse/CLOUDSTACK-3377
>>
>> Thanks and regards,
>> Abhinav
>> -Original Message-
>> From: Daan Hoogland [mailto:dhoogl...@schubergphilis.com]
>> Sent: Friday, July 05, 2013 2:56 PM
>> To: dev@cloudstack.apache.org
>> Subject: master not perfect:(
>>
>> H,
>>
>> I get a repetition of the following sequence of logging when running master.
>> Anybody knows what happened?
>>
>> INFO [agent.manager.AgentManagerImpl] (AgentManager-Handler-11:)
>> Connection from /127.0.0.1 closed but no cleanup was done.
>> WARN [utils.nio.Link] (AgentManager-Selector:) SSL: Fail to find the
>> generated keystore. Loading fail-safe one to continue.
>> ERROR [agent.transport.Request] (AgentManager-Handler-13:) Caught
>> problem with
>> [{"StartupSecondaryStorageCommand":{"type":"SecondaryStorage","dataCe
>> nter":"1","pod":"1","guid":"s-1-VM-
>> NfsSecondaryStorageResource","name":"s-1-VM","version":"4.2.0-
>> SNAPSHOT","iqn":"NoIqn","publicIpAddress":"195.66.90.212","publicNetma
>> s
>> k":"255.255.255.224","publicMacAddress":"06:fb:ca:00:00:01","privateIp
>> Addr
>> ess":"10.200.23.62","privateMacAddress":"06:ad:58:00:00:08","privateNe
>> tma
>> sk":"255.255.255.0","storageIpAddress":"10.200.23.62","storageNetmask"
>> :"2
>> 55.255.255.0","storageMacAddress":"06:ad:58:00:00:08","resourceName":"
>> N fsSecondaryStorageResource","contextMap":{},"wait":0}}]
>> com.google.gson.JsonParseException: The JsonDeserializer
>> com.cloud.agent.transport.ArrayTypeAdaptor@7db106d failed to
>> deserialize json object
>> [{"StartupSecondaryStorageCommand":{"type":"SecondaryStorage","dataCe
>> nter":"1","pod":"1","guid":"s-1-VM-
>> NfsSecondaryStorageResource","name":"s-1-VM","version":"4.2.0-
>> SNAPSHOT","iqn":"NoIqn","publicIpAddress":"195.66.90.212","publicNetma
>> s
>> k":"255.255.255.224","publicMacAddress":"06:fb:ca:00:00:01","privateIp
>> Addr
>> ess":"10.200.23.62","privateMacAddress":"06:ad:58:00:00:08","privateNe
>> tma
>> sk":"255.255.255.0","storageIpAddress":"10.200.23.62","storageNetmask"
>> :"2
>> 55.255.255.0","storageMacAddress":"06:ad:58:00:00:08","resourceName":"
>> N fsSecondaryStorageResource","contextMap":{},"wait":0}}] given the
>> type class [Lcom.cloud.agent.api.Command;
>>at
>> com.google.gson.JsonDeserializerExceptionWrapper.deserialize(JsonDeser
>> ial
>> izerExceptionWrapper.java:64)
>>a
Re: Review Request 12184: Fix for defect CLOUDSTACK-2927
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/12184/#review22587 --- Ship it! Ship It! - Likitha Shetty On June 29, 2013, 12:28 a.m., Rayees Namathponnan wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/12184/ > --- > > (Updated June 29, 2013, 12:28 a.m.) > > > Review request for cloudstack and Prachi Damle. > > > Bugs: CLOUDSTACK-2927 > > > Repository: cloudstack-git > > > Description > --- > > Updated cloud.spec to package from awsapi/resource/Axis2/axis2.xml > cloudstack-bridge/webapps/awsapi/WEB-INF/conf > > > Diffs > - > > > Diff: https://reviews.apache.org/r/12184/diff/ > > > Testing > --- > > tested > > > File Attachments > > > File added > > https://reviews.apache.org/media/uploaded/files/2013/06/29/0001-Adding-axis2.xml-to-cloudstack-bridge-webapps-awsapi.patch > > > Thanks, > > Rayees Namathponnan > >
Re: Review Request: CLOUDSTACK-2167: The Vlan ranges displayed are not in ascending order.
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/11708/#review22148 --- Ship it! Ship It! - Likitha Shetty On June 19, 2013, 11:37 a.m., Saksham Srivastava wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/11708/ > --- > > (Updated June 19, 2013, 11:37 a.m.) > > > Review request for cloudstack and Devdeep Singh. > > > Description > --- > > When multiple vlan ranges are added to a physical networks the vlan ranges > displayed in the output of the listPhysicalNetworks api displays the vlan > range in the order the ranges were added,Instead if they are displayed in the > ascending order range this would make it easy for the end user. > > > This addresses bug CLOUDSTACK-2167. > > > Diffs > - > > server/src/com/cloud/api/ApiResponseHelper.java 7ffa30f > > Diff: https://reviews.apache.org/r/11708/diff/ > > > Testing > --- > > The response of list api is now enhanced: > > 1 > > 49e5cdfc-2c14-415a-9dd3-38ac2fdeef54 > Physical Network 1 > ZONE > 0bd17058-2931-479b-98b5-29c8c91c24d3 > Enabled > 480-504;910-914;916-918;920-923;925-934;936-940 > VLAN > > > Build passes successfully. > > > Thanks, > > Saksham Srivastava > >
Re: Review Request: CS-2273: Automation: Change account membership for VMs
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/11307/#review21084 --- test/integration/component/test_assign_vm.py <https://reviews.apache.org/r/11307/#comment43623> Got it, thanks test/integration/component/test_assign_vm.py <https://reviews.apache.org/r/11307/#comment43622> All snapshots(of both root and attached volumes)are deleted. And the since the VM will be successfully moved shouldn't test condition be different? test/integration/component/test_assign_vm.py <https://reviews.apache.org/r/11307/#comment43624> Even the root disk snapshots are deleted. And since the VM will be successfully moved if both the domains are under the same domain admin shouldn't the test condition change? test/integration/component/test_assign_vm.py <https://reviews.apache.org/r/11307/#comment43627> Oh that makes sense. If the resource type is snapshot shouldn't the value of resourceType parameter be '3' for updateResourceLimit API? I am a little confused. So the test case is that we reduce the snapshot resource limit of subdomain2 to 1 and try to move a VM with 1 snapshot to subdomain1? - Likitha Shetty On May 28, 2013, 9:45 a.m., Ashutosh Kelkar wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/11307/ > --- > > (Updated May 28, 2013, 9:45 a.m.) > > > Review request for cloudstack, Likitha Shetty, Prasanna Santhanam, Parth > Jagirdar, and Girish Shilamkar. > > > Description > --- > > Testcases for changing account membership for vas > > > This addresses bug CLOUDSTACK-2273. > > > Diffs > - > > test/integration/component/test_assign_vm.py PRE-CREATION > tools/marvin/marvin/integration/lib/base.py f3a96bd > > Diff: https://reviews.apache.org/r/11307/diff/ > > > Testing > --- > > > Thanks, > > Ashutosh Kelkar > >
Re: Review Request: CS-2273: Automation: Change account membership for VMs
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/11307/#review21081 --- First two comments have been repeated, please ignore the duplicates. - Likitha Shetty On May 28, 2013, 5:29 a.m., Ashutosh Kelkar wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/11307/ > --- > > (Updated May 28, 2013, 5:29 a.m.) > > > Review request for cloudstack, Likitha Shetty, Prasanna Santhanam, and Girish > Shilamkar. > > > Description > --- > > Testcases for changing account membership for vas > > > This addresses bug CLOUDSTACK-2273. > > > Diffs > - > > test/integration/component/test_assign_vm.py PRE-CREATION > tools/marvin/marvin/integration/lib/base.py f3a96bd > > Diff: https://reviews.apache.org/r/11307/diff/ > > > Testing > --- > > > Thanks, > > Ashutosh Kelkar > >
Re: Review Request: CS-2273: Automation: Change account membership for VMs
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/11307/#review21077 --- test/integration/component/test_assign_vm.py <https://reviews.apache.org/r/11307/#comment43587> How is this test case different from test_07 test/integration/component/test_assign_vm.py <https://reviews.apache.org/r/11307/#comment43589> How is this test different from test_07? test/integration/component/test_assign_vm.py <https://reviews.apache.org/r/11307/#comment43591> create_vm with pf=true has been implemented? test/integration/component/test_assign_vm.py <https://reviews.apache.org/r/11307/#comment43588> create_vm with pf=true has been implemented? test/integration/component/test_assign_vm.py <https://reviews.apache.org/r/11307/#comment43594> If a VM with attached volumes is moved then the VM along with the volumes will be successfully moved to the new owner. test/integration/component/test_assign_vm.py <https://reviews.apache.org/r/11307/#comment43596> When a VM is moved the snapshots of the attached volumes is deleted and the move is successful. test/integration/component/test_assign_vm.py <https://reviews.apache.org/r/11307/#comment43597> In this test case we are setting the limit on the number of VM's that can be in subdomain1 to 1. Haven't we already moved a number of VMs to subdomain1 that are yet to cleaned up? test/integration/component/test_assign_vm.py <https://reviews.apache.org/r/11307/#comment43607> Same concern as above. Also, can you specify for what resource the account limit has been reached? If it is VM how is it different from test_16? - Likitha Shetty On May 28, 2013, 5:29 a.m., Ashutosh Kelkar wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/11307/ > --- > > (Updated May 28, 2013, 5:29 a.m.) > > > Review request for cloudstack, Likitha Shetty, Prasanna Santhanam, and Girish > Shilamkar. > > > Description > --- > > Testcases for changing account membership for vas > > > This addresses bug CLOUDSTACK-2273. > > > Diffs > - > > test/integration/component/test_assign_vm.py PRE-CREATION > tools/marvin/marvin/integration/lib/base.py f3a96bd > > Diff: https://reviews.apache.org/r/11307/diff/ > > > Testing > --- > > > Thanks, > > Ashutosh Kelkar > >
Re: Review Request: CS-2273: Automation: Change account membership for VMs
> On May 23, 2013, 6:14 a.m., Likitha Shetty wrote: > > Ashutosh, are you referring to TP 8 in the Test-Plan? If yes, then the TP is still valid because in the TP the sub-domains (SubDomain1 and SubDomain2) that we are trying to move the VM’s between are under the same domain(Doamin1). But from what I can see, in case of this test condition the sub-domains(subdomain1 and subdomain2) that we are trying to move the VM’s between are under two different domains. Is that right? If we are trying to test TP 8 in this test then we can change line 155 from cls.sdomain_account_user2 = create_domain_account_user(cls.domain_account_user2['domain']) to cls.sdomain_account_user2 = create_domain_account_user(cls.domain_account_user1['domain']). With that change the test condition can pass the VM move. - Likitha --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/11307/#review20929 --- On May 28, 2013, 5:29 a.m., Ashutosh Kelkar wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/11307/ > --- > > (Updated May 28, 2013, 5:29 a.m.) > > > Review request for cloudstack, Likitha Shetty, Prasanna Santhanam, and Girish > Shilamkar. > > > Description > --- > > Testcases for changing account membership for vas > > > This addresses bug CLOUDSTACK-2273. > > > Diffs > - > > test/integration/component/test_assign_vm.py PRE-CREATION > tools/marvin/marvin/integration/lib/base.py f3a96bd > > Diff: https://reviews.apache.org/r/11307/diff/ > > > Testing > --- > > > Thanks, > > Ashutosh Kelkar > >
RE: [ANNOUNCE] New committer: Venkata Swamy
Congratulations Swamy :) >-Original Message- >From: Chip Childers [mailto:chip.child...@sungard.com] >Sent: Friday, May 24, 2013 3:00 AM >To: >Subject: [ANNOUNCE] New committer: Venkata Swamy > >The Project Management Committee (PMC) for Apache CloudStack has asked >Venkata Swamy to become a committer and we are pleased to announce that >they have accepted. > >Being a committer allows many contributors to contribute more autonomously. >For developers, it makes it easier to submit changes and eliminates the need to >have contributions reviewed via the patch submission process. Whether >contributions are development-related or otherwise, it is a recognition of a >contributor's participation in the project and commitment to the project and >the >Apache Way. > >Please join me in congratulating Venkata! > >-chip >on behalf of the CloudStack PMC
RE: [ANNOUNCE] New committer: Sangeetha Hariharan
Congratulations! From: Alex Huang [alex.hu...@citrix.com] Sent: Friday, May 24, 2013 11:56 AM To: dev@cloudstack.apache.org Subject: [ANNOUNCE] New committer: Sangeetha Hariharan The Project Management Committee (PMC) for Apache CloudStack has asked Sangeetha Hariharan to become a committer and we are pleased to announce that they have accepted. Being a committer allows many contributors to contribute more autonomously. For developers, it makes it easier to submit changes and eliminates the need to have contributions reviewed via the patch submission process. Whether contributions are development-related or otherwise, it is a recognition of a contributor's participation in the project and commitment to the project and the Apache Way. Please join me in congratulating Sangeetha! --Alex on behalf of the CloudStack PMC
RE: [ANNOUNCE] New committer: Wei Zhou
Congrats Wei! >-Original Message- >From: Chip Childers [mailto:chip.child...@sungard.com] >Sent: Friday, May 24, 2013 2:53 AM >To: >Subject: [ANNOUNCE] New committer: Wei Zhou > >The Project Management Committee (PMC) for Apache CloudStack has asked >Wei Zhou to become a committer and we are pleased to announce that they >have accepted. > >Being a committer allows many contributors to contribute more autonomously. >For developers, it makes it easier to submit changes and eliminates the need to >have contributions reviewed via the patch submission process. Whether >contributions are development-related or otherwise, it is a recognition of a >contributor's participation in the project and commitment to the project and >the >Apache Way. > >Please join me in congratulating Wei! > >-chip >on behalf of the CloudStack PMC
RE: [ANNOUNCE] New committer: Venkata Swamy
Congratulations Swamy :) >-Original Message- >From: Chip Childers [mailto:chip.child...@sungard.com] >Sent: Friday, May 24, 2013 3:00 AM >To: >Subject: [ANNOUNCE] New committer: Venkata Swamy > >The Project Management Committee (PMC) for Apache CloudStack has asked >Venkata Swamy to become a committer and we are pleased to announce that >they have accepted. > >Being a committer allows many contributors to contribute more autonomously. >For developers, it makes it easier to submit changes and eliminates the need to >have contributions reviewed via the patch submission process. Whether >contributions are development-related or otherwise, it is a recognition of a >contributor's participation in the project and commitment to the project and >the >Apache Way. > >Please join me in congratulating Venkata! > >-chip >on behalf of the CloudStack PMC
RE: [ANNOUNCE] New committer: Sailaja Mada
Congratulations Sailaja ! >-Original Message- >From: Chip Childers [mailto:chip.child...@sungard.com] >Sent: Friday, May 24, 2013 2:52 AM >To: >Subject: [ANNOUNCE] New committer: Sailaja Mada > >The Project Management Committee (PMC) for Apache CloudStack has asked >Sailaja Mada to become a committer and we are pleased to announce that they >have accepted. > >Being a committer allows many contributors to contribute more autonomously. >For developers, it makes it easier to submit changes and eliminates the need to >have contributions reviewed via the patch submission process. Whether >contributions are development-related or otherwise, it is a recognition of a >contributor's participation in the project and commitment to the project and >the >Apache Way. > >Please join me in congratulating Sailaja! > >-chip >on behalf of the CloudStack PMC
Re: Review Request: CS-2273: Automation: Change account membership for VMs
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/11307/#review20929 --- test/integration/component/test_assign_vm.py <https://reviews.apache.org/r/11307/#comment43114> If a domain admin tries to move a VM to an account in a subdomain that belongs to a different domain, the request should fail. This is because a domain admin can only move VM's between 2 accounts that are in the domain path. So shouldn't the check condition of test_08 be changed? - Likitha Shetty On May 23, 2013, 3:56 a.m., Ashutosh Kelkar wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/11307/ > --- > > (Updated May 23, 2013, 3:56 a.m.) > > > Review request for cloudstack, Likitha Shetty, Prasanna Santhanam, and Girish > Shilamkar. > > > Description > --- > > Testcases for changing account membership for vas > > > This addresses bug CLOUDSTACK-2273. > > > Diffs > - > > test/integration/component/test_assign_vm.py PRE-CREATION > tools/marvin/marvin/integration/lib/base.py f3a96bd > > Diff: https://reviews.apache.org/r/11307/diff/ > > > Testing > --- > > > Thanks, > > Ashutosh Kelkar > >
RE: assignVirtualMachine API fails
Girish, I am not able to reproduce this on master. Can you double check if port forwarding has not been set on the VM? And if a PF rule has been configured then it is the expected behavior. Thanks, Likitha From: Girish Shilamkar [mailto:gir...@clogeny.com] Sent: Wednesday, May 22, 2013 12:40 PM To: dev@cloudstack.apache.org Cc: Likitha Shetty; Parth Jagirdar Subject: assignVirtualMachine API fails Hello, While writing automation tests Changing account membership for VMs, assignVirtualMachine API fails with errorCode: 530, errorText:Failed to move vm Remove the Port forwarding rules for this VM before assigning to another user. This happens even though vm wasn't set any PF rule. We saw this on CloudStack-non-OSS-MASTER-373-rhel6.3 Has anyone seen this problem before ? PFA, management server log. Regards, Girish
RE: [ACS42] System VM's are failed to start with NPE with latest master(VMWARE)
I saw the same issue with Xen. Thanks, Likitha >-Original Message- >From: Nitin Mehta [mailto:nitin.me...@citrix.com] >Sent: Thursday, May 16, 2013 5:54 PM >To: dev@cloudstack.apache.org >Cc: Sailaja Mada >Subject: Re: [ACS42] System VM's are failed to start with NPE with latest >master(VMWARE) > >Is this only for vmware ? Did you try other hypervisors since it looks generic >enough ? > >On 16/05/13 5:19 PM, "Sailaja Mada" wrote: > >>Hi, >> >>With latest master , System VM's are failed to start with NPE. Is there >>any issue with recent fixes ? ( VMWARE) >> >>2013-05-16 17:12:20,523 DEBUG [cloud.capacity.CapacityManagerImpl] >>(secstorage-1:null) release cpu from host: 1, old used: 0,reserved: 0, >>actual total: 9572, total with overprovisioning: 9572; new used: >>0,reserved:0; movedfromreserved: false,moveToReserveredfalse >>2013-05-16 17:12:20,523 DEBUG [cloud.capacity.CapacityManagerImpl] >>(secstorage-1:null) release mem from host: 1, old used: 0,reserved: 0, >>total: 17166258176; new used: 0,reserved:0; movedfromreserved: >>false,moveToReserveredfalse >>2013-05-16 17:12:20,524 WARN >>[storage.secondary.SecondaryStorageManagerImpl] (secstorage-1:null) >>Exception while trying to start secondary storage vm >>java.lang.NullPointerException >>at >>com.cloud.capacity.CapacityManagerImpl.postStateTransitionEvent(Capacit >>yMa >>nagerImpl.java:684) >>at >>com.cloud.capacity.CapacityManagerImpl.postStateTransitionEvent(Capacit >>yMa >>nagerImpl.java:90) >>at >>com.cloud.utils.fsm.StateMachine2.transitTo(StateMachine2.java:117) >>at >>com.cloud.vm.VirtualMachineManagerImpl.stateTransitTo(VirtualMachineMan >>age >>rImpl.java:1251) >>at >>com.cloud.vm.VirtualMachineManagerImpl.changeState(VirtualMachineMana >ge >>rIm >>pl.java:660) >>at >>com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineMana >g >>erI >>mpl.java:817) >>at >>com.cloud.vm.VirtualMachineManagerImpl.start(VirtualMachineManagerImpl. >>jav >>a:547) >>at >>com.cloud.vm.VirtualMachineManagerImpl.start(VirtualMachineManagerImpl. >>jav >>a:540) >>at >>com.cloud.storage.secondary.SecondaryStorageManagerImpl.startSecStorage >>Vm( >>SecondaryStorageManagerImpl.java:262) >>at >>com.cloud.storage.secondary.SecondaryStorageManagerImpl.allocCapacity(S >>eco >>ndaryStorageManagerImpl.java:687) >>at >>com.cloud.storage.secondary.SecondaryStorageManagerImpl.expandPool(Seco >>nda >>ryStorageManagerImpl.java:1303) >>at >>com.cloud.secstorage.PremiumSecondaryStorageManagerImpl.scanPool(Premi >u >>mSe >>condaryStorageManagerImpl.java:123) >>at >>com.cloud.secstorage.PremiumSecondaryStorageManagerImpl.scanPool(Premi >u >>mSe >>condaryStorageManagerImpl.java:50) >>at >>com.cloud.vm.SystemVmLoadScanner.loadScan(SystemVmLoadScanner.java:10 >4) >>at >>com.cloud.vm.SystemVmLoadScanner.access$100(SystemVmLoadScanner.java: >33) >>at >>com.cloud.vm.SystemVmLoadScanner$1.reallyRun(SystemVmLoadScanner.java >:81) >>at >>com.cloud.vm.SystemVmLoadScanner$1.run(SystemVmLoadScanner.java:72) >>at >>java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) >>at >>java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:351) >>at >>java.util.concurrent.FutureTask.runAndReset(FutureTask.java:178) >>at >>java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.ac >>ces >>s$201(ScheduledThreadPoolExecutor.java:165) >>at >>java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.ru >>n(S >>cheduledThreadPoolExecutor.java:267) >>at >>java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java: >>1110) >>at >>java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.j >>ava >>:603) >>at java.lang.Thread.run(Thread.java:679) >>2013-05-16 17:12:20,526 INFO >>[storage.secondary.SecondaryStorageManagerImpl] (secstorage-1:null) >>Unable to start secondary storage vm for standby capacity, secStorageVm >>vm Id : 4, will recycle it and start a new one >>2013-05-16 17:12:20,529 DEBUG [cloud.vm.VirtualMachineManagerImpl] >>(secstorage-1:null) VM is already stopped: >>VM[SecondaryStorageVm|s-4-VM] >>2013-05-16 17:12:20,537 DEBUG [cloud.capacity.CapacityManagerImpl] >>(secstorage-1:null) VM state transitted from :Stopped to Expunging with >>event: ExpungeOperationvm's original host id: null new host id: null >>host id before state transition: null >>2013-05-16 17:12:20,540 DEBUG [cloud.vm.VirtualMachineManagerImpl] >>(secstorage-1:null) Destroying vm VM[SecondaryStorageVm|s-4-VM] >> >>Thanks, >>Sailaja.M
RE: [MERGE] Dedicate guest vlan ranges to account
Prasanna, fixed the error.
About the API naming of commands related to guest vlan range dedication, the
API names were chosen to be consistent with the commands related to dedication
of other resources (Host, Pod, Cluster and Zone -
https://reviews.apache.org/r/10797/ ).
In fact I was thinking of renaming the commands related to Public Ip Ranges
dedication to :
dedicatePublicIpRange
releaseDedicatedPublicIpRange
Since we are operating on a dedicated resource isn't it more fitting?
Thank you,
Likitha
-Original Message-
>From: Prasanna Santhanam [mailto:t...@apache.org]
>Sent: Tuesday, May 07, 2013 3:37 PM
>To: dev@cloudstack.apache.org
>Subject: Re: [MERGE] Dedicate guest vlan ranges to account
>
>On Mon, May 06, 2013 at 08:52:38AM +, Likitha Shetty wrote:
>> Thanks for reviewing.
>> Merged in to master - c8d843241e144288300c1912a25b201e010bb7a0.
>>
>
>I tried to run your test but looks like the AccessChecks weren't in place for
>your
>APIs. Since these are admin (?) APIs I've put them into commands.properties.in
>with the admin mask. The APIs then are discovered successfully by the server.
>But the test fails as shown
>below:
>
>~/workspace/cloudstack/incubator-cloudstack(branch:master*) » nosetests --
>with-marvin --marvin-config=setup/dev/advanced.cfg
>test/integration/smoke/test_guest_vlan_range.py --load Test guest vlan range
>dedication ... ERROR
>
>=
>=
>ERROR: Test guest vlan range dedication
>--
>Traceback (most recent call last):
> File "/Users/tsp/workspace/cloudstack/incubator-
>cloudstack/test/integration/smoke/test_guest_vlan_range.py", line 155, in
>test_dedicateGuestVlanRange
>id=dedicate_guest_vlan_range_response.id
> File "/Library/Python/2.7/site-packages/marvin/integration/lib/base.py", line
>2205, in listDedicated
>return map(lambda pn : PhysicalNetwork(pn.__dict__),
>apiclient.listDedicatedGuestVlanRanges(cmd))
> File "/Library/Python/2.7/site-
>packages/marvin/cloudstackAPI/cloudstackAPIClient.py", line 819, in
>listDedicatedGuestVlanRanges
>response = self.connection.marvin_request(command,
>response_type=response, method=method)
> File "/Library/Python/2.7/site-packages/marvin/cloudstackConnection.py", line
>215, in marvin_request
>response = jsonHelper.getResultObj(response.json(), response_type)
> File "/Library/Python/2.7/site-packages/marvin/jsonHelper.py", line 128, in
>getResultObj
>raise
>cloudstackException.cloudstackAPIException(responseName.replace("response",
>""), errMsg)
>cloudstackAPIException: Execute cmd: listdedicatedguestvlanranges failed, due
>to: errorCode: 431, errorText:Unable to execute API command
>listdedicatedguestvlanranges due to invalid value. Invalid parameter id
>value=c6fe7bf1-adb1-4423-8ac9-6ea6febea147 due to incorrect long value
>format, or entity does not exist or due to incorrect parameter annotation for
>the
>field in api cmd class.
>
>This looks like an annotation/type error in the field for id. Can you please
>take a
>look?
>
>
>Also, I'm not sure if the naming can be made less verbose for the dedicateXxx
>APIs.
>
>For public IP dedication we simply call:
>dedicatePublicIpRange
>releasePublicIpRange
>listVlanIpRanges (legacy)
>
>but for guestVlan dedication we have:
>
>dedicateGuestVlanRange
>releaseDedicatedGuestVlanRange (releaseGuestVlanRange?)
>listDedicatedGuestVlanRanges (listGuestVlanRanges? &account=
>&domainid=)
>
>I'm purely looking at naming only, there's probably a reason why these are
>named so.
>
>--
>Prasanna.,
>
>
>Powered by BigRock.com
RE: [MERGE] Dedicate guest vlan ranges to account
Thanks for reviewing. Merged in to master - c8d843241e144288300c1912a25b201e010bb7a0. Thank you, Likitha >-Original Message- >From: Prasanna Santhanam [mailto:t...@apache.org] >Sent: Monday, May 06, 2013 12:52 PM >To: dev@cloudstack.apache.org >Subject: Re: [MERGE] Dedicate guest vlan ranges to account > >+1 - tests look good. > >On Thu, May 02, 2013 at 12:28:09PM +, Hugo Trippaers wrote: >> Looks good to me >> >> +1 to merge >> >> Cheers, >> >> Hugo >> >> > -Original Message- >> > From: Likitha Shetty [mailto:likitha.she...@citrix.com] >> > Sent: Thursday, May 02, 2013 12:28 PM >> > To: dev@cloudstack.apache.org >> > Subject: RE: [MERGE] Dedicate guest vlan ranges to account >> > >> > Updated branch dedicate-guest-vlan-ranges_2 with the suggested changes. >> > >> > Thanks, >> > Likitha >> > >> > >-Original Message- >> > >From: Likitha Shetty [mailto:likitha.she...@citrix.com] >> > >Sent: Thursday, May 02, 2013 10:58 AM >> > >To: dev@cloudstack.apache.org >> > >Subject: RE: [MERGE] Dedicate guest vlan ranges to account >> > > >> > >Thanks for taking a look Hugo. >> > >I will update the branch with the fixes. >> > > >> > >Thanks, >> > >Likitha >> > > >> > >>-Original Message- >> > >>From: Hugo Trippaers [mailto:htrippa...@schubergphilis.com] >> > >>Sent: Wednesday, May 01, 2013 5:07 PM >> > >>To: dev@cloudstack.apache.org >> > >>Subject: RE: [MERGE] Dedicate guest vlan ranges to account >> > >> >> > >>Likitha, >> > >> >> > >>Couple of remarks on the merge request: >> > >> >> > >>I think the calls you added to the system should fail with an >> > >>informative error message if the physical network does not have >> > >>the isolation type VLAN, as your code is only usable in networks >> > >>with VLAN style >> > >isolation. >> > >> >> > >>Can you double check your formatting and line endings of the new files? >> > >>For example DedicateGuestVlanRangeCmd.java seems to have windows >> > style >> > >>line endings. >> > >> >> > >> I also noticed some files with changed permissions (from 644 to >> > >>755) (in one case without any changes in the file itself). Can >> > >>you fix that? Permissions should be 644 for java code. >> > >> >> > >>Cheers, >> > >> >> > >>Hugo >> > >> >> > >>> -Original Message- >> > >>> From: Likitha Shetty [mailto:likitha.she...@citrix.com] >> > >>> Sent: Wednesday, May 01, 2013 12:39 PM >> > >>> To: dev@cloudstack.apache.org >> > >>> Subject: [MERGE] Dedicate guest vlan ranges to account >> > >>> >> > >>> Hi all, >> > >>> >> > >>> I would like to merge the feature Dedicate Guest VLAN range to master. >> > >>> >> > >>> Jira ticket - >> > >>> https://issues.apache.org/jira/browse/CLOUDSTACK-704 >> > >>> FS - https://cwiki.apache.org/confluence/display/CLOUDSTACK/FS- >> > >>> +Dedicate+Guest+VLANs+per+tenant >> > >>> Branch - dedicate-guest-vlan-ranges_2 (was developed in branch >> > >>> dedicate- >> > >>> guest-vlan-ranges) Unit tests - Unit tests for the new API's >> > >>> can be found at >> > >>> server/test/com/cloud/network/DedicateGuestVlanRangesTest.java >> > >>> Integration tests - Python tests can be found be found at >> > >>> test/integration/smoke/test_guest_vlan_range.py >> > >>> Rebased the branch with master - Commit id: >> > >>> 807ad0a39ab272a4af2de3156b0b367570acccea >> > >>> RAT - RAT build is successful and no new dependencies introduced >> > >>> >> > >>> Thanks, >> > >>> Likitha > >-- >Prasanna., > > >Powered by BigRock.com
