[jira] [Commented] (CLOUDSTACK-9551) Pull KVM agent's tmp folder usage within its own folder structure

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15604289#comment-15604289
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9551:


Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/1728
  
@rhtyd a Jenkins job has been kicked to build packages. I'll keep you 
posted as I make progress.


> Pull KVM agent's tmp folder usage within its own folder structure
> -
>
> Key: CLOUDSTACK-9551
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9551
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.2.1, 4.7.1, 4.9.1.0
>Reporter: Abhinandan Prateek
>Assignee: Abhinandan Prateek
>
> We ran into an issue today where the sysadmins wanted to put /tmp on its own 
> mount and set the "noexec" mount flag as a security measure. This is 
> incompatible with the CloudStack KVM agent, because it stores JNA tmp files 
> here and Java is unable to map into these objects. To get around this we 
> moved the agent's temp dir to live with the agent files, which seems like a 
> reasonable thing to do regardless of whether you're trying to secure /tmp.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9551) Pull KVM agent's tmp folder usage within its own folder structure

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15604286#comment-15604286
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9551:


Github user rhtyd commented on the issue:

https://github.com/apache/cloudstack/pull/1728
  
LGTM.
@blueorangutan package


> Pull KVM agent's tmp folder usage within its own folder structure
> -
>
> Key: CLOUDSTACK-9551
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9551
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.2.1, 4.7.1, 4.9.1.0
>Reporter: Abhinandan Prateek
>Assignee: Abhinandan Prateek
>
> We ran into an issue today where the sysadmins wanted to put /tmp on its own 
> mount and set the "noexec" mount flag as a security measure. This is 
> incompatible with the CloudStack KVM agent, because it stores JNA tmp files 
> here and Java is unable to map into these objects. To get around this we 
> moved the agent's temp dir to live with the agent files, which seems like a 
> reasonable thing to do regardless of whether you're trying to secure /tmp.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9551) Pull KVM agent's tmp folder usage within its own folder structure

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15604268#comment-15604268
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9551:


GitHub user abhinandanprateek opened a pull request:

https://github.com/apache/cloudstack/pull/1728

CLOUDSTACK-9551: Move java tmp dir to cloudstack-agent's path to avoid

Move java tmp dir to cloudstack-agent's path to avoid noexec on /tmp

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/shapeblue/cloudstack 4.9_9551

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/cloudstack/pull/1728.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 #1728


commit bd85e5b4da0be5177f7fd766641c75dabaf9c45d
Author: Abhinandan Prateek 
Date:   2016-10-20T05:37:52Z

CLOUDSTACK-9551: Move java tmp dir to cloudstack-agent's path to avoid
noexec on /tmp




> Pull KVM agent's tmp folder usage within its own folder structure
> -
>
> Key: CLOUDSTACK-9551
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9551
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.2.1, 4.7.1, 4.9.1.0
>Reporter: Abhinandan Prateek
>Assignee: Abhinandan Prateek
>
> We ran into an issue today where the sysadmins wanted to put /tmp on its own 
> mount and set the "noexec" mount flag as a security measure. This is 
> incompatible with the CloudStack KVM agent, because it stores JNA tmp files 
> here and Java is unable to map into these objects. To get around this we 
> moved the agent's temp dir to live with the agent files, which seems like a 
> reasonable thing to do regardless of whether you're trying to secure /tmp.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9511) fix test_privategw_acl.py to handle multiple physical networks

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15604213#comment-15604213
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9511:


Github user abhinandanprateek commented on the issue:

https://github.com/apache/cloudstack/pull/1724
  
@murali-reddy LGTM on code review.


> fix test_privategw_acl.py to handle multiple physical networks
> --
>
> Key: CLOUDSTACK-9511
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9511
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: marvin
>Affects Versions: 4.8.1
> Environment: CentOS 7.2 + VMware 5.5u3 + NFS Primary/Secondary Storage
> CentOS 7.2 + XenServer 6.5 + NFS Primary/Secondary Storage
>Reporter: Murali Reddy
>Assignee: Murali Reddy
>Priority: Critical
>  Labels: 4.8.2.0-smoke-test-failure
> Fix For: 4.10.0.0, 4.9.1.0, 4.8.2.0
>
>
> Smoke test test_privategw_acl.py works only if there is single physical 
> network in the zone. If there are separate physical networks for different 
> traffic, then test will fail, as it is hard coded to read to first physical 
> network which may not be the physical network that has guest traffic.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9511) fix test_privategw_acl.py to handle multiple physical networks

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15604138#comment-15604138
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9511:


Github user rhtyd commented on the issue:

https://github.com/apache/cloudstack/pull/1724
  
@murali-reddy thanks, I've added a cleanup step b/w tests to ensure old 
resources can be cleared. Is there a way to modify/run the test to avoid any 
such intermittent error?


https://github.com/shapeblue/Trillian/blob/master/Ansible/roles/marvin/templates/smoketests.sh.j2#L27


> fix test_privategw_acl.py to handle multiple physical networks
> --
>
> Key: CLOUDSTACK-9511
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9511
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: marvin
>Affects Versions: 4.8.1
> Environment: CentOS 7.2 + VMware 5.5u3 + NFS Primary/Secondary Storage
> CentOS 7.2 + XenServer 6.5 + NFS Primary/Secondary Storage
>Reporter: Murali Reddy
>Assignee: Murali Reddy
>Priority: Critical
>  Labels: 4.8.2.0-smoke-test-failure
> Fix For: 4.10.0.0, 4.9.1.0, 4.8.2.0
>
>
> Smoke test test_privategw_acl.py works only if there is single physical 
> network in the zone. If there are separate physical networks for different 
> traffic, then test will fail, as it is hard coded to read to first physical 
> network which may not be the physical network that has guest traffic.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9511) fix test_privategw_acl.py to handle multiple physical networks

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15604139#comment-15604139
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9511:


Github user rhtyd commented on the issue:

https://github.com/apache/cloudstack/pull/1724
  
LGTM on code.


> fix test_privategw_acl.py to handle multiple physical networks
> --
>
> Key: CLOUDSTACK-9511
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9511
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: marvin
>Affects Versions: 4.8.1
> Environment: CentOS 7.2 + VMware 5.5u3 + NFS Primary/Secondary Storage
> CentOS 7.2 + XenServer 6.5 + NFS Primary/Secondary Storage
>Reporter: Murali Reddy
>Assignee: Murali Reddy
>Priority: Critical
>  Labels: 4.8.2.0-smoke-test-failure
> Fix For: 4.10.0.0, 4.9.1.0, 4.8.2.0
>
>
> Smoke test test_privategw_acl.py works only if there is single physical 
> network in the zone. If there are separate physical networks for different 
> traffic, then test will fail, as it is hard coded to read to first physical 
> network which may not be the physical network that has guest traffic.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9511) fix test_privategw_acl.py to handle multiple physical networks

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15604130#comment-15604130
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9511:


Github user murali-reddy commented on the issue:

https://github.com/apache/cloudstack/pull/1724
  
all tests in test_privategw_acl.py passed on KVM & XEN except for 
test_02_vpc_privategw_static_routes test fail in XenServer, which was due to  
private gateway not getting created "createprivategateway failed, due to: 
errorCode: 431, errorText:Network with vlan vlan://842 already exists in zone 
1". A network which may not have cleaned up.

Successfully ran 'test_02_vpc_privategw_static_routes' test manually, there 
no issue with the test.


> fix test_privategw_acl.py to handle multiple physical networks
> --
>
> Key: CLOUDSTACK-9511
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9511
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: marvin
>Affects Versions: 4.8.1
> Environment: CentOS 7.2 + VMware 5.5u3 + NFS Primary/Secondary Storage
> CentOS 7.2 + XenServer 6.5 + NFS Primary/Secondary Storage
>Reporter: Murali Reddy
>Assignee: Murali Reddy
>Priority: Critical
>  Labels: 4.8.2.0-smoke-test-failure
> Fix For: 4.10.0.0, 4.9.1.0, 4.8.2.0
>
>
> Smoke test test_privategw_acl.py works only if there is single physical 
> network in the zone. If there are separate physical networks for different 
> traffic, then test will fail, as it is hard coded to read to first physical 
> network which may not be the physical network that has guest traffic.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9539) Support changing Service offering for instance with VM Snapshots

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15602994#comment-15602994
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9539:


Github user nvazquez commented on a diff in the pull request:

https://github.com/apache/cloudstack/pull/1727#discussion_r84767316
  
--- Diff: setup/db/db/schema-490to4910.sql ---
@@ -50,3 +50,8 @@ INSERT IGNORE INTO `cloud`.`guest_os_hypervisor` 
(uuid,hypervisor_type, hypervis
 -- Ubuntu 16.04 XenServer guest os mapping
 INSERT IGNORE INTO `cloud`.`guest_os_hypervisor` (uuid,hypervisor_type, 
hypervisor_version, guest_os_name, guest_os_id, created, is_user_defined) 
VALUES (UUID(),'Xenserver', '6.5.0', 'Ubuntu Trusty Tahr 14.04', 255, 
utc_timestamp(), 0);
 INSERT IGNORE INTO `cloud`.`guest_os_hypervisor` (uuid,hypervisor_type, 
hypervisor_version, guest_os_name, guest_os_id, created, is_user_defined) 
VALUES (UUID(),'Xenserver', '6.5.0', 'Ubuntu Trusty Tahr 14.04', 256, 
utc_timestamp(), 0);
+
+-- Add service_offering_id column to vm_snapshots table
+ALTER TABLE `cloud`.`vm_snapshots` ADD COLUMN `service_offering_id` 
BIGINT(20) UNSIGNED NOT NULL COMMENT '' AFTER `domain_id`;
+UPDATE vm_snapshots s JOIN vm_instance v ON v.id = s.vm_id SET 
s.service_offering_id = v.service_offering_id;
--- End diff --

Done


> Support changing Service offering for instance with VM Snapshots
> 
>
> Key: CLOUDSTACK-9539
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9539
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Nicolas Vazquez
>Assignee: Nicolas Vazquez
>
> h3. Actual behaviour
> CloudStack doesn't support changing service offering for vm instances which 
> have vm snapshots, they should be removed before changing service offering.
> h3. Goal
> Extend actual behaviour by supporting changing service offering for vms which 
> have vm snapshots. In that case, previously taken snapshots (if reverted) 
> should use previous service offering, future snapshots should use the newest.
> h3. Proposed solution:
> 1. Adding {{service_offering_id}} column on {{vm_snapshots}} table: This way 
> snapshot can be reverted to original state even though service offering can 
> be changed for vm instance.
> NOTE: Existing vm snapshots are populated on update script by {{UPDATE 
> vm_snapshots s JOIN vm_instance v ON v.id = s.vm_id SET s.service_offering_id 
> = v.service_offering_id;}}
> 2. New vm snapshots will use instance vm service offering id as 
> {{service_offering_id}}
> 3. Revert to vm snapshots should use vm snapshot's {{service_offering_id}} 
> value.
> h3. Example use case:
> - Deploy vm using service offering A
> - Take vm snapshot -> snap1 (service offering A)
> - Stop vm
> - Change vm service offering to B
> - Revert to VM snapshot snap 1
> - Start vm
> It is expected that vm has service offering A after last step



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9539) Support changing Service offering for instance with VM Snapshots

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15602980#comment-15602980
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9539:


Github user nvazquez commented on a diff in the pull request:

https://github.com/apache/cloudstack/pull/1727#discussion_r84766346
  
--- Diff: setup/db/db/schema-490to4910.sql ---
@@ -50,3 +50,8 @@ INSERT IGNORE INTO `cloud`.`guest_os_hypervisor` 
(uuid,hypervisor_type, hypervis
 -- Ubuntu 16.04 XenServer guest os mapping
 INSERT IGNORE INTO `cloud`.`guest_os_hypervisor` (uuid,hypervisor_type, 
hypervisor_version, guest_os_name, guest_os_id, created, is_user_defined) 
VALUES (UUID(),'Xenserver', '6.5.0', 'Ubuntu Trusty Tahr 14.04', 255, 
utc_timestamp(), 0);
 INSERT IGNORE INTO `cloud`.`guest_os_hypervisor` (uuid,hypervisor_type, 
hypervisor_version, guest_os_name, guest_os_id, created, is_user_defined) 
VALUES (UUID(),'Xenserver', '6.5.0', 'Ubuntu Trusty Tahr 14.04', 256, 
utc_timestamp(), 0);
+
+-- Add service_offering_id column to vm_snapshots table
+ALTER TABLE `cloud`.`vm_snapshots` ADD COLUMN `service_offering_id` 
BIGINT(20) UNSIGNED NOT NULL COMMENT '' AFTER `domain_id`;
+UPDATE vm_snapshots s JOIN vm_instance v ON v.id = s.vm_id SET 
s.service_offering_id = v.service_offering_id;
--- End diff --

Cool, will change it. Thanks!


> Support changing Service offering for instance with VM Snapshots
> 
>
> Key: CLOUDSTACK-9539
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9539
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Nicolas Vazquez
>Assignee: Nicolas Vazquez
>
> h3. Actual behaviour
> CloudStack doesn't support changing service offering for vm instances which 
> have vm snapshots, they should be removed before changing service offering.
> h3. Goal
> Extend actual behaviour by supporting changing service offering for vms which 
> have vm snapshots. In that case, previously taken snapshots (if reverted) 
> should use previous service offering, future snapshots should use the newest.
> h3. Proposed solution:
> 1. Adding {{service_offering_id}} column on {{vm_snapshots}} table: This way 
> snapshot can be reverted to original state even though service offering can 
> be changed for vm instance.
> NOTE: Existing vm snapshots are populated on update script by {{UPDATE 
> vm_snapshots s JOIN vm_instance v ON v.id = s.vm_id SET s.service_offering_id 
> = v.service_offering_id;}}
> 2. New vm snapshots will use instance vm service offering id as 
> {{service_offering_id}}
> 3. Revert to vm snapshots should use vm snapshot's {{service_offering_id}} 
> value.
> h3. Example use case:
> - Deploy vm using service offering A
> - Take vm snapshot -> snap1 (service offering A)
> - Stop vm
> - Change vm service offering to B
> - Revert to VM snapshot snap 1
> - Start vm
> It is expected that vm has service offering A after last step



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9511) fix test_privategw_acl.py to handle multiple physical networks

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15602961#comment-15602961
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9511:


Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/1724
  
Trillian test result (tid-170)
Environment: xenserver-65sp1 (x2), Advanced Networking with Mgmt server 6
Total time taken: 31761 seconds
Marvin logs: 
https://github.com/blueorangutan/acs-prs/releases/download/trillian/pr1724-t170-xenserver-65sp1.zip
Test completed. 41 look ok, 2 have error(s)


Test | Result | Time (s) | Test File
--- | --- | --- | ---
test_05_rvpc_multi_tiers | `Failure` | 458.90 | test_vpc_redundant.py
test_04_rvpc_network_garbage_collector_nics | `Failure` | 1331.34 | 
test_vpc_redundant.py
test_01_create_redundant_VPC_2tiers_4VMs_4IPs_4PF_ACL | `Failure` | 502.96 
| test_vpc_redundant.py
ContextSuite context=TestVpcSite2SiteVpn>:setup | `Error` | 1704.92 | 
test_vpc_vpn.py
ContextSuite context=TestRVPCSite2SiteVpn>:setup | `Error` | 0.00 | 
test_vpc_vpn.py
test_01_vpc_remote_access_vpn | Success | 156.45 | test_vpc_vpn.py
test_02_VPC_default_routes | Success | 284.75 | test_vpc_router_nics.py
test_01_VPC_nics_after_destroy | Success | 685.62 | test_vpc_router_nics.py
test_03_create_redundant_VPC_1tier_2VMs_2IPs_2PF_ACL_reboot_routers | 
Success | 798.06 | test_vpc_redundant.py
test_02_redundant_VPC_default_routes | Success | 974.49 | 
test_vpc_redundant.py
test_09_delete_detached_volume | Success | 20.66 | test_volumes.py
test_08_resize_volume | Success | 110.83 | test_volumes.py
test_07_resize_fail | Success | 111.00 | test_volumes.py
test_06_download_detached_volume | Success | 25.32 | test_volumes.py
test_05_detach_volume | Success | 100.23 | test_volumes.py
test_04_delete_attached_volume | Success | 15.34 | test_volumes.py
test_03_download_attached_volume | Success | 15.26 | test_volumes.py
test_02_attach_volume | Success | 15.80 | test_volumes.py
test_01_create_volume | Success | 392.77 | test_volumes.py
test_03_delete_vm_snapshots | Success | 280.40 | test_vm_snapshots.py
test_02_revert_vm_snapshots | Success | 181.26 | test_vm_snapshots.py
test_01_create_vm_snapshots | Success | 133.78 | test_vm_snapshots.py
test_deploy_vm_multiple | Success | 293.37 | test_vm_life_cycle.py
test_deploy_vm | Success | 0.02 | test_vm_life_cycle.py
test_advZoneVirtualRouter | Success | 0.01 | test_vm_life_cycle.py
test_10_attachAndDetach_iso | Success | 26.81 | test_vm_life_cycle.py
test_09_expunge_vm | Success | 125.66 | test_vm_life_cycle.py
test_08_migrate_vm | Success | 70.92 | test_vm_life_cycle.py
test_07_restore_vm | Success | 0.09 | test_vm_life_cycle.py
test_06_destroy_vm | Success | 10.12 | test_vm_life_cycle.py
test_03_reboot_vm | Success | 10.15 | test_vm_life_cycle.py
test_02_start_vm | Success | 15.16 | test_vm_life_cycle.py
test_01_stop_vm | Success | 30.24 | test_vm_life_cycle.py
test_CreateTemplateWithDuplicateName | Success | 120.82 | test_templates.py
test_08_list_system_templates | Success | 0.02 | test_templates.py
test_07_list_public_templates | Success | 0.02 | test_templates.py
test_05_template_permissions | Success | 0.04 | test_templates.py
test_04_extract_template | Success | 5.13 | test_templates.py
test_03_delete_template | Success | 5.26 | test_templates.py
test_02_edit_template | Success | 90.37 | test_templates.py
test_01_create_template | Success | 65.54 | test_templates.py
test_10_destroy_cpvm | Success | 191.51 | test_ssvm.py
test_09_destroy_ssvm | Success | 199.09 | test_ssvm.py
test_08_reboot_cpvm | Success | 111.28 | test_ssvm.py
test_07_reboot_ssvm | Success | 144.67 | test_ssvm.py
test_06_stop_cpvm | Success | 131.46 | test_ssvm.py
test_05_stop_ssvm | Success | 168.81 | test_ssvm.py
test_04_cpvm_internals | Success | 1.12 | test_ssvm.py
test_03_ssvm_internals | Success | 3.33 | test_ssvm.py
test_02_list_cpvm_vm | Success | 0.08 | test_ssvm.py
test_01_list_sec_storage_vm | Success | 0.07 | test_ssvm.py
test_01_snapshot_root_disk | Success | 21.23 | test_snapshots.py
test_04_change_offering_small | Success | 70.81 | test_service_offerings.py
test_03_delete_service_offering | Success | 0.03 | test_service_offerings.py
test_02_edit_service_offering | Success | 0.07 | test_service_offerings.py
test_01_create_service_offering | Success | 0.06 | test_service_offerings.py
test_02_sys_template_ready | Success | 0.07 | test_secondary_storage.py
test_01_sys_vm_start | Success | 0.10 | test_secondary_storage.py
test_01_scale_vm | Success | 5.17 | test_scale_vm.py
test_09_reboot_router | Success | 50.35 | test_routers.py
test_08_start_router | 

[jira] [Commented] (CLOUDSTACK-9511) fix test_privategw_acl.py to handle multiple physical networks

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15602930#comment-15602930
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9511:


Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/1724
  
Trillian test result (tid-172)
Environment: vmware-55u3 (x2), Advanced Networking with Mgmt server 7
Total time taken: 30908 seconds
Marvin logs: 
https://github.com/blueorangutan/acs-prs/releases/download/trillian/pr1724-t172-vmware-55u3.zip
Test completed. 40 look ok, 3 have error(s)


Test | Result | Time (s) | Test File
--- | --- | --- | ---
test_02_vpc_privategw_static_routes | `Failure` | 310.65 | 
test_privategw_acl.py
test_01_vpc_site2site_vpn | `Error` | 452.41 | test_vpc_vpn.py
test_01_redundant_vpc_site2site_vpn | `Error` | 674.81 | test_vpc_vpn.py
test_06_download_detached_volume | `Error` | 35.46 | test_volumes.py
test_01_vpc_remote_access_vpn | Success | 182.43 | test_vpc_vpn.py
test_02_VPC_default_routes | Success | 354.07 | test_vpc_router_nics.py
test_01_VPC_nics_after_destroy | Success | 656.92 | test_vpc_router_nics.py
test_05_rvpc_multi_tiers | Success | 527.81 | test_vpc_redundant.py
test_04_rvpc_network_garbage_collector_nics | Success | 1516.08 | 
test_vpc_redundant.py
test_03_create_redundant_VPC_1tier_2VMs_2IPs_2PF_ACL_reboot_routers | 
Success | 593.22 | test_vpc_redundant.py
test_02_redundant_VPC_default_routes | Success | 536.69 | 
test_vpc_redundant.py
test_01_create_redundant_VPC_2tiers_4VMs_4IPs_4PF_ACL | Success | 1156.02 | 
test_vpc_redundant.py
test_09_delete_detached_volume | Success | 31.13 | test_volumes.py
test_05_detach_volume | Success | 100.33 | test_volumes.py
test_04_delete_attached_volume | Success | 20.49 | test_volumes.py
test_03_download_attached_volume | Success | 20.46 | test_volumes.py
test_02_attach_volume | Success | 58.90 | test_volumes.py
test_01_create_volume | Success | 520.02 | test_volumes.py
test_03_delete_vm_snapshots | Success | 275.30 | test_vm_snapshots.py
test_02_revert_vm_snapshots | Success | 199.33 | test_vm_snapshots.py
test_01_test_vm_volume_snapshot | Success | 126.47 | test_vm_snapshots.py
test_01_create_vm_snapshots | Success | 162.16 | test_vm_snapshots.py
test_deploy_vm_multiple | Success | 259.43 | test_vm_life_cycle.py
test_deploy_vm | Success | 0.04 | test_vm_life_cycle.py
test_advZoneVirtualRouter | Success | 0.03 | test_vm_life_cycle.py
test_10_attachAndDetach_iso | Success | 27.17 | test_vm_life_cycle.py
test_09_expunge_vm | Success | 125.19 | test_vm_life_cycle.py
test_08_migrate_vm | Success | 66.44 | test_vm_life_cycle.py
test_07_restore_vm | Success | 0.10 | test_vm_life_cycle.py
test_06_destroy_vm | Success | 10.14 | test_vm_life_cycle.py
test_03_reboot_vm | Success | 5.22 | test_vm_life_cycle.py
test_02_start_vm | Success | 15.21 | test_vm_life_cycle.py
test_01_stop_vm | Success | 10.17 | test_vm_life_cycle.py
test_CreateTemplateWithDuplicateName | Success | 287.82 | test_templates.py
test_08_list_system_templates | Success | 0.03 | test_templates.py
test_07_list_public_templates | Success | 0.03 | test_templates.py
test_05_template_permissions | Success | 0.05 | test_templates.py
test_04_extract_template | Success | 16.66 | test_templates.py
test_03_delete_template | Success | 5.11 | test_templates.py
test_02_edit_template | Success | 90.19 | test_templates.py
test_01_create_template | Success | 182.11 | test_templates.py
test_10_destroy_cpvm | Success | 268.13 | test_ssvm.py
test_09_destroy_ssvm | Success | 235.00 | test_ssvm.py
test_08_reboot_cpvm | Success | 157.76 | test_ssvm.py
test_07_reboot_ssvm | Success | 158.88 | test_ssvm.py
test_06_stop_cpvm | Success | 172.01 | test_ssvm.py
test_05_stop_ssvm | Success | 199.09 | test_ssvm.py
test_04_cpvm_internals | Success | 1.22 | test_ssvm.py
test_03_ssvm_internals | Success | 3.53 | test_ssvm.py
test_02_list_cpvm_vm | Success | 0.12 | test_ssvm.py
test_01_list_sec_storage_vm | Success | 0.13 | test_ssvm.py
test_01_snapshot_root_disk | Success | 26.35 | test_snapshots.py
test_04_change_offering_small | Success | 92.33 | test_service_offerings.py
test_03_delete_service_offering | Success | 0.04 | test_service_offerings.py
test_02_edit_service_offering | Success | 0.08 | test_service_offerings.py
test_01_create_service_offering | Success | 0.11 | test_service_offerings.py
test_02_sys_template_ready | Success | 0.16 | test_secondary_storage.py
test_01_sys_vm_start | Success | 0.16 | test_secondary_storage.py
test_09_reboot_router | Success | 121.05 | test_routers.py
test_08_start_router | Success | 100.96 | test_routers.py
test_07_stop_router | 

[jira] [Commented] (CLOUDSTACK-9539) Support changing Service offering for instance with VM Snapshots

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15602878#comment-15602878
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9539:


Github user ustcweizhou commented on a diff in the pull request:

https://github.com/apache/cloudstack/pull/1727#discussion_r84757955
  
--- Diff: setup/db/db/schema-490to4910.sql ---
@@ -50,3 +50,8 @@ INSERT IGNORE INTO `cloud`.`guest_os_hypervisor` 
(uuid,hypervisor_type, hypervis
 -- Ubuntu 16.04 XenServer guest os mapping
 INSERT IGNORE INTO `cloud`.`guest_os_hypervisor` (uuid,hypervisor_type, 
hypervisor_version, guest_os_name, guest_os_id, created, is_user_defined) 
VALUES (UUID(),'Xenserver', '6.5.0', 'Ubuntu Trusty Tahr 14.04', 255, 
utc_timestamp(), 0);
 INSERT IGNORE INTO `cloud`.`guest_os_hypervisor` (uuid,hypervisor_type, 
hypervisor_version, guest_os_name, guest_os_id, created, is_user_defined) 
VALUES (UUID(),'Xenserver', '6.5.0', 'Ubuntu Trusty Tahr 14.04', 256, 
utc_timestamp(), 0);
+
+-- Add service_offering_id column to vm_snapshots table
+ALTER TABLE `cloud`.`vm_snapshots` ADD COLUMN `service_offering_id` 
BIGINT(20) UNSIGNED NOT NULL COMMENT '' AFTER `domain_id`;
+UPDATE vm_snapshots s JOIN vm_instance v ON v.id = s.vm_id SET 
s.service_offering_id = v.service_offering_id;
--- End diff --

it is better to use 
UPDATE `cloud`.`vm_snapshots` s JOIN `cloud`.`vm_instance` v ON v.id = 
s.vm_id SET s.service_offering_id = v.service_offering_id;


> Support changing Service offering for instance with VM Snapshots
> 
>
> Key: CLOUDSTACK-9539
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9539
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Nicolas Vazquez
>Assignee: Nicolas Vazquez
>
> h3. Actual behaviour
> CloudStack doesn't support changing service offering for vm instances which 
> have vm snapshots, they should be removed before changing service offering.
> h3. Goal
> Extend actual behaviour by supporting changing service offering for vms which 
> have vm snapshots. In that case, previously taken snapshots (if reverted) 
> should use previous service offering, future snapshots should use the newest.
> h3. Proposed solution:
> 1. Adding {{service_offering_id}} column on {{vm_snapshots}} table: This way 
> snapshot can be reverted to original state even though service offering can 
> be changed for vm instance.
> NOTE: Existing vm snapshots are populated on update script by {{UPDATE 
> vm_snapshots s JOIN vm_instance v ON v.id = s.vm_id SET s.service_offering_id 
> = v.service_offering_id;}}
> 2. New vm snapshots will use instance vm service offering id as 
> {{service_offering_id}}
> 3. Revert to vm snapshots should use vm snapshot's {{service_offering_id}} 
> value.
> h3. Example use case:
> - Deploy vm using service offering A
> - Take vm snapshot -> snap1 (service offering A)
> - Stop vm
> - Change vm service offering to B
> - Revert to VM snapshot snap 1
> - Start vm
> It is expected that vm has service offering A after last step



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9511) fix test_privategw_acl.py to handle multiple physical networks

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15602695#comment-15602695
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9511:


Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/1724
  
Trillian test result (tid-171)
Environment: kvm-centos7 (x2), Advanced Networking with Mgmt server 7
Total time taken: 25364 seconds
Marvin logs: 
https://github.com/blueorangutan/acs-prs/releases/download/trillian/pr1724-t171-kvm-centos7.zip
Test completed. 43 look ok, 0 have error(s)


Test | Result | Time (s) | Test File
--- | --- | --- | ---
test_01_vpc_site2site_vpn | Success | 165.84 | test_vpc_vpn.py
test_01_vpc_remote_access_vpn | Success | 71.39 | test_vpc_vpn.py
test_01_redundant_vpc_site2site_vpn | Success | 256.81 | test_vpc_vpn.py
test_02_VPC_default_routes | Success | 271.21 | test_vpc_router_nics.py
test_01_VPC_nics_after_destroy | Success | 570.91 | test_vpc_router_nics.py
test_05_rvpc_multi_tiers | Success | 527.25 | test_vpc_redundant.py
test_04_rvpc_network_garbage_collector_nics | Success | 1469.06 | 
test_vpc_redundant.py
test_03_create_redundant_VPC_1tier_2VMs_2IPs_2PF_ACL_reboot_routers | 
Success | 625.37 | test_vpc_redundant.py
test_02_redundant_VPC_default_routes | Success | 776.65 | 
test_vpc_redundant.py
test_01_create_redundant_VPC_2tiers_4VMs_4IPs_4PF_ACL | Success | 1340.93 | 
test_vpc_redundant.py
test_09_delete_detached_volume | Success | 15.77 | test_volumes.py
test_08_resize_volume | Success | 15.46 | test_volumes.py
test_07_resize_fail | Success | 20.55 | test_volumes.py
test_06_download_detached_volume | Success | 15.40 | test_volumes.py
test_05_detach_volume | Success | 100.26 | test_volumes.py
test_04_delete_attached_volume | Success | 10.31 | test_volumes.py
test_03_download_attached_volume | Success | 15.36 | test_volumes.py
test_02_attach_volume | Success | 73.94 | test_volumes.py
test_01_create_volume | Success | 723.64 | test_volumes.py
test_deploy_vm_multiple | Success | 289.99 | test_vm_life_cycle.py
test_deploy_vm | Success | 0.03 | test_vm_life_cycle.py
test_advZoneVirtualRouter | Success | 0.02 | test_vm_life_cycle.py
test_10_attachAndDetach_iso | Success | 26.93 | test_vm_life_cycle.py
test_09_expunge_vm | Success | 125.22 | test_vm_life_cycle.py
test_08_migrate_vm | Success | 41.16 | test_vm_life_cycle.py
test_07_restore_vm | Success | 0.18 | test_vm_life_cycle.py
test_06_destroy_vm | Success | 125.83 | test_vm_life_cycle.py
test_03_reboot_vm | Success | 126.06 | test_vm_life_cycle.py
test_02_start_vm | Success | 10.30 | test_vm_life_cycle.py
test_01_stop_vm | Success | 40.41 | test_vm_life_cycle.py
test_CreateTemplateWithDuplicateName | Success | 65.91 | test_templates.py
test_08_list_system_templates | Success | 0.03 | test_templates.py
test_07_list_public_templates | Success | 0.03 | test_templates.py
test_05_template_permissions | Success | 0.05 | test_templates.py
test_04_extract_template | Success | 5.27 | test_templates.py
test_03_delete_template | Success | 5.13 | test_templates.py
test_02_edit_template | Success | 90.14 | test_templates.py
test_01_create_template | Success | 60.71 | test_templates.py
test_10_destroy_cpvm | Success | 166.69 | test_ssvm.py
test_09_destroy_ssvm | Success | 133.56 | test_ssvm.py
test_08_reboot_cpvm | Success | 101.55 | test_ssvm.py
test_07_reboot_ssvm | Success | 133.67 | test_ssvm.py
test_06_stop_cpvm | Success | 131.75 | test_ssvm.py
test_05_stop_ssvm | Success | 133.88 | test_ssvm.py
test_04_cpvm_internals | Success | 1.26 | test_ssvm.py
test_03_ssvm_internals | Success | 3.50 | test_ssvm.py
test_02_list_cpvm_vm | Success | 0.21 | test_ssvm.py
test_01_list_sec_storage_vm | Success | 0.19 | test_ssvm.py
test_01_snapshot_root_disk | Success | 11.31 | test_snapshots.py
test_04_change_offering_small | Success | 209.98 | test_service_offerings.py
test_03_delete_service_offering | Success | 0.03 | test_service_offerings.py
test_02_edit_service_offering | Success | 0.05 | test_service_offerings.py
test_01_create_service_offering | Success | 0.11 | test_service_offerings.py
test_02_sys_template_ready | Success | 0.14 | test_secondary_storage.py
test_01_sys_vm_start | Success | 0.17 | test_secondary_storage.py
test_09_reboot_router | Success | 35.40 | test_routers.py
test_08_start_router | Success | 30.38 | test_routers.py
test_07_stop_router | Success | 10.16 | test_routers.py
test_06_router_advanced | Success | 0.07 | test_routers.py
test_05_router_basic | Success | 0.04 | test_routers.py
test_04_restart_network_wo_cleanup | Success | 5.91 | test_routers.py
test_03_restart_network_cleanup | 

[jira] [Commented] (CLOUDSTACK-8830) [VMware] VM snapshot fails for 12 min after instance creation

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8830?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15602500#comment-15602500
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8830:


Github user nvazquez commented on the issue:

https://github.com/apache/cloudstack/pull/1677
  
@jburwell @rhtyd we have rebased 4.9 branch, will start running tests


> [VMware] VM snapshot fails for 12 min after instance creation
> -
>
> Key: CLOUDSTACK-8830
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8830
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Maneesha
>Assignee: Maneesha
>
> ISSUE
> 
> [VMware] VM snapshot fails for 12 min after instance creation
> Environment
> ==
> Product Name: Cloudstack
> Hypervisor: VMWare VSphere 6
> VM DETAILS
> ==
> i-84987-16119-VM
> TROUBLESHOOTING
> ==
> I see that the following failure and immediate success result for the 
> CreateVMSnapshot call
> {noformat}
> 2015-07-24 08:20:55,363 DEBUG [c.c.a.t.Request] 
> (Work-Job-Executor-61:ctx-03fad7f2 job-64835/job-64836 ctx-746f3965) 
> (logid:8b87ab8a) Seq 80-6161487240196259878: Sending  { Cmd , MgmtId: 
> 345051581208, via: 80(ussfoldcsesx112.adslab.local), Ver: v1, Flags: 100011, 
> [{"com.cloud.agent.api.CreateVMSnapshotCommand":{"volumeTOs":[{"uuid":"a89b4ad5-f23f-4df6-84a8-89c4f40b2edb","volumeType":"ROOT","volumeState":"Ready","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"346b381a-8543-3f7b-9eff-fa909ad243c7","id":205,"poolType":"NetworkFilesystem","host":"10.144.35.110","path":"/tintri/ECS-SR-CLD200","port":2049,"url":"NetworkFilesystem://10.144.35.110/tintri/ECS-SR-CLD200/?ROLE=Primary=346b381a-8543-3f7b-9eff-fa909ad243c7"}},"name":"ROOT-16119","size":1073741824,"path":"ROOT-16119","volumeId":19311,"vmName":"i-84987-16119-VM","vmState":"Running","accountId":84987,"chainInfo":"{\"diskDeviceBusName\":\"ide0:1\",\"diskChain\":[\"[346b381a85433f7b9efffa909ad243c7]
>  i-84987-16119-VM/ROOT-16119.vmdk\",\"[346b381a85433f7b9efffa909ad243c7] 
> 49f59e1a4ce23fec8890c8b9e5891d56/49f59e1a4ce23fec8890c8b9e5891d56.vmdk\"]}","format":"OVA","provisioningType":"THIN","id":19311,"deviceId":0,"cacheMode":"NONE","hypervisorType":"VMware"}],"target":{"id":962,"snapshotName":"i-84987-16119-VM_VS_20150724152053","type":"Disk","current":false,"description":"unit-test-instance-snapshot","quiescevm":false},"vmName":"i-84987-16119-VM","guestOSType":"None","wait":1800}}]
>  }
> 2015-07-24 08:20:55,373 DEBUG [c.c.a.t.Request] 
> (Work-Job-Executor-61:ctx-03fad7f2 job-64835/job-64836 ctx-746f3965) 
> (logid:8b87ab8a) Seq 80-6161487240196259878: Executing:  { Cmd , MgmtId: 
> 345051581208, via: 80(ussfoldcsesx112.adslab.local), Ver: v1, Flags: 100011, 
> [{"com.cloud.agent.api.CreateVMSnapshotCommand":{"volumeTOs":[{"uuid":"a89b4ad5-f23f-4df6-84a8-89c4f40b2edb","volumeType":"ROOT","volumeState":"Ready","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"346b381a-8543-3f7b-9eff-fa909ad243c7","id":205,"poolType":"NetworkFilesystem","host":"10.144.35.110","path":"/tintri/ECS-SR-CLD200","port":2049,"url":"NetworkFilesystem://10.144.35.110/tintri/ECS-SR-CLD200/?ROLE=Primary=346b381a-8543-3f7b-9eff-fa909ad243c7"}},"name":"ROOT-16119","size":1073741824,"path":"ROOT-16119","volumeId":19311,"vmName":"i-84987-16119-VM","vmState":"Running","accountId":84987,"chainInfo":"{\"diskDeviceBusName\":\"ide0:1\",\"diskChain\":[\"[346b381a85433f7b9efffa909ad243c7]
>  i-84987-16119-VM/ROOT-16119.vmdk\",\"[346b381a85433f7b9efffa909ad243c7] 
> 49f59e1a4ce23fec8890c8b9e5891d56/49f59e1a4ce23fec8890c8b9e5891d56.vmdk\"]}","format":"OVA","provisioningType":"THIN","id":19311,"deviceId":0,"cacheMode":"NONE","hypervisorType":"VMware"}],"target":{"id":962,"snapshotName":"i-84987-16119-VM_VS_20150724152053","type":"Disk","current":false,"description":"unit-test-instance-snapshot","quiescevm":false},"vmName":"i-84987-16119-VM","guestOSType":"None","wait":1800}}]
>  }
> 2015-07-24 08:20:55,374 DEBUG [c.c.a.m.DirectAgentAttache] 
> (DirectAgent-66:ctx-5fbdccd8) (logid:710814a5) Seq 80-6161487240196259878: 
> Executing request
> 2015-07-24 08:20:55,523 ERROR [c.c.h.v.m.VmwareStorageManagerImpl] 
> (DirectAgent-66:ctx-5fbdccd8 ussfoldcsesx112.adslab.local, 
> job-64835/job-64836, cmd: CreateVMSnapshotCommand) (logid:8b87ab8a) failed to 
> create snapshot for vm:i-84987-16119-VM due to null
> 2015-07-24 08:20:55,524 DEBUG [c.c.a.m.DirectAgentAttache] 
> (DirectAgent-66:ctx-5fbdccd8) (logid:8b87ab8a) Seq 80-6161487240196259878: 
> Response Received: 
> 2015-07-24 08:20:55,525 DEBUG [c.c.a.t.Request] (DirectAgent-66:ctx-5fbdccd8) 
> (logid:8b87ab8a) Seq 80-6161487240196259878: 

[jira] [Commented] (CLOUDSTACK-9560) Root volume of deleted VM left unremoved

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15602450#comment-15602450
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9560:


Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/1726
  
@rhtyd a Trillian-Jenkins test job (centos7 mgmt + kvm-centos7) has been 
kicked to run smoke tests


> Root volume of deleted VM left unremoved
> 
>
> Key: CLOUDSTACK-9560
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9560
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Volumes
>Affects Versions: 4.8.0
> Environment: XenServer
>Reporter: subhash yedugundla
> Fix For: 4.8.1
>
>
> In the following scenario root volume gets unremoved
> Steps to reproduce the issue
> 1. Create a VM.
> 2. Stop this VM.
> 3. On the page of the volume of the VM, click 'Download Volume' icon.
> 4. Wait for the popup screen to display and cancel out with/without clicking 
> the download link.
> 5. Destroy the VM
> Even after the corresponding VM is deleted,expunged, the root-volume is left 
> in 'Expunging' state unremoved.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9560) Root volume of deleted VM left unremoved

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15602448#comment-15602448
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9560:


Github user rhtyd commented on the issue:

https://github.com/apache/cloudstack/pull/1726
  
@blueorangutan test


> Root volume of deleted VM left unremoved
> 
>
> Key: CLOUDSTACK-9560
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9560
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Volumes
>Affects Versions: 4.8.0
> Environment: XenServer
>Reporter: subhash yedugundla
> Fix For: 4.8.1
>
>
> In the following scenario root volume gets unremoved
> Steps to reproduce the issue
> 1. Create a VM.
> 2. Stop this VM.
> 3. On the page of the volume of the VM, click 'Download Volume' icon.
> 4. Wait for the popup screen to display and cancel out with/without clicking 
> the download link.
> 5. Destroy the VM
> Even after the corresponding VM is deleted,expunged, the root-volume is left 
> in 'Expunging' state unremoved.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9560) Root volume of deleted VM left unremoved

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15602444#comment-15602444
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9560:


Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/1726
  
Packaging result: ✔centos6 ✔centos7 ✔debian. JID-91


> Root volume of deleted VM left unremoved
> 
>
> Key: CLOUDSTACK-9560
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9560
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Volumes
>Affects Versions: 4.8.0
> Environment: XenServer
>Reporter: subhash yedugundla
> Fix For: 4.8.1
>
>
> In the following scenario root volume gets unremoved
> Steps to reproduce the issue
> 1. Create a VM.
> 2. Stop this VM.
> 3. On the page of the volume of the VM, click 'Download Volume' icon.
> 4. Wait for the popup screen to display and cancel out with/without clicking 
> the download link.
> 5. Destroy the VM
> Even after the corresponding VM is deleted,expunged, the root-volume is left 
> in 'Expunging' state unremoved.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9539) Support changing Service offering for instance with VM Snapshots

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15602424#comment-15602424
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9539:


GitHub user nvazquez opened a pull request:

https://github.com/apache/cloudstack/pull/1727

CLOUDSTACK-9539: Support changing Service offering for instance with VM 
Snapshots

## Actual behaviour
CloudStack doesn't support changing service offering for vm instances which 
have vm snapshots, they should be removed before changing service offering.

## Goal
Extend actual behaviour by supporting changing service offering for vms 
which have vm snapshots. In that case, previously taken snapshots (if reverted) 
should use previous service offering, future snapshots should use the newest.

## Proposed solution:

1. Adding `service_offering_id` column on `vm_snapshots` table: This way 
snapshot can be reverted to original state even though service offering can be 
changed for vm instance.
NOTE: Existing vm snapshots are populated on update script by:
`UPDATE vm_snapshots s JOIN vm_instance v ON v.id = s.vm_id SET 
s.service_offering_id = v.service_offering_id;`

2. New vm snapshots will use instance vm service offering id as 
`service_offering_id`

3. Revert to vm snapshots should use vm snapshot's `service_offering_id` 
value.

## Example use case:
- Deploy vm using service offering A
- Take vm snapshot -> snap1 (service offering A)
- Stop vm
- Change vm service offering to B
- Revert to VM snapshot snap 1
- Start vm

It is expected that vm has service offering A after last step

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/nvazquez/cloudstack change-serv-offering

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/cloudstack/pull/1727.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 #1727


commit c7d51461250d5585a61cf8d12bf28a8380125d0a
Author: nvazquez 
Date:   2016-10-14T15:23:38Z

CLOUDSTACK-9539: Support changing Service offering for instance with VM 
Snapshots




> Support changing Service offering for instance with VM Snapshots
> 
>
> Key: CLOUDSTACK-9539
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9539
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Nicolas Vazquez
>Assignee: Nicolas Vazquez
>
> h3. Actual behaviour
> CloudStack doesn't support changing service offering for vm instances which 
> have vm snapshots, they should be removed before changing service offering.
> h3. Goal
> Extend actual behaviour by supporting changing service offering for vms which 
> have vm snapshots. In that case, previously taken snapshots (if reverted) 
> should use previous service offering, future snapshots should use the newest.
> h3. Proposed solution:
> 1. Adding {{service_offering_id}} column on {{vm_snapshots}} table: This way 
> snapshot can be reverted to original state even though service offering can 
> be changed for vm instance.
> NOTE: Existing vm snapshots are populated on update script by {{UPDATE 
> vm_snapshots s JOIN vm_instance v ON v.id = s.vm_id SET s.service_offering_id 
> = v.service_offering_id;}}
> 2. New vm snapshots will use instance vm service offering id as 
> {{service_offering_id}}
> 3. Revert to vm snapshots should use vm snapshot's {{service_offering_id}} 
> value.
> h3. Example use case:
> - Deploy vm using service offering A
> - Take vm snapshot -> snap1 (service offering A)
> - Stop vm
> - Change vm service offering to B
> - Revert to VM snapshot snap 1
> - Start vm
> It is expected that vm has service offering A after last step



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CLOUDSTACK-6669) Support volume resize in usage server

[Felipe Rossi (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Felipe Rossi updated CLOUDSTACK-6669:
-
Attachment: screenshot-3.png

> Support volume resize in usage server
> -
>
> Key: CLOUDSTACK-6669
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6669
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Kishan Kavala
>Assignee: Rajani Karuturi
>Priority: Critical
> Fix For: 4.4.0
>
> Attachments: image002.png, image003.png, image004.png, 
> screenshot-1.png, screenshot-2.png, screenshot-3.png
>
>
> volume resize events are generated in usgae_events tables.
> Support to process them and update the usage records has to be added to usage 
> server



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-6669) Support volume resize in usage server

[Felipe Rossi (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15602371#comment-15602371
 ] 

Felipe Rossi commented on CLOUDSTACK-6669:
--

Hi Olivier,

I atached screenshots.

regards

> Support volume resize in usage server
> -
>
> Key: CLOUDSTACK-6669
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6669
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Kishan Kavala
>Assignee: Rajani Karuturi
>Priority: Critical
> Fix For: 4.4.0
>
> Attachments: image002.png, image003.png, image004.png, 
> screenshot-1.png, screenshot-2.png, screenshot-3.png
>
>
> volume resize events are generated in usgae_events tables.
> Support to process them and update the usage records has to be added to usage 
> server



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9560) Root volume of deleted VM left unremoved

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15602346#comment-15602346
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9560:


Github user rhtyd commented on the issue:

https://github.com/apache/cloudstack/pull/1726
  
@blueorangutan package


> Root volume of deleted VM left unremoved
> 
>
> Key: CLOUDSTACK-9560
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9560
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Volumes
>Affects Versions: 4.8.0
> Environment: XenServer
>Reporter: subhash yedugundla
> Fix For: 4.8.1
>
>
> In the following scenario root volume gets unremoved
> Steps to reproduce the issue
> 1. Create a VM.
> 2. Stop this VM.
> 3. On the page of the volume of the VM, click 'Download Volume' icon.
> 4. Wait for the popup screen to display and cancel out with/without clicking 
> the download link.
> 5. Destroy the VM
> Even after the corresponding VM is deleted,expunged, the root-volume is left 
> in 'Expunging' state unremoved.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CLOUDSTACK-9539) Support changing Service offering for instance with VM Snapshots

[Nicolas Vazquez (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Nicolas Vazquez updated CLOUDSTACK-9539:

Description: 
h3. Actual behaviour
CloudStack doesn't support changing service offering for vm instances which 
have vm snapshots, they should be removed before changing service offering.

h3. Goal
Extend actual behaviour by supporting changing service offering for vms which 
have vm snapshots. In that case, previously taken snapshots (if reverted) 
should use previous service offering, future snapshots should use the newest.

h3. Proposed solution:

1. Adding {{service_offering_id}} column on {{vm_snapshots}} table: This way 
snapshot can be reverted to original state even though service offering can be 
changed for vm instance.
NOTE: Existing vm snapshots are populated on update script by {{UPDATE 
vm_snapshots s JOIN vm_instance v ON v.id = s.vm_id SET s.service_offering_id = 
v.service_offering_id;}}

2. New vm snapshots will use instance vm service offering id as 
{{service_offering_id}}

3. Revert to vm snapshots should use vm snapshot's {{service_offering_id}} 
value.

h3. Example use case:
- Deploy vm using service offering A
- Take vm snapshot -> snap1 (service offering A)
- Stop vm
- Change vm service offering to B
- Revert to VM snapshot snap 1
- Start vm

It is expected that vm has service offering A after last step

  was:
h3. Actual behaviour
CloudStack doesn't support changing service offering for vm instances which 
have vm snapshots, they should be removed before changing service offering.

h3. Goal
Extend actual behaviour by supporting changing service offering for vms which 
have vm snapshots. In that case, previously taken snapshots (if reverted) 
should use previous service offering, future snapshots should use the newest.

h3. Proposed solution:

1. Adding {{service_offering_id}} column on {{vm_snapshots}} table: This way 
snapshot can be reverted to original state even though service offering can be 
changed for vm instance.
NOTE: Existing vm snapshots are populated on update script by {{UPDATE 
vm_snapshots s JOIN vm_instance v ON v.id = s.vm_id SET s.service_offering_id = 
v.service_offering_id;}}

2. New vm snapshots will use instance vm service offering id as 
{{service_offering_id}}

3. Revert to vm snapshots should use vm snapshot's {{service_offering_id}} 
value.

h3. Example use case:
- Deploy vm using service offering A
- Take vm snapshot -> snap1 (service offering A)
- Stop vm
- Change vm service offering to B
- Revert to VM snapshot snap 1
- Start vm

It is expected that vm has service offering A after last step


* VM Instance V created with service offering A
* Take vm snapshot of V -> snap1 (service offering A)
* Change V service offering to B
* Revert to vm snapshot snap 1
It is expected that V has service offering A after last step


> Support changing Service offering for instance with VM Snapshots
> 
>
> Key: CLOUDSTACK-9539
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9539
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Nicolas Vazquez
>Assignee: Nicolas Vazquez
>
> h3. Actual behaviour
> CloudStack doesn't support changing service offering for vm instances which 
> have vm snapshots, they should be removed before changing service offering.
> h3. Goal
> Extend actual behaviour by supporting changing service offering for vms which 
> have vm snapshots. In that case, previously taken snapshots (if reverted) 
> should use previous service offering, future snapshots should use the newest.
> h3. Proposed solution:
> 1. Adding {{service_offering_id}} column on {{vm_snapshots}} table: This way 
> snapshot can be reverted to original state even though service offering can 
> be changed for vm instance.
> NOTE: Existing vm snapshots are populated on update script by {{UPDATE 
> vm_snapshots s JOIN vm_instance v ON v.id = s.vm_id SET s.service_offering_id 
> = v.service_offering_id;}}
> 2. New vm snapshots will use instance vm service offering id as 
> {{service_offering_id}}
> 3. Revert to vm snapshots should use vm snapshot's {{service_offering_id}} 
> value.
> h3. Example use case:
> - Deploy vm using service offering A
> - Take vm snapshot -> snap1 (service offering A)
> - Stop vm
> - Change vm service offering to B
> - Revert to VM snapshot snap 1
> - Start vm
> It is expected that vm has service offering A after last step



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CLOUDSTACK-6669) Support volume resize in usage server

[Felipe Rossi (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Felipe Rossi updated CLOUDSTACK-6669:
-
Attachment: screenshot-1.png

> Support volume resize in usage server
> -
>
> Key: CLOUDSTACK-6669
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6669
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Kishan Kavala
>Assignee: Rajani Karuturi
>Priority: Critical
> Fix For: 4.4.0
>
> Attachments: image002.png, image003.png, image004.png, 
> screenshot-1.png, screenshot-2.png
>
>
> volume resize events are generated in usgae_events tables.
> Support to process them and update the usage records has to be added to usage 
> server



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CLOUDSTACK-6669) Support volume resize in usage server

[Felipe Rossi (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Felipe Rossi updated CLOUDSTACK-6669:
-
Attachment: screenshot-2.png

> Support volume resize in usage server
> -
>
> Key: CLOUDSTACK-6669
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6669
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Kishan Kavala
>Assignee: Rajani Karuturi
>Priority: Critical
> Fix For: 4.4.0
>
> Attachments: image002.png, image003.png, image004.png, 
> screenshot-1.png, screenshot-2.png, screenshot-3.png
>
>
> volume resize events are generated in usgae_events tables.
> Support to process them and update the usage records has to be added to usage 
> server



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CLOUDSTACK-9539) Support changing Service offering for instance with VM Snapshots

[Nicolas Vazquez (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Nicolas Vazquez updated CLOUDSTACK-9539:

Description: 
h3. Actual behaviour
CloudStack doesn't support changing service offering for vm instances which 
have vm snapshots, they should be removed before changing service offering.

h3. Goal
Extend actual behaviour by supporting changing service offering for vms which 
have vm snapshots. In that case, previously taken snapshots (if reverted) 
should use previous service offering, future snapshots should use the newest.

h3. Proposed solution:

1. Adding {{service_offering_id}} column on {{vm_snapshots}} table: This way 
snapshot can be reverted to original state even though service offering can be 
changed for vm instance.
NOTE: Existing vm snapshots are populated on update script by {{UPDATE 
vm_snapshots s JOIN vm_instance v ON v.id = s.vm_id SET s.service_offering_id = 
v.service_offering_id;}}

2. New vm snapshots will use instance vm service offering id as 
{{service_offering_id}}

3. Revert to vm snapshots should use vm snapshot's {{service_offering_id}} 
value.

h3. Example use case:
- Deploy vm using service offering A
- Take vm snapshot -> snap1 (service offering A)
- Stop vm
- Change vm service offering to B
- Revert to VM snapshot snap 1
- Start vm

It is expected that vm has service offering A after last step


* VM Instance V created with service offering A
* Take vm snapshot of V -> snap1 (service offering A)
* Change V service offering to B
* Revert to vm snapshot snap 1
It is expected that V has service offering A after last step

  was:
h3. Actual behaviour
CloudStack doesn't support changing service offering for vm instances which 
have vm snapshots, they should be removed before changing service offering.

h3. Goal
Extend actual behaviour by supporting changing service offering for vms which 
have vm snapshots. In that case, previously taken snapshots (if reverted) 
should use previous service offering, future snapshots should use the newest.

h3. Proposed solution:

1. Adding {{service_offering_id}} column on {{vm_snapshots}} table: This way 
snapshot can be reverted to original state even though service offering can be 
changed for vm instance.
NOTE: Existing vm snapshots are populated on update script by {{UPDATE 
vm_snapshots s JOIN vm_instance v ON v.id = s.vm_id SET s.service_offering_id = 
v.service_offering_id;}}

2. New vm snapshots will use instance vm service offering id as 
{{service_offering_id}}

3. Revert to vm snapshots should use vm snapshot's {{service_offering_id}} 
value.

h3. Example use case:
* VM Instance V created with service offering A
* Take vm snapshot of V -> snap1 (service offering A)
* Change V service offering to B
* Revert to vm snapshot snap 1
It is expected that V has service offering A after last step


> Support changing Service offering for instance with VM Snapshots
> 
>
> Key: CLOUDSTACK-9539
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9539
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Nicolas Vazquez
>Assignee: Nicolas Vazquez
>
> h3. Actual behaviour
> CloudStack doesn't support changing service offering for vm instances which 
> have vm snapshots, they should be removed before changing service offering.
> h3. Goal
> Extend actual behaviour by supporting changing service offering for vms which 
> have vm snapshots. In that case, previously taken snapshots (if reverted) 
> should use previous service offering, future snapshots should use the newest.
> h3. Proposed solution:
> 1. Adding {{service_offering_id}} column on {{vm_snapshots}} table: This way 
> snapshot can be reverted to original state even though service offering can 
> be changed for vm instance.
> NOTE: Existing vm snapshots are populated on update script by {{UPDATE 
> vm_snapshots s JOIN vm_instance v ON v.id = s.vm_id SET s.service_offering_id 
> = v.service_offering_id;}}
> 2. New vm snapshots will use instance vm service offering id as 
> {{service_offering_id}}
> 3. Revert to vm snapshots should use vm snapshot's {{service_offering_id}} 
> value.
> h3. Example use case:
> - Deploy vm using service offering A
> - Take vm snapshot -> snap1 (service offering A)
> - Stop vm
> - Change vm service offering to B
> - Revert to VM snapshot snap 1
> - Start vm
> It is expected that vm has service offering A after last step
> * VM Instance V created with service offering A
> * Take vm snapshot of V -> snap1 (service offering A)
> * Change V service offering to B
> * Revert to vm snapshot snap 1
> It is expected that V has service offering A after last step



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CLOUDSTACK-6669) Support volume resize in usage server

[Felipe Rossi (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Felipe Rossi updated CLOUDSTACK-6669:
-
Attachment: (was: screenshot-1.png)

> Support volume resize in usage server
> -
>
> Key: CLOUDSTACK-6669
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6669
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Kishan Kavala
>Assignee: Rajani Karuturi
>Priority: Critical
> Fix For: 4.4.0
>
> Attachments: image002.png, image003.png, image004.png
>
>
> volume resize events are generated in usgae_events tables.
> Support to process them and update the usage records has to be added to usage 
> server



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CLOUDSTACK-6669) Support volume resize in usage server

[Felipe Rossi (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Felipe Rossi updated CLOUDSTACK-6669:
-
Attachment: screenshot-1.png

> Support volume resize in usage server
> -
>
> Key: CLOUDSTACK-6669
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6669
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Kishan Kavala
>Assignee: Rajani Karuturi
>Priority: Critical
> Fix For: 4.4.0
>
> Attachments: image002.png, image003.png, image004.png
>
>
> volume resize events are generated in usgae_events tables.
> Support to process them and update the usage records has to be added to usage 
> server



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9504) Fully support system VMs on managed storage

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15602365#comment-15602365
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9504:


Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/1642
  
@rhtyd a Trillian-Jenkins test job (centos7 mgmt + kvm-centos7) has been 
kicked to run smoke tests


> Fully support system VMs on managed storage
> ---
>
> Key: CLOUDSTACK-9504
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9504
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.10.0.0
> Environment: All
>Reporter: Mike Tutkowski
>Assignee: Mike Tutkowski
> Fix For: 4.10.0.0
>
>
> There are three related items for this ticket:
> 1) Do not permit "custom IOPS" as a parameter when creating a system offering 
> (throw an exception if this parameter is passed in).
> 2) If you transition managed storage into maintenance mode and system VMs 
> were running on that managed storage, the host-side clustered file systems 
> (SRs on XenServer) are not removed. Remove them.
> 3) Add integration tests for system VMs with managed storage.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9504) Fully support system VMs on managed storage

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15602364#comment-15602364
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9504:


Github user rhtyd commented on the issue:

https://github.com/apache/cloudstack/pull/1642
  
@blueorangutan test


> Fully support system VMs on managed storage
> ---
>
> Key: CLOUDSTACK-9504
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9504
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.10.0.0
> Environment: All
>Reporter: Mike Tutkowski
>Assignee: Mike Tutkowski
> Fix For: 4.10.0.0
>
>
> There are three related items for this ticket:
> 1) Do not permit "custom IOPS" as a parameter when creating a system offering 
> (throw an exception if this parameter is passed in).
> 2) If you transition managed storage into maintenance mode and system VMs 
> were running on that managed storage, the host-side clustered file systems 
> (SRs on XenServer) are not removed. Remove them.
> 3) Add integration tests for system VMs with managed storage.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9339) Virtual Routers don't handle Multiple Public Interfaces

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15602352#comment-15602352
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9339:


Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/1659
  
Trillian test result (tid-168)
Environment: kvm-centos7 (x2), Advanced Networking with Mgmt server 7
Total time taken: 24863 seconds
Marvin logs: 
https://github.com/blueorangutan/acs-prs/releases/download/trillian/pr1659-t168-kvm-centos7.zip
Test completed. 45 look ok, 3 have error(s)


Test | Result | Time (s) | Test File
--- | --- | --- | ---
test_04_rvpc_privategw_static_routes | `Failure` | 315.31 | 
test_privategw_acl.py
test_03_vpc_privategw_restart_vpc_cleanup | `Failure` | 244.68 | 
test_privategw_acl.py
test_02_vpc_privategw_static_routes | `Failure` | 270.08 | 
test_privategw_acl.py
test_oobm_zchange_password | `Failure` | 20.53 | test_outofbandmanagement.py
test_04_rvpc_internallb_haproxy_stats_on_all_interfaces | `Failure` | 
307.72 | test_internal_lb.py
test_03_vpc_internallb_haproxy_stats_on_all_interfaces | `Failure` | 242.73 
| test_internal_lb.py
test_02_internallb_roundrobin_1RVPC_3VM_HTTP_port80 | `Failure` | 371.02 | 
test_internal_lb.py
test_01_internallb_roundrobin_1VPC_3VM_HTTP_port80 | `Failure` | 376.01 | 
test_internal_lb.py
test_01_nic | `Error` | 454.93 | test_nic.py
test_01_vpc_site2site_vpn | Success | 149.86 | test_vpc_vpn.py
test_01_vpc_remote_access_vpn | Success | 61.08 | test_vpc_vpn.py
test_01_redundant_vpc_site2site_vpn | Success | 220.38 | test_vpc_vpn.py
test_02_VPC_default_routes | Success | 254.69 | test_vpc_router_nics.py
test_01_VPC_nics_after_destroy | Success | 533.96 | test_vpc_router_nics.py
test_05_rvpc_multi_tiers | Success | 502.20 | test_vpc_redundant.py
test_04_rvpc_network_garbage_collector_nics | Success | 1331.50 | 
test_vpc_redundant.py
test_03_create_redundant_VPC_1tier_2VMs_2IPs_2PF_ACL_reboot_routers | 
Success | 543.34 | test_vpc_redundant.py
test_02_redundant_VPC_default_routes | Success | 750.21 | 
test_vpc_redundant.py
test_01_create_redundant_VPC_2tiers_4VMs_4IPs_4PF_ACL | Success | 1261.03 | 
test_vpc_redundant.py
test_09_delete_detached_volume | Success | 15.67 | test_volumes.py
test_08_resize_volume | Success | 15.40 | test_volumes.py
test_07_resize_fail | Success | 20.48 | test_volumes.py
test_06_download_detached_volume | Success | 15.28 | test_volumes.py
test_05_detach_volume | Success | 100.25 | test_volumes.py
test_04_delete_attached_volume | Success | 10.19 | test_volumes.py
test_03_download_attached_volume | Success | 15.28 | test_volumes.py
test_02_attach_volume | Success | 43.72 | test_volumes.py
test_01_create_volume | Success | 621.05 | test_volumes.py
test_deploy_vm_multiple | Success | 258.59 | test_vm_life_cycle.py
test_deploy_vm | Success | 0.03 | test_vm_life_cycle.py
test_advZoneVirtualRouter | Success | 0.02 | test_vm_life_cycle.py
test_10_attachAndDetach_iso | Success | 26.61 | test_vm_life_cycle.py
test_09_expunge_vm | Success | 125.20 | test_vm_life_cycle.py
test_08_migrate_vm | Success | 36.58 | test_vm_life_cycle.py
test_07_restore_vm | Success | 0.13 | test_vm_life_cycle.py
test_06_destroy_vm | Success | 130.87 | test_vm_life_cycle.py
test_03_reboot_vm | Success | 125.88 | test_vm_life_cycle.py
test_02_start_vm | Success | 5.15 | test_vm_life_cycle.py
test_01_stop_vm | Success | 35.32 | test_vm_life_cycle.py
test_CreateTemplateWithDuplicateName | Success | 85.75 | test_templates.py
test_08_list_system_templates | Success | 0.03 | test_templates.py
test_07_list_public_templates | Success | 0.04 | test_templates.py
test_05_template_permissions | Success | 0.06 | test_templates.py
test_04_extract_template | Success | 5.15 | test_templates.py
test_03_delete_template | Success | 5.11 | test_templates.py
test_02_edit_template | Success | 90.13 | test_templates.py
test_01_create_template | Success | 35.43 | test_templates.py
test_10_destroy_cpvm | Success | 161.49 | test_ssvm.py
test_09_destroy_ssvm | Success | 134.28 | test_ssvm.py
test_08_reboot_cpvm | Success | 101.42 | test_ssvm.py
test_07_reboot_ssvm | Success | 103.31 | test_ssvm.py
test_06_stop_cpvm | Success | 131.59 | test_ssvm.py
test_05_stop_ssvm | Success | 133.39 | test_ssvm.py
test_04_cpvm_internals | Success | 1.03 | test_ssvm.py
test_03_ssvm_internals | Success | 2.96 | test_ssvm.py
test_02_list_cpvm_vm | Success | 0.12 | test_ssvm.py
test_01_list_sec_storage_vm | Success | 0.15 | test_ssvm.py
test_01_snapshot_root_disk | Success | 16.39 | test_snapshots.py
test_04_change_offering_small | Success | 209.57 | test_service_offerings.py

[jira] [Commented] (CLOUDSTACK-9560) Root volume of deleted VM left unremoved

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15602347#comment-15602347
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9560:


Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/1726
  
@rhtyd a Jenkins job has been kicked to build packages. I'll keep you 
posted as I make progress.


> Root volume of deleted VM left unremoved
> 
>
> Key: CLOUDSTACK-9560
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9560
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Volumes
>Affects Versions: 4.8.0
> Environment: XenServer
>Reporter: subhash yedugundla
> Fix For: 4.8.1
>
>
> In the following scenario root volume gets unremoved
> Steps to reproduce the issue
> 1. Create a VM.
> 2. Stop this VM.
> 3. On the page of the volume of the VM, click 'Download Volume' icon.
> 4. Wait for the popup screen to display and cancel out with/without clicking 
> the download link.
> 5. Destroy the VM
> Even after the corresponding VM is deleted,expunged, the root-volume is left 
> in 'Expunging' state unremoved.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-4858) Disable copy snapshot to secondary storage snapshot.backup.rightafter

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-4858?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15602313#comment-15602313
 ] 

ASF GitHub Bot commented on CLOUDSTACK-4858:


Github user syed commented on a diff in the pull request:

https://github.com/apache/cloudstack/pull/1697#discussion_r84712741
  
--- Diff: 
engine/storage/snapshot/src/org/apache/cloudstack/storage/snapshot/XenserverSnapshotStrategy.java
 ---
@@ -374,8 +375,24 @@ public SnapshotInfo takeSnapshot(SnapshotInfo 
snapshot) {
 
 snapshot = result.getSnashot();
 DataStore primaryStore = snapshot.getDataStore();
+boolean backupFlag = 
Boolean.parseBoolean(configDao.getValue(Config.BackupSnapshotAfterTakingSnapshot.toString()));
--- End diff --

@nathanejohnson in #1600 I've added a flag to the create snapshot API 
called `locationType` which can take `primary` or `secondary` as the parameter. 
We could use that here as well. Although for this PR, a global would suffice


> Disable copy snapshot to secondary storage snapshot.backup.rightafter
> -
>
> Key: CLOUDSTACK-4858
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4858
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: API
>Affects Versions: 4.2.0
> Environment: kvm, rbd
>Reporter: Sebastian Igerl
>
> "snapshot.backup.rightafterbackup"  is set to false but still the snapshot is 
> copied to secondary storage.
> Primary storage is Ceph/RDB, Secondary is NFS. I restarted both the 
> management server and the nodes.
> see : 
> http://www.marshut.com/wpviz/disable-copy-snapshot-to-secondary-storage-in-cs-4-2.html



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9560) Root volume of deleted VM left unremoved

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15602287#comment-15602287
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9560:


Github user syed commented on the issue:

https://github.com/apache/cloudstack/pull/1726
  
LGTM :+1: 


> Root volume of deleted VM left unremoved
> 
>
> Key: CLOUDSTACK-9560
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9560
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Volumes
>Affects Versions: 4.8.0
> Environment: XenServer
>Reporter: subhash yedugundla
> Fix For: 4.8.1
>
>
> In the following scenario root volume gets unremoved
> Steps to reproduce the issue
> 1. Create a VM.
> 2. Stop this VM.
> 3. On the page of the volume of the VM, click 'Download Volume' icon.
> 4. Wait for the popup screen to display and cancel out with/without clicking 
> the download link.
> 5. Destroy the VM
> Even after the corresponding VM is deleted,expunged, the root-volume is left 
> in 'Expunging' state unremoved.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-6669) Support volume resize in usage server

[Olivier Lemasle (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15602175#comment-15602175
 ] 

Olivier Lemasle commented on CLOUDSTACK-6669:
-

Hi Felipe,

In your screenshots, you didn't show the corresponding values in 
{{cloud_usage}}. Could you please add it to the ticket?

Thanks,

--
Olivier Lemasle
http://www.apalia.net/en/

> Support volume resize in usage server
> -
>
> Key: CLOUDSTACK-6669
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6669
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Kishan Kavala
>Assignee: Rajani Karuturi
>Priority: Critical
> Fix For: 4.4.0
>
> Attachments: image002.png, image003.png, image004.png
>
>
> volume resize events are generated in usgae_events tables.
> Support to process them and update the usage records has to be added to usage 
> server



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9319) Timeout is not passed to virtual router operations consistently

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15602128#comment-15602128
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9319:


Github user cloudmonger commented on the issue:

https://github.com/apache/cloudstack/pull/1451
  
### ACS CI BVT Run
 **Sumarry:**
 Build Number 120
 Hypervisor xenserver
 NetworkType Advanced
 Passed=100
 Failed=2
 Skipped=5

_Link to logs Folder (search by build_no):_ 
https://www.dropbox.com/sh/yj3wnzbceo9uef2/AAB6u-Iap-xztdm6jHX9SjPja?dl=0


**Failed tests:**
* test_deploy_vm_iso.py

 * test_deploy_vm_from_iso Failing since 5 runs

* test_vm_life_cycle.py

 * test_10_attachAndDetach_iso Failing since 6 runs


**Skipped tests:**
test_01_test_vm_volume_snapshot
test_vm_nic_adapter_vmxnet3
test_static_role_account_acls
test_3d_gpu_support
test_deploy_vgpu_enabled_vm

**Passed test suits:**
test_deploy_vm_with_userdata.py
test_affinity_groups_projects.py
test_portable_publicip.py
test_over_provisioning.py
test_global_settings.py
test_scale_vm.py
test_service_offerings.py
test_routers_iptables_default_policy.py
test_loadbalance.py
test_routers.py
test_reset_vm_on_reboot.py
test_snapshots.py
test_deploy_vms_with_varied_deploymentplanners.py
test_network.py
test_router_dns.py
test_non_contigiousvlan.py
test_login.py
test_list_ids_parameter.py
test_public_ip_range.py
test_multipleips_per_nic.py
test_regions.py
test_affinity_groups.py
test_network_acl.py
test_pvlan.py
test_volumes.py
test_ssvm.py
test_nic.py
test_deploy_vm_root_resize.py
test_resource_detail.py
test_secondary_storage.py
test_routers_network_ops.py
test_disk_offerings.py


> Timeout is not passed to virtual router operations consistently
> ---
>
> Key: CLOUDSTACK-9319
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9319
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Virtual Router
>Affects Versions: 4.8.0
> Environment: KVM + Ceph cloud, Ubuntu hosts.
>Reporter: Aaron Brady
>Priority: Trivial
>
> The timeout parameter is not passed down to `applyConfigToVR` inside 
> `VirtualRoutingResource` in all cases.
> This timeout is worked out as 3 seconds per command or 120 seconds (whichever 
> is larger), but because it's not passed to the first invocation, the default 
> (120 seconds, DEFAULT_EXECUTEINVR_TIMEOUT) is used.
> In a recent upgrade of our Virtual Routers, the timeout was being hit and 
> increasing `router.aggregation.command.each.timeout` had no effect. I built a 
> custom 4.8 agent with the timeout increased to allow the upgrade to continue.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9504) Fully support system VMs on managed storage

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15601984#comment-15601984
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9504:


Github user mike-tutkowski commented on the issue:

https://github.com/apache/cloudstack/pull/1642
  
Any way to easily just re-run test_05_stop_ssvm and test_07_reboot_ssvm?

I'm not sure how this PR would cause such failures. The only changed Java 
code does the following:

* Validates IOPS parameters in a certain situation when creating a new 
System Offering. (should not apply here)

* For managed storage, when the storage-cleanup thread runs, attempts to 
remove the remaining SR. If this fails, the exception is logged and processing 
continues as usual. (should not apply here)


> Fully support system VMs on managed storage
> ---
>
> Key: CLOUDSTACK-9504
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9504
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.10.0.0
> Environment: All
>Reporter: Mike Tutkowski
>Assignee: Mike Tutkowski
> Fix For: 4.10.0.0
>
>
> There are three related items for this ticket:
> 1) Do not permit "custom IOPS" as a parameter when creating a system offering 
> (throw an exception if this parameter is passed in).
> 2) If you transition managed storage into maintenance mode and system VMs 
> were running on that managed storage, the host-side clustered file systems 
> (SRs on XenServer) are not removed. Remove them.
> 3) Add integration tests for system VMs with managed storage.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9560) Root volume of deleted VM left unremoved

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15601855#comment-15601855
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9560:


GitHub user yvsubhash opened a pull request:

https://github.com/apache/cloudstack/pull/1726

CLOUDSTACK-9560 Root volume of deleted VM left unremoved



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/yvsubhash/cloudstack CLOUDSTACK-9560

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/cloudstack/pull/1726.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 #1726


commit a4e8cc20db18e04ec8cce4a90676b5ef632debe9
Author: subhash yedugundla 
Date:   2016-05-31T11:45:04Z

CLOUDSTACK-9560 Root volume of deleted VM left unremoved




> Root volume of deleted VM left unremoved
> 
>
> Key: CLOUDSTACK-9560
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9560
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Volumes
>Affects Versions: 4.8.0
> Environment: XenServer
>Reporter: subhash yedugundla
> Fix For: 4.8.1
>
>
> In the following scenario root volume gets unremoved
> Steps to reproduce the issue
> 1. Create a VM.
> 2. Stop this VM.
> 3. On the page of the volume of the VM, click 'Download Volume' icon.
> 4. Wait for the popup screen to display and cancel out with/without clicking 
> the download link.
> 5. Destroy the VM
> Even after the corresponding VM is deleted,expunged, the root-volume is left 
> in 'Expunging' state unremoved.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9560) Root volume of deleted VM left unremoved

[subhash yedugundla (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15601842#comment-15601842
 ] 

subhash yedugundla commented on CLOUDSTACK-9560:


When a download is attempted a symbolic link would be created in SSVM and 
mapping would be placed in volume_store_ref table. The link would expire after 
the global setting 'extract.url.expiration.interval' which defaults to 4 hours 
and the expired links are cleaned up after the extract.url.cleanup.interval 
after expiry which defaults to 2 hours. The deletion of volume would be 
restricted if there is an entry for the volume in volume_store_ref table. After 
the expiry, the cleanup thread clears the entries in the volume_store_ref 
table, not the entries in the volumes table.  If the vm destroy is attempted 
after cleanup is done from volume_store_ref table, then the volumes would be 
cleanup. However, If the vm is destroyed before the expiry, then this issue 
occurs. So adding volume cleanup during cleanup of expired entries.

> Root volume of deleted VM left unremoved
> 
>
> Key: CLOUDSTACK-9560
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9560
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Volumes
>Affects Versions: 4.8.0
> Environment: XenServer
>Reporter: subhash yedugundla
> Fix For: 4.8.1
>
>
> In the following scenario root volume gets unremoved
> Steps to reproduce the issue
> 1. Create a VM.
> 2. Stop this VM.
> 3. On the page of the volume of the VM, click 'Download Volume' icon.
> 4. Wait for the popup screen to display and cancel out with/without clicking 
> the download link.
> 5. Destroy the VM
> Even after the corresponding VM is deleted,expunged, the root-volume is left 
> in 'Expunging' state unremoved.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9560) Root volume of deleted VM left unremoved

[Wei Zhou (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15601825#comment-15601825
 ] 

Wei Zhou commented on CLOUDSTACK-9560:
--

this is because a snapshot of the volume is still in secondary storage (see 
volume_store_ref table)
The snapshot will be cleaned by Storage manager.
Once it is done, the volume should be removed from database as well.



> Root volume of deleted VM left unremoved
> 
>
> Key: CLOUDSTACK-9560
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9560
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Volumes
>Affects Versions: 4.8.0
> Environment: XenServer
>Reporter: subhash yedugundla
> Fix For: 4.8.1
>
>
> In the following scenario root volume gets unremoved
> Steps to reproduce the issue
> 1. Create a VM.
> 2. Stop this VM.
> 3. On the page of the volume of the VM, click 'Download Volume' icon.
> 4. Wait for the popup screen to display and cancel out with/without clicking 
> the download link.
> 5. Destroy the VM
> Even after the corresponding VM is deleted,expunged, the root-volume is left 
> in 'Expunging' state unremoved.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (CLOUDSTACK-9560) Root volume of deleted VM left unremoved

[subhash yedugundla (JIRA)]

subhash yedugundla created CLOUDSTACK-9560:
--

 Summary: Root volume of deleted VM left unremoved
 Key: CLOUDSTACK-9560
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9560
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Volumes
Affects Versions: 4.8.0
 Environment: XenServer
Reporter: subhash yedugundla
 Fix For: 4.8.1


In the following scenario root volume gets unremoved
Steps to reproduce the issue
1. Create a VM.
2. Stop this VM.
3. On the page of the volume of the VM, click 'Download Volume' icon.
4. Wait for the popup screen to display and cancel out with/without clicking 
the download link.
5. Destroy the VM
Even after the corresponding VM is deleted,expunged, the root-volume is left in 
'Expunging' state unremoved.




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9438) Fix for CLOUDSTACK-9252 - Make NFS version changeable in UI

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15601622#comment-15601622
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9438:


Github user cloudmonger commented on the issue:

https://github.com/apache/cloudstack/pull/1615
  
### ACS CI BVT Run
 **Sumarry:**
 Build Number 117
 Hypervisor xenserver
 NetworkType Advanced
 Passed=18
 Failed=3
 Skipped=2

_Link to logs Folder (search by build_no):_ 
https://www.dropbox.com/sh/yj3wnzbceo9uef2/AAB6u-Iap-xztdm6jHX9SjPja?dl=0


**Failed tests:**
* test_service_offerings.py

 * ContextSuite context=TestServiceOfferings>:setup Failing since 16 runs

* test_vm_life_cycle.py

 * test_10_attachAndDetach_iso Failing since 5 runs

 * ContextSuite context=TestVMLifeCycle>:teardown Failed


**Skipped tests:**
test_vm_nic_adapter_vmxnet3
test_static_role_account_acls

**Passed test suits:**
test_over_provisioning.py
test_deploy_vms_with_varied_deploymentplanners.py
test_router_dns.py
test_resource_detail.py


> Fix for CLOUDSTACK-9252 - Make NFS version changeable in UI
> ---
>
> Key: CLOUDSTACK-9438
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9438
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Nicolas Vazquez
>Assignee: Nicolas Vazquez
>
> h3. Introduction
> From [9252|https://issues.apache.org/jira/browse/CLOUDSTACK-9252] it was 
> possible to configure NFS version for secondary storage mount. 
> However, changing NFS version requires inserting an new detail on 
> {{image_store_details}} table, with {{name = 'nfs.version'}} and {{value = 
> X}} where X is desired NFS version, and then restarting management server for 
> changes to take effect.
> Our improvement aims to make NFS version changeable from UI, instead of 
> previously described workflow.
> h3. Proposed solution
> Basically, NFS version is defined as an image store ConfigKey, this implied:
> * Adding a new Config scope: *ImageStore*
> * Make {{ImageStoreDetailsDao}} class to extend {{ResourceDetailsDaoBase}} 
> and {{ImageStoreDetailVO}} implement {{ResourceDetail}}
> * Insert {{'display'}} column on {{image_store_details}} table
> * Extending {{ListCfgsCmd}} and {{UpdateCfgCmd}} to support *ImageStore* 
> scope, which implied:
> ** Injecting {{ImageStoreDetailsDao}} and {{ImageStoreDao}} on 
> {{ConfigurationManagerImpl}} class, on {{cloud-server}} module.
> h4. Important
> It is important to mention that {{ImageStoreDaoImpl}} and 
> {{ImageStoreDetailsDaoImpl}} classes were moved from {{cloud-engine-storage}} 
> to {{cloud-engine-schema}} module in order to Spring find those beans to 
> inject on {{ConfigurationManagerImpl}} in {{cloud-server}} module.
> We had this maven dependencies between modules:
> * {{cloud-server --> cloud-engine-schema}}
> * {{cloud-engine-storage --> cloud-secondary-storage --> cloud-server}}
> As {{ImageStoreDaoImpl}} and {{ImageStoreDetailsDaoImpl}} were defined in 
> {{cloud-engine-storage}}, and they needed in {{cloud-server}} module, to be 
> injected on {{ConfigurationManagerImpl}}, if we added dependency from 
> {{cloud-server}} to {{cloud-engine-storage}} we would introduce a dependency 
> cycle. To avoid this cycle, we moved those classes to {{cloud-engine-schema}} 
> module



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9511) fix test_privategw_acl.py to handle multiple physical networks

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15601604#comment-15601604
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9511:


Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/1724
  
@rhtyd a Trillian-Jenkins matrix job (centos6 mgmt + xs65sp1, centos7 mgmt 
+ vmware55u3, centos7 mgmt + kvmcentos7) has been kicked to run smoke tests


> fix test_privategw_acl.py to handle multiple physical networks
> --
>
> Key: CLOUDSTACK-9511
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9511
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: marvin
>Affects Versions: 4.8.1
> Environment: CentOS 7.2 + VMware 5.5u3 + NFS Primary/Secondary Storage
> CentOS 7.2 + XenServer 6.5 + NFS Primary/Secondary Storage
>Reporter: Murali Reddy
>Assignee: Murali Reddy
>Priority: Critical
>  Labels: 4.8.2.0-smoke-test-failure
> Fix For: 4.10.0.0, 4.9.1.0, 4.8.2.0
>
>
> Smoke test test_privategw_acl.py works only if there is single physical 
> network in the zone. If there are separate physical networks for different 
> traffic, then test will fail, as it is hard coded to read to first physical 
> network which may not be the physical network that has guest traffic.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9511) fix test_privategw_acl.py to handle multiple physical networks

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15601601#comment-15601601
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9511:


Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/1724
  
Packaging result: ✔centos6 ✔centos7 ✔debian. JID-90


> fix test_privategw_acl.py to handle multiple physical networks
> --
>
> Key: CLOUDSTACK-9511
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9511
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: marvin
>Affects Versions: 4.8.1
> Environment: CentOS 7.2 + VMware 5.5u3 + NFS Primary/Secondary Storage
> CentOS 7.2 + XenServer 6.5 + NFS Primary/Secondary Storage
>Reporter: Murali Reddy
>Assignee: Murali Reddy
>Priority: Critical
>  Labels: 4.8.2.0-smoke-test-failure
> Fix For: 4.10.0.0, 4.9.1.0, 4.8.2.0
>
>
> Smoke test test_privategw_acl.py works only if there is single physical 
> network in the zone. If there are separate physical networks for different 
> traffic, then test will fail, as it is hard coded to read to first physical 
> network which may not be the physical network that has guest traffic.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9511) fix test_privategw_acl.py to handle multiple physical networks

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15601603#comment-15601603
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9511:


Github user rhtyd commented on the issue:

https://github.com/apache/cloudstack/pull/1724
  
@blueorangutan test matrix


> fix test_privategw_acl.py to handle multiple physical networks
> --
>
> Key: CLOUDSTACK-9511
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9511
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: marvin
>Affects Versions: 4.8.1
> Environment: CentOS 7.2 + VMware 5.5u3 + NFS Primary/Secondary Storage
> CentOS 7.2 + XenServer 6.5 + NFS Primary/Secondary Storage
>Reporter: Murali Reddy
>Assignee: Murali Reddy
>Priority: Critical
>  Labels: 4.8.2.0-smoke-test-failure
> Fix For: 4.10.0.0, 4.9.1.0, 4.8.2.0
>
>
> Smoke test test_privategw_acl.py works only if there is single physical 
> network in the zone. If there are separate physical networks for different 
> traffic, then test will fail, as it is hard coded to read to first physical 
> network which may not be the physical network that has guest traffic.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9559) Deleting zone without deleting the secondary storage under the zone should not be allowed

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15601591#comment-15601591
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9559:


GitHub user yvsubhash opened a pull request:

https://github.com/apache/cloudstack/pull/1725

CLOUDSTACK-9559  Why allow deleting zone without deleting the seconda…

CLOUDSTACK-9559  allow deleting zone without deleting the secondary storage 
under the zone

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/yvsubhash/cloudstack CLOUDSTACK-9559

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/cloudstack/pull/1725.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 #1725


commit ad797c85ea30c9af470f180829469ba714b73ff1
Author: subhash_y 
Date:   2016-10-04T11:57:43Z

CLOUDSTACK-9559  Why allow deleting zone without deleting the secondary 
storage under the zone




> Deleting zone without deleting the secondary storage under the zone should 
> not be allowed
> -
>
> Key: CLOUDSTACK-9559
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9559
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Secondary Storage
>Affects Versions: 4.8.0
> Environment: All Hypervisors
>Reporter: subhash yedugundla
> Fix For: 4.8.1
>
>
> When a zone is deleted, with out deleting the corresponding secondary 
> storage. If there are templates or volumes in secondary storage, it wont be 
> possible to delete them from ACS



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9511) fix test_privategw_acl.py to handle multiple physical networks

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15601532#comment-15601532
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9511:


Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/1724
  
@rhtyd a Jenkins job has been kicked to build packages. I'll keep you 
posted as I make progress.


> fix test_privategw_acl.py to handle multiple physical networks
> --
>
> Key: CLOUDSTACK-9511
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9511
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: marvin
>Affects Versions: 4.8.1
> Environment: CentOS 7.2 + VMware 5.5u3 + NFS Primary/Secondary Storage
> CentOS 7.2 + XenServer 6.5 + NFS Primary/Secondary Storage
>Reporter: Murali Reddy
>Assignee: Murali Reddy
>Priority: Critical
>  Labels: 4.8.2.0-smoke-test-failure
> Fix For: 4.10.0.0, 4.9.1.0, 4.8.2.0
>
>
> Smoke test test_privategw_acl.py works only if there is single physical 
> network in the zone. If there are separate physical networks for different 
> traffic, then test will fail, as it is hard coded to read to first physical 
> network which may not be the physical network that has guest traffic.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9511) fix test_privategw_acl.py to handle multiple physical networks

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15601530#comment-15601530
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9511:


Github user rhtyd commented on the issue:

https://github.com/apache/cloudstack/pull/1724
  
@blueorangutan package


> fix test_privategw_acl.py to handle multiple physical networks
> --
>
> Key: CLOUDSTACK-9511
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9511
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: marvin
>Affects Versions: 4.8.1
> Environment: CentOS 7.2 + VMware 5.5u3 + NFS Primary/Secondary Storage
> CentOS 7.2 + XenServer 6.5 + NFS Primary/Secondary Storage
>Reporter: Murali Reddy
>Assignee: Murali Reddy
>Priority: Critical
>  Labels: 4.8.2.0-smoke-test-failure
> Fix For: 4.10.0.0, 4.9.1.0, 4.8.2.0
>
>
> Smoke test test_privategw_acl.py works only if there is single physical 
> network in the zone. If there are separate physical networks for different 
> traffic, then test will fail, as it is hard coded to read to first physical 
> network which may not be the physical network that has guest traffic.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9511) fix test_privategw_acl.py to handle multiple physical networks

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15601484#comment-15601484
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9511:


GitHub user murali-reddy opened a pull request:

https://github.com/apache/cloudstack/pull/1724

CLOUDSTACK-9511: fix test_privategw_acl.py to handle multiple physical 
network


fix to ensure only physical network with guest traffic is picked up for
creating a private network for vpc private gateway

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/murali-reddy/cloudstack test_privategw_acl

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/cloudstack/pull/1724.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 #1724


commit 5728ad03caf0580970f2c8226cae4440e12f4d92
Author: Murali Reddy 
Date:   2016-10-24T09:45:35Z

CLOUDSTACK-9511: fix test_privategw_acl.py to handle multiple physical 
network

fix to ensure only physical network with guest traffic is picked up for
creating a private network for vpc private gateway




> fix test_privategw_acl.py to handle multiple physical networks
> --
>
> Key: CLOUDSTACK-9511
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9511
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: marvin
>Affects Versions: 4.8.1
> Environment: CentOS 7.2 + VMware 5.5u3 + NFS Primary/Secondary Storage
> CentOS 7.2 + XenServer 6.5 + NFS Primary/Secondary Storage
>Reporter: Murali Reddy
>Assignee: Murali Reddy
>Priority: Critical
>  Labels: 4.8.2.0-smoke-test-failure
> Fix For: 4.10.0.0, 4.9.1.0, 4.8.2.0
>
>
> Smoke test test_privategw_acl.py works only if there is single physical 
> network in the zone. If there are separate physical networks for different 
> traffic, then test will fail, as it is hard coded to read to first physical 
> network which may not be the physical network that has guest traffic.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9438) Fix for CLOUDSTACK-9252 - Make NFS version changeable in UI

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15601449#comment-15601449
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9438:


Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/1615
  
@karuturi a Trillian-Jenkins test job (centos7 mgmt + vmware-60u2) has been 
kicked to run smoke tests


> Fix for CLOUDSTACK-9252 - Make NFS version changeable in UI
> ---
>
> Key: CLOUDSTACK-9438
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9438
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Nicolas Vazquez
>Assignee: Nicolas Vazquez
>
> h3. Introduction
> From [9252|https://issues.apache.org/jira/browse/CLOUDSTACK-9252] it was 
> possible to configure NFS version for secondary storage mount. 
> However, changing NFS version requires inserting an new detail on 
> {{image_store_details}} table, with {{name = 'nfs.version'}} and {{value = 
> X}} where X is desired NFS version, and then restarting management server for 
> changes to take effect.
> Our improvement aims to make NFS version changeable from UI, instead of 
> previously described workflow.
> h3. Proposed solution
> Basically, NFS version is defined as an image store ConfigKey, this implied:
> * Adding a new Config scope: *ImageStore*
> * Make {{ImageStoreDetailsDao}} class to extend {{ResourceDetailsDaoBase}} 
> and {{ImageStoreDetailVO}} implement {{ResourceDetail}}
> * Insert {{'display'}} column on {{image_store_details}} table
> * Extending {{ListCfgsCmd}} and {{UpdateCfgCmd}} to support *ImageStore* 
> scope, which implied:
> ** Injecting {{ImageStoreDetailsDao}} and {{ImageStoreDao}} on 
> {{ConfigurationManagerImpl}} class, on {{cloud-server}} module.
> h4. Important
> It is important to mention that {{ImageStoreDaoImpl}} and 
> {{ImageStoreDetailsDaoImpl}} classes were moved from {{cloud-engine-storage}} 
> to {{cloud-engine-schema}} module in order to Spring find those beans to 
> inject on {{ConfigurationManagerImpl}} in {{cloud-server}} module.
> We had this maven dependencies between modules:
> * {{cloud-server --> cloud-engine-schema}}
> * {{cloud-engine-storage --> cloud-secondary-storage --> cloud-server}}
> As {{ImageStoreDaoImpl}} and {{ImageStoreDetailsDaoImpl}} were defined in 
> {{cloud-engine-storage}}, and they needed in {{cloud-server}} module, to be 
> injected on {{ConfigurationManagerImpl}}, if we added dependency from 
> {{cloud-server}} to {{cloud-engine-storage}} we would introduce a dependency 
> cycle. To avoid this cycle, we moved those classes to {{cloud-engine-schema}} 
> module



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9438) Fix for CLOUDSTACK-9252 - Make NFS version changeable in UI

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15601446#comment-15601446
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9438:


Github user karuturi commented on the issue:

https://github.com/apache/cloudstack/pull/1615
  
@blueorangutan test centos7 vmware-60u2


> Fix for CLOUDSTACK-9252 - Make NFS version changeable in UI
> ---
>
> Key: CLOUDSTACK-9438
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9438
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Nicolas Vazquez
>Assignee: Nicolas Vazquez
>
> h3. Introduction
> From [9252|https://issues.apache.org/jira/browse/CLOUDSTACK-9252] it was 
> possible to configure NFS version for secondary storage mount. 
> However, changing NFS version requires inserting an new detail on 
> {{image_store_details}} table, with {{name = 'nfs.version'}} and {{value = 
> X}} where X is desired NFS version, and then restarting management server for 
> changes to take effect.
> Our improvement aims to make NFS version changeable from UI, instead of 
> previously described workflow.
> h3. Proposed solution
> Basically, NFS version is defined as an image store ConfigKey, this implied:
> * Adding a new Config scope: *ImageStore*
> * Make {{ImageStoreDetailsDao}} class to extend {{ResourceDetailsDaoBase}} 
> and {{ImageStoreDetailVO}} implement {{ResourceDetail}}
> * Insert {{'display'}} column on {{image_store_details}} table
> * Extending {{ListCfgsCmd}} and {{UpdateCfgCmd}} to support *ImageStore* 
> scope, which implied:
> ** Injecting {{ImageStoreDetailsDao}} and {{ImageStoreDao}} on 
> {{ConfigurationManagerImpl}} class, on {{cloud-server}} module.
> h4. Important
> It is important to mention that {{ImageStoreDaoImpl}} and 
> {{ImageStoreDetailsDaoImpl}} classes were moved from {{cloud-engine-storage}} 
> to {{cloud-engine-schema}} module in order to Spring find those beans to 
> inject on {{ConfigurationManagerImpl}} in {{cloud-server}} module.
> We had this maven dependencies between modules:
> * {{cloud-server --> cloud-engine-schema}}
> * {{cloud-engine-storage --> cloud-secondary-storage --> cloud-server}}
> As {{ImageStoreDaoImpl}} and {{ImageStoreDetailsDaoImpl}} were defined in 
> {{cloud-engine-storage}}, and they needed in {{cloud-server}} module, to be 
> injected on {{ConfigurationManagerImpl}}, if we added dependency from 
> {{cloud-server}} to {{cloud-engine-storage}} we would introduce a dependency 
> cycle. To avoid this cycle, we moved those classes to {{cloud-engine-schema}} 
> module



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9438) Fix for CLOUDSTACK-9252 - Make NFS version changeable in UI

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15601444#comment-15601444
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9438:


Github user karuturi commented on the issue:

https://github.com/apache/cloudstack/pull/1615
  
@blueorangutan help


> Fix for CLOUDSTACK-9252 - Make NFS version changeable in UI
> ---
>
> Key: CLOUDSTACK-9438
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9438
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Nicolas Vazquez
>Assignee: Nicolas Vazquez
>
> h3. Introduction
> From [9252|https://issues.apache.org/jira/browse/CLOUDSTACK-9252] it was 
> possible to configure NFS version for secondary storage mount. 
> However, changing NFS version requires inserting an new detail on 
> {{image_store_details}} table, with {{name = 'nfs.version'}} and {{value = 
> X}} where X is desired NFS version, and then restarting management server for 
> changes to take effect.
> Our improvement aims to make NFS version changeable from UI, instead of 
> previously described workflow.
> h3. Proposed solution
> Basically, NFS version is defined as an image store ConfigKey, this implied:
> * Adding a new Config scope: *ImageStore*
> * Make {{ImageStoreDetailsDao}} class to extend {{ResourceDetailsDaoBase}} 
> and {{ImageStoreDetailVO}} implement {{ResourceDetail}}
> * Insert {{'display'}} column on {{image_store_details}} table
> * Extending {{ListCfgsCmd}} and {{UpdateCfgCmd}} to support *ImageStore* 
> scope, which implied:
> ** Injecting {{ImageStoreDetailsDao}} and {{ImageStoreDao}} on 
> {{ConfigurationManagerImpl}} class, on {{cloud-server}} module.
> h4. Important
> It is important to mention that {{ImageStoreDaoImpl}} and 
> {{ImageStoreDetailsDaoImpl}} classes were moved from {{cloud-engine-storage}} 
> to {{cloud-engine-schema}} module in order to Spring find those beans to 
> inject on {{ConfigurationManagerImpl}} in {{cloud-server}} module.
> We had this maven dependencies between modules:
> * {{cloud-server --> cloud-engine-schema}}
> * {{cloud-engine-storage --> cloud-secondary-storage --> cloud-server}}
> As {{ImageStoreDaoImpl}} and {{ImageStoreDetailsDaoImpl}} were defined in 
> {{cloud-engine-storage}}, and they needed in {{cloud-server}} module, to be 
> injected on {{ConfigurationManagerImpl}}, if we added dependency from 
> {{cloud-server}} to {{cloud-engine-storage}} we would introduce a dependency 
> cycle. To avoid this cycle, we moved those classes to {{cloud-engine-schema}} 
> module



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9339) Virtual Routers don't handle Multiple Public Interfaces

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15601373#comment-15601373
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9339:


Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/1659
  
@rhtyd a Trillian-Jenkins test job (centos7 mgmt + kvm-centos7) has been 
kicked to run smoke tests


> Virtual Routers don't handle Multiple Public Interfaces
> ---
>
> Key: CLOUDSTACK-9339
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9339
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Virtual Router
>Affects Versions: 4.8.0
>Reporter: dsclose
>  Labels: firewall, nat, router
>
> There are a series of issues with the way Virtual Routers manage multiple 
> public interfaces. These are more pronounced on redundant virtual router 
> setups. I have not attempted to examine these issues in a VPC context. 
> Outside of a VPC context, however, the following is expected behaviour:
> * eth0 connects the router to the guest network.
> * In RvR setups, keepalived manages the guests' gateway IP as a virtual IP on 
> eth0.
> * eth1 provides a local link to the hypervisor, allowing Cloudstack to issue 
> commands to the router.
> * eth2 is the routers public interface. By default, a single public IP will 
> be setup on eth2 along with the necessary iptables and ip rules to source-NAT 
> guest traffic to that public IP.
> * When a public IP address is assigned to the router that is on a separate 
> subnet to the source-NAT IP, a new interface is configured, such as eth3, and 
> the IP is assigned to that interface.
> * This can result in eth3, eth4, eth5, etc. being created depending upon how 
> many public subnets the router has to work with.
> The above all works. The following, however, is currently not working:
> * Public interfaces should be set to DOWN on backup redundant routers. The 
> master.py script is responsible for setting public interfaces to UP during a 
> keepalived transition. Currently the check_is_up method of the CsIP class 
> brings all interfaces UP on both RvR. A proposed fix for this has been 
> discussed on the mailing list. That fix will leave public interfaces DOWN on 
> RvR allowing the keepalived transition to control the state of public 
> interfaces. Issue #1413 includes a commit that contradicts the proposed fix 
> so it is unclear what the current state of the code should be.
> * Newly created interfaces should be set to UP on master redundant routers. 
> Assuming public interfaces should be default be DOWN on an RvR we need to 
> accommodate the fact that, as interfaces are created, no keepalived 
> transition occurs. This means that assigning an IP from a new public subnet 
> will have no effect (as the interface will be down) until the network is 
> restarted with a "clean up."
> * Public interfaces other than eth2 do not forward traffic. There are two 
> iptables rules in the FORWARD chain of the filter table created for eth2 that 
> allow forwarding between eth2 and eth0. Equivalent rules are not created for 
> other public interfaces so forwarded traffic is dropped.
> * Outbound traffic from guest VMs does not honour static-NAT rules. Instead, 
> outbound traffic is source-NAT'd to the networks default source-NAT IP. New 
> connections from guests that are destined for public networks are processed 
> like so:
> 1. Traffic is matched against the following rule in the mangle table that 
> marks the connection with a 0x0:
> *mangle
> -A PREROUTING -i eth0 -m state --state NEW -j CONNMARK --set-xmark 
> 0x0/0x
> 2. There are no "ip rule" statements that match a connection marked 0x0, so 
> the kernel routes the connection via the default gateway. That gateway is on 
> source-NAT subnet, so the connection is routed out of eth2.
> 3. The following iptables rules are then matched in the filter table:
> *filter
> -A FORWARD -i eth0 -o eth2 -j FW_OUTBOUND
> -A FW_OUTBOUND -j FW_EGRESS_RULES
> -A FW_EGRESS_RULES -j ACCEPT
> 4. Finally, the following rule is matched from the nat table, where the IP 
> address is the source-NAT IP:
> *nat
> -A POSTROUTING -o eth2 -j SNAT --to-source 123.4.5.67
>  



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9339) Virtual Routers don't handle Multiple Public Interfaces

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15601371#comment-15601371
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9339:


Github user rhtyd commented on the issue:

https://github.com/apache/cloudstack/pull/1659
  
@blueorangutan test


> Virtual Routers don't handle Multiple Public Interfaces
> ---
>
> Key: CLOUDSTACK-9339
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9339
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Virtual Router
>Affects Versions: 4.8.0
>Reporter: dsclose
>  Labels: firewall, nat, router
>
> There are a series of issues with the way Virtual Routers manage multiple 
> public interfaces. These are more pronounced on redundant virtual router 
> setups. I have not attempted to examine these issues in a VPC context. 
> Outside of a VPC context, however, the following is expected behaviour:
> * eth0 connects the router to the guest network.
> * In RvR setups, keepalived manages the guests' gateway IP as a virtual IP on 
> eth0.
> * eth1 provides a local link to the hypervisor, allowing Cloudstack to issue 
> commands to the router.
> * eth2 is the routers public interface. By default, a single public IP will 
> be setup on eth2 along with the necessary iptables and ip rules to source-NAT 
> guest traffic to that public IP.
> * When a public IP address is assigned to the router that is on a separate 
> subnet to the source-NAT IP, a new interface is configured, such as eth3, and 
> the IP is assigned to that interface.
> * This can result in eth3, eth4, eth5, etc. being created depending upon how 
> many public subnets the router has to work with.
> The above all works. The following, however, is currently not working:
> * Public interfaces should be set to DOWN on backup redundant routers. The 
> master.py script is responsible for setting public interfaces to UP during a 
> keepalived transition. Currently the check_is_up method of the CsIP class 
> brings all interfaces UP on both RvR. A proposed fix for this has been 
> discussed on the mailing list. That fix will leave public interfaces DOWN on 
> RvR allowing the keepalived transition to control the state of public 
> interfaces. Issue #1413 includes a commit that contradicts the proposed fix 
> so it is unclear what the current state of the code should be.
> * Newly created interfaces should be set to UP on master redundant routers. 
> Assuming public interfaces should be default be DOWN on an RvR we need to 
> accommodate the fact that, as interfaces are created, no keepalived 
> transition occurs. This means that assigning an IP from a new public subnet 
> will have no effect (as the interface will be down) until the network is 
> restarted with a "clean up."
> * Public interfaces other than eth2 do not forward traffic. There are two 
> iptables rules in the FORWARD chain of the filter table created for eth2 that 
> allow forwarding between eth2 and eth0. Equivalent rules are not created for 
> other public interfaces so forwarded traffic is dropped.
> * Outbound traffic from guest VMs does not honour static-NAT rules. Instead, 
> outbound traffic is source-NAT'd to the networks default source-NAT IP. New 
> connections from guests that are destined for public networks are processed 
> like so:
> 1. Traffic is matched against the following rule in the mangle table that 
> marks the connection with a 0x0:
> *mangle
> -A PREROUTING -i eth0 -m state --state NEW -j CONNMARK --set-xmark 
> 0x0/0x
> 2. There are no "ip rule" statements that match a connection marked 0x0, so 
> the kernel routes the connection via the default gateway. That gateway is on 
> source-NAT subnet, so the connection is routed out of eth2.
> 3. The following iptables rules are then matched in the filter table:
> *filter
> -A FORWARD -i eth0 -o eth2 -j FW_OUTBOUND
> -A FW_OUTBOUND -j FW_EGRESS_RULES
> -A FW_EGRESS_RULES -j ACCEPT
> 4. Finally, the following rule is matched from the nat table, where the IP 
> address is the source-NAT IP:
> *nat
> -A POSTROUTING -o eth2 -j SNAT --to-source 123.4.5.67
>  



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9504) Fully support system VMs on managed storage

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15601276#comment-15601276
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9504:


Github user rhtyd commented on the issue:

https://github.com/apache/cloudstack/pull/1642
  
@karuturi @mike-tutkowski the oobm related error was an env issue, the 
vpc/vr related failures are know (and fixes are on its way). I'm not sure what 
to make of the ssvm/storage related failures.


> Fully support system VMs on managed storage
> ---
>
> Key: CLOUDSTACK-9504
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9504
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.10.0.0
> Environment: All
>Reporter: Mike Tutkowski
>Assignee: Mike Tutkowski
> Fix For: 4.10.0.0
>
>
> There are three related items for this ticket:
> 1) Do not permit "custom IOPS" as a parameter when creating a system offering 
> (throw an exception if this parameter is passed in).
> 2) If you transition managed storage into maintenance mode and system VMs 
> were running on that managed storage, the host-side clustered file systems 
> (SRs on XenServer) are not removed. Remove them.
> 3) Add integration tests for system VMs with managed storage.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CLOUDSTACK-9504) Fully support system VMs on managed storage

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15601056#comment-15601056
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9504:


Github user karuturi commented on the issue:

https://github.com/apache/cloudstack/pull/1642
  
@blueorangutan @rhtyd How are we on this PR? are the failures related? Or 
can I go ahead and merge this?


> Fully support system VMs on managed storage
> ---
>
> Key: CLOUDSTACK-9504
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9504
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.10.0.0
> Environment: All
>Reporter: Mike Tutkowski
>Assignee: Mike Tutkowski
> Fix For: 4.10.0.0
>
>
> There are three related items for this ticket:
> 1) Do not permit "custom IOPS" as a parameter when creating a system offering 
> (throw an exception if this parameter is passed in).
> 2) If you transition managed storage into maintenance mode and system VMs 
> were running on that managed storage, the host-side clustered file systems 
> (SRs on XenServer) are not removed. Remove them.
> 3) Add integration tests for system VMs with managed storage.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)