[jira] [Commented] (CLOUDSTACK-2940) Domain on SSVM is not being updated for download urls that come for CS.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13680993#comment-13680993 ] Wei Zhou commented on CLOUDSTACK-2940: -- Nitin, I have posted a patch for similar issue on 4.0.* which has not been submitted. FYI, please have a look at : https://reviews.apache.org/r/9696/ Maybe we need more changes. -Wei > Domain on SSVM is not being updated for download urls that come for CS. > --- > > Key: CLOUDSTACK-2940 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2940 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Nitin Mehta >Assignee: Nitin Mehta > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CLOUDSTACK-2939) CPU limit is not getting set for vm after scaleup to a service offering which have cpu cap enabled
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] prashant kumar mishra updated CLOUDSTACK-2939: -- Description: Steps to reproduce 1-Deploye a vm with small service offering (memory:512,cpu:500;cpu cap=not enable) 2-Scaleup to service offering (memory:512,cpu:1000, cpu cap=enable) Expected -- cpu limit should be set for the vm Actual there is no cpu limit for vm My observation -- 1-CPU limit is set to unlimited when i do scaleup from a SO (cpu cap enable) to a SO (cpu cap enable) . was: Steps to reproduce 1-Deploye a vm with small service offering (memory:512,cpu:500;cpu cap=not enable) 2-Scaleup to service offering (memory:512,cpu:1000, cpu cap=enable) Expected -- cpu limit should be set for the vm Actual there is no cpu limit for vm > CPU limit is not getting set for vm after scaleup to a service offering which > have cpu cap enabled > -- > > Key: CLOUDSTACK-2939 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2939 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server, VMware >Affects Versions: 4.2.0 > Environment: VMware ESXI-5.1 >Reporter: prashant kumar mishra > Fix For: 4.2.0 > > Attachments: logs.rar, screenshot-1.jpg > > > Steps to reproduce > > 1-Deploye a vm with small service offering (memory:512,cpu:500;cpu cap=not > enable) > 2-Scaleup to service offering (memory:512,cpu:1000, cpu cap=enable) > Expected > -- > cpu limit should be set for the vm > Actual > > there is no cpu limit for vm > My observation > -- > 1-CPU limit is set to unlimited when i do scaleup from a SO (cpu cap enable) > to a SO (cpu cap enable) . -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CLOUDSTACK-2940) Domain on SSVM is not being updated for download urls that come for CS.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nitin Mehta resolved CLOUDSTACK-2940. - Resolution: Fixed > Domain on SSVM is not being updated for download urls that come for CS. > --- > > Key: CLOUDSTACK-2940 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2940 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Nitin Mehta >Assignee: Nitin Mehta > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CLOUDSTACK-2609) [MultipleIPsPerNic][SharedNetworks] nic_secondary_ips account/domainid is different when compared with primary ups
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2609?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jayapal Reddy resolved CLOUDSTACK-2609. --- Resolution: Fixed > [MultipleIPsPerNic][SharedNetworks] nic_secondary_ips account/domainid is > different when compared with primary ups > -- > > Key: CLOUDSTACK-2609 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2609 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Network Controller >Affects Versions: 4.2.0 > Environment: commit # 85d54cd1c088997dd08f0328984bee1a55703636 >Reporter: venkata swamybabu budumuru >Assignee: Jayapal Reddy > Fix For: 4.2.0 > > Attachments: logs.tgz > > > Steps to reproduce : > 1. Have latest CloudStack with advanced zone having KVM cluster with 1 host > 2. Have at least one non-ROOT domain user > 3. Create at least one share network with scope set domain of the above user > 4. deploy a VM connected to the above shared networks > 5. acquire at least one secondary ips for the above NICs > Observations : > (i) verify in the db cloud.nic_secondary_ips for account and domain id info. > here is the snapshot of the db > mysql> select * from nic_secondary_ips; > ++--+--+---+---+-++-++---+ > | id | uuid | vmId | nicId | ip4_address | > ip6_address | network_id | created | account_id | domain_id | > ++--+--+---+---+-++-++---+ > | 4 | 8402dfa2-94b2-4001-8c2c-b52d5c76bbad | 27 |69 | 10.147.44.235 | > NULL|217 | 2013-05-21 19:49:40 | 1 | 1 | > | 5 | 43954e3e-c5bf-4833-983c-9aec27a27e14 | 27 |70 | 10.147.54.235 | > NULL|218 | 2013-05-21 19:54:24 | 1 | 1 | > ++--+--+---+---+-++-++---+ > (ii) Here is the snapshot of user_ip_address that contains the primary ip > address info > mysql> select * from user_ip_address where id=42\G > *** 1. row *** > id: 42 >uuid: a744755a-f5cd-4959-b338-1c36eaa56c32 > account_id: 4 > domain_id: 2 > public_ip_address: 10.147.54.231 > data_center_id: 3 > source_nat: 0 > allocated: 2013-05-21 17:49:41 > vlan_db_id: 5 > one_to_one_nat: 0 > vm_id: NULL > state: Allocated > mac_address: 32 > source_network_id: 218 > network_id: NULL > physical_network_id: 202 > is_system: 0 > vpc_id: NULL > dnat_vmip: NULL > 1 row in set (0.00 sec) > (iii) In case of user_ip_address, it contains the account and domain id of > the user who deployed the vm but, in case of secondary IPs, it contains the > account and domain id as 1. > Attaching all the required logs along with db dump to the bug. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLOUDSTACK-2940) Domain on SSVM is not being updated for download urls that come for CS.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13680981#comment-13680981 ] Nitin Mehta commented on CLOUDSTACK-2940: - The core of the issue is that the realhostip is hard coded for download urls and was not updated while fixing the bug. Steps to followed to verify the fix: 1. Install the build with out fix 2. Change the global setting "secstorage.ssl.cert.domain" to a custom domain name say, "cloud.tsk" 3. Try to download a template, this still provides the download URL with realhostip.com domain. 4. Now, upgrade to the build with fix. 5. Try to download a template, this provides the URL with changed domain name "cloud.tsk". Following scenarios are tested: 1. Copy ISO & template from one zone to another. 2. Download ISO, template and volume. Check whether the download URL is with changed domain name Above mentioned scenarios are passing. However to check whether the URL is actually working or not, we need to update SSL for the new domain "cloud.tsk" in this case. This is still in progress. Excerpt from the certificate error, while accessing the download URL. == 10-147-53-66.cloud.tsk uses an invalid security certificate. The certificate is only valid for the following names: *.realhostip.com , realhostip.com (Error code: ssl_error_bad_cert_domain) == > Domain on SSVM is not being updated for download urls that come for CS. > --- > > Key: CLOUDSTACK-2940 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2940 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Nitin Mehta >Assignee: Nitin Mehta > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLOUDSTACK-2940) Domain on SSVM is not being updated for download urls that come for CS.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13680983#comment-13680983 ] ASF subversion and git services commented on CLOUDSTACK-2940: - Commit e73aafc09ae3dc21dcbf8851f29c4b1977489fe6 in branch refs/heads/master from [~nitinme] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=e73aafc ] CLOUDSTACK-2940 Allowing Replacement of realhostip.com with a customized domain for SSVM. Though the config variable was there we were always hardcoding to realhostip.com Reviewed-by: Abhi > Domain on SSVM is not being updated for download urls that come for CS. > --- > > Key: CLOUDSTACK-2940 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2940 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Nitin Mehta >Assignee: Nitin Mehta > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CLOUDSTACK-2940) Domain on SSVM is not being updated for download urls that come for CS.
Nitin Mehta created CLOUDSTACK-2940: --- Summary: Domain on SSVM is not being updated for download urls that come for CS. Key: CLOUDSTACK-2940 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2940 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Reporter: Nitin Mehta Assignee: Nitin Mehta -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLOUDSTACK-2749) QA: Write test plan and execute Testplan for midonet network integration
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13680978#comment-13680978 ] Dave Cahill commented on CLOUDSTACK-2749: - Test plan is here: https://cwiki.apache.org/confluence/display/CLOUDSTACK/MidoNet+Test+Plan > QA: Write test plan and execute Testplan for midonet network integration > > > Key: CLOUDSTACK-2749 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2749 > Project: CloudStack > Issue Type: Sub-task > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Network Controller >Affects Versions: 4.2.0 >Reporter: Sudha Ponnaganti >Assignee: Dave Cahill > Fix For: 4.2.0 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CLOUDSTACK-2751) Automation: Automate midonet plugin functionality
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dave Cahill resolved CLOUDSTACK-2751. - Resolution: Won't Fix Closing as Won't Fix after discussing with Sudha. This ticket doesn't make sense for the MidoNet plugin, as the MidoNet agent code etc which would be required for a full automated test are not publicly available. > Automation: Automate midonet plugin functionality > - > > Key: CLOUDSTACK-2751 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2751 > Project: CloudStack > Issue Type: Sub-task > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Network Controller >Affects Versions: 4.2.0 >Reporter: Sudha Ponnaganti > Fix For: 4.2.0 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CLOUDSTACK-2939) CPU limit is not getting set for vm after scaleup to a service offering which have cpu cap enabled
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] prashant kumar mishra updated CLOUDSTACK-2939: -- Attachment: logs.rar > CPU limit is not getting set for vm after scaleup to a service offering which > have cpu cap enabled > -- > > Key: CLOUDSTACK-2939 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2939 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server, VMware >Affects Versions: 4.2.0 > Environment: VMware ESXI-5.1 >Reporter: prashant kumar mishra > Fix For: 4.2.0 > > Attachments: logs.rar, screenshot-1.jpg > > > Steps to reproduce > > 1-Deploye a vm with small service offering (memory:512,cpu:500;cpu cap=not > enable) > 2-Scaleup to service offering (memory:512,cpu:1000, cpu cap=enable) > Expected > -- > cpu limit should be set for the vm > Actual > > there is no cpu limit for vm -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CLOUDSTACK-2937) Scheduled snapshot events should be shown to users
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nitin Mehta resolved CLOUDSTACK-2937. - Resolution: Fixed > Scheduled snapshot events should be shown to users > -- > > Key: CLOUDSTACK-2937 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2937 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Nitin Mehta > > Scheduled snapshot events are generated from root account rather than the > initiator accounts. Hence these initiated users are missing all events related > to their snapshots. > IMPACT > == > Users who have scheduled their snapshots are missing all the snapshot events > related to them as they are generated from root/system account. > DETAILED DESCRIPTION > == > Recurring snapshots are intiaited by a user, but they are created by Root user > on CS. > Whenever a snapshot is created, alongwith, a notification/event is also > created. > Since Root user creates the snapshot, the event is associated with Root user > and not with the user who initiated it. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLOUDSTACK-2937) Scheduled snapshot events should be shown to users
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13680972#comment-13680972 ] ASF subversion and git services commented on CLOUDSTACK-2937: - Commit d21e0647244db9e76b11038e7b8c55e1aca3b6aa in branch refs/heads/master from [~nitinme] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=d21e064 ] CLOUDSTACK-2937 Scheduled snapshot events should be shown to users > Scheduled snapshot events should be shown to users > -- > > Key: CLOUDSTACK-2937 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2937 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Nitin Mehta > > Scheduled snapshot events are generated from root account rather than the > initiator accounts. Hence these initiated users are missing all events related > to their snapshots. > IMPACT > == > Users who have scheduled their snapshots are missing all the snapshot events > related to them as they are generated from root/system account. > DETAILED DESCRIPTION > == > Recurring snapshots are intiaited by a user, but they are created by Root user > on CS. > Whenever a snapshot is created, alongwith, a notification/event is also > created. > Since Root user creates the snapshot, the event is associated with Root user > and not with the user who initiated it. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CLOUDSTACK-2939) CPU limit is not getting set for vm after scaleup to a service offering which have cpu cap enabled
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] prashant kumar mishra updated CLOUDSTACK-2939: -- Attachment: screenshot-1.jpg > CPU limit is not getting set for vm after scaleup to a service offering which > have cpu cap enabled > -- > > Key: CLOUDSTACK-2939 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2939 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server, VMware >Affects Versions: 4.2.0 > Environment: VMware ESXI-5.1 >Reporter: prashant kumar mishra > Fix For: 4.2.0 > > Attachments: screenshot-1.jpg > > > Steps to reproduce > > 1-Deploye a vm with small service offering (memory:512,cpu:500;cpu cap=not > enable) > 2-Scaleup to service offering (memory:512,cpu:1000, cpu cap=enable) > Expected > -- > cpu limit should be set for the vm > Actual > > there is no cpu limit for vm -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CLOUDSTACK-2939) CPU limit is not getting set for vm after scaleup to a service offering which have cpu cap enabled
prashant kumar mishra created CLOUDSTACK-2939: - Summary: CPU limit is not getting set for vm after scaleup to a service offering which have cpu cap enabled Key: CLOUDSTACK-2939 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2939 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Management Server, VMware Affects Versions: 4.2.0 Environment: VMware ESXI-5.1 Reporter: prashant kumar mishra Fix For: 4.2.0 Steps to reproduce 1-Deploye a vm with small service offering (memory:512,cpu:500;cpu cap=not enable) 2-Scaleup to service offering (memory:512,cpu:1000, cpu cap=enable) Expected -- cpu limit should be set for the vm Actual there is no cpu limit for vm -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CLOUDSTACK-2938) [Multiple_IP_Ranges] Password Service does not work in case of multiple subnets in a vlan
Sanjeev N created CLOUDSTACK-2938: - Summary: [Multiple_IP_Ranges] Password Service does not work in case of multiple subnets in a vlan Key: CLOUDSTACK-2938 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2938 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.2.0 Environment: Basic Zone with xen cluster Build: Latest build from master Reporter: Sanjeev N Priority: Critical Fix For: 4.2.0 Password Service does not work in case of multiple subnets in a vlan Steps to Reproduce: = 1.Bring up CS in basic zone with xen cluster 2.Add two CIDRs in guest network in the same vlan 3.Deploy a vm with password enabled template with ip address from CIDR1 4.Deploy another vm with the same password enabled template with ip address from CIDR2 Expected Behaviour: = Password reset should work for the guest vms deployed with ip addresses from both the CIDRs Actual Behaviour: == Password reset functionality worked only for the guest vm deployed with ip address from primary CIDR Observations: On the router vm it is observed that password service is running using socat process and it is listening only on the Router guest vms primary address. root@r-25-QA:~# netstat -atnp | grep 8080 tcp0 0 10.147.43.2:80800.0.0.0:* LISTEN 4723/socat root@r-25-QA:~# ip addr show eth0 2: eth0: mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether 06:f8:fc:00:00:0b brd ff:ff:ff:ff:ff:ff inet 10.147.43.2/25 brd 10.147.43.127 scope global eth0 inet 10.147.43.131/26 brd 10.147.43.191 scope global eth0:21 inet6 fe80::4f8:fcff:fe00:b/64 scope link valid_lft forever preferred_lft forever In the above output 10.147.43.131/26 is the alias ip address which got created after deploying the vm with the ip address from the second cidr. Password reset script resides on guest vm would be sending request to alias ip on VR to get the password, but would fail since socat process is not listening on the alias ip. Workaround: === Restarting password server process "/etc/init.d/cloud-passwd-srvr" would create another socat process listening on alias ip: root@r-25-QA:~# netstat -atnp | grep 8080 tcp0 0 10.147.43.131:8080 0.0.0.0:* LISTEN 4725/socat tcp0 0 10.147.43.2:80800.0.0.0:* LISTEN 4723/socat -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLOUDSTACK-2609) [MultipleIPsPerNic][SharedNetworks] nic_secondary_ips account/domainid is different when compared with primary ups
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2609?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13680946#comment-13680946 ] ASF subversion and git services commented on CLOUDSTACK-2609: - Commit 358f3edc575b9f5ec70010316523a8edeb540d55 in branch refs/heads/master from [~jayapal] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=358f3ed ] CLOUDSTACK-2609 Fixed accoundId, domainId for the secondary ip address for shared networks Signed-off-by: Abhinandan Prateek > [MultipleIPsPerNic][SharedNetworks] nic_secondary_ips account/domainid is > different when compared with primary ups > -- > > Key: CLOUDSTACK-2609 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2609 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Network Controller >Affects Versions: 4.2.0 > Environment: commit # 85d54cd1c088997dd08f0328984bee1a55703636 >Reporter: venkata swamybabu budumuru >Assignee: Jayapal Reddy > Fix For: 4.2.0 > > Attachments: logs.tgz > > > Steps to reproduce : > 1. Have latest CloudStack with advanced zone having KVM cluster with 1 host > 2. Have at least one non-ROOT domain user > 3. Create at least one share network with scope set domain of the above user > 4. deploy a VM connected to the above shared networks > 5. acquire at least one secondary ips for the above NICs > Observations : > (i) verify in the db cloud.nic_secondary_ips for account and domain id info. > here is the snapshot of the db > mysql> select * from nic_secondary_ips; > ++--+--+---+---+-++-++---+ > | id | uuid | vmId | nicId | ip4_address | > ip6_address | network_id | created | account_id | domain_id | > ++--+--+---+---+-++-++---+ > | 4 | 8402dfa2-94b2-4001-8c2c-b52d5c76bbad | 27 |69 | 10.147.44.235 | > NULL|217 | 2013-05-21 19:49:40 | 1 | 1 | > | 5 | 43954e3e-c5bf-4833-983c-9aec27a27e14 | 27 |70 | 10.147.54.235 | > NULL|218 | 2013-05-21 19:54:24 | 1 | 1 | > ++--+--+---+---+-++-++---+ > (ii) Here is the snapshot of user_ip_address that contains the primary ip > address info > mysql> select * from user_ip_address where id=42\G > *** 1. row *** > id: 42 >uuid: a744755a-f5cd-4959-b338-1c36eaa56c32 > account_id: 4 > domain_id: 2 > public_ip_address: 10.147.54.231 > data_center_id: 3 > source_nat: 0 > allocated: 2013-05-21 17:49:41 > vlan_db_id: 5 > one_to_one_nat: 0 > vm_id: NULL > state: Allocated > mac_address: 32 > source_network_id: 218 > network_id: NULL > physical_network_id: 202 > is_system: 0 > vpc_id: NULL > dnat_vmip: NULL > 1 row in set (0.00 sec) > (iii) In case of user_ip_address, it contains the account and domain id of > the user who deployed the vm but, in case of secondary IPs, it contains the > account and domain id as 1. > Attaching all the required logs along with db dump to the bug. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CLOUDSTACK-2937) Scheduled snapshot events should be shown to users
Nitin Mehta created CLOUDSTACK-2937: --- Summary: Scheduled snapshot events should be shown to users Key: CLOUDSTACK-2937 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2937 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Reporter: Nitin Mehta Scheduled snapshot events are generated from root account rather than the initiator accounts. Hence these initiated users are missing all events related to their snapshots. IMPACT == Users who have scheduled their snapshots are missing all the snapshot events related to them as they are generated from root/system account. DETAILED DESCRIPTION == Recurring snapshots are intiaited by a user, but they are created by Root user on CS. Whenever a snapshot is created, alongwith, a notification/event is also created. Since Root user creates the snapshot, the event is associated with Root user and not with the user who initiated it. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CLOUDSTACK-2750) Doc: Document midnet network integration
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2750?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dave Cahill reassigned CLOUDSTACK-2750: --- Assignee: Dave Cahill > Doc: Document midnet network integration > > > Key: CLOUDSTACK-2750 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2750 > Project: CloudStack > Issue Type: Sub-task > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Network Controller >Affects Versions: 4.2.0 >Reporter: Sudha Ponnaganti >Assignee: Dave Cahill > Fix For: 4.2.0 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CLOUDSTACK-2749) QA: Write test plan and execute Testplan for midonet network integration
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2749?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dave Cahill reassigned CLOUDSTACK-2749: --- Assignee: Dave Cahill > QA: Write test plan and execute Testplan for midonet network integration > > > Key: CLOUDSTACK-2749 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2749 > Project: CloudStack > Issue Type: Sub-task > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Network Controller >Affects Versions: 4.2.0 >Reporter: Sudha Ponnaganti >Assignee: Dave Cahill > Fix For: 4.2.0 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CLOUDSTACK-2084) [UI][Dedicated Resources : Public IP Addresses per tenant]When an IP range is dedicated to a project account, UI doesn't recognise that account and displays "add ac
[
https://issues.apache.org/jira/browse/CLOUDSTACK-2084?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jessica Wang resolved CLOUDSTACK-2084.
--
Resolution: Fixed
I'm unable to reproduce this bug.
Server-side seems to be changed(fixed).
I log in as account bbb_admin and create project bbb_admin_project.
Then, I dedicate an IP Range to this project account (bbb_admin).
API response shows account name:
{
"listvlaniprangesresponse": {
"count": 1,
"vlaniprange": [
{
"id": "a3e24575-04c8-4607-abf7-c22f00cb0938",
"forvirtualnetwork": true,
"zoneid": "a92cbc65-7f70-492f-9ea5-5a5191d72037",
"vlan": "159",
"account": "bbb_admin",
"domainid": "647bcd54-12ef-46d0-8e06-89325d2c8c66",
"domain": "bbb",
"gateway": "10.223.67.1",
"netmask": "255.255.255.0",
"startip": "10.223.67.25",
"endip": "10.223.67.26",
"networkid": "d9b905fa-f92f-49e9-bce0-4a110fb7f3fe",
"physicalnetworkid": "9c9b5eb5-19da-4c57-9a80-2a63d398d9bb"
}
]
}
}
> [UI][Dedicated Resources : Public IP Addresses per tenant]When an IP range is
> dedicated to a project account, UI doesn't recognise that account and
> displays "add account" instead of the account name.
> ---
>
> Key: CLOUDSTACK-2084
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2084
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: UI
>Affects Versions: 4.2.0
>Reporter: Abhinav Roy
>Assignee: Jessica Wang
> Fix For: 4.2.0
>
> Attachments: UI-CS2084.jpg
>
>
> Steps :
> ===
> 1. Deploy an advanced networking setup and create an account A1
> 2. Now login as user of account A1 and create a project P1. This leads to the
> creation of a project account AP1.
> 3. Now dedicate an IP range R1 to this project account AP1.
> Expected behaviour :
> ===
> 1. UI should display the project account name to which the IP range is
> dedicated.
> Observed behaviour :
> ===
> 1. UI doesn't show the project account name, instead it displays "add
> account" in that tab
> Reason :
> ==
> when we dedicate an IP range to a project account through the following API
> http://10.102.192.125:8096/client/api?command=dedicatePublicIpRange&id=9&domainid=4&account=PrjAcct-dom11-user-project-4
> We get this response :
>
>
> f240-5b93-4b8b-979d-1d3d95787a66
> true
> 004140d7-4270-45b1-86b1-2308af1de434
> untagged
> efceb0a6-1ac9-4cb7-8d10-26ab664b53d9
> dom11
> 10.102.192.1
> 255.255.252.0
> 10.102.195.61
> 10.102.195.70
> 40a04ee7-246f-4c80-bc18-13c68805b464
> 1027c082-fadd-44c2-a1e8-1397b10b55bc
> dom11-user-project
> 278c8249-0161-4a5a-bb24-91d4fa9f6e97
>
>
> In this response we don't see the account name, instead we see the project id
> and the project name. Hence the UI filter doesn't recognise the account name.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CLOUDSTACK-2080) [UI][Dedicated Resources : Public IP Addresses per tenant]UI hangs when dedication of Public IP addresses to an account fails.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2080?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jessica Wang updated CLOUDSTACK-2080: - Assignee: Brian Federle (was: Jessica Wang) Forward this bug to Brian since it needs to be fixed in UI widget level. In UI application level (ui/scripts/system.js), args.response.error() is being called when dedicatePublicIpRange API call fails. args.response.error() needs to be implemented in UI widget level as well. (Brian, please search keyword "dedicatePublicIpRange" in ui/scripts/system.js) > [UI][Dedicated Resources : Public IP Addresses per tenant]UI hangs when > dedication of Public IP addresses to an account fails. > -- > > Key: CLOUDSTACK-2080 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2080 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.2.0 >Reporter: Abhinav Roy >Assignee: Brian Federle > Fix For: 4.2.0 > > Attachments: UI-CS2080.jpg > > > Steps : > === > 1. Go to Infrastructure -> Zone -> -> Physical Network -> Public > -> IP Ranges and add an IP range. > 2. Now Dedicate the IP range to an account. Make sure that you give wrong > account or domain name > Expected behaviour : > === > 1. The IP Addresses dedication should fails gracefully with a error message. > Observed behaviour : > == > The process fails with an error message but the UI hangs [this is not seen > while doing the same process via API]. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (CLOUDSTACK-1976) [Automation]VM ware - After deleting VM from MS, vms are not getting removed from VCenter console
[ https://issues.apache.org/jira/browse/CLOUDSTACK-1976?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rayees Namathponnan closed CLOUDSTACK-1976. --- Resolution: Fixed Not found with latest build > [Automation]VM ware - After deleting VM from MS, vms are not getting removed > from VCenter console > -- > > Key: CLOUDSTACK-1976 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1976 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: VMware >Affects Versions: 4.2.0 > Environment: VMware > Build - Master >Reporter: Rayees Namathponnan >Assignee: Kelven Yang > Fix For: 4.2.0 > > > Steps to reproduce: > Step 1 : Create new build from master branch and install with Advanced > configuration on VMawre > Step 2 : In Global configuration set : expunge.delay = 60; > Step 3 : Create new VM, ( vm with internal "i-2-143-QA", got created) > Step 4 : Destroy the VM "i-2-143-QA" > Step 5 : Verify "i-2-143-QA" got removed from both MS console's vm instance > list and make sure this VM removed from VMware console > Actual Result: > After 60 sec, VM removed from Cloudstack UI, and vm "i-2-143-QA" in vm list; > but this vm not removed from VCenter console -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLOUDSTACK-2729) [Automation] Libvirt failed find primary storage and VM deployment failed
[
https://issues.apache.org/jira/browse/CLOUDSTACK-2729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13680484#comment-13680484
]
Rayees Namathponnan commented on CLOUDSTACK-2729:
-
Yes, i can mount both primary and secondary manually
Created this environment with two primary storages
"10.223.110.232:/export/home/rayees/SC_QA_AUTO4/primary and
10.223.110.232:/export/home/rayees/SC_QA_AUTO4/primary2 ", after some point of
time 10.223.110.232:/export/home/rayees/SC_QA_AUTO4/primary2 removed from
"virsh pool-list --all" and the same time both the mount points are available
in kvm host, please see the mount output
[root@Rack2Host11 tmp]# mount
/dev/sda2 on / type ext3 (rw)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
devpts on /dev/pts type devpts (rw,gid=5,mode=620)
tmpfs on /dev/shm type tmpfs (rw,rootcontext="system_u:object_r:tmpfs_t:s0")
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)
nfsd on /proc/fs/nfsd type nfsd (rw)
10.223.110.232:/export/home/rayees/SC_QA_AUTO4/primary on
/mnt/fff90cb5-06dd-33b3-8815-d78c08ca01d9 type nfs (rw,noac,addr=10.223.110.232)
10.223.110.232:/export/home/rayees/SC_QA_AUTO4/primary2 on
/mnt/41b632b5-40b3-3024-a38b-ea259c72579f type nfs (rw,noac,addr=10.223.110.232)
If i restart libvirtd service , both primary storages getting listed in "virsh
pool-list --all"
> [Automation] Libvirt failed find primary storage and VM deployment failed
>
>
> Key: CLOUDSTACK-2729
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2729
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Storage Controller
>Affects Versions: 4.2.0
> Environment: Master branch build
> Automation environment - KVM
>Reporter: Rayees Namathponnan
> Fix For: 4.2.0
>
> Attachments: CLOUDSTACK-2729.rar
>
>
> Failed to deploy VM in automation, environment created with , 2 hosts and 2
> primary storages in a cluster
> 1) /export/home/rayees/SC_QA_AUTO4/primary2
> 2) /export/home/rayees/SC_QA_AUTO4/primary
> Libvirt failed to find the primary storage
> /export/home/rayees/SC_QA_AUTO4/primary and VM deployment failed
> MS log
> 2013-05-28 21:11:44,540 DEBUG [agent.transport.Request] (consoleproxy-1:null)
> Seq 4-936706756: Sending { Cmd , MgmtId: 29066118877352, via: 4, Ver: v1,
> Flags: 100111,
> [{"StartCommand":{"vm":{"id":29,"name":"v-29-QA","type":"ConsoleProxy","cpus":1,"minSpeed":500,"maxSpeed":500,"minRam":1073741824,"maxRam":1073741824,"arch":"x86_64","os":"Debian
> GNU/Linux 5.0 (32-bit)","bootArgs":" template=domP type=consoleproxy
> host=10.223.49.195 port=8250 name=v-29-QA premium=true zone=1 pod=1
> guid=Proxy.29 proxy_vm=29 disable_rp_filter=true eth2ip=10.223.122.73
> eth2mask=255.255.255.192 gateway=10.223.122.65 eth0ip=169.254.0.154
> eth0mask=255.255.0.0 eth1ip=10.223.50.96 eth1mask=255.255.255.192
> mgmtcidr=10.223.49.192/26 localgw=10.223.50.65 internaldns1=10.223.110.254
> dns1=72.52.126.11","rebootOnCrash":false,"enableHA":false,"limitCpuUse":false,"vncPassword":"d099568827911cef","params":{},"uuid":"5a146833-6a8c-44e5-83c0-50f34accf513","disks":[{"id":32,"name":"ROOT-29","mountPoint":"/export/home/rayees/SC_QA_AUTO4/primary","path":"f6f8d865-e9c0-4188-8a33-6c6383ca5075","size":276406784,"type":"ROOT","storagePoolType":"NetworkFilesystem","storagePoolUuid":"fff90cb5-06dd-33b3-8815-d78c08ca01d9","deviceId":0}],"nics":[{"deviceId":2,"networkRateMbps":-1,"defaultNic":true,"uuid":"21175978-96bd-4160-8228-8ad15aa40c66","ip":"10.223.122.73","netmask":"255.255.255.192","gateway":"10.223.122.65","mac":"06:2e:5a:00:00:42","dns1":"72.52.126.11","broadcastType":"Vlan","type":"Public","broadcastUri":"vlan://1221","isolationUri":"vlan://1221","isSecurityGroupEnabled":false},{"deviceId":0,"networkRateMbps":-1,"defaultNic":false,"uuid":"e0651452-a76e-4564-96b2-3d5d51e9bcd6","ip":"169.254.0.154","netmask":"255.255.0.0","gateway":"169.254.0.1","mac":"0e:00:a9:fe:00:9a","broadcastType":"LinkLocal","type":"Control","isSecurityGroupEnabled":false},{"deviceId":1,"networkRateMbps":-1,"defaultNic":false,"uuid":"0765c229-468e-4dfd-8382-24ac49791a8d","ip":"10.223.50.96","netmask":"255.255.255.192","gateway":"10.223.50.65","mac":"06:a8:e8:00:00:1d","broadcastType":"Native","type":"Management","isSecurityGroupEnabled":false}]},"hostIp":"10.223.50.66","wait":0}},{"check.CheckSshCommand":{"ip":"169.254.0.154","port":3922,"interval":6,"retries":100,"name":"v-29-QA","wait":0}}]
> }
> 2013-05-28 21:11:44,552 DEBUG [agent.transport.Request]
> (AgentManager-Handler-1:null) Seq 4-936706756: Processing: { Ans: , MgmtId:
> 290661188773
[jira] [Commented] (CLOUDSTACK-2935) Regression test cases are not tear down account if there failure in test case
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13680467#comment-13680467 ] Rayees Namathponnan commented on CLOUDSTACK-2935: - testclient.testcase.TestVPCNetworkPFRules testclient.testcase.TestVPCNetworkLBRules > Regression test cases are not tear down account if there failure in test case > -- > > Key: CLOUDSTACK-2935 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2935 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation >Affects Versions: 4.2.0 > Environment: Automation >Reporter: Rayees Namathponnan >Assignee: Girish Shilamkar > Fix For: 4.2.0 > > > Some of regression test cases are not tearing down account if there failure > in test case , due to this resources are not getting freed -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CLOUDSTACK-2935) Regression test cases are not tear down account if there failure in test case
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rayees Namathponnan updated CLOUDSTACK-2935: Assignee: Girish Shilamkar > Regression test cases are not tear down account if there failure in test case > -- > > Key: CLOUDSTACK-2935 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2935 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation >Affects Versions: 4.2.0 > Environment: Automation >Reporter: Rayees Namathponnan >Assignee: Girish Shilamkar > Fix For: 4.2.0 > > > Some of regression test cases are not tearing down account if there failure > in test case , due to this resources are not getting freed -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CLOUDSTACK-2935) Regression test cases are not tear down account if there failure in test case
Rayees Namathponnan created CLOUDSTACK-2935: --- Summary: Regression test cases are not tear down account if there failure in test case Key: CLOUDSTACK-2935 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2935 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.2.0 Environment: Automation Reporter: Rayees Namathponnan Fix For: 4.2.0 Some of regression test cases are not tearing down account if there failure in test case , due to this resources are not getting freed -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CLOUDSTACK-2934) list firewall rules should list uuids in response
Jayapal Reddy created CLOUDSTACK-2934: - Summary: list firewall rules should list uuids in response Key: CLOUDSTACK-2934 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2934 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Reporter: Jayapal Reddy listfirewallrules is showing numeric ip address id and listegressfirewallrules is listing numeric network id. The APIs should list UUID instead of numeric ids. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLOUDSTACK-2404) Document isolation in advanced zones using PVLAN
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13680369#comment-13680369 ] ASF subversion and git services commented on CLOUDSTACK-2404: - Commit aa01ba75ca7baf35a7060f165439cfa78a401841 in branch refs/heads/master from [~radhikap] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=aa01ba7 ] CLOUDSTACK-2404 > Document isolation in advanced zones using PVLAN > > > Key: CLOUDSTACK-2404 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2404 > Project: CloudStack > Issue Type: Sub-task > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Doc >Affects Versions: 4.2.0 >Reporter: Jessica Tomechak >Assignee: Radhika Nair > Fix For: 4.2.0 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLOUDSTACK-2404) Document isolation in advanced zones using PVLAN
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13680368#comment-13680368 ] ASF subversion and git services commented on CLOUDSTACK-2404: - Commit c12a8187af0613d990334fe0798e1a5d4e6ded80 in branch refs/heads/master from [~radhikap] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=c12a818 ] CLOUDSTACK-2404 > Document isolation in advanced zones using PVLAN > > > Key: CLOUDSTACK-2404 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2404 > Project: CloudStack > Issue Type: Sub-task > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Doc >Affects Versions: 4.2.0 >Reporter: Jessica Tomechak >Assignee: Radhika Nair > Fix For: 4.2.0 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CLOUDSTACK-2933) [VPC][VMware]Unable to login to VM using the LB configured public IP.
manasaveloori created CLOUDSTACK-2933: - Summary: [VPC][VMware]Unable to login to VM using the LB configured public IP. Key: CLOUDSTACK-2933 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2933 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Network Controller Affects Versions: 4.2.0 Reporter: manasaveloori Priority: Critical Fix For: 4.2.0 Steps: 1. Have a CS with advanced zone and VMware host. 2. Create a VPC and a tier. 3. Deploy a VM on the tier . 4. Apply allow_all ACL to the tier network 5. Acquire a public Ip and define a LB rule on port 22. 6. SSH to the VM using the public IP on which LB is defined. Observations: Unable to do SSH to VM: The LB rule is configured in the router under /etc/haproxy/haproxy.cfg. root@r-3-VM:/var/log# vi /etc/haproxy/haproxy.cfg global log 127.0.0.1:3914 local0 warning maxconn 4096 chroot /var/lib/haproxy user haproxy group haproxy daemon defaults log global modetcp option dontlognull retries 3 option redispatch option forwardfor option forceclose timeout connect5000 timeout client 5 timeout server 5 listen stats_on_public 10.147.47.5:8081 mode http option httpclose stats enable stats uri /admin?stats stats realm Haproxy\ Statistics stats authadmin1:AdMiN123 listen 10_147_47_60-22 10.147.47.60:22 balance roundrobin server 10_147_47_60-22_0 10.0.1.249:22 check root@r-3-VM:~# iptables -L -nv Chain INPUT (policy DROP 73 packets, 6206 bytes) pkts bytes target prot opt in out source destination 15 872 LOGtcp -- * * 0.0.0.0/00.0.0.0/0 tcp dpt:22 LOG flags 0 level 4 prefix "**swamy**" 6127 446K NETWORK_STATS all -- * * 0.0.0.0/0 0.0.0.0/0 0 0 ACCEPT all -- * * 0.0.0.0/0224.0.0.18 0 0 ACCEPT all -- * * 0.0.0.0/0225.0.0.50 0 0 ACCEPT icmp -- * * 0.0.0.0/00.0.0.0/0 0 0 ACCEPT all -- lo * 0.0.0.0/00.0.0.0/0 41 2460 ACCEPT tcp -- eth0 * 0.0.0.0/00.0.0.0/0 state NEW tcp dpt:3922 5996 436K ACCEPT all -- * * 0.0.0.0/00.0.0.0/0 state RELATED,ESTABLISHED 0 0 ACCEPT udp -- eth2 * 0.0.0.0/00.0.0.0/0 udp dpt:67 11 809 ACCEPT udp -- eth2 * 0.0.0.0/010.0.1.1 udp dpt:53 0 0 ACCEPT tcp -- eth2 * 0.0.0.0/010.0.1.1 tcp dpt:53 0 0 ACCEPT tcp -- eth2 * 0.0.0.0/010.0.1.1 state NEW tcp dpt:80 0 0 ACCEPT tcp -- eth2 * 0.0.0.0/010.0.1.1 state NEW tcp dpt:8080 0 0 ACCEPT udp -- eth3 * 0.0.0.0/00.0.0.0/0 udp dpt:67 6 456 ACCEPT udp -- eth3 * 0.0.0.0/010.0.2.1 udp dpt:53 0 0 ACCEPT tcp -- eth3 * 0.0.0.0/010.0.2.1 tcp dpt:53 0 0 ACCEPT tcp -- eth3 * 0.0.0.0/010.0.2.1 state NEW tcp dpt:80 0 0 ACCEPT tcp -- eth3 * 0.0.0.0/010.0.2.1 state NEW tcp dpt:8080 0 0 load_balancer_eth0 tcp -- eth0 * 0.0.0.0/0 0.0.0.0/0 0 0 load_balancer_eth2 tcp -- eth2 * 0.0.0.0/0 0.0.0.0/0 0 0 load_balancer_eth3 tcp -- eth3 * 0.0.0.0/0 0.0.0.0/0 15 872 lb_stats tcp -- * * 0.0.0.0/00.0.0.0/0 Chain FORWARD (policy DROP 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 118 28242 NETWORK_STATS_eth1 all -- * * 0.0.0.0/0 0.0.0.0/0 118 28242 NETWORK_STATS all -- * * 0.0.0.0/0 0.0.0.0/0 113 27942 ACCEPT all -- * * 0.0.0.0/00.0.0.0/0 state RELATED,ESTABLISHED 4 240 ACCEPT all -- * * 10.0.0.0/16 !10.0.0.0/16 0 0 ACL_INBOUND_eth3 all -- * eth30.0.0.0/0 10.0.2.0/24 160 ACL_INBOUND_eth2 all -- * eth20.0.0.0/0 10.0.1.0/24 Chain OUTPUT (policy ACCEPT 7639 packets, 575K bytes) pkts bytes target prot opt in out source destination 7639
[jira] [Resolved] (CLOUDSTACK-2932) Allow deleting of snapshots that have errored out.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2932?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nitin Mehta resolved CLOUDSTACK-2932. - Resolution: Fixed > Allow deleting of snapshots that have errored out. > -- > > Key: CLOUDSTACK-2932 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2932 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Nitin Mehta >Assignee: Nitin Mehta > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CLOUDSTACK-2932) Allow deleting of snapshots that have errored out.
Nitin Mehta created CLOUDSTACK-2932: --- Summary: Allow deleting of snapshots that have errored out. Key: CLOUDSTACK-2932 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2932 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Reporter: Nitin Mehta Assignee: Nitin Mehta -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLOUDSTACK-2932) Allow deleting of snapshots that have errored out.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13680366#comment-13680366 ] ASF subversion and git services commented on CLOUDSTACK-2932: - Commit 07e5cbe81394fbd4e36d5ad2fff36cd8eea40a8e in branch refs/heads/master from [~nitinme] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=07e5cbe ] CLOUDSTACK-2932 Allow deleting of snapshots that have errored out. Simply mark the removed column as there is no physiocal clean up required > Allow deleting of snapshots that have errored out. > -- > > Key: CLOUDSTACK-2932 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2932 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Nitin Mehta >Assignee: Nitin Mehta > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CLOUDSTACK-2931) Allow deleting of snapshots that have errored out.
Nitin Mehta created CLOUDSTACK-2931: --- Summary: Allow deleting of snapshots that have errored out. Key: CLOUDSTACK-2931 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2931 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Affects Versions: 4.2.0 Reporter: Nitin Mehta Assignee: Nitin Mehta Fix For: 4.2.0 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CLOUDSTACK-2347) Zone filter for listSnapshots API
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Harikrishna Patnala reassigned CLOUDSTACK-2347: --- Assignee: Harikrishna Patnala > Zone filter for listSnapshots API > - > > Key: CLOUDSTACK-2347 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2347 > Project: CloudStack > Issue Type: New Feature > Security Level: Public(Anyone can view this level - this is the > default.) > Components: API, Snapshot >Reporter: David Noland >Assignee: Harikrishna Patnala > > Many of the list APIs such as listVirtualMachines, listVPCs, listNetworks, > listVolumes, and listTemplates have a zoneid parameter that can be used to > restrict the last to a specified zone. The zoneid parameter is also needed > for the listSnapshot API in order to properly filter the result set by zone. > The returned XML should also return the zone id for each snapshot. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CLOUDSTACK-2930) [VPC][VMware]Exception while applying the user created ACL with protocol as “All” to a tier.
manasaveloori created CLOUDSTACK-2930:
-
Summary: [VPC][VMware]Exception while applying the user created
ACL with protocol as “All” to a tier.
Key: CLOUDSTACK-2930
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2930
Project: CloudStack
Issue Type: Bug
Security Level: Public (Anyone can view this level - this is the default.)
Components: Network Controller
Affects Versions: 4.2.0
Reporter: manasaveloori
Priority: Critical
Fix For: 4.2.0
Steps:
1. Have a CS with advanced zone and VMwarehost.
2. Create a VPC and a tier network
3. Create a Network ACL list and a ACL rule under it with protocol field
as “All”
4. Apply the rule to the tier .
Observation:
Observed the following exception:
2013-06-11 18:15:48,505 ERROR [utils.ssh.SshHelper]
(DirectAgent-137:10.147.40.29) SSH execution of command
/opt/cloud/bin/vpc_acl.sh -d eth2 -i 10.0.1.1 -m 24 -a
Ingress:all:1:65535:0.0.0.0/0:ACCEPT:,Egress:all:1:65535:0.0.0.0/0:ACCEPT:, has
an error status code in return. result output: iptables v1.4.14: unknown option
"--dport"
Try `iptables -h' or 'iptables --help' for more information.
2013-06-11 18:15:48,508 ERROR [vmware.resource.VmwareResource]
(DirectAgent-137:10.147.40.29) SetNetworkACLAnswer on domain router
10.147.40.183 failed. message: iptables v1.4.14: unknown option "--dport"
Try `iptables -h' or 'iptables --help' for more information.
2013-06-11 18:15:48,510 DEBUG [agent.manager.DirectAgentAttache]
(DirectAgent-137:null) Seq 1-1378812142: Response Received:
2013-06-11 18:15:48,510 DEBUG [agent.transport.Request] (DirectAgent-137:null)
Seq 1-1378812142: Processing: { Ans: , MgmtId: 6805241462820, via: 1, Ver: v1,
Flags: 0,
[{"routing.SetNetworkACLAnswer":{"results":[null,null],"result":false,"wait":0}}]
}
2013-06-11 18:15:48,510 DEBUG [agent.transport.Request]
(Job-Executor-15:job-28) Seq 1-1378812142: Received: { Ans: , MgmtId:
6805241462820, via: 1, Ver: v1, Flags: 0, { SetNetworkACLAnswer } }
2013-06-11 18:15:48,511 ERROR [cloud.async.AsyncJobManagerImpl]
(Job-Executor-15:job-28) Unexpected exception while executing
org.apache.cloudstack.api.command.user.network.ReplaceNetworkACLListCmd
com.cloud.exception.ResourceUnavailableException: Resource [DataCenter:1] is
unreachable: Unable to apply network acls on router
at
com.cloud.network.router.VirtualNetworkApplianceManagerImpl.applyRules(VirtualNetworkApplianceManagerImpl.java:3743)
at
com.cloud.network.router.VpcVirtualNetworkApplianceManagerImpl.applyNetworkACLs(VpcVirtualNetworkApplianceManagerImpl.java:717)
at
com.cloud.network.element.VpcVirtualRouterElement.applyNetworkACLs(VpcVirtualRouterElement.java:416)
at
com.cloud.network.vpc.NetworkACLManagerImpl.applyACLItemsToNetwork(NetworkACLManagerImpl.java:409)
at
com.cloud.network.vpc.NetworkACLManagerImpl.applyACLToNetwork(NetworkACLManagerImpl.java:337)
at
com.cloud.network.vpc.NetworkACLManagerImpl.replaceNetworkACL(NetworkACLManagerImpl.java:158)
at
com.cloud.network.vpc.NetworkACLServiceImpl.replaceNetworkACL(NetworkACLServiceImpl.java:233)
at
org.apache.cloudstack.api.command.user.network.ReplaceNetworkACLListCmd.execute(ReplaceNetworkACLListCmd.java:109)
at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:155)
at
com.cloud.async.AsyncJobManagerImpl$1.run(AsyncJobManagerImpl.java:437)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:679)
2013-06-11 18:15:48,513 DEBUG [cloud.async.AsyncJobManagerImpl]
(Job-Executor-15:job-28) Complete async job-28, jobStatus: 2, resultCode: 530,
result: Error Code: 530 Error text: Resource [DataCenter:1] is unreachable:
Unable to apply network acls on router
2013-06-11 18:15:50,096 DEBUG [cloud.api.ApiServlet] (catalina-exec-5:null)
===START=== 10.252.192.69 -- GET
command=queryAsyncJobResult&jobId=c092d23d-ffca-4fa7-b433-54649bc54c49&response=json&sessionkey=ydkJIe0pKVxfZP3S8wS9PfFTNjY%3D&_=1370935298970
2013-06-11 18:15:50,117 DEBUG [cloud.async.AsyncJobManagerImpl]
(catalina-exec-5:null) Async
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLOUDSTACK-2879) Try using Nicira NVP plugin
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13680303#comment-13680303 ] tuna commented on CLOUDSTACK-2879: -- @Seb: I have just understood after talking with Hugo, definitely. > Try using Nicira NVP plugin > --- > > Key: CLOUDSTACK-2879 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2879 > Project: CloudStack > Issue Type: Sub-task > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: tuna >Assignee: tuna > Fix For: 4.2.0 > > > This process I'm trying to use Nicira NVP plugin. Building, trying and > figuring out what's happen. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CLOUDSTACK-2929) unable to upgrade from version 3.0.6.20121222035904
david vz created CLOUDSTACK-2929: Summary: unable to upgrade from version 3.0.6.20121222035904 Key: CLOUDSTACK-2929 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2929 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.1.0 Environment: centos 6.4 Reporter: david vz i tried an upgrade from citrix cloudstack/platform 3.0.6 to 4.1 but the upgrade fails: 2013-06-11 10:18:04,038 DEBUG [upgrade.dao.VersionDaoImpl] (Timer-1:null) Checking to see if the database is at a version befo re it was the version table is created 2013-06-11 10:18:04,046 INFO [cloud.upgrade.DatabaseUpgradeChecker] (Timer-1:null) DB version = 3.0.6.20121222035904 Code Ver sion = 4.1.0 2013-06-11 10:18:04,054 INFO [cloud.upgrade.DatabaseUpgradeChecker] (Timer-1:null) Database upgrade must be performed from 3. 0.6.20121222035904 to 4.1.0 2013-06-11 10:18:04,054 ERROR [cloud.upgrade.DatabaseUpgradeChecker] (Timer-1:null) There is no upgrade path from 3.0.6.201212 22035904 to 4.1.0 2013-06-11 10:18:04,056 ERROR [utils.component.ComponentContext] (Timer-1:null) System integrity check failed. Refuse to start up -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLOUDSTACK-2404) Document isolation in advanced zones using PVLAN
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13680299#comment-13680299 ] Radhika Nair commented on CLOUDSTACK-2404: -- Documentation defect has a dependency on https://issues.apache.org/jira/browse/CLOUDSTACK-2870 > Document isolation in advanced zones using PVLAN > > > Key: CLOUDSTACK-2404 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2404 > Project: CloudStack > Issue Type: Sub-task > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Doc >Affects Versions: 4.2.0 >Reporter: Jessica Tomechak >Assignee: Radhika Nair > Fix For: 4.2.0 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLOUDSTACK-2348) UI of feature "Isolation in Advanced Zone using PVLANs"
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13680297#comment-13680297 ] Radhika Nair commented on CLOUDSTACK-2348: -- Documentation defect has a dependency on https://issues.apache.org/jira/browse/CLOUDSTACK-2870 > UI of feature "Isolation in Advanced Zone using PVLANs" > --- > > Key: CLOUDSTACK-2348 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2348 > Project: CloudStack > Issue Type: Sub-task > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Jessica Wang >Assignee: Jessica Wang > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLOUDSTACK-1456) Isolation in Advanced Zone using PVLANs
[ https://issues.apache.org/jira/browse/CLOUDSTACK-1456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13680298#comment-13680298 ] Radhika Nair commented on CLOUDSTACK-1456: -- Documentation defect has a dependency on https://issues.apache.org/jira/browse/CLOUDSTACK-2870 > Isolation in Advanced Zone using PVLANs > --- > > Key: CLOUDSTACK-1456 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1456 > Project: CloudStack > Issue Type: New Feature > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.2.0 >Reporter: Manan Shah >Assignee: Sheng Yang > Fix For: 4.2.0 > > > Requirements described at: > https://cwiki.apache.org/confluence/display/CLOUDSTACK/Isolation+in+Advanced+Zone+using+PVLANs > Requirements discussion email thread link: -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CLOUDSTACK-654) ELB: auto-scale request handling capacity by provisioning LB appliances
[ https://issues.apache.org/jira/browse/CLOUDSTACK-654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Murali Reddy updated CLOUDSTACK-654: Fix Version/s: (was: 4.2.0) > ELB: auto-scale request handling capacity by provisioning LB appliances > --- > > Key: CLOUDSTACK-654 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-654 > Project: CloudStack > Issue Type: New Feature > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Network Controller >Affects Versions: Future >Reporter: Murali Reddy >Assignee: Murali Reddy > Fix For: Future > > > Current implementation of ELB in CloudStack is different in semantics from > ELB of AWS. Elastic Load Balancing in AWS automatically scales its request > handling capacity in response to incoming application traffic. In contrast, > CloudStack does not provide the ability to auto-scale the request handling > capacity. > This feature request is to enhance ELB as implemented in CloudStack to > support auto-scale the request handling capability. > Release Planning: > Dev list discussion: http://markmail.org/message/lx6tyikvmvd6wix4 > Functional Spec: unknown > Feature branch: unknown -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CLOUDSTACK-654) ELB: auto-scale request handling capacity by provisioning LB appliances
[ https://issues.apache.org/jira/browse/CLOUDSTACK-654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Murali Reddy updated CLOUDSTACK-654: Fix Version/s: Future Moving out from 4.2, ELB is not proposed feature for 4.2 > ELB: auto-scale request handling capacity by provisioning LB appliances > --- > > Key: CLOUDSTACK-654 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-654 > Project: CloudStack > Issue Type: New Feature > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Network Controller >Affects Versions: Future >Reporter: Murali Reddy >Assignee: Murali Reddy > Fix For: 4.2.0, Future > > > Current implementation of ELB in CloudStack is different in semantics from > ELB of AWS. Elastic Load Balancing in AWS automatically scales its request > handling capacity in response to incoming application traffic. In contrast, > CloudStack does not provide the ability to auto-scale the request handling > capacity. > This feature request is to enhance ELB as implemented in CloudStack to > support auto-scale the request handling capability. > Release Planning: > Dev list discussion: http://markmail.org/message/lx6tyikvmvd6wix4 > Functional Spec: unknown > Feature branch: unknown -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
