[jira] [Commented] (CLOUDSTACK-9707) deployVirtualMachine API should fail if hostid is specified and host doesn't have enough resources

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9707:


Github user ustcweizhou commented on the issue:

https://github.com/apache/cloudstack/pull/1868
  
Do we need to add a global setting to determine whether deploy to other 
hosts if the specified host is out of capacity ?


> deployVirtualMachine API should fail if hostid is specified and host doesn't 
> have enough resources
> --
>
> Key: CLOUDSTACK-9707
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9707
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Anshul Gangwar
>Assignee: Anshul Gangwar
>
> While using hostid parameter, vm gets deployed on another if the host
> given is running out of capacity. If host id is specified the deployment 
> should happen
> on the given host and it should fail if the host is out of capacity. We are 
> retrying
> deployment on the entire zone without the given host id if we fail once. The 
> retry,
> which will retry on other hosts, should only be attempted if host id isn't 
> given.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-8897) baremetal:addHost:make host tag info mandtory in baremetal addhost Api call

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-8897:


Github user cloudmonger commented on the issue:

https://github.com/apache/cloudstack/pull/874
  
### ACS CI BVT Run
 **Sumarry:**
 Build Number 411
 Hypervisor xenserver
 NetworkType Advanced
 Passed=103
 Failed=2
 Skipped=7

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


**Failed tests:**
* test_routers_network_ops.py

 * test_01_RVR_Network_FW_PF_SSH_default_routes_egress_true Failed

 * test_02_RVR_Network_FW_PF_SSH_default_routes_egress_false Failed


**Skipped tests:**
test_01_test_vm_volume_snapshot
test_vm_nic_adapter_vmxnet3
test_static_role_account_acls
test_11_ss_nfs_version_on_ssvm
test_nested_virtualization_vmware
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_deploy_vms_with_varied_deploymentplanners.py
test_network.py
test_router_dns.py
test_non_contigiousvlan.py
test_login.py
test_deploy_vm_iso.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_nic.py
test_deploy_vm_root_resize.py
test_resource_detail.py
test_secondary_storage.py
test_vm_life_cycle.py
test_disk_offerings.py


> baremetal:addHost:make host tag info mandtory in baremetal addhost Api call
> ---
>
> Key: CLOUDSTACK-8897
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8897
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Baremetal, Management Server
>Reporter: Harikrishna Patnala
>Assignee: Harikrishna Patnala
> Fix For: 4.9.1.0
>
>
> Right now in baremetal, addhost api is successful with out providing the host 
> tag info and we recommend host tag is mandatory for bare-metal.
> in the current implementation host tag check is happening at vm deployment 
> stage but it will be good to have host tag field as mandatory field during 
> adding of the host it self.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-9707) deployVirtualMachine API should fail if hostid is specified and host doesn't have enough resources

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9707:


Github user koushik-das commented on the issue:

https://github.com/apache/cloudstack/pull/1868
  
Code changes LGTM, also verified that deployment is not retried in case of 
failure if host is specified


> deployVirtualMachine API should fail if hostid is specified and host doesn't 
> have enough resources
> --
>
> Key: CLOUDSTACK-9707
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9707
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Anshul Gangwar
>Assignee: Anshul Gangwar
>
> While using hostid parameter, vm gets deployed on another if the host
> given is running out of capacity. If host id is specified the deployment 
> should happen
> on the given host and it should fail if the host is out of capacity. We are 
> retrying
> deployment on the entire zone without the given host id if we fail once. The 
> retry,
> which will retry on other hosts, should only be attempted if host id isn't 
> given.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-9781) ACS records ID in events tables instead of UUID.

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9781:


Github user jayantpatil1234 commented on the issue:

https://github.com/apache/cloudstack/pull/1940
  
@blueorangutan test cases which are failing, not related to my code 
changes. Could you restart test suites once again. 


> ACS records ID in events tables instead of UUID.
> 
>
> Key: CLOUDSTACK-9781
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9781
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Jayant Patil
>
> ISSUE
> =
> Wrong presentation of volume id in ACS events.
> While creating a snapshot, only volume ID is mentioned in the events. For 
> example, “Scheduled async job for creating snapshot for volume Id:270". On 
> looking into the notification, user is not able to identify the volume. So 
> modified event description with UUID.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-9317) Disabling static NAT on many IPs can leave wrong IPs on the router

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9317:


Github user jayapalu commented on the issue:

https://github.com/apache/cloudstack/pull/1908
  
@ProjectMoon  The ip issue can be worked as separate ticket/PR. It is an 
isolated issue, it is not having any dependency with this PR. So we will get 
this PR in and create a separate ticket for the ip issue. What do you say ?


> Disabling static NAT on many IPs can leave wrong IPs on the router
> --
>
> Key: CLOUDSTACK-9317
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9317
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server, Virtual Router
>Affects Versions: 4.7.0, 4.7.1, 4.7.2
>Reporter: Jeff Hair
>
> The current behavior of enabling or disabling static NAT will call the apply 
> IP associations method in the management server. The method is not 
> thread-safe. If it's called from multiple threads, each thread will load up 
> the list of public IPs in different states (add or revoke)--correct for the 
> thread, but not correct overall. Depending on execution order on the virtual 
> router, the router can end up with public IPs assigned to it that are not 
> supposed to be on it anymore. When another account acquires the same IP, this 
> of course leads to network problems.
> The problem has been in CS since at least 4.2, and likely affects all 
> recently released versions. Affected version is set to 4.7.x because that's 
> what we verified against.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-8239) Add support for VirtIO-SCSI for KVM hypervisors

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-8239:


Github user nathanejohnson commented on the issue:

https://github.com/apache/cloudstack/pull/1955
  
@borisstoyanov so the good news is it didn't skip the test.  the bad news 
is it didn't seem to have proper credentials for ssh'ing into your hosts.  It 
did pass the test where it ssh'ed into the guest, however.  So this at least 
demonstrates a guest is happy.

Do you have any tips on ways of making the smoke test play nice with BO wrt 
ssh'ing into the kvm hosts?


> Add support for VirtIO-SCSI for KVM hypervisors
> ---
>
> Key: CLOUDSTACK-8239
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8239
> Project: CloudStack
>  Issue Type: New Feature
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: KVM, Storage Controller
>Affects Versions: 4.6.0
> Environment: KVM
>Reporter: Andrei Mikhailovsky
>Assignee: Wido den Hollander
>Priority: Critical
>  Labels: ceph, gsoc2017, kvm, libvirt, rbd, storage_drivers, 
> virtio
> Fix For: Future
>
>
> It would be nice to have support for virtio-scsi for KVM hypervisors.
> The reason for using virtio-scsi instead of virtio-blk would be increasing 
> the number of devices you can attach to a vm, have ability to use discard and 
> reclaim unused blocks from the backend storage like ceph rbd. There are also 
> talks about having a greater performance advantage as well.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-9198) VR gets created in the disabled POD

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9198:


GitHub user anshul1886 reopened a pull request:

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

CLOUDSTACK-9198: Virtual router gets deployed in disabled Pod

While starting the router, send the user from the callingContext instead of 
defaulting to System user.

https://issues.apache.org/jira/browse/CLOUDSTACK-9198
## To test:

Verify that Virtual Router is not getting deployed in disabled Pod.


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

$ git pull https://github.com/anshul1886/cloudstack-1 CLOUDSTACK-9198

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

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


commit d3594526294601bcfda01415f370f4bc0e71e910
Author: Anshul Gangwar 
Date:   2015-11-02T08:28:44Z

CLOUDSTACK-9198: Virtual router gets deployed in disabled Pod. While 
starting the
router, send the user from the callingContext instead of defaulting to 
System user




> VR gets created in the disabled POD
> ---
>
> Key: CLOUDSTACK-9198
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9198
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Anshul Gangwar
>Assignee: Anshul Gangwar
>
> VR gets created in the disabled POD



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-9198) VR gets created in the disabled POD

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9198:


Github user anshul1886 closed the pull request at:

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


> VR gets created in the disabled POD
> ---
>
> Key: CLOUDSTACK-9198
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9198
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Anshul Gangwar
>Assignee: Anshul Gangwar
>
> VR gets created in the disabled POD



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-8239) Add support for VirtIO-SCSI for KVM hypervisors

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-8239:


Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/1955
  
Trillian test result (tid-921)
Environment: kvm-centos7 (x2), Advanced Networking with Mgmt server 7
Total time taken: 36820 seconds
Marvin logs: 
https://github.com/blueorangutan/acs-prs/releases/download/trillian/pr1955-t921-kvm-centos7.zip
Intermitten failure detected: 
/marvin/tests/smoke/test_deploy_virtio_scsi_vm.py
Intermitten failure detected: /marvin/tests/smoke/test_privategw_acl.py
Intermitten failure detected: /marvin/tests/smoke/test_snapshots.py
Intermitten failure detected: /marvin/tests/smoke/test_vpc_vpn.py
Test completed. 47 look ok, 3 have error(s)


Test | Result | Time (s) | Test File
--- | --- | --- | ---
test_04_rvpc_privategw_static_routes | `Failure` | 334.38 | 
test_privategw_acl.py
test_02_list_snapshots_with_removed_data_store | `Error` | 0.03 | 
test_snapshots.py
test_03_verify_libvirt_attach_disk | `Error` | 610.88 | 
test_deploy_virtio_scsi_vm.py
test_02_verify_libvirt_after_restart | `Error` | 615.96 | 
test_deploy_virtio_scsi_vm.py
test_01_verify_libvirt | `Error` | 600.73 | test_deploy_virtio_scsi_vm.py
test_01_vpc_site2site_vpn | Success | 159.71 | test_vpc_vpn.py
test_01_vpc_remote_access_vpn | Success | 65.83 | test_vpc_vpn.py
test_01_redundant_vpc_site2site_vpn | Success | 240.43 | test_vpc_vpn.py
test_02_VPC_default_routes | Success | 292.11 | test_vpc_router_nics.py
test_01_VPC_nics_after_destroy | Success | 551.36 | test_vpc_router_nics.py
test_05_rvpc_multi_tiers | Success | 514.33 | test_vpc_redundant.py
test_04_rvpc_network_garbage_collector_nics | Success | 1404.34 | 
test_vpc_redundant.py
test_03_create_redundant_VPC_1tier_2VMs_2IPs_2PF_ACL_reboot_routers | 
Success | 568.61 | test_vpc_redundant.py
test_02_redundant_VPC_default_routes | Success | 737.39 | 
test_vpc_redundant.py
test_01_create_redundant_VPC_2tiers_4VMs_4IPs_4PF_ACL | Success | 1271.92 | 
test_vpc_redundant.py
test_09_delete_detached_volume | Success | 156.17 | test_volumes.py
test_08_resize_volume | Success | 156.09 | test_volumes.py
test_07_resize_fail | Success | 156.08 | test_volumes.py
test_06_download_detached_volume | Success | 156.01 | test_volumes.py
test_05_detach_volume | Success | 150.53 | test_volumes.py
test_04_delete_attached_volume | Success | 150.91 | test_volumes.py
test_03_download_attached_volume | Success | 155.98 | test_volumes.py
test_02_attach_volume | Success | 94.76 | test_volumes.py
test_01_create_volume | Success | 711.91 | test_volumes.py
test_03_delete_vm_snapshots | Success | 275.10 | test_vm_snapshots.py
test_02_revert_vm_snapshots | Success | 100.69 | test_vm_snapshots.py
test_01_create_vm_snapshots | Success | 163.74 | test_vm_snapshots.py
test_deploy_vm_multiple | Success | 256.93 | test_vm_life_cycle.py
test_deploy_vm | Success | 0.02 | test_vm_life_cycle.py
test_advZoneVirtualRouter | Success | 0.02 | test_vm_life_cycle.py
test_10_attachAndDetach_iso | Success | 26.49 | test_vm_life_cycle.py
test_09_expunge_vm | Success | 125.12 | test_vm_life_cycle.py
test_08_migrate_vm | Success | 40.64 | test_vm_life_cycle.py
test_07_restore_vm | Success | 0.09 | test_vm_life_cycle.py
test_06_destroy_vm | Success | 125.64 | test_vm_life_cycle.py
test_03_reboot_vm | Success | 125.79 | test_vm_life_cycle.py
test_02_start_vm | Success | 10.12 | test_vm_life_cycle.py
test_01_stop_vm | Success | 40.25 | test_vm_life_cycle.py
test_CreateTemplateWithDuplicateName | Success | 35.32 | test_templates.py
test_08_list_system_templates | Success | 0.02 | test_templates.py
test_07_list_public_templates | Success | 0.03 | test_templates.py
test_05_template_permissions | Success | 0.04 | test_templates.py
test_04_extract_template | Success | 5.11 | test_templates.py
test_03_delete_template | Success | 5.09 | test_templates.py
test_02_edit_template | Success | 90.09 | test_templates.py
test_01_create_template | Success | 45.35 | test_templates.py
test_10_destroy_cpvm | Success | 161.57 | test_ssvm.py
test_09_destroy_ssvm | Success | 133.41 | test_ssvm.py
test_08_reboot_cpvm | Success | 101.46 | test_ssvm.py
test_07_reboot_ssvm | Success | 133.47 | test_ssvm.py
test_06_stop_cpvm | Success | 131.58 | test_ssvm.py
test_05_stop_ssvm | Success | 133.56 | test_ssvm.py
test_04_cpvm_internals | Success | 1.17 | test_ssvm.py
test_03_ssvm_internals | Success | 3.57 | test_ssvm.py
test_02_list_cpvm_vm | Success | 0.08 | test_ssvm.py
test_01_list_sec_storage_vm | Success | 0.09 

[jira] [Commented] (CLOUDSTACK-8910) The reserved_capacity field increases suddenly after a vmware host failure

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-8910:


Github user cloudmonger commented on the issue:

https://github.com/apache/cloudstack/pull/892
  
### ACS CI BVT Run
 **Sumarry:**
 Build Number 410
 Hypervisor xenserver
 NetworkType Advanced
 Passed=104
 Failed=1
 Skipped=7

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


**Failed tests:**
* test_routers_network_ops.py

 * test_03_RVR_Network_check_router_state Failing since 2 runs


**Skipped tests:**
test_01_test_vm_volume_snapshot
test_vm_nic_adapter_vmxnet3
test_static_role_account_acls
test_11_ss_nfs_version_on_ssvm
test_nested_virtualization_vmware
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_deploy_vms_with_varied_deploymentplanners.py
test_network.py
test_router_dns.py
test_non_contigiousvlan.py
test_login.py
test_deploy_vm_iso.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_nic.py
test_deploy_vm_root_resize.py
test_resource_detail.py
test_secondary_storage.py
test_vm_life_cycle.py
test_disk_offerings.py


> The reserved_capacity field increases suddenly after a vmware host failure
> --
>
> Key: CLOUDSTACK-8910
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8910
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: sudharma jain
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-8239) Add support for VirtIO-SCSI for KVM hypervisors

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-8239:


Github user nathanejohnson commented on the issue:

https://github.com/apache/cloudstack/pull/1955
  
@borisstoyanov Quick questions, what tags need to be present to get picked 
up by BO?  I'm worried my smoke test might get skipped.


> Add support for VirtIO-SCSI for KVM hypervisors
> ---
>
> Key: CLOUDSTACK-8239
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8239
> Project: CloudStack
>  Issue Type: New Feature
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: KVM, Storage Controller
>Affects Versions: 4.6.0
> Environment: KVM
>Reporter: Andrei Mikhailovsky
>Assignee: Wido den Hollander
>Priority: Critical
>  Labels: ceph, gsoc2017, kvm, libvirt, rbd, storage_drivers, 
> virtio
> Fix For: Future
>
>
> It would be nice to have support for virtio-scsi for KVM hypervisors.
> The reason for using virtio-scsi instead of virtio-blk would be increasing 
> the number of devices you can attach to a vm, have ability to use discard and 
> reclaim unused blocks from the backend storage like ceph rbd. There are also 
> talks about having a greater performance advantage as well.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-9608) Errored State and Abandoned state Templates are not displayed on UI

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9608:


Github user serg38 commented on the issue:

https://github.com/apache/cloudstack/pull/1774
  
@borisstoyanov That would be awesome . 


> Errored State and Abandoned state Templates are not displayed on UI
> ---
>
> Key: CLOUDSTACK-9608
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9608
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Priyank Parihar
>Assignee: Priyank Parihar
>
> Errored and Abandoned Templates should also be displayed on UI so that user 
> has the accessibility to delete the template even before the clean up thread 
> is run.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (CLOUDSTACK-9810) Cloudstack Ldap user fails to authenticate

[Michael (JIRA)]

Michael created CLOUDSTACK-9810:
---

 Summary: Cloudstack Ldap user fails to authenticate
 Key: CLOUDSTACK-9810
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9810
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Management Server
Affects Versions: 4.9.2.0
 Environment: CentOS 6.8
Reporter: Michael


I have a user that was previously able to login with LDAP authentication on 
port 389.  I'm using ldap.provider = openldap and restricting my search to a 
group inside active directory specified in ldap.search.group.principle

Anyway, the user now reports that their no longer able to login.  I didn't find 
any errors on the management server's log and his credentials work for other 
systems at our company.  Is there some method to increase the verbose of the 
management server log on this issue?  I have ldap.rad.timeout set to 3 and 
ldap.request.page.size to 1000.  Using active directory for authentication 
against sAMAccountName for ldap.user.object=user.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-9608) Errored State and Abandoned state Templates are not displayed on UI

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9608:


Github user borisstoyanov commented on the issue:

https://github.com/apache/cloudstack/pull/1774
  
I've been thinking of writing an extension in marvin to login at management 
an grab management log at that point -15 sec time, will see when will write 
that... 
Let me address this tomorrow


> Errored State and Abandoned state Templates are not displayed on UI
> ---
>
> Key: CLOUDSTACK-9608
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9608
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Priyank Parihar
>Assignee: Priyank Parihar
>
> Errored and Abandoned Templates should also be displayed on UI so that user 
> has the accessibility to delete the template even before the clean up thread 
> is run.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-8239) Add support for VirtIO-SCSI for KVM hypervisors

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-8239:


Github user borisstoyanov commented on the issue:

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


> Add support for VirtIO-SCSI for KVM hypervisors
> ---
>
> Key: CLOUDSTACK-8239
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8239
> Project: CloudStack
>  Issue Type: New Feature
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: KVM, Storage Controller
>Affects Versions: 4.6.0
> Environment: KVM
>Reporter: Andrei Mikhailovsky
>Assignee: Wido den Hollander
>Priority: Critical
>  Labels: ceph, gsoc2017, kvm, libvirt, rbd, storage_drivers, 
> virtio
> Fix For: Future
>
>
> It would be nice to have support for virtio-scsi for KVM hypervisors.
> The reason for using virtio-scsi instead of virtio-blk would be increasing 
> the number of devices you can attach to a vm, have ability to use discard and 
> reclaim unused blocks from the backend storage like ceph rbd. There are also 
> talks about having a greater performance advantage as well.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-8239) Add support for VirtIO-SCSI for KVM hypervisors

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-8239:


Github user blueorangutan commented on the issue:

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


> Add support for VirtIO-SCSI for KVM hypervisors
> ---
>
> Key: CLOUDSTACK-8239
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8239
> Project: CloudStack
>  Issue Type: New Feature
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: KVM, Storage Controller
>Affects Versions: 4.6.0
> Environment: KVM
>Reporter: Andrei Mikhailovsky
>Assignee: Wido den Hollander
>Priority: Critical
>  Labels: ceph, gsoc2017, kvm, libvirt, rbd, storage_drivers, 
> virtio
> Fix For: Future
>
>
> It would be nice to have support for virtio-scsi for KVM hypervisors.
> The reason for using virtio-scsi instead of virtio-blk would be increasing 
> the number of devices you can attach to a vm, have ability to use discard and 
> reclaim unused blocks from the backend storage like ceph rbd. There are also 
> talks about having a greater performance advantage as well.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-8239) Add support for VirtIO-SCSI for KVM hypervisors

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-8239:


Github user borisstoyanov commented on the issue:

https://github.com/apache/cloudstack/pull/1955
  
Thanks @nathanejohnson, lets run that with BO
@blueorangutan package


> Add support for VirtIO-SCSI for KVM hypervisors
> ---
>
> Key: CLOUDSTACK-8239
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8239
> Project: CloudStack
>  Issue Type: New Feature
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: KVM, Storage Controller
>Affects Versions: 4.6.0
> Environment: KVM
>Reporter: Andrei Mikhailovsky
>Assignee: Wido den Hollander
>Priority: Critical
>  Labels: ceph, gsoc2017, kvm, libvirt, rbd, storage_drivers, 
> virtio
> Fix For: Future
>
>
> It would be nice to have support for virtio-scsi for KVM hypervisors.
> The reason for using virtio-scsi instead of virtio-blk would be increasing 
> the number of devices you can attach to a vm, have ability to use discard and 
> reclaim unused blocks from the backend storage like ceph rbd. There are also 
> talks about having a greater performance advantage as well.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-8239) Add support for VirtIO-SCSI for KVM hypervisors

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-8239:


Github user blueorangutan commented on the issue:

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


> Add support for VirtIO-SCSI for KVM hypervisors
> ---
>
> Key: CLOUDSTACK-8239
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8239
> Project: CloudStack
>  Issue Type: New Feature
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: KVM, Storage Controller
>Affects Versions: 4.6.0
> Environment: KVM
>Reporter: Andrei Mikhailovsky
>Assignee: Wido den Hollander
>Priority: Critical
>  Labels: ceph, gsoc2017, kvm, libvirt, rbd, storage_drivers, 
> virtio
> Fix For: Future
>
>
> It would be nice to have support for virtio-scsi for KVM hypervisors.
> The reason for using virtio-scsi instead of virtio-blk would be increasing 
> the number of devices you can attach to a vm, have ability to use discard and 
> reclaim unused blocks from the backend storage like ceph rbd. There are also 
> talks about having a greater performance advantage as well.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-9610) Disabled Host Keeps Being up status after unmanaging cluster

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9610:


Github user DaanHoogland commented on the issue:

https://github.com/apache/cloudstack/pull/1779
  
@priyankparihar I agree that host should not show as up but indeed why hide 
it? Unless we show no details for an unmanaged cluster we should be able to 
find the host in there. It should still show as disabled of course. 


> Disabled Host Keeps Being up status after unmanaging cluster 
> -
>
> Key: CLOUDSTACK-9610
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9610
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Reporter: Priyank Parihar
>Assignee: Priyank Parihar
>
> ENVIRONMENT 
> = 
> XenServer Version : 6.2 
> ISSUE 
> == 
> Disabled Host Keeps Being 'UP' status after unmanging cluster 
> Repro. steps followed 
> == 
> Disabled Host from UI. 
> Unmanaged the cluster which the host was in. 
> Still can see the Host showing 'UP' in UI 
> Expected Behavior 
> ===
> After disabling the host and un-managing the cluster, the host should appear 
> in "disconnected" state and not UP state. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-9610) Disabled Host Keeps Being up status after unmanaging cluster

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9610:


Github user cloudmonger commented on the issue:

https://github.com/apache/cloudstack/pull/1779
  
### ACS CI BVT Run
 **Sumarry:**
 Build Number 408
 Hypervisor xenserver
 NetworkType Advanced
 Passed=104
 Failed=1
 Skipped=7

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


**Failed tests:**
* test_non_contigiousvlan.py

 * test_extendPhysicalNetworkVlan Failed


**Skipped tests:**
test_01_test_vm_volume_snapshot
test_vm_nic_adapter_vmxnet3
test_static_role_account_acls
test_11_ss_nfs_version_on_ssvm
test_nested_virtualization_vmware
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_deploy_vms_with_varied_deploymentplanners.py
test_network.py
test_router_dns.py
test_login.py
test_deploy_vm_iso.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_nic.py
test_deploy_vm_root_resize.py
test_resource_detail.py
test_secondary_storage.py
test_vm_life_cycle.py
test_routers_network_ops.py
test_disk_offerings.py


> Disabled Host Keeps Being up status after unmanaging cluster 
> -
>
> Key: CLOUDSTACK-9610
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9610
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Reporter: Priyank Parihar
>Assignee: Priyank Parihar
>
> ENVIRONMENT 
> = 
> XenServer Version : 6.2 
> ISSUE 
> == 
> Disabled Host Keeps Being 'UP' status after unmanging cluster 
> Repro. steps followed 
> == 
> Disabled Host from UI. 
> Unmanaged the cluster which the host was in. 
> Still can see the Host showing 'UP' in UI 
> Expected Behavior 
> ===
> After disabling the host and un-managing the cluster, the host should appear 
> in "disconnected" state and not UP state. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-9765) broken db.properties after upgrade

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9765:


Github user Slair1 commented on the issue:

https://github.com/apache/cloudstack/pull/1923
  
This LGTM too, we hit this issue during our upgrade


> broken db.properties after upgrade
> --
>
> Key: CLOUDSTACK-9765
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9765
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Upgrade
>Affects Versions: 4.9.2.0
>Reporter: René Moser
>Assignee: René Moser
>
> {code}
> shapeblue0.el6.x86_64 
>4/8 
>   Updating   : cloudstack-management-4.9.2.0-shapeblue0.el6.x86_64
>   
>   5/8 
> warning: /etc/cloudstack/management/db.properties created as 
> /etc/cloudstack/management/db.properties.rpmnew
> sed: can't read db.properties: No such file or directory
> Unable to determine ssl settings for server.xml, please run 
> cloudstack-setup-management manually
> Unable to determine ssl settings for tomcat.conf, please run 
> cloudstack-setup-management manually
> {code}
> Seeing this error while installing the RPM, resulting in cloudstack 
> management server is not able to connect to the DB after MS service start



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-9604) Root disk resize support for VMware and XenServer

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9604:


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

https://github.com/apache/cloudstack/pull/1813#discussion_r103719599
  
--- Diff: server/src/com/cloud/vm/UserVmManagerImpl.java ---
@@ -3614,6 +3604,26 @@ public UserVmVO doInTransaction(TransactionStatus 
status) throws InsufficientCap
 });
 }
 
+public void validateRootDiskResize(final HypervisorType 
hypervisorType, Long rootDiskSize, VMTemplateVO templateVO, UserVmVO vm, final 
Map customParameters) throws InvalidParameterValueException
+{
+// rootdisksize must be larger than template.
+if ((rootDiskSize << 30) < templateVO.getSize()) {
+Long templateVOSizeGB = templateVO.getSize() / 1024 / 1024 / 
1024;
+s_logger.error("unsupported: rootdisksize override is smaller 
than template size " + templateVO.getSize() + "B (" + templateVOSizeGB + "GB)");
+throw new InvalidParameterValueException("unsupported: 
rootdisksize override is smaller than template size " + templateVO.getSize() + 
"B (" + templateVOSizeGB + "GB)");
+} else if ((rootDiskSize << 30) > templateVO.getSize()){
+if (hypervisorType == HypervisorType.VMware && 
!vm.getDetails().get("rootDiskController").toLowerCase().contains("scsi")) {
+s_logger.error("Found unsupported root disk controller : " 
+ vm.getDetails().get("rootDiskController"));
--- End diff --

I think NPE on line 3615 is due to rootdiskcontroller might be not set for 
VM. If template is imported without explicitly specifying root disk controller 
than a global setting will be in effect.


> Root disk resize support for VMware and XenServer
> -
>
> Key: CLOUDSTACK-9604
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9604
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Priyank Parihar
>Assignee: Priyank Parihar
> Attachments: 1.png, 2.png, 3.png
>
>
> Currently the root size of an instance is locked to that of the template. 
> This creates unnecessary template duplicates, prevents the creation of a 
> market place, wastes time and disk space and generally makes work more 
> complicated.
> Real life example - a small VPS provider might want to offer the following 
> sizes (in GB):
> 10,20,40,80,160,240,320,480,620
> That's 9 offerings.
> The template selection could look like this, including real disk space used:
> Windows 2008 ~10GB
> Windows 2008+Plesk ~15GB
> Windows 2008+MSSQL ~15GB
> Windows 2012 ~10GB
> Windows 2012+Plesk ~15GB
> Windows 2012+MSSQL ~15GB
> CentOS ~1GB
> CentOS+CPanel ~3GB
> CentOS+Virtualmin ~3GB
> CentOS+Zimbra ~3GB
> CentOS+Docker ~2GB
> Debian ~1GB
> Ubuntu LTS ~1GB
> In this case the total disk space used by templates will be 828 GB, that's 
> almost 1 TB. If your storage is expensive and limited SSD this can get 
> painful!
> If the root resize feature is enabled we can reduce this to under 100 GB.
> Specifications and Description 
> Administrators don't want to deploy duplicate OS templates of differing 
> sizes just to support different storage packages. Instead, the VM deployment 
> can accept a size for the root disk and adjust the template clone 
> accordingly. In addition, CloudStack already supports data disk resizing for 
> existing volumes, we can extend that functionality to resize existing root 
> disks. 
>   As mentioned, we can leverage the existing design for resizing an existing 
> volume. The difference with root volumes is that we can't resize via disk 
> offering, therefore we need to verify that no disk offering was passed, just 
> a size. The existing enforcements of new size > existing size will still 
> server their purpose.
>For deployment-based resize (ROOT volume size different from template 
> size), we pass the rootdisksize parameter when the existing code allocates 
> the root volume. In the process, we validate that the root disk size is > 
> existing template size, and non-zero. This will persist the root volume as 
> the desired size regardless of whether or not the VM is started on deploy. 
> Then hypervisor specific code needs to be made to pay attention to the 
> VolumeObjectTO's size attribute and use that when doing the work of cloning 
> from template, rather than inheriting the template's size. This can be 
> implemented one hypervisor at a time, and as such there needs to be a check 
> in UserVmManagerImpl to fail unsupported hypervisors with 
> 

[jira] [Commented] (CLOUDSTACK-9765) broken db.properties after upgrade

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9765:


Github user rhtyd commented on the issue:

https://github.com/apache/cloudstack/pull/1923
  
LGTM. @karuturi not a blocker, but then we'll need to document the 
workaround (manual fix) in the release notes. If RC1 has any blockers, let's 
include this in RC2.


> broken db.properties after upgrade
> --
>
> Key: CLOUDSTACK-9765
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9765
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Upgrade
>Affects Versions: 4.9.2.0
>Reporter: René Moser
>Assignee: René Moser
>
> {code}
> shapeblue0.el6.x86_64 
>4/8 
>   Updating   : cloudstack-management-4.9.2.0-shapeblue0.el6.x86_64
>   
>   5/8 
> warning: /etc/cloudstack/management/db.properties created as 
> /etc/cloudstack/management/db.properties.rpmnew
> sed: can't read db.properties: No such file or directory
> Unable to determine ssl settings for server.xml, please run 
> cloudstack-setup-management manually
> Unable to determine ssl settings for tomcat.conf, please run 
> cloudstack-setup-management manually
> {code}
> Seeing this error while installing the RPM, resulting in cloudstack 
> management server is not able to connect to the DB after MS service start



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-8239) Add support for VirtIO-SCSI for KVM hypervisors

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-8239:


Github user nathanejohnson commented on the issue:

https://github.com/apache/cloudstack/pull/1955
  
@wido I have removed the extraneous log messages.

@boris I have added a smoke test for this that tests both virsh output from 
the host and lspci / lsblk output from the guest.  Here is the output from me 
running this in a bubble:

Test that libvirt properly created domain with scsi controller ... === 
TestName: test_01_verify_libvirt | Status : SUCCESS ===
ok
Verify that libvirt settings are as expected after a VM stop / start ... 
=== TestName: test_02_verify_libvirt_after_restart | Status : SUCCESS ===
ok
Verify that libvirt settings are expected after a disk add ... === 
TestName: test_03_verify_libvirt_attach_disk | Status : SUCCESS ===
ok
Verify that guest sees scsi controller and disks ... === TestName: 
test_04_verify_guest_lspci | Status : SUCCESS ===
ok

--
Ran 4 tests in 658.770s

OK



> Add support for VirtIO-SCSI for KVM hypervisors
> ---
>
> Key: CLOUDSTACK-8239
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8239
> Project: CloudStack
>  Issue Type: New Feature
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: KVM, Storage Controller
>Affects Versions: 4.6.0
> Environment: KVM
>Reporter: Andrei Mikhailovsky
>Assignee: Wido den Hollander
>Priority: Critical
>  Labels: ceph, gsoc2017, kvm, libvirt, rbd, storage_drivers, 
> virtio
> Fix For: Future
>
>
> It would be nice to have support for virtio-scsi for KVM hypervisors.
> The reason for using virtio-scsi instead of virtio-blk would be increasing 
> the number of devices you can attach to a vm, have ability to use discard and 
> reclaim unused blocks from the backend storage like ceph rbd. There are also 
> talks about having a greater performance advantage as well.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (CLOUDSTACK-9809) No Usageid in Volume Usagerecords when detached

[Alexander Stock (JIRA)]

Alexander Stock created CLOUDSTACK-9809:
---

 Summary: No Usageid in Volume Usagerecords when detached
 Key: CLOUDSTACK-9809
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9809
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Usage
Affects Versions: 4.9.0
Reporter: Alexander Stock
 Fix For: Future


Hi,

we discovered some strange behavior with the creation of UsageRecords of 
Volumes which are not attached to a VM. 
There is no  UsageID(UUID of Volume) or the name of the Volume in the records. 

I don't know if this is a bug or if there was some reason for this but for 
billing of these Volumes it would be nice to have these values available.

BR
Alexander



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (CLOUDSTACK-9808) 4.9->4.10 upgrade does not upgrade global settings to point to new template

[Boris Stoyanov (JIRA)]

Boris Stoyanov created CLOUDSTACK-9808:
--

 Summary: 4.9->4.10 upgrade does not upgrade global settings to 
point to new template
 Key: CLOUDSTACK-9808
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9808
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Upgrade
Affects Versions: 4.10.0.0
Reporter: Boris Stoyanov
Priority: Critical


Following the same source of information 
(http://docs.cloudstack.apache.org/projects/cloudstack-release-notes/en/4.10/upgrade/upgrade-4.9.html)
I’ve registered the template with the right naming: "systemvm-kvm-4.10”, waited 
until it was in Ready status.

Then upgraded management and the cloudstack-agent on all hosts. 

Upon starting the management, the DB upgrade was successful. I’ve logged in the 
system and observed that it was still using 4.6.0 ssvm templates. The option to 
upgrade the VR wasn’t available as well. Checking global settings it turns out 
minreq.sysvmtemplate.version = 4.6.0 and router.template.kvm was pointing to 
the original ssmv template (not systemvm-kvm-4.10). The original ssvm template 
is still in active state but it should be in InActive. 

This basically leaves the user unable to upgrade ssvm (which are not working 
btw) without hacking the DB and global settings 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (CLOUDSTACK-9807) 4.5->4.10 upgrade fails. db upgrade script looking for ssvm template-4.6 when having 4.10 already installed.

[Boris Stoyanov (JIRA)]

Boris Stoyanov created CLOUDSTACK-9807:
--

 Summary: 4.5->4.10 upgrade fails. db upgrade script looking for 
ssvm template-4.6 when having 4.10 already installed.
 Key: CLOUDSTACK-9807
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9807
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Upgrade
Affects Versions: 4.10.0.0
Reporter: Boris Stoyanov
Priority: Critical


Following the upgrade instructions from this page: 
http://docs.cloudstack.apache.org/projects/cloudstack-release-notes/en/4.10/upgrade/upgrade-4.5.html

I’ve registered the template with the right naming: "systemvm-kvm-4.10”, waited 
until it was in Ready status.

Then following the upgrade procedure, upgraded the management and the cs-agent. 

Upon starting the management the db.upgrade kicked in, but it failed with the 
following error: 
com.cloud.utils.exception.CloudRuntimeException: 4.6.0KVM SystemVm template not 
found. Cannot upgrade system Vms

It appears that the upgrade script is still looking for 4.6 ssvm template while 
a newer version is installed.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-9175) [VMware DRS] Adding new host to DRS cluster does not participate in load balancing

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9175:


Github user sureshanaparti commented on the issue:

https://github.com/apache/cloudstack/pull/1257
  
@rhtyd Above failures in the test results are not related to the changes in 
this PR.


> [VMware DRS] Adding new host to DRS cluster does not participate in load 
> balancing
> --
>
> Key: CLOUDSTACK-9175
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9175
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server, VMware
>Affects Versions: 4.5.2
>Reporter: Suresh Kumar Anaparti
>Assignee: Suresh Kumar Anaparti
>
> When a new VMware host is added into a cluster, Cloudstack, by default, 
> doesn't create all the port groups present in the cluster. And since it 
> doesn't have all the necessary networking port groups (existing VM's port 
> groups) it is not eligible to participate in DRS load balancing or HA.
> Steps:
> 1. Have a DRS and HA cluster in fully automated mode, with two hosts H1 and 
> H2 created in the vCenter.
> 2. Configure this cluster in Cloudstack and create couple of VMs.
> 3. Start stressing the host by running some cpu hogging scripts in each of 
> the VM.
> 4. Enable maintenance mode on one of the host - say H1 from Cloudstack.
> 5. Also, quickly enable maintenance mode on host H1 from vCenter.
> (This should migrate all the VMs to host H2) Make sure none of the VMs are 
> present on host H1.
> 6. Add host H3 into DRS cluster from vCenter and from Cloudstack as well.
> 7. At this point, the load is definitely imbalanced. This can be verified 
> from vCenter ( Click on cluster -> Go to Summary tab -> under vSphere DRS 
> section, it should show 'Load imbalanced'
> Now, as per DRS rules, the load should be balanced across all the available 
> hosts.
> In this case, even after adding new host, the load is imbalanced. 
> The reason for the load imbalance is VMs (created from Cloudstack) are not 
> eligible to migrate to new host because networks or the cloud portgroups are 
> not available on the new host H3 (except for private).



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-9567) Difference in the api call outputs for CAPACITY_TYPE_CPU = 1

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9567:


Github user yvsubhash commented on the issue:

https://github.com/apache/cloudstack/pull/1734
  
LGTM for the code


> Difference in the api call outputs for CAPACITY_TYPE_CPU = 1
> 
>
> Key: CLOUDSTACK-9567
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9567
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: sudharma jain
>
> The total capacity reported is different, ideally they have to be same
> http://10.223.59.69:8096/client/api?command=listPods=78c23ee6-c585-4065-a03c-08c15492c077=48889c46-dd04-4a50-af06-8aad7ea46f61=true
> 
> 1
> 1042980
> 1621776
> 64.31
> 
> http://10.223.59.69:8096/client/api?command=listCapacity=78c23ee6-c585-4065-a03c-08c15492c077=48889c46-dd04-4a50-af06-8aad7ea46f61=1
> 
> 1
> 
> 1
> 48889c46-dd04-4a50-af06-8aad7ea46f61
> jp2-east01
> 78c23ee6-c585-4065-a03c-08c15492c077
> RG1-ck2ejo2-Pod11
> 1042980
> 2453456
> 42.51
> 
> 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-9567) Difference in the api call outputs for CAPACITY_TYPE_CPU = 1

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9567:


Github user SudharmaJain commented on the issue:

https://github.com/apache/cloudstack/pull/1734
  
Rebased against master.


> Difference in the api call outputs for CAPACITY_TYPE_CPU = 1
> 
>
> Key: CLOUDSTACK-9567
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9567
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: sudharma jain
>
> The total capacity reported is different, ideally they have to be same
> http://10.223.59.69:8096/client/api?command=listPods=78c23ee6-c585-4065-a03c-08c15492c077=48889c46-dd04-4a50-af06-8aad7ea46f61=true
> 
> 1
> 1042980
> 1621776
> 64.31
> 
> http://10.223.59.69:8096/client/api?command=listCapacity=78c23ee6-c585-4065-a03c-08c15492c077=48889c46-dd04-4a50-af06-8aad7ea46f61=1
> 
> 1
> 
> 1
> 48889c46-dd04-4a50-af06-8aad7ea46f61
> jp2-east01
> 78c23ee6-c585-4065-a03c-08c15492c077
> RG1-ck2ejo2-Pod11
> 1042980
> 2453456
> 42.51
> 
> 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-8894) Dynamic scaling is not restricted when destination offering has changes in the vGPU type

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-8894:


Github user cloudmonger commented on the issue:

https://github.com/apache/cloudstack/pull/868
  
### ACS CI BVT Run
 **Sumarry:**
 Build Number 407
 Hypervisor xenserver
 NetworkType Advanced
 Passed=105
 Failed=0
 Skipped=7

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


**Failed tests:**

**Skipped tests:**
test_01_test_vm_volume_snapshot
test_vm_nic_adapter_vmxnet3
test_static_role_account_acls
test_11_ss_nfs_version_on_ssvm
test_nested_virtualization_vmware
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_deploy_vms_with_varied_deploymentplanners.py
test_network.py
test_router_dns.py
test_non_contigiousvlan.py
test_login.py
test_deploy_vm_iso.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_nic.py
test_deploy_vm_root_resize.py
test_resource_detail.py
test_secondary_storage.py
test_vm_life_cycle.py
test_routers_network_ops.py
test_disk_offerings.py


> Dynamic scaling is not restricted when destination offering has changes in 
> the vGPU type
> 
>
> Key: CLOUDSTACK-8894
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8894
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Anshul Gangwar
>Assignee: Anshul Gangwar
>
> Steps:
> 1.Install and configure XenServer 6.5 with vGPU enabled . Enabled dynamic 
> scaliing 
> 2. Deploy VM using K160Q type windows 7 template with PV tools installaed and 
> dynamic scaling enabled 
> 3. Tried dynamic scaling with offering which has K180Q defined.
> Observation: 
> 1. Currently vGPU resource dynamic scaling is not supported. But CloudStack 
> returns success and updating the VM details with new offering details 
> including new vGPU type. 
> 2. But from Xenserver , There is no change with vGPU type and it remains with 
> old vGPU type. This is not correct
> Expected Result:
> Dynamic scaling should be restricted when source/destination offering has 
> vGPU type on a vGPU enabled VM



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-9805) Show VRs in a tab for a network in network detail view

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9805:


Github user koushik-das commented on the issue:

https://github.com/apache/cloudstack/pull/1980
  
Is it only showing VR or other appliances providing service in that 
network? If it is the latter then the tab name is appropriate otherwise it is 
better to name it something like "Virtual Routers" to avoid confusion.
Verify that it is working as expected for RVR, VPC, basic zone network and 
other possible scenarios.


> Show VRs in a tab for a network in network detail view
> --
>
> Key: CLOUDSTACK-9805
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9805
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-8910) The reserved_capacity field increases suddenly after a vmware host failure

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-8910:


Github user sudhansu7 commented on the issue:

https://github.com/apache/cloudstack/pull/892
  
LGTM for code changes.


> The reserved_capacity field increases suddenly after a vmware host failure
> --
>
> Key: CLOUDSTACK-8910
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8910
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: sudharma jain
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-8910) The reserved_capacity field increases suddenly after a vmware host failure

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-8910:


Github user SudharmaJain commented on the issue:

https://github.com/apache/cloudstack/pull/892
  
Rebased against master.


> The reserved_capacity field increases suddenly after a vmware host failure
> --
>
> Key: CLOUDSTACK-8910
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8910
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: sudharma jain
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-9779) Releasing secondary guest IP fails with error VM nic Ip x.x.x.x is mapped to load balancing rule

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9779:


Github user SudharmaJain commented on the issue:

https://github.com/apache/cloudstack/pull/1978
  
LGTM for the code changes. 


> Releasing secondary guest IP fails with error VM nic Ip x.x.x.x is mapped to 
> load balancing rule
> 
>
> Key: CLOUDSTACK-9779
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9779
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Reporter: Nitesh Sarda
>
> ISSUE 
> =
> Releasing secondary guest IP fails with error VM nic Ip x.x.x.x is mapped to 
> load balancing rule
> REPRO STEPS
> ==
> 1. Create two isolated guest networks with same CIDR
> 2. Deploy VMs on both networks
> 3. Acquire secondary IP on NICs of both VMs and make sure they have the same 
> value, user can input the IP address.
> 4. Configure Loadbalancing rule on one of the secondary IP address and try 
> releasing the other secondary IP address.
> 5. The operation would fail
> EXPECTED BEHAVIOR
> ==
> Secondary IP address should be released if there are no LB rules associated 
> with it.
> ACTUAL BEHAVIOR
> ==
> Releasing secondary IP address even if there are no LB rules associated with 
> it.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-9806) Nuage domain template selection per VPC

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9806:


Github user prashanthvarma commented on the issue:

https://github.com/apache/cloudstack/pull/1981
  
PEP8 & PyFlakes compliance of our marvin test code:

CloudStack$
CloudStack$ pep8 test/integration/plugins/nuagevsp/.py
CloudStack$
CloudStack$ pyflakes test/integration/plugins/nuagevsp/.py
CloudStack$

Validations:

Marvin test results:

nosetests --with-marvin --marvin-config=nuage.cfg 
nuagevsp/test_nuage_vsp_domain_template.py

Test Nuage VSP Domain Template selection per VPC ... === TestName: 
test_01_nuage_Domain_Template_selection_per_VPC | Status : SUCCESS ===
ok
Test Nuage VSP Domain Template selection per VPC as ROOT domain ... === 
TestName: test_02_nuage_Domain_Template_selection_per_VPC_as_ROOT_user | Status 
: SUCCESS ===
ok
Test Nuage VSP Domain Template selection per VPC as domain admin ... === 
TestName: test_03_nuage_Domain_Template_selection_per_VPC_as_domain_admin | 
Status : SUCCESS ===
ok
Test Nuage VSP Domain Template selection per VPC as domain ... === 
TestName: test_04_nuage_Domain_Template_selection_per_VPC_as_domain_user | 
Status : SUCCESS ===
ok
Test Nuage VSP Domain Template selection per VPC as subdomain admin ... === 
TestName: test_05_nuage_Domain_Template_selection_per_VPC_as_subdom_admin | 
Status : SUCCESS ===
ok
Test Nuage VSP Domain Template selection per VPC as subdomain ... === 
TestName: test_06_nuage_Domain_Template_selection_per_VPC_as_subdom_user | 
Status : SUCCESS ===
ok
Test Nuage VSP Global Domain Template ... === TestName: 
test_07_nuage_Global_Domain_Template | Status : SUCCESS ===
ok
Test Nuage VSP Global Domain Template as ROOT domain regular user ... === 
TestName: test_08_nuage_Global_Domain_Template_as_ROOT_user | Status : SUCCESS 
===
ok
Test Nuage VSP Global Domain Template as domain admin user ... === 
TestName: test_09_nuage_Global_Domain_Template_as_domain_admin | Status : 
SUCCESS ===
ok
Test Nuage VSP Global Domain Template as domain regular user ... === 
TestName: test_10_nuage_Global_Domain_Template_as_domain_user | Status : 
SUCCESS ===
ok
Test Nuage VSP Global Domain Template as subdomain admin user ... === 
TestName: test_11_nuage_Global_Domain_Template_as_subdomain_admin | Status : 
SUCCESS ===
ok
Test Nuage VSP Global Domain Template as subdomain regular user ... === 
TestName: test_12_nuage_Global_Domain_Template_as_subdomain_user | Status : 
SUCCESS ===
ok

--
Ran 12 tests in 6203.613s

OK


[results.txt](https://github.com/apache/cloudstack/files/810482/results.txt)
[runinfo.txt](https://github.com/apache/cloudstack/files/810483/runinfo.txt)



> Nuage domain template selection per VPC
> ---
>
> Key: CLOUDSTACK-9806
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9806
> Project: CloudStack
>  Issue Type: New Feature
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Reporter: Sigert Goeminne
>Assignee: Sigert Goeminne
>
> When deploying CloudStack with Nuage VSP (Virtualized Services 
> Plugin/Platform), the Cloud/Network Administrator has the ability to define 
> “Domain Templates” in the Nuage VSP Platform and reuse (and instantiate) 
> those when creating networks inside CloudStack. This allows for predefining 
> advanced networking topologies in the SDN platform, and integrate those 
> seamlessly within the CloudStack workflows, without the need of porting all 
> those SDN capabilities (e.g. GRT leaking, Advanced ACL’s, Service Chaining, 
> ...) into CloudStack.
> Today this mechanism works via global settings and allows for one Nuage VSP 
> Domain Template to be specified per CloudStack Network type (Shared, 
> Isolated, VPC). This is fine for most deployments but it doesn’t leave room 
> for hybrid deployments in which different CloudStack networks need 
> individually differentiated SDN capabilities. Especially for VPC’s it would 
> be nice to have finer grained domain template control.
> With the proposed new features, we add the ability to configure a domain 
> template per VPC, i.e. each VPC created in CloudStack can be configured with 
> a different domain template. We will make this option accessible through the 
> UI also, but applicable to Nuage supporting zones only.
> [Design 
> Document|https://cwiki.apache.org/confluence/display/CLOUDSTACK/Nuage+domain+template+selection+per+VPC]



--
This message was sent by Atlassian JIRA

[jira] [Commented] (CLOUDSTACK-9805) Show VRs in a tab for a network in network detail view

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9805:


Github user rhtyd commented on the issue:

https://github.com/apache/cloudstack/pull/1980
  
@PaulAngus @ustcweizhou fixed now, the tab is displayed only to admins.


> Show VRs in a tab for a network in network detail view
> --
>
> Key: CLOUDSTACK-9805
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9805
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-9806) Nuage domain template selection per VPC

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9806:


Github user prashanthvarma commented on the issue:

https://github.com/apache/cloudstack/pull/1981
  
Design document for this feature: 
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Nuage+domain+template+selection+per+VPC


> Nuage domain template selection per VPC
> ---
>
> Key: CLOUDSTACK-9806
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9806
> Project: CloudStack
>  Issue Type: New Feature
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Reporter: Sigert Goeminne
>Assignee: Sigert Goeminne
>
> When deploying CloudStack with Nuage VSP (Virtualized Services 
> Plugin/Platform), the Cloud/Network Administrator has the ability to define 
> “Domain Templates” in the Nuage VSP Platform and reuse (and instantiate) 
> those when creating networks inside CloudStack. This allows for predefining 
> advanced networking topologies in the SDN platform, and integrate those 
> seamlessly within the CloudStack workflows, without the need of porting all 
> those SDN capabilities (e.g. GRT leaking, Advanced ACL’s, Service Chaining, 
> ...) into CloudStack.
> Today this mechanism works via global settings and allows for one Nuage VSP 
> Domain Template to be specified per CloudStack Network type (Shared, 
> Isolated, VPC). This is fine for most deployments but it doesn’t leave room 
> for hybrid deployments in which different CloudStack networks need 
> individually differentiated SDN capabilities. Especially for VPC’s it would 
> be nice to have finer grained domain template control.
> With the proposed new features, we add the ability to configure a domain 
> template per VPC, i.e. each VPC created in CloudStack can be configured with 
> a different domain template. We will make this option accessible through the 
> UI also, but applicable to Nuage supporting zones only.
> [Design 
> Document|https://cwiki.apache.org/confluence/display/CLOUDSTACK/Nuage+domain+template+selection+per+VPC]



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-9806) Nuage domain template selection per VPC

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9806:


GitHub user prashanthvarma opened a pull request:

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

CLOUDSTACK-9806: Nuage domain template selection per VPC

Co-Authored-By: Prashanth Manthena 
Co-Authored-By: Frank Maximus 

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

$ git pull https://github.com/nuagenetworks/cloudstack 
feature/nuage_vpc_selectable_domain_template

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

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


commit 55ce0d91805fc4807952ead3f8160eae589038ab
Author: Sigert Goeminne 
Date:   2016-10-06T12:30:59Z

CLOUDSTACK-9806: Nuage domain template selection per VPC

Co-Authored-By: Prashanth Manthena 
Co-Authored-By: Frank Maximus 




> Nuage domain template selection per VPC
> ---
>
> Key: CLOUDSTACK-9806
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9806
> Project: CloudStack
>  Issue Type: New Feature
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Reporter: Sigert Goeminne
>Assignee: Sigert Goeminne
>
> When deploying CloudStack with Nuage VSP (Virtualized Services 
> Plugin/Platform), the Cloud/Network Administrator has the ability to define 
> “Domain Templates” in the Nuage VSP Platform and reuse (and instantiate) 
> those when creating networks inside CloudStack. This allows for predefining 
> advanced networking topologies in the SDN platform, and integrate those 
> seamlessly within the CloudStack workflows, without the need of porting all 
> those SDN capabilities (e.g. GRT leaking, Advanced ACL’s, Service Chaining, 
> ...) into CloudStack.
> Today this mechanism works via global settings and allows for one Nuage VSP 
> Domain Template to be specified per CloudStack Network type (Shared, 
> Isolated, VPC). This is fine for most deployments but it doesn’t leave room 
> for hybrid deployments in which different CloudStack networks need 
> individually differentiated SDN capabilities. Especially for VPC’s it would 
> be nice to have finer grained domain template control.
> With the proposed new features, we add the ability to configure a domain 
> template per VPC, i.e. each VPC created in CloudStack can be configured with 
> a different domain template. We will make this option accessible through the 
> UI also, but applicable to Nuage supporting zones only.
> [Design 
> Document|https://cwiki.apache.org/confluence/display/CLOUDSTACK/Nuage+domain+template+selection+per+VPC]



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-9567) Difference in the api call outputs for CAPACITY_TYPE_CPU = 1

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9567:


Github user SudharmaJain commented on the issue:

https://github.com/apache/cloudstack/pull/1734
  
@jburwell As suggested, I have added a marvin test case to verify the fix. 
Should I add it to smoke test suite.


> Difference in the api call outputs for CAPACITY_TYPE_CPU = 1
> 
>
> Key: CLOUDSTACK-9567
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9567
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: sudharma jain
>
> The total capacity reported is different, ideally they have to be same
> http://10.223.59.69:8096/client/api?command=listPods=78c23ee6-c585-4065-a03c-08c15492c077=48889c46-dd04-4a50-af06-8aad7ea46f61=true
> 
> 1
> 1042980
> 1621776
> 64.31
> 
> http://10.223.59.69:8096/client/api?command=listCapacity=78c23ee6-c585-4065-a03c-08c15492c077=48889c46-dd04-4a50-af06-8aad7ea46f61=1
> 
> 1
> 
> 1
> 48889c46-dd04-4a50-af06-8aad7ea46f61
> jp2-east01
> 78c23ee6-c585-4065-a03c-08c15492c077
> RG1-ck2ejo2-Pod11
> 1042980
> 2453456
> 42.51
> 
> 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (CLOUDSTACK-9806) Nuage domain template selection per VPC

[Sigert Goeminne (JIRA)]

Sigert Goeminne created CLOUDSTACK-9806:
---

 Summary: Nuage domain template selection per VPC
 Key: CLOUDSTACK-9806
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9806
 Project: CloudStack
  Issue Type: New Feature
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: UI
Reporter: Sigert Goeminne
Assignee: Sigert Goeminne


When deploying CloudStack with Nuage VSP (Virtualized Services 
Plugin/Platform), the Cloud/Network Administrator has the ability to define 
“Domain Templates” in the Nuage VSP Platform and reuse (and instantiate) those 
when creating networks inside CloudStack. This allows for predefining advanced 
networking topologies in the SDN platform, and integrate those seamlessly 
within the CloudStack workflows, without the need of porting all those SDN 
capabilities (e.g. GRT leaking, Advanced ACL’s, Service Chaining, ...) into 
CloudStack.
Today this mechanism works via global settings and allows for one Nuage VSP 
Domain Template to be specified per CloudStack Network type (Shared, Isolated, 
VPC). This is fine for most deployments but it doesn’t leave room for hybrid 
deployments in which different CloudStack networks need individually 
differentiated SDN capabilities. Especially for VPC’s it would be nice to have 
finer grained domain template control.
With the proposed new features, we add the ability to configure a domain 
template per VPC, i.e. each VPC created in CloudStack can be configured with a 
different domain template. We will make this option accessible through the UI 
also, but applicable to Nuage supporting zones only.

[Design 
Document|https://cwiki.apache.org/confluence/display/CLOUDSTACK/Nuage+domain+template+selection+per+VPC]



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-9611) Dedicating a Guest VLAN range to Project does not work

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9611:


Github user nitin-maharana commented on the issue:

https://github.com/apache/cloudstack/pull/1771
  
@ustcweizhou : I have modified the code, can you review it one more time. 
Please see the below snapshot.

https://cloud.githubusercontent.com/assets/12583725/23455743/b4d7be00-fe96-11e6-8a41-398c41f6d019.png;>


> Dedicating a Guest VLAN range to Project does not work
> --
>
> Key: CLOUDSTACK-9611
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9611
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Nitin Kumar Maharana
>
> Trying to dedicate a guest VLAN range to an account fails. If we pass both 
> account and projectid parameters to the dedicateGuestVlanRange (which are not 
> mentioned as mutually exclusive in API description) the API layer throws 
> error saying both are mutually exclusive.
> Steps to Reproduce:
> 
> Create an account. Create a project in that account.
> Go to admin account and change view to the above project.
> Navigate to Infrastructure -> Zone -> Physical Network -> Guest -> Dedicate 
> Guest VLAN range.
> Try to dedicate the guest VLAN range from the project view for the account 
> associated with the project.
> It fails with Error saying accountName and projectId are mutually exclusive.
> Expected:
> 
> The VLAN range should get dedicated to the project account.
> Notes:
> =
> If we do the dedication from default view then it works fine as no projectid 
> is associated over there.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (CLOUDSTACK-9805) Show VRs in a tab for a network in network detail view

[Rohit Yadav (JIRA)]

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

Rohit Yadav updated CLOUDSTACK-9805:

Status: Reviewable  (was: In Progress)

> Show VRs in a tab for a network in network detail view
> --
>
> Key: CLOUDSTACK-9805
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9805
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-9805) Show VRs in a tab for a network in network detail view

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9805:


Github user ustcweizhou commented on the issue:

https://github.com/apache/cloudstack/pull/1980
  
tested. LGTM


> Show VRs in a tab for a network in network detail view
> --
>
> Key: CLOUDSTACK-9805
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9805
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-9198) VR gets created in the disabled POD

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9198:


Github user abhinandanprateek commented on the issue:

https://github.com/apache/cloudstack/pull/1278
  
@anshul1886 @koushik-das I think with above info the fix looks good.

LGTM.


> VR gets created in the disabled POD
> ---
>
> Key: CLOUDSTACK-9198
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9198
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Anshul Gangwar
>Assignee: Anshul Gangwar
>
> VR gets created in the disabled POD



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-9198) VR gets created in the disabled POD

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9198:


Github user anshul1886 commented on the issue:

https://github.com/apache/cloudstack/pull/1278
  
@abhinandanprateek @koushik-das That change is intentional to allow admin 
users to deploy VM on disabled. Ticket which shows that it is intentional  
https://issues.apache.org/jira/browse/CLOUDSTACK-7047.


> VR gets created in the disabled POD
> ---
>
> Key: CLOUDSTACK-9198
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9198
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Anshul Gangwar
>Assignee: Anshul Gangwar
>
> VR gets created in the disabled POD



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-9317) Disabling static NAT on many IPs can leave wrong IPs on the router

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9317:


Github user ProjectMoon commented on the issue:

https://github.com/apache/cloudstack/pull/1908
  
@jayapalu Quite possible, yes. It could be fixed by adding another 
condition to the check that was added with #1907. It could also be "fixed" by 
checkiing if `configured()` returns `True` in the `arpPing()` method of the 
`CsIp` class. But I'm guessing that it doesn't get properly deleted from the 
DataBag when it's removed from the router. Thus it just gets written to 
`/etc/cloudstack/ips.json` again.


> Disabling static NAT on many IPs can leave wrong IPs on the router
> --
>
> Key: CLOUDSTACK-9317
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9317
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server, Virtual Router
>Affects Versions: 4.7.0, 4.7.1, 4.7.2
>Reporter: Jeff Hair
>
> The current behavior of enabling or disabling static NAT will call the apply 
> IP associations method in the management server. The method is not 
> thread-safe. If it's called from multiple threads, each thread will load up 
> the list of public IPs in different states (add or revoke)--correct for the 
> thread, but not correct overall. Depending on execution order on the virtual 
> router, the router can end up with public IPs assigned to it that are not 
> supposed to be on it anymore. When another account acquires the same IP, this 
> of course leads to network problems.
> The problem has been in CS since at least 4.2, and likely affects all 
> recently released versions. Affected version is set to 4.7.x because that's 
> what we verified against.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-9805) Show VRs in a tab for a network in network detail view

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9805:


Github user rhtyd commented on the issue:

https://github.com/apache/cloudstack/pull/1980
  
@ustcweizhou @PaulAngus sure, I can add a tab filter to allow only admins 
to see this. Right now, whoever can see the network tab(s) can see this tab 
too. I'll fix this asap.


> Show VRs in a tab for a network in network detail view
> --
>
> Key: CLOUDSTACK-9805
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9805
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-9608) Errored State and Abandoned state Templates are not displayed on UI

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9608:


Github user priyankparihar commented on the issue:

https://github.com/apache/cloudstack/pull/1774
  
@borisstoyanov Could you please provide management server log for analyzing 
this failure ?


> Errored State and Abandoned state Templates are not displayed on UI
> ---
>
> Key: CLOUDSTACK-9608
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9608
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Priyank Parihar
>Assignee: Priyank Parihar
>
> Errored and Abandoned Templates should also be displayed on UI so that user 
> has the accessibility to delete the template even before the clean up thread 
> is run.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-9607) Preventing template deletion when template is in use.

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9607:


Github user ustcweizhou commented on the issue:

https://github.com/apache/cloudstack/pull/1773
  
LGTM


> Preventing template deletion when template is in use.
> -
>
> Key: CLOUDSTACK-9607
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9607
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Priyank Parihar
>Assignee: Priyank Parihar
>
> Consider this scenario:
> 1. User launches a VM from Template and keep it running
> 2. Admin logins and deleted that template [CloudPlatform does not check 
> existing / running VM etc. while the deletion is done]
> 3. User resets the VM
> 4. CloudPlatform fails to star the VM as it cannot find the corresponding 
> template.
> It throws error as 
> java.lang.RuntimeException: Job failed due to exception Resource [Host:11] is 
> unreachable: Host 11: Unable to start instance due to can't find ready 
> template: 209 for data center 1
> at 
> com.cloud.vm.VmWorkJobDispatcher.runJob(VmWorkJobDispatcher.java:113)
> at 
> org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:495)
> Client is requesting better handing of this scenario. We need to check 
> existing / running VM's when the template is deleted and warn admin about the 
> possible issue that may occur.
> REPRO STEPS
> ==
> 1. Launches a VM from Template and keep it running
> 2. Now delete that template 
> 3. Reset the VM
> 4. CloudPlatform fails to star the VM as it cannot find the corresponding 
> template.
> EXPECTED BEHAVIOR
> ==
> Cloud platform should throw some warning message while the template is 
> deleted if that template is being used by existing / running VM's
> ACTUAL BEHAVIOR
> ==
> Cloud platform does not throw as waring etc.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-9805) Show VRs in a tab for a network in network detail view

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9805:


Github user ustcweizhou commented on the issue:

https://github.com/apache/cloudstack/pull/1980
  
is there any issue for normal users ?



> Show VRs in a tab for a network in network detail view
> --
>
> Key: CLOUDSTACK-9805
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9805
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-9805) Show VRs in a tab for a network in network detail view

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9805:


Github user PaulAngus commented on the issue:

https://github.com/apache/cloudstack/pull/1980
  
Who (user type) has visibility tab of this tab?
can it be hidden ? many service providers **_may_** not want users to see 
this.


> Show VRs in a tab for a network in network detail view
> --
>
> Key: CLOUDSTACK-9805
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9805
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-9611) Dedicating a Guest VLAN range to Project does not work

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9611:


Github user nitin-maharana commented on the issue:

https://github.com/apache/cloudstack/pull/1771
  
@ustcweizhou : You are correct. We have to remove the domain scope. If we 
support the domain scope, we need more changes on the logic. In that case we 
can create a new ticket for that. 


> Dedicating a Guest VLAN range to Project does not work
> --
>
> Key: CLOUDSTACK-9611
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9611
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Nitin Kumar Maharana
>
> Trying to dedicate a guest VLAN range to an account fails. If we pass both 
> account and projectid parameters to the dedicateGuestVlanRange (which are not 
> mentioned as mutually exclusive in API description) the API layer throws 
> error saying both are mutually exclusive.
> Steps to Reproduce:
> 
> Create an account. Create a project in that account.
> Go to admin account and change view to the above project.
> Navigate to Infrastructure -> Zone -> Physical Network -> Guest -> Dedicate 
> Guest VLAN range.
> Try to dedicate the guest VLAN range from the project view for the account 
> associated with the project.
> It fails with Error saying accountName and projectId are mutually exclusive.
> Expected:
> 
> The VLAN range should get dedicated to the project account.
> Notes:
> =
> If we do the dedication from default view then it works fine as no projectid 
> is associated over there.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-9611) Dedicating a Guest VLAN range to Project does not work

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9611:


Github user ustcweizhou commented on the issue:

https://github.com/apache/cloudstack/pull/1771
  
@nitin-maharana I thought dedicating guest vlan range is already 
implemented in CLOUDSTACK-8958.
Actually they are two stories.
In this case, we have to remove the Domain scope from UI as it is not 
supported, unless you make more changes to support it (similar to 
37301ed4540450c29be4f975d58b38dbeec6c296 for CLOUDSTACK-8958).


> Dedicating a Guest VLAN range to Project does not work
> --
>
> Key: CLOUDSTACK-9611
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9611
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Nitin Kumar Maharana
>
> Trying to dedicate a guest VLAN range to an account fails. If we pass both 
> account and projectid parameters to the dedicateGuestVlanRange (which are not 
> mentioned as mutually exclusive in API description) the API layer throws 
> error saying both are mutually exclusive.
> Steps to Reproduce:
> 
> Create an account. Create a project in that account.
> Go to admin account and change view to the above project.
> Navigate to Infrastructure -> Zone -> Physical Network -> Guest -> Dedicate 
> Guest VLAN range.
> Try to dedicate the guest VLAN range from the project view for the account 
> associated with the project.
> It fails with Error saying accountName and projectId are mutually exclusive.
> Expected:
> 
> The VLAN range should get dedicated to the project account.
> Notes:
> =
> If we do the dedication from default view then it works fine as no projectid 
> is associated over there.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-9198) VR gets created in the disabled POD

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9198:


Github user abhinandanprateek commented on the issue:

https://github.com/apache/cloudstack/pull/1278
  
@koushik-das @anshul1886 If we allow admin to deploy resources on disabled 
resources then this fix is fine. Even with the fix a non admin user will be 
able to restart a VM on a disabled resource, so limited by that. Boils down to 
definition of disabled.
I had done a fix in past that will prevent deployment on disabled pods even 
for admin, created a Pr for that now, check this out too: 
https://github.com/apache/cloudstack/pull/1979/files. I think it just boils 
down to the definition of disabled.


> VR gets created in the disabled POD
> ---
>
> Key: CLOUDSTACK-9198
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9198
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Anshul Gangwar
>Assignee: Anshul Gangwar
>
> VR gets created in the disabled POD



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-9805) Show VRs in a tab for a network in network detail view

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9805:


GitHub user rhtyd opened a pull request:

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

CLOUDSTACK-9805: Display VR list in network details

![screenshot from 2017-03-01 
14-52-26](https://cloud.githubusercontent.com/assets/95203/23453709/64f31f8a-fe8f-11e6-8281-a06e27bf3a14.png)

Displays a VR tab that lists VRs for the network in the detail views. This 
has come up several times, and useful for admins when they want to 
reboot/destroy or view VR associated with a network.

Pinging for review - @abhinandanprateek @borisstoyanov @DaanHoogland 
@PaulAngus @karuturi @koushik-das 

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

$ git pull https://github.com/shapeblue/cloudstack vr-ui-tab

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

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


commit 20d16c8c272faaf78a17d64f2e4a129f45504775
Author: Rohit Yadav 
Date:   2017-03-01T09:22:13Z

CLOUDSTACK-9805: Display VR list in network details

Displays a VR tab that lists VRs for the network in the detail views

Signed-off-by: Rohit Yadav 




> Show VRs in a tab for a network in network detail view
> --
>
> Key: CLOUDSTACK-9805
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9805
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (CLOUDSTACK-9805) Show VRs in a tab for a network in network detail view

[Rohit Yadav (JIRA)]

Rohit Yadav created CLOUDSTACK-9805:
---

 Summary: Show VRs in a tab for a network in network detail view
 Key: CLOUDSTACK-9805
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9805
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
Reporter: Rohit Yadav
Assignee: Rohit Yadav






--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-9604) Root disk resize support for VMware and XenServer

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9604:


Github user borisstoyanov commented on the issue:

https://github.com/apache/cloudstack/pull/1813
  
It's a NPE
```
2017-03-01 09:18:09,343 INFO  [c.c.h.v.r.VmwareResource] 
(DirectAgentCronJob-70:ctx-46e74661) (logid:9541e85e) Scan hung worker VM to 
recycle
2017-03-01 09:18:09,399 DEBUG [c.c.a.m.DirectAgentAttache] 
(DirectAgentCronJob-70:ctx-46e74661) (logid:9541e85e) Ping from 2(10.2.2.88)
2017-03-01 09:18:09,399 DEBUG [c.c.v.VirtualMachinePowerStateSyncImpl] 
(DirectAgentCronJob-70:ctx-46e74661) (logid:9541e85e) Process host VM state 
report from ping process. host: 2
2017-03-01 09:18:09,403 DEBUG [c.c.v.VirtualMachinePowerStateSyncImpl] 
(DirectAgentCronJob-70:ctx-46e74661) (logid:9541e85e) Process VM state report. 
host: 2, number of records in report: 2
2017-03-01 09:18:09,403 DEBUG [c.c.v.VirtualMachinePowerStateSyncImpl] 
(DirectAgentCronJob-70:ctx-46e74661) (logid:9541e85e) VM state report. host: 2, 
vm id: 1, power state: PowerOn
2017-03-01 09:18:09,405 DEBUG [c.c.v.VirtualMachinePowerStateSyncImpl] 
(DirectAgentCronJob-70:ctx-46e74661) (logid:9541e85e) VM power state does not 
change, skip DB writing. vm id: 1
2017-03-01 09:18:09,405 DEBUG [c.c.v.VirtualMachinePowerStateSyncImpl] 
(DirectAgentCronJob-70:ctx-46e74661) (logid:9541e85e) VM state report. host: 2, 
vm id: 2, power state: PowerOn
2017-03-01 09:18:09,407 DEBUG [c.c.v.VirtualMachinePowerStateSyncImpl] 
(DirectAgentCronJob-70:ctx-46e74661) (logid:9541e85e) VM power state does not 
change, skip DB writing. vm id: 2
2017-03-01 09:18:09,409 DEBUG [c.c.v.VirtualMachinePowerStateSyncImpl] 
(DirectAgentCronJob-70:ctx-46e74661) (logid:9541e85e) Done with process of VM 
state report. host: 2
2017-03-01 09:18:10,686 DEBUG [c.c.s.StatsCollector] 
(StatsCollector-3:ctx-7fe352c2) (logid:5171a11d) 
HostOutOfBandManagementStatsCollector is running...
2017-03-01 09:18:11,018 DEBUG [c.c.a.m.AgentManagerImpl] 
(AgentManager-Handler-11:null) (logid:) SeqA 3-119: Processing Seq 3-119:  { 
Cmd , MgmtId: -1, via: 3, Ver: v1, Flags: 11, 
[{"com.cloud.agent.api.ConsoleProxyLoadReportCommand":{"_proxyVmId":1,"_loadInfo":"{\n
  \"connections\": []\n}","wait":0}}] }
2017-03-01 09:18:11,023 DEBUG [c.c.a.m.AgentManagerImpl] 
(AgentManager-Handler-11:null) (logid:) SeqA 3-119: Sending Seq 3-119:  { Ans: 
, MgmtId: 7222893545287, via: 3, Ver: v1, Flags: 100010, 
[{"com.cloud.agent.api.AgentControlAnswer":{"result":true,"wait":0}}] }
2017-03-01 09:18:11,571 DEBUG [c.c.a.m.AgentManagerImpl] 
(AgentManager-Handler-10:null) (logid:) Ping from 4(s-2-VM)
2017-03-01 09:18:11,755 DEBUG [c.c.a.m.AgentManagerImpl] 
(AgentManager-Handler-14:null) (logid:) Ping from 3(v-1-VM)
^[[1;9D2017-03-01 09:18:14,974 INFO  [o.a.c.f.j.i.AsyncJobManagerImpl] 
(AsyncJobMgr-Heartbeat-1:ctx-d9c806b4) (logid:1458d11b) Begin cleanup expired 
async-jobs
2017-03-01 09:18:14,980 INFO  [o.a.c.f.j.i.AsyncJobManagerImpl] 
(AsyncJobMgr-Heartbeat-1:ctx-d9c806b4) (logid:1458d11b) End cleanup expired 
async-jobs
2017-03-01 09:18:15,320 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl] 
(RouterStatusMonitor-1:ctx-4ff63676) (logid:883b6d34) Found 0 routers to update 
status.
2017-03-01 09:18:15,321 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl] 
(RouterStatusMonitor-1:ctx-4ff63676) (logid:883b6d34) Found 0 VPC networks to 
update Redundant State.
2017-03-01 09:18:15,322 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl] 
(RouterStatusMonitor-1:ctx-4ff63676) (logid:883b6d34) Found 0 networks to 
update RvR status.
2017-03-01 09:18:15,687 DEBUG [c.c.s.StatsCollector] 
(StatsCollector-3:ctx-0dd9) (logid:51552762) 
HostOutOfBandManagementStatsCollector is running...
2017-03-01 09:18:17,306 DEBUG [c.c.a.ApiServlet] 
(catalina-exec-7:ctx-353f8336) (logid:0d215557) ===START===  10.5.0.15 -- GET  
apiKey=LIN6rqXuaJwMPfGYFh13qDwYz5VNNz1J2J6qIOWcd3oLQOq0WtD4CwRundBL6rzXToa3lQOC_vKjI3nkHtiD8Q=listDomains=taHWwbdB2MfrjDaU2iur%2FdKK3ew%3D=json
2017-03-01 09:18:17,321 DEBUG [c.c.a.ApiServlet] 
(catalina-exec-7:ctx-353f8336 ctx-ac65f9a7 ctx-2f0b4e99) (logid:0d215557) 
===END===  10.5.0.15 -- GET  
apiKey=LIN6rqXuaJwMPfGYFh13qDwYz5VNNz1J2J6qIOWcd3oLQOq0WtD4CwRundBL6rzXToa3lQOC_vKjI3nkHtiD8Q=listDomains=taHWwbdB2MfrjDaU2iur%2FdKK3ew%3D=json
2017-03-01 09:18:17,328 DEBUG [c.c.a.ApiServlet] 
(catalina-exec-6:ctx-3f88e3d1) (logid:b5e4e800) ===START===  10.5.0.15 -- GET  
apiKey=LIN6rqXuaJwMPfGYFh13qDwYz5VNNz1J2J6qIOWcd3oLQOq0WtD4CwRundBL6rzXToa3lQOC_vKjI3nkHtiD8Q=pr1813-t920-vmware-60u2=listZones=2WSEhLiR742m7RumG99EfWta9xU%3D=json
2017-03-01 09:18:17,339 DEBUG [c.c.a.ApiServlet] 
(catalina-exec-6:ctx-3f88e3d1 ctx-e7fcbc14 ctx-77e33e86) (logid:b5e4e800) 

[jira] [Commented] (CLOUDSTACK-9611) Dedicating a Guest VLAN range to Project does not work

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9611:


Github user nitin-maharana commented on the issue:

https://github.com/apache/cloudstack/pull/1771
  
@ustcweizhou : Passing project with domain won't create any issue but not 
passing any account details when we call the API from default view creates an 
issue. Because the internal logic expects account owner of VLAN when dedicated 
from the default view. In the case of project view, it gets the account detail 
from selected project.


> Dedicating a Guest VLAN range to Project does not work
> --
>
> Key: CLOUDSTACK-9611
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9611
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Nitin Kumar Maharana
>
> Trying to dedicate a guest VLAN range to an account fails. If we pass both 
> account and projectid parameters to the dedicateGuestVlanRange (which are not 
> mentioned as mutually exclusive in API description) the API layer throws 
> error saying both are mutually exclusive.
> Steps to Reproduce:
> 
> Create an account. Create a project in that account.
> Go to admin account and change view to the above project.
> Navigate to Infrastructure -> Zone -> Physical Network -> Guest -> Dedicate 
> Guest VLAN range.
> Try to dedicate the guest VLAN range from the project view for the account 
> associated with the project.
> It fails with Error saying accountName and projectId are mutually exclusive.
> Expected:
> 
> The VLAN range should get dedicated to the project account.
> Notes:
> =
> If we do the dedication from default view then it works fine as no projectid 
> is associated over there.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-9198) VR gets created in the disabled POD

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9198:


GitHub user abhinandanprateek opened a pull request:

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

CLOUDSTACK-9198: Donot allow VMs to be deplyed on host that are in di…

…sabled pod


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

$ git pull https://github.com/shapeblue/cloudstack CLOUDSTACK-9198

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

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


commit c7ba2124bbfd03ca2835b5b1affc8fc876fb4154
Author: Abhinandan Prateek 
Date:   2017-01-13T08:07:42Z

CLOUDSTACK-9198: Donot allow VMs to be deplyed on host that are in disabled 
pod

Signed-off-by: Abhinandan Prateek 




> VR gets created in the disabled POD
> ---
>
> Key: CLOUDSTACK-9198
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9198
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Anshul Gangwar
>Assignee: Anshul Gangwar
>
> VR gets created in the disabled POD



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-8897) baremetal:addHost:make host tag info mandtory in baremetal addhost Api call

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-8897:


Github user harikrishna-patnala commented on the issue:

https://github.com/apache/cloudstack/pull/874
  
I have updated the PR based on the comments. Please review.


> baremetal:addHost:make host tag info mandtory in baremetal addhost Api call
> ---
>
> Key: CLOUDSTACK-8897
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8897
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Baremetal, Management Server
>Reporter: Harikrishna Patnala
>Assignee: Harikrishna Patnala
> Fix For: 4.9.1.0
>
>
> Right now in baremetal, addhost api is successful with out providing the host 
> tag info and we recommend host tag is mandatory for bare-metal.
> in the current implementation host tag check is happening at vm deployment 
> stage but it will be good to have host tag field as mandatory field during 
> adding of the host it self.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-9604) Root disk resize support for VMware and XenServer

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9604:


Github user borisstoyanov commented on the issue:

https://github.com/apache/cloudstack/pull/1813
  
@serg38 Unfortunately the instances are being expunged right after tests 
are complete. I can create an env manually and run the root_resize test for 
you. Will keep you posted. 


> Root disk resize support for VMware and XenServer
> -
>
> Key: CLOUDSTACK-9604
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9604
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Priyank Parihar
>Assignee: Priyank Parihar
> Attachments: 1.png, 2.png, 3.png
>
>
> Currently the root size of an instance is locked to that of the template. 
> This creates unnecessary template duplicates, prevents the creation of a 
> market place, wastes time and disk space and generally makes work more 
> complicated.
> Real life example - a small VPS provider might want to offer the following 
> sizes (in GB):
> 10,20,40,80,160,240,320,480,620
> That's 9 offerings.
> The template selection could look like this, including real disk space used:
> Windows 2008 ~10GB
> Windows 2008+Plesk ~15GB
> Windows 2008+MSSQL ~15GB
> Windows 2012 ~10GB
> Windows 2012+Plesk ~15GB
> Windows 2012+MSSQL ~15GB
> CentOS ~1GB
> CentOS+CPanel ~3GB
> CentOS+Virtualmin ~3GB
> CentOS+Zimbra ~3GB
> CentOS+Docker ~2GB
> Debian ~1GB
> Ubuntu LTS ~1GB
> In this case the total disk space used by templates will be 828 GB, that's 
> almost 1 TB. If your storage is expensive and limited SSD this can get 
> painful!
> If the root resize feature is enabled we can reduce this to under 100 GB.
> Specifications and Description 
> Administrators don't want to deploy duplicate OS templates of differing 
> sizes just to support different storage packages. Instead, the VM deployment 
> can accept a size for the root disk and adjust the template clone 
> accordingly. In addition, CloudStack already supports data disk resizing for 
> existing volumes, we can extend that functionality to resize existing root 
> disks. 
>   As mentioned, we can leverage the existing design for resizing an existing 
> volume. The difference with root volumes is that we can't resize via disk 
> offering, therefore we need to verify that no disk offering was passed, just 
> a size. The existing enforcements of new size > existing size will still 
> server their purpose.
>For deployment-based resize (ROOT volume size different from template 
> size), we pass the rootdisksize parameter when the existing code allocates 
> the root volume. In the process, we validate that the root disk size is > 
> existing template size, and non-zero. This will persist the root volume as 
> the desired size regardless of whether or not the VM is started on deploy. 
> Then hypervisor specific code needs to be made to pay attention to the 
> VolumeObjectTO's size attribute and use that when doing the work of cloning 
> from template, rather than inheriting the template's size. This can be 
> implemented one hypervisor at a time, and as such there needs to be a check 
> in UserVmManagerImpl to fail unsupported hypervisors with 
> InvalidParameterValueException when the rootdisksize is passed.
>
> Hypervisor specific changes
> XenServer
> Resize ROOT volume is only supported for stopped VMs
> Newly created ROOT volume will be resized after clone from template
> VMware  
> Resize ROOT volume is only supported for stopped VMs.
> New size should be large then the previous size.
> Newly created ROOT volume will be resized after clone from template iff
>  There is no root disk chaining.(means use Full clone)
> And Root Disk controller setting is not  IDE.
> Previously created Root Volume could be resized iif
> There is no root disk chaining.
> And Root Disk controller setting is not  IDE.
> Web Services APIs
> resizeVolume API call will not change, but it will accept volume UUIDs of 
> root volumes in id parameter for resizing.
> deployVirtualMachine API call will allow new rootdisksize parameter to be 
> passed. This parameter will be used as the disk size (in GB) when cloning 
> from template.
> UI
> 1) (refer attached image 1) shows UI that resize volume option is added for 
> ROOT disks.
> 2) (refer attached image 2) when user calls the resize volume on ROOT volume. 
> Here only size option is shown. For DATADISK disk offerings are shown.
> 3) (refer attached image 3) when user deploys VM. New option for Root disk 
> size is added.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-9198) VR gets created in the disabled POD

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9198:


Github user anshul1886 commented on the issue:

https://github.com/apache/cloudstack/pull/1278
  
@abhinandanprateek #1860 should take care of last host id scenario. Other 
case of user specifying host, should we not allow deploying VM in disabled Pod? 
That's a separate issue by the way.


> VR gets created in the disabled POD
> ---
>
> Key: CLOUDSTACK-9198
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9198
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Anshul Gangwar
>Assignee: Anshul Gangwar
>
> VR gets created in the disabled POD



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-9198) VR gets created in the disabled POD

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9198:


Github user koushik-das commented on the issue:

https://github.com/apache/cloudstack/pull/1278
  
I think disabled resource related checks are only applicable for regular 
users, root/system users can go ahead and deploy VMs in disabled resources as 
well.


> VR gets created in the disabled POD
> ---
>
> Key: CLOUDSTACK-9198
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9198
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Anshul Gangwar
>Assignee: Anshul Gangwar
>
> VR gets created in the disabled POD



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (CLOUDSTACK-9784) GPU detail not displayed in GPU tab of management server UI.

[Nitesh Sarda (JIRA)]

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

Nitesh Sarda resolved CLOUDSTACK-9784.
--
Resolution: Fixed

> GPU detail not displayed in GPU tab of management server UI.
> 
>
> Key: CLOUDSTACK-9784
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9784
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Nitesh Sarda
>
> ISSUE
> ==
> When GPU tab of the host is selected on the management server UI, no GPU 
> detail is displayed.
> RESOLUTION
> ==
>  There is a javascript file namely "system.js" in which while fetching the 
> GPU details, sort functionality in dataprovider is returning value as 
> undefined and hence it throwing an exception. So handled the output as 
> undefined gracefully to avoid exception.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (CLOUDSTACK-9198) VR gets created in the disabled POD

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9198:


Github user abhinandanprateek commented on the issue:

https://github.com/apache/cloudstack/pull/1278
  
@anshul1886 If you trace the method planDeployment in 
DeploymentPlanningManagerImpl then you will see that orderCluster is getting 
invoked at line 500. By that time I think the deployment plan for a VM that has 
hostid or lasthost id populated is already returned (line 472 and 369). This 
will allow vm to be started on a disabled pod as well as any VM that is created 
for a host in a disabled pod to be allowed as host id is pre-set for such VMs. 
There should be additional checks above to disallow a disabled pod.


> VR gets created in the disabled POD
> ---
>
> Key: CLOUDSTACK-9198
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9198
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Anshul Gangwar
>Assignee: Anshul Gangwar
>
> VR gets created in the disabled POD



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)