[jira] [Commented] (CLOUDSTACK-7907) UI heavily broken
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14251377#comment-14251377 ] Andrija Panic commented on CLOUDSTACK-7907: --- Ilya - I have just searched my API log - and there is NO line(s) when the issue happened (I expected to see 2 api lines with deployVm.., one that failed, and than the second that was executed fine - since I clicked on the URL in the firebug on the exact api URL) - but there is ony the line that was successfuly executed - so as Alex said - this seems like JS issue - the same seems true (although I could not catch the error) - for the second issue described here - breadcrumb issue - geting back to home page, instead of Instances list etc... UI heavily broken - Key: CLOUDSTACK-7907 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7907 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: API Affects Versions: 4.3.0, 4.4.1 Environment: not relevant Reporter: Andrija Panic Priority: Critical (A serious one, that we encounter pretty often): Issue: I start new VM deloyment wizard, choose template etc at the end when I click the finish, when the job should be sent to MGMT server - simply nothing happens - so ajax does't get executed at all, no litle circle spinning etc - no logs in mgmt server, simply ajax doesn't get executed...Same behaviour sometimes happen when I click on Configure on the VPC. I confirmed behaviour in acs 4.3.0 and I'm still checking in 4.4.1, but I doubt anything has changed OR 2) (not a big issue, however very annoying): I filter instances by some account/domain, then click on some instance (view it's properties or whatever), than in the breadcrumb I click back on instances, and instead of being show the page with all the filtered instances, I get back to the home page of ACS... So it doesn't really happens always, but randomly, with different browsers, clearing all cache etc... The issue here is that nothing get's logged to MGMT log at all... -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-8088) VM scale up is failing in vmware with Unable to execute ScaleVmCommand due to java.lang.NullPointerException
Saksham Srivastava created CLOUDSTACK-8088: -- Summary: VM scale up is failing in vmware with Unable to execute ScaleVmCommand due to java.lang.NullPointerException Key: CLOUDSTACK-8088 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8088 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Reporter: Saksham Srivastava Assignee: Saksham Srivastava setup --- Vcenter 5.5 (esxi-5.5) setup steps to reproduce 1-enable zone level setting enable.dynamic.scale.vm 2-deploy a vm which is dynamically scalable 3- try to scale up vm to medium SO (#cpu=1,cpu=1000,mem=1024) expected --- scaling up should be sucessful actual --- scaling up is failing with error com.cloud.utils.exception.CloudRuntimeException: Unable to scale vm due to Unable to execute ScaleVmCommand due to java.lang.NullPointerException -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-4735) Management IP address pool exhausted
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4735?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14251396#comment-14251396 ] Nux commented on CLOUDSTACK-4735: - Daniel, Thanks for sharing, that worked for me, too. I hope this will get addressed in the code, though. Management IP address pool exhausted Key: CLOUDSTACK-4735 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4735 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: XenServer Affects Versions: 4.1.0 Environment: Management server (CentOS 6.4 64 bit, CLoudStack 4.1.1), XenServer 6.1 Reporter: Daniel Hertanu With only one computing node in the Zone, rebooting it without enabling maintenance mode on it, determines the management IP addresses pool to be exhausted as a result of CloudStack attempting continuously to provision the system VMs. Regardless the expunge delay or interval values, the management IPs are not released anymore and the common error reported in the logs is: 2013-09-24 14:56:24,410 INFO [cloud.vm.VirtualMachineManagerImpl] (Job-Executor-22:job-72) Insufficient capacity com.cloud.exception.InsufficientAddressCapacityException: Unable to get a management ip addressScope=interface com.cloud.dc.Pod; id=1 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8088) VM scale up is failing in vmware with Unable to execute ScaleVmCommand due to java.lang.NullPointerException
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8088?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14251395#comment-14251395 ] Star Guo commented on CLOUDSTACK-8088: -- Hi, which version? VM scale up is failing in vmware with Unable to execute ScaleVmCommand due to java.lang.NullPointerException Key: CLOUDSTACK-8088 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8088 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Reporter: Saksham Srivastava Assignee: Saksham Srivastava setup --- Vcenter 5.5 (esxi-5.5) setup steps to reproduce 1-enable zone level setting enable.dynamic.scale.vm 2-deploy a vm which is dynamically scalable 3- try to scale up vm to medium SO (#cpu=1,cpu=1000,mem=1024) expected --- scaling up should be sucessful actual --- scaling up is failing with error com.cloud.utils.exception.CloudRuntimeException: Unable to scale vm due to Unable to execute ScaleVmCommand due to java.lang.NullPointerException -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8088) VM scale up is failing in vmware with Unable to execute ScaleVmCommand due to java.lang.NullPointerException
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8088?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14251400#comment-14251400 ] ASF subversion and git services commented on CLOUDSTACK-8088: - Commit 1df0453d27e8378065c15878067fc9d2dc961e30 in cloudstack's branch refs/heads/master from [~saksham] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=1df0453 ] CLOUDSTACK-8088: VM scale up is failing in vmware with Unable to execute ScaleVmCommand due to java.lang.NullPointerException VM scale up is failing in vmware with Unable to execute ScaleVmCommand due to java.lang.NullPointerException Key: CLOUDSTACK-8088 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8088 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Reporter: Saksham Srivastava Assignee: Saksham Srivastava setup --- Vcenter 5.5 (esxi-5.5) setup steps to reproduce 1-enable zone level setting enable.dynamic.scale.vm 2-deploy a vm which is dynamically scalable 3- try to scale up vm to medium SO (#cpu=1,cpu=1000,mem=1024) expected --- scaling up should be sucessful actual --- scaling up is failing with error com.cloud.utils.exception.CloudRuntimeException: Unable to scale vm due to Unable to execute ScaleVmCommand due to java.lang.NullPointerException -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8088) VM scale up is failing in vmware with Unable to execute ScaleVmCommand due to java.lang.NullPointerException
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8088?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14251399#comment-14251399 ] Saksham Srivastava commented on CLOUDSTACK-8088: Using current master/4.5 VM scale up is failing in vmware with Unable to execute ScaleVmCommand due to java.lang.NullPointerException Key: CLOUDSTACK-8088 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8088 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Reporter: Saksham Srivastava Assignee: Saksham Srivastava setup --- Vcenter 5.5 (esxi-5.5) setup steps to reproduce 1-enable zone level setting enable.dynamic.scale.vm 2-deploy a vm which is dynamically scalable 3- try to scale up vm to medium SO (#cpu=1,cpu=1000,mem=1024) expected --- scaling up should be sucessful actual --- scaling up is failing with error com.cloud.utils.exception.CloudRuntimeException: Unable to scale vm due to Unable to execute ScaleVmCommand due to java.lang.NullPointerException -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-8088) VM scale up is failing in vmware with Unable to execute ScaleVmCommand due to java.lang.NullPointerException
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8088?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Saksham Srivastava updated CLOUDSTACK-8088: --- Affects Version/s: 4.5.0 VM scale up is failing in vmware with Unable to execute ScaleVmCommand due to java.lang.NullPointerException Key: CLOUDSTACK-8088 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8088 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.5.0 Reporter: Saksham Srivastava Assignee: Saksham Srivastava setup --- Vcenter 5.5 (esxi-5.5) setup steps to reproduce 1-enable zone level setting enable.dynamic.scale.vm 2-deploy a vm which is dynamically scalable 3- try to scale up vm to medium SO (#cpu=1,cpu=1000,mem=1024) expected --- scaling up should be sucessful actual --- scaling up is failing with error com.cloud.utils.exception.CloudRuntimeException: Unable to scale vm due to Unable to execute ScaleVmCommand due to java.lang.NullPointerException -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-8088) VM scale up is failing in vmware with Unable to execute ScaleVmCommand due to java.lang.NullPointerException
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8088?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Saksham Srivastava updated CLOUDSTACK-8088:
---
Description:
setup
---
Vcenter 5.5 (esxi-5.5) setup
steps to reproduce
1-enable zone level setting enable.dynamic.scale.vm
2-deploy a vm which is dynamically scalable
3- try to scale up vm to medium SO (#cpu=1,cpu=1000,mem=1024)
expected
---
scaling up should be sucessful
actual
---
scaling up is failing with error
com.cloud.utils.exception.CloudRuntimeException: Unable to scale vm due to
Unable to execute ScaleVmCommand due to java.lang.NullPointerException
During scale vm command, in VmwareResource.java the following line is executed
where there is no value sent in the 'details' map for the configuration
parameter 'vmware.reserve.mem'. because of this NPE is occured.
int getReservedMemoryMb(VirtualMachineTO vmSpec) {
if
(vmSpec.getDetails().get(VMwareGuru.VmwareReserveMemory.key()).equalsIgnoreCase(true))
{ ...
In VirtualMachineManagerImpl.java ScaleVmCommand is prepared where
VirtualMachineTO transfer object is created as following where we are not
setting 'details' map.
public ScaleVmCommand(String vmName, int cpus, Integer minSpeed, Integer
maxSpeed, long minRam, long maxRam, boolean limitCpuUse) {
.
this.vm = new VirtualMachineTO(1L, vmName, null, cpus, minSpeed, maxSpeed,
minRam, maxRam, null, null, false, limitCpuUse, null);
.
We need to pass these configuration parameters (vmware.reserve.cpu,
vmware.reserve.mem) to VMwareResource.java using VirtualMachineTO.
was:
setup
---
Vcenter 5.5 (esxi-5.5) setup
steps to reproduce
1-enable zone level setting enable.dynamic.scale.vm
2-deploy a vm which is dynamically scalable
3- try to scale up vm to medium SO (#cpu=1,cpu=1000,mem=1024)
expected
---
scaling up should be sucessful
actual
---
scaling up is failing with error
com.cloud.utils.exception.CloudRuntimeException: Unable to scale vm due to
Unable to execute ScaleVmCommand due to java.lang.NullPointerException
VM scale up is failing in vmware with Unable to execute ScaleVmCommand due to
java.lang.NullPointerException
Key: CLOUDSTACK-8088
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8088
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Affects Versions: 4.5.0
Reporter: Saksham Srivastava
Assignee: Saksham Srivastava
setup
---
Vcenter 5.5 (esxi-5.5) setup
steps to reproduce
1-enable zone level setting enable.dynamic.scale.vm
2-deploy a vm which is dynamically scalable
3- try to scale up vm to medium SO (#cpu=1,cpu=1000,mem=1024)
expected
---
scaling up should be sucessful
actual
---
scaling up is failing with error
com.cloud.utils.exception.CloudRuntimeException: Unable to scale vm due to
Unable to execute ScaleVmCommand due to java.lang.NullPointerException
During scale vm command, in VmwareResource.java the following line is
executed where there is no value sent in the 'details' map for the
configuration parameter 'vmware.reserve.mem'. because of this NPE is occured.
int getReservedMemoryMb(VirtualMachineTO vmSpec) {
if
(vmSpec.getDetails().get(VMwareGuru.VmwareReserveMemory.key()).equalsIgnoreCase(true))
{ ...
In VirtualMachineManagerImpl.java ScaleVmCommand is prepared where
VirtualMachineTO transfer object is created as following where we are not
setting 'details' map.
public ScaleVmCommand(String vmName, int cpus, Integer minSpeed, Integer
maxSpeed, long minRam, long maxRam, boolean limitCpuUse) {
.
this.vm = new VirtualMachineTO(1L, vmName, null, cpus, minSpeed, maxSpeed,
minRam, maxRam, null, null, false, limitCpuUse, null);
.
We need to pass these configuration parameters (vmware.reserve.cpu,
vmware.reserve.mem) to VMwareResource.java using VirtualMachineTO.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-8089) Fix component/test_explicit_dedication.py and move it to maint folder
Gaurav Aradhye created CLOUDSTACK-8089: -- Summary: Fix component/test_explicit_dedication.py and move it to maint folder Key: CLOUDSTACK-8089 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8089 Project: CloudStack Issue Type: Test Security Level: Public (Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.5.0 Reporter: Gaurav Aradhye Assignee: Gaurav Aradhye Fix For: 4.5.0 The test suite needs to be run separately as it requires to have one host with no VM running. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8038) Create a new reusable tinylinux appliance for all hypervisors
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14251443#comment-14251443 ] Nux commented on CLOUDSTACK-8038: - Ok, I think I got something that works on all HVs including PV xen, root passwd ssh key scripts needed to be modified a bit to work with busybox. I am still working on getting the root resize feature working as there isn't really space for anything serious. Use some tmpfs or /dev/null for tests :) https://github.com/NuxRo/macchinina the img file is raw, grab the bz2 appropriate for your setup. Create a new reusable tinylinux appliance for all hypervisors - Key: CLOUDSTACK-8038 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8038 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Reporter: Rohit Yadav Assignee: Rohit Yadav Fix For: Future, 4.6.0 Using our systemvm build infra/scripts, create a tiny linux appliance (10-20 MB in size) that has the reset password/ssh-public-key scripts for testing purposes. Make this available for everyone for various hypervisors - Xen, VMWare, KVM, HyperV, OVM (LXC). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-8090) Move test_dedicated_vlan_range.py to maint folder - test cases need to be run separately
Gaurav Aradhye created CLOUDSTACK-8090: -- Summary: Move test_dedicated_vlan_range.py to maint folder - test cases need to be run separately Key: CLOUDSTACK-8090 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8090 Project: CloudStack Issue Type: Test Security Level: Public (Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.5.0 Reporter: Gaurav Aradhye Assignee: Gaurav Aradhye Fix For: 4.5.0 The test cases need to be run separately as they create vlan ranges, and dedicated them to an account/project. In between the vlans should not get consumed by other account. Else test cases will fail like following Execute cmd: dedicateguestvlanrange failed, due to: errorCode: 431, errorText:Guest vlan from this range 3390 is allocated to a different account. Can only dedicate a range which has no allocated vlans or has vlans allocated to the same account -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-8090) Move test_dedicated_vlan_range.py to maint folder - test cases need to be run separately
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8090?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gaurav Aradhye updated CLOUDSTACK-8090: --- Status: Reviewable (was: In Progress) Move test_dedicated_vlan_range.py to maint folder - test cases need to be run separately Key: CLOUDSTACK-8090 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8090 Project: CloudStack Issue Type: Test Security Level: Public(Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.5.0 Reporter: Gaurav Aradhye Assignee: Gaurav Aradhye Labels: automation Fix For: 4.5.0 The test cases need to be run separately as they create vlan ranges, and dedicated them to an account/project. In between the vlans should not get consumed by other account. Else test cases will fail like following Execute cmd: dedicateguestvlanrange failed, due to: errorCode: 431, errorText:Guest vlan from this range 3390 is allocated to a different account. Can only dedicate a range which has no allocated vlans or has vlans allocated to the same account -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7184) HA should wait for at least 'xen.heartbeat.interval' sec before starting HA on vm's when host is marked down
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14251498#comment-14251498 ] ASF subversion and git services commented on CLOUDSTACK-7184: - Commit 8dfcd51bebe990449faff21e39b2b9315d11046d in cloudstack's branch refs/heads/4.4 from [~dahn] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=8dfcd51 ] CLOUDSTACK-7184 new config var is not available when not in the db HA should wait for at least 'xen.heartbeat.interval' sec before starting HA on vm's when host is marked down Key: CLOUDSTACK-7184 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7184 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Hypervisor Controller, Management Server, XenServer Affects Versions: 4.3.0, 4.4.0, 4.5.0 Environment: CloudStack 4.3 with XenServer 6.2 hypervisors Reporter: Remi Bergsma Assignee: Daan Hoogland Priority: Blocker Hypervisor got isolated for 30 seconds due to a network issue. CloudStack did discover this and marked the host as down, and immediately started HA. Just 18 seconds later the hypervisor returned and we ended up with 5 vm's that were running on two hypervisors at the same time. This, of course, resulted in file system corruption and the loss of the vm's. One side of the story is why XenServer allowed this to happen (will not bother you with this one). The CloudStack side of the story: HA should only start after at least xen.heartbeat.interval seconds. If the host is down long enough, the Xen heartbeat script will fence the hypervisor and prevent corruption. If it is not down long enough, nothing should happen. Logs (short): 2014-07-25 05:03:28,596 WARN [c.c.a.m.DirectAgentAttache] (DirectAgent-122:ctx-690badc5) Unable to get current status on 505(mccpvmXX) . 2014-07-25 05:03:31,920 ERROR [c.c.a.m.AgentManagerImpl] (AgentTaskPool-10:ctx-11b9af3e) Host is down: 505-mccpvmXX. Starting HA on the VMs . 2014-07-25 05:03:49,655 DEBUG [c.c.h.Status] (ClusteredAgentManager Timer:ctx-0e00979c) Transition:[Resource state = Enabled, Agent event = AgentDisconnected, Host id = 505, name = mccpvmXX] cs marks host down: 2014-07-25 05:03:31,920 cs marks host up: 2014-07-25 05:03:49,655 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7184) HA should wait for at least 'xen.heartbeat.interval' sec before starting HA on vm's when host is marked down
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14251530#comment-14251530 ] ASF subversion and git services commented on CLOUDSTACK-7184: - Commit 86c425ec839ccc14fe323b48b875753633675e3f in cloudstack's branch refs/heads/4.4 from [~dahn] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=86c425e ] CLOUDSTACK-7184 cp feature fix in conf-value-description HA should wait for at least 'xen.heartbeat.interval' sec before starting HA on vm's when host is marked down Key: CLOUDSTACK-7184 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7184 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Hypervisor Controller, Management Server, XenServer Affects Versions: 4.3.0, 4.4.0, 4.5.0 Environment: CloudStack 4.3 with XenServer 6.2 hypervisors Reporter: Remi Bergsma Assignee: Daan Hoogland Priority: Blocker Hypervisor got isolated for 30 seconds due to a network issue. CloudStack did discover this and marked the host as down, and immediately started HA. Just 18 seconds later the hypervisor returned and we ended up with 5 vm's that were running on two hypervisors at the same time. This, of course, resulted in file system corruption and the loss of the vm's. One side of the story is why XenServer allowed this to happen (will not bother you with this one). The CloudStack side of the story: HA should only start after at least xen.heartbeat.interval seconds. If the host is down long enough, the Xen heartbeat script will fence the hypervisor and prevent corruption. If it is not down long enough, nothing should happen. Logs (short): 2014-07-25 05:03:28,596 WARN [c.c.a.m.DirectAgentAttache] (DirectAgent-122:ctx-690badc5) Unable to get current status on 505(mccpvmXX) . 2014-07-25 05:03:31,920 ERROR [c.c.a.m.AgentManagerImpl] (AgentTaskPool-10:ctx-11b9af3e) Host is down: 505-mccpvmXX. Starting HA on the VMs . 2014-07-25 05:03:49,655 DEBUG [c.c.h.Status] (ClusteredAgentManager Timer:ctx-0e00979c) Transition:[Resource state = Enabled, Agent event = AgentDisconnected, Host id = 505, name = mccpvmXX] cs marks host down: 2014-07-25 05:03:31,920 cs marks host up: 2014-07-25 05:03:49,655 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7184) HA should wait for at least 'xen.heartbeat.interval' sec before starting HA on vm's when host is marked down
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14251532#comment-14251532 ] ASF subversion and git services commented on CLOUDSTACK-7184: - Commit 8b6e251b5d5e47a45f392d999fde0f14765c3ca1 in cloudstack's branch refs/heads/4.5 from [~dahn] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=8b6e251 ] CLOUDSTACK-7184 config value for xen heartbeat timeout HA should wait for at least 'xen.heartbeat.interval' sec before starting HA on vm's when host is marked down Key: CLOUDSTACK-7184 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7184 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Hypervisor Controller, Management Server, XenServer Affects Versions: 4.3.0, 4.4.0, 4.5.0 Environment: CloudStack 4.3 with XenServer 6.2 hypervisors Reporter: Remi Bergsma Assignee: Daan Hoogland Priority: Blocker Hypervisor got isolated for 30 seconds due to a network issue. CloudStack did discover this and marked the host as down, and immediately started HA. Just 18 seconds later the hypervisor returned and we ended up with 5 vm's that were running on two hypervisors at the same time. This, of course, resulted in file system corruption and the loss of the vm's. One side of the story is why XenServer allowed this to happen (will not bother you with this one). The CloudStack side of the story: HA should only start after at least xen.heartbeat.interval seconds. If the host is down long enough, the Xen heartbeat script will fence the hypervisor and prevent corruption. If it is not down long enough, nothing should happen. Logs (short): 2014-07-25 05:03:28,596 WARN [c.c.a.m.DirectAgentAttache] (DirectAgent-122:ctx-690badc5) Unable to get current status on 505(mccpvmXX) . 2014-07-25 05:03:31,920 ERROR [c.c.a.m.AgentManagerImpl] (AgentTaskPool-10:ctx-11b9af3e) Host is down: 505-mccpvmXX. Starting HA on the VMs . 2014-07-25 05:03:49,655 DEBUG [c.c.h.Status] (ClusteredAgentManager Timer:ctx-0e00979c) Transition:[Resource state = Enabled, Agent event = AgentDisconnected, Host id = 505, name = mccpvmXX] cs marks host down: 2014-07-25 05:03:31,920 cs marks host up: 2014-07-25 05:03:49,655 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7184) HA should wait for at least 'xen.heartbeat.interval' sec before starting HA on vm's when host is marked down
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14251566#comment-14251566 ] ASF subversion and git services commented on CLOUDSTACK-7184: - Commit 8b6e251b5d5e47a45f392d999fde0f14765c3ca1 in cloudstack's branch refs/heads/master from [~dahn] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=8b6e251 ] CLOUDSTACK-7184 config value for xen heartbeat timeout HA should wait for at least 'xen.heartbeat.interval' sec before starting HA on vm's when host is marked down Key: CLOUDSTACK-7184 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7184 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Hypervisor Controller, Management Server, XenServer Affects Versions: 4.3.0, 4.4.0, 4.5.0 Environment: CloudStack 4.3 with XenServer 6.2 hypervisors Reporter: Remi Bergsma Assignee: Daan Hoogland Priority: Blocker Hypervisor got isolated for 30 seconds due to a network issue. CloudStack did discover this and marked the host as down, and immediately started HA. Just 18 seconds later the hypervisor returned and we ended up with 5 vm's that were running on two hypervisors at the same time. This, of course, resulted in file system corruption and the loss of the vm's. One side of the story is why XenServer allowed this to happen (will not bother you with this one). The CloudStack side of the story: HA should only start after at least xen.heartbeat.interval seconds. If the host is down long enough, the Xen heartbeat script will fence the hypervisor and prevent corruption. If it is not down long enough, nothing should happen. Logs (short): 2014-07-25 05:03:28,596 WARN [c.c.a.m.DirectAgentAttache] (DirectAgent-122:ctx-690badc5) Unable to get current status on 505(mccpvmXX) . 2014-07-25 05:03:31,920 ERROR [c.c.a.m.AgentManagerImpl] (AgentTaskPool-10:ctx-11b9af3e) Host is down: 505-mccpvmXX. Starting HA on the VMs . 2014-07-25 05:03:49,655 DEBUG [c.c.h.Status] (ClusteredAgentManager Timer:ctx-0e00979c) Transition:[Resource state = Enabled, Agent event = AgentDisconnected, Host id = 505, name = mccpvmXX] cs marks host down: 2014-07-25 05:03:31,920 cs marks host up: 2014-07-25 05:03:49,655 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-4021) [Automation] TestExplicitDedication.test_01_deploy_vm_with_explicit_dedication failed to deploy VM
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Saksham Srivastava resolved CLOUDSTACK-4021.
Resolution: Duplicate
[Automation]
TestExplicitDedication.test_01_deploy_vm_with_explicit_dedication failed to
deploy VM
--
Key: CLOUDSTACK-4021
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4021
Project: CloudStack
Issue Type: Test
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: Saksham Srivastava
Fix For: 4.3.2
Test case
integration.component.test_explicit_dedication.TestExplicitDedication.test_01_deploy_vm_with_explicit_dedication
failing automation runs
Error Message
Execute cmd: asyncquery failed, due to: {errorcode : 533, errortext :
u'Unable to create a deployment for
VM[User|dec11341-27b0-4fc9-86f4-7570037a456c], Please check the affinity
groups provided, there may not be sufficient capacity to follow them'}
Stacktrace
Traceback (most recent call last):
File /usr/local/lib/python2.7/unittest/case.py, line 318, in run
testMethod()
File
/Repo_30X/ipcl/cloudstack/test/integration/component/test_explicit_dedication.py,
line 204, in test_01_deploy_vm_with_explicit_dedication
mode=self.services[mode]
File
/usr/local/lib/python2.7/site-packages/marvin/integration/lib/base.py, line
388, in create
virtual_machine = apiclient.deployVirtualMachine(cmd, method=method)
File
/usr/local/lib/python2.7/site-packages/marvin/cloudstackAPI/cloudstackAPIClient.py,
line 614, in deployVirtualMachine
response = self.connection.marvin_request(command,
response_type=response, method=method)
File
/usr/local/lib/python2.7/site-packages/marvin/cloudstackConnection.py, line
230, in marvin_request
response = self.poll(asyncJobId, response_type)
File
/usr/local/lib/python2.7/site-packages/marvin/cloudstackConnection.py, line
91, in poll
asyncquery, asyncResonse.jobresult)
cloudstackAPIException: Execute cmd: asyncquery failed, due to: {errorcode :
533, errortext : u'Unable to create a deployment for
VM[User|dec11341-27b0-4fc9-86f4-7570037a456c], Please check the affinity
groups provided, there may not be sufficient capacity to follow them'}
Looks like test case trying to create VM eventhough there is no host with
emplty VM
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-4021) [Automation] TestExplicitDedication.test_01_deploy_vm_with_explicit_dedication failed to deploy VM
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4021?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14251574#comment-14251574
]
Saksham Srivastava commented on CLOUDSTACK-4021:
Tracked by another ticket.https://issues.apache.org/jira/browse/CLOUDSTACK-8089
[Automation]
TestExplicitDedication.test_01_deploy_vm_with_explicit_dedication failed to
deploy VM
--
Key: CLOUDSTACK-4021
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4021
Project: CloudStack
Issue Type: Test
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: Saksham Srivastava
Fix For: 4.3.2
Test case
integration.component.test_explicit_dedication.TestExplicitDedication.test_01_deploy_vm_with_explicit_dedication
failing automation runs
Error Message
Execute cmd: asyncquery failed, due to: {errorcode : 533, errortext :
u'Unable to create a deployment for
VM[User|dec11341-27b0-4fc9-86f4-7570037a456c], Please check the affinity
groups provided, there may not be sufficient capacity to follow them'}
Stacktrace
Traceback (most recent call last):
File /usr/local/lib/python2.7/unittest/case.py, line 318, in run
testMethod()
File
/Repo_30X/ipcl/cloudstack/test/integration/component/test_explicit_dedication.py,
line 204, in test_01_deploy_vm_with_explicit_dedication
mode=self.services[mode]
File
/usr/local/lib/python2.7/site-packages/marvin/integration/lib/base.py, line
388, in create
virtual_machine = apiclient.deployVirtualMachine(cmd, method=method)
File
/usr/local/lib/python2.7/site-packages/marvin/cloudstackAPI/cloudstackAPIClient.py,
line 614, in deployVirtualMachine
response = self.connection.marvin_request(command,
response_type=response, method=method)
File
/usr/local/lib/python2.7/site-packages/marvin/cloudstackConnection.py, line
230, in marvin_request
response = self.poll(asyncJobId, response_type)
File
/usr/local/lib/python2.7/site-packages/marvin/cloudstackConnection.py, line
91, in poll
asyncquery, asyncResonse.jobresult)
cloudstackAPIException: Execute cmd: asyncquery failed, due to: {errorcode :
533, errortext : u'Unable to create a deployment for
VM[User|dec11341-27b0-4fc9-86f4-7570037a456c], Please check the affinity
groups provided, there may not be sufficient capacity to follow them'}
Looks like test case trying to create VM eventhough there is no host with
emplty VM
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-8091) Stale entry exists for a VM NIC even after an exception while adding a new nic to vm
Saksham Srivastava created CLOUDSTACK-8091: -- Summary: Stale entry exists for a VM NIC even after an exception while adding a new nic to vm Key: CLOUDSTACK-8091 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8091 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Affects Versions: 4.5.0 Reporter: Saksham Srivastava Assignee: Saksham Srivastava Steps: 1. Create an Isolated Network. 2. Make sure there are no guest vlans remaining. 3. Add an additional NIC to the VM with the network created in step 1. Observations: = 1. Adding network to the VM throws an error message And on refreshing the page, the new NIC shows up on CloudStack and acquires an IP address. This is due to the stale entry present in the database. 2. On the Hypervisor side, the NIC isn't mapped to the VM. Its only on the CloudStack side that we have the entry. Expected: = Need to clear the stale entry if the add NIC did not go through with success. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8091) Stale entry exists for a VM NIC even after an exception while adding a new nic to vm
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14251588#comment-14251588 ] ASF subversion and git services commented on CLOUDSTACK-8091: - Commit 4821bfffe2813ffb43761246e75cc7cf73291d27 in cloudstack's branch refs/heads/master from [~saksham] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=4821bff ] CLOUDSTACK-8091: Stale entry exists for a VM NIC even after an exception while adding a new nic to vm Stale entry exists for a VM NIC even after an exception while adding a new nic to vm Key: CLOUDSTACK-8091 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8091 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.5.0 Reporter: Saksham Srivastava Assignee: Saksham Srivastava Steps: 1. Create an Isolated Network. 2. Make sure there are no guest vlans remaining. 3. Add an additional NIC to the VM with the network created in step 1. Observations: = 1. Adding network to the VM throws an error message And on refreshing the page, the new NIC shows up on CloudStack and acquires an IP address. This is due to the stale entry present in the database. 2. On the Hypervisor side, the NIC isn't mapped to the VM. Its only on the CloudStack side that we have the entry. Expected: = Need to clear the stale entry if the add NIC did not go through with success. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-6853) Fail to remove the network when VM that used to run on this network (but not anymore) still exist
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6853?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Srikanteswararao Talluri closed CLOUDSTACK-6853. Verified. Closing the bug Fail to remove the network when VM that used to run on this network (but not anymore) still exist - Key: CLOUDSTACK-6853 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6853 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.4.0 Reporter: Alena Prokharchyk Assignee: Alena Prokharchyk Priority: Critical Fix For: 4.4.0 Steps to reproduce: 1) Create 2 networks 2) Deploy vm in network1. 3) Add vm to network2 using addNic api. 4) Remove vm from network2 using removeNic api. Try to remove the network2. The removal should be successful as there are no vms belong to it anymore. Bug: the network fails to remove, and the error message says that there is a vm (created on step2) still belonging to the network. Its a bug in the DB search method where we look for the VM in a particular network. In this case we do joins between table1=user_vm and table2=nics based on instance_id. As long as the result in table1 (vm) is not removed, its being returned to the user when the matching record is found in table2, no matter if the record in table2 is removed or not. It just has to exist there. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7301) subsequent snapshots failing after previous snapshot error
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14251607#comment-14251607 ] Rohit Yadav commented on CLOUDSTACK-7301: - I hit a similar issue and I think searching in JIRA I found that it has been fixed for 4.5/master; https://issues.apache.org/jira/browse/CLOUDSTACK-7947 will cherry-pick for 4.3/4.4 subsequent snapshots failing after previous snapshot error -- Key: CLOUDSTACK-7301 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7301 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.3.0 Reporter: Vincent Vuong After a snapshot that resulted in error, subsequent snapshots fails with the same error. both recurring and manual snapshots are failing. xenserver 6.2 server log: 014-08-10 02:40:11,212 INFO [o.a.c.a.c.u.s.CreateSnapshotCmd] (Job-Executor-76:ctx-6ce5578c ctx-5bb45501) VOLSS: createSnapshotCmd starts:1407663611212 2014-08-10 02:40:11,292 DEBUG [o.a.c.s.d.d.CloudStackPrimaryDataStoreDriverImpl] (Job-Executor-76:ctx-6ce5578c ctx-5bb45501) Failed to take snapshot: 2063 java.lang.NullPointerException at org.apache.cloudstack.storage.snapshot.SnapshotObject.getId(SnapshotObject.java:149) at org.apache.cloudstack.storage.datastore.ObjectInDataStoreManagerImpl.findObject(ObjectInDataStoreManagerImpl.java:338) at org.apache.cloudstack.storage.snapshot.SnapshotObject.getPath(SnapshotObject.java:206) at org.apache.cloudstack.storage.to.SnapshotObjectTO.init(SnapshotObjectTO.java:60) at org.apache.cloudstack.storage.snapshot.SnapshotObject.getTO(SnapshotObject.java:274) at org.apache.cloudstack.storage.datastore.driver.CloudStackPrimaryDataStoreDriverImpl.takeSnapshot(CloudStackPrimaryDataStoreDriverImpl.java:258) at org.apache.cloudstack.storage.snapshot.SnapshotServiceImpl.takeSnapshot(SnapshotServiceImpl.java:204) at org.apache.cloudstack.storage.snapshot.XenserverSnapshotStrategy.takeSnapshot(XenserverSnapshotStrategy.java:285) at com.cloud.storage.snapshot.SnapshotManagerImpl.takeSnapshot(SnapshotManagerImpl.java:945) at sun.reflect.GeneratedMethodAccessor232.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:622) at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317) at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150) at org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172) at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204) at com.sun.proxy.$Proxy160.takeSnapshot(Unknown Source) at org.apache.cloudstack.storage.volume.VolumeServiceImpl.takeSnapshot(VolumeServiceImpl.java:1373) at com.cloud.storage.VolumeApiServiceImpl.orchestrateTakeVolumeSnapshot(VolumeApiServiceImpl.java:1783) at com.cloud.storage.VolumeApiServiceImpl.takeSnapshot(VolumeApiServiceImpl.java:1724) at sun.reflect.GeneratedMethodAccessor231.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:622) at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317) at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150) at org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172) at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204) at com.sun.proxy.$Proxy196.takeSnapshot(Unknown Source) at org.apache.cloudstack.api.command.user.snapshot.CreateSnapshotCmd.execute(CreateSnapshotCmd.java:181) at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:161) at
[jira] [Commented] (CLOUDSTACK-7947) Unable to take a snapshot of a volumes
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7947?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14251616#comment-14251616 ] ASF subversion and git services commented on CLOUDSTACK-7947: - Commit ebf9897293a826d068b57c49c273bf4b9fd7f72e in cloudstack's branch refs/heads/4.3 from Edison Su [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=ebf9897 ] CLOUDSTACK-7301, CLOUDSTACK-7947: double check if parent snapshot is removed or not when creating new snapshot, check if parent snapshot is removed or not Reviewed-by: Min (cherry picked from commit bd799653293f9dc257ab68a3b04f6ea769e08e36) Signed-off-by: Rohit Yadav rohit.ya...@shapeblue.com Conflicts: engine/storage/snapshot/src/org/apache/cloudstack/storage/snapshot/XenserverSnapshotStrategy.java Unable to take a snapshot of a volumes -- Key: CLOUDSTACK-7947 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7947 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Storage Controller Reporter: edison su Assignee: edison su Priority: Critical Fix For: 4.5.0 2014-08-14 10:31:49,926 DEBUG [o.a.c.s.d.d.CloudStackPrimaryDataStoreDriverImpl] (Work-Job-Executor-127:ctx-89498f92 job-18945/job-18946 ctx-1fd165da) Failed to take snapshot: 1582 java.lang.NullPointerException at org.apache.cloudstack.storage.snapshot.SnapshotObject.getId(SnapshotObject.java:149) at org.apache.cloudstack.storage.datastore.ObjectInDataStoreManagerImpl.findObject(ObjectInDataStoreManagerImpl.java:338) at org.apache.cloudstack.storage.snapshot.SnapshotObject.getPath(SnapshotObject.java:206) at org.apache.cloudstack.storage.to.SnapshotObjectTO.init(SnapshotObjectTO.java:60) at org.apache.cloudstack.storage.snapshot.SnapshotObject.getTO(SnapshotObject.java:274) at org.apache.cloudstack.storage.datastore.driver.CloudStackPrimaryDataStoreDriverImpl.takeSnapshot(CloudStackPrimaryDataStoreDriverImpl.java:258) at org.apache.cloudstack.storage.snapshot.SnapshotServiceImpl.takeSnapshot(SnapshotServiceImpl.java:204) at org.apache.cloudstack.storage.snapshot.XenserverSnapshotStrategy.takeSnapshot(XenserverSnapshotStrategy.java:291) at com.cloud.storage.snapshot.SnapshotManagerImpl.takeSnapshot(SnapshotManagerImpl.java:946) at sun.reflect.GeneratedMethodAccessor412.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317) at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150) at org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172) at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204) at com.sun.proxy.$Proxy160.takeSnapshot(Unknown Source) at org.apache.cloudstack.storage.volume.VolumeServiceImpl.takeSnapshot(VolumeServiceImpl.java:1387) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CLOUDSTACK-7532) [Templates] Template status is not shown in UI/API response for non-default account users
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
prashant kumar mishra closed CLOUDSTACK-7532.
-
verified on latest setup :
--
http://10.*.*.*:8080/client/api?command=listTemplatesresponse=xmlsessionkey=0tf0Tk0i8yVfNWHjGAX9GYjdHA4%3Dtemplatefilter=selfid=cbe8fa1b-6eb5-41bc-a973-4d84fd612584_=1418907051805
listtemplatesresponse
cloud-stack-version=4.5.0-SNAPSHOTcount1/counttemplateidcbe8fa1b-6eb5-41bc-a973-4d84fd612584/idnameon/namedisplaytexton/displaytextispublicfalse/ispubliccreated2014-12-18T12:45:16+/createdisreadytrue/isreadypasswordenabledfalse/passwordenabledformatVHD/formatisfeaturedfalse/isfeaturedcrossZonesfalse/crossZonesostypeidc70d909a-86ac-11e4-bd3c-4edf767b3835/ostypeidostypenameDebian
GNU/Linux
7(64-bit)/ostypenameaccounttest/accountzoneida19117bf-74d6-4ae0-8c68-26bc12bbc287/zoneidzonenameXenRT-Zone-0/zonenamestatusDownload
Complete/statussize262144/sizetemplatetypeUSER/templatetypehypervisorXenServer/hypervisordomainROOT/domaindomainidc6cf7ec2-86ac-11e4-bd3c-4edf767b3835/domainidisextractablefalse/isextractablechecksum2502d91106d65a7606030dd04ffa130e/checksumdetails{hypervisortoolsversion=xenserver61}/detailssshkeyenabledfalse/sshkeyenabledisdynamicallyscalablefalse/isdynamicallyscalable/template/listtemplatesresponse
[Templates] Template status is not shown in UI/API response for non-default
account users
-
Key: CLOUDSTACK-7532
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7532
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: API, Template
Affects Versions: 4.5.0
Environment: Latest build from master with commit:
c33fea2cd27664db32c1173e98511470bf0a0724
Reporter: Sanjeev N
Assignee: Nitin Mehta
Priority: Critical
Labels: api, templates
Fix For: 4.5.0
Attachments: template_status.PNG
[Templates] Template status is not shown in UI/API response for non-default
account users
Steps to Reproduce:
===
1.Bring up CS with latest build
2.Create one account under root domain
3.Register template using the account created above
4.After the template download is completed verify the template status using
the account created at step2
Expected Result:
==
In UI/API response status field should be there and it should be set to
Download Complete after the successful template download.
Actual Behavior:
Status is shown only for the default admin user. But it is not showed to
other account users.
Impact:
==
Marvin tests which use template register would fail because of the status
filed missing.
Following is the code from base.py where the tests are failing:
elif 'Downloaded' in template.status:
time.sleep(interval)
becasue template.status is NoneType
API:
http://10.147.40.10:8080/client/api?command=listTemplatessessionkey=SgRK4kwpxxjg3Jx%2FwePLoS0aK3c%3Dtemplatefilter=selfid=550ad6ac-38d2-11e4-a56e-d4ae527ccfaa_=1410351906876
API Response:
===
listtemplatesresponse
cloud-stack-version=4.5.0-SNAPSHOTcount1/counttemplateid550ad6ac-38d2-11e4-a56e-d4ae527ccfaa/idnameCentOS
5.6(64-bit) no GUI (XenServer)/namedisplaytextCentOS 5.6(64-bit) no GUI
(XenServer)/displaytextispublictrue/ispubliccreated2014-09-10T15:59:38+0530/createdisreadytrue/isreadypasswordenabledfalse/passwordenabledformatVHD/formatisfeaturedtrue/isfeaturedcrossZonestrue/crossZonesostypeid572126ea-38d2-11e4-a56e-d4ae527ccfaa/ostypeidostypenameCentOS
5.6
(64-bit)/ostypenameaccountsystem/accountzoneid680f7c3a-a9ee-4ed3-b594-981d56f8da4b/zoneidzonenamez2/zonenamesize21474836480/sizetemplatetypeBUILTIN/templatetypehypervisorXenServer/hypervisordomainROOT/domaindomainid54e9d4e4-38d2-11e4-a56e-d4ae527ccfaa/domainidisextractabletrue/isextractablechecksum905cec879afd9c9d22ecc8036131a180/checksumsshkeyenabledfalse/sshkeyenabledisdynamicallyscalabletrue/isdynamicallyscalable/template/listtemplatesresponse
In the above API response status field is missing.
This bug is easily reproducible.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7301) subsequent snapshots failing after previous snapshot error
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14251615#comment-14251615 ] ASF subversion and git services commented on CLOUDSTACK-7301: - Commit ebf9897293a826d068b57c49c273bf4b9fd7f72e in cloudstack's branch refs/heads/4.3 from Edison Su [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=ebf9897 ] CLOUDSTACK-7301, CLOUDSTACK-7947: double check if parent snapshot is removed or not when creating new snapshot, check if parent snapshot is removed or not Reviewed-by: Min (cherry picked from commit bd799653293f9dc257ab68a3b04f6ea769e08e36) Signed-off-by: Rohit Yadav rohit.ya...@shapeblue.com Conflicts: engine/storage/snapshot/src/org/apache/cloudstack/storage/snapshot/XenserverSnapshotStrategy.java subsequent snapshots failing after previous snapshot error -- Key: CLOUDSTACK-7301 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7301 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.3.0 Reporter: Vincent Vuong After a snapshot that resulted in error, subsequent snapshots fails with the same error. both recurring and manual snapshots are failing. xenserver 6.2 server log: 014-08-10 02:40:11,212 INFO [o.a.c.a.c.u.s.CreateSnapshotCmd] (Job-Executor-76:ctx-6ce5578c ctx-5bb45501) VOLSS: createSnapshotCmd starts:1407663611212 2014-08-10 02:40:11,292 DEBUG [o.a.c.s.d.d.CloudStackPrimaryDataStoreDriverImpl] (Job-Executor-76:ctx-6ce5578c ctx-5bb45501) Failed to take snapshot: 2063 java.lang.NullPointerException at org.apache.cloudstack.storage.snapshot.SnapshotObject.getId(SnapshotObject.java:149) at org.apache.cloudstack.storage.datastore.ObjectInDataStoreManagerImpl.findObject(ObjectInDataStoreManagerImpl.java:338) at org.apache.cloudstack.storage.snapshot.SnapshotObject.getPath(SnapshotObject.java:206) at org.apache.cloudstack.storage.to.SnapshotObjectTO.init(SnapshotObjectTO.java:60) at org.apache.cloudstack.storage.snapshot.SnapshotObject.getTO(SnapshotObject.java:274) at org.apache.cloudstack.storage.datastore.driver.CloudStackPrimaryDataStoreDriverImpl.takeSnapshot(CloudStackPrimaryDataStoreDriverImpl.java:258) at org.apache.cloudstack.storage.snapshot.SnapshotServiceImpl.takeSnapshot(SnapshotServiceImpl.java:204) at org.apache.cloudstack.storage.snapshot.XenserverSnapshotStrategy.takeSnapshot(XenserverSnapshotStrategy.java:285) at com.cloud.storage.snapshot.SnapshotManagerImpl.takeSnapshot(SnapshotManagerImpl.java:945) at sun.reflect.GeneratedMethodAccessor232.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:622) at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317) at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150) at org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172) at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204) at com.sun.proxy.$Proxy160.takeSnapshot(Unknown Source) at org.apache.cloudstack.storage.volume.VolumeServiceImpl.takeSnapshot(VolumeServiceImpl.java:1373) at com.cloud.storage.VolumeApiServiceImpl.orchestrateTakeVolumeSnapshot(VolumeApiServiceImpl.java:1783) at com.cloud.storage.VolumeApiServiceImpl.takeSnapshot(VolumeApiServiceImpl.java:1724) at sun.reflect.GeneratedMethodAccessor231.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:622) at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317) at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150) at org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91) at
[jira] [Resolved] (CLOUDSTACK-7301) subsequent snapshots failing after previous snapshot error
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rohit Yadav resolved CLOUDSTACK-7301. - Resolution: Fixed Assignee: Rohit Yadav Cherry-picked fix for 4.3, 4.4; looks like already fixed for 4.5/master. Please close after testing. subsequent snapshots failing after previous snapshot error -- Key: CLOUDSTACK-7301 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7301 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.3.0 Reporter: Vincent Vuong Assignee: Rohit Yadav After a snapshot that resulted in error, subsequent snapshots fails with the same error. both recurring and manual snapshots are failing. xenserver 6.2 server log: 014-08-10 02:40:11,212 INFO [o.a.c.a.c.u.s.CreateSnapshotCmd] (Job-Executor-76:ctx-6ce5578c ctx-5bb45501) VOLSS: createSnapshotCmd starts:1407663611212 2014-08-10 02:40:11,292 DEBUG [o.a.c.s.d.d.CloudStackPrimaryDataStoreDriverImpl] (Job-Executor-76:ctx-6ce5578c ctx-5bb45501) Failed to take snapshot: 2063 java.lang.NullPointerException at org.apache.cloudstack.storage.snapshot.SnapshotObject.getId(SnapshotObject.java:149) at org.apache.cloudstack.storage.datastore.ObjectInDataStoreManagerImpl.findObject(ObjectInDataStoreManagerImpl.java:338) at org.apache.cloudstack.storage.snapshot.SnapshotObject.getPath(SnapshotObject.java:206) at org.apache.cloudstack.storage.to.SnapshotObjectTO.init(SnapshotObjectTO.java:60) at org.apache.cloudstack.storage.snapshot.SnapshotObject.getTO(SnapshotObject.java:274) at org.apache.cloudstack.storage.datastore.driver.CloudStackPrimaryDataStoreDriverImpl.takeSnapshot(CloudStackPrimaryDataStoreDriverImpl.java:258) at org.apache.cloudstack.storage.snapshot.SnapshotServiceImpl.takeSnapshot(SnapshotServiceImpl.java:204) at org.apache.cloudstack.storage.snapshot.XenserverSnapshotStrategy.takeSnapshot(XenserverSnapshotStrategy.java:285) at com.cloud.storage.snapshot.SnapshotManagerImpl.takeSnapshot(SnapshotManagerImpl.java:945) at sun.reflect.GeneratedMethodAccessor232.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:622) at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317) at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150) at org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172) at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204) at com.sun.proxy.$Proxy160.takeSnapshot(Unknown Source) at org.apache.cloudstack.storage.volume.VolumeServiceImpl.takeSnapshot(VolumeServiceImpl.java:1373) at com.cloud.storage.VolumeApiServiceImpl.orchestrateTakeVolumeSnapshot(VolumeApiServiceImpl.java:1783) at com.cloud.storage.VolumeApiServiceImpl.takeSnapshot(VolumeApiServiceImpl.java:1724) at sun.reflect.GeneratedMethodAccessor231.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:622) at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317) at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150) at org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172) at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204) at com.sun.proxy.$Proxy196.takeSnapshot(Unknown Source) at org.apache.cloudstack.api.command.user.snapshot.CreateSnapshotCmd.execute(CreateSnapshotCmd.java:181) at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:161) at com.cloud.api.ApiAsyncJobDispatcher.runJobInContext(ApiAsyncJobDispatcher.java:109)
[jira] [Commented] (CLOUDSTACK-7301) subsequent snapshots failing after previous snapshot error
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14251618#comment-14251618 ] ASF subversion and git services commented on CLOUDSTACK-7301: - Commit 0e312a7a779424519166d5bc2812672bbf7474a4 in cloudstack's branch refs/heads/4.4 from Edison Su [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=0e312a7 ] CLOUDSTACK-7301, CLOUDSTACK-7947: double check if parent snapshot is removed or not when creating new snapshot, check if parent snapshot is removed or not Reviewed-by: Min (cherry picked from commit bd799653293f9dc257ab68a3b04f6ea769e08e36) Signed-off-by: Rohit Yadav rohit.ya...@shapeblue.com Conflicts: engine/storage/snapshot/src/org/apache/cloudstack/storage/snapshot/XenserverSnapshotStrategy.java (cherry picked from commit ebf9897293a826d068b57c49c273bf4b9fd7f72e) Signed-off-by: Rohit Yadav rohit.ya...@shapeblue.com Conflicts: engine/storage/snapshot/src/org/apache/cloudstack/storage/snapshot/XenserverSnapshotStrategy.java subsequent snapshots failing after previous snapshot error -- Key: CLOUDSTACK-7301 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7301 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.3.0 Reporter: Vincent Vuong After a snapshot that resulted in error, subsequent snapshots fails with the same error. both recurring and manual snapshots are failing. xenserver 6.2 server log: 014-08-10 02:40:11,212 INFO [o.a.c.a.c.u.s.CreateSnapshotCmd] (Job-Executor-76:ctx-6ce5578c ctx-5bb45501) VOLSS: createSnapshotCmd starts:1407663611212 2014-08-10 02:40:11,292 DEBUG [o.a.c.s.d.d.CloudStackPrimaryDataStoreDriverImpl] (Job-Executor-76:ctx-6ce5578c ctx-5bb45501) Failed to take snapshot: 2063 java.lang.NullPointerException at org.apache.cloudstack.storage.snapshot.SnapshotObject.getId(SnapshotObject.java:149) at org.apache.cloudstack.storage.datastore.ObjectInDataStoreManagerImpl.findObject(ObjectInDataStoreManagerImpl.java:338) at org.apache.cloudstack.storage.snapshot.SnapshotObject.getPath(SnapshotObject.java:206) at org.apache.cloudstack.storage.to.SnapshotObjectTO.init(SnapshotObjectTO.java:60) at org.apache.cloudstack.storage.snapshot.SnapshotObject.getTO(SnapshotObject.java:274) at org.apache.cloudstack.storage.datastore.driver.CloudStackPrimaryDataStoreDriverImpl.takeSnapshot(CloudStackPrimaryDataStoreDriverImpl.java:258) at org.apache.cloudstack.storage.snapshot.SnapshotServiceImpl.takeSnapshot(SnapshotServiceImpl.java:204) at org.apache.cloudstack.storage.snapshot.XenserverSnapshotStrategy.takeSnapshot(XenserverSnapshotStrategy.java:285) at com.cloud.storage.snapshot.SnapshotManagerImpl.takeSnapshot(SnapshotManagerImpl.java:945) at sun.reflect.GeneratedMethodAccessor232.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:622) at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317) at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150) at org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172) at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204) at com.sun.proxy.$Proxy160.takeSnapshot(Unknown Source) at org.apache.cloudstack.storage.volume.VolumeServiceImpl.takeSnapshot(VolumeServiceImpl.java:1373) at com.cloud.storage.VolumeApiServiceImpl.orchestrateTakeVolumeSnapshot(VolumeApiServiceImpl.java:1783) at com.cloud.storage.VolumeApiServiceImpl.takeSnapshot(VolumeApiServiceImpl.java:1724) at sun.reflect.GeneratedMethodAccessor231.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:622) at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317) at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183) at
[jira] [Commented] (CLOUDSTACK-7947) Unable to take a snapshot of a volumes
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7947?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14251619#comment-14251619 ] ASF subversion and git services commented on CLOUDSTACK-7947: - Commit 0e312a7a779424519166d5bc2812672bbf7474a4 in cloudstack's branch refs/heads/4.4 from Edison Su [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=0e312a7 ] CLOUDSTACK-7301, CLOUDSTACK-7947: double check if parent snapshot is removed or not when creating new snapshot, check if parent snapshot is removed or not Reviewed-by: Min (cherry picked from commit bd799653293f9dc257ab68a3b04f6ea769e08e36) Signed-off-by: Rohit Yadav rohit.ya...@shapeblue.com Conflicts: engine/storage/snapshot/src/org/apache/cloudstack/storage/snapshot/XenserverSnapshotStrategy.java (cherry picked from commit ebf9897293a826d068b57c49c273bf4b9fd7f72e) Signed-off-by: Rohit Yadav rohit.ya...@shapeblue.com Conflicts: engine/storage/snapshot/src/org/apache/cloudstack/storage/snapshot/XenserverSnapshotStrategy.java Unable to take a snapshot of a volumes -- Key: CLOUDSTACK-7947 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7947 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Storage Controller Reporter: edison su Assignee: edison su Priority: Critical Fix For: 4.5.0 2014-08-14 10:31:49,926 DEBUG [o.a.c.s.d.d.CloudStackPrimaryDataStoreDriverImpl] (Work-Job-Executor-127:ctx-89498f92 job-18945/job-18946 ctx-1fd165da) Failed to take snapshot: 1582 java.lang.NullPointerException at org.apache.cloudstack.storage.snapshot.SnapshotObject.getId(SnapshotObject.java:149) at org.apache.cloudstack.storage.datastore.ObjectInDataStoreManagerImpl.findObject(ObjectInDataStoreManagerImpl.java:338) at org.apache.cloudstack.storage.snapshot.SnapshotObject.getPath(SnapshotObject.java:206) at org.apache.cloudstack.storage.to.SnapshotObjectTO.init(SnapshotObjectTO.java:60) at org.apache.cloudstack.storage.snapshot.SnapshotObject.getTO(SnapshotObject.java:274) at org.apache.cloudstack.storage.datastore.driver.CloudStackPrimaryDataStoreDriverImpl.takeSnapshot(CloudStackPrimaryDataStoreDriverImpl.java:258) at org.apache.cloudstack.storage.snapshot.SnapshotServiceImpl.takeSnapshot(SnapshotServiceImpl.java:204) at org.apache.cloudstack.storage.snapshot.XenserverSnapshotStrategy.takeSnapshot(XenserverSnapshotStrategy.java:291) at com.cloud.storage.snapshot.SnapshotManagerImpl.takeSnapshot(SnapshotManagerImpl.java:946) at sun.reflect.GeneratedMethodAccessor412.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317) at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150) at org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172) at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204) at com.sun.proxy.$Proxy160.takeSnapshot(Unknown Source) at org.apache.cloudstack.storage.volume.VolumeServiceImpl.takeSnapshot(VolumeServiceImpl.java:1387) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7184) HA should wait for at least 'xen.heartbeat.interval' sec before starting HA on vm's when host is marked down
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14251651#comment-14251651 ] ASF subversion and git services commented on CLOUDSTACK-7184: - Commit 67a7f74be0db6f2d505c9ba1ade7782238e1962a in cloudstack's branch refs/heads/4.5 from [~dahn] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=67a7f74 ] CLOUDSTACK-7184 fieldname typo HA should wait for at least 'xen.heartbeat.interval' sec before starting HA on vm's when host is marked down Key: CLOUDSTACK-7184 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7184 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Hypervisor Controller, Management Server, XenServer Affects Versions: 4.3.0, 4.4.0, 4.5.0 Environment: CloudStack 4.3 with XenServer 6.2 hypervisors Reporter: Remi Bergsma Assignee: Daan Hoogland Priority: Blocker Hypervisor got isolated for 30 seconds due to a network issue. CloudStack did discover this and marked the host as down, and immediately started HA. Just 18 seconds later the hypervisor returned and we ended up with 5 vm's that were running on two hypervisors at the same time. This, of course, resulted in file system corruption and the loss of the vm's. One side of the story is why XenServer allowed this to happen (will not bother you with this one). The CloudStack side of the story: HA should only start after at least xen.heartbeat.interval seconds. If the host is down long enough, the Xen heartbeat script will fence the hypervisor and prevent corruption. If it is not down long enough, nothing should happen. Logs (short): 2014-07-25 05:03:28,596 WARN [c.c.a.m.DirectAgentAttache] (DirectAgent-122:ctx-690badc5) Unable to get current status on 505(mccpvmXX) . 2014-07-25 05:03:31,920 ERROR [c.c.a.m.AgentManagerImpl] (AgentTaskPool-10:ctx-11b9af3e) Host is down: 505-mccpvmXX. Starting HA on the VMs . 2014-07-25 05:03:49,655 DEBUG [c.c.h.Status] (ClusteredAgentManager Timer:ctx-0e00979c) Transition:[Resource state = Enabled, Agent event = AgentDisconnected, Host id = 505, name = mccpvmXX] cs marks host down: 2014-07-25 05:03:31,920 cs marks host up: 2014-07-25 05:03:49,655 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7184) HA should wait for at least 'xen.heartbeat.interval' sec before starting HA on vm's when host is marked down
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14251652#comment-14251652 ] ASF subversion and git services commented on CLOUDSTACK-7184: - Commit 67a7f74be0db6f2d505c9ba1ade7782238e1962a in cloudstack's branch refs/heads/master from [~dahn] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=67a7f74 ] CLOUDSTACK-7184 fieldname typo HA should wait for at least 'xen.heartbeat.interval' sec before starting HA on vm's when host is marked down Key: CLOUDSTACK-7184 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7184 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Hypervisor Controller, Management Server, XenServer Affects Versions: 4.3.0, 4.4.0, 4.5.0 Environment: CloudStack 4.3 with XenServer 6.2 hypervisors Reporter: Remi Bergsma Assignee: Daan Hoogland Priority: Blocker Hypervisor got isolated for 30 seconds due to a network issue. CloudStack did discover this and marked the host as down, and immediately started HA. Just 18 seconds later the hypervisor returned and we ended up with 5 vm's that were running on two hypervisors at the same time. This, of course, resulted in file system corruption and the loss of the vm's. One side of the story is why XenServer allowed this to happen (will not bother you with this one). The CloudStack side of the story: HA should only start after at least xen.heartbeat.interval seconds. If the host is down long enough, the Xen heartbeat script will fence the hypervisor and prevent corruption. If it is not down long enough, nothing should happen. Logs (short): 2014-07-25 05:03:28,596 WARN [c.c.a.m.DirectAgentAttache] (DirectAgent-122:ctx-690badc5) Unable to get current status on 505(mccpvmXX) . 2014-07-25 05:03:31,920 ERROR [c.c.a.m.AgentManagerImpl] (AgentTaskPool-10:ctx-11b9af3e) Host is down: 505-mccpvmXX. Starting HA on the VMs . 2014-07-25 05:03:49,655 DEBUG [c.c.h.Status] (ClusteredAgentManager Timer:ctx-0e00979c) Transition:[Resource state = Enabled, Agent event = AgentDisconnected, Host id = 505, name = mccpvmXX] cs marks host down: 2014-07-25 05:03:31,920 cs marks host up: 2014-07-25 05:03:49,655 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-8092) Unable to start instance due to failed to configure ip alias on the router as a part of dhcp config
Tom created CLOUDSTACK-8092:
---
Summary: Unable to start instance due to failed to configure ip
alias on the router as a part of dhcp config
Key: CLOUDSTACK-8092
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8092
Project: CloudStack
Issue Type: Bug
Security Level: Public (Anyone can view this level - this is the default.)
Components: KVM, Management Server
Affects Versions: 4.4.1
Reporter: Tom
I have a guest network that I recently added an additional IP range on a
different subnet to. When I try to deploy a VM while specifying an IP in that
new IP range it fails to deploy with the following error:
2014-12-17 15:42:23,598 ERROR [c.c.a.ApiAsyncJobDispatcher]
(API-Job-Executor-103:ctx-b660e3e5 job-3004) Unexpected exception while
executing org.apache.cloudstack.api.command.user.vm.DeployVMCmd
java.lang.RuntimeException: Job failed due to exception Resource [Host:19] is
unreachable: Host 19: Unable to start instance due to failed to configure ip
alias on the router as a part of dhcp config
at com.cloud.vm.VmWorkJobDispatcher.runJob(VmWorkJobDispatcher.java:114)
at
org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:503)
at
org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49)
at
org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
at
org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
at
org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
at
org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46)
at
org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.run(AsyncJobManagerImpl.java:460)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
2014-12-17 15:42:23,599 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(API-Job-Executor-103:ctx-b660e3e5 job-3004) Complete async job-3004,
jobStatus: FAILED, resultCode: 530, result:
org.apache.cloudstack.api.response.ExceptionResponse/
null/{uuidList:[],errorcode:530,errortext:Job failed due to exception
Resource [Host:19] is unreachable: Host 19: Unable to start instance due to
failed to configure ip alias on the router as a part of dhcp config}
This looks very similar to CLOUDSTACK-3871, but if I'm reading the fix
correctly it only applied to XenServer.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-8093) Not able to list shared templates by passing id.
Min Chen created CLOUDSTACK-8093:
Summary: Not able to list shared templates by passing id.
Key: CLOUDSTACK-8093
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8093
Project: CloudStack
Issue Type: Bug
Security Level: Public (Anyone can view this level - this is the default.)
Components: IAM
Affects Versions: 4.4.0
Reporter: Min Chen
Assignee: Min Chen
Priority: Critical
Fix For: 4.5.0
Steps to reproduce the problem:
Create user test and testa under ROOT domain.
Register a private template T1 as user test.
Update Template permission to ass user testa for this template - T1.
As testa , list the details of this template by passing its Id:
This action is not permitted:
http://localhost:8080/client/api?command=listTemplatesresponse=jsonsessionkey=qVqJ8mbFV8EsjE9vKoCydIaP0BM%3Dtemplatefilter=selfid=cb0dd33f-3a0d-49fb-bf1f-0b6c15ad1455_=1418851061799
{ listtemplatesresponse :
{uuidList:[],errorcode:531,cserrorcode:4365,errortext:Acct[bdee8701-0495-4140-8823-25d56723082d-test-b]
does not have permission to operate with resource
Acct[cc0f203d-4018-470e-85f8-44105a7d182e-test-a]}
}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8093) Not able to list shared templates by passing id.
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14251989#comment-14251989
]
ASF subversion and git services commented on CLOUDSTACK-8093:
-
Commit d304409c98c87e9fb8a4e712cd7f9110c91bd1fa in cloudstack's branch
refs/heads/master from [~minchen07]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=d304409 ]
CLOUDSTACK-8093:Not able to list shared templates by passing id.
Not able to list shared templates by passing id.
Key: CLOUDSTACK-8093
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8093
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: IAM
Affects Versions: 4.4.0
Reporter: Min Chen
Assignee: Min Chen
Priority: Critical
Fix For: 4.5.0
Steps to reproduce the problem:
Create user test and testa under ROOT domain.
Register a private template T1 as user test.
Update Template permission to ass user testa for this template - T1.
As testa , list the details of this template by passing its Id:
This action is not permitted:
http://localhost:8080/client/api?command=listTemplatesresponse=jsonsessionkey=qVqJ8mbFV8EsjE9vKoCydIaP0BM%3Dtemplatefilter=selfid=cb0dd33f-3a0d-49fb-bf1f-0b6c15ad1455_=1418851061799
{ listtemplatesresponse :
{uuidList:[],errorcode:531,cserrorcode:4365,errortext:Acct[bdee8701-0495-4140-8823-25d56723082d-test-b]
does not have permission to operate with resource
Acct[cc0f203d-4018-470e-85f8-44105a7d182e-test-a]}
}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8093) Not able to list shared templates by passing id.
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14252033#comment-14252033
]
ASF subversion and git services commented on CLOUDSTACK-8093:
-
Commit 3506789b0b4d0da55f9713f19c1e0f41c16830ee in cloudstack's branch
refs/heads/4.5 from [~minchen07]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=3506789 ]
CLOUDSTACK-8093:Not able to list shared templates by passing id.
Not able to list shared templates by passing id.
Key: CLOUDSTACK-8093
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8093
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: IAM
Affects Versions: 4.4.0
Reporter: Min Chen
Assignee: Min Chen
Priority: Critical
Fix For: 4.5.0
Steps to reproduce the problem:
Create user test and testa under ROOT domain.
Register a private template T1 as user test.
Update Template permission to ass user testa for this template - T1.
As testa , list the details of this template by passing its Id:
This action is not permitted:
http://localhost:8080/client/api?command=listTemplatesresponse=jsonsessionkey=qVqJ8mbFV8EsjE9vKoCydIaP0BM%3Dtemplatefilter=selfid=cb0dd33f-3a0d-49fb-bf1f-0b6c15ad1455_=1418851061799
{ listtemplatesresponse :
{uuidList:[],errorcode:531,cserrorcode:4365,errortext:Acct[bdee8701-0495-4140-8823-25d56723082d-test-b]
does not have permission to operate with resource
Acct[cc0f203d-4018-470e-85f8-44105a7d182e-test-a]}
}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8093) Not able to list shared templates by passing id.
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14252035#comment-14252035
]
Min Chen commented on CLOUDSTACK-8093:
--
Fixed it by properly checking template permission when id is passed
Not able to list shared templates by passing id.
Key: CLOUDSTACK-8093
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8093
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: IAM
Affects Versions: 4.4.0
Reporter: Min Chen
Assignee: Min Chen
Priority: Critical
Fix For: 4.5.0
Steps to reproduce the problem:
Create user test and testa under ROOT domain.
Register a private template T1 as user test.
Update Template permission to ass user testa for this template - T1.
As testa , list the details of this template by passing its Id:
This action is not permitted:
http://localhost:8080/client/api?command=listTemplatesresponse=jsonsessionkey=qVqJ8mbFV8EsjE9vKoCydIaP0BM%3Dtemplatefilter=selfid=cb0dd33f-3a0d-49fb-bf1f-0b6c15ad1455_=1418851061799
{ listtemplatesresponse :
{uuidList:[],errorcode:531,cserrorcode:4365,errortext:Acct[bdee8701-0495-4140-8823-25d56723082d-test-b]
does not have permission to operate with resource
Acct[cc0f203d-4018-470e-85f8-44105a7d182e-test-a]}
}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-8093) Not able to list shared templates by passing id.
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8093?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Min Chen resolved CLOUDSTACK-8093.
--
Resolution: Fixed
Not able to list shared templates by passing id.
Key: CLOUDSTACK-8093
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8093
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: IAM
Affects Versions: 4.4.0
Reporter: Min Chen
Assignee: Min Chen
Priority: Critical
Fix For: 4.5.0
Steps to reproduce the problem:
Create user test and testa under ROOT domain.
Register a private template T1 as user test.
Update Template permission to ass user testa for this template - T1.
As testa , list the details of this template by passing its Id:
This action is not permitted:
http://localhost:8080/client/api?command=listTemplatesresponse=jsonsessionkey=qVqJ8mbFV8EsjE9vKoCydIaP0BM%3Dtemplatefilter=selfid=cb0dd33f-3a0d-49fb-bf1f-0b6c15ad1455_=1418851061799
{ listtemplatesresponse :
{uuidList:[],errorcode:531,cserrorcode:4365,errortext:Acct[bdee8701-0495-4140-8823-25d56723082d-test-b]
does not have permission to operate with resource
Acct[cc0f203d-4018-470e-85f8-44105a7d182e-test-a]}
}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-8094) Label Issue for Migrate Volume Option UI
Vania Xu created CLOUDSTACK-8094: Summary: Label Issue for Migrate Volume Option UI Key: CLOUDSTACK-8094 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8094 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: UI Affects Versions: 4.5.0 Reporter: Vania Xu Priority: Trivial Fix For: Future, 4.5.0 For Migrate Volume label in the UI, it shows label.migrate.volume.to.primary.storage. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-8094) Label Issue for Migrate Volume Option in UI
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8094?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vania Xu updated CLOUDSTACK-8094: - Summary: Label Issue for Migrate Volume Option in UI (was: Label Issue for Migrate Volume Option UI) Label Issue for Migrate Volume Option in UI --- Key: CLOUDSTACK-8094 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8094 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: UI Affects Versions: 4.5.0 Reporter: Vania Xu Priority: Trivial Labels: labels, ui Fix For: Future, 4.5.0 Original Estimate: 24h Remaining Estimate: 24h For Migrate Volume label in the UI, it shows label.migrate.volume.to.primary.storage. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8089) Fix component/test_explicit_dedication.py and move it to maint folder
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14252697#comment-14252697 ] ASF subversion and git services commented on CLOUDSTACK-8089: - Commit ad258cc8f5e2ef5d524aae761501cdc32e397fc4 in cloudstack's branch refs/heads/master from [~gauravaradhye] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=ad258cc ] CLOUDSTACK-8089: Fixed test_explicit_dedication.py test case and moved to maint folder for it is to be run separately Signed-off-by: pdion891 pdion...@apache.org Fix component/test_explicit_dedication.py and move it to maint folder - Key: CLOUDSTACK-8089 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8089 Project: CloudStack Issue Type: Test Security Level: Public(Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.5.0 Reporter: Gaurav Aradhye Assignee: Gaurav Aradhye Labels: automation Fix For: 4.5.0 The test suite needs to be run separately as it requires to have one host with no VM running. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8089) Fix component/test_explicit_dedication.py and move it to maint folder
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14252695#comment-14252695 ] ASF subversion and git services commented on CLOUDSTACK-8089: - Commit 27295d235d0db1eccb571b4f8ea010e9f1cf3c45 in cloudstack's branch refs/heads/4.5 from [~gauravaradhye] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=27295d2 ] CLOUDSTACK-8089: Fixed test_explicit_dedication.py test case and moved to maint folder for it is to be run separately Signed-off-by: pdion891 pdion...@apache.org Fix component/test_explicit_dedication.py and move it to maint folder - Key: CLOUDSTACK-8089 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8089 Project: CloudStack Issue Type: Test Security Level: Public(Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.5.0 Reporter: Gaurav Aradhye Assignee: Gaurav Aradhye Labels: automation Fix For: 4.5.0 The test suite needs to be run separately as it requires to have one host with no VM running. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-6744) UI zone wizard baremetal change it to support EIP ELB feature
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14252794#comment-14252794 ] ASF subversion and git services commented on CLOUDSTACK-6744: - Commit 65c742cd66e032c91a6e12e9eae4343c7f18965f in cloudstack's branch refs/heads/4.5 from [~jessicawang] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=65c742c ] CLOUDSTACK-6744 UI zone wizard baremetal hypervisor support EIP ELB feature. UI zone wizard baremetal change it to support EIP ELB feature --- Key: CLOUDSTACK-6744 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6744 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: UI Reporter: Jessica Wang Assignee: Jessica Wang -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-6744) UI zone wizard baremetal change it to support EIP ELB feature
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14252795#comment-14252795 ] ASF subversion and git services commented on CLOUDSTACK-6744: - Commit 923c65d7ce791e86d2e949a9d55bfc666bda1cfe in cloudstack's branch refs/heads/master from [~jessicawang] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=923c65d ] CLOUDSTACK-6744 UI zone wizard baremetal hypervisor support EIP ELB feature. UI zone wizard baremetal change it to support EIP ELB feature --- Key: CLOUDSTACK-6744 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6744 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: UI Reporter: Jessica Wang Assignee: Jessica Wang -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8084) [Automation] Fix test_add_remove_network.TestFailureScenariosAddNetworkToVM.test_17_add_nic_different_zone
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14252931#comment-14252931
]
ASF subversion and git services commented on CLOUDSTACK-8084:
-
Commit 3090e4a0301c4be50d0d46703b2d9fa070c2e91b in cloudstack's branch
refs/heads/master from [~gauravaradhye]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=3090e4a ]
CLOUDSTACK-8084: Fixed test_17_add_nic_different_zone in
test_add_remove_network.py
Signed-off-by: SrikanteswaraRao Talluri tall...@apache.org
[Automation] Fix
test_add_remove_network.TestFailureScenariosAddNetworkToVM.test_17_add_nic_different_zone
--
Key: CLOUDSTACK-8084
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8084
Project: CloudStack
Issue Type: Test
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Automation
Affects Versions: 4.5.0
Reporter: Gaurav Aradhye
Assignee: Gaurav Aradhye
Labels: automation
Fix For: 4.5.0
The test case failed in cleanup operation while deleting the network.
Error Message
Warning: Exception during cleanup : Job failed: {jobprocstatus : 0, created :
u'2014-12-15T22:24:53+', cmd :
u'org.apache.cloudstack.api.command.user.network.DeleteNetworkCmd', userid :
u'2f1ad6e2-848d-11e4-af34-8e4219cb0651', jobstatus : 2, jobid :
u'88e2de77-89c0-47de-bdb6-7b8d354a8ead', jobresultcode : 530, jobresulttype :
u'object', jobresult : {errorcode : 530, errortext : u'Failed to delete
network'}, accountid : u'2f1ac986-848d-11e4-af34-8e4219cb0651'}
Stacktrace
File /usr/lib/python2.7/unittest/case.py, line 361, in run
self.tearDown()
File
/root/cloudstack/test/integration/component/test_add_remove_network.py,
line 1184, in tearDown
raise Exception(Warning: Exception during cleanup : %s % e)
'Warning: Exception during cleanup : Job failed: {jobprocstatus : 0, created
: u\'2014-12-15T22:24:53+\', cmd :
u\'org.apache.cloudstack.api.command.user.network.DeleteNetworkCmd\', userid
: u\'2f1ad6e2-848d-11e4-af34-8e4219cb0651\', jobstatus : 2, jobid :
u\'88e2de77-89c0-47de-bdb6-7b8d354a8ead\', jobresultcode : 530, jobresulttype
: u\'object\', jobresult : {errorcode : 530, errortext : u\'Failed to delete
network\'}, accountid : u\'2f1ac986-848d-11e4-af34-8e4219cb0651\'}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8087) Fix component/maint/test_vpc_on_host_maintenance.py
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8087?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14252929#comment-14252929 ] ASF subversion and git services commented on CLOUDSTACK-8087: - Commit 162f61b73fa0e8faa981bc090df27fea8afc4c50 in cloudstack's branch refs/heads/master from [~ashutoshk] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=162f61b ] CLOUDSTACK-8087: Fixed test_vpc_on_host_maintenance.py Signed-off-by: SrikanteswaraRao Talluri tall...@apache.org Fix component/maint/test_vpc_on_host_maintenance.py --- Key: CLOUDSTACK-8087 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8087 Project: CloudStack Issue Type: Test Security Level: Public(Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.5.0 Reporter: Ashutosk Kelkar Assignee: Ashutosk Kelkar Labels: automation Fix For: 4.5.0 The test case fails while creating VPC when the hosts are in maintenance state. The VPC should be created with start parameter as False in this case. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8086) [Automation][Simulator] Simulator needs a Portable IP Range to execute PortableIP Test Cases
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8086?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14252930#comment-14252930 ] ASF subversion and git services commented on CLOUDSTACK-8086: - Commit 696698090eb2ea548bfc74b802ba7dd01a584b91 in cloudstack's branch refs/heads/master from [~chandanp] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=6966980 ] CLOUDSTACK-8086: Simulator needs a Portable IP Range to execute Portable IP Test Cases Signed-off-by: SrikanteswaraRao Talluri tall...@apache.org [Automation][Simulator] Simulator needs a Portable IP Range to execute PortableIP Test Cases Key: CLOUDSTACK-8086 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8086 Project: CloudStack Issue Type: Test Security Level: Public(Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.5.0 Reporter: Chandan Purushothama Assignee: Chandan Purushothama Priority: Critical Fix For: 4.5.0 Currently test cases are failing in Simulator, since the portable IP Range dictionary is empty in testdata.py. Fake IP Range information needs to be provided so that the test cases can be run without any issues. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8090) Move test_dedicated_vlan_range.py to maint folder - test cases need to be run separately
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8090?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14252928#comment-14252928 ] ASF subversion and git services commented on CLOUDSTACK-8090: - Commit 95b558414f0808d63920a2906f484fd6b15a4713 in cloudstack's branch refs/heads/master from [~gauravaradhye] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=95b5584 ] CLOUDSTACK-8090: Moving test_dedicated_guest_vlan_ranges.py to maint folder for the test cases need to be run separately, serially Signed-off-by: SrikanteswaraRao Talluri tall...@apache.org Move test_dedicated_vlan_range.py to maint folder - test cases need to be run separately Key: CLOUDSTACK-8090 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8090 Project: CloudStack Issue Type: Test Security Level: Public(Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.5.0 Reporter: Gaurav Aradhye Assignee: Gaurav Aradhye Labels: automation Fix For: 4.5.0 The test cases need to be run separately as they create vlan ranges, and dedicated them to an account/project. In between the vlans should not get consumed by other account. Else test cases will fail like following Execute cmd: dedicateguestvlanrange failed, due to: errorCode: 431, errorText:Guest vlan from this range 3390 is allocated to a different account. Can only dedicate a range which has no allocated vlans or has vlans allocated to the same account -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8087) Fix component/maint/test_vpc_on_host_maintenance.py
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8087?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14252947#comment-14252947 ] ASF subversion and git services commented on CLOUDSTACK-8087: - Commit 6c722c9d219ae3bedad12a28105800b096eeb147 in cloudstack's branch refs/heads/4.5 from [~ashutoshk] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=6c722c9 ] CLOUDSTACK-8087: Fixed test_vpc_on_host_maintenance.py Signed-off-by: SrikanteswaraRao Talluri tall...@apache.org Fix component/maint/test_vpc_on_host_maintenance.py --- Key: CLOUDSTACK-8087 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8087 Project: CloudStack Issue Type: Test Security Level: Public(Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.5.0 Reporter: Ashutosk Kelkar Assignee: Ashutosk Kelkar Labels: automation Fix For: 4.5.0 The test case fails while creating VPC when the hosts are in maintenance state. The VPC should be created with start parameter as False in this case. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8090) Move test_dedicated_vlan_range.py to maint folder - test cases need to be run separately
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8090?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14252944#comment-14252944 ] ASF subversion and git services commented on CLOUDSTACK-8090: - Commit d88126988b04bb8a58fb70e195722b01b45f05dc in cloudstack's branch refs/heads/4.5 from [~gauravaradhye] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=d881269 ] CLOUDSTACK-8090: Moving test_dedicated_guest_vlan_ranges.py to maint folder for the test cases need to be run separately, serially Signed-off-by: SrikanteswaraRao Talluri tall...@apache.org Move test_dedicated_vlan_range.py to maint folder - test cases need to be run separately Key: CLOUDSTACK-8090 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8090 Project: CloudStack Issue Type: Test Security Level: Public(Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.5.0 Reporter: Gaurav Aradhye Assignee: Gaurav Aradhye Labels: automation Fix For: 4.5.0 The test cases need to be run separately as they create vlan ranges, and dedicated them to an account/project. In between the vlans should not get consumed by other account. Else test cases will fail like following Execute cmd: dedicateguestvlanrange failed, due to: errorCode: 431, errorText:Guest vlan from this range 3390 is allocated to a different account. Can only dedicate a range which has no allocated vlans or has vlans allocated to the same account -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8086) [Automation][Simulator] Simulator needs a Portable IP Range to execute PortableIP Test Cases
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8086?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14252945#comment-14252945 ] ASF subversion and git services commented on CLOUDSTACK-8086: - Commit f2c7ead8ee68de963a97eae9dc78bf524565691e in cloudstack's branch refs/heads/4.5 from [~chandanp] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=f2c7ead ] CLOUDSTACK-8086: Simulator needs a Portable IP Range to execute Portable IP Test Cases Signed-off-by: SrikanteswaraRao Talluri tall...@apache.org [Automation][Simulator] Simulator needs a Portable IP Range to execute PortableIP Test Cases Key: CLOUDSTACK-8086 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8086 Project: CloudStack Issue Type: Test Security Level: Public(Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.5.0 Reporter: Chandan Purushothama Assignee: Chandan Purushothama Priority: Critical Fix For: 4.5.0 Currently test cases are failing in Simulator, since the portable IP Range dictionary is empty in testdata.py. Fake IP Range information needs to be provided so that the test cases can be run without any issues. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8084) [Automation] Fix test_add_remove_network.TestFailureScenariosAddNetworkToVM.test_17_add_nic_different_zone
[
https://issues.apache.org/jira/browse/CLOUDSTACK-8084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14252946#comment-14252946
]
ASF subversion and git services commented on CLOUDSTACK-8084:
-
Commit 0db63d87aa40de7493a6bc66b7686cf8922bc742 in cloudstack's branch
refs/heads/4.5 from [~gauravaradhye]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=0db63d8 ]
CLOUDSTACK-8084: Fixed test_17_add_nic_different_zone in
test_add_remove_network.py
Signed-off-by: SrikanteswaraRao Talluri tall...@apache.org
[Automation] Fix
test_add_remove_network.TestFailureScenariosAddNetworkToVM.test_17_add_nic_different_zone
--
Key: CLOUDSTACK-8084
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8084
Project: CloudStack
Issue Type: Test
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Automation
Affects Versions: 4.5.0
Reporter: Gaurav Aradhye
Assignee: Gaurav Aradhye
Labels: automation
Fix For: 4.5.0
The test case failed in cleanup operation while deleting the network.
Error Message
Warning: Exception during cleanup : Job failed: {jobprocstatus : 0, created :
u'2014-12-15T22:24:53+', cmd :
u'org.apache.cloudstack.api.command.user.network.DeleteNetworkCmd', userid :
u'2f1ad6e2-848d-11e4-af34-8e4219cb0651', jobstatus : 2, jobid :
u'88e2de77-89c0-47de-bdb6-7b8d354a8ead', jobresultcode : 530, jobresulttype :
u'object', jobresult : {errorcode : 530, errortext : u'Failed to delete
network'}, accountid : u'2f1ac986-848d-11e4-af34-8e4219cb0651'}
Stacktrace
File /usr/lib/python2.7/unittest/case.py, line 361, in run
self.tearDown()
File
/root/cloudstack/test/integration/component/test_add_remove_network.py,
line 1184, in tearDown
raise Exception(Warning: Exception during cleanup : %s % e)
'Warning: Exception during cleanup : Job failed: {jobprocstatus : 0, created
: u\'2014-12-15T22:24:53+\', cmd :
u\'org.apache.cloudstack.api.command.user.network.DeleteNetworkCmd\', userid
: u\'2f1ad6e2-848d-11e4-af34-8e4219cb0651\', jobstatus : 2, jobid :
u\'88e2de77-89c0-47de-bdb6-7b8d354a8ead\', jobresultcode : 530, jobresulttype
: u\'object\', jobresult : {errorcode : 530, errortext : u\'Failed to delete
network\'}, accountid : u\'2f1ac986-848d-11e4-af34-8e4219cb0651\'}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-8095) .component.test_escalations_instances.TestInstances.test_13_attach_detach_iso Fails while attaching Iso
Ashutosk Kelkar created CLOUDSTACK-8095:
---
Summary:
.component.test_escalations_instances.TestInstances.test_13_attach_detach_iso
Fails while attaching Iso
Key: CLOUDSTACK-8095
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8095
Project: CloudStack
Issue Type: Test
Security Level: Public (Anyone can view this level - this is the default.)
Components: Automation
Affects Versions: 4.5.0
Environment: Xen and Vmware
Reporter: Ashutosk Kelkar
Assignee: Ashutosk Kelkar
Fix For: 4.5.0
It fails with below error:
Error Message
Job failed: {jobprocstatus : 0, created : u'2014-12-17T07:06:31+', cmd :
u'org.apache.cloudstack.api.command.user.iso.AttachIsoCmd', userid :
u'df904517-e7fd-401b-80b4-978bb05c0e13', jobstatus : 2, jobid :
u'c07c3da0-e816-4577-b1ad-c616b51aeeb7', jobresultcode : 530, jobresulttype :
u'object', jobresult : {errorcode : 431, errortext : u'Cannot attach Xenserver
PV drivers to incompatible hypervisor VMware'}, accountid :
u'5c0feab3-f7a2-41e6-8898-78e0866f1af4'}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-8094) Label Issue for Migrate Volume Option in UI
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14253119#comment-14253119 ] Wei Zhou commented on CLOUDSTACK-8094: -- this issue does not exist in my testing. Could you create and upload a screen snapshot ? Label Issue for Migrate Volume Option in UI --- Key: CLOUDSTACK-8094 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8094 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: UI Affects Versions: 4.5.0 Reporter: Vania Xu Priority: Trivial Labels: labels, ui Fix For: Future, 4.5.0 Original Estimate: 24h Remaining Estimate: 24h For Migrate Volume label in the UI, it shows label.migrate.volume.to.primary.storage. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
