[jira] [Resolved] (CLOUDSTACK-7727) [Automation] [LXC] Various BVT test issues with LXC
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7727?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Brett resolved CLOUDSTACK-7727. Resolution: Fixed [Automation] [LXC] Various BVT test issues with LXC --- Key: CLOUDSTACK-7727 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7727 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.5.0 Reporter: Alex Brett Assignee: Alex Brett Fix For: 4.5.0 Various tests should skip when running with LXC due to the limitations it imposes. The limitations list from https://cwiki.apache.org/confluence/display/CLOUDSTACK/LXC+Enhancements is: * No Console access * No Live migration * No migration across clusters * No snapshot support * No upload/download volume support * No template creation from ROOT volume * No ISO support for create Vm This ticket is to modify the BVT tests to skip where appropriate. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7753) [Automation] [HyperV] TestServiceOfferings.test_04_change_offering_small detecting memory incorrectly
Alex Brett created CLOUDSTACK-7753: -- Summary: [Automation] [HyperV] TestServiceOfferings.test_04_change_offering_small detecting memory incorrectly Key: CLOUDSTACK-7753 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7753 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.5.0 Reporter: Alex Brett Assignee: Devdeep Singh Priority: Critical Fix For: 4.5.0 Deployed VM has the following memory configuration on the VM: [root@Atoms-VM-2 ~]# cat /proc/meminfo | grep Mem MemTotal: 363416 kB MemFree: 81864 kB [root@Atoms-VM-2 ~]# Which is around 354.8984375 MB But the Service Offering specified specifies 512 MB as shown below: mysql select id,name,instance_name,state,service_offering_id from vm_instance where id=59 \G id: 59 name: Atoms-VM-2 instance_name: i-36-59-VM state: Running service_offering_id: 1 1 row in set (0.00 sec) mysql select * from service_offering where id=1 \G id: 1 cpu: 1 speed: 500 ram_size: 512 nw_rate: NULL mc_rate: NULL ha_enabled: 0 limit_cpu_use: 0 host_tag: NULL default_use: 0 vm_type: NULL sort_key: 0 is_volatile: 0 deployment_planner: NULL 1 row in set (0.00 sec) mysql -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7753) [Automation] [HyperV] TestServiceOfferings.test_04_change_offering_small detecting memory incorrectly
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14176984#comment-14176984 ] Alex Brett commented on CLOUDSTACK-7753: integration.smoke.test_service_offerings.TestServiceOfferings.test_04_change_offering_small is currently failing on HyperV, the bug CLOUDSTACK-7737 was raised from this, however it was determined that cloudstack is doing the right thing, as such we need to fix the Marvin test instead... [Automation] [HyperV] TestServiceOfferings.test_04_change_offering_small detecting memory incorrectly - Key: CLOUDSTACK-7753 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7753 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.5.0 Reporter: Alex Brett Assignee: Alex Brett Priority: Critical Fix For: 4.5.0 Deployed VM has the following memory configuration on the VM: [root@Atoms-VM-2 ~]# cat /proc/meminfo | grep Mem MemTotal: 363416 kB MemFree: 81864 kB [root@Atoms-VM-2 ~]# Which is around 354.8984375 MB But the Service Offering specified specifies 512 MB as shown below: mysql select id,name,instance_name,state,service_offering_id from vm_instance where id=59 \G id: 59 name: Atoms-VM-2 instance_name: i-36-59-VM state: Running service_offering_id: 1 1 row in set (0.00 sec) mysql select * from service_offering where id=1 \G id: 1 cpu: 1 speed: 500 ram_size: 512 nw_rate: NULL mc_rate: NULL ha_enabled: 0 limit_cpu_use: 0 host_tag: NULL default_use: 0 vm_type: NULL sort_key: 0 is_volatile: 0 deployment_planner: NULL 1 row in set (0.00 sec) mysql -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CLOUDSTACK-7753) [Automation] [HyperV] TestServiceOfferings.test_04_change_offering_small detecting memory incorrectly
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7753?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Brett reassigned CLOUDSTACK-7753: -- Assignee: Chandan Purushothama (was: Alex Brett) [~chandanp] are you able to look at this, if not I might have some time in the next couple of weeks? [Automation] [HyperV] TestServiceOfferings.test_04_change_offering_small detecting memory incorrectly - Key: CLOUDSTACK-7753 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7753 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.5.0 Reporter: Alex Brett Assignee: Chandan Purushothama Priority: Critical Fix For: 4.5.0 Deployed VM has the following memory configuration on the VM: [root@Atoms-VM-2 ~]# cat /proc/meminfo | grep Mem MemTotal: 363416 kB MemFree: 81864 kB [root@Atoms-VM-2 ~]# Which is around 354.8984375 MB But the Service Offering specified specifies 512 MB as shown below: mysql select id,name,instance_name,state,service_offering_id from vm_instance where id=59 \G id: 59 name: Atoms-VM-2 instance_name: i-36-59-VM state: Running service_offering_id: 1 1 row in set (0.00 sec) mysql select * from service_offering where id=1 \G id: 1 cpu: 1 speed: 500 ram_size: 512 nw_rate: NULL mc_rate: NULL ha_enabled: 0 limit_cpu_use: 0 host_tag: NULL default_use: 0 vm_type: NULL sort_key: 0 is_volatile: 0 deployment_planner: NULL 1 row in set (0.00 sec) mysql -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7727) [Automation] [LXC] Various BVT test issues with LXC
Alex Brett created CLOUDSTACK-7727: -- Summary: [Automation] [LXC] Various BVT test issues with LXC Key: CLOUDSTACK-7727 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7727 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.5.0 Reporter: Alex Brett Assignee: Alex Brett Fix For: 4.5.0 Various tests should skip when running with LXC due to the limitations it imposes. The limitations list from https://cwiki.apache.org/confluence/display/CLOUDSTACK/LXC+Enhancements is: * No Console access * No Live migration * No migration across clusters * No snapshot support * No upload/download volume support * No template creation from ROOT volume * No ISO support for create Vm This ticket is to modify the BVT tests to skip where appropriate. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-7673) [Automation] integration.smoke.test_ssvm.TestSSVMs tests only comparing first gateway found
Alex Brett created CLOUDSTACK-7673: -- Summary: [Automation] integration.smoke.test_ssvm.TestSSVMs tests only comparing first gateway found Key: CLOUDSTACK-7673 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7673 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.5.0 Reporter: Alex Brett Assignee: Alex Brett Fix For: 4.5.0 When running with an EIP zone, the API listVlanRanges gives two gateways back. integration.smoke.test_ssvm.TestSSVMs assumes however that there is only one, and so just picks the first. Unfortunately in EIP it seems the 'correct' one for the SSVM is the second, so the test fails. The test should therefore be modified to check if the SSVM gateway matches one of the IPs from listVlanRanges. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7673) [Automation] integration.smoke.test_ssvm.TestSSVMs tests only comparing first gateway found
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7673?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14160407#comment-14160407 ] Alex Brett commented on CLOUDSTACK-7673: Review requested posted at https://reviews.apache.org/r/26364/ [Automation] integration.smoke.test_ssvm.TestSSVMs tests only comparing first gateway found --- Key: CLOUDSTACK-7673 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7673 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.5.0 Reporter: Alex Brett Assignee: Alex Brett Fix For: 4.5.0 When running with an EIP zone, the API listVlanRanges gives two gateways back. integration.smoke.test_ssvm.TestSSVMs assumes however that there is only one, and so just picks the first. Unfortunately in EIP it seems the 'correct' one for the SSVM is the second, so the test fails. The test should therefore be modified to check if the SSVM gateway matches one of the IPs from listVlanRanges. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7621) Database schema not getting upgraded
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14146070#comment-14146070 ] Alex Brett commented on CLOUDSTACK-7621: Looking at the history, I see the following two schema changes between a working build and a broken one: https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=commit;h=872b48b0c34d85d934344c8ccf33fa328d2748ed https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=commit;h=b3c117a11eda3373a5a7187547a441be908f4453 [~pdion] could this be a side effect of these? Database schema not getting upgraded Key: CLOUDSTACK-7621 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7621 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.5.0 Reporter: Pavan Kumar Bandarupally Priority: Blocker Fix For: 4.5.0 Attachments: management-server.log After installing management server , the process is stuck at database schema update. The update doesn't progress ahead from 4.0.0 mysql select * from version; ++-+-+--+ | id | version | updated | step | ++-+-+--+ | 1 | 4.0.0 | 2014-09-24 12:14:11 | Complete | ++-+-+--+ 1 row in set (0.00 sec) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7621) Database schema not getting upgraded
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14146076#comment-14146076
]
Alex Brett commented on CLOUDSTACK-7621:
Also from localhost log on another run:
{noformat}
SEVERE: Exception sending context initialized event to listener instance of
class org.apache.cloudstack.spring.module.web.CloudStackContextLoaderListener
org.springframework.context.ApplicationContextException: Failed to start bean
'cloudStackLifeCycle'; nested exception is
com.cloud.utils.exception.CloudRuntimeException: Caught: null
at
org.springframework.context.support.DefaultLifecycleProcessor.doStart(DefaultLifecycleProcessor.java:170)
at
org.springframework.context.support.DefaultLifecycleProcessor.access$200(DefaultLifecycleProcessor.java:51)
at
org.springframework.context.support.DefaultLifecycleProcessor$LifecycleGroup.start(DefaultLifecycleProcessor.java:339)
at
org.springframework.context.support.DefaultLifecycleProcessor.startBeans(DefaultLifecycleProcessor.java:143)
at
org.springframework.context.support.DefaultLifecycleProcessor.onRefresh(DefaultLifecycleProcessor.java:108)
at
org.springframework.context.support.AbstractApplicationContext.finishRefresh(AbstractApplicationContext.java:945)
at
org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:482)
at
org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet.loadContext(DefaultModuleDefinitionSet.java:145)
at
org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet$2.with(DefaultModuleDefinitionSet.java:122)
at
org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet.withModule(DefaultModuleDefinitionSet.java:245)
at
org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet.withModule(DefaultModuleDefinitionSet.java:250)
at
org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet.withModule(DefaultModuleDefinitionSet.java:233)
at
org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet.loadContexts(DefaultModuleDefinitionSet.java:117)
at
org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet.load(DefaultModuleDefinitionSet.java:79)
at
org.apache.cloudstack.spring.module.factory.ModuleBasedContextFactory.loadModules(ModuleBasedContextFactory.java:37)
at
org.apache.cloudstack.spring.module.factory.CloudStackSpringContext.init(CloudStackSpringContext.java:70)
at
org.apache.cloudstack.spring.module.factory.CloudStackSpringContext.init(CloudStackSpringContext.java:57)
at
org.apache.cloudstack.spring.module.factory.CloudStackSpringContext.init(CloudStackSpringContext.java:61)
at
org.apache.cloudstack.spring.module.web.CloudStackContextLoaderListener.contextInitialized(CloudStackContextLoaderListener.java:52)
at
org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:3972)
at
org.apache.catalina.core.StandardContext.start(StandardContext.java:4467)
at
org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:791)
at
org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:771)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:526)
at
org.apache.catalina.startup.HostConfig.deployDirectory(HostConfig.java:1041)
at
org.apache.catalina.startup.HostConfig.deployDirectories(HostConfig.java:964)
at
org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:502)
at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1277)
at
org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:321)
at
org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1053)
at org.apache.catalina.core.StandardHost.start(StandardHost.java:722)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1045)
at
org.apache.catalina.core.StandardEngine.start(StandardEngine.java:443)
at
org.apache.catalina.core.StandardService.start(StandardService.java:516)
at
org.apache.catalina.core.StandardServer.start(StandardServer.java:710)
at org.apache.catalina.startup.Catalina.start(Catalina.java:593)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:289)
at
[jira] [Resolved] (CLOUDSTACK-7621) Database schema not getting upgraded
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Brett resolved CLOUDSTACK-7621. Resolution: Fixed Appears to be fixed by https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=commit;h=2503aaafef5280ce20e319c77623f9709d85151a which reverted [~anthonyxu]'s commit https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=commit;h=093fa6f0a53bd031a09e4042c3aa25860bc947e5 Looks to be just a coincidence that some schema changes came in at the same time - apologies for any confusion... Database schema not getting upgraded Key: CLOUDSTACK-7621 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7621 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.5.0 Reporter: Pavan Kumar Bandarupally Priority: Blocker Fix For: 4.5.0 Attachments: localhost.2014-09-24.log, management-server.log After installing management server , the process is stuck at database schema update. The update doesn't progress ahead from 4.0.0 mysql select * from version; ++-+-+--+ | id | version | updated | step | ++-+-+--+ | 1 | 4.0.0 | 2014-09-24 12:14:11 | Complete | ++-+-+--+ 1 row in set (0.00 sec) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7623) SystemVMs not starting
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7623?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Brett updated CLOUDSTACK-7623: --- Summary: SystemVMs not starting (was: SystemVMs not getting created on VmWare) SystemVMs not starting -- Key: CLOUDSTACK-7623 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7623 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: SystemVM Affects Versions: 4.5.0 Reporter: Pavan Kumar Bandarupally Priority: Blocker Fix For: 4.5.0 Attachments: management-server.log After installing latest Management Server and zone creation, system VMs are not getting created. The following exception is being generated: 2014-09-24 17:37:17,918 WARN [c.c.u.d.Merovingian2] (consoleproxy-1:ctx-bc88696c) Timed out on acquiring lock vm_instance1 . Waited for 0seconds 2014-09-24 17:37:17,919 WARN [c.c.c.ConsoleProxyManagerImpl] (consoleproxy-1:ctx-bc88696c) Runtime Exception while trying to start console proxy com.cloud.utils.exception.CloudRuntimeException: Timed out on acquiring lock vm_instance1 . Waited for 0seconds at com.cloud.utils.db.Merovingian2.acquire(Merovingian2.java:143) at com.cloud.utils.db.TransactionLegacy.lock(TransactionLegacy.java:389) at com.cloud.utils.db.GenericDaoBase.lockInLockTable(GenericDaoBase.java:1057) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) 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 com.cloud.utils.db.TransactionContextInterceptor.invoke(TransactionContextInterceptor.java:34) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161) 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 $Proxy53.lockInLockTable(Unknown Source) at com.cloud.vm.VirtualMachineManagerImpl$3.doInTransaction(VirtualMachineManagerImpl.java:3927) at com.cloud.vm.VirtualMachineManagerImpl$3.doInTransaction(VirtualMachineManagerImpl.java:3922) at com.cloud.utils.db.Transaction$2.doInTransaction(Transaction.java:49) at com.cloud.utils.db.Transaction.execute(Transaction.java:37) at com.cloud.utils.db.Transaction.execute(Transaction.java:46) at com.cloud.vm.VirtualMachineManagerImpl.startVmThroughJobQueue(VirtualMachineManagerImpl.java:3922) at com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManagerImpl.java:769) at com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManagerImpl.java:748) at com.cloud.consoleproxy.ConsoleProxyManagerImpl.startProxy(ConsoleProxyManagerImpl.java:540) at com.cloud.consoleproxy.ConsoleProxyManagerImpl.allocCapacity(ConsoleProxyManagerImpl.java:919) at com.cloud.consoleproxy.ConsoleProxyManagerImpl.expandPool(ConsoleProxyManagerImpl.java:1640) at com.cloud.consoleproxy.ConsoleProxyManagerImpl.expandPool(ConsoleProxyManagerImpl.java:157) at com.cloud.vm.SystemVmLoadScanner.loadScan(SystemVmLoadScanner.java:120) at com.cloud.vm.SystemVmLoadScanner.access$100(SystemVmLoadScanner.java:35) at com.cloud.vm.SystemVmLoadScanner$1.reallyRun(SystemVmLoadScanner.java:90) at com.cloud.vm.SystemVmLoadScanner$1.runInContext(SystemVmLoadScanner.java:81) 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
[jira] [Commented] (CLOUDSTACK-7623) SystemVMs not starting
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14146277#comment-14146277 ] Alex Brett commented on CLOUDSTACK-7623: Based on the exception text I imagine https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=commit;h=d8ad3e32bc6ee41d576fa99473834485a5266f93 is the cause here - it turned something that was returning false in to raising the exception we're seeing... SystemVMs not starting -- Key: CLOUDSTACK-7623 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7623 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: SystemVM Affects Versions: 4.5.0 Reporter: Pavan Kumar Bandarupally Priority: Blocker Fix For: 4.5.0 Attachments: management-server.log After installing latest Management Server and zone creation, system VMs are not getting created. The following exception is being generated: 2014-09-24 17:37:17,918 WARN [c.c.u.d.Merovingian2] (consoleproxy-1:ctx-bc88696c) Timed out on acquiring lock vm_instance1 . Waited for 0seconds 2014-09-24 17:37:17,919 WARN [c.c.c.ConsoleProxyManagerImpl] (consoleproxy-1:ctx-bc88696c) Runtime Exception while trying to start console proxy com.cloud.utils.exception.CloudRuntimeException: Timed out on acquiring lock vm_instance1 . Waited for 0seconds at com.cloud.utils.db.Merovingian2.acquire(Merovingian2.java:143) at com.cloud.utils.db.TransactionLegacy.lock(TransactionLegacy.java:389) at com.cloud.utils.db.GenericDaoBase.lockInLockTable(GenericDaoBase.java:1057) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) 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 com.cloud.utils.db.TransactionContextInterceptor.invoke(TransactionContextInterceptor.java:34) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161) 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 $Proxy53.lockInLockTable(Unknown Source) at com.cloud.vm.VirtualMachineManagerImpl$3.doInTransaction(VirtualMachineManagerImpl.java:3927) at com.cloud.vm.VirtualMachineManagerImpl$3.doInTransaction(VirtualMachineManagerImpl.java:3922) at com.cloud.utils.db.Transaction$2.doInTransaction(Transaction.java:49) at com.cloud.utils.db.Transaction.execute(Transaction.java:37) at com.cloud.utils.db.Transaction.execute(Transaction.java:46) at com.cloud.vm.VirtualMachineManagerImpl.startVmThroughJobQueue(VirtualMachineManagerImpl.java:3922) at com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManagerImpl.java:769) at com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManagerImpl.java:748) at com.cloud.consoleproxy.ConsoleProxyManagerImpl.startProxy(ConsoleProxyManagerImpl.java:540) at com.cloud.consoleproxy.ConsoleProxyManagerImpl.allocCapacity(ConsoleProxyManagerImpl.java:919) at com.cloud.consoleproxy.ConsoleProxyManagerImpl.expandPool(ConsoleProxyManagerImpl.java:1640) at com.cloud.consoleproxy.ConsoleProxyManagerImpl.expandPool(ConsoleProxyManagerImpl.java:157) at com.cloud.vm.SystemVmLoadScanner.loadScan(SystemVmLoadScanner.java:120) at com.cloud.vm.SystemVmLoadScanner.access$100(SystemVmLoadScanner.java:35) at com.cloud.vm.SystemVmLoadScanner$1.reallyRun(SystemVmLoadScanner.java:90) at com.cloud.vm.SystemVmLoadScanner$1.runInContext(SystemVmLoadScanner.java:81) 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
[jira] [Resolved] (CLOUDSTACK-7354) [Automation] test_scale_vm fails with VMWare
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Brett resolved CLOUDSTACK-7354. Resolution: Fixed Resolving this one as the change is in and the test passing :) [Automation] test_scale_vm fails with VMWare Key: CLOUDSTACK-7354 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7354 Project: CloudStack Issue Type: Test Security Level: Public(Anyone can view this level - this is the default.) Components: Automation, VMware Affects Versions: Future, 4.5.0 Reporter: John Dilley Assignee: John Dilley Fix For: 4.5.0 test_scale_vm fails on VMWare, complaining about the lack of tools. The VM property needs to set isdynamicallyscalable to true, which the testcase does, but unfortunately after the Scale VM command has been attempted. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7310) XenServer does not support shrink data disk. CloudStack should prevent such an operation on XenServer
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Brett updated CLOUDSTACK-7310: --- Component/s: (was: Automation) Assignee: (was: John Dilley) Summary: XenServer does not support shrink data disk. CloudStack should prevent such an operation on XenServer (was: [Automation] XenServer does not support shrink data disk. CloudStack should prevent such an operation on XenServer) Fair enough - in that case removing the automation tag/component and unassigning from John Dilley, as I know he will not be fixing the API code... XenServer does not support shrink data disk. CloudStack should prevent such an operation on XenServer - Key: CLOUDSTACK-7310 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7310 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Volumes, XenServer Affects Versions: 4.5.0 Reporter: Chandan Purushothama Priority: Critical Fix For: 4.5.0 XenServer does not allowing shrinking of disks currently. Please add code on Cloudstack to prevent such an operation (similar to VMWare case). Failing to prevent such an operation on XenServer leads to https://issues.apache.org/jira/browse/CLOUDSTACK-7228 . -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7346) iSCSI primary storage test should be skipped on VMWare
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Brett resolved CLOUDSTACK-7346. Resolution: Fixed Resolving as the fix went in in the commit in the comments iSCSI primary storage test should be skipped on VMWare -- Key: CLOUDSTACK-7346 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7346 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Automation Affects Versions: Future, 4.5.0 Reporter: John Dilley Assignee: John Dilley Priority: Critical Fix For: 4.5.0 As description - VMWare only supports VMFS which must be created in vCenter. We should create a smoke test for shared mount points (KVM), VMFS (VMWare) and CIFS (Hyper-V) at some point, however given that no tests exist for the other hypervisors yet, I'll postpone adding VMWare's primary storage test for now. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7310) [Automation] XenServer does not support shrink data disk. CloudStack should prevent such an operation on XenServer
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Brett resolved CLOUDSTACK-7310. Resolution: Duplicate Fixed in CLOUDSTACK-7228 [Automation] XenServer does not support shrink data disk. CloudStack should prevent such an operation on XenServer -- Key: CLOUDSTACK-7310 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7310 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Automation, Volumes, XenServer Affects Versions: 4.5.0 Reporter: Chandan Purushothama Assignee: John Dilley Priority: Critical Fix For: 4.5.0 XenServer does not allowing shrinking of disks currently. Please add code on Cloudstack to prevent such an operation (similar to VMWare case). Failing to prevent such an operation on XenServer leads to https://issues.apache.org/jira/browse/CLOUDSTACK-7228 . -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7467) TestVolumes.test_07_resize_fail failing
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Brett resolved CLOUDSTACK-7467.
Resolution: Fixed
Indeed it should, resolving as fixed
TestVolumes.test_07_resize_fail failing
---
Key: CLOUDSTACK-7467
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7467
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Volumes
Affects Versions: 4.5.0
Reporter: Alex Brett
Assignee: Mike Tutkowski
Fix For: 4.5.0
Attachments: management-server.log, runinfo.txt
Commit de6a3112b6b80952d1598acaa112ac50a3ef9d32
(https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=commit;h=de6a3112b6b80952d1598acaa112ac50a3ef9d32)
has caused the BVT test
integration.smoke.test_volumes.TestVolumes.test_07_resize_fail to start
failing with:
{noformat}
==
ERROR: Test resize (negative) non-existent volume
--
Traceback (most recent call last):
File /root/cloudstack/test/integration/smoke/test_volumes.py, line 591,
in test_07_resize_fail
self.apiClient.resizeVolume(cmd)
File
/usr/local/lib/python2.7/dist-packages/marvin/cloudstackAPI/cloudstackAPIClient.py,
line 1716, in resizeVolume
response = self.connection.marvinRequest(command, response_type=response,
method=method)
File
/usr/local/lib/python2.7/dist-packages/marvin/cloudstackConnection.py, line
379, in marvinRequest
raise e
Exception: Job failed: {jobprocstatus : 0, created :
u'2014-09-02T12:19:32+', cmd :
u'org.apache.cloudstack.api.command.admin.volume.ResizeVolumeCmdByAdmin',
userid : u'71a314e6-3296-11e4-b130-0a474b082b17', jobstatus : 2, jobid :
u'b719d471-9acd-49c4-9493-599b7053d4b1', jobresultcode : 530, jobresulttype :
u'object', jobresult : {errorcode : 530, errortext : uTo change a volume's
size without providing a new disk offering, its current disk offering must be
customizable or it must be a root volume.}, accountid :
u'71a306cc-3296-11e4-b130-0a474b082b17'}
begin captured stdout -
=== TestName: test_07_resize_fail | Status : EXCEPTION ===
{noformat}
From what I can see here the test is providing a diskofferingid in its
command, so the error text doesn't appear to make sense, but I'm not hugely
familiar with this area so it is possible the test has always been doing
something wrong...
I'll attach the full runinfo.txt and management server log from a run to this
ticket - assigning initially to Mike Tutkowski as the author of the above
commit...
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7291) LXC: Mgmt server/agent keeps killing systemvms
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14121142#comment-14121142 ] Alex Brett commented on CLOUDSTACK-7291: OK, I'm obviously seeing something different then (though the symptoms are very similar). I'll do a deeper analysis of the logs and file a separate ticket etc as necessary once I'm back in the office... LXC: Mgmt server/agent keeps killing systemvms -- Key: CLOUDSTACK-7291 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7291 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.3.0, 4.3.1 Reporter: Rohit Yadav Priority: Blocker Fix For: 4.3.1 Followed installation and setup docs of 4.3, was unable to get LXC to work on Ubuntu 14.04/trusty. The systemvms kept coming up and result from ssvm_check.sh was good and it was able to reach mgmt server /host, even then mgmt server complained that it was unable to contact agent on the systemvm (ping), while the agent would gracefully shutdown the systemvm (by killing them). Relevant log: 2014-08-07 19:52:26,294 INFO [c.c.u.e.CSExceptionErrorCode] (secstorage-1:ctx-fc57ef43) Could not find exception: com.cloud.exception.OperationTimedoutException in error code list for exceptions 2014-08-07 19:52:26,295 DEBUG [c.c.v.VirtualMachineManagerImpl] (consoleproxy-1:ctx-e123fa9c) Unable to send the start command to host Host[-1-Routing] 2014-08-07 19:52:26,295 DEBUG [c.c.a.m.AgentAttache] (consoleproxy-1:ctx-e123fa9c) Seq 1-51249205: Cancelling. 2014-08-07 19:52:26,295 DEBUG [c.c.v.VirtualMachineManagerImpl] (consoleproxy-1:ctx-e123fa9c) Unable to send the start command to host Host[-1-Routing] 2014-08-07 19:52:26,303 DEBUG [c.c.h.Status] (AgentTaskPool-13:ctx-0b35e679) Transition:[Resource state = Enabled, Agent event = ShutdownRequested, Host id = 1, name = bluebox1.bhaisaab.org] 2014-08-07 19:52:26,311 DEBUG [c.c.h.HighAvailabilityManagerImpl] (secstorage-1:ctx-fc57ef43) Scheduled HAWork[12-CheckStop-2-Starting-Scheduled] 2014-08-07 19:52:26,314 WARN [c.c.s.s.SecondaryStorageManagerImpl] (secstorage-1:ctx-fc57ef43) Exception while trying to start secondary storage vm com.cloud.exception.AgentUnavailableException: Resource [Host:1] is unreachable: Host 1: Unable to start s-2-VM ---at com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:1051) ---at com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManagerImpl.java:761) ---at com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManagerImpl.java:745) ---at com.cloud.storage.secondary.SecondaryStorageManagerImpl.startSecStorageVm(SecondaryStorageManagerImpl.java:261) ---at com.cloud.storage.secondary.SecondaryStorageManagerImpl.allocCapacity(SecondaryStorageManagerImpl.java:694) ---at com.cloud.storage.secondary.SecondaryStorageManagerImpl.expandPool(SecondaryStorageManagerImpl.java:1278) ---at com.cloud.secstorage.PremiumSecondaryStorageManagerImpl.scanPool(PremiumSecondaryStorageManagerImpl.java:123) ---at com.cloud.secstorage.PremiumSecondaryStorageManagerImpl.scanPool(PremiumSecondaryStorageManagerImpl.java:50) ---at com.cloud.vm.SystemVmLoadScanner.loadScan(SystemVmLoadScanner.java:111) ... ... ... Caused by: com.cloud.exception.OperationTimedoutException: Commands 51249206 to Host 1 timed out after 3600 ---at com.cloud.agent.manager.AgentAttache.send(AgentAttache.java:439) ---at com.cloud.agent.manager.AgentManagerImpl.send(AgentManagerImpl.java:394) ---at com.cloud.agent.manager.AgentManagerImpl.send(AgentManagerImpl.java:920) ---at com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:989) ---... 24 more -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7472) Change cloudstack agent.properties file for rhel 7 to include kvmclock.disable=true
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Brett updated CLOUDSTACK-7472: --- Description: We need to minimize manual steps that needs to be done after agent installation so change cloudstack agent.properties file for rhel 7 to include kvmclock.disable=true was: We need to minimize manual steps that needs to be done after agent installation so change cloudstack agent.properties file for rhel 7 to include kvmclock.disable=true Summary: Change cloudstack agent.properties file for rhel 7 to include kvmclock.disable=true (was: [LXC] change cloudstack agent.properties file for rhel 7 to include kvmclock.disable=true) Removing LXC tag as this also affects KVM on RHEL7 Change cloudstack agent.properties file for rhel 7 to include kvmclock.disable=true --- Key: CLOUDSTACK-7472 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7472 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: KVM Affects Versions: 4.5.0 Reporter: shweta agarwal Assignee: Kishan Kavala Priority: Critical Fix For: 4.5.0 We need to minimize manual steps that needs to be done after agent installation so change cloudstack agent.properties file for rhel 7 to include kvmclock.disable=true -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7291) LXC: Mgmt server/agent keeps killing systemvms
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Brett updated CLOUDSTACK-7291: --- Priority: Blocker (was: Major) Upping this to blocker as I'm also seeing it and it is preventing me starting VMs on LXC LXC: Mgmt server/agent keeps killing systemvms -- Key: CLOUDSTACK-7291 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7291 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.3.0, 4.3.1 Reporter: Rohit Yadav Assignee: Kishan Kavala Priority: Blocker Fix For: Future, 4.5.0 Followed installation and setup docs of 4.3, was unable to get LXC to work on Ubuntu 14.04/trusty. The systemvms kept coming up and result from ssvm_check.sh was good and it was able to reach mgmt server /host, even then mgmt server complained that it was unable to contact agent on the systemvm (ping), while the agent would gracefully shutdown the systemvm (by killing them). Relevant log: 2014-08-07 19:52:26,294 INFO [c.c.u.e.CSExceptionErrorCode] (secstorage-1:ctx-fc57ef43) Could not find exception: com.cloud.exception.OperationTimedoutException in error code list for exceptions 2014-08-07 19:52:26,295 DEBUG [c.c.v.VirtualMachineManagerImpl] (consoleproxy-1:ctx-e123fa9c) Unable to send the start command to host Host[-1-Routing] 2014-08-07 19:52:26,295 DEBUG [c.c.a.m.AgentAttache] (consoleproxy-1:ctx-e123fa9c) Seq 1-51249205: Cancelling. 2014-08-07 19:52:26,295 DEBUG [c.c.v.VirtualMachineManagerImpl] (consoleproxy-1:ctx-e123fa9c) Unable to send the start command to host Host[-1-Routing] 2014-08-07 19:52:26,303 DEBUG [c.c.h.Status] (AgentTaskPool-13:ctx-0b35e679) Transition:[Resource state = Enabled, Agent event = ShutdownRequested, Host id = 1, name = bluebox1.bhaisaab.org] 2014-08-07 19:52:26,311 DEBUG [c.c.h.HighAvailabilityManagerImpl] (secstorage-1:ctx-fc57ef43) Scheduled HAWork[12-CheckStop-2-Starting-Scheduled] 2014-08-07 19:52:26,314 WARN [c.c.s.s.SecondaryStorageManagerImpl] (secstorage-1:ctx-fc57ef43) Exception while trying to start secondary storage vm com.cloud.exception.AgentUnavailableException: Resource [Host:1] is unreachable: Host 1: Unable to start s-2-VM ---at com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:1051) ---at com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManagerImpl.java:761) ---at com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManagerImpl.java:745) ---at com.cloud.storage.secondary.SecondaryStorageManagerImpl.startSecStorageVm(SecondaryStorageManagerImpl.java:261) ---at com.cloud.storage.secondary.SecondaryStorageManagerImpl.allocCapacity(SecondaryStorageManagerImpl.java:694) ---at com.cloud.storage.secondary.SecondaryStorageManagerImpl.expandPool(SecondaryStorageManagerImpl.java:1278) ---at com.cloud.secstorage.PremiumSecondaryStorageManagerImpl.scanPool(PremiumSecondaryStorageManagerImpl.java:123) ---at com.cloud.secstorage.PremiumSecondaryStorageManagerImpl.scanPool(PremiumSecondaryStorageManagerImpl.java:50) ---at com.cloud.vm.SystemVmLoadScanner.loadScan(SystemVmLoadScanner.java:111) ... ... ... Caused by: com.cloud.exception.OperationTimedoutException: Commands 51249206 to Host 1 timed out after 3600 ---at com.cloud.agent.manager.AgentAttache.send(AgentAttache.java:439) ---at com.cloud.agent.manager.AgentManagerImpl.send(AgentManagerImpl.java:394) ---at com.cloud.agent.manager.AgentManagerImpl.send(AgentManagerImpl.java:920) ---at com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:989) ---... 24 more -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CLOUDSTACK-7291) LXC: Mgmt server/agent keeps killing systemvms
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14119779#comment-14119779 ] Alex Brett edited comment on CLOUDSTACK-7291 at 9/3/14 11:47 AM: - Upping this to blocker as I'm also seeing this on rhel7 and it is preventing me starting VMs on LXC was (Author: alexbre): Upping this to blocker as I'm also seeing it and it is preventing me starting VMs on LXC LXC: Mgmt server/agent keeps killing systemvms -- Key: CLOUDSTACK-7291 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7291 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Affects Versions: 4.3.0, 4.3.1 Reporter: Rohit Yadav Assignee: Kishan Kavala Priority: Blocker Fix For: Future, 4.5.0 Followed installation and setup docs of 4.3, was unable to get LXC to work on Ubuntu 14.04/trusty. The systemvms kept coming up and result from ssvm_check.sh was good and it was able to reach mgmt server /host, even then mgmt server complained that it was unable to contact agent on the systemvm (ping), while the agent would gracefully shutdown the systemvm (by killing them). Relevant log: 2014-08-07 19:52:26,294 INFO [c.c.u.e.CSExceptionErrorCode] (secstorage-1:ctx-fc57ef43) Could not find exception: com.cloud.exception.OperationTimedoutException in error code list for exceptions 2014-08-07 19:52:26,295 DEBUG [c.c.v.VirtualMachineManagerImpl] (consoleproxy-1:ctx-e123fa9c) Unable to send the start command to host Host[-1-Routing] 2014-08-07 19:52:26,295 DEBUG [c.c.a.m.AgentAttache] (consoleproxy-1:ctx-e123fa9c) Seq 1-51249205: Cancelling. 2014-08-07 19:52:26,295 DEBUG [c.c.v.VirtualMachineManagerImpl] (consoleproxy-1:ctx-e123fa9c) Unable to send the start command to host Host[-1-Routing] 2014-08-07 19:52:26,303 DEBUG [c.c.h.Status] (AgentTaskPool-13:ctx-0b35e679) Transition:[Resource state = Enabled, Agent event = ShutdownRequested, Host id = 1, name = bluebox1.bhaisaab.org] 2014-08-07 19:52:26,311 DEBUG [c.c.h.HighAvailabilityManagerImpl] (secstorage-1:ctx-fc57ef43) Scheduled HAWork[12-CheckStop-2-Starting-Scheduled] 2014-08-07 19:52:26,314 WARN [c.c.s.s.SecondaryStorageManagerImpl] (secstorage-1:ctx-fc57ef43) Exception while trying to start secondary storage vm com.cloud.exception.AgentUnavailableException: Resource [Host:1] is unreachable: Host 1: Unable to start s-2-VM ---at com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:1051) ---at com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManagerImpl.java:761) ---at com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManagerImpl.java:745) ---at com.cloud.storage.secondary.SecondaryStorageManagerImpl.startSecStorageVm(SecondaryStorageManagerImpl.java:261) ---at com.cloud.storage.secondary.SecondaryStorageManagerImpl.allocCapacity(SecondaryStorageManagerImpl.java:694) ---at com.cloud.storage.secondary.SecondaryStorageManagerImpl.expandPool(SecondaryStorageManagerImpl.java:1278) ---at com.cloud.secstorage.PremiumSecondaryStorageManagerImpl.scanPool(PremiumSecondaryStorageManagerImpl.java:123) ---at com.cloud.secstorage.PremiumSecondaryStorageManagerImpl.scanPool(PremiumSecondaryStorageManagerImpl.java:50) ---at com.cloud.vm.SystemVmLoadScanner.loadScan(SystemVmLoadScanner.java:111) ... ... ... Caused by: com.cloud.exception.OperationTimedoutException: Commands 51249206 to Host 1 timed out after 3600 ---at com.cloud.agent.manager.AgentAttache.send(AgentAttache.java:439) ---at com.cloud.agent.manager.AgentManagerImpl.send(AgentManagerImpl.java:394) ---at com.cloud.agent.manager.AgentManagerImpl.send(AgentManagerImpl.java:920) ---at com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:989) ---... 24 more -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CLOUDSTACK-7455) Unable to connect to management server ?since SAML2 merge?
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7455?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Brett resolved CLOUDSTACK-7455.
Resolution: Fixed
Resolving as this was fixed by the commit mentioned above...
Unable to connect to management server ?since SAML2 merge?
--
Key: CLOUDSTACK-7455
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7455
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Management Server
Affects Versions: 4.5.0
Reporter: Alex Brett
Priority: Blocker
Fix For: 4.5.0
Attachments: management-server.log
In builds that have the SAML2 merge in, while I can start the management
server, it appears not to fully startup, and doesn't give the UI or API.
management-server.log (attached) stops at:
{noformat}
2014-08-29 14:55:02,097 INFO [o.a.c.s.l.CloudStackExtendedLifeCycle]
(main:null) Starting CloudStack Components
2014-08-29 14:55:02,098 INFO [o.a.c.s.l.CloudStackExtendedLifeCycle]
(main:null) Done Starting CloudStack Components
2014-08-29 14:55:02,098 INFO [o.a.c.s.m.m.i.DefaultModuleDefinitionSet]
(main:null) Starting module [core]
2014-08-29 14:55:02,098 INFO [o.a.c.s.l.CloudStackExtendedLifeCycle]
(main:null) Starting CloudStack Components
2014-08-29 14:55:02,106 INFO [c.c.h.h.m.HypervManagerImpl] (main:null)
Cleanup mounted mount points used in previous session
2014-08-29 14:55:02,141 INFO [c.c.u.DatabaseIntegrityChecker] (main:null)
Grabbing lock to check for database integrity.
2014-08-29 14:55:02,143 INFO [c.c.u.DatabaseIntegrityChecker] (main:null)
Performing database integrity check
2014-08-29 14:55:02,144 DEBUG [c.c.u.DatabaseIntegrityChecker] (main:null) No
duplicate hosts with the same local storage found in database
2014-08-29 14:55:02,146 DEBUG [c.c.u.d.VersionDaoImpl] (main:null) Checking
to see if the database is at a version before it was the version table is
created
2014-08-29 14:55:02,150 INFO [c.c.c.ClusterManagerImpl] (main:null) Starting
Cluster manager, msid : 99326614648649
2014-08-29 14:55:02,155 INFO [c.c.c.ClusterManagerImpl] (main:null)
Management server 99326614648649, runId 1409324073632 is being started
2014-08-29 14:55:02,156 INFO [c.c.c.ClusterManagerImpl] (main:null)
Management server (host id : 1) is being started at 127.0.0.1:9090
2014-08-29 14:55:02,162 INFO [c.c.c.ClusterManagerImpl] (main:null) Cluster
manager was started successfully
2014-08-29 14:55:02,167 DEBUG [c.c.u.s.Script] (main:null) Executing:
/bin/bash -c /sbin/route | grep default
2014-08-29 14:55:02,183 DEBUG [c.c.u.s.Script] (main:null) Execution is
successful.
2014-08-29 14:55:02,185 WARN [c.c.c.ConfigurationManagerImpl] (main:null)
Management network CIDR is not configured originally. Set it default to
10.220.128.0/19
2014-08-29 14:55:02,190 WARN [o.a.c.alerts] (main:null) alertType:: 14 //
dataCenterId:: 0 // podId:: 0 // clusterId:: null // message:: Management
network CIDR is not configured originally. Set it default to 10.220.128.0/19
2014-08-29 14:55:02,215 INFO [c.c.h.HighAvailabilityManagerImpl]
(HA-Worker-0:null) Starting work
2014-08-29 14:55:02,224 INFO [c.c.h.HighAvailabilityManagerImpl]
(HA-Worker-3:null) Starting work
2014-08-29 14:55:02,224 INFO [c.c.h.HighAvailabilityManagerImpl]
(HA-Worker-4:null) Starting work
2014-08-29 14:55:02,218 INFO [c.c.h.HighAvailabilityManagerImpl]
(HA-Worker-2:null) Starting work
2014-08-29 14:55:02,218 INFO [c.c.h.HighAvailabilityManagerImpl]
(HA-Worker-1:null) Starting work
2014-08-29 14:55:02,290 DEBUG [c.c.n.l.LBHealthCheckManagerImpl] (main:null)
LB HealthCheckmanager is getting Started
2014-08-29 14:55:02,307 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl]
(NetworkStatsUpdater-1:ctx-5b259b22) Successfully updated aggregate network
stats
2014-08-29 14:55:11,061 INFO [c.c.u.c.ComponentContext] (main:null)
Configuring
com.cloud.bridge.persist.dao.CloudStackAccountDaoImpl_EnhancerByCloudStack_156f5045
2014-08-29 14:55:11,066 INFO [c.c.u.c.ComponentContext] (main:null)
Configuring
com.cloud.bridge.persist.dao.OfferingDaoImpl_EnhancerByCloudStack_aa79bf9f
2014-08-29 14:55:11,066 INFO [c.c.u.c.ComponentContext] (main:null)
Configuring
com.cloud.bridge.persist.dao.SMetaDaoImpl_EnhancerByCloudStack_c720af97
2014-08-29 14:55:11,066 INFO [c.c.u.c.ComponentContext] (main:null)
Configuring
com.cloud.bridge.persist.dao.MultipartMetaDaoImpl_EnhancerByCloudStack_ae893256
2014-08-29 14:55:11,067 INFO [c.c.u.c.ComponentContext] (main:null)
Configuring
com.cloud.bridge.persist.dao.UserCredentialsDaoImpl_EnhancerByCloudStack_68227ab6
2014-08-29 14:55:11,067 INFO
[jira] [Created] (CLOUDSTACK-7467) TestVolumes.test_07_resize_fail failing
Alex Brett created CLOUDSTACK-7467:
--
Summary: TestVolumes.test_07_resize_fail failing
Key: CLOUDSTACK-7467
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7467
Project: CloudStack
Issue Type: Bug
Security Level: Public (Anyone can view this level - this is the default.)
Components: Volumes
Affects Versions: 4.5.0
Reporter: Alex Brett
Assignee: Mike Tutkowski
Fix For: 4.5.0
Attachments: management-server.log, runinfo.txt
Commit de6a3112b6b80952d1598acaa112ac50a3ef9d32
(https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=commit;h=de6a3112b6b80952d1598acaa112ac50a3ef9d32)
has caused the BVT test
integration.smoke.test_volumes.TestVolumes.test_07_resize_fail to start failing
with:
{noformat}
==
ERROR: Test resize (negative) non-existent volume
--
Traceback (most recent call last):
File /root/cloudstack/test/integration/smoke/test_volumes.py, line 591, in
test_07_resize_fail
self.apiClient.resizeVolume(cmd)
File
/usr/local/lib/python2.7/dist-packages/marvin/cloudstackAPI/cloudstackAPIClient.py,
line 1716, in resizeVolume
response = self.connection.marvinRequest(command, response_type=response,
method=method)
File /usr/local/lib/python2.7/dist-packages/marvin/cloudstackConnection.py,
line 379, in marvinRequest
raise e
Exception: Job failed: {jobprocstatus : 0, created :
u'2014-09-02T12:19:32+', cmd :
u'org.apache.cloudstack.api.command.admin.volume.ResizeVolumeCmdByAdmin',
userid : u'71a314e6-3296-11e4-b130-0a474b082b17', jobstatus : 2, jobid :
u'b719d471-9acd-49c4-9493-599b7053d4b1', jobresultcode : 530, jobresulttype :
u'object', jobresult : {errorcode : 530, errortext : uTo change a volume's
size without providing a new disk offering, its current disk offering must be
customizable or it must be a root volume.}, accountid :
u'71a306cc-3296-11e4-b130-0a474b082b17'}
begin captured stdout -
=== TestName: test_07_resize_fail | Status : EXCEPTION ===
{noformat}
From what I can see here the test is providing a diskofferingid in its
command, so the error text doesn't appear to make sense, but I'm not hugely
familiar with this area so it is possible the test has always been doing
something wrong...
I'll attach the full runinfo.txt and management server log from a run to this
ticket - assigning initially to Mike Tutkowski as the author of the above
commit...
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-7467) TestVolumes.test_07_resize_fail failing
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Brett updated CLOUDSTACK-7467:
---
Attachment: runinfo.txt
management-server.log
TestVolumes.test_07_resize_fail failing
---
Key: CLOUDSTACK-7467
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7467
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Volumes
Affects Versions: 4.5.0
Reporter: Alex Brett
Assignee: Mike Tutkowski
Fix For: 4.5.0
Attachments: management-server.log, runinfo.txt
Commit de6a3112b6b80952d1598acaa112ac50a3ef9d32
(https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=commit;h=de6a3112b6b80952d1598acaa112ac50a3ef9d32)
has caused the BVT test
integration.smoke.test_volumes.TestVolumes.test_07_resize_fail to start
failing with:
{noformat}
==
ERROR: Test resize (negative) non-existent volume
--
Traceback (most recent call last):
File /root/cloudstack/test/integration/smoke/test_volumes.py, line 591,
in test_07_resize_fail
self.apiClient.resizeVolume(cmd)
File
/usr/local/lib/python2.7/dist-packages/marvin/cloudstackAPI/cloudstackAPIClient.py,
line 1716, in resizeVolume
response = self.connection.marvinRequest(command, response_type=response,
method=method)
File
/usr/local/lib/python2.7/dist-packages/marvin/cloudstackConnection.py, line
379, in marvinRequest
raise e
Exception: Job failed: {jobprocstatus : 0, created :
u'2014-09-02T12:19:32+', cmd :
u'org.apache.cloudstack.api.command.admin.volume.ResizeVolumeCmdByAdmin',
userid : u'71a314e6-3296-11e4-b130-0a474b082b17', jobstatus : 2, jobid :
u'b719d471-9acd-49c4-9493-599b7053d4b1', jobresultcode : 530, jobresulttype :
u'object', jobresult : {errorcode : 530, errortext : uTo change a volume's
size without providing a new disk offering, its current disk offering must be
customizable or it must be a root volume.}, accountid :
u'71a306cc-3296-11e4-b130-0a474b082b17'}
begin captured stdout -
=== TestName: test_07_resize_fail | Status : EXCEPTION ===
{noformat}
From what I can see here the test is providing a diskofferingid in its
command, so the error text doesn't appear to make sense, but I'm not hugely
familiar with this area so it is possible the test has always been doing
something wrong...
I'll attach the full runinfo.txt and management server log from a run to this
ticket - assigning initially to Mike Tutkowski as the author of the above
commit...
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7467) TestVolumes.test_07_resize_fail failing
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14118351#comment-14118351
]
Alex Brett commented on CLOUDSTACK-7467:
bq. Can you tell me if my analysis is correct here (i.e. you used to not get an
exception, but now you do)?
Correct - the test expects this resize to succeed, and it used to, but now it
throws an exception.
bq. If so, I'm thinking the new logic is better than the old logic because it
seems this test case was missing a problem (it was expecting the resize to work
(i.e. not throw an exception), but in reality the code was ignoring the newly
passed-in size and setting the size of the volume to be the same as it
currently is).
That makes sense (though the error message in this case might want tweaking as
it's quite misleading by claiming you didn't pass in a diskofferingid).
Looking at the test in more detail I can see the steps it executes are:
* Attempts to resize a volume with an invalid volume ID, verifies it gets an
exception with invalid in it somewhere
* Attempts to resize a volume with an invalid disk offering ID, verifies it
gets an exception with invalid in it somewhere
* Attempts to resize a root disk using a disk offering, verifies it gets an
exception
* Attaches a volume that is not custom, then attempts to resize it (this is
where it is now failing but wasn't previously), then verifies that the volume
*doesn't* resize
So it looks like the test was actually verifying the behaviour as is, and all
that needs modifying is for it to expect an exception rather than expecting the
command to be accepted but not actually do the resize...
TestVolumes.test_07_resize_fail failing
---
Key: CLOUDSTACK-7467
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7467
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Volumes
Affects Versions: 4.5.0
Reporter: Alex Brett
Assignee: Mike Tutkowski
Fix For: 4.5.0
Attachments: management-server.log, runinfo.txt
Commit de6a3112b6b80952d1598acaa112ac50a3ef9d32
(https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=commit;h=de6a3112b6b80952d1598acaa112ac50a3ef9d32)
has caused the BVT test
integration.smoke.test_volumes.TestVolumes.test_07_resize_fail to start
failing with:
{noformat}
==
ERROR: Test resize (negative) non-existent volume
--
Traceback (most recent call last):
File /root/cloudstack/test/integration/smoke/test_volumes.py, line 591,
in test_07_resize_fail
self.apiClient.resizeVolume(cmd)
File
/usr/local/lib/python2.7/dist-packages/marvin/cloudstackAPI/cloudstackAPIClient.py,
line 1716, in resizeVolume
response = self.connection.marvinRequest(command, response_type=response,
method=method)
File
/usr/local/lib/python2.7/dist-packages/marvin/cloudstackConnection.py, line
379, in marvinRequest
raise e
Exception: Job failed: {jobprocstatus : 0, created :
u'2014-09-02T12:19:32+', cmd :
u'org.apache.cloudstack.api.command.admin.volume.ResizeVolumeCmdByAdmin',
userid : u'71a314e6-3296-11e4-b130-0a474b082b17', jobstatus : 2, jobid :
u'b719d471-9acd-49c4-9493-599b7053d4b1', jobresultcode : 530, jobresulttype :
u'object', jobresult : {errorcode : 530, errortext : uTo change a volume's
size without providing a new disk offering, its current disk offering must be
customizable or it must be a root volume.}, accountid :
u'71a306cc-3296-11e4-b130-0a474b082b17'}
begin captured stdout -
=== TestName: test_07_resize_fail | Status : EXCEPTION ===
{noformat}
From what I can see here the test is providing a diskofferingid in its
command, so the error text doesn't appear to make sense, but I'm not hugely
familiar with this area so it is possible the test has always been doing
something wrong...
I'll attach the full runinfo.txt and management server log from a run to this
ticket - assigning initially to Mike Tutkowski as the author of the above
commit...
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7467) TestVolumes.test_07_resize_fail failing
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14118359#comment-14118359
]
Alex Brett commented on CLOUDSTACK-7467:
I'll prepare a patch that fixes up the test...
TestVolumes.test_07_resize_fail failing
---
Key: CLOUDSTACK-7467
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7467
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Volumes
Affects Versions: 4.5.0
Reporter: Alex Brett
Assignee: Mike Tutkowski
Fix For: 4.5.0
Attachments: management-server.log, runinfo.txt
Commit de6a3112b6b80952d1598acaa112ac50a3ef9d32
(https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=commit;h=de6a3112b6b80952d1598acaa112ac50a3ef9d32)
has caused the BVT test
integration.smoke.test_volumes.TestVolumes.test_07_resize_fail to start
failing with:
{noformat}
==
ERROR: Test resize (negative) non-existent volume
--
Traceback (most recent call last):
File /root/cloudstack/test/integration/smoke/test_volumes.py, line 591,
in test_07_resize_fail
self.apiClient.resizeVolume(cmd)
File
/usr/local/lib/python2.7/dist-packages/marvin/cloudstackAPI/cloudstackAPIClient.py,
line 1716, in resizeVolume
response = self.connection.marvinRequest(command, response_type=response,
method=method)
File
/usr/local/lib/python2.7/dist-packages/marvin/cloudstackConnection.py, line
379, in marvinRequest
raise e
Exception: Job failed: {jobprocstatus : 0, created :
u'2014-09-02T12:19:32+', cmd :
u'org.apache.cloudstack.api.command.admin.volume.ResizeVolumeCmdByAdmin',
userid : u'71a314e6-3296-11e4-b130-0a474b082b17', jobstatus : 2, jobid :
u'b719d471-9acd-49c4-9493-599b7053d4b1', jobresultcode : 530, jobresulttype :
u'object', jobresult : {errorcode : 530, errortext : uTo change a volume's
size without providing a new disk offering, its current disk offering must be
customizable or it must be a root volume.}, accountid :
u'71a306cc-3296-11e4-b130-0a474b082b17'}
begin captured stdout -
=== TestName: test_07_resize_fail | Status : EXCEPTION ===
{noformat}
From what I can see here the test is providing a diskofferingid in its
command, so the error text doesn't appear to make sense, but I'm not hugely
familiar with this area so it is possible the test has always been doing
something wrong...
I'll attach the full runinfo.txt and management server log from a run to this
ticket - assigning initially to Mike Tutkowski as the author of the above
commit...
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7467) TestVolumes.test_07_resize_fail failing
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14118360#comment-14118360
]
Alex Brett commented on CLOUDSTACK-7467:
That's true - not sure how helpful it is though, as the user might not realise
they've passed in the same disk offering ;)
TestVolumes.test_07_resize_fail failing
---
Key: CLOUDSTACK-7467
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7467
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Volumes
Affects Versions: 4.5.0
Reporter: Alex Brett
Assignee: Mike Tutkowski
Fix For: 4.5.0
Attachments: management-server.log, runinfo.txt
Commit de6a3112b6b80952d1598acaa112ac50a3ef9d32
(https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=commit;h=de6a3112b6b80952d1598acaa112ac50a3ef9d32)
has caused the BVT test
integration.smoke.test_volumes.TestVolumes.test_07_resize_fail to start
failing with:
{noformat}
==
ERROR: Test resize (negative) non-existent volume
--
Traceback (most recent call last):
File /root/cloudstack/test/integration/smoke/test_volumes.py, line 591,
in test_07_resize_fail
self.apiClient.resizeVolume(cmd)
File
/usr/local/lib/python2.7/dist-packages/marvin/cloudstackAPI/cloudstackAPIClient.py,
line 1716, in resizeVolume
response = self.connection.marvinRequest(command, response_type=response,
method=method)
File
/usr/local/lib/python2.7/dist-packages/marvin/cloudstackConnection.py, line
379, in marvinRequest
raise e
Exception: Job failed: {jobprocstatus : 0, created :
u'2014-09-02T12:19:32+', cmd :
u'org.apache.cloudstack.api.command.admin.volume.ResizeVolumeCmdByAdmin',
userid : u'71a314e6-3296-11e4-b130-0a474b082b17', jobstatus : 2, jobid :
u'b719d471-9acd-49c4-9493-599b7053d4b1', jobresultcode : 530, jobresulttype :
u'object', jobresult : {errorcode : 530, errortext : uTo change a volume's
size without providing a new disk offering, its current disk offering must be
customizable or it must be a root volume.}, accountid :
u'71a306cc-3296-11e4-b130-0a474b082b17'}
begin captured stdout -
=== TestName: test_07_resize_fail | Status : EXCEPTION ===
{noformat}
From what I can see here the test is providing a diskofferingid in its
command, so the error text doesn't appear to make sense, but I'm not hugely
familiar with this area so it is possible the test has always been doing
something wrong...
I'll attach the full runinfo.txt and management server log from a run to this
ticket - assigning initially to Mike Tutkowski as the author of the above
commit...
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7467) TestVolumes.test_07_resize_fail failing
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14118423#comment-14118423
]
Alex Brett commented on CLOUDSTACK-7467:
Review posted at https://reviews.apache.org/r/25258/ (if you're not happy
reviewing the Marvin code let me know and I'll find someone here who can do so
and then commit it for me).
Re: error message - your suggestion looks sensible to me, though I think it is
probably quite a corner case so probably not a big deal either way!
TestVolumes.test_07_resize_fail failing
---
Key: CLOUDSTACK-7467
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7467
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Volumes
Affects Versions: 4.5.0
Reporter: Alex Brett
Assignee: Mike Tutkowski
Fix For: 4.5.0
Attachments: management-server.log, runinfo.txt
Commit de6a3112b6b80952d1598acaa112ac50a3ef9d32
(https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=commit;h=de6a3112b6b80952d1598acaa112ac50a3ef9d32)
has caused the BVT test
integration.smoke.test_volumes.TestVolumes.test_07_resize_fail to start
failing with:
{noformat}
==
ERROR: Test resize (negative) non-existent volume
--
Traceback (most recent call last):
File /root/cloudstack/test/integration/smoke/test_volumes.py, line 591,
in test_07_resize_fail
self.apiClient.resizeVolume(cmd)
File
/usr/local/lib/python2.7/dist-packages/marvin/cloudstackAPI/cloudstackAPIClient.py,
line 1716, in resizeVolume
response = self.connection.marvinRequest(command, response_type=response,
method=method)
File
/usr/local/lib/python2.7/dist-packages/marvin/cloudstackConnection.py, line
379, in marvinRequest
raise e
Exception: Job failed: {jobprocstatus : 0, created :
u'2014-09-02T12:19:32+', cmd :
u'org.apache.cloudstack.api.command.admin.volume.ResizeVolumeCmdByAdmin',
userid : u'71a314e6-3296-11e4-b130-0a474b082b17', jobstatus : 2, jobid :
u'b719d471-9acd-49c4-9493-599b7053d4b1', jobresultcode : 530, jobresulttype :
u'object', jobresult : {errorcode : 530, errortext : uTo change a volume's
size without providing a new disk offering, its current disk offering must be
customizable or it must be a root volume.}, accountid :
u'71a306cc-3296-11e4-b130-0a474b082b17'}
begin captured stdout -
=== TestName: test_07_resize_fail | Status : EXCEPTION ===
{noformat}
From what I can see here the test is providing a diskofferingid in its
command, so the error text doesn't appear to make sense, but I'm not hugely
familiar with this area so it is possible the test has always been doing
something wrong...
I'll attach the full runinfo.txt and management server log from a run to this
ticket - assigning initially to Mike Tutkowski as the author of the above
commit...
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-7455) Unable to connect to management server ?since SAML2 merge?
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14116679#comment-14116679
]
Alex Brett commented on CLOUDSTACK-7455:
Sadly I'm still seeing the same, but I think I've found the exception in
localhost log:
{noformat}
Aug 30, 2014 11:10:50 PM org.apache.catalina.core.StandardContext listenerStart
SEVERE: Exception sending context initialized event to listener instance of
class org.apache.cloudstack.spring.module.web.CloudStackContextLoaderListener
java.lang.NullPointerException
at java.util.ArrayList.addAll(ArrayList.java:530)
at
com.cloud.api.auth.APIAuthenticationManagerImpl.getCommands(APIAuthenticationManagerImpl.java:72)
at
com.cloud.api.auth.APIAuthenticationManagerImpl.start(APIAuthenticationManagerImpl.java:56)
at
org.apache.cloudstack.spring.lifecycle.CloudStackExtendedLifeCycle$1.with(CloudStackExtendedLifeCycle.java:75)
at
org.apache.cloudstack.spring.lifecycle.CloudStackExtendedLifeCycle.with(CloudStackExtendedLifeCycle.java:153)
at
org.apache.cloudstack.spring.lifecycle.CloudStackExtendedLifeCycle.startBeans(CloudStackExtendedLifeCycle.java:72)
at
org.apache.cloudstack.spring.lifecycle.CloudStackExtendedLifeCycleStart.run(CloudStackExtendedLifeCycleStart.java:46)
at
org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet$1.with(DefaultModuleDefinitionSet.java:105)
at
org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet.withModule(DefaultModuleDefinitionSet.java:245)
at
org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet.withModule(DefaultModuleDefinitionSet.java:250)
at
org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet.withModule(DefaultModuleDefinitionSet.java:250)
at
org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet.withModule(DefaultModuleDefinitionSet.java:233)
at
org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet.startContexts(DefaultModuleDefinitionSet.java:97)
at
org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet.load(DefaultModuleDefinitionSet.java:80)
at
org.apache.cloudstack.spring.module.factory.ModuleBasedContextFactory.loadModules(ModuleBasedContextFactory.java:37)
at
org.apache.cloudstack.spring.module.factory.CloudStackSpringContext.init(CloudStackSpringContext.java:70)
at
org.apache.cloudstack.spring.module.factory.CloudStackSpringContext.init(CloudStackSpringContext.java:57)
at
org.apache.cloudstack.spring.module.factory.CloudStackSpringContext.init(CloudStackSpringContext.java:61)
at
org.apache.cloudstack.spring.module.web.CloudStackContextLoaderListener.contextInitialized(CloudStackContextLoaderListener.java:52)
at
org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:3972)
at
org.apache.catalina.core.StandardContext.start(StandardContext.java:4467)
at
org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:791)
at
org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:771)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:526)
at
org.apache.catalina.startup.HostConfig.deployDirectory(HostConfig.java:1041)
at
org.apache.catalina.startup.HostConfig.deployDirectories(HostConfig.java:964)
at
org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:502)
at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1277)
at
org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:321)
at
org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1053)
at org.apache.catalina.core.StandardHost.start(StandardHost.java:722)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1045)
at
org.apache.catalina.core.StandardEngine.start(StandardEngine.java:443)
at
org.apache.catalina.core.StandardService.start(StandardService.java:516)
at
org.apache.catalina.core.StandardServer.start(StandardServer.java:710)
at org.apache.catalina.startup.Catalina.start(Catalina.java:593)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:289)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:414)
{noformat}
Unable to connect to management
[jira] [Commented] (CLOUDSTACK-7455) Unable to connect to management server ?since SAML2 merge?
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14116578#comment-14116578
]
Alex Brett commented on CLOUDSTACK-7455:
I've just kicked off a set of tests (would have done so earlier but have been
out all day and not able to connect in to launch the tests). The
jenkins.buildacloud.org simulator tests look to be working again now though so
that's a good sign...
Unable to connect to management server ?since SAML2 merge?
--
Key: CLOUDSTACK-7455
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7455
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Management Server
Affects Versions: 4.5.0
Reporter: Alex Brett
Priority: Blocker
Fix For: 4.5.0
Attachments: management-server.log
In builds that have the SAML2 merge in, while I can start the management
server, it appears not to fully startup, and doesn't give the UI or API.
management-server.log (attached) stops at:
{noformat}
2014-08-29 14:55:02,097 INFO [o.a.c.s.l.CloudStackExtendedLifeCycle]
(main:null) Starting CloudStack Components
2014-08-29 14:55:02,098 INFO [o.a.c.s.l.CloudStackExtendedLifeCycle]
(main:null) Done Starting CloudStack Components
2014-08-29 14:55:02,098 INFO [o.a.c.s.m.m.i.DefaultModuleDefinitionSet]
(main:null) Starting module [core]
2014-08-29 14:55:02,098 INFO [o.a.c.s.l.CloudStackExtendedLifeCycle]
(main:null) Starting CloudStack Components
2014-08-29 14:55:02,106 INFO [c.c.h.h.m.HypervManagerImpl] (main:null)
Cleanup mounted mount points used in previous session
2014-08-29 14:55:02,141 INFO [c.c.u.DatabaseIntegrityChecker] (main:null)
Grabbing lock to check for database integrity.
2014-08-29 14:55:02,143 INFO [c.c.u.DatabaseIntegrityChecker] (main:null)
Performing database integrity check
2014-08-29 14:55:02,144 DEBUG [c.c.u.DatabaseIntegrityChecker] (main:null) No
duplicate hosts with the same local storage found in database
2014-08-29 14:55:02,146 DEBUG [c.c.u.d.VersionDaoImpl] (main:null) Checking
to see if the database is at a version before it was the version table is
created
2014-08-29 14:55:02,150 INFO [c.c.c.ClusterManagerImpl] (main:null) Starting
Cluster manager, msid : 99326614648649
2014-08-29 14:55:02,155 INFO [c.c.c.ClusterManagerImpl] (main:null)
Management server 99326614648649, runId 1409324073632 is being started
2014-08-29 14:55:02,156 INFO [c.c.c.ClusterManagerImpl] (main:null)
Management server (host id : 1) is being started at 127.0.0.1:9090
2014-08-29 14:55:02,162 INFO [c.c.c.ClusterManagerImpl] (main:null) Cluster
manager was started successfully
2014-08-29 14:55:02,167 DEBUG [c.c.u.s.Script] (main:null) Executing:
/bin/bash -c /sbin/route | grep default
2014-08-29 14:55:02,183 DEBUG [c.c.u.s.Script] (main:null) Execution is
successful.
2014-08-29 14:55:02,185 WARN [c.c.c.ConfigurationManagerImpl] (main:null)
Management network CIDR is not configured originally. Set it default to
10.220.128.0/19
2014-08-29 14:55:02,190 WARN [o.a.c.alerts] (main:null) alertType:: 14 //
dataCenterId:: 0 // podId:: 0 // clusterId:: null // message:: Management
network CIDR is not configured originally. Set it default to 10.220.128.0/19
2014-08-29 14:55:02,215 INFO [c.c.h.HighAvailabilityManagerImpl]
(HA-Worker-0:null) Starting work
2014-08-29 14:55:02,224 INFO [c.c.h.HighAvailabilityManagerImpl]
(HA-Worker-3:null) Starting work
2014-08-29 14:55:02,224 INFO [c.c.h.HighAvailabilityManagerImpl]
(HA-Worker-4:null) Starting work
2014-08-29 14:55:02,218 INFO [c.c.h.HighAvailabilityManagerImpl]
(HA-Worker-2:null) Starting work
2014-08-29 14:55:02,218 INFO [c.c.h.HighAvailabilityManagerImpl]
(HA-Worker-1:null) Starting work
2014-08-29 14:55:02,290 DEBUG [c.c.n.l.LBHealthCheckManagerImpl] (main:null)
LB HealthCheckmanager is getting Started
2014-08-29 14:55:02,307 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl]
(NetworkStatsUpdater-1:ctx-5b259b22) Successfully updated aggregate network
stats
2014-08-29 14:55:11,061 INFO [c.c.u.c.ComponentContext] (main:null)
Configuring
com.cloud.bridge.persist.dao.CloudStackAccountDaoImpl_EnhancerByCloudStack_156f5045
2014-08-29 14:55:11,066 INFO [c.c.u.c.ComponentContext] (main:null)
Configuring
com.cloud.bridge.persist.dao.OfferingDaoImpl_EnhancerByCloudStack_aa79bf9f
2014-08-29 14:55:11,066 INFO [c.c.u.c.ComponentContext] (main:null)
Configuring
com.cloud.bridge.persist.dao.SMetaDaoImpl_EnhancerByCloudStack_c720af97
2014-08-29 14:55:11,066 INFO [c.c.u.c.ComponentContext] (main:null)
Configuring
[jira] [Assigned] (CLOUDSTACK-7448) [Automation] test_delete_account and test_releaseIP failing in advanced zone
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Brett reassigned CLOUDSTACK-7448:
--
Assignee: Alex Brett (was: Ashutosk Kelkar)
[Automation] test_delete_account and test_releaseIP failing in advanced zone
Key: CLOUDSTACK-7448
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7448
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Automation
Affects Versions: 4.5.0
Reporter: Alex Brett
Assignee: Alex Brett
Fix For: 4.5.0
Advanced zone BVTs are currently seeing two test failures:
integration.smoke.test_network.TestDeleteAccount.test_delete_account
integration.smoke.test_network.TestReleaseIP.test_releaseIP
In both cases the failure is:
{noformat}
Execute cmd: createloadbalancerrule failed, due to: errorCode: 537,
errorText:The range specified, 22-22, conflicts with rule 55 which has 22-22
{noformat}
This appears to be due to this commit from CLOUDSTACK-4840, which changed
test_data.py to specify the publicport for the lbrule as 22 and not :
https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=134a868
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CLOUDSTACK-7448) [Automation] test_delete_account and test_releaseIP failing in advanced zone
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14115316#comment-14115316
]
Alex Brett commented on CLOUDSTACK-7448:
Review posted to https://reviews.apache.org/r/25187/
[Automation] test_delete_account and test_releaseIP failing in advanced zone
Key: CLOUDSTACK-7448
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7448
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Automation
Affects Versions: 4.5.0
Reporter: Alex Brett
Assignee: Alex Brett
Fix For: 4.5.0
Advanced zone BVTs are currently seeing two test failures:
integration.smoke.test_network.TestDeleteAccount.test_delete_account
integration.smoke.test_network.TestReleaseIP.test_releaseIP
In both cases the failure is:
{noformat}
Execute cmd: createloadbalancerrule failed, due to: errorCode: 537,
errorText:The range specified, 22-22, conflicts with rule 55 which has 22-22
{noformat}
This appears to be due to this commit from CLOUDSTACK-4840, which changed
test_data.py to specify the publicport for the lbrule as 22 and not :
https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=134a868
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (CLOUDSTACK-7455) Unable to connect to management server since SAML2 merge
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7455?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Brett updated CLOUDSTACK-7455:
---
Attachment: management-server.log
Unable to connect to management server since SAML2 merge
Key: CLOUDSTACK-7455
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7455
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Management Server
Affects Versions: 4.5.0
Reporter: Alex Brett
Priority: Blocker
Fix For: 4.5.0
Attachments: management-server.log
In builds that have the SAML2 merge in, while I can start the management
server, it appears not to fully startup, and doesn't give the UI or API.
management-server.log (attached) stops at:
{noformat}
2014-08-29 14:55:02,097 INFO [o.a.c.s.l.CloudStackExtendedLifeCycle]
(main:null) Starting CloudStack Components
2014-08-29 14:55:02,098 INFO [o.a.c.s.l.CloudStackExtendedLifeCycle]
(main:null) Done Starting CloudStack Components
2014-08-29 14:55:02,098 INFO [o.a.c.s.m.m.i.DefaultModuleDefinitionSet]
(main:null) Starting module [core]
2014-08-29 14:55:02,098 INFO [o.a.c.s.l.CloudStackExtendedLifeCycle]
(main:null) Starting CloudStack Components
2014-08-29 14:55:02,106 INFO [c.c.h.h.m.HypervManagerImpl] (main:null)
Cleanup mounted mount points used in previous session
2014-08-29 14:55:02,141 INFO [c.c.u.DatabaseIntegrityChecker] (main:null)
Grabbing lock to check for database integrity.
2014-08-29 14:55:02,143 INFO [c.c.u.DatabaseIntegrityChecker] (main:null)
Performing database integrity check
2014-08-29 14:55:02,144 DEBUG [c.c.u.DatabaseIntegrityChecker] (main:null) No
duplicate hosts with the same local storage found in database
2014-08-29 14:55:02,146 DEBUG [c.c.u.d.VersionDaoImpl] (main:null) Checking
to see if the database is at a version before it was the version table is
created
2014-08-29 14:55:02,150 INFO [c.c.c.ClusterManagerImpl] (main:null) Starting
Cluster manager, msid : 99326614648649
2014-08-29 14:55:02,155 INFO [c.c.c.ClusterManagerImpl] (main:null)
Management server 99326614648649, runId 1409324073632 is being started
2014-08-29 14:55:02,156 INFO [c.c.c.ClusterManagerImpl] (main:null)
Management server (host id : 1) is being started at 127.0.0.1:9090
2014-08-29 14:55:02,162 INFO [c.c.c.ClusterManagerImpl] (main:null) Cluster
manager was started successfully
2014-08-29 14:55:02,167 DEBUG [c.c.u.s.Script] (main:null) Executing:
/bin/bash -c /sbin/route | grep default
2014-08-29 14:55:02,183 DEBUG [c.c.u.s.Script] (main:null) Execution is
successful.
2014-08-29 14:55:02,185 WARN [c.c.c.ConfigurationManagerImpl] (main:null)
Management network CIDR is not configured originally. Set it default to
10.220.128.0/19
2014-08-29 14:55:02,190 WARN [o.a.c.alerts] (main:null) alertType:: 14 //
dataCenterId:: 0 // podId:: 0 // clusterId:: null // message:: Management
network CIDR is not configured originally. Set it default to 10.220.128.0/19
2014-08-29 14:55:02,215 INFO [c.c.h.HighAvailabilityManagerImpl]
(HA-Worker-0:null) Starting work
2014-08-29 14:55:02,224 INFO [c.c.h.HighAvailabilityManagerImpl]
(HA-Worker-3:null) Starting work
2014-08-29 14:55:02,224 INFO [c.c.h.HighAvailabilityManagerImpl]
(HA-Worker-4:null) Starting work
2014-08-29 14:55:02,218 INFO [c.c.h.HighAvailabilityManagerImpl]
(HA-Worker-2:null) Starting work
2014-08-29 14:55:02,218 INFO [c.c.h.HighAvailabilityManagerImpl]
(HA-Worker-1:null) Starting work
2014-08-29 14:55:02,290 DEBUG [c.c.n.l.LBHealthCheckManagerImpl] (main:null)
LB HealthCheckmanager is getting Started
2014-08-29 14:55:02,307 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl]
(NetworkStatsUpdater-1:ctx-5b259b22) Successfully updated aggregate network
stats
2014-08-29 14:55:11,061 INFO [c.c.u.c.ComponentContext] (main:null)
Configuring
com.cloud.bridge.persist.dao.CloudStackAccountDaoImpl_EnhancerByCloudStack_156f5045
2014-08-29 14:55:11,066 INFO [c.c.u.c.ComponentContext] (main:null)
Configuring
com.cloud.bridge.persist.dao.OfferingDaoImpl_EnhancerByCloudStack_aa79bf9f
2014-08-29 14:55:11,066 INFO [c.c.u.c.ComponentContext] (main:null)
Configuring
com.cloud.bridge.persist.dao.SMetaDaoImpl_EnhancerByCloudStack_c720af97
2014-08-29 14:55:11,066 INFO [c.c.u.c.ComponentContext] (main:null)
Configuring
com.cloud.bridge.persist.dao.MultipartMetaDaoImpl_EnhancerByCloudStack_ae893256
2014-08-29 14:55:11,067 INFO [c.c.u.c.ComponentContext] (main:null)
Configuring
com.cloud.bridge.persist.dao.UserCredentialsDaoImpl_EnhancerByCloudStack_68227ab6
2014-08-29 14:55:11,067 INFO [c.c.u.c.ComponentContext] (main:null)
Configuring
[jira] [Updated] (CLOUDSTACK-7455) Unable to connect to management server ?since SAML2 merge?
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7455?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Brett updated CLOUDSTACK-7455:
---
Summary: Unable to connect to management server ?since SAML2 merge? (was:
Unable to connect to management server since SAML2 merge)
Unable to connect to management server ?since SAML2 merge?
--
Key: CLOUDSTACK-7455
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7455
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Management Server
Affects Versions: 4.5.0
Reporter: Alex Brett
Priority: Blocker
Fix For: 4.5.0
Attachments: management-server.log
In builds that have the SAML2 merge in, while I can start the management
server, it appears not to fully startup, and doesn't give the UI or API.
management-server.log (attached) stops at:
{noformat}
2014-08-29 14:55:02,097 INFO [o.a.c.s.l.CloudStackExtendedLifeCycle]
(main:null) Starting CloudStack Components
2014-08-29 14:55:02,098 INFO [o.a.c.s.l.CloudStackExtendedLifeCycle]
(main:null) Done Starting CloudStack Components
2014-08-29 14:55:02,098 INFO [o.a.c.s.m.m.i.DefaultModuleDefinitionSet]
(main:null) Starting module [core]
2014-08-29 14:55:02,098 INFO [o.a.c.s.l.CloudStackExtendedLifeCycle]
(main:null) Starting CloudStack Components
2014-08-29 14:55:02,106 INFO [c.c.h.h.m.HypervManagerImpl] (main:null)
Cleanup mounted mount points used in previous session
2014-08-29 14:55:02,141 INFO [c.c.u.DatabaseIntegrityChecker] (main:null)
Grabbing lock to check for database integrity.
2014-08-29 14:55:02,143 INFO [c.c.u.DatabaseIntegrityChecker] (main:null)
Performing database integrity check
2014-08-29 14:55:02,144 DEBUG [c.c.u.DatabaseIntegrityChecker] (main:null) No
duplicate hosts with the same local storage found in database
2014-08-29 14:55:02,146 DEBUG [c.c.u.d.VersionDaoImpl] (main:null) Checking
to see if the database is at a version before it was the version table is
created
2014-08-29 14:55:02,150 INFO [c.c.c.ClusterManagerImpl] (main:null) Starting
Cluster manager, msid : 99326614648649
2014-08-29 14:55:02,155 INFO [c.c.c.ClusterManagerImpl] (main:null)
Management server 99326614648649, runId 1409324073632 is being started
2014-08-29 14:55:02,156 INFO [c.c.c.ClusterManagerImpl] (main:null)
Management server (host id : 1) is being started at 127.0.0.1:9090
2014-08-29 14:55:02,162 INFO [c.c.c.ClusterManagerImpl] (main:null) Cluster
manager was started successfully
2014-08-29 14:55:02,167 DEBUG [c.c.u.s.Script] (main:null) Executing:
/bin/bash -c /sbin/route | grep default
2014-08-29 14:55:02,183 DEBUG [c.c.u.s.Script] (main:null) Execution is
successful.
2014-08-29 14:55:02,185 WARN [c.c.c.ConfigurationManagerImpl] (main:null)
Management network CIDR is not configured originally. Set it default to
10.220.128.0/19
2014-08-29 14:55:02,190 WARN [o.a.c.alerts] (main:null) alertType:: 14 //
dataCenterId:: 0 // podId:: 0 // clusterId:: null // message:: Management
network CIDR is not configured originally. Set it default to 10.220.128.0/19
2014-08-29 14:55:02,215 INFO [c.c.h.HighAvailabilityManagerImpl]
(HA-Worker-0:null) Starting work
2014-08-29 14:55:02,224 INFO [c.c.h.HighAvailabilityManagerImpl]
(HA-Worker-3:null) Starting work
2014-08-29 14:55:02,224 INFO [c.c.h.HighAvailabilityManagerImpl]
(HA-Worker-4:null) Starting work
2014-08-29 14:55:02,218 INFO [c.c.h.HighAvailabilityManagerImpl]
(HA-Worker-2:null) Starting work
2014-08-29 14:55:02,218 INFO [c.c.h.HighAvailabilityManagerImpl]
(HA-Worker-1:null) Starting work
2014-08-29 14:55:02,290 DEBUG [c.c.n.l.LBHealthCheckManagerImpl] (main:null)
LB HealthCheckmanager is getting Started
2014-08-29 14:55:02,307 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl]
(NetworkStatsUpdater-1:ctx-5b259b22) Successfully updated aggregate network
stats
2014-08-29 14:55:11,061 INFO [c.c.u.c.ComponentContext] (main:null)
Configuring
com.cloud.bridge.persist.dao.CloudStackAccountDaoImpl_EnhancerByCloudStack_156f5045
2014-08-29 14:55:11,066 INFO [c.c.u.c.ComponentContext] (main:null)
Configuring
com.cloud.bridge.persist.dao.OfferingDaoImpl_EnhancerByCloudStack_aa79bf9f
2014-08-29 14:55:11,066 INFO [c.c.u.c.ComponentContext] (main:null)
Configuring
com.cloud.bridge.persist.dao.SMetaDaoImpl_EnhancerByCloudStack_c720af97
2014-08-29 14:55:11,066 INFO [c.c.u.c.ComponentContext] (main:null)
Configuring
com.cloud.bridge.persist.dao.MultipartMetaDaoImpl_EnhancerByCloudStack_ae893256
2014-08-29 14:55:11,067 INFO [c.c.u.c.ComponentContext] (main:null)
Configuring
[jira] [Created] (CLOUDSTACK-7455) Unable to connect to management server since SAML2 merge
Alex Brett created CLOUDSTACK-7455:
--
Summary: Unable to connect to management server since SAML2 merge
Key: CLOUDSTACK-7455
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7455
Project: CloudStack
Issue Type: Bug
Security Level: Public (Anyone can view this level - this is the default.)
Components: Management Server
Affects Versions: 4.5.0
Reporter: Alex Brett
Priority: Blocker
Fix For: 4.5.0
Attachments: management-server.log
In builds that have the SAML2 merge in, while I can start the management
server, it appears not to fully startup, and doesn't give the UI or API.
management-server.log (attached) stops at:
{noformat}
2014-08-29 14:55:02,097 INFO [o.a.c.s.l.CloudStackExtendedLifeCycle]
(main:null) Starting CloudStack Components
2014-08-29 14:55:02,098 INFO [o.a.c.s.l.CloudStackExtendedLifeCycle]
(main:null) Done Starting CloudStack Components
2014-08-29 14:55:02,098 INFO [o.a.c.s.m.m.i.DefaultModuleDefinitionSet]
(main:null) Starting module [core]
2014-08-29 14:55:02,098 INFO [o.a.c.s.l.CloudStackExtendedLifeCycle]
(main:null) Starting CloudStack Components
2014-08-29 14:55:02,106 INFO [c.c.h.h.m.HypervManagerImpl] (main:null) Cleanup
mounted mount points used in previous session
2014-08-29 14:55:02,141 INFO [c.c.u.DatabaseIntegrityChecker] (main:null)
Grabbing lock to check for database integrity.
2014-08-29 14:55:02,143 INFO [c.c.u.DatabaseIntegrityChecker] (main:null)
Performing database integrity check
2014-08-29 14:55:02,144 DEBUG [c.c.u.DatabaseIntegrityChecker] (main:null) No
duplicate hosts with the same local storage found in database
2014-08-29 14:55:02,146 DEBUG [c.c.u.d.VersionDaoImpl] (main:null) Checking to
see if the database is at a version before it was the version table is created
2014-08-29 14:55:02,150 INFO [c.c.c.ClusterManagerImpl] (main:null) Starting
Cluster manager, msid : 99326614648649
2014-08-29 14:55:02,155 INFO [c.c.c.ClusterManagerImpl] (main:null) Management
server 99326614648649, runId 1409324073632 is being started
2014-08-29 14:55:02,156 INFO [c.c.c.ClusterManagerImpl] (main:null) Management
server (host id : 1) is being started at 127.0.0.1:9090
2014-08-29 14:55:02,162 INFO [c.c.c.ClusterManagerImpl] (main:null) Cluster
manager was started successfully
2014-08-29 14:55:02,167 DEBUG [c.c.u.s.Script] (main:null) Executing: /bin/bash
-c /sbin/route | grep default
2014-08-29 14:55:02,183 DEBUG [c.c.u.s.Script] (main:null) Execution is
successful.
2014-08-29 14:55:02,185 WARN [c.c.c.ConfigurationManagerImpl] (main:null)
Management network CIDR is not configured originally. Set it default to
10.220.128.0/19
2014-08-29 14:55:02,190 WARN [o.a.c.alerts] (main:null) alertType:: 14 //
dataCenterId:: 0 // podId:: 0 // clusterId:: null // message:: Management
network CIDR is not configured originally. Set it default to 10.220.128.0/19
2014-08-29 14:55:02,215 INFO [c.c.h.HighAvailabilityManagerImpl]
(HA-Worker-0:null) Starting work
2014-08-29 14:55:02,224 INFO [c.c.h.HighAvailabilityManagerImpl]
(HA-Worker-3:null) Starting work
2014-08-29 14:55:02,224 INFO [c.c.h.HighAvailabilityManagerImpl]
(HA-Worker-4:null) Starting work
2014-08-29 14:55:02,218 INFO [c.c.h.HighAvailabilityManagerImpl]
(HA-Worker-2:null) Starting work
2014-08-29 14:55:02,218 INFO [c.c.h.HighAvailabilityManagerImpl]
(HA-Worker-1:null) Starting work
2014-08-29 14:55:02,290 DEBUG [c.c.n.l.LBHealthCheckManagerImpl] (main:null) LB
HealthCheckmanager is getting Started
2014-08-29 14:55:02,307 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl]
(NetworkStatsUpdater-1:ctx-5b259b22) Successfully updated aggregate network
stats
2014-08-29 14:55:11,061 INFO [c.c.u.c.ComponentContext] (main:null)
Configuring
com.cloud.bridge.persist.dao.CloudStackAccountDaoImpl_EnhancerByCloudStack_156f5045
2014-08-29 14:55:11,066 INFO [c.c.u.c.ComponentContext] (main:null)
Configuring
com.cloud.bridge.persist.dao.OfferingDaoImpl_EnhancerByCloudStack_aa79bf9f
2014-08-29 14:55:11,066 INFO [c.c.u.c.ComponentContext] (main:null)
Configuring
com.cloud.bridge.persist.dao.SMetaDaoImpl_EnhancerByCloudStack_c720af97
2014-08-29 14:55:11,066 INFO [c.c.u.c.ComponentContext] (main:null)
Configuring
com.cloud.bridge.persist.dao.MultipartMetaDaoImpl_EnhancerByCloudStack_ae893256
2014-08-29 14:55:11,067 INFO [c.c.u.c.ComponentContext] (main:null)
Configuring
com.cloud.bridge.persist.dao.UserCredentialsDaoImpl_EnhancerByCloudStack_68227ab6
2014-08-29 14:55:11,067 INFO [c.c.u.c.ComponentContext] (main:null)
Configuring
com.cloud.bridge.persist.dao.CloudStackConfigurationDaoImpl_EnhancerByCloudStack_d654c274
2014-08-29 14:55:11,067 INFO [c.c.u.c.ComponentContext] (main:null)
Configuring
com.cloud.bridge.persist.dao.BucketPolicyDaoImpl_EnhancerByCloudStack_2def2c39
2014-08-29 14:55:11,067 INFO
[jira] [Commented] (CLOUDSTACK-7455) Unable to connect to management server ?since SAML2 merge?
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14115438#comment-14115438
]
Alex Brett commented on CLOUDSTACK-7455:
Changes since the last good build I had
(d9531fb0de6e59bfbb0ec2082558e3879b6e1668) and the one in the ticket
(de6a3112b6b80952d1598acaa112ac50a3ef9d32) are:
{noformat}
commit de6a3112b6b80952d1598acaa112ac50a3ef9d32
Author: Mike Tutkowski mike.tutkow...@solidfire.com
Date: Thu Aug 28 23:19:04 2014 -0600
Update to volume-resize logic
commit 0e79cd1172e4340b957b0328354761e8a9305609
Author: Mike Tutkowski mike.tutkow...@solidfire.com
Date: Thu Aug 28 23:14:42 2014 -0600
Minor changes to SolidFire automation-related code
commit b693e61fe665c98177f85aedb0b4b228f269c0b9
Author: amoghvk amogh.vase...@citrix.com
Date: Thu Aug 28 17:47:08 2014 -0700
Temp fix for compilation issue, need to check what caused it
commit bea73e511e47e6543529d823f003a4dd998f7a49
Author: Jessica Wang jessicaw...@apache.org
Date: Thu Aug 28 16:17:00 2014 -0700
CLOUDSTACK-7454: UI zone wizard Hyper-V primary storage/secondary
storage move SMB Domain field to be on top of SMB Username field.
commit 81608afee1318b2a283707ac9e6481f4f6629cc2
Author: Rohit Yadav rohit.ya...@shapeblue.com
Date: Thu Aug 28 20:06:38 2014 +0200
SAML2LoginAPIAuthenticatorCmdTest: Add missing license
Signed-off-by: Rohit Yadav rohit.ya...@shapeblue.com
commit 97ed5ff636d922212e6ced91f6b1c41a9c9824d5
Merge: d9531fb 6eae9b8
Author: Rohit Yadav rohit.ya...@shapeblue.com
Date: Thu Aug 28 19:57:25 2014 +0200
Merge branch 'saml2'
Implements CLOUDSTACK-7083
Branch: saml2
Proposal: http://markmail.org/message/4ba4ztmqpud3l4uo
JIRA ticket: https://issues.apache.org/jira/browse/CLOUDSTACK-7083
FS: https://cwiki.apache.org/confluence/display/CLOUDSTACK/SAML+2.0+Plugin
Unit tests: Tests for each auth cmd class, SAMLUtils and SAMLAuthenticator,
fixes unit test for ApiServlet
Build status: clean build works with unit tests, testing using mvn3.0.5 and
jdk 1.7
commit 6eae9b859692417182103d06f5215fff11289942
Author: Rohit Yadav rohit.ya...@shapeblue.com
Date: Thu Aug 28 18:47:08 2014 +0200
saml: disable plugin by default and don't initiate if not enabled
Signed-off-by: Rohit Yadav rohit.ya...@shapeblue.com
commit aa02e30e9502d0bbb175a5367bce0282b035d5b6
Author: Rohit Yadav rohit.ya...@shapeblue.com
Date: Thu Aug 28 18:40:51 2014 +0200
saml: fix tests and update method signature that generates random certs
Signed-off-by: Rohit Yadav rohit.ya...@shapeblue.com
commit 249446dc521a273fe14b3e9e49b397a363ef577d
Author: Rohit Yadav rohit.ya...@shapeblue.com
Date: Thu Aug 28 18:40:05 2014 +0200
server: add config to enable/disable SAML SSO/SLO plugin
Signed-off-by: Rohit Yadav rohit.ya...@shapeblue.com
commit 5e7928bcb94be56fa3b9da68bc963d09bcace815
Author: Rohit Yadav rohit.ya...@shapeblue.com
Date: Thu Aug 28 18:39:28 2014 +0200
utils: fix static certificate value string in SAMLUtils
Signed-off-by: Rohit Yadav rohit.ya...@shapeblue.com
commit 0402f68b127df1ae7bdb0b299e462711db8d8030
Author: Rohit Yadav rohit.ya...@shapeblue.com
Date: Tue Aug 26 23:06:17 2014 +0200
SAML2LogoutAPIAuthenticatorCmd: if session is null, redirect to login page
If session is null, probably logout (local) happened removing the name id
and
session index which is needed for global logout. The limitation by design
is that
local logout will void possibility of global logout. To globally logout, one
use the SLO api which would logout locally as well.
Signed-off-by: Rohit Yadav rohit.ya...@shapeblue.com
commit de4e74b2b462773cb2866aa976e349e3f7151e9d
Author: Rohit Yadav rohit.ya...@shapeblue.com
Date: Mon Aug 25 17:32:13 2014 +0200
saml: Add unit tests for saml plugin
- Fixes signatures on plugin manager for ease of testing
- Fixes authenticator
- Adds unit testing for getType and authenticate methods for all cmd classes
- Adds SAMLAuthenticator test
Signed-off-by: Rohit Yadav rohit.ya...@shapeblue.com
commit 1ed532fb2011b2a6f203cfa000df5466d7924f25
Author: Rohit Yadav rohit.ya...@shapeblue.com
Date: Mon Aug 25 17:31:01 2014 +0200
SAMLUtils: add unit test for SAMLUtils and method to randomly generate X509
certs
Signed-off-by: Rohit Yadav rohit.ya...@shapeblue.com
commit 15fdc1744c42c0e70b3cde31ca4b163c7983bec2
Author: Rohit Yadav rohit.ya...@shapeblue.com
Date: Mon Aug 25 02:41:26 2014 +0200
SAML2LogoutAPIAuthenticatorCmd: check logout response and redirect to UI
Signed-off-by: Rohit Yadav rohit.ya...@shapeblue.com
commit 3bf387c8828fdd388155704fd64f9bcd84bc3e7a
Author: Rohit Yadav rohit.ya...@shapeblue.com
Date: Mon Aug 25 02:39:50 2014 +0200
SAMLUtils: Create new NameID using
[jira] [Comment Edited] (CLOUDSTACK-7455) Unable to connect to management server ?since SAML2 merge?
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14115438#comment-14115438
]
Alex Brett edited comment on CLOUDSTACK-7455 at 8/29/14 4:47 PM:
-
Changes since the last good build I had
(d9531fb0de6e59bfbb0ec2082558e3879b6e1668) -and the one in the ticket
(de6a3112b6b80952d1598acaa112ac50a3ef9d32)- and the first one I've seen the
problem on (b693e61fe665c98177f85aedb0b4b228f269c0b9) are:
{noformat}
commit b693e61fe665c98177f85aedb0b4b228f269c0b9
Author: amoghvk amogh.vase...@citrix.com
Date: Thu Aug 28 17:47:08 2014 -0700
Temp fix for compilation issue, need to check what caused it
commit bea73e511e47e6543529d823f003a4dd998f7a49
Author: Jessica Wang jessicaw...@apache.org
Date: Thu Aug 28 16:17:00 2014 -0700
CLOUDSTACK-7454: UI zone wizard Hyper-V primary storage/secondary
storage move SMB Domain field to be on top of SMB Username field.
commit 81608afee1318b2a283707ac9e6481f4f6629cc2
Author: Rohit Yadav rohit.ya...@shapeblue.com
Date: Thu Aug 28 20:06:38 2014 +0200
SAML2LoginAPIAuthenticatorCmdTest: Add missing license
Signed-off-by: Rohit Yadav rohit.ya...@shapeblue.com
commit 97ed5ff636d922212e6ced91f6b1c41a9c9824d5
Merge: d9531fb 6eae9b8
Author: Rohit Yadav rohit.ya...@shapeblue.com
Date: Thu Aug 28 19:57:25 2014 +0200
Merge branch 'saml2'
Implements CLOUDSTACK-7083
Branch: saml2
Proposal: http://markmail.org/message/4ba4ztmqpud3l4uo
JIRA ticket: https://issues.apache.org/jira/browse/CLOUDSTACK-7083
FS: https://cwiki.apache.org/confluence/display/CLOUDSTACK/SAML+2.0+Plugin
Unit tests: Tests for each auth cmd class, SAMLUtils and SAMLAuthenticator,
fixes unit test for ApiServlet
Build status: clean build works with unit tests, testing using mvn3.0.5 and
jdk 1.7
commit 6eae9b859692417182103d06f5215fff11289942
Author: Rohit Yadav rohit.ya...@shapeblue.com
Date: Thu Aug 28 18:47:08 2014 +0200
saml: disable plugin by default and don't initiate if not enabled
Signed-off-by: Rohit Yadav rohit.ya...@shapeblue.com
commit aa02e30e9502d0bbb175a5367bce0282b035d5b6
Author: Rohit Yadav rohit.ya...@shapeblue.com
Date: Thu Aug 28 18:40:51 2014 +0200
saml: fix tests and update method signature that generates random certs
Signed-off-by: Rohit Yadav rohit.ya...@shapeblue.com
commit 249446dc521a273fe14b3e9e49b397a363ef577d
Author: Rohit Yadav rohit.ya...@shapeblue.com
Date: Thu Aug 28 18:40:05 2014 +0200
server: add config to enable/disable SAML SSO/SLO plugin
Signed-off-by: Rohit Yadav rohit.ya...@shapeblue.com
commit 5e7928bcb94be56fa3b9da68bc963d09bcace815
Author: Rohit Yadav rohit.ya...@shapeblue.com
Date: Thu Aug 28 18:39:28 2014 +0200
utils: fix static certificate value string in SAMLUtils
Signed-off-by: Rohit Yadav rohit.ya...@shapeblue.com
commit 0402f68b127df1ae7bdb0b299e462711db8d8030
Author: Rohit Yadav rohit.ya...@shapeblue.com
Date: Tue Aug 26 23:06:17 2014 +0200
SAML2LogoutAPIAuthenticatorCmd: if session is null, redirect to login page
If session is null, probably logout (local) happened removing the name id
and
session index which is needed for global logout. The limitation by design
is that
local logout will void possibility of global logout. To globally logout, one
use the SLO api which would logout locally as well.
Signed-off-by: Rohit Yadav rohit.ya...@shapeblue.com
commit de4e74b2b462773cb2866aa976e349e3f7151e9d
Author: Rohit Yadav rohit.ya...@shapeblue.com
Date: Mon Aug 25 17:32:13 2014 +0200
saml: Add unit tests for saml plugin
- Fixes signatures on plugin manager for ease of testing
- Fixes authenticator
- Adds unit testing for getType and authenticate methods for all cmd classes
- Adds SAMLAuthenticator test
Signed-off-by: Rohit Yadav rohit.ya...@shapeblue.com
commit 1ed532fb2011b2a6f203cfa000df5466d7924f25
Author: Rohit Yadav rohit.ya...@shapeblue.com
Date: Mon Aug 25 17:31:01 2014 +0200
SAMLUtils: add unit test for SAMLUtils and method to randomly generate X509
certs
Signed-off-by: Rohit Yadav rohit.ya...@shapeblue.com
commit 15fdc1744c42c0e70b3cde31ca4b163c7983bec2
Author: Rohit Yadav rohit.ya...@shapeblue.com
Date: Mon Aug 25 02:41:26 2014 +0200
SAML2LogoutAPIAuthenticatorCmd: check logout response and redirect to UI
Signed-off-by: Rohit Yadav rohit.ya...@shapeblue.com
commit 3bf387c8828fdd388155704fd64f9bcd84bc3e7a
Author: Rohit Yadav rohit.ya...@shapeblue.com
Date: Mon Aug 25 02:39:50 2014 +0200
SAMLUtils: Create new NameID using passed nameId taking just id and session
idx
Signed-off-by: Rohit Yadav rohit.ya...@shapeblue.com
commit 8dc50927f9cfe994e2c2a828aedf77826f2599d9
Author: Rohit Yadav rohit.ya...@shapeblue.com
Date: Mon Aug 25 01:58:24
[jira] [Created] (CLOUDSTACK-7448) [Automation] test_delete_account and test_releaseIP failing in advanced zone
Alex Brett created CLOUDSTACK-7448:
--
Summary: [Automation] test_delete_account and test_releaseIP
failing in advanced zone
Key: CLOUDSTACK-7448
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7448
Project: CloudStack
Issue Type: Bug
Security Level: Public (Anyone can view this level - this is the default.)
Components: Automation
Affects Versions: 4.5.0
Reporter: Alex Brett
Assignee: Alex Brett
Fix For: 4.5.0
Advanced zone BVTs are currently seeing two test failures:
integration.smoke.test_network.TestDeleteAccount.test_delete_account
integration.smoke.test_network.TestReleaseIP.test_releaseIP
In both cases the failure is:
{noformat}
Execute cmd: createloadbalancerrule failed, due to: errorCode: 537,
errorText:The range specified, 22-22, conflicts with rule 55 which has 22-22
{noformat}
This appears to be due to this commit from CLOUDSTACK-4840, which changed
test_data.py to specify the publicport for the lbrule as 22 and not :
https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=134a868
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Assigned] (CLOUDSTACK-7448) [Automation] test_delete_account and test_releaseIP failing in advanced zone
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Brett reassigned CLOUDSTACK-7448:
--
Assignee: Ashutosk Kelkar (was: Alex Brett)
Assigning to Ashutosk as this appears to be related to the change in
CLOUDSTACK-4840
[Automation] test_delete_account and test_releaseIP failing in advanced zone
Key: CLOUDSTACK-7448
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7448
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Automation
Affects Versions: 4.5.0
Reporter: Alex Brett
Assignee: Ashutosk Kelkar
Fix For: 4.5.0
Advanced zone BVTs are currently seeing two test failures:
integration.smoke.test_network.TestDeleteAccount.test_delete_account
integration.smoke.test_network.TestReleaseIP.test_releaseIP
In both cases the failure is:
{noformat}
Execute cmd: createloadbalancerrule failed, due to: errorCode: 537,
errorText:The range specified, 22-22, conflicts with rule 55 which has 22-22
{noformat}
This appears to be due to this commit from CLOUDSTACK-4840, which changed
test_data.py to specify the publicport for the lbrule as 22 and not :
https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=134a868
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Resolved] (CLOUDSTACK-7363) [Automation] test_vmware_drs should skip on non-VMWare Hypervisors
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Brett resolved CLOUDSTACK-7363. Resolution: Fixed [Automation] test_vmware_drs should skip on non-VMWare Hypervisors -- Key: CLOUDSTACK-7363 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7363 Project: CloudStack Issue Type: Improvement Security Level: Public(Anyone can view this level - this is the default.) Components: Automation Reporter: Alex Brett Assignee: Alex Brett Fix For: 4.5.0 test/integration/component/test_vmware_drs.py is testing pure VMWare features, so is only valid if run on VMWare hosts, however it currently doesn't check this. It should test the hypervisor type and skip if a non-VMWare hypervisor is in use. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CLOUDSTACK-7363) [Automation] test_vmware_drs should skip on non-VMWare Hypervisors
Alex Brett created CLOUDSTACK-7363: -- Summary: [Automation] test_vmware_drs should skip on non-VMWare Hypervisors Key: CLOUDSTACK-7363 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7363 Project: CloudStack Issue Type: Improvement Security Level: Public (Anyone can view this level - this is the default.) Components: Automation Reporter: Alex Brett Assignee: Alex Brett Fix For: 4.5.0 test/integration/component/test_vmware_drs.py is testing pure VMWare features, so is only valid if run on VMWare hosts, however it currently doesn't check this. It should test the hypervisor type and skip if a non-VMWare hypervisor is in use. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (CLOUDSTACK-7306) [Automation] test_01_primary_storage_iscsi shouldn't run on KVM or HyperV
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Brett resolved CLOUDSTACK-7306. Resolution: Fixed Fix Version/s: 4.5.0 Fixed in commit 4c4d89f4d93c25e551dc094ebce1bc4c5ee5b16d [Automation] test_01_primary_storage_iscsi shouldn't run on KVM or HyperV - Key: CLOUDSTACK-7306 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7306 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.5.0 Reporter: Alex Brett Assignee: Alex Brett Fix For: 4.5.0 test_01_primary_storage_iscsi in test/integration/smoke/test_primary_storage.py currently attempts to set up an iSCSI primary storage pool, regardless of the type of host. For KVM, we only support iSCSI via shared mount point, and for Hyper-V we don't support it at all, so the test should skip in these cases. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CLOUDSTACK-7322) [Automation] Tag disruptive tests
Alex Brett created CLOUDSTACK-7322: -- Summary: [Automation] Tag disruptive tests Key: CLOUDSTACK-7322 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7322 Project: CloudStack Issue Type: Improvement Security Level: Public (Anyone can view this level - this is the default.) Components: Automation Reporter: Alex Brett Assignee: Alex Brett Fix For: 4.5.0 Some Marvin tests are disruptive, in that they cannot be run in parallel with other tests. An example being a test which reboots the secondary storage VM. Current automation systems which run tests in parallel have manually defined lists of these disruptive tests - we should instead put an attribute on them, in order that they can be picked up by standard nosetests attribute filtering, and then run in serial. I have a patch prepared which does this for known disruptive tests, and if accepted I will put some documentation on the wiki regarding how to identify tests which can't be run in parallel using nosetests. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CLOUDSTACK-7306) [Automation] test_01_primary_storage_iscsi shouldn't run on KVM or HyperV
Alex Brett created CLOUDSTACK-7306: -- Summary: [Automation] test_01_primary_storage_iscsi shouldn't run on KVM or HyperV Key: CLOUDSTACK-7306 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7306 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.5.0 Reporter: Alex Brett Assignee: Alex Brett test_01_primary_storage_iscsi in test/integration/smoke/test_primary_storage.py currently attempts to set up an iSCSI primary storage pool, regardless of the type of host. For KVM, we only support iSCSI via shared mount point, and for Hyper-V we don't support it at all, so the test should skip in these cases. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-7306) [Automation] test_01_primary_storage_iscsi shouldn't run on KVM or HyperV
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14092813#comment-14092813 ] Alex Brett commented on CLOUDSTACK-7306: Review request at https://reviews.apache.org/r/24550/ [Automation] test_01_primary_storage_iscsi shouldn't run on KVM or HyperV - Key: CLOUDSTACK-7306 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7306 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.5.0 Reporter: Alex Brett Assignee: Alex Brett test_01_primary_storage_iscsi in test/integration/smoke/test_primary_storage.py currently attempts to set up an iSCSI primary storage pool, regardless of the type of host. For KVM, we only support iSCSI via shared mount point, and for Hyper-V we don't support it at all, so the test should skip in these cases. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CLOUDSTACK-7307) [Automation] Ability to instruct nosetests not to run tests which require the simulator
Alex Brett created CLOUDSTACK-7307:
--
Summary: [Automation] Ability to instruct nosetests not to run
tests which require the simulator
Key: CLOUDSTACK-7307
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7307
Project: CloudStack
Issue Type: Improvement
Security Level: Public (Anyone can view this level - this is the default.)
Components: Automation
Affects Versions: 4.5.0
Reporter: Alex Brett
Assignee: Alex Brett
There are a number of Marvin tests which only work if using the simulator, an
example being test_deploy_vm_start_failure in
test/integration/smoke/misc/test_deploy_vm.py
When running tests via nosetests, we currently use a combination of the 'tags'
and 'required_hardware' attributes to select the right tests to run. For
example a KVM advanced zone BVT would run nosetests with {{-a tags=advanced}},
while a simulator test would do {{-a tags=advanced,required_hardware=false}}.
An attempt at solving this issue has been made by setting the required_hardware
attribute to simulator only, e.g.:
{noformat}
@attr(tags = ['advanced'], required_hardware=simulator only)
def test_deploy_vm_start_failure(self):
{noformat}
Unfortunately this is not practical from nosetests, as you can't do e.g. {{-a
required_hardware!='simulator only'}}, as nosetests does not support this. The
only way now to identify all appropriate tests would be to run it with
something like {{-a tags=advanced,!required_hardware -a
tags=advanced,required_hardware=false -a
tags=advanced,required_hardware=true}}. This is both confusing, and potentially
error prone as if someone adds an additional value to required_hardware,
nosetests will miss it.
In theory it is possible to achieve something using the {{-A}} argument to
nosetests, however experimenting here shows that it would still end up being
very confusing.
I believe the solution is to add a new attribute simulator_only, at which
point a typical advanced zone BVT could be run with just {{-a
tags=advanced,!simulator_only}}.
I've prepared a patch which adds this attribute.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CLOUDSTACK-7307) [Automation] Ability to instruct nosetests not to run tests which require the simulator
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14092848#comment-14092848
]
Alex Brett commented on CLOUDSTACK-7307:
Review request at https://reviews.apache.org/r/24552/
[Automation] Ability to instruct nosetests not to run tests which require the
simulator
---
Key: CLOUDSTACK-7307
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7307
Project: CloudStack
Issue Type: Improvement
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Automation
Affects Versions: 4.5.0
Reporter: Alex Brett
Assignee: Alex Brett
There are a number of Marvin tests which only work if using the simulator, an
example being test_deploy_vm_start_failure in
test/integration/smoke/misc/test_deploy_vm.py
When running tests via nosetests, we currently use a combination of the
'tags' and 'required_hardware' attributes to select the right tests to run.
For example a KVM advanced zone BVT would run nosetests with {{-a
tags=advanced}}, while a simulator test would do {{-a
tags=advanced,required_hardware=false}}.
An attempt at solving this issue has been made by setting the
required_hardware attribute to simulator only, e.g.:
{noformat}
@attr(tags = ['advanced'], required_hardware=simulator only)
def test_deploy_vm_start_failure(self):
{noformat}
Unfortunately this is not practical from nosetests, as you can't do e.g. {{-a
required_hardware!='simulator only'}}, as nosetests does not support this.
The only way now to identify all appropriate tests would be to run it with
something like {{-a tags=advanced,!required_hardware -a
tags=advanced,required_hardware=false -a
tags=advanced,required_hardware=true}}. This is both confusing, and
potentially error prone as if someone adds an additional value to
required_hardware, nosetests will miss it.
In theory it is possible to achieve something using the {{-A}} argument to
nosetests, however experimenting here shows that it would still end up being
very confusing.
I believe the solution is to add a new attribute simulator_only, at which
point a typical advanced zone BVT could be run with just {{-a
tags=advanced,!simulator_only}}.
I've prepared a patch which adds this attribute.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CLOUDSTACK-7173) Resizing of data volume is throwing java NPE
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14077663#comment-14077663
]
Alex Brett commented on CLOUDSTACK-7173:
Looking in the code, there's a few variables here that are Long objects rather
than a long primitive, yet have getters that return long primitives. The
problem we're hitting here is something is calling getNewMinIops(), which is
trying to cast a null Long value to a long, thus raising an NPE.
The call being made here is to provide it to something that is expecting a Long
object, so I think the fix is as simple as changing the getters to return a
Long rather than a long. I'll put a patch together that does this...
Resizing of data volume is throwing java NPE
Key: CLOUDSTACK-7173
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7173
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Volumes
Affects Versions: 4.5.0
Reporter: shweta agarwal
Priority: Critical
Fix For: 4.5.0
Attachments: log.tar.gz
Repro steps :
1. Create a Vm with data disk
2 . try to resize the data disk
Bug :
Resize will fail Ms log shows :
2014-07-23 05:34:53,366 ERROR [c.c.v.VmWorkJobDispatcher]
(Work-Job-Executor-5:ctx-2f1038c6 job-300/job-301) Unable to complete
AsyncJobVO {id:301, userId: 2, accountId: 2, instanceType: null, instanceId:
null, cmd: com.cloud.storage.VmWorkResizeVolume, cmdInfo:
rO0ABXNyACRjb20uY2xvdWQuc3RvcmFnZS5WbVdvcmtSZXNpemVWb2x1bWVU03zH0Fe-ggIAB0oAC2N1cnJlbnRTaXplSgAHbmV3U2l6ZVoACHNocmlua09rSgAIdm9sdW1lSWRMAApuZXdNYXhJb3BzdAAQTGphdmEvbGFuZy9Mb25nO0wACm5ld01pbklvcHNxAH4AAUwAFG5ld1NlcnZpY2VPZmZlcmluZ0lkcQB-AAF4cgATY29tLmNsb3VkLnZtLlZtV29ya5-ZtlbwJWdrAgAESgAJYWNjb3VudElkSgAGdXNlcklkSgAEdm1JZEwAC2hhbmRsZXJOYW1ldAASTGphdmEvbGFuZy9TdHJpbmc7eHAAAgACACZ0ABRWb2x1bWVBcGlTZXJ2aWNlSW1wbAFABQAAACtwcHNyAA5qYXZhLmxhbmcuTG9uZzuL5JDMjyPfAgABSgAFdmFsdWV4cgAQamF2YS5sYW5nLk51bWJlcoaslR0LlOCLAgAAeHAABA,
cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
null, initMsid: 233845177509765, completeMsid: null, lastUpdated: null,
lastPolled: null, created: Wed Jul 23 05:34:53 EDT 2014}, job origin:300
java.lang.NullPointerException
at
com.cloud.storage.VmWorkResizeVolume.getNewMinIops(VmWorkResizeVolume.java:59)
at
com.cloud.storage.VolumeApiServiceImpl.orchestrateResizeVolume(VolumeApiServiceImpl.java:2630)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at
com.cloud.vm.VmWorkJobHandlerProxy.handleVmWorkJob(VmWorkJobHandlerProxy.java:107)
at
com.cloud.storage.VolumeApiServiceImpl.handleVmWorkJob(VolumeApiServiceImpl.java:2654)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
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 $Proxy183.handleVmWorkJob(Unknown Source)
at
com.cloud.vm.VmWorkJobDispatcher.runJob(VmWorkJobDispatcher.java:102)
at
org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:507)
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
[jira] [Commented] (CLOUDSTACK-7173) Resizing of data volume is throwing java NPE
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14077683#comment-14077683
]
Alex Brett commented on CLOUDSTACK-7173:
Review posted at https://reviews.apache.org/r/24050/
Resizing of data volume is throwing java NPE
Key: CLOUDSTACK-7173
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7173
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Volumes
Affects Versions: 4.5.0
Reporter: shweta agarwal
Priority: Critical
Fix For: 4.5.0
Attachments: log.tar.gz
Repro steps :
1. Create a Vm with data disk
2 . try to resize the data disk
Bug :
Resize will fail Ms log shows :
2014-07-23 05:34:53,366 ERROR [c.c.v.VmWorkJobDispatcher]
(Work-Job-Executor-5:ctx-2f1038c6 job-300/job-301) Unable to complete
AsyncJobVO {id:301, userId: 2, accountId: 2, instanceType: null, instanceId:
null, cmd: com.cloud.storage.VmWorkResizeVolume, cmdInfo:
rO0ABXNyACRjb20uY2xvdWQuc3RvcmFnZS5WbVdvcmtSZXNpemVWb2x1bWVU03zH0Fe-ggIAB0oAC2N1cnJlbnRTaXplSgAHbmV3U2l6ZVoACHNocmlua09rSgAIdm9sdW1lSWRMAApuZXdNYXhJb3BzdAAQTGphdmEvbGFuZy9Mb25nO0wACm5ld01pbklvcHNxAH4AAUwAFG5ld1NlcnZpY2VPZmZlcmluZ0lkcQB-AAF4cgATY29tLmNsb3VkLnZtLlZtV29ya5-ZtlbwJWdrAgAESgAJYWNjb3VudElkSgAGdXNlcklkSgAEdm1JZEwAC2hhbmRsZXJOYW1ldAASTGphdmEvbGFuZy9TdHJpbmc7eHAAAgACACZ0ABRWb2x1bWVBcGlTZXJ2aWNlSW1wbAFABQAAACtwcHNyAA5qYXZhLmxhbmcuTG9uZzuL5JDMjyPfAgABSgAFdmFsdWV4cgAQamF2YS5sYW5nLk51bWJlcoaslR0LlOCLAgAAeHAABA,
cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
null, initMsid: 233845177509765, completeMsid: null, lastUpdated: null,
lastPolled: null, created: Wed Jul 23 05:34:53 EDT 2014}, job origin:300
java.lang.NullPointerException
at
com.cloud.storage.VmWorkResizeVolume.getNewMinIops(VmWorkResizeVolume.java:59)
at
com.cloud.storage.VolumeApiServiceImpl.orchestrateResizeVolume(VolumeApiServiceImpl.java:2630)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at
com.cloud.vm.VmWorkJobHandlerProxy.handleVmWorkJob(VmWorkJobHandlerProxy.java:107)
at
com.cloud.storage.VolumeApiServiceImpl.handleVmWorkJob(VolumeApiServiceImpl.java:2654)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
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 $Proxy183.handleVmWorkJob(Unknown Source)
at
com.cloud.vm.VmWorkJobDispatcher.runJob(VmWorkJobDispatcher.java:102)
at
org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:507)
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:464)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at
[jira] [Commented] (CLOUDSTACK-7173) Resizing of data volume is throwing java NPE
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14076283#comment-14076283
]
Alex Brett commented on CLOUDSTACK-7173:
This is causing automation failures on KVM, specifically:
integration.smoke.test_volumes.TestVolumes.test_07_resize_fail
integration.smoke.test_volumes.TestVolumes.test_08_resize_volume
Resizing of data volume is throwing java NPE
Key: CLOUDSTACK-7173
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7173
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Volumes
Affects Versions: 4.5.0
Reporter: shweta agarwal
Priority: Critical
Fix For: 4.5.0
Attachments: log.tar.gz
Repro steps :
1. Create a Vm with data disk
2 . try to resize the data disk
Bug :
Resize will fail Ms log shows :
2014-07-23 05:34:53,366 ERROR [c.c.v.VmWorkJobDispatcher]
(Work-Job-Executor-5:ctx-2f1038c6 job-300/job-301) Unable to complete
AsyncJobVO {id:301, userId: 2, accountId: 2, instanceType: null, instanceId:
null, cmd: com.cloud.storage.VmWorkResizeVolume, cmdInfo:
rO0ABXNyACRjb20uY2xvdWQuc3RvcmFnZS5WbVdvcmtSZXNpemVWb2x1bWVU03zH0Fe-ggIAB0oAC2N1cnJlbnRTaXplSgAHbmV3U2l6ZVoACHNocmlua09rSgAIdm9sdW1lSWRMAApuZXdNYXhJb3BzdAAQTGphdmEvbGFuZy9Mb25nO0wACm5ld01pbklvcHNxAH4AAUwAFG5ld1NlcnZpY2VPZmZlcmluZ0lkcQB-AAF4cgATY29tLmNsb3VkLnZtLlZtV29ya5-ZtlbwJWdrAgAESgAJYWNjb3VudElkSgAGdXNlcklkSgAEdm1JZEwAC2hhbmRsZXJOYW1ldAASTGphdmEvbGFuZy9TdHJpbmc7eHAAAgACACZ0ABRWb2x1bWVBcGlTZXJ2aWNlSW1wbAFABQAAACtwcHNyAA5qYXZhLmxhbmcuTG9uZzuL5JDMjyPfAgABSgAFdmFsdWV4cgAQamF2YS5sYW5nLk51bWJlcoaslR0LlOCLAgAAeHAABA,
cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
null, initMsid: 233845177509765, completeMsid: null, lastUpdated: null,
lastPolled: null, created: Wed Jul 23 05:34:53 EDT 2014}, job origin:300
java.lang.NullPointerException
at
com.cloud.storage.VmWorkResizeVolume.getNewMinIops(VmWorkResizeVolume.java:59)
at
com.cloud.storage.VolumeApiServiceImpl.orchestrateResizeVolume(VolumeApiServiceImpl.java:2630)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at
com.cloud.vm.VmWorkJobHandlerProxy.handleVmWorkJob(VmWorkJobHandlerProxy.java:107)
at
com.cloud.storage.VolumeApiServiceImpl.handleVmWorkJob(VolumeApiServiceImpl.java:2654)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
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 $Proxy183.handleVmWorkJob(Unknown Source)
at
com.cloud.vm.VmWorkJobDispatcher.runJob(VmWorkJobDispatcher.java:102)
at
org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:507)
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:464)
at
[jira] [Updated] (CLOUDSTACK-7194) deployvirtualmachine command hypervisor argument inconsistent
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Brett updated CLOUDSTACK-7194:
---
Affects Version/s: 4.5.0
deployvirtualmachine command hypervisor argument inconsistent
-
Key: CLOUDSTACK-7194
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7194
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: API
Affects Versions: 4.5.0
Environment: Observed running basic BVT against KVM hosts
Reporter: Alex Brett
The deployvirtualmachine API command takes a hypervisor argument. When used
with an ISO, this argument has an effect and restricts which type of
hypervisor the instance gets deployed to.
When used with a template however, it is the hypervisor type of the template
that matters. As such you can call deployvirtualmachine giving it a
hypervisor argument of XenServer, but a template that is deployed against a
KVM host, and the resulting instance will be running on KVM. In fact you can
even give it an argument of XenServer when you don't have any XenServer
hosts, and it will still work properly.
There is however some validation performed on the hypervisor argument - for
example if you attempt to deploy a virtual machine from a KVM based template,
specifying a hypervisor type of XenServer, and attempt to specify a
rootdisksize override (as in the integration.smoke.test_deploy_vm_root_resize
automated tests), you get this error back:
{noformat}
Hypervisor XenServer does not support rootdisksize override
{noformat}
This is very inconsistent - my suggestion to make this more sensible
therefore would be to do one of the following:
* Validate the hypervisor argument against the hypervisor of the template,
and return an error if they differ
* Ignore (or perhaps don't accept) the hypervisor argument when deploying
from a template, and ensure all validation etc is performed using the
hypervisor parameter of the template
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (CLOUDSTACK-7194) deployvirtualmachine command hypervisor argument inconsistent
Alex Brett created CLOUDSTACK-7194:
--
Summary: deployvirtualmachine command hypervisor argument
inconsistent
Key: CLOUDSTACK-7194
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7194
Project: CloudStack
Issue Type: Bug
Security Level: Public (Anyone can view this level - this is the default.)
Components: API
Environment: Observed running basic BVT against KVM hosts
Reporter: Alex Brett
The deployvirtualmachine API command takes a hypervisor argument. When used
with an ISO, this argument has an effect and restricts which type of hypervisor
the instance gets deployed to.
When used with a template however, it is the hypervisor type of the template
that matters. As such you can call deployvirtualmachine giving it a hypervisor
argument of XenServer, but a template that is deployed against a KVM host,
and the resulting instance will be running on KVM. In fact you can even give it
an argument of XenServer when you don't have any XenServer hosts, and it will
still work properly.
There is however some validation performed on the hypervisor argument - for
example if you attempt to deploy a virtual machine from a KVM based template,
specifying a hypervisor type of XenServer, and attempt to specify a
rootdisksize override (as in the integration.smoke.test_deploy_vm_root_resize
automated tests), you get this error back:
{noformat}
Hypervisor XenServer does not support rootdisksize override
{noformat}
This is very inconsistent - my suggestion to make this more sensible therefore
would be to do one of the following:
* Validate the hypervisor argument against the hypervisor of the template, and
return an error if they differ
* Ignore (or perhaps don't accept) the hypervisor argument when deploying from
a template, and ensure all validation etc is performed using the hypervisor
parameter of the template
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CLOUDSTACK-7170) [Automation] Failed to add KVM agent with master
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14071627#comment-14071627
]
Alex Brett commented on CLOUDSTACK-7170:
I'm seeing the same problem, I note in the logs I have I can see a couple of
connection attempts from the agent being closed, with some SSL warnings, e.g.:
{noformat}
2014-07-23 10:36:39,107 WARN [c.c.u.n.Link] (AgentManager-Selector:null) SSL:
Fail to find the generated keystore. Loading fail-safe one to continue.
2014-07-23 10:36:39,452 INFO [c.c.a.m.AgentManagerImpl]
(AgentManager-Handler-2:null) Connection from /10.220.163.38 closed but no
cleanup was done.
{noformat}
[Automation] Failed to add KVM agent with master
--
Key: CLOUDSTACK-7170
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7170
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: KVM
Affects Versions: 4.5.0
Environment: KVM - RHEL 6.3
Master
Reporter: Rayees Namathponnan
Priority: Blocker
Fix For: 4.5.0
Attachments: July_23_KVM.rar
This issue observed in automation setup, failed add KVM agent
Might be regressed after
https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=commit;h=173909e99d85cfcc85b017bc426950f9f16fddf0
MS log
---
2014-07-23 00:49:18,307 WARN [c.c.r.ResourceManagerImpl]
(catalina-exec-8:ctx-9df22e36 ctx-c5a4207e ctx-3d7179b3) Unable to find the
server resources at http://10.223.50.66
2014-07-23 00:49:18,310 INFO [c.c.u.e.CSExceptionErrorCode]
(catalina-exec-8:ctx-9df22e36 ctx-c5a4207e ctx-3d7179b3) Could not find
exception: com.cloud.exception.DiscoveryException in error code list for
exceptions
2014-07-23 00:49:18,310 WARN [o.a.c.a.c.a.h.AddHostCmd]
(catalina-exec-8:ctx-9df22e36 ctx-c5a4207e ctx-3d7179b3) Exception:
com.cloud.exception.DiscoveryException: Unable to add the host
at
com.cloud.resource.ResourceManagerImpl.discoverHostsFull(ResourceManagerImpl.java:790)
at
com.cloud.resource.ResourceManagerImpl.discoverHosts(ResourceManagerImpl.java:585)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
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.$Proxy148.discoverHosts(Unknown Source)
at
org.apache.cloudstack.api.command.admin.host.AddHostCmd.execute(AddHostCmd.java:142)
at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:141)
at com.cloud.api.ApiServer.queueCommand(ApiServer.java:694)
at com.cloud.api.ApiServer.handleRequest(ApiServer.java:517)
at
com.cloud.api.ApiServlet.processRequestInContext(ApiServlet.java:317)
at com.cloud.api.ApiServlet$1.run(ApiServlet.java:118)
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 com.cloud.api.ApiServlet.processRequest(ApiServlet.java:115)
at com.cloud.api.ApiServlet.doGet(ApiServlet.java:77)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:617)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at
[jira] [Commented] (CLOUDSTACK-7170) [Automation] Failed to add KVM agent with master
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14071629#comment-14071629
]
Alex Brett commented on CLOUDSTACK-7170:
This may also be affecting communication from the system VMs to the management
server, as on a XenServer setup they aren't communicating, and similar log
entries are observed:
{noformat}
2014-07-23 10:51:59,591 WARN [c.c.u.n.Link] (AgentManager-Selector:null) SSL:
Fail to find the generated keystore. Loading fail-safe one to continue.
2014-07-23 10:52:01,317 WARN [c.c.u.n.Link] (AgentManager-Selector:null) SSL:
Fail to find the generated keystore. Loading fail-safe one to continue.
2014-07-23 10:52:01,494 INFO [c.c.a.m.AgentManagerImpl]
(AgentManager-Handler-3:null) Connection from /10.220.165.112 closed but no
cleanup was done.
2014-07-23 10:52:01,497 INFO [c.c.a.m.AgentManagerImpl]
(AgentManager-Handler-4:null) Connection from /10.220.165.113 closed but no
cleanup was done.
{noformat}
[Automation] Failed to add KVM agent with master
--
Key: CLOUDSTACK-7170
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7170
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: KVM
Affects Versions: 4.5.0
Environment: KVM - RHEL 6.3
Master
Reporter: Rayees Namathponnan
Priority: Blocker
Fix For: 4.5.0
Attachments: July_23_KVM.rar
This issue observed in automation setup, failed add KVM agent
Might be regressed after
https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=commit;h=173909e99d85cfcc85b017bc426950f9f16fddf0
MS log
---
2014-07-23 00:49:18,307 WARN [c.c.r.ResourceManagerImpl]
(catalina-exec-8:ctx-9df22e36 ctx-c5a4207e ctx-3d7179b3) Unable to find the
server resources at http://10.223.50.66
2014-07-23 00:49:18,310 INFO [c.c.u.e.CSExceptionErrorCode]
(catalina-exec-8:ctx-9df22e36 ctx-c5a4207e ctx-3d7179b3) Could not find
exception: com.cloud.exception.DiscoveryException in error code list for
exceptions
2014-07-23 00:49:18,310 WARN [o.a.c.a.c.a.h.AddHostCmd]
(catalina-exec-8:ctx-9df22e36 ctx-c5a4207e ctx-3d7179b3) Exception:
com.cloud.exception.DiscoveryException: Unable to add the host
at
com.cloud.resource.ResourceManagerImpl.discoverHostsFull(ResourceManagerImpl.java:790)
at
com.cloud.resource.ResourceManagerImpl.discoverHosts(ResourceManagerImpl.java:585)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
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.$Proxy148.discoverHosts(Unknown Source)
at
org.apache.cloudstack.api.command.admin.host.AddHostCmd.execute(AddHostCmd.java:142)
at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:141)
at com.cloud.api.ApiServer.queueCommand(ApiServer.java:694)
at com.cloud.api.ApiServer.handleRequest(ApiServer.java:517)
at
com.cloud.api.ApiServlet.processRequestInContext(ApiServlet.java:317)
at com.cloud.api.ApiServlet$1.run(ApiServlet.java:118)
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 com.cloud.api.ApiServlet.processRequest(ApiServlet.java:115)
at com.cloud.api.ApiServlet.doGet(ApiServlet.java:77)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:617)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
[jira] [Commented] (CLOUDSTACK-7170) [Automation] Failed to add KVM agent with master
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14071632#comment-14071632
]
Alex Brett commented on CLOUDSTACK-7170:
Changes that I can see between a working build and a failing one (I'll see if I
can narrow this down a bit):
{noformat}
commit d3af2dbecacf260acda9f84a51a42838cc0f798c
Author: Will Stevens wstev...@cloudops.com
Date: Tue Jul 22 17:28:01 2014 -0400
CLOUDSTACK-6886 - Fixed the issue created by the SSL feature with the SDX:
commit 173909e99d85cfcc85b017bc426950f9f16fddf0
Author: Wido den Hollander w...@widodh.nl
Date: Tue Jul 22 22:28:34 2014 +0200
CLOUDSTACK-6181: Allow RBD volumes to be resized
We don't need an external script to investigate the format of the RBD
volume,
we only have to ask Libvirt to resize the volume and that will ask librbd to
do so.
commit 2c0765195a4a01ee51973c48d0561261d4fb01c6
Author: Gaurav Aradhye gaurav.arad...@clogeny.com
Date: Tue Jul 22 04:23:10 2014 -0400
CLOUDSTACK-7147: Resolving test script issue in test_ip_reservation.py
commit 613eb12104af5c27935091127a1a19941f96e336
Author: Ashutosh K ashut...@clogeny.com
Date: Tue Jul 22 04:57:46 2014 -0400
CLOUDSTACK-7044: Portable IP Range test case changes - reading portable ip
range from test_data.py file
commit 981becc73585c9a789b377e18af623c325b0bc7f
Author: Ashutosh K ashut...@clogeny.com
Date: Tue Jul 22 05:05:47 2014 -0400
CLOUDSTACK-7148: Adding missing list method
commit 45888e214c949d1e48d800339b366c42a7990641
Author: Ashutosh K ashut...@clogeny.com
Date: Mon Jul 21 03:15:07 2014 -0400
CLOUDSTACK-7137: Resolving cleanup issue in
test_escalations_securitygroups.py
commit 3b32732459730bfd4848678c95c27e2eb653cc04
Author: Min Chen min.c...@citrix.com
Date: Tue Jul 22 09:47:27 2014 -0700
CLOUDSTACK-7162:queryAsyncJobResult api does not return jobinstanceid.
commit 1d2124dcbf48d15d23ddbdea23a29f0ab21be6f3
Author: Hugo Trippaers htrippa...@schubergphilis.com
Date: Tue Jul 22 17:43:49 2014 +0200
Fix NPE reported on IRC, provide the user an informative error message
commit 4523490d44160b054de9e943f72db1d0ce06054a
Author: Santhosh Edukulla santhosh.eduku...@gmail.com
Date: Mon Jul 21 20:49:03 2014 +0530
Fixed Coverity Issues reported
Signed-off-by: Santhosh Edukulla santhosh.eduku...@gmail.com
commit 7d3f381d9476fec5dc7ba1cada8294bcb2df0ffa
Author: Kishan Kavala kis...@apache.org
Date: Tue Jul 22 17:50:16 2014 +0530
Set mapped device path while detaching rbd disk
commit 4bf321bd034f179c1ac9dda111fbb5e1034fadd0
Author: Hugo Trippaers htrippa...@schubergphilis.com
Date: Tue Jul 22 13:11:46 2014 +0200
Fix equality check using != on objects
Cleanup in the code, removing dead code
commit 28333664159dd618682b0b07352782af641d295d
Author: Hugo Trippaers htrippa...@schubergphilis.com
Date: Tue Jul 22 13:11:11 2014 +0200
Remove dead code
commit 70e68be4f32538b7965e916cce1f51334fadbbd5
Author: Hugo Trippaers htrippa...@schubergphilis.com
Date: Tue Jul 22 13:10:26 2014 +0200
Fix string encoding problem reported by coverity
commit 493fd170543658ac7602e230a336985c59e8e1a1
Author: Likitha Shetty likitha.she...@citrix.com
Date: Mon Jul 14 15:04:37 2014 +0530
CLOUDSTACK-7152. Attaching datadisk to VMs that have VM snapshot throws
'Unexpected exception'.
Like with other API commands, ensure input parameter validation for
AttachVolume happens outside the job queue.
commit b3e4c6d6dc9bf57aa880ab100a76027b2a12053d
Author: Likitha Shetty likitha.she...@citrix.com
Date: Tue Jul 22 09:48:20 2014 +0530
CLOUDSTACK-7150. [VMware] Global config 'vm.instancename' is not honored.
If global config 'vm.instancename' is set to true, VM name in vCenter
should be 'instance_name-vm_hostname'.
commit 4596ae9aac81ecec2c1de95950da431e7490b95d
Author: sanjeev sanj...@apache.org
Date: Thu Jul 17 17:19:04 2014 +0530
Changed delete method signature inside VirtualMachine class. From 4.3
onwards vm destroy has expunge parameter to expunge the vm immediately.
Signed-off-by: sanjeev sanj...@apache.org
Signed-off-by: Santhosh Edukulla santhosh.eduku...@gmail.com
commit 88f35179ef90dc4f7696b6fe2e8ee7ca4d00586c
Author: Girish Shilamkar gir...@clogeny.com
Date: Mon Jul 21 19:10:34 2014 -0400
Revert CLOUDSTACK-7130: Adding BugId to failed test cases
This reverts commit 24da72f37395a6bb612ea1d073db0155289cf000.
{noformat}
[Automation] Failed to add KVM agent with master
--
Key: CLOUDSTACK-7170
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7170
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: KVM
Affects Versions:
[jira] [Commented] (CLOUDSTACK-7168) [Automation]Management Server connection with System VMs (SSVM and CPVM) gets closed and System VMs cannot perform their operations
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14071633#comment-14071633 ] Alex Brett commented on CLOUDSTACK-7168: This may also be the cause of CLOUDSTACK-7170 [Automation]Management Server connection with System VMs (SSVM and CPVM) gets closed and System VMs cannot perform their operations --- Key: CLOUDSTACK-7168 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7168 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Management Server, XenServer Affects Versions: 4.5.0 Reporter: Chandan Purushothama Assignee: Amogh Vasekar Priority: Blocker Fix For: 4.5.0 Attachments: management-server.zip After deployment of 4.5 Cloudstack setup. System VMs get deployed successfully. But the connection between management server and system vms gets closed. This happened on both the zones on my setup. Management Server Log: 2014-07-22 16:21:45,155 INFO [c.c.a.m.AgentManagerImpl] (AgentManager-Handler-7:null) Connection from /10.223.57.88 closed but no cleanup was done. 2014-07-22 16:21:48,265 DEBUG [c.c.a.ApiServlet] (catalina-exec-10:ctx-b0a5c72a) ===START=== 10.216.51.74 -- GET command=listVolumesresponse=jsonsessionkey=7PVfBDi0Ka28miYXWJKSUv2%2Fiqg%3DlistAll=truepage=1pagesize=20_=1406071442911 2014-07-22 16:21:48,305 DEBUG [c.c.a.ApiServlet] (catalina-exec-10:ctx-b0a5c72a ctx-0cacdb59) ===END=== 10.216.51.74 -- GET command=listVolumesresponse=jsonsessionkey=7PVfBDi0Ka28miYXWJKSUv2%2Fiqg%3DlistAll=truepage=1pagesize=20_=1406071442911 2014-07-22 16:21:49,882 DEBUG [c.c.a.ApiServlet] (catalina-exec-11:ctx-45196a92) ===START=== 10.216.51.74 -- GET command=listVirtualMachinesresponse=jsonsessionkey=7PVfBDi0Ka28miYXWJKSUv2%2Fiqg%3DlistAll=truepage=1pagesize=20_=1406071444564 2014-07-22 16:21:49,920 DEBUG [c.c.a.ApiServlet] (catalina-exec-11:ctx-45196a92 ctx-5eb663f6) ===END=== 10.216.51.74 -- GET command=listVirtualMachinesresponse=jsonsessionkey=7PVfBDi0Ka28miYXWJKSUv2%2Fiqg%3DlistAll=truepage=1pagesize=20_=1406071444564 2014-07-22 16:21:50,656 INFO [c.c.a.m.AgentManagerImpl] (AgentManager-Handler-9:null) Connection from /10.223.57.86 closed but no cleanup was done. == Bug Impact: == 1. No Console view (Management Server connection to CPVM gets closed) 2. No Template download (Management Server connection to SSVM gets closed) -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Comment Edited] (CLOUDSTACK-7170) [Automation] Failed to add KVM agent with master
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14071632#comment-14071632
]
Alex Brett edited comment on CLOUDSTACK-7170 at 7/23/14 12:03 PM:
--
Changes that I can see between a working build and a failing one (I'll see if I
can narrow this down a bit):
{noformat}
commit d3af2dbecacf260acda9f84a51a42838cc0f798c
Author: Will Stevens wstev...@cloudops.com
Date: Tue Jul 22 17:28:01 2014 -0400
CLOUDSTACK-6886 - Fixed the issue created by the SSL feature with the SDX:
commit 173909e99d85cfcc85b017bc426950f9f16fddf0
Author: Wido den Hollander w...@widodh.nl
Date: Tue Jul 22 22:28:34 2014 +0200
CLOUDSTACK-6181: Allow RBD volumes to be resized
We don't need an external script to investigate the format of the RBD
volume,
we only have to ask Libvirt to resize the volume and that will ask librbd to
do so.
commit 2c0765195a4a01ee51973c48d0561261d4fb01c6
Author: Gaurav Aradhye gaurav.arad...@clogeny.com
Date: Tue Jul 22 04:23:10 2014 -0400
CLOUDSTACK-7147: Resolving test script issue in test_ip_reservation.py
commit 613eb12104af5c27935091127a1a19941f96e336
Author: Ashutosh K ashut...@clogeny.com
Date: Tue Jul 22 04:57:46 2014 -0400
CLOUDSTACK-7044: Portable IP Range test case changes - reading portable ip
range from test_data.py file
commit 981becc73585c9a789b377e18af623c325b0bc7f
Author: Ashutosh K ashut...@clogeny.com
Date: Tue Jul 22 05:05:47 2014 -0400
CLOUDSTACK-7148: Adding missing list method
commit 45888e214c949d1e48d800339b366c42a7990641
Author: Ashutosh K ashut...@clogeny.com
Date: Mon Jul 21 03:15:07 2014 -0400
CLOUDSTACK-7137: Resolving cleanup issue in
test_escalations_securitygroups.py
commit 3b32732459730bfd4848678c95c27e2eb653cc04
Author: Min Chen min.c...@citrix.com
Date: Tue Jul 22 09:47:27 2014 -0700
CLOUDSTACK-7162:queryAsyncJobResult api does not return jobinstanceid.
commit 1d2124dcbf48d15d23ddbdea23a29f0ab21be6f3
Author: Hugo Trippaers htrippa...@schubergphilis.com
Date: Tue Jul 22 17:43:49 2014 +0200
Fix NPE reported on IRC, provide the user an informative error message
commit 4523490d44160b054de9e943f72db1d0ce06054a
Author: Santhosh Edukulla santhosh.eduku...@gmail.com
Date: Mon Jul 21 20:49:03 2014 +0530
Fixed Coverity Issues reported
Signed-off-by: Santhosh Edukulla santhosh.eduku...@gmail.com
{noformat}
was (Author: alexbre):
Changes that I can see between a working build and a failing one (I'll see if I
can narrow this down a bit):
{noformat}
commit d3af2dbecacf260acda9f84a51a42838cc0f798c
Author: Will Stevens wstev...@cloudops.com
Date: Tue Jul 22 17:28:01 2014 -0400
CLOUDSTACK-6886 - Fixed the issue created by the SSL feature with the SDX:
commit 173909e99d85cfcc85b017bc426950f9f16fddf0
Author: Wido den Hollander w...@widodh.nl
Date: Tue Jul 22 22:28:34 2014 +0200
CLOUDSTACK-6181: Allow RBD volumes to be resized
We don't need an external script to investigate the format of the RBD
volume,
we only have to ask Libvirt to resize the volume and that will ask librbd to
do so.
commit 2c0765195a4a01ee51973c48d0561261d4fb01c6
Author: Gaurav Aradhye gaurav.arad...@clogeny.com
Date: Tue Jul 22 04:23:10 2014 -0400
CLOUDSTACK-7147: Resolving test script issue in test_ip_reservation.py
commit 613eb12104af5c27935091127a1a19941f96e336
Author: Ashutosh K ashut...@clogeny.com
Date: Tue Jul 22 04:57:46 2014 -0400
CLOUDSTACK-7044: Portable IP Range test case changes - reading portable ip
range from test_data.py file
commit 981becc73585c9a789b377e18af623c325b0bc7f
Author: Ashutosh K ashut...@clogeny.com
Date: Tue Jul 22 05:05:47 2014 -0400
CLOUDSTACK-7148: Adding missing list method
commit 45888e214c949d1e48d800339b366c42a7990641
Author: Ashutosh K ashut...@clogeny.com
Date: Mon Jul 21 03:15:07 2014 -0400
CLOUDSTACK-7137: Resolving cleanup issue in
test_escalations_securitygroups.py
commit 3b32732459730bfd4848678c95c27e2eb653cc04
Author: Min Chen min.c...@citrix.com
Date: Tue Jul 22 09:47:27 2014 -0700
CLOUDSTACK-7162:queryAsyncJobResult api does not return jobinstanceid.
commit 1d2124dcbf48d15d23ddbdea23a29f0ab21be6f3
Author: Hugo Trippaers htrippa...@schubergphilis.com
Date: Tue Jul 22 17:43:49 2014 +0200
Fix NPE reported on IRC, provide the user an informative error message
commit 4523490d44160b054de9e943f72db1d0ce06054a
Author: Santhosh Edukulla santhosh.eduku...@gmail.com
Date: Mon Jul 21 20:49:03 2014 +0530
Fixed Coverity Issues reported
Signed-off-by: Santhosh Edukulla santhosh.eduku...@gmail.com
commit 7d3f381d9476fec5dc7ba1cada8294bcb2df0ffa
Author: Kishan Kavala kis...@apache.org
Date: Tue Jul 22 17:50:16 2014 +0530
Set mapped device path while detaching rbd disk
commit 4bf321bd034f179c1ac9dda111fbb5e1034fadd0
Author: Hugo
[jira] [Comment Edited] (CLOUDSTACK-7170) [Automation] Failed to add KVM agent with master
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14071632#comment-14071632
]
Alex Brett edited comment on CLOUDSTACK-7170 at 7/23/14 12:37 PM:
--
Changes that I can see between a working build and a failing one:
{noformat}
commit 3b32732459730bfd4848678c95c27e2eb653cc04
Author: Min Chen min.c...@citrix.com
Date: Tue Jul 22 09:47:27 2014 -0700
CLOUDSTACK-7162:queryAsyncJobResult api does not return jobinstanceid.
commit 1d2124dcbf48d15d23ddbdea23a29f0ab21be6f3
Author: Hugo Trippaers htrippa...@schubergphilis.com
Date: Tue Jul 22 17:43:49 2014 +0200
Fix NPE reported on IRC, provide the user an informative error message
commit 4523490d44160b054de9e943f72db1d0ce06054a
Author: Santhosh Edukulla santhosh.eduku...@gmail.com
Date: Mon Jul 21 20:49:03 2014 +0530
Fixed Coverity Issues reported
Signed-off-by: Santhosh Edukulla santhosh.eduku...@gmail.com
{noformat}
was (Author: alexbre):
Changes that I can see between a working build and a failing one (I'll see if I
can narrow this down a bit):
{noformat}
commit d3af2dbecacf260acda9f84a51a42838cc0f798c
Author: Will Stevens wstev...@cloudops.com
Date: Tue Jul 22 17:28:01 2014 -0400
CLOUDSTACK-6886 - Fixed the issue created by the SSL feature with the SDX:
commit 173909e99d85cfcc85b017bc426950f9f16fddf0
Author: Wido den Hollander w...@widodh.nl
Date: Tue Jul 22 22:28:34 2014 +0200
CLOUDSTACK-6181: Allow RBD volumes to be resized
We don't need an external script to investigate the format of the RBD
volume,
we only have to ask Libvirt to resize the volume and that will ask librbd to
do so.
commit 2c0765195a4a01ee51973c48d0561261d4fb01c6
Author: Gaurav Aradhye gaurav.arad...@clogeny.com
Date: Tue Jul 22 04:23:10 2014 -0400
CLOUDSTACK-7147: Resolving test script issue in test_ip_reservation.py
commit 613eb12104af5c27935091127a1a19941f96e336
Author: Ashutosh K ashut...@clogeny.com
Date: Tue Jul 22 04:57:46 2014 -0400
CLOUDSTACK-7044: Portable IP Range test case changes - reading portable ip
range from test_data.py file
commit 981becc73585c9a789b377e18af623c325b0bc7f
Author: Ashutosh K ashut...@clogeny.com
Date: Tue Jul 22 05:05:47 2014 -0400
CLOUDSTACK-7148: Adding missing list method
commit 45888e214c949d1e48d800339b366c42a7990641
Author: Ashutosh K ashut...@clogeny.com
Date: Mon Jul 21 03:15:07 2014 -0400
CLOUDSTACK-7137: Resolving cleanup issue in
test_escalations_securitygroups.py
commit 3b32732459730bfd4848678c95c27e2eb653cc04
Author: Min Chen min.c...@citrix.com
Date: Tue Jul 22 09:47:27 2014 -0700
CLOUDSTACK-7162:queryAsyncJobResult api does not return jobinstanceid.
commit 1d2124dcbf48d15d23ddbdea23a29f0ab21be6f3
Author: Hugo Trippaers htrippa...@schubergphilis.com
Date: Tue Jul 22 17:43:49 2014 +0200
Fix NPE reported on IRC, provide the user an informative error message
commit 4523490d44160b054de9e943f72db1d0ce06054a
Author: Santhosh Edukulla santhosh.eduku...@gmail.com
Date: Mon Jul 21 20:49:03 2014 +0530
Fixed Coverity Issues reported
Signed-off-by: Santhosh Edukulla santhosh.eduku...@gmail.com
{noformat}
[Automation] Failed to add KVM agent with master
--
Key: CLOUDSTACK-7170
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7170
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: KVM
Affects Versions: 4.5.0
Environment: KVM - RHEL 6.3
Master
Reporter: Rayees Namathponnan
Priority: Blocker
Fix For: 4.5.0
Attachments: July_23_KVM.rar
This issue observed in automation setup, failed add KVM agent
Might be regressed after
https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=commit;h=173909e99d85cfcc85b017bc426950f9f16fddf0
MS log
---
2014-07-23 00:49:18,307 WARN [c.c.r.ResourceManagerImpl]
(catalina-exec-8:ctx-9df22e36 ctx-c5a4207e ctx-3d7179b3) Unable to find the
server resources at http://10.223.50.66
2014-07-23 00:49:18,310 INFO [c.c.u.e.CSExceptionErrorCode]
(catalina-exec-8:ctx-9df22e36 ctx-c5a4207e ctx-3d7179b3) Could not find
exception: com.cloud.exception.DiscoveryException in error code list for
exceptions
2014-07-23 00:49:18,310 WARN [o.a.c.a.c.a.h.AddHostCmd]
(catalina-exec-8:ctx-9df22e36 ctx-c5a4207e ctx-3d7179b3) Exception:
com.cloud.exception.DiscoveryException: Unable to add the host
at
com.cloud.resource.ResourceManagerImpl.discoverHostsFull(ResourceManagerImpl.java:790)
at
com.cloud.resource.ResourceManagerImpl.discoverHosts(ResourceManagerImpl.java:585)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[jira] [Commented] (CLOUDSTACK-7170) [Automation] Failed to add KVM agent with master
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14072117#comment-14072117
]
Alex Brett commented on CLOUDSTACK-7170:
Narrowed down even further to:
{noformat}
commit 4523490d44160b054de9e943f72db1d0ce06054a
Author: Santhosh Edukulla santhosh.eduku...@gmail.com
Date: Mon Jul 21 20:49:03 2014 +0530
Fixed Coverity Issues reported
Signed-off-by: Santhosh Edukulla santhosh.eduku...@gmail.com
{noformat}
[Automation] Failed to add KVM agent with master
--
Key: CLOUDSTACK-7170
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7170
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: KVM
Affects Versions: 4.5.0
Environment: KVM - RHEL 6.3
Master
Reporter: Rayees Namathponnan
Assignee: Kishan Kavala
Priority: Blocker
Fix For: 4.5.0
Attachments: July_23_KVM.rar
This issue observed in automation setup, failed add KVM agent
Might be regressed after
https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=commit;h=173909e99d85cfcc85b017bc426950f9f16fddf0
MS log
---
2014-07-23 00:49:18,307 WARN [c.c.r.ResourceManagerImpl]
(catalina-exec-8:ctx-9df22e36 ctx-c5a4207e ctx-3d7179b3) Unable to find the
server resources at http://10.223.50.66
2014-07-23 00:49:18,310 INFO [c.c.u.e.CSExceptionErrorCode]
(catalina-exec-8:ctx-9df22e36 ctx-c5a4207e ctx-3d7179b3) Could not find
exception: com.cloud.exception.DiscoveryException in error code list for
exceptions
2014-07-23 00:49:18,310 WARN [o.a.c.a.c.a.h.AddHostCmd]
(catalina-exec-8:ctx-9df22e36 ctx-c5a4207e ctx-3d7179b3) Exception:
com.cloud.exception.DiscoveryException: Unable to add the host
at
com.cloud.resource.ResourceManagerImpl.discoverHostsFull(ResourceManagerImpl.java:790)
at
com.cloud.resource.ResourceManagerImpl.discoverHosts(ResourceManagerImpl.java:585)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
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.$Proxy148.discoverHosts(Unknown Source)
at
org.apache.cloudstack.api.command.admin.host.AddHostCmd.execute(AddHostCmd.java:142)
at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:141)
at com.cloud.api.ApiServer.queueCommand(ApiServer.java:694)
at com.cloud.api.ApiServer.handleRequest(ApiServer.java:517)
at
com.cloud.api.ApiServlet.processRequestInContext(ApiServlet.java:317)
at com.cloud.api.ApiServlet$1.run(ApiServlet.java:118)
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 com.cloud.api.ApiServlet.processRequest(ApiServlet.java:115)
at com.cloud.api.ApiServlet.doGet(ApiServlet.java:77)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:617)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at
[jira] [Commented] (CLOUDSTACK-6862) [Automation] Test case TestDeployvGPUenabledVM.test_deploy_vgpu_enabled_vm faling during BVT
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14063626#comment-14063626
]
Alex Brett commented on CLOUDSTACK-6862:
This in fact appears to still be an issue - the current logic in setUpClass to
not run against non-XenServer hypervisors doesn't appear to be working and the
test is still running against KVM.
In addition the CLOUDSTACK-6914 change didn't actually solve the fact this test
needs to run on a machine with vGPU hardware, so it tries to run on all
XenServer hosts and therefore most of the time fails as most hosts don't have
vGPU hardware...
[Automation] Test case TestDeployvGPUenabledVM.test_deploy_vgpu_enabled_vm
faling during BVT
-
Key: CLOUDSTACK-6862
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6862
Project: CloudStack
Issue Type: Test
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Automation
Affects Versions: 4.4.0
Reporter: Rayees Namathponnan
Priority: Blocker
Fix For: 4.4.0
Test case
integration.smoke.test_deploy_vgpu_enabled_vm.TestDeployvGPUenabledVM.test_deploy_vgpu_enabled_vm
failing in BVT
Error Message
Execute cmd: createserviceoffering failed, due to: errorCode: 401,
errorText:unable to verify user credentials and/or request signature
begin captured stdout -
=== TestName: test_deploy_vgpu_enabled_vm | Status : EXCEPTION ===
- end captured stdout --
begin captured logging
test_deploy_vgpu_enabled_vm
(integration.smoke.test_deploy_vgpu_enabled_vm.TestDeployvGPUenabledVM):
DEBUG: STARTED : TC: test_deploy_vgpu_enabled_vm :::
test_deploy_vgpu_enabled_vm
(integration.smoke.test_deploy_vgpu_enabled_vm.TestDeployvGPUenabledVM):
DEBUG: Payload: {'apiKey':
u'8wj_03oPp3z6PQXsldtXr3ChyTC4UsL9BOx9gRCT30xsgLqo3uQhklIturqaW5KgZPbpy_vkNUd0h8g_hTVs5A',
'command': 'listDomains', 'signature': '8Yh5KlFqCsxhD/NB2fOBHSPL1kI=',
'response': 'json'}
test_deploy_vgpu_enabled_vm
(integration.smoke.test_deploy_vgpu_enabled_vm.TestDeployvGPUenabledVM):
DEBUG: Sending GET Cmd : listDomains===
requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection
(1): 172.16.88.21
requests.packages.urllib3.connectionpool: DEBUG: GET
/client/api?apiKey=8wj_03oPp3z6PQXsldtXr3ChyTC4UsL9BOx9gRCT30xsgLqo3uQhklIturqaW5KgZPbpy_vkNUd0h8g_hTVs5Acommand=listDomainsresponse=jsonsignature=8Yh5KlFqCsxhD%2FNB2fOBHSPL1kI%3D
HTTP/1.1 200 159
test_deploy_vgpu_enabled_vm
(integration.smoke.test_deploy_vgpu_enabled_vm.TestDeployvGPUenabledVM):
DEBUG: Response : [{path : u'ROOT', haschild : False, id :
u'6b3a436e-ef1f-11e3-a141-00163e189e44', name : u'ROOT', level : 0}]
test_deploy_vgpu_enabled_vm
(integration.smoke.test_deploy_vgpu_enabled_vm.TestDeployvGPUenabledVM):
DEBUG: Payload: {'apiKey':
u'8wj_03oPp3z6PQXsldtXr3ChyTC4UsL9BOx9gRCT30xsgLqo3uQhklIturqaW5KgZPbpy_vkNUd0h8g_hTVs5A',
'name': 'zone-xen', 'command': 'listZones', 'signature':
'Z7nIBao2vEVG1YiHM2kVrh6QcPY=', 'response': 'json'}
test_deploy_vgpu_enabled_vm
(integration.smoke.test_deploy_vgpu_enabled_vm.TestDeployvGPUenabledVM):
DEBUG: Sending GET Cmd : listZones===
requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection
(1): 172.16.88.21
requests.packages.urllib3.connectionpool: DEBUG: GET
/client/api?response=jsonapiKey=8wj_03oPp3z6PQXsldtXr3ChyTC4UsL9BOx9gRCT30xsgLqo3uQhklIturqaW5KgZPbpy_vkNUd0h8g_hTVs5Acommand=listZonesname=zone-xensignature=Z7nIBao2vEVG1YiHM2kVrh6QcPY%3D
HTTP/1.1 200 446
test_deploy_vgpu_enabled_vm
(integration.smoke.test_deploy_vgpu_enabled_vm.TestDeployvGPUenabledVM):
DEBUG: Response : [{localstorageenabled : False, name : u'zone-xen',
guestcidraddress : u'10.1.1.0/24', tags : [], zonetoken :
u'562e3c93-9149-38c6-8555-de48e3e6c847', dns2 : u'8.8.4.4', dns1 :
u'8.8.8.8', securitygroupsenabled : False, allocationstate : u'Enabled',
internaldns1 : u'172.16.88.7', dhcpprovider : u'VirtualRouter', networktype :
u'Advanced', id : u'ad43d834-dc57-4da5-b3ae-0ef3f106192b', internaldns2 :
u'172.16.88.8'}]
test_deploy_vgpu_enabled_vm
(integration.smoke.test_deploy_vgpu_enabled_vm.TestDeployvGPUenabledVM):
DEBUG: Payload: {'apiKey':
u'8wj_03oPp3z6PQXsldtXr3ChyTC4UsL9BOx9gRCT30xsgLqo3uQhklIturqaW5KgZPbpy_vkNUd0h8g_hTVs5A',
'templatefilter': 'featured', 'command': 'listTemplates', 'signature':
'KGHcOyWgw042qhRsMQWkZ7VdUIM=', 'zoneid':
u'ad43d834-dc57-4da5-b3ae-0ef3f106192b', 'response': 'json'}
test_deploy_vgpu_enabled_vm
[jira] [Created] (CLOUDSTACK-7031) [Automation] deployDataCenter.py issues
Alex Brett created CLOUDSTACK-7031: -- Summary: [Automation] deployDataCenter.py issues Key: CLOUDSTACK-7031 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7031 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.4.0 Reporter: Alex Brett Fix For: 4.4.0 In Marvin's deployDataCenter.py on master and 4.4-forward, some functions within the DeployDataCenters class call sys.exit(1) directly. Good practise is for sys.exit to only ever be called from inside a __main__ environment, and not from within a class. In particular, if using the deployDataCenter.py code as a library rather than invoking it directly, this can result in unexpected application exits if a problem occurs. In addition, when run directly deployDataCenter.py will always exit with error code 1, even after a successful deploy, which is not helpful to anybody wanting to script the code. I've prepared a patch against 4.4-forward that resolves these issues (and also tidies up logging by removing calls to print from inside the DeployDataCenters class), which I'll submit for review. I can't assign this ticket to myself however... -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6914) The present way of tagging the test cases has issues and is not usable. Need to modify this.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6914?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14033663#comment-14033663 ] Alex Brett commented on CLOUDSTACK-6914: Is there any documentation around the new required_hardware flag that this commit seems to have introduced? The present way of tagging the test cases has issues and is not usable. Need to modify this. Key: CLOUDSTACK-6914 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6914 Project: CloudStack Issue Type: Bug Security Level: Public(Anyone can view this level - this is the default.) Components: Automation Affects Versions: 4.4.0 Reporter: Bharat Kumar Assignee: Santhosh Kumar Edukulla Fix For: 4.4.0 Currently we add all the test meta data in a single tag called tags, as a result we cannot use proper nosetest conditions to filter the simulator test cases from provisioning. Also some tests have both simulator and provisioning tags added to the same test case.Some test cases have simulator, selfservice tags and others. Tracking this bug to clean up the tags. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6862) [Automation] Test case TestDeployvGPUenabledVM.test_deploy_vgpu_enabled_vm faling during BVT
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14032413#comment-14032413
]
Alex Brett commented on CLOUDSTACK-6862:
It looks like the fix for CLOUDSTACK-6914 should resolve this, I suggest this
ticket gets closed off as a duplicate...
[Automation] Test case TestDeployvGPUenabledVM.test_deploy_vgpu_enabled_vm
faling during BVT
-
Key: CLOUDSTACK-6862
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6862
Project: CloudStack
Issue Type: Test
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Automation
Affects Versions: 4.4.0
Reporter: Rayees Namathponnan
Priority: Blocker
Fix For: 4.4.0
Test case
integration.smoke.test_deploy_vgpu_enabled_vm.TestDeployvGPUenabledVM.test_deploy_vgpu_enabled_vm
failing in BVT
Error Message
Execute cmd: createserviceoffering failed, due to: errorCode: 401,
errorText:unable to verify user credentials and/or request signature
begin captured stdout -
=== TestName: test_deploy_vgpu_enabled_vm | Status : EXCEPTION ===
- end captured stdout --
begin captured logging
test_deploy_vgpu_enabled_vm
(integration.smoke.test_deploy_vgpu_enabled_vm.TestDeployvGPUenabledVM):
DEBUG: STARTED : TC: test_deploy_vgpu_enabled_vm :::
test_deploy_vgpu_enabled_vm
(integration.smoke.test_deploy_vgpu_enabled_vm.TestDeployvGPUenabledVM):
DEBUG: Payload: {'apiKey':
u'8wj_03oPp3z6PQXsldtXr3ChyTC4UsL9BOx9gRCT30xsgLqo3uQhklIturqaW5KgZPbpy_vkNUd0h8g_hTVs5A',
'command': 'listDomains', 'signature': '8Yh5KlFqCsxhD/NB2fOBHSPL1kI=',
'response': 'json'}
test_deploy_vgpu_enabled_vm
(integration.smoke.test_deploy_vgpu_enabled_vm.TestDeployvGPUenabledVM):
DEBUG: Sending GET Cmd : listDomains===
requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection
(1): 172.16.88.21
requests.packages.urllib3.connectionpool: DEBUG: GET
/client/api?apiKey=8wj_03oPp3z6PQXsldtXr3ChyTC4UsL9BOx9gRCT30xsgLqo3uQhklIturqaW5KgZPbpy_vkNUd0h8g_hTVs5Acommand=listDomainsresponse=jsonsignature=8Yh5KlFqCsxhD%2FNB2fOBHSPL1kI%3D
HTTP/1.1 200 159
test_deploy_vgpu_enabled_vm
(integration.smoke.test_deploy_vgpu_enabled_vm.TestDeployvGPUenabledVM):
DEBUG: Response : [{path : u'ROOT', haschild : False, id :
u'6b3a436e-ef1f-11e3-a141-00163e189e44', name : u'ROOT', level : 0}]
test_deploy_vgpu_enabled_vm
(integration.smoke.test_deploy_vgpu_enabled_vm.TestDeployvGPUenabledVM):
DEBUG: Payload: {'apiKey':
u'8wj_03oPp3z6PQXsldtXr3ChyTC4UsL9BOx9gRCT30xsgLqo3uQhklIturqaW5KgZPbpy_vkNUd0h8g_hTVs5A',
'name': 'zone-xen', 'command': 'listZones', 'signature':
'Z7nIBao2vEVG1YiHM2kVrh6QcPY=', 'response': 'json'}
test_deploy_vgpu_enabled_vm
(integration.smoke.test_deploy_vgpu_enabled_vm.TestDeployvGPUenabledVM):
DEBUG: Sending GET Cmd : listZones===
requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection
(1): 172.16.88.21
requests.packages.urllib3.connectionpool: DEBUG: GET
/client/api?response=jsonapiKey=8wj_03oPp3z6PQXsldtXr3ChyTC4UsL9BOx9gRCT30xsgLqo3uQhklIturqaW5KgZPbpy_vkNUd0h8g_hTVs5Acommand=listZonesname=zone-xensignature=Z7nIBao2vEVG1YiHM2kVrh6QcPY%3D
HTTP/1.1 200 446
test_deploy_vgpu_enabled_vm
(integration.smoke.test_deploy_vgpu_enabled_vm.TestDeployvGPUenabledVM):
DEBUG: Response : [{localstorageenabled : False, name : u'zone-xen',
guestcidraddress : u'10.1.1.0/24', tags : [], zonetoken :
u'562e3c93-9149-38c6-8555-de48e3e6c847', dns2 : u'8.8.4.4', dns1 :
u'8.8.8.8', securitygroupsenabled : False, allocationstate : u'Enabled',
internaldns1 : u'172.16.88.7', dhcpprovider : u'VirtualRouter', networktype :
u'Advanced', id : u'ad43d834-dc57-4da5-b3ae-0ef3f106192b', internaldns2 :
u'172.16.88.8'}]
test_deploy_vgpu_enabled_vm
(integration.smoke.test_deploy_vgpu_enabled_vm.TestDeployvGPUenabledVM):
DEBUG: Payload: {'apiKey':
u'8wj_03oPp3z6PQXsldtXr3ChyTC4UsL9BOx9gRCT30xsgLqo3uQhklIturqaW5KgZPbpy_vkNUd0h8g_hTVs5A',
'templatefilter': 'featured', 'command': 'listTemplates', 'signature':
'KGHcOyWgw042qhRsMQWkZ7VdUIM=', 'zoneid':
u'ad43d834-dc57-4da5-b3ae-0ef3f106192b', 'response': 'json'}
test_deploy_vgpu_enabled_vm
(integration.smoke.test_deploy_vgpu_enabled_vm.TestDeployvGPUenabledVM):
DEBUG: Sending GET Cmd : listTemplates===
requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection
(1): 172.16.88.21
requests.packages.urllib3.connectionpool: DEBUG: GET
[jira] [Commented] (CLOUDSTACK-6876) test_deploy_vgpu_enabled_vm is failing on xen and Kvm runs.
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14029133#comment-14029133
]
Alex Brett commented on CLOUDSTACK-6876:
This is a duplicate of CLOUDSTACK-6862
test_deploy_vgpu_enabled_vm is failing on xen and Kvm runs.
---
Key: CLOUDSTACK-6876
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6876
Project: CloudStack
Issue Type: Sub-task
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Automation
Reporter: Bharat Kumar
Error Message
Execute cmd: createserviceoffering failed, due to: errorCode: 401,
errorText:unable to verify user credentials and/or request signature
begin captured stdout -
=== TestName: test_deploy_vgpu_enabled_vm | Status : EXCEPTION ===
- end captured stdout --
begin captured logging
test_deploy_vgpu_enabled_vm
(integration.smoke.test_deploy_vgpu_enabled_vm.TestDeployvGPUenabledVM):
DEBUG: STARTED : TC: test_deploy_vgpu_enabled_vm :::
test_deploy_vgpu_enabled_vm
(integration.smoke.test_deploy_vgpu_enabled_vm.TestDeployvGPUenabledVM):
DEBUG: Payload: {'apiKey':
u'N9xuraDqhuIDa7f0I_v0nkI3Kk2wLZ5w9UH3F86H-TeAnoXJ1iRnOaYMLJDd2w-rjwH6LCiSEnw24lNX6LH8iA',
'command': 'listDomains', 'signature': 'lalPSnJlAM6GkRDFC2sNKSa5T+o=',
'response': 'json'}
test_deploy_vgpu_enabled_vm
(integration.smoke.test_deploy_vgpu_enabled_vm.TestDeployvGPUenabledVM):
DEBUG: Sending GET Cmd : listDomains===
requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection
(1): 172.16.88.21
requests.packages.urllib3.connectionpool: DEBUG: GET
/client/api?apiKey=N9xuraDqhuIDa7f0I_v0nkI3Kk2wLZ5w9UH3F86H-TeAnoXJ1iRnOaYMLJDd2w-rjwH6LCiSEnw24lNX6LH8iAcommand=listDomainsresponse=jsonsignature=lalPSnJlAM6GkRDFC2sNKSa5T%2Bo%3D
HTTP/1.1 200 159
test_deploy_vgpu_enabled_vm
(integration.smoke.test_deploy_vgpu_enabled_vm.TestDeployvGPUenabledVM):
DEBUG: Response : [{path : u'ROOT', haschild : False, id :
u'b5e7af36-ef7f-11e3-a141-00163e189e44', name : u'ROOT', level : 0}]
test_deploy_vgpu_enabled_vm
(integration.smoke.test_deploy_vgpu_enabled_vm.TestDeployvGPUenabledVM):
DEBUG: Payload: {'apiKey':
u'N9xuraDqhuIDa7f0I_v0nkI3Kk2wLZ5w9UH3F86H-TeAnoXJ1iRnOaYMLJDd2w-rjwH6LCiSEnw24lNX6LH8iA',
'name': 'zone-xen', 'command': 'listZones', 'signature':
'TFpPtnJ8uzOTOnEQ53yyluY5Ed0=', 'response': 'json'}
test_deploy_vgpu_enabled_vm
(integration.smoke.test_deploy_vgpu_enabled_vm.TestDeployvGPUenabledVM):
DEBUG: Sending GET Cmd : listZones===
requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection
(1): 172.16.88.21
requests.packages.urllib3.connectionpool: DEBUG: GET
/client/api?response=jsonapiKey=N9xuraDqhuIDa7f0I_v0nkI3Kk2wLZ5w9UH3F86H-TeAnoXJ1iRnOaYMLJDd2w-rjwH6LCiSEnw24lNX6LH8iAcommand=listZonesname=zone-xensignature=TFpPtnJ8uzOTOnEQ53yyluY5Ed0%3D
HTTP/1.1 200 446
test_deploy_vgpu_enabled_vm
(integration.smoke.test_deploy_vgpu_enabled_vm.TestDeployvGPUenabledVM):
DEBUG: Response : [{localstorageenabled : False, name : u'zone-xen',
guestcidraddress : u'10.1.1.0/24', tags : [], zonetoken :
u'21715335-f736-3016-9d97-0765620600c0', dns2 : u'8.8.4.4', dns1 :
u'8.8.8.8', securitygroupsenabled : False, allocationstate : u'Enabled',
internaldns1 : u'172.16.88.7', dhcpprovider : u'VirtualRouter', networktype :
u'Advanced', id : u'243eb08f-31e9-4283-953b-52578d8b1c6a', internaldns2 :
u'172.16.88.8'}]
test_deploy_vgpu_enabled_vm
(integration.smoke.test_deploy_vgpu_enabled_vm.TestDeployvGPUenabledVM):
DEBUG: Payload: {'apiKey':
u'N9xuraDqhuIDa7f0I_v0nkI3Kk2wLZ5w9UH3F86H-TeAnoXJ1iRnOaYMLJDd2w-rjwH6LCiSEnw24lNX6LH8iA',
'templatefilter': 'featured', 'command': 'listTemplates', 'signature':
'eIj8lFw1ONlBOoquO50AKcXIBEI=', 'zoneid':
u'243eb08f-31e9-4283-953b-52578d8b1c6a', 'response': 'json'}
test_deploy_vgpu_enabled_vm
(integration.smoke.test_deploy_vgpu_enabled_vm.TestDeployvGPUenabledVM):
DEBUG: Sending GET Cmd : listTemplates===
requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection
(1): 172.16.88.21
requests.packages.urllib3.connectionpool: DEBUG: GET
/client/api?templatefilter=featuredapiKey=N9xuraDqhuIDa7f0I_v0nkI3Kk2wLZ5w9UH3F86H-TeAnoXJ1iRnOaYMLJDd2w-rjwH6LCiSEnw24lNX6LH8iAzoneid=243eb08f-31e9-4283-953b-52578d8b1c6acommand=listTemplatessignature=eIj8lFw1ONlBOoquO50AKcXIBEI%3Dresponse=json
HTTP/1.1 200 818
test_deploy_vgpu_enabled_vm
(integration.smoke.test_deploy_vgpu_enabled_vm.TestDeployvGPUenabledVM):
DEBUG: Response : [{domain : u'ROOT', domainid :
[jira] [Commented] (CLOUDSTACK-6862) [Automation] Test case TestDeployvGPUenabledVM.test_deploy_vgpu_enabled_vm faling during BVT
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14029138#comment-14029138
]
Alex Brett commented on CLOUDSTACK-6862:
I've created a patch that does the above and posted it at
https://reviews.apache.org/r/22512/
[Automation] Test case TestDeployvGPUenabledVM.test_deploy_vgpu_enabled_vm
faling during BVT
-
Key: CLOUDSTACK-6862
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6862
Project: CloudStack
Issue Type: Test
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Automation
Affects Versions: 4.4.0
Reporter: Rayees Namathponnan
Priority: Blocker
Fix For: 4.4.0
Test case
integration.smoke.test_deploy_vgpu_enabled_vm.TestDeployvGPUenabledVM.test_deploy_vgpu_enabled_vm
failing in BVT
Error Message
Execute cmd: createserviceoffering failed, due to: errorCode: 401,
errorText:unable to verify user credentials and/or request signature
begin captured stdout -
=== TestName: test_deploy_vgpu_enabled_vm | Status : EXCEPTION ===
- end captured stdout --
begin captured logging
test_deploy_vgpu_enabled_vm
(integration.smoke.test_deploy_vgpu_enabled_vm.TestDeployvGPUenabledVM):
DEBUG: STARTED : TC: test_deploy_vgpu_enabled_vm :::
test_deploy_vgpu_enabled_vm
(integration.smoke.test_deploy_vgpu_enabled_vm.TestDeployvGPUenabledVM):
DEBUG: Payload: {'apiKey':
u'8wj_03oPp3z6PQXsldtXr3ChyTC4UsL9BOx9gRCT30xsgLqo3uQhklIturqaW5KgZPbpy_vkNUd0h8g_hTVs5A',
'command': 'listDomains', 'signature': '8Yh5KlFqCsxhD/NB2fOBHSPL1kI=',
'response': 'json'}
test_deploy_vgpu_enabled_vm
(integration.smoke.test_deploy_vgpu_enabled_vm.TestDeployvGPUenabledVM):
DEBUG: Sending GET Cmd : listDomains===
requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection
(1): 172.16.88.21
requests.packages.urllib3.connectionpool: DEBUG: GET
/client/api?apiKey=8wj_03oPp3z6PQXsldtXr3ChyTC4UsL9BOx9gRCT30xsgLqo3uQhklIturqaW5KgZPbpy_vkNUd0h8g_hTVs5Acommand=listDomainsresponse=jsonsignature=8Yh5KlFqCsxhD%2FNB2fOBHSPL1kI%3D
HTTP/1.1 200 159
test_deploy_vgpu_enabled_vm
(integration.smoke.test_deploy_vgpu_enabled_vm.TestDeployvGPUenabledVM):
DEBUG: Response : [{path : u'ROOT', haschild : False, id :
u'6b3a436e-ef1f-11e3-a141-00163e189e44', name : u'ROOT', level : 0}]
test_deploy_vgpu_enabled_vm
(integration.smoke.test_deploy_vgpu_enabled_vm.TestDeployvGPUenabledVM):
DEBUG: Payload: {'apiKey':
u'8wj_03oPp3z6PQXsldtXr3ChyTC4UsL9BOx9gRCT30xsgLqo3uQhklIturqaW5KgZPbpy_vkNUd0h8g_hTVs5A',
'name': 'zone-xen', 'command': 'listZones', 'signature':
'Z7nIBao2vEVG1YiHM2kVrh6QcPY=', 'response': 'json'}
test_deploy_vgpu_enabled_vm
(integration.smoke.test_deploy_vgpu_enabled_vm.TestDeployvGPUenabledVM):
DEBUG: Sending GET Cmd : listZones===
requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection
(1): 172.16.88.21
requests.packages.urllib3.connectionpool: DEBUG: GET
/client/api?response=jsonapiKey=8wj_03oPp3z6PQXsldtXr3ChyTC4UsL9BOx9gRCT30xsgLqo3uQhklIturqaW5KgZPbpy_vkNUd0h8g_hTVs5Acommand=listZonesname=zone-xensignature=Z7nIBao2vEVG1YiHM2kVrh6QcPY%3D
HTTP/1.1 200 446
test_deploy_vgpu_enabled_vm
(integration.smoke.test_deploy_vgpu_enabled_vm.TestDeployvGPUenabledVM):
DEBUG: Response : [{localstorageenabled : False, name : u'zone-xen',
guestcidraddress : u'10.1.1.0/24', tags : [], zonetoken :
u'562e3c93-9149-38c6-8555-de48e3e6c847', dns2 : u'8.8.4.4', dns1 :
u'8.8.8.8', securitygroupsenabled : False, allocationstate : u'Enabled',
internaldns1 : u'172.16.88.7', dhcpprovider : u'VirtualRouter', networktype :
u'Advanced', id : u'ad43d834-dc57-4da5-b3ae-0ef3f106192b', internaldns2 :
u'172.16.88.8'}]
test_deploy_vgpu_enabled_vm
(integration.smoke.test_deploy_vgpu_enabled_vm.TestDeployvGPUenabledVM):
DEBUG: Payload: {'apiKey':
u'8wj_03oPp3z6PQXsldtXr3ChyTC4UsL9BOx9gRCT30xsgLqo3uQhklIturqaW5KgZPbpy_vkNUd0h8g_hTVs5A',
'templatefilter': 'featured', 'command': 'listTemplates', 'signature':
'KGHcOyWgw042qhRsMQWkZ7VdUIM=', 'zoneid':
u'ad43d834-dc57-4da5-b3ae-0ef3f106192b', 'response': 'json'}
test_deploy_vgpu_enabled_vm
(integration.smoke.test_deploy_vgpu_enabled_vm.TestDeployvGPUenabledVM):
DEBUG: Sending GET Cmd : listTemplates===
requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection
(1): 172.16.88.21
requests.packages.urllib3.connectionpool: DEBUG: GET
