[jira] [Commented] (CLOUDSTACK-10146) Bypass Secondary Storage for KVM templates
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16309257#comment-16309257 ] ASF GitHub Bot commented on CLOUDSTACK-10146: - blueorangutan commented on issue #2379: CLOUDSTACK-10146: Bypass Secondary Storage for KVM templates URL: https://github.com/apache/cloudstack/pull/2379#issuecomment-354953130 @borisstoyanov a Trillian-Jenkins matrix job (centos6 mgmt + xs65sp1, centos7 mgmt + vmware55u3, centos7 mgmt + kvmcentos7) 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 > Bypass Secondary Storage for KVM templates > -- > > Key: CLOUDSTACK-10146 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10146 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.11.0.0 >Reporter: Nicolas Vazquez >Assignee: Nicolas Vazquez > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CLOUDSTACK-10146) Bypass Secondary Storage for KVM templates
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16309256#comment-16309256 ] ASF GitHub Bot commented on CLOUDSTACK-10146: - borisstoyanov commented on issue #2379: CLOUDSTACK-10146: Bypass Secondary Storage for KVM templates URL: https://github.com/apache/cloudstack/pull/2379#issuecomment-354953116 @blueorangutan test matrix 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 > Bypass Secondary Storage for KVM templates > -- > > Key: CLOUDSTACK-10146 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10146 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.11.0.0 >Reporter: Nicolas Vazquez >Assignee: Nicolas Vazquez > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CLOUDSTACK-4045) IP address acquired with associateIpAddress is marked as source NAT, causing disassociateIpAddress to fail later
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16309253#comment-16309253 ] ASF GitHub Bot commented on CLOUDSTACK-4045: blueorangutan commented on issue #2382: CLOUDSTACK-4045 URL: https://github.com/apache/cloudstack/pull/2382#issuecomment-354952773 @houthuis 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 > IP address acquired with associateIpAddress is marked as source NAT, causing > disassociateIpAddress to fail later > > > Key: CLOUDSTACK-4045 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4045 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.0.0, 4.0.1, 4.0.2, 4.1.0, 4.1.1, 4.2.0 >Reporter: Murali Reddy >Assignee: Murali Reddy > Fix For: Future > > > When you can create network, network is in allocated state. when network is > implemented CloudStack implicitly should acquire a public IP for source nat. > But there is assumption that first IP this is associated with network is > always for source NAT IP. So when you do > 1. create network (network is in allocated state) > 2. acquire a public IP and associate with the network > 3. disassociate ip address > #3 will fail because CloudStack marks the IP acquired in #1 to be source NAT. > For users this is counter-intutive because when a IP is acquired, he/she > should be able to release it as well. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CLOUDSTACK-4045) IP address acquired with associateIpAddress is marked as source NAT, causing disassociateIpAddress to fail later
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16309252#comment-16309252 ] ASF GitHub Bot commented on CLOUDSTACK-4045: houthuis commented on issue #2382: CLOUDSTACK-4045 URL: https://github.com/apache/cloudstack/pull/2382#issuecomment-354952738 @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 > IP address acquired with associateIpAddress is marked as source NAT, causing > disassociateIpAddress to fail later > > > Key: CLOUDSTACK-4045 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4045 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.0.0, 4.0.1, 4.0.2, 4.1.0, 4.1.1, 4.2.0 >Reporter: Murali Reddy >Assignee: Murali Reddy > Fix For: Future > > > When you can create network, network is in allocated state. when network is > implemented CloudStack implicitly should acquire a public IP for source nat. > But there is assumption that first IP this is associated with network is > always for source NAT IP. So when you do > 1. create network (network is in allocated state) > 2. acquire a public IP and associate with the network > 3. disassociate ip address > #3 will fail because CloudStack marks the IP acquired in #1 to be source NAT. > For users this is counter-intutive because when a IP is acquired, he/she > should be able to release it as well. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CLOUDSTACK-10146) Bypass Secondary Storage for KVM templates
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16309231#comment-16309231 ] ASF GitHub Bot commented on CLOUDSTACK-10146: - blueorangutan commented on issue #2379: CLOUDSTACK-10146: Bypass Secondary Storage for KVM templates URL: https://github.com/apache/cloudstack/pull/2379#issuecomment-354949660 Packaging result: ✔centos6 ✔centos7 ✔debian. JID-1549 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 > Bypass Secondary Storage for KVM templates > -- > > Key: CLOUDSTACK-10146 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10146 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.11.0.0 >Reporter: Nicolas Vazquez >Assignee: Nicolas Vazquez > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CLOUDSTACK-10146) Bypass Secondary Storage for KVM templates
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16309215#comment-16309215 ] ASF GitHub Bot commented on CLOUDSTACK-10146: - blueorangutan commented on issue #2379: CLOUDSTACK-10146: Bypass Secondary Storage for KVM templates URL: https://github.com/apache/cloudstack/pull/2379#issuecomment-354946827 @borisstoyanov 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 > Bypass Secondary Storage for KVM templates > -- > > Key: CLOUDSTACK-10146 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10146 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.11.0.0 >Reporter: Nicolas Vazquez >Assignee: Nicolas Vazquez > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CLOUDSTACK-10146) Bypass Secondary Storage for KVM templates
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16309214#comment-16309214 ] ASF GitHub Bot commented on CLOUDSTACK-10146: - borisstoyanov commented on issue #2379: CLOUDSTACK-10146: Bypass Secondary Storage for KVM templates URL: https://github.com/apache/cloudstack/pull/2379#issuecomment-354946761 @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 > Bypass Secondary Storage for KVM templates > -- > > Key: CLOUDSTACK-10146 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10146 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.11.0.0 >Reporter: Nicolas Vazquez >Assignee: Nicolas Vazquez > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CLOUDSTACK-9892) Primary storage resource check is broken when using root disk size override to deploy VM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16309197#comment-16309197 ] ASF GitHub Bot commented on CLOUDSTACK-9892: yvsubhash commented on issue #2088: CLOUDSTACK-9892: Primary storage resource check is broken when using … URL: https://github.com/apache/cloudstack/pull/2088#issuecomment-354943980 @rhtyd I am looking in to it. will respond shortly 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 > Primary storage resource check is broken when using root disk size override > to deploy VM > > > Key: CLOUDSTACK-9892 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9892 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.10.0.0 >Reporter: Koushik Das >Assignee: Koushik Das >Priority: Critical > Fix For: 4.11.0.0 > > > Primary storage resource check for account/domain is broken when using root > disk size override to deploy VM -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CLOUDSTACK-9921) NPE when garbage collector is running
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16309155#comment-16309155 ] ASF GitHub Bot commented on CLOUDSTACK-9921: jayakarteek commented on issue #2139: CLOUDSTACK-9921: NPE when storage garbage collector is running. URL: https://github.com/apache/cloudstack/pull/2139#issuecomment-354938090 @rhtyd I am looking in to issue 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 > NPE when garbage collector is running > - > > Key: CLOUDSTACK-9921 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9921 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: jay > > Steps to reproduce issue > 1. Deploy a VM > 2. Take snapshot of the root volume > 3. Delete the snapshot > 4. Before the garbage collector has run, shutdown the VM and assign the VM to > other user. > 5. When garage collector executes NPE shows in the logs. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CLOUDSTACK-10117) LDAP mapping on domain level
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16309029#comment-16309029 ] ASF GitHub Bot commented on CLOUDSTACK-10117: - blueorangutan commented on issue #2381: CLOUDSTACK-10117 Account ldap binding URL: https://github.com/apache/cloudstack/pull/2381#issuecomment-354924567 Trillian test result (tid-1975) Environment: kvm-centos7 (x2), Advanced Networking with Mgmt server 7 Total time taken: 38513 seconds Marvin logs: https://github.com/blueorangutan/acs-prs/releases/download/trillian/pr2381-t1975-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_hostha_kvm.py Smoke tests completed. 66 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 > LDAP mapping on domain level > > > Key: CLOUDSTACK-10117 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10117 > Project: CloudStack > Issue Type: New Feature > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Daan Hoogland > > see FS: > https://cwiki.apache.org/confluence/display/CLOUDSTACK/Domain+level+LDAP+bindinings -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CLOUDSTACK-10024) Physical Networking Migration
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10024?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16308879#comment-16308879 ] ASF GitHub Bot commented on CLOUDSTACK-10024: - blueorangutan commented on issue #2374: CLOUDSTACK-10024: Network Migration: Tackle review comments URL: https://github.com/apache/cloudstack/pull/2374#issuecomment-354902410 Trillian test result (tid-1969) Environment: kvm-centos7 (x2), Advanced Networking with Mgmt server 7 Total time taken: 38420 seconds Marvin logs: https://github.com/blueorangutan/acs-prs/releases/download/trillian/pr2374-t1969-kvm-centos7.zip Intermitten failure detected: /marvin/tests/smoke/test_privategw_acl.py Intermitten failure detected: /marvin/tests/smoke/test_ssvm.py Intermitten failure detected: /marvin/tests/smoke/test_vpc_redundant.py Smoke tests completed. 66 look OK, 1 have error(s) Only failed tests results shown below: Test | Result | Time (s) | Test File --- | --- | --- | --- test_03_ssvm_internals | `Failure` | 3.68 | test_ssvm.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 > Physical Networking Migration > - > > Key: CLOUDSTACK-10024 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10024 > Project: CloudStack > Issue Type: New Feature > Security Level: Public(Anyone can view this level - this is the > default.) > Components: API, KVM, Management Server, VMware >Reporter: Frank Maximus >Assignee: Frank Maximus > Fix For: 4.11.0.0 > > > *As a* Cloud Owner > *I want to* migrate my existing guest networks to another physical network > infrastructure > *In order to* leverage new network technologies, e.g. leverage SDN. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CLOUDSTACK-10207) updateVpnCustomerGateway: unexpected changes on optional keys
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16308795#comment-16308795 ] ASF GitHub Bot commented on CLOUDSTACK-10207: - blueorangutan commented on issue #2377: CLOUDSTACK-10207: updateVpnCustomerGateway: fix defaulting for option… URL: https://github.com/apache/cloudstack/pull/2377#issuecomment-354887256 Trillian test result (tid-1974) Environment: kvm-centos7 (x2), Advanced Networking with Mgmt server 7 Total time taken: 27861 seconds Marvin logs: https://github.com/blueorangutan/acs-prs/releases/download/trillian/pr2377-t1974-kvm-centos7.zip Intermitten failure detected: /marvin/tests/smoke/test_hostha_kvm.py Smoke tests completed. 65 look OK, 1 have error(s) Only failed tests results shown below: Test | Result | Time (s) | Test File --- | --- | --- | --- test_hostha_enable_ha_when_host_in_maintenance | `Error` | 1.16 | 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 > updateVpnCustomerGateway: unexpected changes on optional keys > - > > Key: CLOUDSTACK-10207 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10207 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: API >Reporter: René Moser >Assignee: René Moser >Priority: Minor > Fix For: 4.11.0.0 > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CLOUDSTACK-10108) ConfigKey based approach for reading 'ping' configuaration for Management Server
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16308693#comment-16308693 ] ASF GitHub Bot commented on CLOUDSTACK-10108: - blueorangutan commented on issue #2292: CLOUDSTACK-10108:ConfigKey based approach for reading 'ping' configua… URL: https://github.com/apache/cloudstack/pull/2292#issuecomment-354872486 Trillian test result (tid-1972) Environment: kvm-centos7 (x2), Advanced Networking with Mgmt server 7 Total time taken: 28117 seconds Marvin logs: https://github.com/blueorangutan/acs-prs/releases/download/trillian/pr2292-t1972-kvm-centos7.zip Intermitten failure detected: /marvin/tests/smoke/test_outofbandmanagement.py Intermitten failure detected: /marvin/tests/smoke/test_vpc_redundant.py Smoke tests completed. 64 look OK, 2 have error(s) Only failed tests results shown below: Test | Result | Time (s) | Test File --- | --- | --- | --- test_oobm_multiple_mgmt_server_ownership | `Error` | 0.15 | test_outofbandmanagement.py test_01_create_redundant_VPC_2tiers_4VMs_4IPs_4PF_ACL | `Failure` | 387.85 | test_vpc_redundant.py test_05_rvpc_multi_tiers | `Failure` | 341.31 | test_vpc_redundant.py test_05_rvpc_multi_tiers | `Error` | 387.09 | test_vpc_redundant.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 > ConfigKey based approach for reading 'ping' configuaration for Management > Server > > > Key: CLOUDSTACK-10108 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10108 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: mrunalini >Priority: Minor > > In CLOUDSTACK-9886, we are reading ping.interval and ping.timeout using > configdao which involves direct reading of DB. So, replace it with ConfigKey > based approach -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CLOUDSTACK-10104) Optimize database transactions in ListDomain API to improve performance
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16308676#comment-16308676 ] ASF GitHub Bot commented on CLOUDSTACK-10104: - blueorangutan commented on issue #2282: CLOUDSTACK-10104:Optimize database transactions in ListDomain API to improve performance URL: https://github.com/apache/cloudstack/pull/2282#issuecomment-354870130 Trillian test result (tid-1968) Environment: kvm-centos7 (x2), Advanced Networking with Mgmt server 7 Total time taken: 29253 seconds Marvin logs: https://github.com/blueorangutan/acs-prs/releases/download/trillian/pr2282-t1968-kvm-centos7.zip Intermitten failure detected: /marvin/tests/smoke/test_password_server.py Intermitten failure detected: /marvin/tests/smoke/test_vpc_redundant.py Intermitten failure detected: /marvin/tests/smoke/test_hostha_kvm.py Smoke tests completed. 64 look OK, 2 have error(s) Only failed tests results shown below: Test | Result | Time (s) | Test File --- | --- | --- | --- test_04_rvpc_network_garbage_collector_nics | `Failure` | 276.42 | test_vpc_redundant.py test_hostha_enable_ha_when_host_in_maintenance | `Error` | 1.26 | 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 > Optimize database transactions in ListDomain API to improve performance > --- > > Key: CLOUDSTACK-10104 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10104 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: API >Reporter: Pranali Mande > > While creating the response object for the 'listDomain' API, several database > calls are triggered to fetch details like parent domain, project limit, IP > limit, etc. These database calls are triggered for each record found for in > the main fetch query, which is causing the response to slow down. The > database transactions could be optimized to reduce the response time of the > Listdomain API -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CLOUDSTACK-7958) Limit user login to specific subnets
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7958?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16308425#comment-16308425 ] ASF GitHub Bot commented on CLOUDSTACK-7958: blueorangutan commented on issue #2046: CLOUDSTACK-7958: Add configuration for limit to CIDRs for Admin API calls URL: https://github.com/apache/cloudstack/pull/2046#issuecomment-354828226 @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 > 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] [Commented] (CLOUDSTACK-7958) Limit user login to specific subnets
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7958?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16308423#comment-16308423 ] ASF GitHub Bot commented on CLOUDSTACK-7958: rhtyd commented on issue #2046: CLOUDSTACK-7958: Add configuration for limit to CIDRs for Admin API calls URL: https://github.com/apache/cloudstack/pull/2046#issuecomment-354828040 @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 > 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] [Commented] (CLOUDSTACK-7958) Limit user login to specific subnets
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7958?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16308414#comment-16308414 ] ASF GitHub Bot commented on CLOUDSTACK-7958: blueorangutan commented on issue #2046: CLOUDSTACK-7958: Add configuration for limit to CIDRs for Admin API calls URL: https://github.com/apache/cloudstack/pull/2046#issuecomment-354826585 Packaging result: ✔centos6 ✔centos7 ✔debian. JID-1548 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 > 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] [Commented] (CLOUDSTACK-7958) Limit user login to specific subnets
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7958?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16308386#comment-16308386 ] ASF GitHub Bot commented on CLOUDSTACK-7958: blueorangutan commented on issue #2046: CLOUDSTACK-7958: Add configuration for limit to CIDRs for Admin API calls URL: https://github.com/apache/cloudstack/pull/2046#issuecomment-354819210 @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 > 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] [Commented] (CLOUDSTACK-7958) Limit user login to specific subnets
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7958?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16308385#comment-16308385 ] ASF GitHub Bot commented on CLOUDSTACK-7958: rhtyd commented on issue #2046: CLOUDSTACK-7958: Add configuration for limit to CIDRs for Admin API calls URL: https://github.com/apache/cloudstack/pull/2046#issuecomment-354819190 @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 > 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] [Commented] (CLOUDSTACK-7958) Limit user login to specific subnets
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7958?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16308383#comment-16308383 ] ASF GitHub Bot commented on CLOUDSTACK-7958: wido commented on issue #2046: CLOUDSTACK-7958: Add configuration for limit to CIDRs for Admin API calls URL: https://github.com/apache/cloudstack/pull/2046#issuecomment-354819088 Done! I'll be back at work next week 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 > 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] [Commented] (CLOUDSTACK-9813) Use configdrive for userdata, metadata & password
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16308344#comment-16308344 ] ASF GitHub Bot commented on CLOUDSTACK-9813: fmaximus commented on issue #2097: [4.11] CLOUDSTACK-9813: Extending Config Drive support URL: https://github.com/apache/cloudstack/pull/2097#issuecomment-354811387 Rebased, and to answer the question about PR #2116 This PR is not dependent on it, even more: As I mentioned on that #2116, it would make that PR unnecessary. 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-10188) Resource Accounting for primary storage is Broken
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16308270#comment-16308270 ] 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-354796499 @rhtyd I'll do it in a couple of days. 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-4045) IP address acquired with associateIpAddress is marked as source NAT, causing disassociateIpAddress to fail later
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16308147#comment-16308147 ] ASF GitHub Bot commented on CLOUDSTACK-4045: blueorangutan commented on issue #2382: CLOUDSTACK-4045 URL: https://github.com/apache/cloudstack/pull/2382#issuecomment-354779818 Packaging result: ✔centos6 ✔centos7 ✔debian. JID-1547 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 > IP address acquired with associateIpAddress is marked as source NAT, causing > disassociateIpAddress to fail later > > > Key: CLOUDSTACK-4045 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4045 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.0.0, 4.0.1, 4.0.2, 4.1.0, 4.1.1, 4.2.0 >Reporter: Murali Reddy >Assignee: Murali Reddy > Fix For: Future > > > When you can create network, network is in allocated state. when network is > implemented CloudStack implicitly should acquire a public IP for source nat. > But there is assumption that first IP this is associated with network is > always for source NAT IP. So when you do > 1. create network (network is in allocated state) > 2. acquire a public IP and associate with the network > 3. disassociate ip address > #3 will fail because CloudStack marks the IP acquired in #1 to be source NAT. > For users this is counter-intutive because when a IP is acquired, he/she > should be able to release it as well. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CLOUDSTACK-4757) Support OVA files with multiple disks for templates
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16308143#comment-16308143 ] 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-354779662 Packaging result: ✔centos6 ✔centos7 ✔debian. JID-1545 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-10126) Separate Subnet for CPVM and SSVM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16308144#comment-16308144 ] ASF GitHub Bot commented on CLOUDSTACK-10126: - blueorangutan commented on issue #2368: CLOUDSTACK-10126: Separate Subnet for SSVM and CPVM URL: https://github.com/apache/cloudstack/pull/2368#issuecomment-354779664 Packaging result: ✔centos6 ✔centos7 ✔debian. JID-1544 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 > Separate Subnet for CPVM and SSVM > - > > Key: CLOUDSTACK-10126 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10126 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.11.0.0 >Reporter: Nicolas Vazquez >Assignee: Nicolas Vazquez > > Separate Management Subnet for CPVM and SSVM -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CLOUDSTACK-9896) ListDedicatedXXX doesn't respect pagination
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16308142#comment-16308142 ] ASF GitHub Bot commented on CLOUDSTACK-9896: blueorangutan commented on issue #2073: CLOUDSTACK-9896: API: listDedicatedXXX should respect pagination URL: https://github.com/apache/cloudstack/pull/2073#issuecomment-354779661 Packaging result: ✔centos6 ✔centos7 ✔debian. JID-1543 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 > ListDedicatedXXX doesn't respect pagination > --- > > Key: CLOUDSTACK-9896 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9896 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: API >Reporter: Marc-Aurèle Brothier >Assignee: Marc-Aurèle Brothier >Priority: Minor > > The listDedicatedZones, listDedicatedPods, listDedicatedClusters, > listDedicatedHosts are not using the pagination filter to return the results. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CLOUDSTACK-4045) IP address acquired with associateIpAddress is marked as source NAT, causing disassociateIpAddress to fail later
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16308112#comment-16308112
]
ASF GitHub Bot commented on CLOUDSTACK-4045:
houthuis commented on a change in pull request #2382: CLOUDSTACK-4045
URL: https://github.com/apache/cloudstack/pull/2382#discussion_r159235216
##
File path: server/src/com/cloud/network/IpAddressManagerImpl.java
##
@@ -1394,6 +1380,25 @@ public IPAddressVO associateIPToGuestNetwork(long ipId,
long networkId, boolean
}
}
+protected boolean isSourceNatAvailableForNetwork(long networkId, Account
owner, IPAddressVO ipToAssoc, Network network) {
Review comment:
no, not really. must be a result of intellij's extract method
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
> IP address acquired with associateIpAddress is marked as source NAT, causing
> disassociateIpAddress to fail later
>
>
> Key: CLOUDSTACK-4045
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4045
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Affects Versions: 4.0.0, 4.0.1, 4.0.2, 4.1.0, 4.1.1, 4.2.0
>Reporter: Murali Reddy
>Assignee: Murali Reddy
> Fix For: Future
>
>
> When you can create network, network is in allocated state. when network is
> implemented CloudStack implicitly should acquire a public IP for source nat.
> But there is assumption that first IP this is associated with network is
> always for source NAT IP. So when you do
> 1. create network (network is in allocated state)
> 2. acquire a public IP and associate with the network
> 3. disassociate ip address
> #3 will fail because CloudStack marks the IP acquired in #1 to be source NAT.
> For users this is counter-intutive because when a IP is acquired, he/she
> should be able to release it as well.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CLOUDSTACK-4045) IP address acquired with associateIpAddress is marked as source NAT, causing disassociateIpAddress to fail later
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16308097#comment-16308097
]
ASF GitHub Bot commented on CLOUDSTACK-4045:
DaanHoogland commented on a change in pull request #2382: CLOUDSTACK-4045
URL: https://github.com/apache/cloudstack/pull/2382#discussion_r159233316
##
File path: server/test/com/cloud/network/IpAddressManagerTest.java
##
@@ -17,38 +17,109 @@
package com.cloud.network;
+import com.cloud.exception.InvalidParameterValueException;
+import com.cloud.exception.ResourceUnavailableException;
+import com.cloud.network.dao.IPAddressDao;
+import com.cloud.network.dao.IPAddressVO;
+import com.cloud.network.dao.NetworkDao;
+import com.cloud.network.dao.NetworkVO;
+import com.cloud.network.rules.StaticNat;
+import com.cloud.network.rules.StaticNatImpl;
+import com.cloud.offerings.NetworkOfferingVO;
+import com.cloud.offerings.dao.NetworkOfferingDao;
+import com.cloud.user.AccountVO;
+import com.cloud.utils.net.Ip;
import org.junit.Assert;
import org.junit.Before;
import org.junit.Test;
import org.mockito.InjectMocks;
import org.mockito.Mock;
+import org.mockito.Mockito;
import org.mockito.MockitoAnnotations;
-
-import com.cloud.network.dao.IPAddressDao;
-import com.cloud.network.dao.IPAddressVO;
-import com.cloud.network.rules.StaticNat;
-import com.cloud.network.rules.StaticNatImpl;
-import com.cloud.utils.net.Ip;
-
-import static org.mockito.Mockito.when;
+import org.mockito.Spy;
import java.util.Collections;
import java.util.List;
+import static org.junit.Assert.assertFalse;
+import static org.junit.Assert.assertTrue;
import static org.mockito.Mockito.anyLong;
+import static org.mockito.Mockito.doReturn;
import static org.mockito.Mockito.mock;
+import static org.mockito.Mockito.when;
public class IpAddressManagerTest {
@Mock
IPAddressDao _ipAddrDao;
+@Mock
+NetworkDao _networkDao;
+
+@Mock
+NetworkOfferingDao _networkOfferingDao;
+
+@Mock
+NetworkModel _networkModel;
+
+@Spy
@InjectMocks
IpAddressManagerImpl _ipManager;
+IPAddressVO ipAddressVO;
+
+NetworkVO networkAllocated;
+
+NetworkVO networkImplemented;
+
+NetworkVO networkNat;
+
+AccountVO account;
+
@Before
-public void setup() {
+public void setup() throws ResourceUnavailableException {
MockitoAnnotations.initMocks(this);
+
Review comment:
a lot of this mock data is test specific and should not be in the setup
method
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
> IP address acquired with associateIpAddress is marked as source NAT, causing
> disassociateIpAddress to fail later
>
>
> Key: CLOUDSTACK-4045
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4045
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Affects Versions: 4.0.0, 4.0.1, 4.0.2, 4.1.0, 4.1.1, 4.2.0
>Reporter: Murali Reddy
>Assignee: Murali Reddy
> Fix For: Future
>
>
> When you can create network, network is in allocated state. when network is
> implemented CloudStack implicitly should acquire a public IP for source nat.
> But there is assumption that first IP this is associated with network is
> always for source NAT IP. So when you do
> 1. create network (network is in allocated state)
> 2. acquire a public IP and associate with the network
> 3. disassociate ip address
> #3 will fail because CloudStack marks the IP acquired in #1 to be source NAT.
> For users this is counter-intutive because when a IP is acquired, he/she
> should be able to release it as well.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CLOUDSTACK-4045) IP address acquired with associateIpAddress is marked as source NAT, causing disassociateIpAddress to fail later
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16308095#comment-16308095
]
ASF GitHub Bot commented on CLOUDSTACK-4045:
DaanHoogland commented on a change in pull request #2382: CLOUDSTACK-4045
URL: https://github.com/apache/cloudstack/pull/2382#discussion_r159233140
##
File path: server/src/com/cloud/network/IpAddressManagerImpl.java
##
@@ -1394,6 +1380,25 @@ public IPAddressVO associateIPToGuestNetwork(long ipId,
long networkId, boolean
}
}
+protected boolean isSourceNatAvailableForNetwork(long networkId, Account
owner, IPAddressVO ipToAssoc, Network network) {
Review comment:
is networkId needed on this signature? network is being passed as well!
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
> IP address acquired with associateIpAddress is marked as source NAT, causing
> disassociateIpAddress to fail later
>
>
> Key: CLOUDSTACK-4045
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4045
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Affects Versions: 4.0.0, 4.0.1, 4.0.2, 4.1.0, 4.1.1, 4.2.0
>Reporter: Murali Reddy
>Assignee: Murali Reddy
> Fix For: Future
>
>
> When you can create network, network is in allocated state. when network is
> implemented CloudStack implicitly should acquire a public IP for source nat.
> But there is assumption that first IP this is associated with network is
> always for source NAT IP. So when you do
> 1. create network (network is in allocated state)
> 2. acquire a public IP and associate with the network
> 3. disassociate ip address
> #3 will fail because CloudStack marks the IP acquired in #1 to be source NAT.
> For users this is counter-intutive because when a IP is acquired, he/she
> should be able to release it as well.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CLOUDSTACK-4045) IP address acquired with associateIpAddress is marked as source NAT, causing disassociateIpAddress to fail later
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16308096#comment-16308096
]
ASF GitHub Bot commented on CLOUDSTACK-4045:
DaanHoogland commented on a change in pull request #2382: CLOUDSTACK-4045
URL: https://github.com/apache/cloudstack/pull/2382#discussion_r159233471
##
File path: server/test/com/cloud/network/IpAddressManagerTest.java
##
@@ -17,38 +17,109 @@
package com.cloud.network;
+import com.cloud.exception.InvalidParameterValueException;
+import com.cloud.exception.ResourceUnavailableException;
+import com.cloud.network.dao.IPAddressDao;
+import com.cloud.network.dao.IPAddressVO;
+import com.cloud.network.dao.NetworkDao;
+import com.cloud.network.dao.NetworkVO;
+import com.cloud.network.rules.StaticNat;
+import com.cloud.network.rules.StaticNatImpl;
+import com.cloud.offerings.NetworkOfferingVO;
+import com.cloud.offerings.dao.NetworkOfferingDao;
+import com.cloud.user.AccountVO;
+import com.cloud.utils.net.Ip;
import org.junit.Assert;
import org.junit.Before;
import org.junit.Test;
import org.mockito.InjectMocks;
import org.mockito.Mock;
+import org.mockito.Mockito;
import org.mockito.MockitoAnnotations;
-
-import com.cloud.network.dao.IPAddressDao;
-import com.cloud.network.dao.IPAddressVO;
-import com.cloud.network.rules.StaticNat;
-import com.cloud.network.rules.StaticNatImpl;
-import com.cloud.utils.net.Ip;
-
-import static org.mockito.Mockito.when;
+import org.mockito.Spy;
import java.util.Collections;
import java.util.List;
+import static org.junit.Assert.assertFalse;
+import static org.junit.Assert.assertTrue;
import static org.mockito.Mockito.anyLong;
+import static org.mockito.Mockito.doReturn;
import static org.mockito.Mockito.mock;
+import static org.mockito.Mockito.when;
public class IpAddressManagerTest {
@Mock
IPAddressDao _ipAddrDao;
+@Mock
+NetworkDao _networkDao;
+
+@Mock
+NetworkOfferingDao _networkOfferingDao;
+
+@Mock
+NetworkModel _networkModel;
+
+@Spy
@InjectMocks
IpAddressManagerImpl _ipManager;
+IPAddressVO ipAddressVO;
+
+NetworkVO networkAllocated;
+
+NetworkVO networkImplemented;
+
+NetworkVO networkNat;
+
+AccountVO account;
+
@Before
-public void setup() {
+public void setup() throws ResourceUnavailableException {
MockitoAnnotations.initMocks(this);
+
+ipAddressVO = new IPAddressVO(new Ip("192.0.0.1"), 1L, 1L, 1L,false);
+ipAddressVO.setAllocatedToAccountId(1L);
+
+IPAddressVO sourceNat = new IPAddressVO(new Ip("192.0.0.2"), 1L, 1L,
1L,true);
+
+networkAllocated = Mockito.mock(NetworkVO.class);
+
when(networkAllocated.getTrafficType()).thenReturn(Networks.TrafficType.Guest);
+when(networkAllocated.getNetworkOfferingId()).thenReturn(8L);
+when(networkAllocated.getState()).thenReturn(Network.State.Allocated);
+
when(networkAllocated.getGuestType()).thenReturn(Network.GuestType.Isolated);
+when(networkAllocated.getVpcId()).thenReturn(null);
+
+networkImplemented = Mockito.mock(NetworkVO.class);
+
when(networkImplemented.getTrafficType()).thenReturn(Networks.TrafficType.Guest);
+when(networkImplemented.getNetworkOfferingId()).thenReturn(8L);
+
when(networkImplemented.getState()).thenReturn(Network.State.Implemented);
+
when(networkImplemented.getGuestType()).thenReturn(Network.GuestType.Isolated);
+when(networkImplemented.getVpcId()).thenReturn(null);
+
+networkNat = Mockito.mock(NetworkVO.class);
+
when(networkNat.getTrafficType()).thenReturn(Networks.TrafficType.Guest);
+when(networkNat.getNetworkOfferingId()).thenReturn(8L);
+when(networkNat.getState()).thenReturn(Network.State.Implemented);
+when(networkNat.getGuestType()).thenReturn(Network.GuestType.Isolated);
+when(networkNat.getId()).thenReturn(3L);
+when(networkNat.getVpcId()).thenReturn(null);
+
+account = new AccountVO("admin", 1L, null, (short) 1, 1L,
"c65a73d5-ebbd-11e7-8f45-107b44277808");
+account.setId(1L);
+
+NetworkOfferingVO networkOfferingVO =
Mockito.mock(NetworkOfferingVO.class);
+networkOfferingVO.setSharedSourceNat(false);
+
+Mockito.when(_networkDao.findById(1L)).thenReturn(networkAllocated);
Review comment:
the ids of networkAllocated and networkImplemented are mixed up in
comparison with the test methods
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
> IP address acquired with associateIpAddress is marked as source NAT, causing
>
[jira] [Commented] (CLOUDSTACK-9025) Unable to deploy VM instance from template if template spin from linked clone snapshot
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16308093#comment-16308093 ] ASF GitHub Bot commented on CLOUDSTACK-9025: blueorangutan commented on issue #2315: A comprehensive solution for CLOUDSTACK-9025 and CLOUDSTACK-10128. URL: https://github.com/apache/cloudstack/pull/2315#issuecomment-354774294 Packaging result: ✔centos6 ✔centos7 ✔debian. JID-1542 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 deploy VM instance from template if template spin from linked clone > snapshot > -- > > Key: CLOUDSTACK-9025 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9025 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: XenServer >Affects Versions: 4.5.2 > Environment: XenServer 6.5 >Reporter: Anshul Gangwar >Assignee: Anshul Gangwar >Priority: Critical > Fix For: 4.6.0 > > > As default, CloudStack create linked clone snapshot for VM instance . When we > take a snapshot for the VM, and create a template based on such snapshot, > CloudStack only download incremental VHD as template file, as a result, the > VM instance fail to deploy as it is incomplete. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CLOUDSTACK-4045) IP address acquired with associateIpAddress is marked as source NAT, causing disassociateIpAddress to fail later
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16308072#comment-16308072 ] ASF GitHub Bot commented on CLOUDSTACK-4045: blueorangutan commented on issue #2382: CLOUDSTACK-4045 URL: https://github.com/apache/cloudstack/pull/2382#issuecomment-354770063 @PaulAngus 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 > IP address acquired with associateIpAddress is marked as source NAT, causing > disassociateIpAddress to fail later > > > Key: CLOUDSTACK-4045 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4045 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.0.0, 4.0.1, 4.0.2, 4.1.0, 4.1.1, 4.2.0 >Reporter: Murali Reddy >Assignee: Murali Reddy > Fix For: Future > > > When you can create network, network is in allocated state. when network is > implemented CloudStack implicitly should acquire a public IP for source nat. > But there is assumption that first IP this is associated with network is > always for source NAT IP. So when you do > 1. create network (network is in allocated state) > 2. acquire a public IP and associate with the network > 3. disassociate ip address > #3 will fail because CloudStack marks the IP acquired in #1 to be source NAT. > For users this is counter-intutive because when a IP is acquired, he/she > should be able to release it as well. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CLOUDSTACK-4045) IP address acquired with associateIpAddress is marked as source NAT, causing disassociateIpAddress to fail later
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16308071#comment-16308071 ] ASF GitHub Bot commented on CLOUDSTACK-4045: PaulAngus commented on issue #2382: CLOUDSTACK-4045 URL: https://github.com/apache/cloudstack/pull/2382#issuecomment-354769968 @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 > IP address acquired with associateIpAddress is marked as source NAT, causing > disassociateIpAddress to fail later > > > Key: CLOUDSTACK-4045 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4045 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.0.0, 4.0.1, 4.0.2, 4.1.0, 4.1.1, 4.2.0 >Reporter: Murali Reddy >Assignee: Murali Reddy > Fix For: Future > > > When you can create network, network is in allocated state. when network is > implemented CloudStack implicitly should acquire a public IP for source nat. > But there is assumption that first IP this is associated with network is > always for source NAT IP. So when you do > 1. create network (network is in allocated state) > 2. acquire a public IP and associate with the network > 3. disassociate ip address > #3 will fail because CloudStack marks the IP acquired in #1 to be source NAT. > For users this is counter-intutive because when a IP is acquired, he/she > should be able to release it as well. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CLOUDSTACK-9906) Create snapshot after volume resize for the volume with existing snapshot(s)
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16308055#comment-16308055 ] ASF GitHub Bot commented on CLOUDSTACK-9906: blueorangutan commented on issue #2079: CLOUDSTACK-9906 Create snapshot after volume resize for the volume with existing snapshot(s) URL: https://github.com/apache/cloudstack/pull/2079#issuecomment-354767793 Packaging result: ✔centos6 ✔centos7 ✔debian. JID-1541 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 > Create snapshot after volume resize for the volume with existing snapshot(s) > > > Key: CLOUDSTACK-9906 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9906 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Snapshot, Volumes > Environment: XenServer >Reporter: Suresh Kumar Anaparti >Assignee: Suresh Kumar Anaparti > > Snapshot of a volume fails if the volume has an existing snapshot(s) taken > before resizing of the volume. This behavior needs to be improved so that > taking snapshot would be successful when there is an existing snapshot(s) > before volume resizing. > REPRO STEPS > = > - Create a volume with 10 GB and attach to any VM. > - Take snapshot of the volume. > - Change volume size from 10GB to 15 GB. > - Take snapshot of the volume after resizing it. > - Create a volume from the snapshot taken after resizing volume. > - Attach the volume (created above) to any VM and check the size. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CLOUDSTACK-9607) Preventing template deletion when template is in use.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9607?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16308051#comment-16308051 ] ASF GitHub Bot commented on CLOUDSTACK-9607: blueorangutan commented on issue #1773: CLOUDSTACK-9607: Preventing template deletion when template is in use. URL: https://github.com/apache/cloudstack/pull/1773#issuecomment-354767129 Packaging result: ✔centos6 ✔centos7 ✔debian. JID-1540 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 > Preventing template deletion when template is in use. > - > > Key: CLOUDSTACK-9607 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9607 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Priyank Parihar >Assignee: Priyank Parihar > > Consider this scenario: > 1. User launches a VM from Template and keep it running > 2. Admin logins and deleted that template [CloudPlatform does not check > existing / running VM etc. while the deletion is done] > 3. User resets the VM > 4. CloudPlatform fails to star the VM as it cannot find the corresponding > template. > It throws error as > java.lang.RuntimeException: Job failed due to exception Resource [Host:11] is > unreachable: Host 11: Unable to start instance due to can't find ready > template: 209 for data center 1 > at > com.cloud.vm.VmWorkJobDispatcher.runJob(VmWorkJobDispatcher.java:113) > at > org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:495) > Client is requesting better handing of this scenario. We need to check > existing / running VM's when the template is deleted and warn admin about the > possible issue that may occur. > REPRO STEPS > == > 1. Launches a VM from Template and keep it running > 2. Now delete that template > 3. Reset the VM > 4. CloudPlatform fails to star the VM as it cannot find the corresponding > template. > EXPECTED BEHAVIOR > == > Cloud platform should throw some warning message while the template is > deleted if that template is being used by existing / running VM's > ACTUAL BEHAVIOR > == > Cloud platform does not throw as waring etc. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CLOUDSTACK-9730) [VMware] Unable to add a host with space in its name to existing VMware cluster
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16308050#comment-16308050 ] ASF GitHub Bot commented on CLOUDSTACK-9730: blueorangutan commented on issue #1891: CLOUDSTACK-9730: [VMware] Unable to add a host with space in its name to existing VMware cluster URL: https://github.com/apache/cloudstack/pull/1891#issuecomment-354767130 Packaging result: ✔centos6 ✔centos7 ✔debian. JID-1539 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 > [VMware] Unable to add a host with space in its name to existing VMware > cluster > --- > > Key: CLOUDSTACK-9730 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9730 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: VMware >Reporter: Suresh Kumar Anaparti >Assignee: Suresh Kumar Anaparti > Fix For: 4.10.1.0 > > > ISSUE > == > Unable to add a host with space in the name to existing VMware cluster. > While adding host, CloudStack tries to persist the validated inventory url > path in database, which inserts encoded url into database which means > whitespace would be stored as '+' symbols. Url from API parameter string is > being converted to URI object as part of validation, where the url path is > getting encoded. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CLOUDSTACK-10126) Separate Subnet for CPVM and SSVM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16308014#comment-16308014 ] ASF GitHub Bot commented on CLOUDSTACK-10126: - rhtyd commented on issue #2368: CLOUDSTACK-10126: Separate Subnet for SSVM and CPVM URL: https://github.com/apache/cloudstack/pull/2368#issuecomment-354762565 @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 > Separate Subnet for CPVM and SSVM > - > > Key: CLOUDSTACK-10126 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10126 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.11.0.0 >Reporter: Nicolas Vazquez >Assignee: Nicolas Vazquez > > Separate Management Subnet for CPVM and SSVM -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CLOUDSTACK-4757) Support OVA files with multiple disks for templates
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16308016#comment-16308016 ] 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-354762645 @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-9813) Use configdrive for userdata, metadata & password
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16308013#comment-16308013 ] 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-354762541 @fmaximus can you fix the conflicts? 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-10126) Separate Subnet for CPVM and SSVM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16308015#comment-16308015 ] ASF GitHub Bot commented on CLOUDSTACK-10126: - blueorangutan commented on issue #2368: CLOUDSTACK-10126: Separate Subnet for SSVM and CPVM URL: https://github.com/apache/cloudstack/pull/2368#issuecomment-354762633 @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 > Separate Subnet for CPVM and SSVM > - > > Key: CLOUDSTACK-10126 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10126 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.11.0.0 >Reporter: Nicolas Vazquez >Assignee: Nicolas Vazquez > > Separate Management Subnet for CPVM and SSVM -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CLOUDSTACK-7958) Limit user login to specific subnets
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7958?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16308010#comment-16308010 ] ASF GitHub Bot commented on CLOUDSTACK-7958: rhtyd commented on issue #2046: CLOUDSTACK-7958: Add configuration for limit to CIDRs for Admin API calls URL: https://github.com/apache/cloudstack/pull/2046#issuecomment-354762456 Ping @wido - can you fix the conflicts? 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 > 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] [Commented] (CLOUDSTACK-4757) Support OVA files with multiple disks for templates
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16308012#comment-16308012 ] 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-354762490 @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-9896) ListDedicatedXXX doesn't respect pagination
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16308011#comment-16308011 ] ASF GitHub Bot commented on CLOUDSTACK-9896: blueorangutan commented on issue #2073: CLOUDSTACK-9896: API: listDedicatedXXX should respect pagination URL: https://github.com/apache/cloudstack/pull/2073#issuecomment-354762462 @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 > ListDedicatedXXX doesn't respect pagination > --- > > Key: CLOUDSTACK-9896 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9896 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: API >Reporter: Marc-Aurèle Brothier >Assignee: Marc-Aurèle Brothier >Priority: Minor > > The listDedicatedZones, listDedicatedPods, listDedicatedClusters, > listDedicatedHosts are not using the pagination filter to return the results. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CLOUDSTACK-10205) LinkDomainToLdap returns internal id
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16308009#comment-16308009 ] ASF GitHub Bot commented on CLOUDSTACK-10205: - rhtyd commented on issue #2378: CLOUDSTACK-10205 make LinkDomainToLdap return UUID instead of internal id URL: https://github.com/apache/cloudstack/pull/2378#issuecomment-354762379 Tests LGTM, additional review requested for merging 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 > LinkDomainToLdap returns internal id > > > Key: CLOUDSTACK-10205 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10205 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Daan Hoogland > > The response should contain the uuid for the domain and not the internal db > id. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CLOUDSTACK-9896) ListDedicatedXXX doesn't respect pagination
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16308007#comment-16308007 ] ASF GitHub Bot commented on CLOUDSTACK-9896: rhtyd commented on issue #2073: CLOUDSTACK-9896: API: listDedicatedXXX should respect pagination URL: https://github.com/apache/cloudstack/pull/2073#issuecomment-354762269 @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 > ListDedicatedXXX doesn't respect pagination > --- > > Key: CLOUDSTACK-9896 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9896 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: API >Reporter: Marc-Aurèle Brothier >Assignee: Marc-Aurèle Brothier >Priority: Minor > > The listDedicatedZones, listDedicatedPods, listDedicatedClusters, > listDedicatedHosts are not using the pagination filter to return the results. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CLOUDSTACK-10108) ConfigKey based approach for reading 'ping' configuaration for Management Server
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16308008#comment-16308008 ] ASF GitHub Bot commented on CLOUDSTACK-10108: - blueorangutan commented on issue #2292: CLOUDSTACK-10108:ConfigKey based approach for reading 'ping' configua… URL: https://github.com/apache/cloudstack/pull/2292#issuecomment-354762278 @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 > ConfigKey based approach for reading 'ping' configuaration for Management > Server > > > Key: CLOUDSTACK-10108 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10108 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: mrunalini >Priority: Minor > > In CLOUDSTACK-9886, we are reading ping.interval and ping.timeout using > configdao which involves direct reading of DB. So, replace it with ConfigKey > based approach -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CLOUDSTACK-9025) Unable to deploy VM instance from template if template spin from linked clone snapshot
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16308005#comment-16308005 ] ASF GitHub Bot commented on CLOUDSTACK-9025: blueorangutan commented on issue #2315: A comprehensive solution for CLOUDSTACK-9025 and CLOUDSTACK-10128. URL: https://github.com/apache/cloudstack/pull/2315#issuecomment-354762139 @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 > Unable to deploy VM instance from template if template spin from linked clone > snapshot > -- > > Key: CLOUDSTACK-9025 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9025 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: XenServer >Affects Versions: 4.5.2 > Environment: XenServer 6.5 >Reporter: Anshul Gangwar >Assignee: Anshul Gangwar >Priority: Critical > Fix For: 4.6.0 > > > As default, CloudStack create linked clone snapshot for VM instance . When we > take a snapshot for the VM, and create a template based on such snapshot, > CloudStack only download incremental VHD as template file, as a result, the > VM instance fail to deploy as it is incomplete. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CLOUDSTACK-10108) ConfigKey based approach for reading 'ping' configuaration for Management Server
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16308006#comment-16308006 ] ASF GitHub Bot commented on CLOUDSTACK-10108: - rhtyd commented on issue #2292: CLOUDSTACK-10108:ConfigKey based approach for reading 'ping' configua… URL: https://github.com/apache/cloudstack/pull/2292#issuecomment-354762142 @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 > ConfigKey based approach for reading 'ping' configuaration for Management > Server > > > Key: CLOUDSTACK-10108 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10108 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: mrunalini >Priority: Minor > > In CLOUDSTACK-9886, we are reading ping.interval and ping.timeout using > configdao which involves direct reading of DB. So, replace it with ConfigKey > based approach -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CLOUDSTACK-9025) Unable to deploy VM instance from template if template spin from linked clone snapshot
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16308004#comment-16308004 ] ASF GitHub Bot commented on CLOUDSTACK-9025: rhtyd commented on issue #2315: A comprehensive solution for CLOUDSTACK-9025 and CLOUDSTACK-10128. URL: https://github.com/apache/cloudstack/pull/2315#issuecomment-354762066 Ping - can we have additional review on it thanks. @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 > Unable to deploy VM instance from template if template spin from linked clone > snapshot > -- > > Key: CLOUDSTACK-9025 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9025 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: XenServer >Affects Versions: 4.5.2 > Environment: XenServer 6.5 >Reporter: Anshul Gangwar >Assignee: Anshul Gangwar >Priority: Critical > Fix For: 4.6.0 > > > As default, CloudStack create linked clone snapshot for VM instance . When we > take a snapshot for the VM, and create a template based on such snapshot, > CloudStack only download incremental VHD as template file, as a result, the > VM instance fail to deploy as it is incomplete. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CLOUDSTACK-9906) Create snapshot after volume resize for the volume with existing snapshot(s)
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16308003#comment-16308003 ] ASF GitHub Bot commented on CLOUDSTACK-9906: blueorangutan commented on issue #2079: CLOUDSTACK-9906 Create snapshot after volume resize for the volume with existing snapshot(s) URL: https://github.com/apache/cloudstack/pull/2079#issuecomment-354762005 @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 > Create snapshot after volume resize for the volume with existing snapshot(s) > > > Key: CLOUDSTACK-9906 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9906 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Snapshot, Volumes > Environment: XenServer >Reporter: Suresh Kumar Anaparti >Assignee: Suresh Kumar Anaparti > > Snapshot of a volume fails if the volume has an existing snapshot(s) taken > before resizing of the volume. This behavior needs to be improved so that > taking snapshot would be successful when there is an existing snapshot(s) > before volume resizing. > REPRO STEPS > = > - Create a volume with 10 GB and attach to any VM. > - Take snapshot of the volume. > - Change volume size from 10GB to 15 GB. > - Take snapshot of the volume after resizing it. > - Create a volume from the snapshot taken after resizing volume. > - Attach the volume (created above) to any VM and check the size. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CLOUDSTACK-9906) Create snapshot after volume resize for the volume with existing snapshot(s)
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16308001#comment-16308001 ] ASF GitHub Bot commented on CLOUDSTACK-9906: rhtyd commented on issue #2079: CLOUDSTACK-9906 Create snapshot after volume resize for the volume with existing snapshot(s) URL: https://github.com/apache/cloudstack/pull/2079#issuecomment-354761833 @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 > Create snapshot after volume resize for the volume with existing snapshot(s) > > > Key: CLOUDSTACK-9906 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9906 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Snapshot, Volumes > Environment: XenServer >Reporter: Suresh Kumar Anaparti >Assignee: Suresh Kumar Anaparti > > Snapshot of a volume fails if the volume has an existing snapshot(s) taken > before resizing of the volume. This behavior needs to be improved so that > taking snapshot would be successful when there is an existing snapshot(s) > before volume resizing. > REPRO STEPS > = > - Create a volume with 10 GB and attach to any VM. > - Take snapshot of the volume. > - Change volume size from 10GB to 15 GB. > - Take snapshot of the volume after resizing it. > - Create a volume from the snapshot taken after resizing volume. > - Attach the volume (created above) to any VM and check the size. -- 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
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16308000#comment-16308000
]
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-354761775
ping @jayapalu
I'll remove this from 4.11 milestone due to lack of engagement, response
from the author and discussions.
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: Blocker
> 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 ff:ff:ff:ff:ff:ff
> inet
[jira] [Commented] (CLOUDSTACK-10188) Resource Accounting for primary storage is Broken
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16307999#comment-16307999 ] 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-354761649 ping @bwsw 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-10197) XenServer 7.1: Cannot mount xentool iso from cloudstack on VMs
[
https://issues.apache.org/jira/browse/CLOUDSTACK-10197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16307998#comment-16307998
]
ASF GitHub Bot commented on CLOUDSTACK-10197:
-
rhtyd commented on issue #2365: CLOUDSTACK-10197: Rename xentools iso for
XenServer 7.0+
URL: https://github.com/apache/cloudstack/pull/2365#issuecomment-354761606
Thanks @khos2ow any updates?
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
> XenServer 7.1: Cannot mount xentool iso from cloudstack on VMs
> ---
>
> Key: CLOUDSTACK-10197
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10197
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Affects Versions: 4.10.0.0
> Environment: XenServer 7.0+
>Reporter: Khosrow Moossavi
> Fix For: Future
>
>
> In XenServer 7.0+ xentools iso has been renamed from *xs-tools* to
> *guest-tools* so CloudStack fails to attach it to any VM.
> {code}
> (acs-admin) > attach iso
> virtualmachineid=d13eeff1-2d99-46a9-8fc5-3510df6e9f5e
> id=e8a56540-0fc3-44de-9911-635d2d8f25c4
> errorcode = 530
> errortext = Failed to attach iso
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CLOUDSTACK-10096) Can't reset api.integration.port and usage.sanity.check.interval back to null
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10096?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16307995#comment-16307995 ] ASF GitHub Bot commented on CLOUDSTACK-10096: - rhtyd commented on issue #2274: CLOUDSTACK-10096 Can't reset integration.api.port and usage.sanity.ch… URL: https://github.com/apache/cloudstack/pull/2274#issuecomment-354761394 @SudharmaJain ping? 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 > Can't reset api.integration.port and usage.sanity.check.interval back to null > - > > Key: CLOUDSTACK-10096 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10096 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: sudharma jain > > Fix for CLOUDSTACK-7931 enforces a value to be configured for > api.integration.port and usage.sanity.check.interval. These global configs > can't be reset back to null(default). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CLOUDSTACK-10087) Template registration errors out when template URL is https
[
https://issues.apache.org/jira/browse/CLOUDSTACK-10087?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16307997#comment-16307997
]
ASF GitHub Bot commented on CLOUDSTACK-10087:
-
rhtyd commented on issue #2271: CLOUDSTACK-10087 Template registration errors
out when template URL i…
URL: https://github.com/apache/cloudstack/pull/2271#issuecomment-354761432
@SudharmaJain ping
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
> Template registration errors out when template URL is https
> ---
>
> Key: CLOUDSTACK-10087
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10087
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Reporter: sudharma jain
>
> *Management server logs:*
> 2017-08-23 08:55:36,706 DEBUG [c.c.a.t.Request] (AgentManager-Handler-5:null)
> (logid:) Seq 4-7842174326135586819: Processing: { Ans: , MgmtId: 4278190080,
> via: 4, Ver: v1, Flags: 110,
> [{"com.cloud.agent.api.Answer":{"result":false,"details":"com.amazonaws.SdkClientException:
> Unable to execute HTTP request: sun.security.validator.ValidatorException:
> PKIX path building failed:
> sun.security.provider.certpath.SunCertPathBuilderException: unable to find
> valid certification path to requested target\n\tat
> com.amazonaws.http.AmazonHttpClient$RequestExecutor.executeHelper(AmazonHttpClient.java:972)\n\tat
>
> com.amazonaws.http.AmazonHttpClient$RequestExecutor.doExecute(AmazonHttpClient.java:676)\n\tat
>
> com.amazonaws.http.AmazonHttpClient$RequestExecutor.executeWithTimer(AmazonHttpClient.java:650)\n\tat
>
> com.amazonaws.http.AmazonHttpClient$RequestExecutor.execute(AmazonHttpClient.java:633)\n\tat
>
> com.amazonaws.http.AmazonHttpClient$RequestExecutor.access$300(AmazonHttpClient.java:601)\n\tat
>
> com.amazonaws.http.AmazonHttpClient$RequestExecutionBuilderImpl.execute(AmazonHttpClient.java:583)\n\tat
> com.amazonaws.http.AmazonHttpClient.execute(AmazonHttpClient.java:447)\n\tat
> com.amazonaws.services.s3.AmazonS3Client.invoke(AmazonS3Client.java:4137)\n\tat
>
> com.amazonaws.services.s3.AmazonS3Client.getBucketRegionViaHeadRequest(AmazonS3Client.java:4856)\n\tat
>
> com.amazonaws.services.s3.AmazonS3Client.fetchRegionFromCache(AmazonS3Client.java:4830)\n\tat
>
> com.amazonaws.services.s3.AmazonS3Client.invoke(AmazonS3Client.java:4122)\n\tat
>
> com.amazonaws.services.s3.AmazonS3Client.invoke(AmazonS3Client.java:4079)\n\tat
>
> com.amazonaws.services.s3.AmazonS3Client.listObjects(AmazonS3Client.java:819)\n\tat
> com.cloud.utils.storage.S3.S3Utils.listDirectory(S3Utils.java:179)\n\tat
> org.apache.cloudstack.storage.resource.NfsSecondaryStorageResource.s3ListVolume(NfsSecondaryStorageResource.java:1667)\n\tat
>
> org.apache.cloudstack.storage.resource.NfsSecondaryStorageResource.execute(NfsSecondaryStorageResource.java:1721)\n\tat
>
> org.apache.cloudstack.storage.resource.NfsSecondaryStorageResource.executeRequest(NfsSecondaryStorageResource.java:277)\n\tat
>
> com.cloud.storage.resource.PremiumSecondaryStorageResource.defaultAction(PremiumSecondaryStorageResource.java:64)\n\tat
>
> com.cloud.storage.resource.PremiumSecondaryStorageResource.executeRequest(PremiumSecondaryStorageResource.java:60)\n\tat
> com.cloud.agent.Agent.processRequest(Agent.java:525)\n\tat
> com.cloud.agent.Agent$AgentRequestHandler.doTask(Agent.java:833)\n\tat
> com.cloud.utils.nio.Task.call(Task.java:83)\n\tat
> com.cloud.utils.nio.Task.call(Task.java:29)\n\tat
> java.util.concurrent.FutureTask.run(FutureTask.java:266)\n\tat
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)\n\tat
>
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)\n\tat
> java.lang.Thread.run(Thread.java:745)\nCaused by:
> javax.net.ssl.SSLHandshakeException:
> sun.security.validator.ValidatorException: PKIX path building failed:
> sun.security.provider.certpath.SunCertPathBuilderException: unable to find
> valid certification path to requested target\n\tat
> sun.security.ssl.Alerts.getSSLException(Alerts.java:192)\n\tat
> sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1949)\n\tat
> sun.security.ssl.Handshaker.fatalSE(Handshaker.java:302)\n\tat
> sun.security.ssl.Handshaker.fatalSE(Handshaker.java:296)\n\tat
> sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1509)\n\tat
>
> sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:216)\n\tat
>
[jira] [Commented] (CLOUDSTACK-9921) NPE when garbage collector is running
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16307994#comment-16307994 ] ASF GitHub Bot commented on CLOUDSTACK-9921: rhtyd commented on issue #2139: CLOUDSTACK-9921: NPE when storage garbage collector is running. URL: https://github.com/apache/cloudstack/pull/2139#issuecomment-354761358 Ping, any updates? I'll remove this from 4.11 milestone due to lack of engagement, a response from the author and discussions. 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 > NPE when garbage collector is running > - > > Key: CLOUDSTACK-9921 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9921 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: jay > > Steps to reproduce issue > 1. Deploy a VM > 2. Take snapshot of the root volume > 3. Delete the snapshot > 4. Before the garbage collector has run, shutdown the VM and assign the VM to > other user. > 5. When garage collector executes NPE shows in the logs. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CLOUDSTACK-10025) To create a better VNC client for Cloudstack using noVNC
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16307993#comment-16307993 ] ASF GitHub Bot commented on CLOUDSTACK-10025: - rhtyd commented on issue #2204: [CLOUDSTACK-10025] Adding Support for NoVNC Console for KVM and XENSERVER URL: https://github.com/apache/cloudstack/pull/2204#issuecomment-354761308 Ping, any updates? I'll remove this from 4.11 milestone due to lack of engagement, a response from the author, reviewers and discussions. Hopefully, we can get this stabilized, reviewed/tested merged for a future release. 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 > To create a better VNC client for Cloudstack using noVNC > > > Key: CLOUDSTACK-10025 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10025 > Project: CloudStack > Issue Type: New Feature > Security Level: Public(Anyone can view this level - this is the > default.) > Components: VNC Proxy >Affects Versions: 4.11.0.0 >Reporter: Sachin >Priority: Minor > Labels: features > > I have implemented this feature as my GSoC'17 project. noVNC is written in > javascript and uses websockets to connect to VNC server. We have modified the > ConsoleProxy server to accept websocket request from noVNC client, which then > forwards the request request to VNC server. > Javascript cannot make plain tcp request, hence the websocket request have to > be forwarded to the VNC server via a proxy server that basically converts > websocket request from client to plain tcp request for VNC server. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CLOUDSTACK-4045) IP address acquired with associateIpAddress is marked as source NAT, causing disassociateIpAddress to fail later
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16307992#comment-16307992 ] ASF GitHub Bot commented on CLOUDSTACK-4045: houthuis opened a new pull request #2382: CLOUDSTACK-4045 URL: https://github.com/apache/cloudstack/pull/2382 added a check for network state when determining whether a new IP should be source NAT. this prevents associated IP's to be marked as source NAT when the network is in allocated state, causing disassociateIpAddress to fail later Code will now throw a InvalidParameterValueException in the above scenario. 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 > IP address acquired with associateIpAddress is marked as source NAT, causing > disassociateIpAddress to fail later > > > Key: CLOUDSTACK-4045 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4045 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.0.0, 4.0.1, 4.0.2, 4.1.0, 4.1.1, 4.2.0 >Reporter: Murali Reddy >Assignee: Murali Reddy > Fix For: Future > > > When you can create network, network is in allocated state. when network is > implemented CloudStack implicitly should acquire a public IP for source nat. > But there is assumption that first IP this is associated with network is > always for source NAT IP. So when you do > 1. create network (network is in allocated state) > 2. acquire a public IP and associate with the network > 3. disassociate ip address > #3 will fail because CloudStack marks the IP acquired in #1 to be source NAT. > For users this is counter-intutive because when a IP is acquired, he/she > should be able to release it as well. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CLOUDSTACK-8735) Browser Based Volume and Template Test Automation
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8735?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16307991#comment-16307991 ] ASF GitHub Bot commented on CLOUDSTACK-8735: rhtyd commented on issue #2117: CLOUDSTACK-8735:Browser Based Volume and Template Upload Test Automat… URL: https://github.com/apache/cloudstack/pull/2117#issuecomment-354761122 Ping, any updates? I'll remove this from 4.11 milestone due to lack of engagement, a response from the author and discussions. 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 > Browser Based Volume and Template Test Automation > -- > > Key: CLOUDSTACK-8735 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8735 > Project: CloudStack > Issue Type: Test > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation >Reporter: Sailaja Mada >Assignee: Sailaja Mada > > Browser Based Volume and Template Test Automation -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CLOUDSTACK-9852) Storage Load Balancer
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16307986#comment-16307986 ] ASF GitHub Bot commented on CLOUDSTACK-9852: rhtyd commented on issue #2067: CLOUDSTACK-9852: This patch implements the storage lb feature URL: https://github.com/apache/cloudstack/pull/2067#issuecomment-354760815 Ping, any updates? I'll remove this from 4.11 milestone due to lack of engagement, response from the author and discussions. 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 > Storage Load Balancer > - > > Key: CLOUDSTACK-9852 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9852 > Project: CloudStack > Issue Type: New Feature > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Anshul Gangwar >Assignee: Anshul Gangwar > > Currently CloudStack does not support any type of storage load balancing. It > always lists the primary storage and secondary storage in same order and the > pick the first one which satisfies the criteria. If user wants to load > balance then there is no way for user to tell volume to go to different > primary storage or secondary storage. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CLOUDSTACK-9892) Primary storage resource check is broken when using root disk size override to deploy VM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16307989#comment-16307989 ] ASF GitHub Bot commented on CLOUDSTACK-9892: rhtyd commented on issue #2088: CLOUDSTACK-9892: Primary storage resource check is broken when using … URL: https://github.com/apache/cloudstack/pull/2088#issuecomment-354760889 Ping @koushik-das 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 > Primary storage resource check is broken when using root disk size override > to deploy VM > > > Key: CLOUDSTACK-9892 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9892 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.10.0.0 >Reporter: Koushik Das >Assignee: Koushik Das >Priority: Critical > Fix For: 4.11.0.0 > > > Primary storage resource check for account/domain is broken when using root > disk size override to deploy VM -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CLOUDSTACK-9681) able to migrate data volume even logical volume size more than the destination pool size.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16307982#comment-16307982 ] ASF GitHub Bot commented on CLOUDSTACK-9681: rhtyd commented on issue #1835: CLOUDSTACK-9681: Make the migration of volume to go through allocator… URL: https://github.com/apache/cloudstack/pull/1835#issuecomment-354760635 Ping, any updates? I'll remove this from 4.11 milestone due to lack of engagement and discussions. 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 > able to migrate data volume even logical volume size more than the > destination pool size. > -- > > Key: CLOUDSTACK-9681 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9681 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Anshul Gangwar >Assignee: Anshul Gangwar > > 1. Create a advanced zone > 2. Add multiple primary storage's in the same cluster > 3. add a storage tag to one primary storage(eg:ps3) here total disk capacity > is 27 gb and storage provisioning factor set to 1 and > pool.storage.allocated.capacity.disablethresholdto 1 > pool.storage.capacity.disablethreshold to 1 > 4. create a computer offering by mentioning above storage tag > 5.deploy a vm using above computer offering > 6.once it successful,create a data disk(5gb) > 7. make sure its ready and resize the data disk from 5gb to 100 gb > 8.migrate the volume from ps2 to ps3 even though it says not suitable. > here source volume size > destination storage pool size. > actual result: > volume migration successful even though volume size is greater than > destination primary storage size instead of failing migration operation. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CLOUDSTACK-9607) Preventing template deletion when template is in use.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9607?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16307984#comment-16307984 ] ASF GitHub Bot commented on CLOUDSTACK-9607: rhtyd commented on issue #1773: CLOUDSTACK-9607: Preventing template deletion when template is in use. URL: https://github.com/apache/cloudstack/pull/1773#issuecomment-354760691 @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 > Preventing template deletion when template is in use. > - > > Key: CLOUDSTACK-9607 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9607 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Priyank Parihar >Assignee: Priyank Parihar > > Consider this scenario: > 1. User launches a VM from Template and keep it running > 2. Admin logins and deleted that template [CloudPlatform does not check > existing / running VM etc. while the deletion is done] > 3. User resets the VM > 4. CloudPlatform fails to star the VM as it cannot find the corresponding > template. > It throws error as > java.lang.RuntimeException: Job failed due to exception Resource [Host:11] is > unreachable: Host 11: Unable to start instance due to can't find ready > template: 209 for data center 1 > at > com.cloud.vm.VmWorkJobDispatcher.runJob(VmWorkJobDispatcher.java:113) > at > org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:495) > Client is requesting better handing of this scenario. We need to check > existing / running VM's when the template is deleted and warn admin about the > possible issue that may occur. > REPRO STEPS > == > 1. Launches a VM from Template and keep it running > 2. Now delete that template > 3. Reset the VM > 4. CloudPlatform fails to star the VM as it cannot find the corresponding > template. > EXPECTED BEHAVIOR > == > Cloud platform should throw some warning message while the template is > deleted if that template is being used by existing / running VM's > ACTUAL BEHAVIOR > == > Cloud platform does not throw as waring etc. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CLOUDSTACK-9607) Preventing template deletion when template is in use.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9607?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16307985#comment-16307985 ] ASF GitHub Bot commented on CLOUDSTACK-9607: blueorangutan commented on issue #1773: CLOUDSTACK-9607: Preventing template deletion when template is in use. URL: https://github.com/apache/cloudstack/pull/1773#issuecomment-354760722 @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 > Preventing template deletion when template is in use. > - > > Key: CLOUDSTACK-9607 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9607 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Priyank Parihar >Assignee: Priyank Parihar > > Consider this scenario: > 1. User launches a VM from Template and keep it running > 2. Admin logins and deleted that template [CloudPlatform does not check > existing / running VM etc. while the deletion is done] > 3. User resets the VM > 4. CloudPlatform fails to star the VM as it cannot find the corresponding > template. > It throws error as > java.lang.RuntimeException: Job failed due to exception Resource [Host:11] is > unreachable: Host 11: Unable to start instance due to can't find ready > template: 209 for data center 1 > at > com.cloud.vm.VmWorkJobDispatcher.runJob(VmWorkJobDispatcher.java:113) > at > org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:495) > Client is requesting better handing of this scenario. We need to check > existing / running VM's when the template is deleted and warn admin about the > possible issue that may occur. > REPRO STEPS > == > 1. Launches a VM from Template and keep it running > 2. Now delete that template > 3. Reset the VM > 4. CloudPlatform fails to star the VM as it cannot find the corresponding > template. > EXPECTED BEHAVIOR > == > Cloud platform should throw some warning message while the template is > deleted if that template is being used by existing / running VM's > ACTUAL BEHAVIOR > == > Cloud platform does not throw as waring etc. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CLOUDSTACK-9730) [VMware] Unable to add a host with space in its name to existing VMware cluster
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16307979#comment-16307979 ] ASF GitHub Bot commented on CLOUDSTACK-9730: rhtyd commented on issue #1891: CLOUDSTACK-9730: [VMware] Unable to add a host with space in its name to existing VMware cluster URL: https://github.com/apache/cloudstack/pull/1891#issuecomment-354760537 @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 > [VMware] Unable to add a host with space in its name to existing VMware > cluster > --- > > Key: CLOUDSTACK-9730 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9730 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: VMware >Reporter: Suresh Kumar Anaparti >Assignee: Suresh Kumar Anaparti > Fix For: 4.10.1.0 > > > ISSUE > == > Unable to add a host with space in the name to existing VMware cluster. > While adding host, CloudStack tries to persist the validated inventory url > path in database, which inserts encoded url into database which means > whitespace would be stored as '+' symbols. Url from API parameter string is > being converted to URI object as part of validation, where the url path is > getting encoded. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CLOUDSTACK-9730) [VMware] Unable to add a host with space in its name to existing VMware cluster
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16307980#comment-16307980 ] ASF GitHub Bot commented on CLOUDSTACK-9730: blueorangutan commented on issue #1891: CLOUDSTACK-9730: [VMware] Unable to add a host with space in its name to existing VMware cluster URL: https://github.com/apache/cloudstack/pull/1891#issuecomment-354760562 @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 > [VMware] Unable to add a host with space in its name to existing VMware > cluster > --- > > Key: CLOUDSTACK-9730 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9730 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: VMware >Reporter: Suresh Kumar Anaparti >Assignee: Suresh Kumar Anaparti > Fix For: 4.10.1.0 > > > ISSUE > == > Unable to add a host with space in the name to existing VMware cluster. > While adding host, CloudStack tries to persist the validated inventory url > path in database, which inserts encoded url into database which means > whitespace would be stored as '+' symbols. Url from API parameter string is > being converted to URI object as part of validation, where the url path is > getting encoded. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CLOUDSTACK-9727) Password reset discrepancy in RVR when one of the Router is not in Running state.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9727?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16307978#comment-16307978 ] ASF GitHub Bot commented on CLOUDSTACK-9727: rhtyd commented on issue #1965: CLOUDSTACK-9727 Password reset discrepancy in RVR when one of the Rou… URL: https://github.com/apache/cloudstack/pull/1965#issuecomment-354760339 Ping, any updates? I'll remove this from 4.11 milestone due to lack of engagement and discussions. 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 > Password reset discrepancy in RVR when one of the Router is not in Running > state. > - > > Key: CLOUDSTACK-9727 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9727 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.9.0 >Reporter: Bharat Kumar >Assignee: Bharat Kumar > Fix For: 4.9.2.0 > > > - Deploy an instance and place " cloud-set-guest-password " script in the > /etc/init.d location and provide the executable permission. > - Create a template from the above VM. > - Create a new network offering with RVR enabled. > - Deploy a new VM from the above created template and select the above RVR > offering. > - Ensure that the password script is sucessfuly running. > - Put the backup router in stopped state and ensure only master is running. > - Now stop the VM and and Reset the password. > - DO not start the VM , Now Stop the current Master and start the Back up. > - Now the Back Up would be the Master. Now start the VM. > Observations: > - The password is saved onto only Master which is in stopped state now or > either in backup if we start it. > - The current Master which was back up earlier do not have the new password. > Hence user cannot now login with the new password. > - In this scenario there is disperancy in the password stored on both the > RVR's. > The only way to sync both the passwords now is , ensure both the RVR are > running and reset the password on VM. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CLOUDSTACK-8855) Improve Error Message for Host Alert State
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16307977#comment-16307977 ] ASF GitHub Bot commented on CLOUDSTACK-8855: rafaelweingartner commented on issue #2380: CLOUDSTACK-8855 Improve Error Message for Host Alert State and reconnect host API. URL: https://github.com/apache/cloudstack/pull/2380#issuecomment-354760130 @DaanHoogland that is probably because I am not in the Gitbox experiment. It is great that you picked this up, I was thinking on doing that myself, but with my current workload I would not have time to do this now. I would say that here I see the same problem as in #837. It feels so simple to create a new column in "AlertVO" table to add the content. I am not going to repeat the discussion we had there here. So, as long as others are ok with it. With the current state of the PR I give a -0. 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 > Improve Error Message for Host Alert State > -- > > Key: CLOUDSTACK-8855 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8855 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.6.0 >Reporter: Bharat Kumar >Assignee: Bharat Kumar > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CLOUDSTACK-8608) Fix unpleasant admin experience with VMware fresh installs/upgrades - System VM's failed to start due to permissions issue
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16307973#comment-16307973 ] ASF GitHub Bot commented on CLOUDSTACK-8608: rhtyd commented on issue #1875: CLOUDSTACK-8608: [VMware] System VMs failed to start due to permissions issue. Provide permissions to template folder when mounted on management server. URL: https://github.com/apache/cloudstack/pull/1875#issuecomment-354760001 @sureshanaparti this is marked blocker however no activity or discussion is seen, I'll remove the 'blocker' label and ask the author to engage in a conversation. 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 > Fix unpleasant admin experience with VMware fresh installs/upgrades - System > VM's failed to start due to permissions issue > -- > > Key: CLOUDSTACK-8608 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8608 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Likitha Shetty >Assignee: Suresh Kumar Anaparti > Fix For: Future > > > VMware uses a folder in machine where management server is running to mount > secondary storage. This is a bootstrap phase to start system vm, because > unlike KVM, Xenserver, management server cannot directly access VMWare ESXI > host to download systemvm template from secondary storage to primary storage. > The secondary storage is usually managed by SSVM that uses root account to > download templates. However, management server is using account 'cloud' to > manipulate templates after secondary storage is mounted. After admin > registers new systemvm template in CS as a normal upgrade procedure, the old > SSVM will download the template using account root, but management server > will create new SSVM from the new template using account 'cloud'. Then a > permission denied error will raise. > Prior to 4.4, CS used to handle this by running 'chmod -R' to the folder to > which secondary storage is mounted every time management server mounts > secondary storage. Unfortunately, this method is slow because we are trying > to give permissions to the entire folder. So in 4.4, we stopped automatically > providing the permissions and asked admin to manually run 'chmod -R' to the > folder 'templates' on secondary storage, after registering new systemvm > template. > We can avoid this manual admin step by only providing permissions for the > /templates folder instead of the entire folder. This way we will avoid the > snapshots folder which could be very large in upgrade setups. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CLOUDSTACK-9781) ACS records ID in events tables instead of UUID.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9781?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16307970#comment-16307970 ] ASF GitHub Bot commented on CLOUDSTACK-9781: rhtyd commented on issue #1940: CLOUDSTACK-9781:ACS records ID in events tables instead of UUID. URL: https://github.com/apache/cloudstack/pull/1940#issuecomment-354759842 Given objections on ML that such a change could break billing and other integrations, I've removed this from 4.11 milestone. However, refactoring and exporting uuids insteads of IDs is inevitable and perhaps a proper migration/path is needed to be advised on dev/user MLs before such a change could be accepted in future releases. 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 > ACS records ID in events tables instead of UUID. > > > Key: CLOUDSTACK-9781 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9781 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Jayant Patil > > ISSUE > = > Wrong presentation of volume id in ACS events. > While creating a snapshot, only volume ID is mentioned in the events. For > example, “Scheduled async job for creating snapshot for volume Id:270". On > looking into the notification, user is not able to identify the volume. So > modified event description with UUID. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CLOUDSTACK-10108) ConfigKey based approach for reading 'ping' configuaration for Management Server
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16307965#comment-16307965 ] ASF GitHub Bot commented on CLOUDSTACK-10108: - rhtyd commented on issue #2292: CLOUDSTACK-10108:ConfigKey based approach for reading 'ping' configua… URL: https://github.com/apache/cloudstack/pull/2292#issuecomment-354759458 @blueorangutan test centos7 vmware-65 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 > ConfigKey based approach for reading 'ping' configuaration for Management > Server > > > Key: CLOUDSTACK-10108 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10108 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: mrunalini >Priority: Minor > > In CLOUDSTACK-9886, we are reading ping.interval and ping.timeout using > configdao which involves direct reading of DB. So, replace it with ConfigKey > based approach -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CLOUDSTACK-10108) ConfigKey based approach for reading 'ping' configuaration for Management Server
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16307966#comment-16307966 ] ASF GitHub Bot commented on CLOUDSTACK-10108: - blueorangutan commented on issue #2292: CLOUDSTACK-10108:ConfigKey based approach for reading 'ping' configua… URL: https://github.com/apache/cloudstack/pull/2292#issuecomment-354759503 @rhtyd unsupported parameters provided. Supported mgmt server os are: `centos6, centos7, ubuntu`. Supported hypervisors are: `kvm-centos6, kvm-centos7, kvm-ubuntu, xenserver-65sp1, xenserver-62sp1, vmware-60u2, vmware-55u3, vmware-51u1, vmware-50u1` 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 > ConfigKey based approach for reading 'ping' configuaration for Management > Server > > > Key: CLOUDSTACK-10108 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10108 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: mrunalini >Priority: Minor > > In CLOUDSTACK-9886, we are reading ping.interval and ping.timeout using > configdao which involves direct reading of DB. So, replace it with ConfigKey > based approach -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CLOUDSTACK-8855) Improve Error Message for Host Alert State
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16307964#comment-16307964 ] ASF GitHub Bot commented on CLOUDSTACK-8855: rhtyd commented on issue #2380: CLOUDSTACK-8855 Improve Error Message for Host Alert State and reconnect host API. URL: https://github.com/apache/cloudstack/pull/2380#issuecomment-354758853 @DaanHoogland can you fix the build failures? 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 > Improve Error Message for Host Alert State > -- > > Key: CLOUDSTACK-8855 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8855 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.6.0 >Reporter: Bharat Kumar >Assignee: Bharat Kumar > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CLOUDSTACK-10104) Optimize database transactions in ListDomain API to improve performance
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16307962#comment-16307962 ] ASF GitHub Bot commented on CLOUDSTACK-10104: - blueorangutan commented on issue #2282: CLOUDSTACK-10104:Optimize database transactions in ListDomain API to improve performance URL: https://github.com/apache/cloudstack/pull/2282#issuecomment-354757717 @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 > Optimize database transactions in ListDomain API to improve performance > --- > > Key: CLOUDSTACK-10104 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10104 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: API >Reporter: Pranali Mande > > While creating the response object for the 'listDomain' API, several database > calls are triggered to fetch details like parent domain, project limit, IP > limit, etc. These database calls are triggered for each record found for in > the main fetch query, which is causing the response to slow down. The > database transactions could be optimized to reduce the response time of the > Listdomain API -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CLOUDSTACK-10104) Optimize database transactions in ListDomain API to improve performance
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16307960#comment-16307960 ] ASF GitHub Bot commented on CLOUDSTACK-10104: - rhtyd commented on issue #2282: CLOUDSTACK-10104:Optimize database transactions in ListDomain API to improve performance URL: https://github.com/apache/cloudstack/pull/2282#issuecomment-354757619 @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 > Optimize database transactions in ListDomain API to improve performance > --- > > Key: CLOUDSTACK-10104 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10104 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: API >Reporter: Pranali Mande > > While creating the response object for the 'listDomain' API, several database > calls are triggered to fetch details like parent domain, project limit, IP > limit, etc. These database calls are triggered for each record found for in > the main fetch query, which is causing the response to slow down. The > database transactions could be optimized to reduce the response time of the > Listdomain API -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CLOUDSTACK-10108) ConfigKey based approach for reading 'ping' configuaration for Management Server
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16307947#comment-16307947 ] ASF GitHub Bot commented on CLOUDSTACK-10108: - blueorangutan commented on issue #2292: CLOUDSTACK-10108:ConfigKey based approach for reading 'ping' configua… URL: https://github.com/apache/cloudstack/pull/2292#issuecomment-354754080 Packaging result: ✔centos6 ✔centos7 ✔debian. JID-1537 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 > ConfigKey based approach for reading 'ping' configuaration for Management > Server > > > Key: CLOUDSTACK-10108 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10108 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: mrunalini >Priority: Minor > > In CLOUDSTACK-9886, we are reading ping.interval and ping.timeout using > configdao which involves direct reading of DB. So, replace it with ConfigKey > based approach -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CLOUDSTACK-10104) Optimize database transactions in ListDomain API to improve performance
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16307948#comment-16307948 ] ASF GitHub Bot commented on CLOUDSTACK-10104: - blueorangutan commented on issue #2282: CLOUDSTACK-10104:Optimize database transactions in ListDomain API to improve performance URL: https://github.com/apache/cloudstack/pull/2282#issuecomment-354754082 Packaging result: ✔centos6 ✔centos7 ✔debian. JID-1538 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 > Optimize database transactions in ListDomain API to improve performance > --- > > Key: CLOUDSTACK-10104 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10104 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: API >Reporter: Pranali Mande > > While creating the response object for the 'listDomain' API, several database > calls are triggered to fetch details like parent domain, project limit, IP > limit, etc. These database calls are triggered for each record found for in > the main fetch query, which is causing the response to slow down. The > database transactions could be optimized to reduce the response time of the > Listdomain API -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CLOUDSTACK-10104) Optimize database transactions in ListDomain API to improve performance
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16307916#comment-16307916 ] ASF GitHub Bot commented on CLOUDSTACK-10104: - blueorangutan commented on issue #2282: CLOUDSTACK-10104:Optimize database transactions in ListDomain API to improve performance URL: https://github.com/apache/cloudstack/pull/2282#issuecomment-354749206 @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 > Optimize database transactions in ListDomain API to improve performance > --- > > Key: CLOUDSTACK-10104 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10104 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: API >Reporter: Pranali Mande > > While creating the response object for the 'listDomain' API, several database > calls are triggered to fetch details like parent domain, project limit, IP > limit, etc. These database calls are triggered for each record found for in > the main fetch query, which is causing the response to slow down. The > database transactions could be optimized to reduce the response time of the > Listdomain API -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CLOUDSTACK-10104) Optimize database transactions in ListDomain API to improve performance
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16307917#comment-16307917 ] ASF GitHub Bot commented on CLOUDSTACK-10104: - rhtyd commented on issue #2282: CLOUDSTACK-10104:Optimize database transactions in ListDomain API to improve performance URL: https://github.com/apache/cloudstack/pull/2282#issuecomment-354749075 @PranaliM I'll rekick tests. Additional code review/lgtm is needed as well. @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 > Optimize database transactions in ListDomain API to improve performance > --- > > Key: CLOUDSTACK-10104 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10104 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: API >Reporter: Pranali Mande > > While creating the response object for the 'listDomain' API, several database > calls are triggered to fetch details like parent domain, project limit, IP > limit, etc. These database calls are triggered for each record found for in > the main fetch query, which is causing the response to slow down. The > database transactions could be optimized to reduce the response time of the > Listdomain API -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CLOUDSTACK-10108) ConfigKey based approach for reading 'ping' configuaration for Management Server
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16307913#comment-16307913 ] ASF GitHub Bot commented on CLOUDSTACK-10108: - blueorangutan commented on issue #2292: CLOUDSTACK-10108:ConfigKey based approach for reading 'ping' configua… URL: https://github.com/apache/cloudstack/pull/2292#issuecomment-354749035 @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 > ConfigKey based approach for reading 'ping' configuaration for Management > Server > > > Key: CLOUDSTACK-10108 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10108 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: mrunalini >Priority: Minor > > In CLOUDSTACK-9886, we are reading ping.interval and ping.timeout using > configdao which involves direct reading of DB. So, replace it with ConfigKey > based approach -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CLOUDSTACK-10104) Optimize database transactions in ListDomain API to improve performance
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16307914#comment-16307914 ] ASF GitHub Bot commented on CLOUDSTACK-10104: - rhtyd commented on issue #2282: CLOUDSTACK-10104:Optimize database transactions in ListDomain API to improve performance URL: https://github.com/apache/cloudstack/pull/2282#issuecomment-354749075 @PranaliM I'll 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 > Optimize database transactions in ListDomain API to improve performance > --- > > Key: CLOUDSTACK-10104 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10104 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: API >Reporter: Pranali Mande > > While creating the response object for the 'listDomain' API, several database > calls are triggered to fetch details like parent domain, project limit, IP > limit, etc. These database calls are triggered for each record found for in > the main fetch query, which is causing the response to slow down. The > database transactions could be optimized to reduce the response time of the > Listdomain API -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CLOUDSTACK-10108) ConfigKey based approach for reading 'ping' configuaration for Management Server
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16307912#comment-16307912 ] ASF GitHub Bot commented on CLOUDSTACK-10108: - rhtyd commented on issue #2292: CLOUDSTACK-10108:ConfigKey based approach for reading 'ping' configua… URL: https://github.com/apache/cloudstack/pull/2292#issuecomment-354748996 @mrunalinikankariya no, not without regression tests. Please also see the left comments specifically around refactoring the code. Thanks. @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 > ConfigKey based approach for reading 'ping' configuaration for Management > Server > > > Key: CLOUDSTACK-10108 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10108 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: mrunalini >Priority: Minor > > In CLOUDSTACK-9886, we are reading ping.interval and ping.timeout using > configdao which involves direct reading of DB. So, replace it with ConfigKey > based approach -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CLOUDSTACK-10117) LDAP mapping on domain level
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16307894#comment-16307894 ] ASF GitHub Bot commented on CLOUDSTACK-10117: - DaanHoogland commented on issue #2381: CLOUDSTACK-10117 Account ldap binding URL: https://github.com/apache/cloudstack/pull/2381#issuecomment-354745696 @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 > LDAP mapping on domain level > > > Key: CLOUDSTACK-10117 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10117 > Project: CloudStack > Issue Type: New Feature > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Daan Hoogland > > see FS: > https://cwiki.apache.org/confluence/display/CLOUDSTACK/Domain+level+LDAP+bindinings -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CLOUDSTACK-10117) LDAP mapping on domain level
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16307895#comment-16307895 ] ASF GitHub Bot commented on CLOUDSTACK-10117: - blueorangutan commented on issue #2381: CLOUDSTACK-10117 Account ldap binding URL: https://github.com/apache/cloudstack/pull/2381#issuecomment-354745722 @DaanHoogland 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 > LDAP mapping on domain level > > > Key: CLOUDSTACK-10117 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10117 > Project: CloudStack > Issue Type: New Feature > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Daan Hoogland > > see FS: > https://cwiki.apache.org/confluence/display/CLOUDSTACK/Domain+level+LDAP+bindinings -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CLOUDSTACK-10117) LDAP mapping on domain level
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16307890#comment-16307890 ] ASF GitHub Bot commented on CLOUDSTACK-10117: - blueorangutan commented on issue #2381: CLOUDSTACK-10117 Account ldap binding URL: https://github.com/apache/cloudstack/pull/2381#issuecomment-354744993 Packaging result: ✔centos6 ✔centos7 ✔debian. JID-1536 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 > LDAP mapping on domain level > > > Key: CLOUDSTACK-10117 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10117 > Project: CloudStack > Issue Type: New Feature > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Daan Hoogland > > see FS: > https://cwiki.apache.org/confluence/display/CLOUDSTACK/Domain+level+LDAP+bindinings -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CLOUDSTACK-10117) LDAP mapping on domain level
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16307860#comment-16307860 ] ASF GitHub Bot commented on CLOUDSTACK-10117: - blueorangutan commented on issue #2381: CLOUDSTACK-10117 Account ldap binding URL: https://github.com/apache/cloudstack/pull/2381#issuecomment-354739735 @DaanHoogland 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 > LDAP mapping on domain level > > > Key: CLOUDSTACK-10117 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10117 > Project: CloudStack > Issue Type: New Feature > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Daan Hoogland > > see FS: > https://cwiki.apache.org/confluence/display/CLOUDSTACK/Domain+level+LDAP+bindinings -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CLOUDSTACK-10117) LDAP mapping on domain level
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16307856#comment-16307856 ] ASF GitHub Bot commented on CLOUDSTACK-10117: - DaanHoogland commented on issue #2381: CLOUDSTACK-10117 Account ldap binding URL: https://github.com/apache/cloudstack/pull/2381#issuecomment-354739575 @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 > LDAP mapping on domain level > > > Key: CLOUDSTACK-10117 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10117 > Project: CloudStack > Issue Type: New Feature > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Daan Hoogland > > see FS: > https://cwiki.apache.org/confluence/display/CLOUDSTACK/Domain+level+LDAP+bindinings -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CLOUDSTACK-10117) LDAP mapping on domain level
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16307853#comment-16307853 ] ASF GitHub Bot commented on CLOUDSTACK-10117: - DaanHoogland commented on issue #2369: CLOUDSTACK-10117 Domain level ldap configuration URL: https://github.com/apache/cloudstack/pull/2369#issuecomment-354739441 this is overridden by #2381 which implements account level binding on ldap groups 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 > LDAP mapping on domain level > > > Key: CLOUDSTACK-10117 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10117 > Project: CloudStack > Issue Type: New Feature > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Daan Hoogland > > see FS: > https://cwiki.apache.org/confluence/display/CLOUDSTACK/Domain+level+LDAP+bindinings -- This message was sent by Atlassian JIRA (v6.4.14#64029)
