[jira] [Commented] (CLOUDSTACK-10134) Performance improvement for applying port forwarding rules

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-10134:
-

muralikoripally commented on issue #2311: CLOUDSTACK-10134 Optimization of 
applying port forwarding rules
URL: https://github.com/apache/cloudstack/pull/2311#issuecomment-356515968
 
 
   Verified by adding 50 port forwarding rules parallel on this PR and also on 
master branch.
   Observed, rules add complete timings are improved.
   
   Steps:
   
   1. Allocate ip address
   2. Added 50 PortForwarding rule to the IP address repeatedly - Captured 
time (start time)
   3. Repeatedly check all the Async jobs and capture the completion time.
   
   Here are timings (captured time from creatPF rule request to its Async job 
compete):
   
   On Master branch: Took 129 seconds to complete all the rules
   On PR: Took 85 seconds to complete all the rules.
   
   Also verified that all the rules are applied.
   LGTM for test.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Performance improvement for applying port forwarding rules
> --
>
> Key: CLOUDSTACK-10134
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10134
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Virtual Router
>Reporter: subhash yedugundla
>
> Repro Steps
> Step to reproduce: 
> 1. Allocate ip address 
> 2. Add PortForwarding rule to the IP address repeatedly 
> 3. Check the time that setting takes
> Time for each rules goes up for every new rule that gets added. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CLOUDSTACK-4757) Support OVA files with multiple disks for templates

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-4757:


blueorangutan commented on issue #2146: CLOUDSTACK-4757: Support OVA files with 
multiple disks for templates
URL: https://github.com/apache/cloudstack/pull/2146#issuecomment-356483559
 
 
   Trillian test result (tid-2098)
   Environment: vmware-55u3 (x2), Advanced Networking with Mgmt server 7
   Total time taken: 53879 seconds
   Marvin logs: 
https://github.com/blueorangutan/acs-prs/releases/download/trillian/pr2146-t2098-vmware-55u3.zip
   Intermitten failure detected: 
/marvin/tests/smoke/test_deploy_vgpu_enabled_vm.py
   Intermitten failure detected: 
/marvin/tests/smoke/test_deploy_vm_root_resize.py
   Intermitten failure detected: /marvin/tests/smoke/test_ssvm.py
   Intermitten failure detected: /marvin/tests/smoke/test_templates.py
   Intermitten failure detected: /marvin/tests/smoke/test_vm_life_cycle.py
   Smoke tests completed. 62 look OK, 5 have error(s)
   Only failed tests results shown below:
   
   
   Test | Result | Time (s) | Test File
   --- | --- | --- | ---
   test_3d_gpu_support | `Failure` | 459.60 | test_deploy_vgpu_enabled_vm.py
   test_00_deploy_vm_root_resize | `Error` | 0.22 | 
test_deploy_vm_root_resize.py
   test_05_stop_ssvm | `Error` | 1008.31 | test_ssvm.py
   test_08_reboot_cpvm | `Error` | 912.60 | test_ssvm.py
   ContextSuite context=TestCreateTemplateWithDirectDownload>:setup | `Error` | 
5.26 | test_templates.py
   test_08_migrate_vm | `Error` | 42.75 | test_vm_life_cycle.py
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Support OVA files with multiple disks for templates
> ---
>
> Key: CLOUDSTACK-4757
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4757
> Project: CloudStack
>  Issue Type: New Feature
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Storage Controller
>Reporter: Likitha Shetty
>Assignee: Nicolas Vazquez
>Priority: Minor
> Fix For: Future
>
>
> CloudStack volumes and templates are one single virtual disk in case of 
> XenServer/XCP and KVM hypervisors since the files used for templates and 
> volumes are virtual disks (VHD, QCOW2). However, VMware volumes and templates 
> are in OVA format, which are archives that can contain a complete VM 
> including multiple VMDKs and other files such as ISOs. And currently, 
> Cloudstack only supports Template creation based on OVA files containing a 
> single disk. If a user creates a template from a OVA file containing more 
> than 1 disk and launches an instance using this template, only the first disk 
> is attached to the new instance and other disks are ignored.
> Similarly with uploaded volumes, attaching an uploaded volume that contains 
> multiple disks to a VM will result in only one VMDK to being attached to the 
> VM.
> This behavior needs to be improved in VMWare to support OVA files with 
> multiple disks for both uploaded volumes and templates. i.e. If a user 
> creates a template from a OVA file containing more than 1 disk and launches 
> an instance using this template, the first disk should be attached to the new 
> instance as the ROOT disk and volumes should be created based on other VMDK 
> disks in the OVA file and should be attached to the instance.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CLOUDSTACK-9620) Improvements for Managed Storage

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9620:


blueorangutan commented on issue #2298: CLOUDSTACK-9620: Enhancements for 
managed storage
URL: https://github.com/apache/cloudstack/pull/2298#issuecomment-356481562
 
 
   Trillian test result (tid-2090)
   Environment: vmware-55u3 (x2), Advanced Networking with Mgmt server 7
   Total time taken: 64886 seconds
   Marvin logs: 
https://github.com/blueorangutan/acs-prs/releases/download/trillian/pr2298-t2090-vmware-55u3.zip
   Intermitten failure detected: 
/marvin/tests/smoke/test_deploy_vgpu_enabled_vm.py
   Intermitten failure detected: 
/marvin/tests/smoke/test_deploy_vm_root_resize.py
   Intermitten failure detected: /marvin/tests/smoke/test_privategw_acl.py
   Intermitten failure detected: /marvin/tests/smoke/test_public_ip_range.py
   Intermitten failure detected: /marvin/tests/smoke/test_ssvm.py
   Intermitten failure detected: /marvin/tests/smoke/test_templates.py
   Intermitten failure detected: /marvin/tests/smoke/test_usage.py
   Intermitten failure detected: /marvin/tests/smoke/test_vm_snapshots.py
   Intermitten failure detected: /marvin/tests/smoke/test_volumes.py
   Intermitten failure detected: /marvin/tests/smoke/test_host_maintenance.py
   Smoke tests completed. 60 look OK, 7 have error(s)
   Only failed tests results shown below:
   
   
   Test | Result | Time (s) | Test File
   --- | --- | --- | ---
   test_00_deploy_vm_root_resize | `Error` | 0.07 | 
test_deploy_vm_root_resize.py
   test_02_deploy_vm_root_resize | `Failure` | 0.00 | 
test_deploy_vm_root_resize.py
   test_01_list_sec_storage_vm | `Failure` | 0.14 | test_ssvm.py
   test_02_list_cpvm_vm | `Failure` | 0.14 | test_ssvm.py
   test_05_stop_ssvm | `Failure` | 143.89 | test_ssvm.py
   test_06_stop_cpvm | `Failure` | 157.09 | test_ssvm.py
   ContextSuite context=TestCreateTemplateWithDirectDownload>:setup | `Error` | 
20.76 | test_templates.py
   test_04_extract_template | `Failure` | 167.64 | test_templates.py
   ContextSuite context=TestISOUsage>:setup | `Error` | 0.00 | test_usage.py
   test_change_service_offering_for_vm_with_snapshots | `Failure` | 413.49 | 
test_vm_snapshots.py
   test_06_download_detached_volume | `Failure` | 238.21 | test_volumes.py
   test_02_cancel_host_maintenace_with_migration_jobs | `Error` | 111.36 | 
test_host_maintenance.py
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Improvements for Managed Storage
> 
>
> Key: CLOUDSTACK-9620
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9620
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: KVM, Management Server, VMware, XenServer
>Affects Versions: 4.11.0.0
> Environment: KVM, vSphere, and XenServer
>Reporter: Mike Tutkowski
>Assignee: Mike Tutkowski
> Fix For: 4.11.0.0
>
>
> Allowed zone-wide primary storage based on a custom plug-in to be added via 
> the GUI in a KVM-only environment (previously this only worked for XenServer 
> and VMware)
> Added support for root disks on managed storage with KVM
> Added support for volume snapshots with managed storage on KVM
> Enabled creating a template directly from a volume (i.e. without having to go 
> through a volume snapshot) on KVM with managed storage
> Only allowed the resizing of a volume for managed storage on KVM if the 
> volume in question is either not attached to a VM or is attached to a VM in 
> the Stopped state
> Included support for Reinstall VM on KVM with managed storage
> Enabled offline migration on KVM from non-managed storage to managed storage 
> and vice versa
> Included support for online storage migration on KVM with managed storage 
> (NFS and Ceph to managed storage)
> Added support to download (extract) a managed-storage volume to a QCOW2 file
> When uploading a file from outside of CloudStack to CloudStack, set the min 
> and max IOPS, if applicable.
> Included support for the KVM auto-convergence feature
> The compression flag was actually added in version 1.0.3 (103) as opposed 
> to version 1.3.0 (1003000) (changed this to reflect the correct version)
> On KVM when using iSCSI-based managed storage, if the user shuts a VM down 
> from the guest OS (as opposed to doing so from CloudStack), we need to pass 
> to the KVM agent a list of applicable iSCSI volumes that need to be 
> disconnected.
> Added a new 

[jira] [Commented] (CLOUDSTACK-9620) Improvements for Managed Storage

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9620:


mike-tutkowski commented on issue #2298: CLOUDSTACK-9620: Enhancements for 
managed storage
URL: https://github.com/apache/cloudstack/pull/2298#issuecomment-356481529
 
 
   @rhtyd Just so I get a feeling for the test failures with regards to other 
PRs: Are other PRs failing with issues that don't seem directly related to them?
   
   With regards to my progress running the managed-storage tests, I'm about 1/3 
of the way through.
   
   So far, I only see one failure. It is possibly related to commit 1d0f212. 
The problem concerns SAN-assisted snapshots. This is when we take a SAN 
snapshot, but we don't want to keep the snapshot on the SAN, so we migrate it 
to secondary storage (the idea here is to minimize the impact on the source 
volume that we are taking a volume snapshot on by not copying from that volume 
to secondary storage, but rather going through a SAN snapshot).
   
   In any event, we can't create a template from this kind of snapshot anymore 
because we can't find a hypervisor host to perform the copy from secondary to 
primary storage.
   
   I have this noted and plan to investigate it soon. In the meanwhile, I've 
just continued running the tests and all has been well with them.
   
   Once I have all of the tests run, I can post results.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Improvements for Managed Storage
> 
>
> Key: CLOUDSTACK-9620
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9620
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: KVM, Management Server, VMware, XenServer
>Affects Versions: 4.11.0.0
> Environment: KVM, vSphere, and XenServer
>Reporter: Mike Tutkowski
>Assignee: Mike Tutkowski
> Fix For: 4.11.0.0
>
>
> Allowed zone-wide primary storage based on a custom plug-in to be added via 
> the GUI in a KVM-only environment (previously this only worked for XenServer 
> and VMware)
> Added support for root disks on managed storage with KVM
> Added support for volume snapshots with managed storage on KVM
> Enabled creating a template directly from a volume (i.e. without having to go 
> through a volume snapshot) on KVM with managed storage
> Only allowed the resizing of a volume for managed storage on KVM if the 
> volume in question is either not attached to a VM or is attached to a VM in 
> the Stopped state
> Included support for Reinstall VM on KVM with managed storage
> Enabled offline migration on KVM from non-managed storage to managed storage 
> and vice versa
> Included support for online storage migration on KVM with managed storage 
> (NFS and Ceph to managed storage)
> Added support to download (extract) a managed-storage volume to a QCOW2 file
> When uploading a file from outside of CloudStack to CloudStack, set the min 
> and max IOPS, if applicable.
> Included support for the KVM auto-convergence feature
> The compression flag was actually added in version 1.0.3 (103) as opposed 
> to version 1.3.0 (1003000) (changed this to reflect the correct version)
> On KVM when using iSCSI-based managed storage, if the user shuts a VM down 
> from the guest OS (as opposed to doing so from CloudStack), we need to pass 
> to the KVM agent a list of applicable iSCSI volumes that need to be 
> disconnected.
> Added a new Global Setting: kvm.storage.live.migration.wait
> For XenServer, added a check to enforce that only volumes from zone-wide 
> managed storage can be storage motioned from a host in one cluster to a host 
> in another cluster (cannot do so at the time being with volumes from 
> cluster-scoped managed storage)
> Don’t allow Storage XenMotion on a VM that has any managed-storage volume 
> with one or more snapshots.
> Enabled for managed storage with VMware: Template caching, create snapshot, 
> delete snapshot, create volume from snapshot, and create template from 
> snapshot
> Added an SIOC API plug-in to support VMware SIOC
> When starting a VM that uses managed storage in a cluster other than the one 
> it last was running in, we need to remove the reference to the iSCSI volume 
> from the original cluster.
> Added the ability to revert a volume to a snapshot
> Enabled cluster-scoped managed storage
> Added support for VMware dynamic discovery



--
This message was sent by Atlassian 

[jira] [Commented] (CLOUDSTACK-9620) Improvements for Managed Storage

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9620:


blueorangutan commented on issue #2298: CLOUDSTACK-9620: Enhancements for 
managed storage
URL: https://github.com/apache/cloudstack/pull/2298#issuecomment-356459368
 
 
   Trillian test result (tid-2089)
   Environment: kvm-centos7 (x2), Advanced Networking with Mgmt server 7
   Total time taken: 57412 seconds
   Marvin logs: 
https://github.com/blueorangutan/acs-prs/releases/download/trillian/pr2298-t2089-kvm-centos7.zip
   Intermitten failure detected: /marvin/tests/smoke/test_accounts.py
   Intermitten failure detected: 
/marvin/tests/smoke/test_deploy_virtio_scsi_vm.py
   Intermitten failure detected: /marvin/tests/smoke/test_deploy_vm_iso.py
   Intermitten failure detected: /marvin/tests/smoke/test_iso.py
   Intermitten failure detected: /marvin/tests/smoke/test_public_ip_range.py
   Intermitten failure detected: /marvin/tests/smoke/test_ssvm.py
   Intermitten failure detected: /marvin/tests/smoke/test_templates.py
   Intermitten failure detected: /marvin/tests/smoke/test_usage.py
   Intermitten failure detected: /marvin/tests/smoke/test_vm_life_cycle.py
   Intermitten failure detected: /marvin/tests/smoke/test_volumes.py
   Smoke tests completed. 59 look OK, 8 have error(s)
   Only failed tests results shown below:
   
   
   Test | Result | Time (s) | Test File
   --- | --- | --- | ---
   ContextSuite context=TestAccounts>:setup | `Error` | 0.00 | test_accounts.py
   ContextSuite context=TestAddVmToSubDomain>:setup | `Error` | 0.00 | 
test_accounts.py
   test_DeleteDomain | `Error` | 1.73 | test_accounts.py
   test_forceDeleteDomain | `Error` | 1.73 | test_accounts.py
   ContextSuite context=TestRemoveUserFromAccount>:setup | `Error` | 17.95 | 
test_accounts.py
   ContextSuite context=TestDeployVirtioSCSIVM>:setup | `Error` | 0.00 | 
test_deploy_virtio_scsi_vm.py
   test_deploy_vm_from_iso | `Error` | 1520.42 | test_deploy_vm_iso.py
   test_01_1_create_iso_with_checksum_sha1_negative | `Error` | 70.72 | 
test_iso.py
   test_01_create_iso_with_checksum_sha1 | `Error` | 65.64 | test_iso.py
   test_01_create_iso_with_checksum_sha1 | `Error` | 70.73 | test_iso.py
   test_02_1_create_iso_with_checksum_sha256_negative | `Error` | 70.70 | 
test_iso.py
   test_02_create_iso_with_checksum_sha256 | `Error` | 65.58 | test_iso.py
   test_02_create_iso_with_checksum_sha256 | `Error` | 70.67 | test_iso.py
   test_03_1_create_iso_with_checksum_md5_negative | `Error` | 70.66 | 
test_iso.py
   test_03_create_iso_with_checksum_md5 | `Error` | 65.58 | test_iso.py
   test_03_create_iso_with_checksum_md5 | `Error` | 70.66 | test_iso.py
   test_04_create_iso_with_no_checksum | `Error` | 65.58 | test_iso.py
   test_04_create_iso_with_no_checksum | `Error` | 70.66 | test_iso.py
   test_01_create_iso | `Failure` | 1518.19 | test_iso.py
   ContextSuite context=TestISO>:setup | `Error` | 3042.55 | test_iso.py
   test_01_list_sec_storage_vm | `Failure` | 0.17 | test_ssvm.py
   test_02_list_cpvm_vm | `Failure` | 0.17 | test_ssvm.py
   test_05_stop_ssvm | `Failure` | 69.63 | test_ssvm.py
   test_06_stop_cpvm | `Failure` | 98.25 | test_ssvm.py
   test_04_extract_template | `Failure` | 132.34 | test_templates.py
   ContextSuite context=TestISOUsage>:setup | `Error` | 0.00 | test_usage.py
   test_06_download_detached_volume | `Failure` | 147.62 | test_volumes.py
   test_07_resize_fail | `Failure` | 15.39 | test_volumes.py
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Improvements for Managed Storage
> 
>
> Key: CLOUDSTACK-9620
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9620
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: KVM, Management Server, VMware, XenServer
>Affects Versions: 4.11.0.0
> Environment: KVM, vSphere, and XenServer
>Reporter: Mike Tutkowski
>Assignee: Mike Tutkowski
> Fix For: 4.11.0.0
>
>
> Allowed zone-wide primary storage based on a custom plug-in to be added via 
> the GUI in a KVM-only environment (previously this only worked for XenServer 
> and VMware)
> Added support for root disks on managed storage with KVM
> Added support for volume snapshots with managed storage on KVM
> Enabled creating a template directly from a volume (i.e. without having to go 
> through a volume snapshot) on KVM with managed storage
> Only allowed the 

[jira] [Commented] (CLOUDSTACK-9813) Use configdrive for userdata, metadata & password

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9813:


rhtyd commented on a change in pull request #2097: [4.11] CLOUDSTACK-9813: 
Extending Config Drive support
URL: https://github.com/apache/cloudstack/pull/2097#discussion_r160524430
 
 

 ##
 File path: tools/marvin/marvin/config/test_data.py
 ##
 @@ -513,6 +565,19 @@
 "NetworkACL": 'VpcVirtualRouter'
 }
 },
+"vpc_offering_configdrive": {
+"name": 'VPC offering ConfigDrive',
+"displaytext": 'VPC offering ConfigDrive',
+"supportedservices": 
'Dhcp,StaticNat,SourceNat,NetworkACL,UserData,Dns',
+"serviceProviderList": {
+"Dhcp": "VpcVirtualRouter",
+"StaticNat": "VpcVirtualRouter",
+"SourceNat": "VpcVirtualRouter",
+"NetworkACL": "VpcVirtualRouter",
+"UserData": "ConfigDrive",
+"Dns": "VpcVirtualRouter"
+}
+},
 
 Review comment:
   Yes, the test dsta should not be part of marvin library at all. We should 
stop doing that at least with new tests. 


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Use configdrive for userdata, metadata & password 
> --
>
> Key: CLOUDSTACK-9813
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9813
> Project: CloudStack
>  Issue Type: New Feature
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: KVM, Network Controller, Secondary Storage, SystemVM, 
> VMware
>Affects Versions: Future
>Reporter: Eric Waegeman
>Assignee: Kris Sterckx
>
> To avoid the use of an extra VM for the virtual router we implement 
> configdrive for userdata, metadata & password. 
> The configdrive ISO is created on the secondary store and the KVM & VMware 
> plugins are adapted to accept the configdrive ISO as second cdrom.
> Is applicable for isolated, VPC and shared networks.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CLOUDSTACK-9620) Improvements for Managed Storage

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9620:


blueorangutan commented on issue #2298: CLOUDSTACK-9620: Enhancements for 
managed storage
URL: https://github.com/apache/cloudstack/pull/2298#issuecomment-356402302
 
 
   Trillian test result (tid-2096)
   Environment: xenserver-65sp1 (x2), Advanced Networking with Mgmt server 6
   Total time taken: 38478 seconds
   Marvin logs: 
https://github.com/blueorangutan/acs-prs/releases/download/trillian/pr2298-t2096-xenserver-65sp1.zip
   Intermitten failure detected: /marvin/tests/smoke/test_deploy_vm_iso.py
   Intermitten failure detected: /marvin/tests/smoke/test_ssvm.py
   Intermitten failure detected: /marvin/tests/smoke/test_templates.py
   Intermitten failure detected: /marvin/tests/smoke/test_vm_snapshots.py
   Intermitten failure detected: /marvin/tests/smoke/test_volumes.py
   Smoke tests completed. 64 look OK, 3 have error(s)
   Only failed tests results shown below:
   
   
   Test | Result | Time (s) | Test File
   --- | --- | --- | ---
   ContextSuite context=TestCreateTemplateWithDirectDownload>:setup | `Error` | 
15.29 | test_templates.py
   test_02_edit_template | `Failure` | 90.16 | test_templates.py
   test_change_service_offering_for_vm_with_snapshots | `Failure` | 228.66 | 
test_vm_snapshots.py
   test_07_resize_fail | `Failure` | 45.83 | test_volumes.py
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Improvements for Managed Storage
> 
>
> Key: CLOUDSTACK-9620
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9620
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: KVM, Management Server, VMware, XenServer
>Affects Versions: 4.11.0.0
> Environment: KVM, vSphere, and XenServer
>Reporter: Mike Tutkowski
>Assignee: Mike Tutkowski
> Fix For: 4.11.0.0
>
>
> Allowed zone-wide primary storage based on a custom plug-in to be added via 
> the GUI in a KVM-only environment (previously this only worked for XenServer 
> and VMware)
> Added support for root disks on managed storage with KVM
> Added support for volume snapshots with managed storage on KVM
> Enabled creating a template directly from a volume (i.e. without having to go 
> through a volume snapshot) on KVM with managed storage
> Only allowed the resizing of a volume for managed storage on KVM if the 
> volume in question is either not attached to a VM or is attached to a VM in 
> the Stopped state
> Included support for Reinstall VM on KVM with managed storage
> Enabled offline migration on KVM from non-managed storage to managed storage 
> and vice versa
> Included support for online storage migration on KVM with managed storage 
> (NFS and Ceph to managed storage)
> Added support to download (extract) a managed-storage volume to a QCOW2 file
> When uploading a file from outside of CloudStack to CloudStack, set the min 
> and max IOPS, if applicable.
> Included support for the KVM auto-convergence feature
> The compression flag was actually added in version 1.0.3 (103) as opposed 
> to version 1.3.0 (1003000) (changed this to reflect the correct version)
> On KVM when using iSCSI-based managed storage, if the user shuts a VM down 
> from the guest OS (as opposed to doing so from CloudStack), we need to pass 
> to the KVM agent a list of applicable iSCSI volumes that need to be 
> disconnected.
> Added a new Global Setting: kvm.storage.live.migration.wait
> For XenServer, added a check to enforce that only volumes from zone-wide 
> managed storage can be storage motioned from a host in one cluster to a host 
> in another cluster (cannot do so at the time being with volumes from 
> cluster-scoped managed storage)
> Don’t allow Storage XenMotion on a VM that has any managed-storage volume 
> with one or more snapshots.
> Enabled for managed storage with VMware: Template caching, create snapshot, 
> delete snapshot, create volume from snapshot, and create template from 
> snapshot
> Added an SIOC API plug-in to support VMware SIOC
> When starting a VM that uses managed storage in a cluster other than the one 
> it last was running in, we need to remove the reference to the iSCSI volume 
> from the original cluster.
> Added the ability to revert a volume to a snapshot
> Enabled cluster-scoped managed storage
> Added support for VMware dynamic discovery



--
This message was sent 

[jira] [Commented] (CLOUDSTACK-9813) Use configdrive for userdata, metadata & password

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9813:


blueorangutan commented on issue #2097: [4.11] CLOUDSTACK-9813: Extending 
Config Drive support
URL: https://github.com/apache/cloudstack/pull/2097#issuecomment-356395209
 
 
   Trillian test result (tid-2094)
   Environment: kvm-centos7 (x2), Advanced Networking with Mgmt server 7
   Total time taken: 36912 seconds
   Marvin logs: 
https://github.com/blueorangutan/acs-prs/releases/download/trillian/pr2097-t2094-kvm-centos7.zip
   Intermitten failure detected: 
/marvin/tests/smoke/test_deploy_virtio_scsi_vm.py
   Intermitten failure detected: /marvin/tests/smoke/test_internal_lb.py
   Intermitten failure detected: /marvin/tests/smoke/test_privategw_acl.py
   Intermitten failure detected: /marvin/tests/smoke/test_router_dhcphosts.py
   Intermitten failure detected: /marvin/tests/smoke/test_volumes.py
   Intermitten failure detected: /marvin/tests/smoke/test_host_maintenance.py
   Intermitten failure detected: /marvin/tests/smoke/test_hostha_kvm.py
   Smoke tests completed. 65 look OK, 2 have error(s)
   Only failed tests results shown below:
   
   
   Test | Result | Time (s) | Test File
   --- | --- | --- | ---
   test_07_resize_fail | `Failure` | 4.40 | test_volumes.py
   test_hostha_enable_ha_when_host_in_maintenance | `Error` | 0.78 | 
test_hostha_kvm.py
   test_hostha_kvm_host_fencing | `Error` | 633.21 | test_hostha_kvm.py
   test_hostha_kvm_host_recovering | `Error` | 633.43 | test_hostha_kvm.py
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Use configdrive for userdata, metadata & password 
> --
>
> Key: CLOUDSTACK-9813
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9813
> Project: CloudStack
>  Issue Type: New Feature
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: KVM, Network Controller, Secondary Storage, SystemVM, 
> VMware
>Affects Versions: Future
>Reporter: Eric Waegeman
>Assignee: Kris Sterckx
>
> To avoid the use of an extra VM for the virtual router we implement 
> configdrive for userdata, metadata & password. 
> The configdrive ISO is created on the secondary store and the KVM & VMware 
> plugins are adapted to accept the configdrive ISO as second cdrom.
> Is applicable for isolated, VPC and shared networks.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (CLOUDSTACK-10222) Clean previous snaphosts from primary storage when taking new one

[Khosrow Moossavi (JIRA)]

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

Khosrow Moossavi updated CLOUDSTACK-10222:
--
Labels: easyfix  (was: )

> Clean previous snaphosts from primary storage when taking new one
> -
>
> Key: CLOUDSTACK-10222
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10222
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Secondary Storage, Snapshot, XenServer
>Affects Versions: 4.10.0.0
> Environment: XenServer, Swift
>Reporter: Khosrow Moossavi
>  Labels: easyfix
> Fix For: 4.11.0.0
>
>
> When user creates a snapshot (manual or recurring), snapshot remains on the 
> primary storage, even if the snapshot is transferred successfully to 
> secondary storage. This is causing issues because XenServer can only hold a 
> limited number of snapshots in its VDI chain, preventing the user from 
> creating new snapshots after some time, when too many old snapshots are 
> present on the primary storage. 
> {code:java}
> reason: SR_BACKEND_FAILURE_109 The snapshot chain is too long
> {code}
> Proposed solution:
> Keep only one snapshot (last successful) on the primary storage regardless 
> that it was a full or partial snapshot.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CLOUDSTACK-10222) Clean previous snaphosts from primary storage when taking new one

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-10222:
-

khos2ow commented on issue #2398: CLOUDSTACK-10222: Clean previous snaphosts 
from primary storage when …
URL: https://github.com/apache/cloudstack/pull/2398#issuecomment-356385233
 
 
   @rafaelweingartner updated the PR.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Clean previous snaphosts from primary storage when taking new one
> -
>
> Key: CLOUDSTACK-10222
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10222
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Secondary Storage, Snapshot, XenServer
>Affects Versions: 4.10.0.0
> Environment: XenServer, Swift
>Reporter: Khosrow Moossavi
> Fix For: 4.11.0.0
>
>
> When user creates a snapshot (manual or recurring), snapshot remains on the 
> primary storage, even if the snapshot is transferred successfully to 
> secondary storage. This is causing issues because XenServer can only hold a 
> limited number of snapshots in its VDI chain, preventing the user from 
> creating new snapshots after some time, when too many old snapshots are 
> present on the primary storage. 
> {code:java}
> reason: SR_BACKEND_FAILURE_109 The snapshot chain is too long
> {code}
> Proposed solution:
> Keep only one snapshot (last successful) on the primary storage regardless 
> that it was a full or partial snapshot.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CLOUDSTACK-10109) Enable dedication of public IPs to SSVM and CPVM

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on CLOUDSTACK-10109:
--

Commit b0d7844cf0cc107e15532a7f675f9c9ad8293fd9 in cloudstack's branch 
refs/heads/master from [~bhaisaab]
[ https://gitbox.apache.org/repos/asf?p=cloudstack.git;h=b0d7844 ]

CLOUDSTACK-10109: Fix regression from PR #2295 (#2394)

This fixes regression introduced in PR #2295:
- Pass assign=true to fetch new public IP
- Use wait_until instead of sleep+wait in tests
- Loop through list of public IP ranges to match the systemvm gateway
- Fix potential NPE seen when adding simulator host(s)
- Removes aria2 installation from setup_agent.sh using yum, it's already
  dependency for cloudstack-agent package

Signed-off-by: Rohit Yadav 

> Enable dedication of public IPs to SSVM and CPVM
> 
>
> Key: CLOUDSTACK-10109
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10109
> Project: CloudStack
>  Issue Type: New Feature
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Nicolas Vazquez
>Assignee: Nicolas Vazquez
> Attachments: public01.png, public02.png, public03.png
>
>
> It is required to dedicate a public IP range for SSVM and CPVM in order to 
> apply firewall rules to control inbound access.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CLOUDSTACK-10109) Enable dedication of public IPs to SSVM and CPVM

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-10109:
-

rhtyd closed pull request #2394: CLOUDSTACK-10109: Fix regression from PR #2295
URL: https://github.com/apache/cloudstack/pull/2394
 
 
   

This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:

As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):

diff --git 
a/plugins/storage/volume/solidfire/src/org/apache/cloudstack/storage/datastore/provider/SolidFireHostListener.java
 
b/plugins/storage/volume/solidfire/src/org/apache/cloudstack/storage/datastore/provider/SolidFireHostListener.java
index 69e1a7995c3..21a7fade52a 100644
--- 
a/plugins/storage/volume/solidfire/src/org/apache/cloudstack/storage/datastore/provider/SolidFireHostListener.java
+++ 
b/plugins/storage/volume/solidfire/src/org/apache/cloudstack/storage/datastore/provider/SolidFireHostListener.java
@@ -74,6 +74,11 @@
 public boolean hostAdded(long hostId) {
 HostVO host = _hostDao.findById(hostId);
 
+if (host == null) {
+s_logger.error("Failed to add host by SolidFireHostListener as 
host was not found with id=" + hostId);
+return false;
+}
+
 SolidFireUtil.hostAddedToOrRemovedFromCluster(hostId, 
host.getClusterId(), true, SolidFireUtil.PROVIDER_NAME,
 _clusterDao, _clusterDetailsDao, _storagePoolDao, 
_storagePoolDetailsDao, _hostDao);
 
diff --git 
a/plugins/storage/volume/solidfire/src/org/apache/cloudstack/storage/datastore/provider/SolidFireSharedHostListener.java
 
b/plugins/storage/volume/solidfire/src/org/apache/cloudstack/storage/datastore/provider/SolidFireSharedHostListener.java
index f88041a3c49..29c39483d11 100644
--- 
a/plugins/storage/volume/solidfire/src/org/apache/cloudstack/storage/datastore/provider/SolidFireSharedHostListener.java
+++ 
b/plugins/storage/volume/solidfire/src/org/apache/cloudstack/storage/datastore/provider/SolidFireSharedHostListener.java
@@ -68,6 +68,11 @@
 public boolean hostAdded(long hostId) {
 HostVO host = hostDao.findById(hostId);
 
+if (host == null) {
+LOGGER.error("Failed to add host by SolidFireSharedHostListener as 
host was not found with id=" + hostId);
+return false;
+}
+
 SolidFireUtil.hostAddedToOrRemovedFromCluster(hostId, 
host.getClusterId(), true, SolidFireUtil.SHARED_PROVIDER_NAME,
 clusterDao, clusterDetailsDao, storagePoolDao, 
storagePoolDetailsDao, hostDao);
 
diff --git a/scripts/vm/hypervisor/kvm/setup_agent.sh 
b/scripts/vm/hypervisor/kvm/setup_agent.sh
index b3c2e0fd280..d55c6adfde2 100755
--- a/scripts/vm/hypervisor/kvm/setup_agent.sh
+++ b/scripts/vm/hypervisor/kvm/setup_agent.sh
@@ -224,17 +224,5 @@ then
 setenforce 0
 fi
 
-which aria2c
-if [ $? -gt 0 ]
-then
-yum install epel-release -y
-yum install aria2 -y
-if [ $? -gt 0 ]
-then
-printf "failed to install aria2"
-exit 1
-fi
-fi
-
 cloudstack-setup-agent --host=$host --zone=$zone --pod=$pod --cluster=$cluster 
--guid=$guid $paramters -a > /dev/null
 #cloud_consoleP_setup $host $zone $pod
diff --git a/server/src/com/cloud/network/IpAddressManagerImpl.java 
b/server/src/com/cloud/network/IpAddressManagerImpl.java
index 891dddf66f8..c00359c92f0 100644
--- a/server/src/com/cloud/network/IpAddressManagerImpl.java
+++ b/server/src/com/cloud/network/IpAddressManagerImpl.java
@@ -964,13 +964,7 @@ public PublicIp doInTransaction(TransactionStatus status) 
throws InsufficientAdd
 VpcVO vpc = _vpcDao.findById(vpcId);
 displayIp = vpc.isDisplay();
 }
-PublicIp ip = fetchNewPublicIp(dcId, null, null, owner, 
VlanType.VirtualNetwork, guestNtwkId, isSourceNat, false, null, false, vpcId, 
displayIp, false);
-IPAddressVO publicIp = ip.ip();
-
-markPublicIpAsAllocated(publicIp);
-_ipAddressDao.update(publicIp.getId(), publicIp);
-
-return ip;
+return fetchNewPublicIp(dcId, null, null, owner, 
VlanType.VirtualNetwork, guestNtwkId, isSourceNat, true, null, false, vpcId, 
displayIp, false);
 }
 });
 if (ip.getState() != State.Allocated) {
diff --git a/test/integration/smoke/test_public_ip_range.py 
b/test/integration/smoke/test_public_ip_range.py
index 624a407dc4a..664fdb4d482 100644
--- a/test/integration/smoke/test_public_ip_range.py
+++ b/test/integration/smoke/test_public_ip_range.py
@@ -204,25 +204,24 @@ def is_ip_in_range(self, start_ip, end_ip, ip_to_test):
 ip = self.get_ip_as_number(ip_to_test)
 

[jira] [Commented] (CLOUDSTACK-10109) Enable dedication of public IPs to SSVM and CPVM

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-10109:
-

rhtyd commented on issue #2394: CLOUDSTACK-10109: Fix regression from PR #2295
URL: https://github.com/apache/cloudstack/pull/2394#issuecomment-356384425
 
 
   Merging this based on test results and code reviews, and also that Travis 
passed. 


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Enable dedication of public IPs to SSVM and CPVM
> 
>
> Key: CLOUDSTACK-10109
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10109
> Project: CloudStack
>  Issue Type: New Feature
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Nicolas Vazquez
>Assignee: Nicolas Vazquez
> Attachments: public01.png, public02.png, public03.png
>
>
> It is required to dedicate a public IP range for SSVM and CPVM in order to 
> apply firewall rules to control inbound access.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CLOUDSTACK-10109) Enable dedication of public IPs to SSVM and CPVM

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-10109:
-

rhtyd commented on issue #2394: CLOUDSTACK-10109: Fix regression from PR #2295
URL: https://github.com/apache/cloudstack/pull/2394#issuecomment-356384425
 
 
   Merging this based on test results and code reviews. 


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Enable dedication of public IPs to SSVM and CPVM
> 
>
> Key: CLOUDSTACK-10109
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10109
> Project: CloudStack
>  Issue Type: New Feature
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Nicolas Vazquez
>Assignee: Nicolas Vazquez
> Attachments: public01.png, public02.png, public03.png
>
>
> It is required to dedicate a public IP range for SSVM and CPVM in order to 
> apply firewall rules to control inbound access.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CLOUDSTACK-10217) When IPv4 address of Instance is updated DHCP data is not cleared on VR

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on CLOUDSTACK-10217:
--

Commit e01dd89c930b6218e0062becf20e0dc594d00569 in cloudstack's branch 
refs/heads/master from [~widodh]
[ https://gitbox.apache.org/repos/asf?p=cloudstack.git;h=e01dd89 ]

CLOUDSTACK-10217: Clean up old MAC addresses from DHCP lease file (#2393)

When the IPv4 address of a Instance changes we need to make sure the
old entry is removed from the DHCP lease file on the Virtual Router
otherwise the Instance will still get the old lease.

Signed-off-by: Wido den Hollander 

> When IPv4 address of Instance is updated DHCP data is not cleared on VR
> ---
>
> Key: CLOUDSTACK-10217
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10217
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Virtual Router
>Affects Versions: 4.10.0.0
> Environment: Basic Networking - KVM
>Reporter: Wido den Hollander
>Assignee: Wido den Hollander
>  Labels: basic-networking, dhcp, virtual-router
> Fix For: 4.11.0.0
>
>
> When the IPv4 address of a NIC is changed the new entry is added to the DHCP 
> lease file in the Virtual Router, but the old entry (with the same MAC) is 
> not removed and this causes the Instance to still receive the old address.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CLOUDSTACK-10217) When IPv4 address of Instance is updated DHCP data is not cleared on VR

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-10217:
-

rhtyd commented on issue #2393: CLOUDSTACK-10217: Clean up old MAC addresses 
from DHCP lease file
URL: https://github.com/apache/cloudstack/pull/2393#issuecomment-356383945
 
 
   Test lgtm, and code lgtm. Considering Daan's review as lgtm, merging based 
on two lgtms, and purely on test results. 


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> When IPv4 address of Instance is updated DHCP data is not cleared on VR
> ---
>
> Key: CLOUDSTACK-10217
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10217
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Virtual Router
>Affects Versions: 4.10.0.0
> Environment: Basic Networking - KVM
>Reporter: Wido den Hollander
>Assignee: Wido den Hollander
>  Labels: basic-networking, dhcp, virtual-router
> Fix For: 4.11.0.0
>
>
> When the IPv4 address of a NIC is changed the new entry is added to the DHCP 
> lease file in the Virtual Router, but the old entry (with the same MAC) is 
> not removed and this causes the Instance to still receive the old address.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CLOUDSTACK-10217) When IPv4 address of Instance is updated DHCP data is not cleared on VR

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-10217:
-

rhtyd closed pull request #2393: CLOUDSTACK-10217: Clean up old MAC addresses 
from DHCP lease file
URL: https://github.com/apache/cloudstack/pull/2393
 
 
   

This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:

As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):

diff --git a/systemvm/debian/opt/cloud/bin/cs_dhcp.py 
b/systemvm/debian/opt/cloud/bin/cs_dhcp.py
index b85e650d90a..88b4b7568c5 100755
--- a/systemvm/debian/opt/cloud/bin/cs_dhcp.py
+++ b/systemvm/debian/opt/cloud/bin/cs_dhcp.py
@@ -25,12 +25,18 @@ def merge(dbag, data):
 if data['ipv4_address'] in dbag:
 del(dbag[data['ipv4_address']])
 else:
-remove_key = None
+remove_keys = set()
 for key, entry in dbag.iteritems():
 if key != 'id' and entry['host_name'] == data['host_name']:
-remove_key = key
+remove_keys.add(key)
 break
-if remove_key is not None:
+
+for key, entry in dbag.iteritems():
+if key != 'id' and entry['mac_address'] == data['mac_address']:
+remove_keys.add(key)
+break
+
+for remove_key in remove_keys:
 del(dbag[remove_key])
 
 dbag[data['ipv4_address']] = data


 


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> When IPv4 address of Instance is updated DHCP data is not cleared on VR
> ---
>
> Key: CLOUDSTACK-10217
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10217
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Virtual Router
>Affects Versions: 4.10.0.0
> Environment: Basic Networking - KVM
>Reporter: Wido den Hollander
>Assignee: Wido den Hollander
>  Labels: basic-networking, dhcp, virtual-router
> Fix For: 4.11.0.0
>
>
> When the IPv4 address of a NIC is changed the new entry is added to the DHCP 
> lease file in the Virtual Router, but the old entry (with the same MAC) is 
> not removed and this causes the Instance to still receive the old address.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CLOUDSTACK-10222) Clean previous snaphosts from primary storage when taking new one

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-10222:
-

khos2ow commented on a change in pull request #2398: CLOUDSTACK-10222: Clean 
previous snaphosts from primary storage when …
URL: https://github.com/apache/cloudstack/pull/2398#discussion_r160494160
 
 

 ##
 File path: 
plugins/hypervisors/xenserver/src/com/cloud/hypervisor/xenserver/resource/Xenserver625StorageProcessor.java
 ##
 @@ -576,13 +578,20 @@ public Answer backupSnapshot(final CopyCommand cmd) {
 s_logger.info("New snapshot details: " + newSnapshot.toString());
 s_logger.info("New snapshot physical utilization: "+physicalSize);
 
+successful = true;
+
 return new CopyCmdAnswer(newSnapshot);
 } catch (final Types.XenAPIException e) {
 details = "BackupSnapshot Failed due to " + e.toString();
 s_logger.warn(details, e);
 } catch (final Exception e) {
 details = "BackupSnapshot Failed due to " + e.getMessage();
 s_logger.warn(details, e);
+} finally {
+if (!successful) {
 
 Review comment:
   When the two `catch` block merged together I'll move this from `finally` to 
`catch`.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Clean previous snaphosts from primary storage when taking new one
> -
>
> Key: CLOUDSTACK-10222
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10222
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Secondary Storage, Snapshot, XenServer
>Affects Versions: 4.10.0.0
> Environment: XenServer, Swift
>Reporter: Khosrow Moossavi
> Fix For: 4.11.0.0
>
>
> When user creates a snapshot (manual or recurring), snapshot remains on the 
> primary storage, even if the snapshot is transferred successfully to 
> secondary storage. This is causing issues because XenServer can only hold a 
> limited number of snapshots in its VDI chain, preventing the user from 
> creating new snapshots after some time, when too many old snapshots are 
> present on the primary storage. 
> {code:java}
> reason: SR_BACKEND_FAILURE_109 The snapshot chain is too long
> {code}
> Proposed solution:
> Keep only one snapshot (last successful) on the primary storage regardless 
> that it was a full or partial snapshot.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CLOUDSTACK-10222) Clean previous snaphosts from primary storage when taking new one

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-10222:
-

khos2ow commented on a change in pull request #2398: CLOUDSTACK-10222: Clean 
previous snaphosts from primary storage when …
URL: https://github.com/apache/cloudstack/pull/2398#discussion_r160494001
 
 

 ##
 File path: 
plugins/hypervisors/xenserver/src/com/cloud/hypervisor/xenserver/resource/Xenserver625StorageProcessor.java
 ##
 @@ -576,13 +578,20 @@ public Answer backupSnapshot(final CopyCommand cmd) {
 s_logger.info("New snapshot details: " + newSnapshot.toString());
 s_logger.info("New snapshot physical utilization: "+physicalSize);
 
+successful = true;
+
 return new CopyCmdAnswer(newSnapshot);
 } catch (final Types.XenAPIException e) {
 details = "BackupSnapshot Failed due to " + e.toString();
 s_logger.warn(details, e);
 } catch (final Exception e) {
 
 Review comment:
   Actually not, there are multiple other exceptions can be thrown which this 
block should catch them. The difference is that `Types.XenAPIException` doesn't 
have a meaningful `getMessage()` method. I'll combine them together though.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Clean previous snaphosts from primary storage when taking new one
> -
>
> Key: CLOUDSTACK-10222
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10222
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Secondary Storage, Snapshot, XenServer
>Affects Versions: 4.10.0.0
> Environment: XenServer, Swift
>Reporter: Khosrow Moossavi
> Fix For: 4.11.0.0
>
>
> When user creates a snapshot (manual or recurring), snapshot remains on the 
> primary storage, even if the snapshot is transferred successfully to 
> secondary storage. This is causing issues because XenServer can only hold a 
> limited number of snapshots in its VDI chain, preventing the user from 
> creating new snapshots after some time, when too many old snapshots are 
> present on the primary storage. 
> {code:java}
> reason: SR_BACKEND_FAILURE_109 The snapshot chain is too long
> {code}
> Proposed solution:
> Keep only one snapshot (last successful) on the primary storage regardless 
> that it was a full or partial snapshot.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CLOUDSTACK-10109) Enable dedication of public IPs to SSVM and CPVM

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-10109:
-

blueorangutan commented on issue #2394: CLOUDSTACK-10109: Fix regression from 
PR #2295
URL: https://github.com/apache/cloudstack/pull/2394#issuecomment-356376736
 
 
   Trillian test result (tid-2087)
   Environment: kvm-centos7 (x2), Advanced Networking with Mgmt server 7
   Total time taken: 36843 seconds
   Marvin logs: 
https://github.com/blueorangutan/acs-prs/releases/download/trillian/pr2394-t2087-kvm-centos7.zip
   Intermitten failure detected: /marvin/tests/smoke/test_hostha_kvm.py
   Smoke tests completed. 67 look OK, 0 have error(s)
   Only failed tests results shown below:
   
   
   Test | Result | Time (s) | Test File
   --- | --- | --- | ---
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Enable dedication of public IPs to SSVM and CPVM
> 
>
> Key: CLOUDSTACK-10109
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10109
> Project: CloudStack
>  Issue Type: New Feature
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Nicolas Vazquez
>Assignee: Nicolas Vazquez
> Attachments: public01.png, public02.png, public03.png
>
>
> It is required to dedicate a public IP range for SSVM and CPVM in order to 
> apply firewall rules to control inbound access.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CLOUDSTACK-10222) Clean previous snaphosts from primary storage when taking new one

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-10222:
-

rafaelweingartner commented on a change in pull request #2398: 
CLOUDSTACK-10222: Clean previous snaphosts from primary storage when …
URL: https://github.com/apache/cloudstack/pull/2398#discussion_r160486246
 
 

 ##
 File path: 
plugins/hypervisors/xenserver/src/com/cloud/hypervisor/xenserver/resource/Xenserver625StorageProcessor.java
 ##
 @@ -576,13 +578,20 @@ public Answer backupSnapshot(final CopyCommand cmd) {
 s_logger.info("New snapshot details: " + newSnapshot.toString());
 s_logger.info("New snapshot physical utilization: "+physicalSize);
 
+successful = true;
+
 return new CopyCmdAnswer(newSnapshot);
 } catch (final Types.XenAPIException e) {
 details = "BackupSnapshot Failed due to " + e.toString();
 s_logger.warn(details, e);
 } catch (final Exception e) {
 details = "BackupSnapshot Failed due to " + e.getMessage();
 s_logger.warn(details, e);
+} finally {
+if (!successful) {
 
 Review comment:
   What about removing this finally and boolean control variable? You only need 
to worry about exception cases (normal workflow is already addressed at 
567-568). So, you can do something like this in the catch block: 
   ```
   destroySnapshotOnPrimaryStorage(conn, snapshotUuid);
   ```
   
   BTW: the method `destroySnapshotOnPrimaryStorage(Conn, String)` does seem to 
need that boolean return and we also could remove its catch of `Exception`.
 


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Clean previous snaphosts from primary storage when taking new one
> -
>
> Key: CLOUDSTACK-10222
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10222
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Secondary Storage, Snapshot, XenServer
>Affects Versions: 4.10.0.0
> Environment: XenServer, Swift
>Reporter: Khosrow Moossavi
> Fix For: 4.11.0.0
>
>
> When user creates a snapshot (manual or recurring), snapshot remains on the 
> primary storage, even if the snapshot is transferred successfully to 
> secondary storage. This is causing issues because XenServer can only hold a 
> limited number of snapshots in its VDI chain, preventing the user from 
> creating new snapshots after some time, when too many old snapshots are 
> present on the primary storage. 
> {code:java}
> reason: SR_BACKEND_FAILURE_109 The snapshot chain is too long
> {code}
> Proposed solution:
> Keep only one snapshot (last successful) on the primary storage regardless 
> that it was a full or partial snapshot.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CLOUDSTACK-10222) Clean previous snaphosts from primary storage when taking new one

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-10222:
-

rafaelweingartner commented on a change in pull request #2398: 
CLOUDSTACK-10222: Clean previous snaphosts from primary storage when …
URL: https://github.com/apache/cloudstack/pull/2398#discussion_r160485571
 
 

 ##
 File path: 
plugins/hypervisors/xenserver/src/com/cloud/hypervisor/xenserver/resource/Xenserver625StorageProcessor.java
 ##
 @@ -576,13 +578,20 @@ public Answer backupSnapshot(final CopyCommand cmd) {
 s_logger.info("New snapshot details: " + newSnapshot.toString());
 s_logger.info("New snapshot physical utilization: "+physicalSize);
 
+successful = true;
+
 return new CopyCmdAnswer(newSnapshot);
 } catch (final Types.XenAPIException e) {
 details = "BackupSnapshot Failed due to " + e.toString();
 s_logger.warn(details, e);
 } catch (final Exception e) {
 
 Review comment:
   It seems that this generic exception can be removed.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Clean previous snaphosts from primary storage when taking new one
> -
>
> Key: CLOUDSTACK-10222
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10222
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Secondary Storage, Snapshot, XenServer
>Affects Versions: 4.10.0.0
> Environment: XenServer, Swift
>Reporter: Khosrow Moossavi
> Fix For: 4.11.0.0
>
>
> When user creates a snapshot (manual or recurring), snapshot remains on the 
> primary storage, even if the snapshot is transferred successfully to 
> secondary storage. This is causing issues because XenServer can only hold a 
> limited number of snapshots in its VDI chain, preventing the user from 
> creating new snapshots after some time, when too many old snapshots are 
> present on the primary storage. 
> {code:java}
> reason: SR_BACKEND_FAILURE_109 The snapshot chain is too long
> {code}
> Proposed solution:
> Keep only one snapshot (last successful) on the primary storage regardless 
> that it was a full or partial snapshot.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CLOUDSTACK-10217) When IPv4 address of Instance is updated DHCP data is not cleared on VR

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-10217:
-

blueorangutan commented on issue #2393: CLOUDSTACK-10217: Clean up old MAC 
addresses from DHCP lease file
URL: https://github.com/apache/cloudstack/pull/2393#issuecomment-356358549
 
 
   Trillian test result (tid-2091)
   Environment: kvm-centos7 (x2), Advanced Networking with Mgmt server 7
   Total time taken: 28925 seconds
   Marvin logs: 
https://github.com/blueorangutan/acs-prs/releases/download/trillian/pr2393-t2091-kvm-centos7.zip
   Intermitten failure detected: /marvin/tests/smoke/test_internal_lb.py
   Smoke tests completed. 67 look OK, 0 have error(s)
   Only failed tests results shown below:
   
   
   Test | Result | Time (s) | Test File
   --- | --- | --- | ---
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> When IPv4 address of Instance is updated DHCP data is not cleared on VR
> ---
>
> Key: CLOUDSTACK-10217
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10217
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Virtual Router
>Affects Versions: 4.10.0.0
> Environment: Basic Networking - KVM
>Reporter: Wido den Hollander
>Assignee: Wido den Hollander
>  Labels: basic-networking, dhcp, virtual-router
> Fix For: 4.11.0.0
>
>
> When the IPv4 address of a NIC is changed the new entry is added to the DHCP 
> lease file in the Virtual Router, but the old entry (with the same MAC) is 
> not removed and this causes the Instance to still receive the old address.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CLOUDSTACK-10188) Resource Accounting for primary storage is Broken

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-10188:
-

blueorangutan commented on issue #2362: CLOUDSTACK-10188 - Resource Accounting 
for primary storage is Broken when Domains are in use
URL: https://github.com/apache/cloudstack/pull/2362#issuecomment-356357840
 
 
   Trillian test result (tid-2095)
   Environment: kvm-centos7 (x2), Advanced Networking with Mgmt server 7
   Total time taken: 28771 seconds
   Marvin logs: 
https://github.com/blueorangutan/acs-prs/releases/download/trillian/pr2362-t2095-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_vpc_redundant.py
   Intermitten failure detected: /marvin/tests/smoke/test_host_maintenance.py
   Intermitten failure detected: /marvin/tests/smoke/test_hostha_kvm.py
   Smoke tests completed. 65 look OK, 2 have error(s)
   Only failed tests results shown below:
   
   
   Test | Result | Time (s) | Test File
   --- | --- | --- | ---
   test_05_rvpc_multi_tiers | `Failure` | 310.72 | test_vpc_redundant.py
   test_05_rvpc_multi_tiers | `Error` | 336.43 | test_vpc_redundant.py
   test_hostha_enable_ha_when_host_in_maintenance | `Error` | 0.63 | 
test_hostha_kvm.py
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Resource Accounting for primary storage is Broken
> -
>
> Key: CLOUDSTACK-10188
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10188
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.9.0, 4.10.0.0, 4.11.0.0
>Reporter: Ivan Kudryavtsev
>
> During storage expunge domain resource statistics for primary storage space 
> resource counter is not updated for domain. This leads to the situation when 
> domain resource statistics for primary storage is overfilled (statistics only 
> increase but not decrease).
> Global scheduled task resourcecount.check.interval > 0 provides a workaround 
> but not fixes the problem truly because when accounts inside domains use 
> primary_storage allocation/deallocation intensively it leads to service block 
> of operation.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CLOUDSTACK-10222) Clean previous snaphosts from primary storage when taking new one

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-10222:
-

khos2ow opened a new pull request #2398: CLOUDSTACK-10222: Clean previous 
snaphosts from primary storage when …
URL: https://github.com/apache/cloudstack/pull/2398
 
 
   …taking new one
   
   When user creates a snapshot (manual or recurring), snapshot remains on
   the primary storage, even if the snapshot is transferred successfully to
   secondary storage. This is causing issues because XenServer can only hold
   a limited number of snapshots in its VDI chain, preventing the user from
   creating new snapshots after some time, when too many old snapshots are
   present on the primary storage.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Clean previous snaphosts from primary storage when taking new one
> -
>
> Key: CLOUDSTACK-10222
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10222
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Secondary Storage, Snapshot, XenServer
>Affects Versions: 4.10.0.0
> Environment: XenServer, Swift
>Reporter: Khosrow Moossavi
> Fix For: 4.11.0.0
>
>
> When user creates a snapshot (manual or recurring), snapshot remains on the 
> primary storage, even if the snapshot is transferred successfully to 
> secondary storage. This is causing issues because XenServer can only hold a 
> limited number of snapshots in its VDI chain, preventing the user from 
> creating new snapshots after some time, when too many old snapshots are 
> present on the primary storage. 
> {code:java}
> reason: SR_BACKEND_FAILURE_109 The snapshot chain is too long
> {code}
> Proposed solution:
> Keep only one snapshot (last successful) on the primary storage regardless 
> that it was a full or partial snapshot.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (CLOUDSTACK-10222) Clean previous snaphosts from primary storage when taking new one

[Khosrow Moossavi (JIRA)]

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

Khosrow Moossavi updated CLOUDSTACK-10222:
--
Summary: Clean previous snaphosts from primary storage when taking new one  
(was: Snaphosts remain on primary storage)

> Clean previous snaphosts from primary storage when taking new one
> -
>
> Key: CLOUDSTACK-10222
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10222
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Secondary Storage, Snapshot, XenServer
>Affects Versions: 4.10.0.0
> Environment: XenServer, Swift
>Reporter: Khosrow Moossavi
> Fix For: 4.11.0.0
>
>
> When user creates a snapshot (manual or recurring), snapshot remains on the 
> primary storage, even if the snapshot is transferred successfully to 
> secondary storage. This is causing issues because XenServer can only hold a 
> limited number of snapshots in its VDI chain, preventing the user from 
> creating new snapshots after some time, when too many old snapshots are 
> present on the primary storage. 
> {code:java}
> reason: SR_BACKEND_FAILURE_109 The snapshot chain is too long
> {code}
> Proposed solution:
> Keep only one snapshot (last successful) on the primary storage regardless 
> that it was a full or partial snapshot.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (CLOUDSTACK-10222) Snaphosts remain on primary storage

[Khosrow Moossavi (JIRA)]

Khosrow Moossavi created CLOUDSTACK-10222:
-

 Summary: Snaphosts remain on primary storage
 Key: CLOUDSTACK-10222
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10222
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Secondary Storage, Snapshot, XenServer
Affects Versions: 4.10.0.0
 Environment: XenServer, Swift
Reporter: Khosrow Moossavi
 Fix For: 4.11.0.0


When user creates a snapshot (manual or recurring), snapshot remains on the 
primary storage, even if the snapshot is transferred successfully to secondary 
storage. This is causing issues because XenServer can only hold a limited 
number of snapshots in its VDI chain, preventing the user from creating new 
snapshots after some time, when too many old snapshots are present on the 
primary storage. 
{code:java}
reason: SR_BACKEND_FAILURE_109 The snapshot chain is too long
{code}


Proposed solution:
Keep only one snapshot (last successful) on the primary storage regardless that 
it was a full or partial snapshot.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CLOUDSTACK-9813) Use configdrive for userdata, metadata & password

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9813:


krissterckx commented on a change in pull request #2097: [4.11] 
CLOUDSTACK-9813: Extending Config Drive support
URL: https://github.com/apache/cloudstack/pull/2097#discussion_r160435009
 
 

 ##
 File path: server/src/com/cloud/network/NetworkServiceImpl.java
 ##
 @@ -4198,20 +4201,36 @@ private PhysicalNetworkServiceProvider 
addDefaultBaremetalProvidersToPhysicalNet
 addProviderToPhysicalNetwork(physicalNetworkId, 
"BaremetalUserdataProvider", null, null);
 } else if (dvo.getNetworkType() == NetworkType.Advanced) {
 addProviderToPhysicalNetwork(physicalNetworkId, 
"BaremetalPxeProvider", null, null);
-enableBaremetalProvider("BaremetalPxeProvider");
+enableProvider("BaremetalPxeProvider");
 }
 
 return null;
 }
 
-private void enableBaremetalProvider(String providerName) {
+private void enableProvider(String providerName) {
 QueryBuilder q = 
QueryBuilder.create(PhysicalNetworkServiceProviderVO.class);
 q.and(q.entity().getProviderName(), SearchCriteria.Op.EQ, 
providerName);
 PhysicalNetworkServiceProviderVO provider = q.find();
 provider.setState(PhysicalNetworkServiceProvider.State.Enabled);
 _pNSPDao.update(provider.getId(), provider);
 }
 
+private PhysicalNetworkServiceProvider 
addConfigDriveToPhysicalNetwork(long physicalNetworkId) {
+PhysicalNetworkVO pvo = 
_physicalNetworkDao.findById(physicalNetworkId);
+DataCenterVO dvo = _dcDao.findById(pvo.getDataCenterId());
+if (dvo.getNetworkType() == NetworkType.Advanced) {
 
 Review comment:
   @wido you suggest we remove the check ?


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Use configdrive for userdata, metadata & password 
> --
>
> Key: CLOUDSTACK-9813
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9813
> Project: CloudStack
>  Issue Type: New Feature
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: KVM, Network Controller, Secondary Storage, SystemVM, 
> VMware
>Affects Versions: Future
>Reporter: Eric Waegeman
>Assignee: Kris Sterckx
>
> To avoid the use of an extra VM for the virtual router we implement 
> configdrive for userdata, metadata & password. 
> The configdrive ISO is created on the secondary store and the KVM & VMware 
> plugins are adapted to accept the configdrive ISO as second cdrom.
> Is applicable for isolated, VPC and shared networks.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CLOUDSTACK-9813) Use configdrive for userdata, metadata & password

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9813:


wido commented on a change in pull request #2097: [4.11] CLOUDSTACK-9813: 
Extending Config Drive support
URL: https://github.com/apache/cloudstack/pull/2097#discussion_r160428915
 
 

 ##
 File path: server/src/com/cloud/network/NetworkServiceImpl.java
 ##
 @@ -4198,20 +4201,36 @@ private PhysicalNetworkServiceProvider 
addDefaultBaremetalProvidersToPhysicalNet
 addProviderToPhysicalNetwork(physicalNetworkId, 
"BaremetalUserdataProvider", null, null);
 } else if (dvo.getNetworkType() == NetworkType.Advanced) {
 addProviderToPhysicalNetwork(physicalNetworkId, 
"BaremetalPxeProvider", null, null);
-enableBaremetalProvider("BaremetalPxeProvider");
+enableProvider("BaremetalPxeProvider");
 }
 
 return null;
 }
 
-private void enableBaremetalProvider(String providerName) {
+private void enableProvider(String providerName) {
 QueryBuilder q = 
QueryBuilder.create(PhysicalNetworkServiceProviderVO.class);
 q.and(q.entity().getProviderName(), SearchCriteria.Op.EQ, 
providerName);
 PhysicalNetworkServiceProviderVO provider = q.find();
 provider.setState(PhysicalNetworkServiceProvider.State.Enabled);
 _pNSPDao.update(provider.getId(), provider);
 }
 
+private PhysicalNetworkServiceProvider 
addConfigDriveToPhysicalNetwork(long physicalNetworkId) {
+PhysicalNetworkVO pvo = 
_physicalNetworkDao.findById(physicalNetworkId);
+DataCenterVO dvo = _dcDao.findById(pvo.getDataCenterId());
+if (dvo.getNetworkType() == NetworkType.Advanced) {
 
 Review comment:
   Understood! Thanks, I'll test that when I get the chance, but that won't be 
very soon :(
   
   Don't wait with merging before my tests


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Use configdrive for userdata, metadata & password 
> --
>
> Key: CLOUDSTACK-9813
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9813
> Project: CloudStack
>  Issue Type: New Feature
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: KVM, Network Controller, Secondary Storage, SystemVM, 
> VMware
>Affects Versions: Future
>Reporter: Eric Waegeman
>Assignee: Kris Sterckx
>
> To avoid the use of an extra VM for the virtual router we implement 
> configdrive for userdata, metadata & password. 
> The configdrive ISO is created on the secondary store and the KVM & VMware 
> plugins are adapted to accept the configdrive ISO as second cdrom.
> Is applicable for isolated, VPC and shared networks.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CLOUDSTACK-9813) Use configdrive for userdata, metadata & password

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9813:


krissterckx commented on a change in pull request #2097: [4.11] 
CLOUDSTACK-9813: Extending Config Drive support
URL: https://github.com/apache/cloudstack/pull/2097#discussion_r160427278
 
 

 ##
 File path: server/src/com/cloud/network/NetworkServiceImpl.java
 ##
 @@ -4198,20 +4201,36 @@ private PhysicalNetworkServiceProvider 
addDefaultBaremetalProvidersToPhysicalNet
 addProviderToPhysicalNetwork(physicalNetworkId, 
"BaremetalUserdataProvider", null, null);
 } else if (dvo.getNetworkType() == NetworkType.Advanced) {
 addProviderToPhysicalNetwork(physicalNetworkId, 
"BaremetalPxeProvider", null, null);
-enableBaremetalProvider("BaremetalPxeProvider");
+enableProvider("BaremetalPxeProvider");
 }
 
 return null;
 }
 
-private void enableBaremetalProvider(String providerName) {
+private void enableProvider(String providerName) {
 QueryBuilder q = 
QueryBuilder.create(PhysicalNetworkServiceProviderVO.class);
 q.and(q.entity().getProviderName(), SearchCriteria.Op.EQ, 
providerName);
 PhysicalNetworkServiceProviderVO provider = q.find();
 provider.setState(PhysicalNetworkServiceProvider.State.Enabled);
 _pNSPDao.update(provider.getId(), provider);
 }
 
+private PhysicalNetworkServiceProvider 
addConfigDriveToPhysicalNetwork(long physicalNetworkId) {
+PhysicalNetworkVO pvo = 
_physicalNetworkDao.findById(physicalNetworkId);
+DataCenterVO dvo = _dcDao.findById(pvo.getDataCenterId());
+if (dvo.getNetworkType() == NetworkType.Advanced) {
 
 Review comment:
   No technical reason but there is very limited knowledge about Basic 
networking within Nuage team; it would be best that other community members 
further extend it. We could leave out the check but it might not just work like 
that.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Use configdrive for userdata, metadata & password 
> --
>
> Key: CLOUDSTACK-9813
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9813
> Project: CloudStack
>  Issue Type: New Feature
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: KVM, Network Controller, Secondary Storage, SystemVM, 
> VMware
>Affects Versions: Future
>Reporter: Eric Waegeman
>Assignee: Kris Sterckx
>
> To avoid the use of an extra VM for the virtual router we implement 
> configdrive for userdata, metadata & password. 
> The configdrive ISO is created on the secondary store and the KVM & VMware 
> plugins are adapted to accept the configdrive ISO as second cdrom.
> Is applicable for isolated, VPC and shared networks.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CLOUDSTACK-10221) Allow specification of IPv6 details when creating Basic Network

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-10221:
-

wido opened a new pull request #2397: CLOUDSTACK-10221: Allow IPv6 when 
creating a Basic Network
URL: https://github.com/apache/cloudstack/pull/2397
 
 
   Since CloudStack 4.10 Basic Networking supports IPv6 and thus
   should be allowed to be specified when creating a network.
   
   Signed-off-by: Wido den Hollander 


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Allow specification of IPv6 details when creating Basic Network
> ---
>
> Key: CLOUDSTACK-10221
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10221
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server, Network Controller
>Affects Versions: 4.10.0.0, 4.11.0.0
> Environment: Basic Networking with IPv6
>Reporter: Wido den Hollander
>
> Currently IPv6 details can't be supplied when creating a Basic Network as 
> this will error out.
> Basic Networking does support IPv6 so this restriction can be removed



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CLOUDSTACK-9749) cloudstack master vpc_internal_lb feature is broken as port 8080 is in use by password server on lb VM

[Rohit Yadav (JIRA)]

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

Rohit Yadav commented on CLOUDSTACK-9749:
-

Thanks for sharing [~smeetsr], the debian9 systemvmtemplate uses systemd enabld 
scripts where password server is started from here:
https://github.com/apache/cloudstack/blob/master/systemvm/debian/opt/cloud/bin/cs/CsAddress.py#L569

Given the regression you've found, the fix should go in the above file to avoid 
starting password server when it's a non-router VM (rvr, dhcpsrvr, or router).

> cloudstack master vpc_internal_lb feature is broken as port 8080 is in use by 
> password server on lb VM
> --
>
> Key: CLOUDSTACK-9749
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9749
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.10.0.0, 4.9.2.0, 4.8.2.0, 4.11.0.0
>Reporter: Raf Smeets
>Assignee: Frank Maximus
>Priority: Critical
> Fix For: 4.10.0.0
>
> Attachments: runinfo.txt
>
>
> cloudstack master vpc_internal_lb feature is broken as port 8080 is in use by 
> password server on lb VM
> Executed test/integration/plugins/nuagevsp/test_nuage_vpc_internal_lb.py 
> which failed in test_05_nuage_internallb_traffic at the point where it is 
> checking the lb via wget of file using port 8080.
> As port 8080 already is occupied by the password_server, it fails.
> I have added the runinfo.txt of the failing test to this bugticket.
> Similar issue was reported internally via CLOUD-972.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CLOUDSTACK-10013) Migrate to Debian9 systemvmtemplate

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-10013:
-

rhtyd commented on issue #2211: CLOUDSTACK-10013: Migrate systemvmtemplate to 
Debian9
URL: https://github.com/apache/cloudstack/pull/2211#issuecomment-356301826
 
 
   @fmaximus thanks for sharing, can you explore a fix and perhaps help submit 
a PR on this basing the fix in the python script than the shell/setup scripts:
   
https://github.com/apache/cloudstack/blob/master/systemvm/debian/opt/cloud/bin/cs/CsAddress.py#L569
 


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Migrate to Debian9 systemvmtemplate
> ---
>
> Key: CLOUDSTACK-10013
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10013
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
> Fix For: 4.11.0.0
>
>
> Migrate to debian9 based systemvmtemplate



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (CLOUDSTACK-9749) cloudstack master vpc_internal_lb feature is broken as port 8080 is in use by password server on lb VM

[Raf Smeets (JIRA)]

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

Raf Smeets edited comment on CLOUDSTACK-9749 at 1/9/18 2:30 PM:


Since the introduction of Debian9 in 4.11 systemvmtemplate, 
test_05_nuage_internallb_traffic of test_nuage_vpc_internal_lb.py fails in 
connectivity check.

Previously I had raised CLOUDSTACK-9749 as password service was using port 8080.
Fix was to no longer run password service in internal_lb_vm, but it seems that 
with this new template, this fix is no longer working 

I can see password service is using port 8080 on internal_lb_vm.

Last login: Tue Jan  9 10:52:52 2018 from 10.30.36.2
[root@ovs-2 ~]# virsh list --all
 IdName   State

 2 s-1-VM running
 31i-12-61-VM running
 32i-12-63-VM running
 33b-64-VMrunning
 34b-67-VMrunning
 35i-12-69-VM running

[root@ovs-2 ~]# ssh -i ~/.ssh/id_rsa.cloud -p 3922 169.254.2.46 Linux b-67-VM 
4.9.0-4-amd64 #1 SMP Debian 4.9.65-3 (2017-12-03) x86_64

root@b-67-VM:~# netstat -an | grep 8080
tcp0  0 10.1.2.55:8080  0.0.0.0:*   LISTEN 
root@b-67-VM:~# netstat -tlpn
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address   Foreign Address State   
PID/Program name
tcp0  0 10.1.2.55:8080  0.0.0.0:*   LISTEN  
1165/python 
tcp0  0 169.254.2.46:3922   0.0.0.0:*   LISTEN  
1075/sshd   
root@b-67-VM:~# ps -ef | grep 1165
root  1165 1  0 13:32 ?00:00:00 python 
/opt/cloud/bin/passwd_server_ip.py 10.1.2.55
root  2044  2034  0 13:36 pts/000:00:00 grep 1165

root@b-67-VM:~# systemctl status cloud-password-server@10.1.2.55
? cloud-password-server@10.1.2.55.service - Cloud password server on 10.1.2.55
   Loaded: loaded (/etc/systemd/system/cloud-password-server@.service; 
disabled; vendor preset: enabled)
   Active: active (running) since Tue 2018-01-09 13:32:06 UTC; 7min ago
 Main PID: 1165 (python)
Tasks: 1 (limit: 4915)
   CGroup: 
/system.slice/system-cloud\x2dpassword\x2dserver.slice/cloud-password-server@10.1.2.55.service
   +-1165 python /opt/cloud/bin/passwd_server_ip.py 10.1.2.55

Jan 09 13:32:06 b-67-VM systemd[1]: Started Cloud password server on 10.1.2.55.
Jan 09 13:32:06 b-67-VM passwd_server_ip.py[1165]: serve_password running on 
10.1.2.55:8080

root@b-67-VM:~# systemctl stop cloud-password-server@10.1.2.55
root@b-67-VM:~# systemctl status cloud-password-server@10.1.2.55
? cloud-password-server@10.1.2.55.service - Cloud password server on 10.1.2.55
   Loaded: loaded (/etc/systemd/system/cloud-password-server@.service; 
disabled; vendor preset: enabled)
   Active: inactive (dead)

Jan 09 13:32:06 b-67-VM systemd[1]: Started Cloud password server on 10.1.2.55.
Jan 09 13:32:06 b-67-VM passwd_server_ip.py[1165]: serve_password running on 
10.1.2.55:8080
Jan 09 13:40:40 b-67-VM passwd_server_ip.py[1165]: serve_password: bad_request 
from IP 10.1.3.141
Jan 09 13:41:01 b-67-VM systemd[1]: Stopping Cloud password server on 
10.1.2.55...
Jan 09 13:41:01 b-67-VM systemd[1]: Stopped Cloud password server on 10.1.2.55.
root@b-67-VM:~# systemctl disable cloud-password-server@10.1.2.55
root@b-67-VM:~# systemctl status cloud-password-server@10.1.2.55
? cloud-password-server@10.1.2.55.service - Cloud password server on 10.1.2.55
   Loaded: loaded (/etc/systemd/system/cloud-password-server@.service; 
disabled; vendor preset: enabled)
   Active: inactive (dead)

Jan 09 13:32:06 b-67-VM systemd[1]: Started Cloud password server on 10.1.2.55.
Jan 09 13:32:06 b-67-VM passwd_server_ip.py[1165]: serve_password running on 
10.1.2.55:8080
Jan 09 13:40:40 b-67-VM passwd_server_ip.py[1165]: serve_password: bad_request 
from IP 10.1.3.141
Jan 09 13:41:01 b-67-VM systemd[1]: Stopping Cloud password server on 
10.1.2.55...
Jan 09 13:41:01 b-67-VM systemd[1]: Stopped Cloud password server on 10.1.2.55.
root@b-67-VM:~# systemctl disable cloud-password-server@
root@b-67-VM:~# systemctl enable cloud-password-server@10.1.2.55
Created symlink 
/etc/systemd/system/multi-user.target.wants/cloud-password-server@10.1.2.55.service
 -> /etc/systemd/system/cloud-password-server@.service.
root@b-67-VM:~# systemctl disable cloud-password-server@
Removed 
/etc/systemd/system/multi-user.target.wants/cloud-password-server@10.1.2.55.service.


was (Author: smeetsr):
Since the introduction of Debian9 systemvmtemplate, 
test_05_nuage_internallb_traffic of test_nuage_vpc_internal_lb.py fails in 
connectivity check.

Previously I had raised CLOUDSTACK-9749 as password service was using port 8080.
Fix 

[jira] [Updated] (CLOUDSTACK-9749) cloudstack master vpc_internal_lb feature is broken as port 8080 is in use by password server on lb VM

[Raf Smeets (JIRA)]

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

Raf Smeets updated CLOUDSTACK-9749:
---
Affects Version/s: 4.11.0.0

> cloudstack master vpc_internal_lb feature is broken as port 8080 is in use by 
> password server on lb VM
> --
>
> Key: CLOUDSTACK-9749
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9749
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.10.0.0, 4.9.2.0, 4.8.2.0, 4.11.0.0
>Reporter: Raf Smeets
>Assignee: Frank Maximus
>Priority: Critical
> Fix For: 4.10.0.0
>
> Attachments: runinfo.txt
>
>
> cloudstack master vpc_internal_lb feature is broken as port 8080 is in use by 
> password server on lb VM
> Executed test/integration/plugins/nuagevsp/test_nuage_vpc_internal_lb.py 
> which failed in test_05_nuage_internallb_traffic at the point where it is 
> checking the lb via wget of file using port 8080.
> As port 8080 already is occupied by the password_server, it fails.
> I have added the runinfo.txt of the failing test to this bugticket.
> Similar issue was reported internally via CLOUD-972.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CLOUDSTACK-10013) Migrate to Debian9 systemvmtemplate

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-10013:
-

fmaximus commented on issue #2211: CLOUDSTACK-10013: Migrate systemvmtemplate 
to Debian9
URL: https://github.com/apache/cloudstack/pull/2211#issuecomment-356295209
 
 
   Seems like we hit https://issues.apache.org/jira/browse/CLOUDSTACK-9749 
again.
   Password server is running on internal LB VM, while it should only run on 
routers.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Migrate to Debian9 systemvmtemplate
> ---
>
> Key: CLOUDSTACK-10013
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10013
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
> Fix For: 4.11.0.0
>
>
> Migrate to debian9 based systemvmtemplate



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (CLOUDSTACK-10221) Allow specification of IPv6 details when creating Basic Network

[Wido den Hollander (JIRA)]

Wido den Hollander created CLOUDSTACK-10221:
---

 Summary: Allow specification of IPv6 details when creating Basic 
Network
 Key: CLOUDSTACK-10221
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10221
 Project: CloudStack
  Issue Type: Improvement
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Management Server, Network Controller
Affects Versions: 4.10.0.0, 4.11.0.0
 Environment: Basic Networking with IPv6
Reporter: Wido den Hollander


Currently IPv6 details can't be supplied when creating a Basic Network as this 
will error out.

Basic Networking does support IPv6 so this restriction can be removed



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CLOUDSTACK-9813) Use configdrive for userdata, metadata & password

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9813:


wido commented on a change in pull request #2097: [4.11] CLOUDSTACK-9813: 
Extending Config Drive support
URL: https://github.com/apache/cloudstack/pull/2097#discussion_r160414658
 
 

 ##
 File path: server/src/com/cloud/network/NetworkServiceImpl.java
 ##
 @@ -4198,20 +4201,36 @@ private PhysicalNetworkServiceProvider 
addDefaultBaremetalProvidersToPhysicalNet
 addProviderToPhysicalNetwork(physicalNetworkId, 
"BaremetalUserdataProvider", null, null);
 } else if (dvo.getNetworkType() == NetworkType.Advanced) {
 addProviderToPhysicalNetwork(physicalNetworkId, 
"BaremetalPxeProvider", null, null);
-enableBaremetalProvider("BaremetalPxeProvider");
+enableProvider("BaremetalPxeProvider");
 }
 
 return null;
 }
 
-private void enableBaremetalProvider(String providerName) {
+private void enableProvider(String providerName) {
 QueryBuilder q = 
QueryBuilder.create(PhysicalNetworkServiceProviderVO.class);
 q.and(q.entity().getProviderName(), SearchCriteria.Op.EQ, 
providerName);
 PhysicalNetworkServiceProviderVO provider = q.find();
 provider.setState(PhysicalNetworkServiceProvider.State.Enabled);
 _pNSPDao.update(provider.getId(), provider);
 }
 
+private PhysicalNetworkServiceProvider 
addConfigDriveToPhysicalNetwork(long physicalNetworkId) {
+PhysicalNetworkVO pvo = 
_physicalNetworkDao.findById(physicalNetworkId);
+DataCenterVO dvo = _dcDao.findById(pvo.getDataCenterId());
+if (dvo.getNetworkType() == NetworkType.Advanced) {
 
 Review comment:
   Why wouldn't config-drive be supported in Basic Networking?
   
   It's a network provider, correct?


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Use configdrive for userdata, metadata & password 
> --
>
> Key: CLOUDSTACK-9813
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9813
> Project: CloudStack
>  Issue Type: New Feature
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: KVM, Network Controller, Secondary Storage, SystemVM, 
> VMware
>Affects Versions: Future
>Reporter: Eric Waegeman
>Assignee: Kris Sterckx
>
> To avoid the use of an extra VM for the virtual router we implement 
> configdrive for userdata, metadata & password. 
> The configdrive ISO is created on the secondary store and the KVM & VMware 
> plugins are adapted to accept the configdrive ISO as second cdrom.
> Is applicable for isolated, VPC and shared networks.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CLOUDSTACK-10220) IPv4 NIC alias is not added on Virtual Router in Basic Networking when NIC has IPv6 address

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-10220:
-

wido opened a new pull request #2396: CLOUDSTACK-10220: Configure IPv4 alias on 
VR regardless of IPv6
URL: https://github.com/apache/cloudstack/pull/2396
 
 
   For some reason when a IPv6 address is present for a NIC IPv4 subnet aliases 
are not configured on the VR.
   
   This seems to be very old code (>5 yr) and written at a time when IPv6 
wasn't implemented in CloudStack
   
   Removing this additional evaluation in the if-statement works for us in 
Basic Networking


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> IPv4 NIC alias is not added on Virtual Router in Basic Networking when NIC 
> has IPv6 address
> ---
>
> Key: CLOUDSTACK-10220
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10220
> 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.10.0.0
> Environment: Basic Networking with IPv6 enabled
>Reporter: Wido den Hollander
>Assignee: Wido den Hollander
>  Labels: basic-networking, ipv6, virtual-router
>
> When multiple IPv4 subnets are configured inside a POD with Basic Networking 
> a NIC alias is created for the VR when a Instance starts and 
> DhcpAccrossMultipleSubnets is supported.
> However, when the Instance has a IPv6 address this IPv4 alias is not created 
> and prohibits the Instance from getting a IPv4 address



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (CLOUDSTACK-10220) IPv4 NIC alias is not added on Virtual Router in Basic Networking when NIC has IPv6 address

[Wido den Hollander (JIRA)]

Wido den Hollander created CLOUDSTACK-10220:
---

 Summary: IPv4 NIC alias is not added on Virtual Router in Basic 
Networking when NIC has IPv6 address
 Key: CLOUDSTACK-10220
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10220
 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.10.0.0
 Environment: Basic Networking with IPv6 enabled
Reporter: Wido den Hollander
Assignee: Wido den Hollander


When multiple IPv4 subnets are configured inside a POD with Basic Networking a 
NIC alias is created for the VR when a Instance starts and 
DhcpAccrossMultipleSubnets is supported.

However, when the Instance has a IPv6 address this IPv4 alias is not created 
and prohibits the Instance from getting a IPv4 address



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CLOUDSTACK-1164) Use libvirt for security groups for KVM

[Nux (JIRA)]

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

Nux commented on CLOUDSTACK-1164:
-

Well, at least you tried, now we know it's not really an option. Thanks!

> Use libvirt for security groups for KVM
> ---
>
> Key: CLOUDSTACK-1164
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1164
> Project: CloudStack
>  Issue Type: Wish
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Hypervisor Controller, KVM
>Affects Versions: 4.0.0, 4.1.0
>Reporter: Wido den Hollander
>  Labels: kvm, libvirt, security-groups
> Fix For: Future
>
>
> The current implementation for the security groups uses a custom Python 
> script which applies iptable and ebtable rules to the hypervisor.
> Libvirt also supports this with network filters: 
> http://libvirt.org/formatnwfilter.html
> It might be cleaner to do this via libvirt, but the downside is that a lot of 
> functions are only supported by libvirt 0.9.8 and higher.
> This might not be possible at this moment, but it might be worth a shot at a 
> later stadium.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CLOUDSTACK-1164) Use libvirt for security groups for KVM

[Wido den Hollander (JIRA)]

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

Wido den Hollander commented on CLOUDSTACK-1164:


I tried a lot, but the libvirt network filters do not seem to be able to do 
this at this moment. They lack a lot of functionality..

> Use libvirt for security groups for KVM
> ---
>
> Key: CLOUDSTACK-1164
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1164
> Project: CloudStack
>  Issue Type: Wish
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Hypervisor Controller, KVM
>Affects Versions: 4.0.0, 4.1.0
>Reporter: Wido den Hollander
>  Labels: kvm, libvirt, security-groups
> Fix For: Future
>
>
> The current implementation for the security groups uses a custom Python 
> script which applies iptable and ebtable rules to the hypervisor.
> Libvirt also supports this with network filters: 
> http://libvirt.org/formatnwfilter.html
> It might be cleaner to do this via libvirt, but the downside is that a lot of 
> functions are only supported by libvirt 0.9.8 and higher.
> This might not be possible at this moment, but it might be worth a shot at a 
> later stadium.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CLOUDSTACK-9813) Use configdrive for userdata, metadata & password

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9813:


fmaximus commented on a change in pull request #2097: [4.11] CLOUDSTACK-9813: 
Extending Config Drive support
URL: https://github.com/apache/cloudstack/pull/2097#discussion_r160403836
 
 

 ##
 File path: api/src/org/apache/cloudstack/api/command/user/vm/DeployVMCmd.java
 ##
 @@ -281,6 +283,13 @@ public Long getTemplateId() {
 }
 
 public String getUserData() {
+if (userData != null) {
+try {
+userData = URLDecoder.decode(userData, "UTF-8");
 
 Review comment:
   The UI sends the userdata UrlEncoded.
   But you're correct that this shouldn't happen if the userdata isn't URL 
encoded in the first place.
   I'm going to move the code to UserVmManagerImpl.validateUserData(),
   and only to the URL decode if the userdata contains %


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Use configdrive for userdata, metadata & password 
> --
>
> Key: CLOUDSTACK-9813
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9813
> Project: CloudStack
>  Issue Type: New Feature
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: KVM, Network Controller, Secondary Storage, SystemVM, 
> VMware
>Affects Versions: Future
>Reporter: Eric Waegeman
>Assignee: Kris Sterckx
>
> To avoid the use of an extra VM for the virtual router we implement 
> configdrive for userdata, metadata & password. 
> The configdrive ISO is created on the secondary store and the KVM & VMware 
> plugins are adapted to accept the configdrive ISO as second cdrom.
> Is applicable for isolated, VPC and shared networks.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CLOUDSTACK-9813) Use configdrive for userdata, metadata & password

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9813:


krissterckx commented on a change in pull request #2097: [4.11] 
CLOUDSTACK-9813: Extending Config Drive support
URL: https://github.com/apache/cloudstack/pull/2097#discussion_r160401714
 
 

 ##
 File path: tools/marvin/marvin/config/test_data.py
 ##
 @@ -513,6 +565,19 @@
 "NetworkACL": 'VpcVirtualRouter'
 }
 },
+"vpc_offering_configdrive": {
+"name": 'VPC offering ConfigDrive',
+"displaytext": 'VPC offering ConfigDrive',
+"supportedservices": 
'Dhcp,StaticNat,SourceNat,NetworkACL,UserData,Dns',
+"serviceProviderList": {
+"Dhcp": "VpcVirtualRouter",
+"StaticNat": "VpcVirtualRouter",
+"SourceNat": "VpcVirtualRouter",
+"NetworkACL": "VpcVirtualRouter",
+"UserData": "ConfigDrive",
+"Dns": "VpcVirtualRouter"
+}
+},
 
 Review comment:
   @rhtyd are you saying that even for new generic component tests that are 
added (see test_configdrive.py being added), the policy is to add offering to 
the test itself rather than extending test_data , even when config drive 
becomes a new generic capability, added by this PR ?


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Use configdrive for userdata, metadata & password 
> --
>
> Key: CLOUDSTACK-9813
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9813
> Project: CloudStack
>  Issue Type: New Feature
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: KVM, Network Controller, Secondary Storage, SystemVM, 
> VMware
>Affects Versions: Future
>Reporter: Eric Waegeman
>Assignee: Kris Sterckx
>
> To avoid the use of an extra VM for the virtual router we implement 
> configdrive for userdata, metadata & password. 
> The configdrive ISO is created on the secondary store and the KVM & VMware 
> plugins are adapted to accept the configdrive ISO as second cdrom.
> Is applicable for isolated, VPC and shared networks.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CLOUDSTACK-10013) Migrate to Debian9 systemvmtemplate

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on CLOUDSTACK-10013:
--

Commit c9afa8e5b4d3787f5212cc0205b86ded0c89a1d7 in cloudstack's branch 
refs/heads/master from [~rohit.ya...@shapeblue.com]
[ https://gitbox.apache.org/repos/asf?p=cloudstack.git;h=c9afa8e ]

CLOUDSTACK-10013: Fix systemvmtemplate build failure

This enables security updates in preseed file and removes purges
old kernel, and increases maximum /boot partition size. Build failures
were found due to insufficient space in /boot. Tested with packer+qemu
on Ubuntu 17.10.

Also silently remove xmas cloudstack cloudmonkey logo without hurting
anyone's sentiments (no monkeys were harmed in this commit ;).

Signed-off-by: Rohit Yadav 


> Migrate to Debian9 systemvmtemplate
> ---
>
> Key: CLOUDSTACK-10013
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10013
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
> Fix For: 4.11.0.0
>
>
> Migrate to debian9 based systemvmtemplate



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (CLOUDSTACK-10212) Changing IPv4 Address of NIC in Basic Networking does not update the gateway

[Wido den Hollander (JIRA)]

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

Wido den Hollander resolved CLOUDSTACK-10212.
-
Resolution: Fixed

Merged into master

> Changing IPv4 Address of NIC in Basic Networking does not update the gateway
> 
>
> Key: CLOUDSTACK-10212
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10212
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Network Controller
>Affects Versions: 4.10.0.0
> Environment: CloudStack 4.10 - KVM - Basic Networking
>Reporter: Wido den Hollander
>Assignee: Wido den Hollander
> Fix For: 4.11.0.0
>
>
> When using updateVMNic to change the IPv4 address of a NIC the IPv4 address 
> is changed, but the Gateway stays the same.
> This can cause problems when multiple IPv4 ranges are used and a wrong 
> gateway is issued to the Instance through DHCP.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (CLOUDSTACK-10212) Changing IPv4 Address of NIC in Basic Networking does not update the gateway

[Wido den Hollander (JIRA)]

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

Wido den Hollander closed CLOUDSTACK-10212.
---

Fixed in master

> Changing IPv4 Address of NIC in Basic Networking does not update the gateway
> 
>
> Key: CLOUDSTACK-10212
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10212
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Network Controller
>Affects Versions: 4.10.0.0
> Environment: CloudStack 4.10 - KVM - Basic Networking
>Reporter: Wido den Hollander
>Assignee: Wido den Hollander
> Fix For: 4.11.0.0
>
>
> When using updateVMNic to change the IPv4 address of a NIC the IPv4 address 
> is changed, but the Gateway stays the same.
> This can cause problems when multiple IPv4 ranges are used and a wrong 
> gateway is issued to the Instance through DHCP.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (CLOUDSTACK-7958) Limit user login to specific subnets

[Wido den Hollander (JIRA)]

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

Wido den Hollander resolved CLOUDSTACK-7958.

Resolution: Fixed

Merged into master

> Limit user login to specific subnets
> 
>
> Key: CLOUDSTACK-7958
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7958
> Project: CloudStack
>  Issue Type: New Feature
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: API, Management Server
>Affects Versions: Future
>Reporter: Wido den Hollander
>Assignee: Wido den Hollander
>Priority: Minor
> Fix For: Future
>
>
> When exposing the API there is a potential danger that a user gets his hands 
> on a account with Admin privileges and does bad things to a cloud.
> It would be a useful feature if we could limit certain accounts/users to 
> specific subnets.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (CLOUDSTACK-451) System VMs shouldn't be just Debian based

[Wido den Hollander (JIRA)]

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

Wido den Hollander closed CLOUDSTACK-451.
-
Resolution: Fixed

We moved to Debian 9 now and we will probably won't to something else very soon

> System VMs shouldn't be just Debian based
> -
>
> Key: CLOUDSTACK-451
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-451
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Wido den Hollander
>Assignee: ilya musayev
> Fix For: Future
>
>
> This one is tied into: CLOUDSTACK-450
> Currently our System VMs are a Debian based template which are pretty big.
> If we abstract the way we talk to the System VM by adding an API it shouldn't 
> matter anymore which distro or OS will be running in there.
> Some users might want to use a different distribution or build their own 
> homebrew System VM as long as they implement the API.
> Most System VM tasks can be done in Read-Only mode as well, the filesystem of 
> the System VM doesn't need to be R/W, which would make them more robust.
> In the end a System VM shouldn't have to be bigger then something like 50MB 
> when stripped down.
> This issue is here to raise awareness that this has to be addressed at some 
> point.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CLOUDSTACK-10013) Migrate to Debian9 systemvmtemplate

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-10013:
-

DaanHoogland commented on issue #2395: CLOUDSTACK-10013: Enable debian security 
repos during systemvm building
URL: https://github.com/apache/cloudstack/pull/2395#issuecomment-356262413
 
 
   @wido more of a misunderstanding than a mistake. 'silently' is my phrase. I 
remarked that and meant to say that a PR is not needed if security feels it 
should be merged. @rhtyd took action as he saw fit. I dont think any harm was 
done indeed.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Migrate to Debian9 systemvmtemplate
> ---
>
> Key: CLOUDSTACK-10013
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10013
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
> Fix For: 4.11.0.0
>
>
> Migrate to debian9 based systemvmtemplate



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CLOUDSTACK-10109) Enable dedication of public IPs to SSVM and CPVM

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-10109:
-

DaanHoogland commented on issue #2394: CLOUDSTACK-10109: Fix regression from PR 
#2295
URL: https://github.com/apache/cloudstack/pull/2394#issuecomment-356261251
 
 
   lgtm


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Enable dedication of public IPs to SSVM and CPVM
> 
>
> Key: CLOUDSTACK-10109
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10109
> Project: CloudStack
>  Issue Type: New Feature
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Nicolas Vazquez
>Assignee: Nicolas Vazquez
> Attachments: public01.png, public02.png, public03.png
>
>
> It is required to dedicate a public IP range for SSVM and CPVM in order to 
> apply firewall rules to control inbound access.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CLOUDSTACK-10013) Migrate to Debian9 systemvmtemplate

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-10013:
-

rhtyd commented on issue #2395: CLOUDSTACK-10013: Enable debian security repos 
during systemvm building
URL: https://github.com/apache/cloudstack/pull/2395#issuecomment-356255899
 
 
   Thanks @wido @rafaelweingartner - see security@ :)
 


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Migrate to Debian9 systemvmtemplate
> ---
>
> Key: CLOUDSTACK-10013
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10013
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
> Fix For: 4.11.0.0
>
>
> Migrate to debian9 based systemvmtemplate



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CLOUDSTACK-10013) Migrate to Debian9 systemvmtemplate

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-10013:
-

wido commented on issue #2395: CLOUDSTACK-10013: Enable debian security repos 
during systemvm building
URL: https://github.com/apache/cloudstack/pull/2395#issuecomment-356255994
 
 
   Probably a mistake by @rhtyd , no harm done. Can you elaborate? Tnx!


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Migrate to Debian9 systemvmtemplate
> ---
>
> Key: CLOUDSTACK-10013
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10013
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
> Fix For: 4.11.0.0
>
>
> Migrate to debian9 based systemvmtemplate



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CLOUDSTACK-10013) Migrate to Debian9 systemvmtemplate

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-10013:
-

rhtyd commented on issue #2395: CLOUDSTACK-10013: Enable debian security repos 
during systemvm building
URL: https://github.com/apache/cloudstack/pull/2395#issuecomment-356255899
 
 
   Thanks @wido @rafaelweingartner - see secrurity@ :)


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Migrate to Debian9 systemvmtemplate
> ---
>
> Key: CLOUDSTACK-10013
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10013
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
> Fix For: 4.11.0.0
>
>
> Migrate to debian9 based systemvmtemplate



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CLOUDSTACK-10013) Migrate to Debian9 systemvmtemplate

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-10013:
-

wido commented on issue #2395: CLOUDSTACK-10013: Enable debian security repos 
during systemvm building
URL: https://github.com/apache/cloudstack/pull/2395#issuecomment-356255994
 
 
   Probably a mistake by @rhtyd , no harm done. Can you elaborate? Tnx!


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Migrate to Debian9 systemvmtemplate
> ---
>
> Key: CLOUDSTACK-10013
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10013
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
> Fix For: 4.11.0.0
>
>
> Migrate to debian9 based systemvmtemplate



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CLOUDSTACK-10013) Migrate to Debian9 systemvmtemplate

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-10013:
-

rafaelweingartner commented on issue #2395: CLOUDSTACK-10013: Enable debian 
security repos during systemvm building
URL: https://github.com/apache/cloudstack/pull/2395#issuecomment-356253889
 
 
   It seems that it was merged "silently" The commit ID used is: 
d30b75cfbc505cc547bd8f5150fa95
   
   Trying to achieve security by obscurity ?!


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Migrate to Debian9 systemvmtemplate
> ---
>
> Key: CLOUDSTACK-10013
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10013
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
> Fix For: 4.11.0.0
>
>
> Migrate to debian9 based systemvmtemplate



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CLOUDSTACK-10013) Migrate to Debian9 systemvmtemplate

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-10013:
-

wido commented on issue #2395: CLOUDSTACK-10013: Enable debian security repos 
during systemvm building
URL: https://github.com/apache/cloudstack/pull/2395#issuecomment-356252391
 
 
   LGTM, but why was it closed?


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Migrate to Debian9 systemvmtemplate
> ---
>
> Key: CLOUDSTACK-10013
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10013
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
> Fix For: 4.11.0.0
>
>
> Migrate to debian9 based systemvmtemplate



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CLOUDSTACK-10013) Migrate to Debian9 systemvmtemplate

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on CLOUDSTACK-10013:
--

Commit d30b75cfbc505cc547bd8f5150fa95b72631e1cf in cloudstack's branch 
refs/heads/master from [~rohit.ya...@shapeblue.com]
[ https://gitbox.apache.org/repos/asf?p=cloudstack.git;h=d30b75c ]

CLOUDSTACK-10013: Enable debian security repos during systemvm building

Perform a dist-upgrade to upgrade all packages especially the linux
kernel before building the systemvmtemplate.

Signed-off-by: Rohit Yadav 


> Migrate to Debian9 systemvmtemplate
> ---
>
> Key: CLOUDSTACK-10013
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10013
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
> Fix For: 4.11.0.0
>
>
> Migrate to debian9 based systemvmtemplate



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CLOUDSTACK-9813) Use configdrive for userdata, metadata & password

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9813:


sgoeminn commented on a change in pull request #2097: [4.11] CLOUDSTACK-9813: 
Extending Config Drive support
URL: https://github.com/apache/cloudstack/pull/2097#discussion_r160371696
 
 

 ##
 File path: 
plugins/hypervisors/xenserver/src/com/cloud/hypervisor/xenserver/resource/wrapper/xenbase/CitrixPrepareForMigrationCommandWrapper.java
 ##
 @@ -47,7 +47,7 @@ public Answer execute(final PrepareForMigrationCommand 
command, final CitrixReso
 String configDriveLabel = vm.getConfigDriveLabel();
 
 if (configDriveLabel == null)  {
-configDriveLabel = "config";
+configDriveLabel = "config-2";
 
 Review comment:
   @rhtyd it's added to be OpenStack compatible. In this way it works out of 
the box in combination with cloud-init. [design doc 
config-drive](https://cwiki.apache.org/confluence/display/CLOUDSTACK/Using+ConfigDrive+for+Metadata%2C+Userdata+and+Password#UsingConfigDriveforMetadata,UserdataandPassword-OpenStack(cloud-init)compatibility(version2))


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Use configdrive for userdata, metadata & password 
> --
>
> Key: CLOUDSTACK-9813
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9813
> Project: CloudStack
>  Issue Type: New Feature
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: KVM, Network Controller, Secondary Storage, SystemVM, 
> VMware
>Affects Versions: Future
>Reporter: Eric Waegeman
>Assignee: Kris Sterckx
>
> To avoid the use of an extra VM for the virtual router we implement 
> configdrive for userdata, metadata & password. 
> The configdrive ISO is created on the secondary store and the KVM & VMware 
> plugins are adapted to accept the configdrive ISO as second cdrom.
> Is applicable for isolated, VPC and shared networks.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CLOUDSTACK-10013) Migrate to Debian9 systemvmtemplate

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-10013:
-

rhtyd closed pull request #2395: CLOUDSTACK-10013: Enable debian security repos 
during systemvm building
URL: https://github.com/apache/cloudstack/pull/2395
 
 
   

This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:

As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):

diff --git a/tools/appliance/systemvmtemplate/scripts/apt_upgrade.sh 
b/tools/appliance/systemvmtemplate/scripts/apt_upgrade.sh
index 7387159696f..402bf21af2c 100644
--- a/tools/appliance/systemvmtemplate/scripts/apt_upgrade.sh
+++ b/tools/appliance/systemvmtemplate/scripts/apt_upgrade.sh
@@ -35,6 +35,7 @@ function add_backports() {
   sed -i '/deb-src/d' /etc/apt/sources.list
   sed -i '/backports/d' /etc/apt/sources.list
   echo 'deb http://http.debian.net/debian stretch-backports main' >> 
/etc/apt/sources.list
+  echo 'deb http://security.debian.org/debian-security stretch/updates main' 
>> /etc/apt/sources.list
 }
 
 function apt_upgrade() {


 


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Migrate to Debian9 systemvmtemplate
> ---
>
> Key: CLOUDSTACK-10013
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10013
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
> Fix For: 4.11.0.0
>
>
> Migrate to debian9 based systemvmtemplate



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CLOUDSTACK-10013) Migrate to Debian9 systemvmtemplate

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-10013:
-

rhtyd opened a new pull request #2395: CLOUDSTACK-10013: Enable debian security 
repos during systemvm building
URL: https://github.com/apache/cloudstack/pull/2395
 
 
   This enables the Debian security repos for stretch
   
   This is needed to build new 4.11 systemvmtemplates with the meltdown kernel 
fix. Please lgtm/review - @DaanHoogland @borisstoyanov @wido @rafaelweingartner 
@marcaurele and others.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Migrate to Debian9 systemvmtemplate
> ---
>
> Key: CLOUDSTACK-10013
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10013
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
> Fix For: 4.11.0.0
>
>
> Migrate to debian9 based systemvmtemplate



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CLOUDSTACK-4757) Support OVA files with multiple disks for templates

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-4757:


blueorangutan commented on issue #2146: CLOUDSTACK-4757: Support OVA files with 
multiple disks for templates
URL: https://github.com/apache/cloudstack/pull/2146#issuecomment-356241633
 
 
   Packaging result: ✔centos6 ✔centos7 ✔debian. JID-1634


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Support OVA files with multiple disks for templates
> ---
>
> Key: CLOUDSTACK-4757
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4757
> Project: CloudStack
>  Issue Type: New Feature
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Storage Controller
>Reporter: Likitha Shetty
>Assignee: Nicolas Vazquez
>Priority: Minor
> Fix For: Future
>
>
> CloudStack volumes and templates are one single virtual disk in case of 
> XenServer/XCP and KVM hypervisors since the files used for templates and 
> volumes are virtual disks (VHD, QCOW2). However, VMware volumes and templates 
> are in OVA format, which are archives that can contain a complete VM 
> including multiple VMDKs and other files such as ISOs. And currently, 
> Cloudstack only supports Template creation based on OVA files containing a 
> single disk. If a user creates a template from a OVA file containing more 
> than 1 disk and launches an instance using this template, only the first disk 
> is attached to the new instance and other disks are ignored.
> Similarly with uploaded volumes, attaching an uploaded volume that contains 
> multiple disks to a VM will result in only one VMDK to being attached to the 
> VM.
> This behavior needs to be improved in VMWare to support OVA files with 
> multiple disks for both uploaded volumes and templates. i.e. If a user 
> creates a template from a OVA file containing more than 1 disk and launches 
> an instance using this template, the first disk should be attached to the new 
> instance as the ROOT disk and volumes should be created based on other VMDK 
> disks in the OVA file and should be attached to the instance.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CLOUDSTACK-9813) Use configdrive for userdata, metadata & password

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9813:


rhtyd commented on issue #2097: [4.11] CLOUDSTACK-9813: Extending Config Drive 
support
URL: https://github.com/apache/cloudstack/pull/2097#issuecomment-356240262
 
 
   I've left some outstanding comments, please see @fmaximus @krissterckx . 
Thanks.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Use configdrive for userdata, metadata & password 
> --
>
> Key: CLOUDSTACK-9813
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9813
> Project: CloudStack
>  Issue Type: New Feature
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: KVM, Network Controller, Secondary Storage, SystemVM, 
> VMware
>Affects Versions: Future
>Reporter: Eric Waegeman
>Assignee: Kris Sterckx
>
> To avoid the use of an extra VM for the virtual router we implement 
> configdrive for userdata, metadata & password. 
> The configdrive ISO is created on the secondary store and the KVM & VMware 
> plugins are adapted to accept the configdrive ISO as second cdrom.
> Is applicable for isolated, VPC and shared networks.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CLOUDSTACK-9813) Use configdrive for userdata, metadata & password

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9813:


rhtyd commented on a change in pull request #2097: [4.11] CLOUDSTACK-9813: 
Extending Config Drive support
URL: https://github.com/apache/cloudstack/pull/2097#discussion_r160365198
 
 

 ##
 File path: tools/marvin/marvin/config/test_data.py
 ##
 @@ -2186,6 +2371,33 @@
 "Dns": "VpcVirtualRouter"
 }
 },
+"vpc_offering_configdrive_withoutdns": {
 
 Review comment:
   @krissterckx can you please get them moved to a specific test. Thanks.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Use configdrive for userdata, metadata & password 
> --
>
> Key: CLOUDSTACK-9813
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9813
> Project: CloudStack
>  Issue Type: New Feature
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: KVM, Network Controller, Secondary Storage, SystemVM, 
> VMware
>Affects Versions: Future
>Reporter: Eric Waegeman
>Assignee: Kris Sterckx
>
> To avoid the use of an extra VM for the virtual router we implement 
> configdrive for userdata, metadata & password. 
> The configdrive ISO is created on the secondary store and the KVM & VMware 
> plugins are adapted to accept the configdrive ISO as second cdrom.
> Is applicable for isolated, VPC and shared networks.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CLOUDSTACK-9813) Use configdrive for userdata, metadata & password

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9813:


rhtyd commented on a change in pull request #2097: [4.11] CLOUDSTACK-9813: 
Extending Config Drive support
URL: https://github.com/apache/cloudstack/pull/2097#discussion_r160364934
 
 

 ##
 File path: tools/marvin/marvin/config/test_data.py
 ##
 @@ -513,6 +565,19 @@
 "NetworkACL": 'VpcVirtualRouter'
 }
 },
+"vpc_offering_configdrive": {
+"name": 'VPC offering ConfigDrive',
+"displaytext": 'VPC offering ConfigDrive',
+"supportedservices": 
'Dhcp,StaticNat,SourceNat,NetworkACL,UserData,Dns',
+"serviceProviderList": {
+"Dhcp": "VpcVirtualRouter",
+"StaticNat": "VpcVirtualRouter",
+"SourceNat": "VpcVirtualRouter",
+"NetworkACL": "VpcVirtualRouter",
+"UserData": "ConfigDrive",
+"Dns": "VpcVirtualRouter"
+}
+},
 
 Review comment:
   @fmaximus can you move the test data to test itself? (for all the changes in 
test_data.py)


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Use configdrive for userdata, metadata & password 
> --
>
> Key: CLOUDSTACK-9813
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9813
> Project: CloudStack
>  Issue Type: New Feature
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: KVM, Network Controller, Secondary Storage, SystemVM, 
> VMware
>Affects Versions: Future
>Reporter: Eric Waegeman
>Assignee: Kris Sterckx
>
> To avoid the use of an extra VM for the virtual router we implement 
> configdrive for userdata, metadata & password. 
> The configdrive ISO is created on the secondary store and the KVM & VMware 
> plugins are adapted to accept the configdrive ISO as second cdrom.
> Is applicable for isolated, VPC and shared networks.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CLOUDSTACK-9813) Use configdrive for userdata, metadata & password

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9813:


rhtyd commented on a change in pull request #2097: [4.11] CLOUDSTACK-9813: 
Extending Config Drive support
URL: https://github.com/apache/cloudstack/pull/2097#discussion_r160364847
 
 

 ##
 File path: tools/marvin/marvin/config/test_data.py
 ##
 @@ -49,6 +49,27 @@
 "forvirtualnetwork": "true",
 "vlan": "300"
 },
+"publiciprange1": {
+"gateway": "10.200.100.1",
+"netmask": "255.255.255.0",
+"startip": "10.200.100.101",
+"endip": "10.200.100.105",
+"forvirtualnetwork": "false"
+},
+"publiciprange2": {
+"gateway": "10.219.1.1",
+"netmask": "255.255.255.0",
+"startip": "10.219.1.2",
+"endip": "10.219.1.5",
+"forvirtualnetwork": "false"
+},
+"publiciprange3": {
+"gateway": "10.200.100.1",
+"netmask": "255.255.255.0",
+"startip": "10.200.100.2",
+"endip": "10.200.100.20",
+"forvirtualnetwork": "false"
+},
 
 Review comment:
   @fmaximus can you move the test data to test itself?


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Use configdrive for userdata, metadata & password 
> --
>
> Key: CLOUDSTACK-9813
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9813
> Project: CloudStack
>  Issue Type: New Feature
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: KVM, Network Controller, Secondary Storage, SystemVM, 
> VMware
>Affects Versions: Future
>Reporter: Eric Waegeman
>Assignee: Kris Sterckx
>
> To avoid the use of an extra VM for the virtual router we implement 
> configdrive for userdata, metadata & password. 
> The configdrive ISO is created on the secondary store and the KVM & VMware 
> plugins are adapted to accept the configdrive ISO as second cdrom.
> Is applicable for isolated, VPC and shared networks.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CLOUDSTACK-9813) Use configdrive for userdata, metadata & password

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9813:


rhtyd commented on a change in pull request #2097: [4.11] CLOUDSTACK-9813: 
Extending Config Drive support
URL: https://github.com/apache/cloudstack/pull/2097#discussion_r160364763
 
 

 ##
 File path: tools/appliance/systemvmtemplate/scripts/configure_proxy.sh
 ##
 @@ -0,0 +1,38 @@
+#!/bin/bash
 
 Review comment:
   @fmaximus ^^


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Use configdrive for userdata, metadata & password 
> --
>
> Key: CLOUDSTACK-9813
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9813
> Project: CloudStack
>  Issue Type: New Feature
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: KVM, Network Controller, Secondary Storage, SystemVM, 
> VMware
>Affects Versions: Future
>Reporter: Eric Waegeman
>Assignee: Kris Sterckx
>
> To avoid the use of an extra VM for the virtual router we implement 
> configdrive for userdata, metadata & password. 
> The configdrive ISO is created on the secondary store and the KVM & VMware 
> plugins are adapted to accept the configdrive ISO as second cdrom.
> Is applicable for isolated, VPC and shared networks.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CLOUDSTACK-9813) Use configdrive for userdata, metadata & password

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9813:


rhtyd commented on a change in pull request #2097: [4.11] CLOUDSTACK-9813: 
Extending Config Drive support
URL: https://github.com/apache/cloudstack/pull/2097#discussion_r160364542
 
 

 ##
 File path: 
plugins/hypervisors/xenserver/src/com/cloud/hypervisor/xenserver/resource/wrapper/xenbase/CitrixPrepareForMigrationCommandWrapper.java
 ##
 @@ -47,7 +47,7 @@ public Answer execute(final PrepareForMigrationCommand 
command, final CitrixReso
 String configDriveLabel = vm.getConfigDriveLabel();
 
 if (configDriveLabel == null)  {
-configDriveLabel = "config";
+configDriveLabel = "config-2";
 
 Review comment:
   Why was the config drive label changed with a `-2` suffix?


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Use configdrive for userdata, metadata & password 
> --
>
> Key: CLOUDSTACK-9813
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9813
> Project: CloudStack
>  Issue Type: New Feature
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: KVM, Network Controller, Secondary Storage, SystemVM, 
> VMware
>Affects Versions: Future
>Reporter: Eric Waegeman
>Assignee: Kris Sterckx
>
> To avoid the use of an extra VM for the virtual router we implement 
> configdrive for userdata, metadata & password. 
> The configdrive ISO is created on the secondary store and the KVM & VMware 
> plugins are adapted to accept the configdrive ISO as second cdrom.
> Is applicable for isolated, VPC and shared networks.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CLOUDSTACK-4757) Support OVA files with multiple disks for templates

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-4757:


rhtyd commented on issue #2146: CLOUDSTACK-4757: Support OVA files with 
multiple disks for templates
URL: https://github.com/apache/cloudstack/pull/2146#issuecomment-355812751
 
 
   @blueorangutan package


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Support OVA files with multiple disks for templates
> ---
>
> Key: CLOUDSTACK-4757
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4757
> Project: CloudStack
>  Issue Type: New Feature
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Storage Controller
>Reporter: Likitha Shetty
>Assignee: Nicolas Vazquez
>Priority: Minor
> Fix For: Future
>
>
> CloudStack volumes and templates are one single virtual disk in case of 
> XenServer/XCP and KVM hypervisors since the files used for templates and 
> volumes are virtual disks (VHD, QCOW2). However, VMware volumes and templates 
> are in OVA format, which are archives that can contain a complete VM 
> including multiple VMDKs and other files such as ISOs. And currently, 
> Cloudstack only supports Template creation based on OVA files containing a 
> single disk. If a user creates a template from a OVA file containing more 
> than 1 disk and launches an instance using this template, only the first disk 
> is attached to the new instance and other disks are ignored.
> Similarly with uploaded volumes, attaching an uploaded volume that contains 
> multiple disks to a VM will result in only one VMDK to being attached to the 
> VM.
> This behavior needs to be improved in VMWare to support OVA files with 
> multiple disks for both uploaded volumes and templates. i.e. If a user 
> creates a template from a OVA file containing more than 1 disk and launches 
> an instance using this template, the first disk should be attached to the new 
> instance as the ROOT disk and volumes should be created based on other VMDK 
> disks in the OVA file and should be attached to the instance.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CLOUDSTACK-4757) Support OVA files with multiple disks for templates

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-4757:


blueorangutan commented on issue #2146: CLOUDSTACK-4757: Support OVA files with 
multiple disks for templates
URL: https://github.com/apache/cloudstack/pull/2146#issuecomment-355812800
 
 
   @rhtyd a Jenkins job has been kicked to build packages. I'll keep you posted 
as I make progress.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Support OVA files with multiple disks for templates
> ---
>
> Key: CLOUDSTACK-4757
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4757
> Project: CloudStack
>  Issue Type: New Feature
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Storage Controller
>Reporter: Likitha Shetty
>Assignee: Nicolas Vazquez
>Priority: Minor
> Fix For: Future
>
>
> CloudStack volumes and templates are one single virtual disk in case of 
> XenServer/XCP and KVM hypervisors since the files used for templates and 
> volumes are virtual disks (VHD, QCOW2). However, VMware volumes and templates 
> are in OVA format, which are archives that can contain a complete VM 
> including multiple VMDKs and other files such as ISOs. And currently, 
> Cloudstack only supports Template creation based on OVA files containing a 
> single disk. If a user creates a template from a OVA file containing more 
> than 1 disk and launches an instance using this template, only the first disk 
> is attached to the new instance and other disks are ignored.
> Similarly with uploaded volumes, attaching an uploaded volume that contains 
> multiple disks to a VM will result in only one VMDK to being attached to the 
> VM.
> This behavior needs to be improved in VMWare to support OVA files with 
> multiple disks for both uploaded volumes and templates. i.e. If a user 
> creates a template from a OVA file containing more than 1 disk and launches 
> an instance using this template, the first disk should be attached to the new 
> instance as the ROOT disk and volumes should be created based on other VMDK 
> disks in the OVA file and should be attached to the instance.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CLOUDSTACK-4757) Support OVA files with multiple disks for templates

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-4757:


blueorangutan commented on issue #2146: CLOUDSTACK-4757: Support OVA files with 
multiple disks for templates
URL: https://github.com/apache/cloudstack/pull/2146#issuecomment-355814305
 
 
   @rhtyd a Trillian-Jenkins test job (centos7 mgmt + vmware-55u3) has been 
kicked to run smoke tests


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Support OVA files with multiple disks for templates
> ---
>
> Key: CLOUDSTACK-4757
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4757
> Project: CloudStack
>  Issue Type: New Feature
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Storage Controller
>Reporter: Likitha Shetty
>Assignee: Nicolas Vazquez
>Priority: Minor
> Fix For: Future
>
>
> CloudStack volumes and templates are one single virtual disk in case of 
> XenServer/XCP and KVM hypervisors since the files used for templates and 
> volumes are virtual disks (VHD, QCOW2). However, VMware volumes and templates 
> are in OVA format, which are archives that can contain a complete VM 
> including multiple VMDKs and other files such as ISOs. And currently, 
> Cloudstack only supports Template creation based on OVA files containing a 
> single disk. If a user creates a template from a OVA file containing more 
> than 1 disk and launches an instance using this template, only the first disk 
> is attached to the new instance and other disks are ignored.
> Similarly with uploaded volumes, attaching an uploaded volume that contains 
> multiple disks to a VM will result in only one VMDK to being attached to the 
> VM.
> This behavior needs to be improved in VMWare to support OVA files with 
> multiple disks for both uploaded volumes and templates. i.e. If a user 
> creates a template from a OVA file containing more than 1 disk and launches 
> an instance using this template, the first disk should be attached to the new 
> instance as the ROOT disk and volumes should be created based on other VMDK 
> disks in the OVA file and should be attached to the instance.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CLOUDSTACK-4757) Support OVA files with multiple disks for templates

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-4757:


rhtyd commented on issue #2146: CLOUDSTACK-4757: Support OVA files with 
multiple disks for templates
URL: https://github.com/apache/cloudstack/pull/2146#issuecomment-355814287
 
 
   @blueorangutan test centos7 vmware-55u3


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Support OVA files with multiple disks for templates
> ---
>
> Key: CLOUDSTACK-4757
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4757
> Project: CloudStack
>  Issue Type: New Feature
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Storage Controller
>Reporter: Likitha Shetty
>Assignee: Nicolas Vazquez
>Priority: Minor
> Fix For: Future
>
>
> CloudStack volumes and templates are one single virtual disk in case of 
> XenServer/XCP and KVM hypervisors since the files used for templates and 
> volumes are virtual disks (VHD, QCOW2). However, VMware volumes and templates 
> are in OVA format, which are archives that can contain a complete VM 
> including multiple VMDKs and other files such as ISOs. And currently, 
> Cloudstack only supports Template creation based on OVA files containing a 
> single disk. If a user creates a template from a OVA file containing more 
> than 1 disk and launches an instance using this template, only the first disk 
> is attached to the new instance and other disks are ignored.
> Similarly with uploaded volumes, attaching an uploaded volume that contains 
> multiple disks to a VM will result in only one VMDK to being attached to the 
> VM.
> This behavior needs to be improved in VMWare to support OVA files with 
> multiple disks for both uploaded volumes and templates. i.e. If a user 
> creates a template from a OVA file containing more than 1 disk and launches 
> an instance using this template, the first disk should be attached to the new 
> instance as the ROOT disk and volumes should be created based on other VMDK 
> disks in the OVA file and should be attached to the instance.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CLOUDSTACK-4757) Support OVA files with multiple disks for templates

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-4757:


blueorangutan commented on issue #2146: CLOUDSTACK-4757: Support OVA files with 
multiple disks for templates
URL: https://github.com/apache/cloudstack/pull/2146#issuecomment-356234565
 
 
   @rhtyd a Jenkins job has been kicked to build packages. I'll keep you posted 
as I make progress.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Support OVA files with multiple disks for templates
> ---
>
> Key: CLOUDSTACK-4757
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4757
> Project: CloudStack
>  Issue Type: New Feature
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Storage Controller
>Reporter: Likitha Shetty
>Assignee: Nicolas Vazquez
>Priority: Minor
> Fix For: Future
>
>
> CloudStack volumes and templates are one single virtual disk in case of 
> XenServer/XCP and KVM hypervisors since the files used for templates and 
> volumes are virtual disks (VHD, QCOW2). However, VMware volumes and templates 
> are in OVA format, which are archives that can contain a complete VM 
> including multiple VMDKs and other files such as ISOs. And currently, 
> Cloudstack only supports Template creation based on OVA files containing a 
> single disk. If a user creates a template from a OVA file containing more 
> than 1 disk and launches an instance using this template, only the first disk 
> is attached to the new instance and other disks are ignored.
> Similarly with uploaded volumes, attaching an uploaded volume that contains 
> multiple disks to a VM will result in only one VMDK to being attached to the 
> VM.
> This behavior needs to be improved in VMWare to support OVA files with 
> multiple disks for both uploaded volumes and templates. i.e. If a user 
> creates a template from a OVA file containing more than 1 disk and launches 
> an instance using this template, the first disk should be attached to the new 
> instance as the ROOT disk and volumes should be created based on other VMDK 
> disks in the OVA file and should be attached to the instance.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CLOUDSTACK-4757) Support OVA files with multiple disks for templates

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-4757:


blueorangutan commented on issue #2146: CLOUDSTACK-4757: Support OVA files with 
multiple disks for templates
URL: https://github.com/apache/cloudstack/pull/2146#issuecomment-355814247
 
 
   Packaging result: ✔centos6 ✔centos7 ✔debian. JID-1611


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Support OVA files with multiple disks for templates
> ---
>
> Key: CLOUDSTACK-4757
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4757
> Project: CloudStack
>  Issue Type: New Feature
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Storage Controller
>Reporter: Likitha Shetty
>Assignee: Nicolas Vazquez
>Priority: Minor
> Fix For: Future
>
>
> CloudStack volumes and templates are one single virtual disk in case of 
> XenServer/XCP and KVM hypervisors since the files used for templates and 
> volumes are virtual disks (VHD, QCOW2). However, VMware volumes and templates 
> are in OVA format, which are archives that can contain a complete VM 
> including multiple VMDKs and other files such as ISOs. And currently, 
> Cloudstack only supports Template creation based on OVA files containing a 
> single disk. If a user creates a template from a OVA file containing more 
> than 1 disk and launches an instance using this template, only the first disk 
> is attached to the new instance and other disks are ignored.
> Similarly with uploaded volumes, attaching an uploaded volume that contains 
> multiple disks to a VM will result in only one VMDK to being attached to the 
> VM.
> This behavior needs to be improved in VMWare to support OVA files with 
> multiple disks for both uploaded volumes and templates. i.e. If a user 
> creates a template from a OVA file containing more than 1 disk and launches 
> an instance using this template, the first disk should be attached to the new 
> instance as the ROOT disk and volumes should be created based on other VMDK 
> disks in the OVA file and should be attached to the instance.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CLOUDSTACK-4757) Support OVA files with multiple disks for templates

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-4757:


rhtyd commented on issue #2146: CLOUDSTACK-4757: Support OVA files with 
multiple disks for templates
URL: https://github.com/apache/cloudstack/pull/2146#issuecomment-356234536
 
 
   @blueorangutan package
   
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Support OVA files with multiple disks for templates
> ---
>
> Key: CLOUDSTACK-4757
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4757
> Project: CloudStack
>  Issue Type: New Feature
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Storage Controller
>Reporter: Likitha Shetty
>Assignee: Nicolas Vazquez
>Priority: Minor
> Fix For: Future
>
>
> CloudStack volumes and templates are one single virtual disk in case of 
> XenServer/XCP and KVM hypervisors since the files used for templates and 
> volumes are virtual disks (VHD, QCOW2). However, VMware volumes and templates 
> are in OVA format, which are archives that can contain a complete VM 
> including multiple VMDKs and other files such as ISOs. And currently, 
> Cloudstack only supports Template creation based on OVA files containing a 
> single disk. If a user creates a template from a OVA file containing more 
> than 1 disk and launches an instance using this template, only the first disk 
> is attached to the new instance and other disks are ignored.
> Similarly with uploaded volumes, attaching an uploaded volume that contains 
> multiple disks to a VM will result in only one VMDK to being attached to the 
> VM.
> This behavior needs to be improved in VMWare to support OVA files with 
> multiple disks for both uploaded volumes and templates. i.e. If a user 
> creates a template from a OVA file containing more than 1 disk and launches 
> an instance using this template, the first disk should be attached to the new 
> instance as the ROOT disk and volumes should be created based on other VMDK 
> disks in the OVA file and should be attached to the instance.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CLOUDSTACK-10188) Resource Accounting for primary storage is Broken

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-10188:
-

bwsw commented on issue #2362: CLOUDSTACK-10188 - Resource Accounting for 
primary storage is Broken when Domains are in use
URL: https://github.com/apache/cloudstack/pull/2362#issuecomment-356234061
 
 
   @borisstoyanov, got it, not sure can find a time for additional research.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Resource Accounting for primary storage is Broken
> -
>
> Key: CLOUDSTACK-10188
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10188
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.9.0, 4.10.0.0, 4.11.0.0
>Reporter: Ivan Kudryavtsev
>
> During storage expunge domain resource statistics for primary storage space 
> resource counter is not updated for domain. This leads to the situation when 
> domain resource statistics for primary storage is overfilled (statistics only 
> increase but not decrease).
> Global scheduled task resourcecount.check.interval > 0 provides a workaround 
> but not fixes the problem truly because when accounts inside domains use 
> primary_storage allocation/deallocation intensively it leads to service block 
> of operation.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CLOUDSTACK-10188) Resource Accounting for primary storage is Broken

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-10188:
-

blueorangutan commented on issue #2362: CLOUDSTACK-10188 - Resource Accounting 
for primary storage is Broken when Domains are in use
URL: https://github.com/apache/cloudstack/pull/2362#issuecomment-356227990
 
 
   @rhtyd a Trillian-Jenkins test job (centos7 mgmt + kvm-centos7) has been 
kicked to run smoke tests


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Resource Accounting for primary storage is Broken
> -
>
> Key: CLOUDSTACK-10188
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10188
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.9.0, 4.10.0.0, 4.11.0.0
>Reporter: Ivan Kudryavtsev
>
> During storage expunge domain resource statistics for primary storage space 
> resource counter is not updated for domain. This leads to the situation when 
> domain resource statistics for primary storage is overfilled (statistics only 
> increase but not decrease).
> Global scheduled task resourcecount.check.interval > 0 provides a workaround 
> but not fixes the problem truly because when accounts inside domains use 
> primary_storage allocation/deallocation intensively it leads to service block 
> of operation.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CLOUDSTACK-10109) Enable dedication of public IPs to SSVM and CPVM

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-10109:
-

rhtyd commented on issue #2394: CLOUDSTACK-10109: Fix regression from PR #2295
URL: https://github.com/apache/cloudstack/pull/2394#issuecomment-356228072
 
 
   Thanks @DaanHoogland are you lgtm on it? (pending test results of course)


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Enable dedication of public IPs to SSVM and CPVM
> 
>
> Key: CLOUDSTACK-10109
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10109
> Project: CloudStack
>  Issue Type: New Feature
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Nicolas Vazquez
>Assignee: Nicolas Vazquez
> Attachments: public01.png, public02.png, public03.png
>
>
> It is required to dedicate a public IP range for SSVM and CPVM in order to 
> apply firewall rules to control inbound access.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CLOUDSTACK-10188) Resource Accounting for primary storage is Broken

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-10188:
-

rhtyd commented on issue #2362: CLOUDSTACK-10188 - Resource Accounting for 
primary storage is Broken when Domains are in use
URL: https://github.com/apache/cloudstack/pull/2362#issuecomment-356227786
 
 
   @bwsw it means one of the test cases from `test_volumes.py` - 
`test_07_resize_fail`, you can analyze why it failed from the marvin test logs 
- Marvin logs: 
https://github.com/blueorangutan/acs-prs/releases/download/trillian/pr2362-t2073-kvm-centos7.zip.
 It maybe most likely env related. I'll kick test again.
   @blueorangutan test


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Resource Accounting for primary storage is Broken
> -
>
> Key: CLOUDSTACK-10188
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10188
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.9.0, 4.10.0.0, 4.11.0.0
>Reporter: Ivan Kudryavtsev
>
> During storage expunge domain resource statistics for primary storage space 
> resource counter is not updated for domain. This leads to the situation when 
> domain resource statistics for primary storage is overfilled (statistics only 
> increase but not decrease).
> Global scheduled task resourcecount.check.interval > 0 provides a workaround 
> but not fixes the problem truly because when accounts inside domains use 
> primary_storage allocation/deallocation intensively it leads to service block 
> of operation.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CLOUDSTACK-10188) Resource Accounting for primary storage is Broken

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-10188:
-

bwsw commented on issue #2362: CLOUDSTACK-10188 - Resource Accounting for 
primary storage is Broken when Domains are in use
URL: https://github.com/apache/cloudstack/pull/2362#issuecomment-356224162
 
 
   @rhtyd 
   Hm, then what does it mean (copied from there):
   ```
   test_07_resize_fail | Failure | 15.42 | test_volumes.py
   ```
   
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Resource Accounting for primary storage is Broken
> -
>
> Key: CLOUDSTACK-10188
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10188
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.9.0, 4.10.0.0, 4.11.0.0
>Reporter: Ivan Kudryavtsev
>
> During storage expunge domain resource statistics for primary storage space 
> resource counter is not updated for domain. This leads to the situation when 
> domain resource statistics for primary storage is overfilled (statistics only 
> increase but not decrease).
> Global scheduled task resourcecount.check.interval > 0 provides a workaround 
> but not fixes the problem truly because when accounts inside domains use 
> primary_storage allocation/deallocation intensively it leads to service block 
> of operation.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CLOUDSTACK-10188) Resource Accounting for primary storage is Broken

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-10188:
-

blueorangutan commented on issue #2362: CLOUDSTACK-10188 - Resource Accounting 
for primary storage is Broken when Domains are in use
URL: https://github.com/apache/cloudstack/pull/2362#issuecomment-356224049
 
 
   Packaging result: ✔centos6 ✔centos7 ✔debian. JID-1633


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Resource Accounting for primary storage is Broken
> -
>
> Key: CLOUDSTACK-10188
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10188
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.9.0, 4.10.0.0, 4.11.0.0
>Reporter: Ivan Kudryavtsev
>
> During storage expunge domain resource statistics for primary storage space 
> resource counter is not updated for domain. This leads to the situation when 
> domain resource statistics for primary storage is overfilled (statistics only 
> increase but not decrease).
> Global scheduled task resourcecount.check.interval > 0 provides a workaround 
> but not fixes the problem truly because when accounts inside domains use 
> primary_storage allocation/deallocation intensively it leads to service block 
> of operation.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CLOUDSTACK-4757) Support OVA files with multiple disks for templates

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-4757:


blueorangutan commented on issue #2146: CLOUDSTACK-4757: Support OVA files with 
multiple disks for templates
URL: https://github.com/apache/cloudstack/pull/2146#issuecomment-356223098
 
 
   @borisstoyanov a Trillian-Jenkins test job (centos7 mgmt + vmware-55u3) has 
been kicked to run smoke tests


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Support OVA files with multiple disks for templates
> ---
>
> Key: CLOUDSTACK-4757
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4757
> Project: CloudStack
>  Issue Type: New Feature
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Storage Controller
>Reporter: Likitha Shetty
>Assignee: Nicolas Vazquez
>Priority: Minor
> Fix For: Future
>
>
> CloudStack volumes and templates are one single virtual disk in case of 
> XenServer/XCP and KVM hypervisors since the files used for templates and 
> volumes are virtual disks (VHD, QCOW2). However, VMware volumes and templates 
> are in OVA format, which are archives that can contain a complete VM 
> including multiple VMDKs and other files such as ISOs. And currently, 
> Cloudstack only supports Template creation based on OVA files containing a 
> single disk. If a user creates a template from a OVA file containing more 
> than 1 disk and launches an instance using this template, only the first disk 
> is attached to the new instance and other disks are ignored.
> Similarly with uploaded volumes, attaching an uploaded volume that contains 
> multiple disks to a VM will result in only one VMDK to being attached to the 
> VM.
> This behavior needs to be improved in VMWare to support OVA files with 
> multiple disks for both uploaded volumes and templates. i.e. If a user 
> creates a template from a OVA file containing more than 1 disk and launches 
> an instance using this template, the first disk should be attached to the new 
> instance as the ROOT disk and volumes should be created based on other VMDK 
> disks in the OVA file and should be attached to the instance.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CLOUDSTACK-4757) Support OVA files with multiple disks for templates

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-4757:


borisstoyanov commented on issue #2146: CLOUDSTACK-4757: Support OVA files with 
multiple disks for templates
URL: https://github.com/apache/cloudstack/pull/2146#issuecomment-356222856
 
 
   @blueorangutan test centos7 vmware-55u3


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Support OVA files with multiple disks for templates
> ---
>
> Key: CLOUDSTACK-4757
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4757
> Project: CloudStack
>  Issue Type: New Feature
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Storage Controller
>Reporter: Likitha Shetty
>Assignee: Nicolas Vazquez
>Priority: Minor
> Fix For: Future
>
>
> CloudStack volumes and templates are one single virtual disk in case of 
> XenServer/XCP and KVM hypervisors since the files used for templates and 
> volumes are virtual disks (VHD, QCOW2). However, VMware volumes and templates 
> are in OVA format, which are archives that can contain a complete VM 
> including multiple VMDKs and other files such as ISOs. And currently, 
> Cloudstack only supports Template creation based on OVA files containing a 
> single disk. If a user creates a template from a OVA file containing more 
> than 1 disk and launches an instance using this template, only the first disk 
> is attached to the new instance and other disks are ignored.
> Similarly with uploaded volumes, attaching an uploaded volume that contains 
> multiple disks to a VM will result in only one VMDK to being attached to the 
> VM.
> This behavior needs to be improved in VMWare to support OVA files with 
> multiple disks for both uploaded volumes and templates. i.e. If a user 
> creates a template from a OVA file containing more than 1 disk and launches 
> an instance using this template, the first disk should be attached to the new 
> instance as the ROOT disk and volumes should be created based on other VMDK 
> disks in the OVA file and should be attached to the instance.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CLOUDSTACK-10217) When IPv4 address of Instance is updated DHCP data is not cleared on VR

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-10217:
-

rhtyd commented on issue #2393: CLOUDSTACK-10217: Clean up old MAC addresses 
from DHCP lease file
URL: https://github.com/apache/cloudstack/pull/2393#issuecomment-356221978
 
 
   @blueorangutan test 


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> When IPv4 address of Instance is updated DHCP data is not cleared on VR
> ---
>
> Key: CLOUDSTACK-10217
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10217
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Virtual Router
>Affects Versions: 4.10.0.0
> Environment: Basic Networking - KVM
>Reporter: Wido den Hollander
>Assignee: Wido den Hollander
>  Labels: basic-networking, dhcp, virtual-router
> Fix For: 4.11.0.0
>
>
> When the IPv4 address of a NIC is changed the new entry is added to the DHCP 
> lease file in the Virtual Router, but the old entry (with the same MAC) is 
> not removed and this causes the Instance to still receive the old address.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CLOUDSTACK-10217) When IPv4 address of Instance is updated DHCP data is not cleared on VR

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-10217:
-

blueorangutan commented on issue #2393: CLOUDSTACK-10217: Clean up old MAC 
addresses from DHCP lease file
URL: https://github.com/apache/cloudstack/pull/2393#issuecomment-356222075
 
 
   @rhtyd a Trillian-Jenkins test job (centos7 mgmt + kvm-centos7) has been 
kicked to run smoke tests


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> When IPv4 address of Instance is updated DHCP data is not cleared on VR
> ---
>
> Key: CLOUDSTACK-10217
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10217
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Virtual Router
>Affects Versions: 4.10.0.0
> Environment: Basic Networking - KVM
>Reporter: Wido den Hollander
>Assignee: Wido den Hollander
>  Labels: basic-networking, dhcp, virtual-router
> Fix For: 4.11.0.0
>
>
> When the IPv4 address of a NIC is changed the new entry is added to the DHCP 
> lease file in the Virtual Router, but the old entry (with the same MAC) is 
> not removed and this causes the Instance to still receive the old address.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CLOUDSTACK-9813) Use configdrive for userdata, metadata & password

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9813:


blueorangutan commented on issue #2097: [4.11] CLOUDSTACK-9813: Extending 
Config Drive support
URL: https://github.com/apache/cloudstack/pull/2097#issuecomment-356220778
 
 
   Packaging result: ✔centos6 ✔centos7 ✔debian. JID-1632


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Use configdrive for userdata, metadata & password 
> --
>
> Key: CLOUDSTACK-9813
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9813
> Project: CloudStack
>  Issue Type: New Feature
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: KVM, Network Controller, Secondary Storage, SystemVM, 
> VMware
>Affects Versions: Future
>Reporter: Eric Waegeman
>Assignee: Kris Sterckx
>
> To avoid the use of an extra VM for the virtual router we implement 
> configdrive for userdata, metadata & password. 
> The configdrive ISO is created on the secondary store and the KVM & VMware 
> plugins are adapted to accept the configdrive ISO as second cdrom.
> Is applicable for isolated, VPC and shared networks.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CLOUDSTACK-10217) When IPv4 address of Instance is updated DHCP data is not cleared on VR

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-10217:
-

blueorangutan commented on issue #2393: CLOUDSTACK-10217: Clean up old MAC 
addresses from DHCP lease file
URL: https://github.com/apache/cloudstack/pull/2393#issuecomment-356220780
 
 
   Packaging result: ✔centos6 ✔centos7 ✔debian. JID-1631


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> When IPv4 address of Instance is updated DHCP data is not cleared on VR
> ---
>
> Key: CLOUDSTACK-10217
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10217
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Virtual Router
>Affects Versions: 4.10.0.0
> Environment: Basic Networking - KVM
>Reporter: Wido den Hollander
>Assignee: Wido den Hollander
>  Labels: basic-networking, dhcp, virtual-router
> Fix For: 4.11.0.0
>
>
> When the IPv4 address of a NIC is changed the new entry is added to the DHCP 
> lease file in the Virtual Router, but the old entry (with the same MAC) is 
> not removed and this causes the Instance to still receive the old address.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CLOUDSTACK-10109) Enable dedication of public IPs to SSVM and CPVM

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-10109:
-

DaanHoogland commented on issue #2394: CLOUDSTACK-10109: Fix regression from PR 
#2295
URL: https://github.com/apache/cloudstack/pull/2394#issuecomment-356219599
 
 
   good work @rhtyd thanks for clearing my faulty uderstanding


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Enable dedication of public IPs to SSVM and CPVM
> 
>
> Key: CLOUDSTACK-10109
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10109
> Project: CloudStack
>  Issue Type: New Feature
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Nicolas Vazquez
>Assignee: Nicolas Vazquez
> Attachments: public01.png, public02.png, public03.png
>
>
> It is required to dedicate a public IP range for SSVM and CPVM in order to 
> apply firewall rules to control inbound access.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CLOUDSTACK-4757) Support OVA files with multiple disks for templates

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-4757:


blueorangutan commented on issue #2146: CLOUDSTACK-4757: Support OVA files with 
multiple disks for templates
URL: https://github.com/apache/cloudstack/pull/2146#issuecomment-356219053
 
 
   Packaging result: ✔centos6 ✔centos7 ✔debian. JID-1630


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Support OVA files with multiple disks for templates
> ---
>
> Key: CLOUDSTACK-4757
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4757
> Project: CloudStack
>  Issue Type: New Feature
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Storage Controller
>Reporter: Likitha Shetty
>Assignee: Nicolas Vazquez
>Priority: Minor
> Fix For: Future
>
>
> CloudStack volumes and templates are one single virtual disk in case of 
> XenServer/XCP and KVM hypervisors since the files used for templates and 
> volumes are virtual disks (VHD, QCOW2). However, VMware volumes and templates 
> are in OVA format, which are archives that can contain a complete VM 
> including multiple VMDKs and other files such as ISOs. And currently, 
> Cloudstack only supports Template creation based on OVA files containing a 
> single disk. If a user creates a template from a OVA file containing more 
> than 1 disk and launches an instance using this template, only the first disk 
> is attached to the new instance and other disks are ignored.
> Similarly with uploaded volumes, attaching an uploaded volume that contains 
> multiple disks to a VM will result in only one VMDK to being attached to the 
> VM.
> This behavior needs to be improved in VMWare to support OVA files with 
> multiple disks for both uploaded volumes and templates. i.e. If a user 
> creates a template from a OVA file containing more than 1 disk and launches 
> an instance using this template, the first disk should be attached to the new 
> instance as the ROOT disk and volumes should be created based on other VMDK 
> disks in the OVA file and should be attached to the instance.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CLOUDSTACK-10109) Enable dedication of public IPs to SSVM and CPVM

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-10109:
-

rhtyd commented on a change in pull request #2394: CLOUDSTACK-10109: Fix 
regression from PR #2295
URL: https://github.com/apache/cloudstack/pull/2394#discussion_r160343510
 
 

 ##
 File path: scripts/vm/hypervisor/kvm/setup_agent.sh
 ##
 @@ -224,17 +224,5 @@ then
 setenforce 0
 fi
 
-which aria2c
-if [ $? -gt 0 ]
-then
-yum install epel-release -y
-yum install aria2 -y
-if [ $? -gt 0 ]
-then
-printf "failed to install aria2"
 
 Review comment:
   fyi - this is removed as installing cloudstack-agent will install aria2 and 
this script assumes a yum-enabled system that will fail on debian/ubuntu etc.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Enable dedication of public IPs to SSVM and CPVM
> 
>
> Key: CLOUDSTACK-10109
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10109
> Project: CloudStack
>  Issue Type: New Feature
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Nicolas Vazquez
>Assignee: Nicolas Vazquez
> Attachments: public01.png, public02.png, public03.png
>
>
> It is required to dedicate a public IP range for SSVM and CPVM in order to 
> apply firewall rules to control inbound access.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CLOUDSTACK-9885) VPC RVR: On deleting first tier and configuring Private GW both VRs becoming MASTER

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-9885:


rhtyd commented on issue #2128: CLOUDSTACK-9885: VPCVR: Updated to the private 
the traffic_type
URL: https://github.com/apache/cloudstack/pull/2128#issuecomment-356214216
 
 
   Given there is no engagement from the author and this issue is a specific 
case, does not block the release I'll move this to 4.12 milestone. /cc 
@jayapalu 


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> VPC RVR: On deleting first tier and configuring Private GW  both VRs becoming 
> MASTER
> 
>
> Key: CLOUDSTACK-9885
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9885
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.10.0.0
>Reporter: Jayapal Reddy
>Assignee: Jayapal Reddy
>Priority: Critical
> Fix For: 4.10.1.0
>
>
> - Configure two tier networks t1 and t2. Delete the t1 network. Both VRs are 
> getting  into MASTER state.
> r-269-QA - was BACKUP VR. On deleting t1 network it became MASTER.
> {noformat}
> root@r-269-QA:~# ip a
> 1: lo:  mtu 16436 qdisc noqueue state UNKNOWN
> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> inet 127.0.0.1/8 scope host lo
> 2: eth0:  mtu 1500 qdisc pfifo_fast state UP 
> qlen 1000
> link/ether 0e:00:a9:fe:01:dc brd ff:ff:ff:ff:ff:ff
> inet 169.254.1.220/16 brd 169.254.255.255 scope global eth0
> 3: eth1:  mtu 1500 qdisc pfifo_fast state DOWN qlen 1000
> link/ether 06:e4:c8:00:00:0e brd ff:ff:ff:ff:ff:ff
> inet 10.147.46.102/24 brd 10.147.46.255 scope global eth1
> 4: eth2:  mtu 1500 qdisc pfifo_fast state UP 
> qlen 1000
> link/ether 02:00:5d:a4:00:03 brd ff:ff:ff:ff:ff:ff
> inet 10.1.1.33/24 brd 10.1.1.255 scope global eth2
> 5: eth3:  mtu 1500 qdisc pfifo_fast state UP 
> qlen 1000
> link/ether 06:de:fc:00:00:29 brd ff:ff:ff:ff:ff:ff
> inet 10.147.52.200/24 brd 10.147.52.255 scope global eth3
> 6: eth4:  mtu 1500 qdisc pfifo_fast state UP 
> qlen 1000
> link/ether 02:00:31:e1:00:03 brd ff:ff:ff:ff:ff:ff
> inet 10.1.2.78/24 brd 10.1.2.255 scope global eth4
> root@r-269-QA:~#
> root@r-269-QA:~# ip a
> 1: lo:  mtu 16436 qdisc noqueue state UNKNOWN
> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> inet 127.0.0.1/8 scope host lo
> 2: eth0:  mtu 1500 qdisc pfifo_fast state UP 
> qlen 1000
> link/ether 0e:00:a9:fe:01:dc brd ff:ff:ff:ff:ff:ff
> inet 169.254.1.220/16 brd 169.254.255.255 scope global eth0
> 3: eth1:  mtu 1500 qdisc pfifo_fast state UP 
> qlen 1000
> link/ether 06:e4:c8:00:00:0e brd ff:ff:ff:ff:ff:ff
> inet 10.147.46.102/24 brd 10.147.46.255 scope global eth1
> 5: eth3:  mtu 1500 qdisc pfifo_fast state UP 
> qlen 1000
> link/ether 06:de:fc:00:00:29 brd ff:ff:ff:ff:ff:ff
> inet 10.147.52.200/24 brd 10.147.52.255 scope global eth3
> inet 10.147.52.100/24 brd 10.147.52.255 scope global secondary eth3
> 6: eth4:  mtu 1500 qdisc pfifo_fast state UP 
> qlen 1000
> link/ether 02:00:31:e1:00:03 brd ff:ff:ff:ff:ff:ff
> inet 10.1.2.78/24 brd 10.1.2.255 scope global eth4
> inet 10.1.2.1/24 brd 10.1.2.255 scope global secondary eth4
> root@r-269-QA:~# checkrouter.sh
> Status: MASTER
> root@r-269-QA:~#
> {noformat}
> root@r-268-QA - was MASTER VR. On deleting t1 it deleted its eth2 interface 
> and delete 10.2.1.1 ip on ethic interface.
>After some time it configured 10.2.1.1 ip on eth4 and it became master.
> {noformat}
> root@r-268-QA:~# ip a
> 1: lo:  mtu 16436 qdisc noqueue state UNKNOWN
> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> inet 127.0.0.1/8 scope host lo
> 2: eth0:  mtu 1500 qdisc pfifo_fast state UP 
> qlen 1000
> link/ether 0e:00:a9:fe:02:ac brd ff:ff:ff:ff:ff:ff
> inet 169.254.2.172/16 brd 169.254.255.255 scope global eth0
> 3: eth1:  mtu 1500 qdisc pfifo_fast state UP 
> qlen 1000
> link/ether 06:e4:c8:00:00:0e brd 

[jira] [Commented] (CLOUDSTACK-10188) Resource Accounting for primary storage is Broken

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-10188:
-

rhtyd commented on issue #2362: CLOUDSTACK-10188 - Resource Accounting for 
primary storage is Broken when Domains are in use
URL: https://github.com/apache/cloudstack/pull/2362#issuecomment-356213875
 
 
   Additional review requested - @DaanHoogland @borisstoyanov @wido @marcaurele 
@rafaelweingartner and others


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Resource Accounting for primary storage is Broken
> -
>
> Key: CLOUDSTACK-10188
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10188
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.9.0, 4.10.0.0, 4.11.0.0
>Reporter: Ivan Kudryavtsev
>
> During storage expunge domain resource statistics for primary storage space 
> resource counter is not updated for domain. This leads to the situation when 
> domain resource statistics for primary storage is overfilled (statistics only 
> increase but not decrease).
> Global scheduled task resourcecount.check.interval > 0 provides a workaround 
> but not fixes the problem truly because when accounts inside domains use 
> primary_storage allocation/deallocation intensively it leads to service block 
> of operation.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CLOUDSTACK-10188) Resource Accounting for primary storage is Broken

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-10188:
-

rhtyd commented on issue #2362: CLOUDSTACK-10188 - Resource Accounting for 
primary storage is Broken when Domains are in use
URL: https://github.com/apache/cloudstack/pull/2362#issuecomment-356213647
 
 
   Thanks @bwsw I'll investigate. meanwhile, rekick tests. However 
https://github.com/apache/cloudstack/pull/2379#issuecomment-356183984 does not 
have resize related failure.
   @blueorangutan package
 


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Resource Accounting for primary storage is Broken
> -
>
> Key: CLOUDSTACK-10188
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10188
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.9.0, 4.10.0.0, 4.11.0.0
>Reporter: Ivan Kudryavtsev
>
> During storage expunge domain resource statistics for primary storage space 
> resource counter is not updated for domain. This leads to the situation when 
> domain resource statistics for primary storage is overfilled (statistics only 
> increase but not decrease).
> Global scheduled task resourcecount.check.interval > 0 provides a workaround 
> but not fixes the problem truly because when accounts inside domains use 
> primary_storage allocation/deallocation intensively it leads to service block 
> of operation.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CLOUDSTACK-10188) Resource Accounting for primary storage is Broken

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-10188:
-

blueorangutan commented on issue #2362: CLOUDSTACK-10188 - Resource Accounting 
for primary storage is Broken when Domains are in use
URL: https://github.com/apache/cloudstack/pull/2362#issuecomment-356213709
 
 
   @rhtyd a Jenkins job has been kicked to build packages. I'll keep you posted 
as I make progress.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Resource Accounting for primary storage is Broken
> -
>
> Key: CLOUDSTACK-10188
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10188
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.9.0, 4.10.0.0, 4.11.0.0
>Reporter: Ivan Kudryavtsev
>
> During storage expunge domain resource statistics for primary storage space 
> resource counter is not updated for domain. This leads to the situation when 
> domain resource statistics for primary storage is overfilled (statistics only 
> increase but not decrease).
> Global scheduled task resourcecount.check.interval > 0 provides a workaround 
> but not fixes the problem truly because when accounts inside domains use 
> primary_storage allocation/deallocation intensively it leads to service block 
> of operation.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CLOUDSTACK-10188) Resource Accounting for primary storage is Broken

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-10188:
-

rhtyd commented on issue #2362: CLOUDSTACK-10188 - Resource Accounting for 
primary storage is Broken when Domains are in use
URL: https://github.com/apache/cloudstack/pull/2362#issuecomment-356213647
 
 
   Thanks @bwsw I'll investigate. meanwhile, rekick tests.
   @blueorangutan package


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Resource Accounting for primary storage is Broken
> -
>
> Key: CLOUDSTACK-10188
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10188
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.9.0, 4.10.0.0, 4.11.0.0
>Reporter: Ivan Kudryavtsev
>
> During storage expunge domain resource statistics for primary storage space 
> resource counter is not updated for domain. This leads to the situation when 
> domain resource statistics for primary storage is overfilled (statistics only 
> increase but not decrease).
> Global scheduled task resourcecount.check.interval > 0 provides a workaround 
> but not fixes the problem truly because when accounts inside domains use 
> primary_storage allocation/deallocation intensively it leads to service block 
> of operation.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CLOUDSTACK-8922) Unable to delete IP tag

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-8922:


yvsubhash commented on issue #905: BUG-ID: CLOUDSTACK-8922:  Unable to delete 
IP tag
URL: https://github.com/apache/cloudstack/pull/905#issuecomment-356213530
 
 
   closing this pr as #2350 takes care of this


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Unable to delete IP tag
> ---
>
> Key: CLOUDSTACK-8922
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8922
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.5.2
>Reporter: subhash yedugundla
>
> 1. Acquire new IP address 
> 2. Create tags for the IP 
> 3. Delete the tag from Step#2 
>  an error occurs at Step#3 whereby the delete tag operation fails with 
> "Acct[f4d0c381-e0b7-4aed-aa90-3336d42f7540-7100017] does not have 
> permission to operate within domain id\u003d632"
> TROUBLESHOOTING
> ==
> Acquire new IP address
> *
> {noformat}
> 2014-11-19 15:08:15,870 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
> (catalina-exec-20:ctx-faed32b5 ctx-712308cb ctx-401bfcaf) submit async 
> job-72419, details: AsyncJobVO {id:72419, userId: 17, accountId: 15, 
> instanceType: IpAddress, instanceId: 672, cmd: 
> org.apache.cloudstack.api.command.user.address.AssociateIPAddrCmd, cmdInfo: 
> {"id":"672","response":"json","cmdEventType":"NET.IPASSIGN","ctxUserId":"17","zoneid":"a117e75f-d02e-4074-806d-889c61261394","httpmethod":"GET","ctxAccountId":"15","networkid":"0ca7c69e-c281-407b-a152-2559c10a81a6","ctxStartEventId":"166725","signature":"3NZRU6dIBxg1HMDiP/MkY2agRn4\u003d","apikey":"tuwHXs1AfpQheJeJ9BcLdoVxIBCItASnguAbus76AMUcIXuyFgHOJiIB44fO57p_bBaqyfppmxrC-rQSb-nxXg"},
>  cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result: 
> null, initMsid: 345048681027, completeMsid: null, lastUpdated: null, 
> lastPolled: null, created: null}
> 2014-11-19 15:08:15,870 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
> (API-Job-Executor-68:ctx-fca9add6 job-72419) Executing AsyncJobVO {id:72419, 
> userId: 17, accountId: 15, instanceType: IpAddress, instanceId: 672, cmd: 
> org.apache.cloudstack.api.command.user.address.AssociateIPAddrCmd, cmdInfo: 
> {"id":"672","response":"json","cmdEventType":"NET.IPASSIGN","ctxUserId":"17","zoneid":"a117e75f-d02e-4074-806d-889c61261394","httpmethod":"GET","ctxAccountId":"15","networkid":"0ca7c69e-c281-407b-a152-2559c10a81a6","ctxStartEventId":"166725","signature":"3NZRU6dIBxg1HMDiP/MkY2agRn4\u003d","apikey":"tuwHXs1AfpQheJeJ9BcLdoVxIBCItASnguAbus76AMUcIXuyFgHOJiIB44fO57p_bBaqyfppmxrC-rQSb-nxXg"},
>  cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result: 
> null, initMsid: 345048681027, completeMsid: null, lastUpdated: null, 
> lastPolled: null, created: null}
> 2014-11-19 15:08:15,890 DEBUG [c.c.u.AccountManagerImpl] 
> (API-Job-Executor-68:ctx-fca9add6 job-72419 ctx-96bbdee5) Access to 
> Ntwk[216|Guest|8] granted to 
> Acct[f4d0c381-e0b7-4aed-aa90-3336d42f7540-7100017] by DomainChecker
> 2014-11-19 15:08:15,911 DEBUG [c.c.n.IpAddressManagerImpl] 
> (API-Job-Executor-68:ctx-fca9add6 job-72419 ctx-96bbdee5) Successfully 
> associated ip address 210.140.170.160 to network Ntwk[216|Guest|8]
> 2014-11-19 15:08:15,922 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
> (API-Job-Executor-68:ctx-fca9add6 job-72419 ctx-96bbdee5) Complete async 
> job-72419, jobStatus: SUCCEEDED, resultCode: 0, result: 
> org.apache.cloudstack.api.response.IPAddressResponse/ipaddress/{"id":"3d7c3a2a-1f2d-46dc-9905-4a7ce620e7e9","ipaddress":"210.140.170.160","allocated":"2014-11-19T15:08:15+0900","zoneid":"a117e75f-d02e-4074-806d-889c61261394","zonename":"tesla","issourcenat":false,"account":"7100017","domainid":"cc27e32c-6acd-4fdf-a1e5-734cef8a7fe0","domain":"7100017","forvirtualnetwork":true,"isstaticnat":false,"issystem":false,"associatednetworkid":"0ca7c69e-c281-407b-a152-2559c10a81a6","associatednetworkname":"network1","networkid":"79132c74-fe77-4bd5-9915-ce7c577fb95f","state":"Allocating","physicalnetworkid":"4a00ce42-6a30-4494-afdd-3531d883237b","tags":[],"isportable":false}
> 2014-11-19 15:08:15,932 INFO  [o.a.c.f.j.i.AsyncJobMonitor] 
> (API-Job-Executor-68:ctx-fca9add6 job-72419) Remove job-72419 from job 
> monitoring
> 

[jira] [Commented] (CLOUDSTACK-8922) Unable to delete IP tag

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-8922:


yvsubhash closed pull request #905: BUG-ID: CLOUDSTACK-8922:  Unable to delete 
IP tag
URL: https://github.com/apache/cloudstack/pull/905
 
 
   

This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:

As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):

diff --git a/.travis.yml b/.travis.yml
index b4749c05e31..b7b358c2e18 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -91,6 +91,7 @@ env:
  smoke/test_staticroles
  smoke/test_templates
  smoke/test_usage
+ smoke/test_tags
  smoke/test_usage_events
  smoke/test_vm_life_cycle
  smoke/test_vm_snapshots
@@ -144,8 +145,6 @@ env:
  component/test_stopped_vm"
 
 - TESTS="component/test_resource_limits"
-
-- TESTS="component/test_tags
  component/test_templates
  component/test_update_vm
  component/test_volumes"
diff --git a/server/src/com/cloud/tags/TaggedResourceManagerImpl.java 
b/server/src/com/cloud/tags/TaggedResourceManagerImpl.java
index 7528d6861dc..752adb517cd 100644
--- a/server/src/com/cloud/tags/TaggedResourceManagerImpl.java
+++ b/server/src/com/cloud/tags/TaggedResourceManagerImpl.java
@@ -299,21 +299,9 @@ public String getUuid(String resourceId, 
ResourceObjectType resourceType) {
 @DB
 @ActionEvent(eventType = EventTypes.EVENT_TAGS_DELETE, eventDescription = 
"deleting resource tags")
 public boolean deleteTags(List resourceIds, ResourceObjectType 
resourceType, Map tags) {
-Account caller = CallContext.current().getCallingAccount();
-
-SearchBuilder sb = 
_resourceTagDao.createSearchBuilder();
-sb.and().op("resourceId", sb.entity().getResourceId(), 
SearchCriteria.Op.IN);
-sb.or("resourceUuid", sb.entity().getResourceUuid(), 
SearchCriteria.Op.IN);
-sb.cp();
-sb.and("resourceType", sb.entity().getResourceType(), 
SearchCriteria.Op.EQ);
-
-SearchCriteria sc = sb.create();
-sc.setParameters("resourceId", resourceIds.toArray());
-sc.setParameters("resourceUuid", resourceIds.toArray());
-sc.setParameters("resourceType", resourceType);
 
-List resourceTags = _resourceTagDao.search(sc, 
null);
-;
+Account caller = CallContext.current().getCallingAccount();
+List resourceTags = 
getResourceTags(resourceIds, resourceType);
 final List tagsToRemove = new ArrayList();
 
 // Finalize which tags should be removed
@@ -363,6 +351,48 @@ public void doInTransactionWithoutResult(TransactionStatus 
status) {
 return true;
 }
 
+private List  getResourceTags(final List 
resourceIds, ResourceObjectType resourceType) {
+
+List uuids = new ArrayList();
+List internalIds = new ArrayList();
+for(String resourceId : resourceIds){
+
if(resourceId.matches("^[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$")){
+uuids.add(resourceId);
+}else{
+try {
+Long.parseLong(resourceId);
+} catch (final NumberFormatException e) {
+throw new InvalidParameterValueException("Invalid 
resourceId");
+}
+internalIds.add(resourceId);
+}
+}
+
+SearchBuilder sb = 
_resourceTagDao.createSearchBuilder();
+
+if(!uuids.isEmpty() && !internalIds.isEmpty()){
+throw new InvalidParameterValueException("Expecting only uuids or 
Ids");
+}else if (!uuids.isEmpty()){
+sb.and("resourceUuid", sb.entity().getResourceUuid(), 
SearchCriteria.Op.IN);
+}else if (!internalIds.isEmpty()){
+sb.and("resourceId", sb.entity().getResourceId(), 
SearchCriteria.Op.IN);
+}
+
+sb.and("resourceType", sb.entity().getResourceType(), 
SearchCriteria.Op.EQ);
+
+SearchCriteria sc = sb.create();
+
+if (!uuids.isEmpty()){
+sc.setParameters("resourceUuid", resourceIds.toArray());
+}else if (!internalIds.isEmpty()){
+sc.setParameters("resourceId", resourceIds.toArray());
+}
+
+sc.setParameters("resourceType", resourceType);
+return _resourceTagDao.search(sc, null);
+
+}
+
 @Override
 public List 
listByResourceTypeAndId(ResourceObjectType type, long resourceId) {
 return _resourceTagDao.listBy(resourceId, type);
diff --git a/test/integration/component/test_tags.py 
b/test/integration/smoke/test_tags.py
similarity index 89%
rename from 

[jira] [Commented] (CLOUDSTACK-10212) Changing IPv4 Address of NIC in Basic Networking does not update the gateway

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on CLOUDSTACK-10212:
--

Commit 35b43399467737c23ec8d1b1337f1bcfb8e88aa1 in cloudstack's branch 
refs/heads/master from [~widodh]
[ https://gitbox.apache.org/repos/asf?p=cloudstack.git;h=35b4339 ]

CLOUDSTACK-10212: Update Netmask/Gateway when Changing IPv4 address (#2388)

This can otherwise cause problems in Basic Networking where multiple
IPv4 ranges are configured in a POD.

Signed-off-by: Wido den Hollander 

> Changing IPv4 Address of NIC in Basic Networking does not update the gateway
> 
>
> Key: CLOUDSTACK-10212
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10212
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Network Controller
>Affects Versions: 4.10.0.0
> Environment: CloudStack 4.10 - KVM - Basic Networking
>Reporter: Wido den Hollander
>Assignee: Wido den Hollander
> Fix For: 4.11.0.0
>
>
> When using updateVMNic to change the IPv4 address of a NIC the IPv4 address 
> is changed, but the Gateway stays the same.
> This can cause problems when multiple IPv4 ranges are used and a wrong 
> gateway is issued to the Instance through DHCP.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CLOUDSTACK-10212) Changing IPv4 Address of NIC in Basic Networking does not update the gateway

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-10212:
-

rhtyd closed pull request #2388: CLOUDSTACK-10212: Update Netmask/Gateway when 
Changing IPv4 address
URL: https://github.com/apache/cloudstack/pull/2388
 
 
   

This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:

As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):

diff --git a/server/src/com/cloud/vm/UserVmManagerImpl.java 
b/server/src/com/cloud/vm/UserVmManagerImpl.java
index df9130c682d..b2978b1968f 100644
--- a/server/src/com/cloud/vm/UserVmManagerImpl.java
+++ b/server/src/com/cloud/vm/UserVmManagerImpl.java
@@ -137,6 +137,7 @@
 import com.cloud.dc.dao.DedicatedResourceDao;
 import com.cloud.dc.dao.HostPodDao;
 import com.cloud.dc.dao.VlanDao;
+import com.cloud.dc.Vlan;
 import com.cloud.dc.Vlan.VlanType;
 import com.cloud.dc.VlanVO;
 import com.cloud.deploy.DataCenterDeployment;
@@ -473,7 +474,7 @@
 @Inject
 private UserStatisticsDao _userStatsDao;
 @Inject
-private VlanDao _vlanDao;
+protected VlanDao _vlanDao;
 @Inject
 VolumeService _volService;
 @Inject
@@ -1565,6 +1566,12 @@ public UserVm 
updateNicIpForVirtualMachine(UpdateVmNicIpCmd cmd) {
 if (ipaddr == null) {
 throw new InvalidParameterValueException("Allocating ip to 
guest nic " + nicVO.getUuid() + " failed, please choose another ip");
 }
+
+final IPAddressVO newIp = 
_ipAddressDao.findByIpAndDcId(dc.getId(), ipaddr);
+final Vlan vlan = _vlanDao.findById(newIp.getVlanId());
+nicVO.setIPv4Gateway(vlan.getVlanGateway());
+nicVO.setIPv4Netmask(vlan.getVlanNetmask());
+
 final IPAddressVO ip = 
_ipAddressDao.findByIpAndSourceNetworkId(nicVO.getNetworkId(), 
nicVO.getIPv4Address());
 if (ip != null) {
 Transaction.execute(new TransactionCallbackNoReturn() {
@@ -1584,7 +1591,7 @@ public void 
doInTransactionWithoutResult(TransactionStatus status) {
 return null;
 }
 
-// update nic ipaddress
+s_logger.debug("Updating IPv4 address of NIC " + nicVO + " to " + 
ipaddr + "/" + nicVO.getIPv4Netmask() + " with gateway " + 
nicVO.getIPv4Gateway());
 nicVO.setIPv4Address(ipaddr);
 _nicDao.persist(nicVO);
 
diff --git a/server/test/com/cloud/vm/UserVmManagerTest.java 
b/server/test/com/cloud/vm/UserVmManagerTest.java
index 89555a2c8c8..c61d5cdce1d 100644
--- a/server/test/com/cloud/vm/UserVmManagerTest.java
+++ b/server/test/com/cloud/vm/UserVmManagerTest.java
@@ -42,6 +42,9 @@
 import java.util.Map;
 import java.util.UUID;
 
+import com.cloud.dc.VlanVO;
+import com.cloud.dc.dao.VlanDao;
+import com.cloud.network.dao.IPAddressVO;
 import com.cloud.network.element.UserDataServiceProvider;
 import com.cloud.storage.Storage;
 import com.cloud.user.User;
@@ -195,6 +198,8 @@
 @Mock
 NicDao _nicDao;
 @Mock
+VlanDao _vlanDao;
+@Mock
 NicVO _nicMock;
 @Mock
 NetworkModel _networkModel;
@@ -243,6 +248,7 @@ public void setup() {
 _userVmMgr._vmSnapshotDao = _vmSnapshotDao;
 _userVmMgr._configDao = _configDao;
 _userVmMgr._nicDao = _nicDao;
+_userVmMgr._vlanDao = _vlanDao;
 _userVmMgr._networkModel = _networkModel;
 _userVmMgr._networkDao = _networkDao;
 _userVmMgr._dcDao = _dcDao;
@@ -843,9 +849,18 @@ public void testUpdateVmNicIpSuccess2() throws Exception {
 when(_dcDao.findById(anyLong())).thenReturn(_dcMock);
 when(_dcMock.getNetworkType()).thenReturn(NetworkType.Advanced);
 
+IPAddressVO newIp = mock(IPAddressVO.class);
+when(newIp.getVlanId()).thenReturn(1L);
+
+VlanVO vlan = mock(VlanVO.class);
+when(vlan.getVlanGateway()).thenReturn("10.10.10.1");
+when(vlan.getVlanNetmask()).thenReturn("255.255.255.0");
+
 when(_ipAddrMgr.allocatePublicIpForGuestNic(Mockito.eq(_networkMock), 
anyLong(), Mockito.eq(_accountMock), anyString())).thenReturn("10.10.10.10");
 when(_ipAddressDao.findByIpAndSourceNetworkId(anyLong(), 
anyString())).thenReturn(null);
 when(_nicDao.persist(any(NicVO.class))).thenReturn(nic);
+when(_ipAddressDao.findByIpAndDcId(anyLong(), 
anyString())).thenReturn(newIp);
+when(_vlanDao.findById(anyLong())).thenReturn(vlan);
 
 Account caller = new AccountVO("testaccount", 1, "networkdomain", 
(short)0, UUID.randomUUID().toString());
 UserVO user = new UserVO(1, "testuser", "password", "firstname", 
"lastName", "email", "timezone", UUID.randomUUID().toString(), 
User.Source.UNKNOWN);


 

[jira] [Commented] (CLOUDSTACK-10212) Changing IPv4 Address of NIC in Basic Networking does not update the gateway

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on CLOUDSTACK-10212:
-

rhtyd commented on issue #2388: CLOUDSTACK-10212: Update Netmask/Gateway when 
Changing IPv4 address
URL: https://github.com/apache/cloudstack/pull/2388#issuecomment-356212656
 
 
   Tests LGTM, the one failure is env related.
   Merging this based on code reviews and test results.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Changing IPv4 Address of NIC in Basic Networking does not update the gateway
> 
>
> Key: CLOUDSTACK-10212
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10212
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Network Controller
>Affects Versions: 4.10.0.0
> Environment: CloudStack 4.10 - KVM - Basic Networking
>Reporter: Wido den Hollander
>Assignee: Wido den Hollander
> Fix For: 4.11.0.0
>
>
> When using updateVMNic to change the IPv4 address of a NIC the IPv4 address 
> is changed, but the Gateway stays the same.
> This can cause problems when multiple IPv4 ranges are used and a wrong 
> gateway is issued to the Instance through DHCP.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)