[jira] [Resolved] (CLOUDSTACK-5250) [Automation] integration.smoke.test_network.TestReleaseIP.test_releaseIP failing
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Girish Shilamkar resolved CLOUDSTACK-5250.
--
Resolution: Cannot Reproduce
Not seen in latest run (342)
> [Automation] integration.smoke.test_network.TestReleaseIP.test_releaseIP
> failing
> --
>
> Key: CLOUDSTACK-5250
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5250
> Project: CloudStack
> Issue Type: Test
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Automation
>Affects Versions: 4.3.0
> Environment: KVM
> automation
>Reporter: Rayees Namathponnan
> Fix For: 4.3.0
>
>
> [Automation] integration.smoke.test_network.TestReleaseIP.test_releaseIP
> failing after fixing CLOUDSTACK-4344
> heck if disassociated IP Address is no longer available
> >> begin captured logging <<
> test_releaseIP (integration.smoke.test_network.TestReleaseIP): DEBUG:
> Deleting Public IP : 2c0e1ad7-639b-4564-ba82-d44a41740c34
> test_releaseIP (integration.smoke.test_network.TestReleaseIP): DEBUG: List
> Public IP response[{networkid : u'04c5487a-5754-432f-81cd-d52738c1eb9c',
> physicalnetworkid : u'ddf995ff-4f12-4cae-9729-5b763a1e1170', account :
> u'test-TestReleaseIP-test_releaseIP-RTK06M', domainid :
> u'5f0d3956-531c-11e3-a447-1a6f7bb0d0a8', issourcenat : True, isstaticnat :
> False, tags : [], associatednetworkname :
> u'test-TestReleaseIP-test_releaseIP-RTK06M-network', domain : u'ROOT', vlanid
> : u'7746889d-db42-41c2-90d1-1876847c2377', zoneid :
> u'9338ab1f-fee3-43dc-98cc-9aa2839b0d19', vlanname : u'vlan://1221', state :
> u'Allocated', associatednetworkid : u'823a5c6c-53d4-4dc0-8672-a3daeb9ff6ff',
> zonename : u'Adv-KVM-Zone1', forvirtualnetwork : True, allocated :
> u'2013-11-21T20:11:44-0800', issystem : False, ipaddress : u'10.223.122.74',
> id : u'2c0e1ad7-639b-4564-ba82-d44a41740c34', isportable : False}]
> - >> end captured logging << -
> Stacktrace
> File "/usr/local/lib/python2.7/unittest/case.py", line 318, in run
> testMethod()
> File "/Repo_30X/ipcl/cloudstack/test/integration/smoke/test_network.py",
> line 859, in test_releaseIP
> "Check if disassociated IP Address is no longer available"
> File "/usr/local/lib/python2.7/unittest/case.py", line 494, in assertEqual
> assertion_func(first, second, msg=msg)
> File "/usr/local/lib/python2.7/unittest/case.py", line 487, in
> _baseAssertEqual
> raise self.failureException(msg)
> Check if disassociated IP Address is no longer available
> >> begin captured logging <<
> test_releaseIP (integration.smoke.test_network.TestReleaseIP): DEBUG:
> Deleting Public IP : 2c0e1ad7-639b-4564-ba82-d44a41740c34
> test_releaseIP (integration.smoke.test_network.TestReleaseIP): DEBUG: List
> Public IP response[{networkid : u'04c5487a-5754-432f-81cd-d52738c1eb9c',
> physicalnetworkid : u'ddf995ff-4f12-4cae-9729-5b763a1e1170', account :
> u'test-TestReleaseIP-test_releaseIP-RTK06M', domainid :
> u'5f0d3956-531c-11e3-a447-1a6f7bb0d0a8', issourcenat : True, isstaticnat :
> False, tags : [], associatednetworkname :
> u'test-TestReleaseIP-test_releaseIP-RTK06M-network', domain : u'ROOT', vlanid
> : u'7746889d-db42-41c2-90d1-1876847c2377', zoneid :
> u'9338ab1f-fee3-43dc-98cc-9aa2839b0d19', vlanname : u'vlan://1221', state :
> u'Allocated', associatednetworkid : u'823a5c6c-53d4-4dc0-8672-a3daeb9ff6ff',
> zonename : u'Adv-KVM-Zone1', forvirtualnetwork : True, allocated :
> u'2013-11-21T20:11:44-0800', issystem : False, ipaddress : u'10.223.122.74',
> id : u'2c0e1ad7-639b-4564-ba82-d44a41740c34', isportable : False}]
> - >> end captured logging << -
--
This message was sent by Atlassian JIRA
(v6.1.4#6159)
[jira] [Created] (CLOUDSTACK-5513) VM can't start after creating snapshot from it (CS4.2 + VMware 5.1)
Denis Finko created CLOUDSTACK-5513: --- Summary: VM can't start after creating snapshot from it (CS4.2 + VMware 5.1) Key: CLOUDSTACK-5513 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5513 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: VMware Affects Versions: 4.2.0 Environment: CloudStack 4.2 + vmware 5.1 Reporter: Denis Finko Priority: Critical Fix For: 4.3.0 Hello, I have found issue in our environment CloudStack 4.2 + vmware 5.1 which was described in https://issues.apache.org/jira/browse/CLOUDSTACK-3234 That issue is still present and not fixed. How to reproduce this issue: - Create VM in CloudStack - Select that VM in CloudStack and click to 'Take VM snapshot' - Try to reboot VM (you will be succeed with this and VM will be started) - if you 'Stop' VM from CloudStack UI - and then 'Start' VM You will see error in VMware: - Invalid configuration for device '0' - Cannot remove virtual disk from the virtual machine because it or one of its parent disks is part of a snapshot of the virtual machine. And this issue in CS UI: Unable to create a deployment for VM[User|vm-test] If we remove created snapshot from CS. VM can start. -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Updated] (CLOUDSTACK-5267) [Automation] instance.name name should not append with VM's Name
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Girish Shilamkar updated CLOUDSTACK-5267: - Assignee: Gaurav Aradhye (was: Girish Shilamkar) > [Automation] instance.name name should not append with VM's Name > > > Key: CLOUDSTACK-5267 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5267 > Project: CloudStack > Issue Type: Test > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation >Affects Versions: 4.3.0 > Environment: Branch : 4.3.0 >Reporter: Rayees Namathponnan >Assignee: Gaurav Aradhye >Priority: Blocker > Labels: automation > Fix For: 4.3.0 > > > Steps to reproduce > Step 1 : set instance.name=TestVM in global parameter > Step 2 : Restart MS and Deploy Vm, dont specify any name while deploying the > VM > Actual Result > UUID of new VM is 56276ab1-3353-473c-8b35-f27f81f68bd8, and vm should be > deployed with name "56276ab1-3353-473c-8b35-f27f81f68bd8" > vm deployed with name TestVM56276ab1-3353-473c-8b35-f27f81f68bd8, here > instance.name also included > We need to remove instance.name from vm name -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Updated] (CLOUDSTACK-5195) UI exception misleads when the DB failure happens at the time of VM creation.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajani Karuturi updated CLOUDSTACK-5195: Priority: Major (was: Critical) > UI exception misleads when the DB failure happens at the time of VM creation. > - > > Key: CLOUDSTACK-5195 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5195 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Install and Setup >Affects Versions: 4.3.0 >Reporter: Kiran Koneti >Assignee: Rajani Karuturi > Fix For: 4.3.0 > > > UI exception misleads when the DB failure happens at the time of VM > creation.The exception says the VM creation failed due to insufficient > capacity,This is the same message observed when any of the system resources > get exhausted.There should be some other message saying that the DB was not > reachable as we observe the below error message in the management server logs > "16:03:15,928 ERROR [c.c.v.VirtualMachineManagerImpl] > (Job-Executor-14:ctx-82a89feb ctx-317a42d4) Failed to start instance > VM[User|VM2] > com.cloud.utils.exception.CloudRuntimeException: SQL Exception on inquiry > at com.cloud.utils.db.Merovingian2.isLocked(Merovingian2.java:232) > at com.cloud.utils.db.Merovingian2.owns(Merovingian2.java:377) > at com.cloud.utils.db.Merovingian2.acquire(Merovingian2.java:126) > at > com.cloud.utils.db.TransactionLegacy.lock(TransactionLegacy.java:385) > at > com.cloud.utils.db.GenericDaoBase.acquireInLockTable(GenericDaoBase.java:1001) > 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:616) > 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:33) > 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 $Proxy33.acquireInLockTable(Unknown Source) > at > com.cloud.network.router.VirtualNetworkApplianceManagerImpl.findOrDeployVirtualRouterInGuestNetwork(VirtualNetworkApplianceManagerImpl.java:1306) > at > com.cloud.network.router.VirtualNetworkApplianceManagerImpl.deployVirtualRouterInGuestNetwork(VirtualNetworkApplianceManagerImpl.java:1841) > 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:616) > 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 $Proxy241.deployVirtualRouterInGuestNetwork(Unknown Source) > at > com.cloud.network.element.VirtualRouterElement.prepare(VirtualRouterElement.java:221) > at > org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.prepareElement(NetworkOrchestrator.java:1158) > at > org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.prepareNic(NetworkOrchestrator.java:1292) > at > org.apache.c
[jira] [Updated] (CLOUDSTACK-5513) VM can't start after creating snapshot from it (CS4.2 + VMware 5.1)
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Finko updated CLOUDSTACK-5513: Attachment: management-server.log Also I have attached management-server.log > VM can't start after creating snapshot from it (CS4.2 + VMware 5.1) > --- > > Key: CLOUDSTACK-5513 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5513 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: VMware >Affects Versions: 4.2.0 > Environment: CloudStack 4.2 + vmware 5.1 >Reporter: Denis Finko >Priority: Critical > Fix For: 4.3.0 > > Attachments: management-server.log > > > Hello, > I have found issue in our environment CloudStack 4.2 + vmware 5.1 which was > described in https://issues.apache.org/jira/browse/CLOUDSTACK-3234 > That issue is still present and not fixed. > How to reproduce this issue: > - Create VM in CloudStack > - Select that VM in CloudStack and click to 'Take VM snapshot' > - Try to reboot VM (you will be succeed with this and VM will be started) > - if you 'Stop' VM from CloudStack UI > - and then 'Start' VM > You will see error in VMware: > - Invalid configuration for device '0' > - Cannot remove virtual disk from the virtual machine because it or one of > its parent disks is part of a snapshot of the virtual machine. > And this issue in CS UI: > Unable to create a deployment for VM[User|vm-test] > If we remove created snapshot from CS. VM can start. -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Updated] (CLOUDSTACK-5435) ldap params are not encrypted
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajani Karuturi updated CLOUDSTACK-5435: Priority: Critical (was: Major) > ldap params are not encrypted > - > > Key: CLOUDSTACK-5435 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5435 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.3.0 >Reporter: Rajani Karuturi >Assignee: Rajani Karuturi >Priority: Critical > Labels: ldap > Fix For: Future, 4.3.0 > > > ldap global params in configuration table are not encrypted. These were > encrypted in 4.2 -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Updated] (CLOUDSTACK-5195) UI exception misleads when the DB failure happens at the time of VM creation.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajani Karuturi updated CLOUDSTACK-5195: Priority: Critical (was: Major) > UI exception misleads when the DB failure happens at the time of VM creation. > - > > Key: CLOUDSTACK-5195 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5195 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Install and Setup >Affects Versions: 4.3.0 >Reporter: Kiran Koneti >Assignee: Rajani Karuturi >Priority: Critical > Fix For: 4.3.0 > > > UI exception misleads when the DB failure happens at the time of VM > creation.The exception says the VM creation failed due to insufficient > capacity,This is the same message observed when any of the system resources > get exhausted.There should be some other message saying that the DB was not > reachable as we observe the below error message in the management server logs > "16:03:15,928 ERROR [c.c.v.VirtualMachineManagerImpl] > (Job-Executor-14:ctx-82a89feb ctx-317a42d4) Failed to start instance > VM[User|VM2] > com.cloud.utils.exception.CloudRuntimeException: SQL Exception on inquiry > at com.cloud.utils.db.Merovingian2.isLocked(Merovingian2.java:232) > at com.cloud.utils.db.Merovingian2.owns(Merovingian2.java:377) > at com.cloud.utils.db.Merovingian2.acquire(Merovingian2.java:126) > at > com.cloud.utils.db.TransactionLegacy.lock(TransactionLegacy.java:385) > at > com.cloud.utils.db.GenericDaoBase.acquireInLockTable(GenericDaoBase.java:1001) > 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:616) > 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:33) > 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 $Proxy33.acquireInLockTable(Unknown Source) > at > com.cloud.network.router.VirtualNetworkApplianceManagerImpl.findOrDeployVirtualRouterInGuestNetwork(VirtualNetworkApplianceManagerImpl.java:1306) > at > com.cloud.network.router.VirtualNetworkApplianceManagerImpl.deployVirtualRouterInGuestNetwork(VirtualNetworkApplianceManagerImpl.java:1841) > 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:616) > 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 $Proxy241.deployVirtualRouterInGuestNetwork(Unknown Source) > at > com.cloud.network.element.VirtualRouterElement.prepare(VirtualRouterElement.java:221) > at > org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.prepareElement(NetworkOrchestrator.java:1158) > at > org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.prepareNic(NetworkOrchestrator.java:12
[jira] [Commented] (CLOUDSTACK-5506) [Automation] component.test_egress_fw_rules test cases failed with error "global name 'list_virtual_machines' is not defined"
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5506?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13848919#comment-13848919
]
ASF subversion and git services commented on CLOUDSTACK-5506:
-
Commit f2683e894af004b986253f883c589f33bc29e956 in branch refs/heads/4.2 from
[~gpshilamkar]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=f2683e8 ]
CLOUDSTACK-5506: Fixed egress_fw_rules.py, one of hunks was missing.
> [Automation] component.test_egress_fw_rules test cases failed with error
> "global name 'list_virtual_machines' is not defined"
> -
>
> Key: CLOUDSTACK-5506
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5506
> Project: CloudStack
> Issue Type: Test
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Automation
>Affects Versions: 4.3.0
> Environment: Automation
>Reporter: Rayees Namathponnan
>Assignee: Girish Shilamkar
> Fix For: 4.3.0
>
>
> 26 test case from suite integration.component.test_egress_fw_rules failed
> with error
> Error Message
> Warning! Cleanup failed: global name 'list_virtual_machines' is not defined
> >> begin captured logging <<
> CSLog: DEBUG: sending GET request: listDomains {}
> requests.packages.urllib3.connectionpool: DEBUG: "GET
> /client/api?apiKey=xD2wDZTvUzDtHF5SAMlCud-rv-Li61wOoIYy8KLUHKIHUqxoe0gSvxoi57iu2_h5fMnVzwH9U5FTYmDv8rCgbQ&name=expunge.interval&command=listConfigurations&signature=QTt2mo%2FRMKOAzjJuTeJUvdn7NgQ%3D&response=json&listall=True
> HTTP/1.1" 200 220
> test_01_1_egress_fr1
> (integration.component.test_egress_fw_rules.TestEgressFWRules): DEBUG:
> Request:
> http://10.223.49.197:8080/client/api?apiKey=xD2wDZTvUzDtHF5SAMlCud-rv-Li61wOoIYy8KLUHKIHUqxoe0gSvxoi57iu2_h5fMnVzwH9U5FTYmDv8rCgbQ&name=expunge.interval&command=listConfigurations&signature=QTt2mo%2FRMKOAzjJuTeJUvdn7NgQ%3D&response=json&listall=True
> Response: { "listconfigurationsresponse" : { "count":1 ,"configuration" : [
> {"category":"Advanced","name":"expunge.interval","value":"60","description":"The
> interval (in seconds) to wait before running the expunge thread."} ] } }
> test_01_1_egress_fr1
> (integration.component.test_egress_fw_rules.TestEgressFWRules): DEBUG:
> sending GET request: listConfigurations {'name': 'expunge.delay', 'listall':
> True}
> test_01_1_egress_fr1
> (integration.component.test_egress_fw_rules.TestEgressFWRules): DEBUG:
> Computed Signature by Marvin: C8BlUCJKbFRmvpjVRJjHaEiVPsk=
> requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection
> (1): 10.223.49.197
> requests.packages.urllib3.connectionpool: DEBUG: "GET
> /client/api?apiKey=xD2wDZTvUzDtHF5SAMlCud-rv-Li61wOoIYy8KLUHKIHUqxoe0gSvxoi57iu2_h5fMnVzwH9U5FTYmDv8rCgbQ&name=expunge.delay&command=listConfigurations&signature=C8BlUCJKbFRmvpjVRJjHaEiVPsk%3D&response=json&listall=True
> HTTP/1.1" 200 287
> test_01_1_egress_fr1
> (integration.component.test_egress_fw_rules.TestEgressFWRules): DEBUG:
> Request:
> http://10.223.49.197:8080/client/api?apiKey=xD2wDZTvUzDtHF5SAMlCud-rv-Li61wOoIYy8KLUHKIHUqxoe0gSvxoi57iu2_h5fMnVzwH9U5FTYmDv8rCgbQ&name=expunge.delay&command=listConfigurations&signature=C8BlUCJKbFRmvpjVRJjHaEiVPsk%3D&response=json&listall=True
> Response: { "listconfigurationsresponse" : { "count":1 ,"configuration" : [
> {"category":"Advanced","name":"expunge.delay","value":"60","description":"Determines
> how long (in seconds) to wait before actually expunging destroyed vm. The
> default value = the default value of expunge.interval"} ] } }
> test_01_1_egress_fr1
> (integration.component.test_egress_fw_rules.TestEgressFWRules): CRITICAL:
> EXCEPTION: test_01_1_egress_fr1: Traceback (most recent call last):
> File "/usr/local/lib/python2.7/unittest/case.py", line 345, in run
> self.tearDown()
> File
> "/data/Repo2/qa/cloudstack/test/integration/component/test_egress_fw_rules.py",
> line 397, in tearDown
> self.fail("Warning! Cleanup failed: %s" % e)
> File "/usr/local/lib/python2.7/unittest/case.py", line 393, in fail
> raise self.failureException(msg)
> AssertionError: Warning! Cleanup failed: global name 'list_virtual_machines'
> is not defined
> - >> end captured logging << -
> Stacktrace
> File "/usr/local/lib/python2.7/unittest/case.py", line 345, in run
> self.tearDown()
> File
> "/data/Repo2/qa/cloudstack/test/integration/component/test_egress_fw_rules.py",
> line 397, in tearDown
> self.fail("Warning! Cleanup failed: %s" % e)
> File "/usr/local/lib/python2.7/unittest/case.py", line 393, in fail
> raise self.failureExcept
[jira] [Commented] (CLOUDSTACK-5506) [Automation] component.test_egress_fw_rules test cases failed with error "global name 'list_virtual_machines' is not defined"
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5506?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13848922#comment-13848922
]
ASF subversion and git services commented on CLOUDSTACK-5506:
-
Commit 6eec7b97078c8e8e17610bbe1655f8005eca10b2 in branch refs/heads/4.3 from
[~gpshilamkar]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=6eec7b9 ]
CLOUDSTACK-5506: Fixed egress_fw_rules.py, one of hunks was missing.
> [Automation] component.test_egress_fw_rules test cases failed with error
> "global name 'list_virtual_machines' is not defined"
> -
>
> Key: CLOUDSTACK-5506
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5506
> Project: CloudStack
> Issue Type: Test
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Automation
>Affects Versions: 4.3.0
> Environment: Automation
>Reporter: Rayees Namathponnan
>Assignee: Girish Shilamkar
> Fix For: 4.3.0
>
>
> 26 test case from suite integration.component.test_egress_fw_rules failed
> with error
> Error Message
> Warning! Cleanup failed: global name 'list_virtual_machines' is not defined
> >> begin captured logging <<
> CSLog: DEBUG: sending GET request: listDomains {}
> requests.packages.urllib3.connectionpool: DEBUG: "GET
> /client/api?apiKey=xD2wDZTvUzDtHF5SAMlCud-rv-Li61wOoIYy8KLUHKIHUqxoe0gSvxoi57iu2_h5fMnVzwH9U5FTYmDv8rCgbQ&name=expunge.interval&command=listConfigurations&signature=QTt2mo%2FRMKOAzjJuTeJUvdn7NgQ%3D&response=json&listall=True
> HTTP/1.1" 200 220
> test_01_1_egress_fr1
> (integration.component.test_egress_fw_rules.TestEgressFWRules): DEBUG:
> Request:
> http://10.223.49.197:8080/client/api?apiKey=xD2wDZTvUzDtHF5SAMlCud-rv-Li61wOoIYy8KLUHKIHUqxoe0gSvxoi57iu2_h5fMnVzwH9U5FTYmDv8rCgbQ&name=expunge.interval&command=listConfigurations&signature=QTt2mo%2FRMKOAzjJuTeJUvdn7NgQ%3D&response=json&listall=True
> Response: { "listconfigurationsresponse" : { "count":1 ,"configuration" : [
> {"category":"Advanced","name":"expunge.interval","value":"60","description":"The
> interval (in seconds) to wait before running the expunge thread."} ] } }
> test_01_1_egress_fr1
> (integration.component.test_egress_fw_rules.TestEgressFWRules): DEBUG:
> sending GET request: listConfigurations {'name': 'expunge.delay', 'listall':
> True}
> test_01_1_egress_fr1
> (integration.component.test_egress_fw_rules.TestEgressFWRules): DEBUG:
> Computed Signature by Marvin: C8BlUCJKbFRmvpjVRJjHaEiVPsk=
> requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection
> (1): 10.223.49.197
> requests.packages.urllib3.connectionpool: DEBUG: "GET
> /client/api?apiKey=xD2wDZTvUzDtHF5SAMlCud-rv-Li61wOoIYy8KLUHKIHUqxoe0gSvxoi57iu2_h5fMnVzwH9U5FTYmDv8rCgbQ&name=expunge.delay&command=listConfigurations&signature=C8BlUCJKbFRmvpjVRJjHaEiVPsk%3D&response=json&listall=True
> HTTP/1.1" 200 287
> test_01_1_egress_fr1
> (integration.component.test_egress_fw_rules.TestEgressFWRules): DEBUG:
> Request:
> http://10.223.49.197:8080/client/api?apiKey=xD2wDZTvUzDtHF5SAMlCud-rv-Li61wOoIYy8KLUHKIHUqxoe0gSvxoi57iu2_h5fMnVzwH9U5FTYmDv8rCgbQ&name=expunge.delay&command=listConfigurations&signature=C8BlUCJKbFRmvpjVRJjHaEiVPsk%3D&response=json&listall=True
> Response: { "listconfigurationsresponse" : { "count":1 ,"configuration" : [
> {"category":"Advanced","name":"expunge.delay","value":"60","description":"Determines
> how long (in seconds) to wait before actually expunging destroyed vm. The
> default value = the default value of expunge.interval"} ] } }
> test_01_1_egress_fr1
> (integration.component.test_egress_fw_rules.TestEgressFWRules): CRITICAL:
> EXCEPTION: test_01_1_egress_fr1: Traceback (most recent call last):
> File "/usr/local/lib/python2.7/unittest/case.py", line 345, in run
> self.tearDown()
> File
> "/data/Repo2/qa/cloudstack/test/integration/component/test_egress_fw_rules.py",
> line 397, in tearDown
> self.fail("Warning! Cleanup failed: %s" % e)
> File "/usr/local/lib/python2.7/unittest/case.py", line 393, in fail
> raise self.failureException(msg)
> AssertionError: Warning! Cleanup failed: global name 'list_virtual_machines'
> is not defined
> - >> end captured logging << -
> Stacktrace
> File "/usr/local/lib/python2.7/unittest/case.py", line 345, in run
> self.tearDown()
> File
> "/data/Repo2/qa/cloudstack/test/integration/component/test_egress_fw_rules.py",
> line 397, in tearDown
> self.fail("Warning! Cleanup failed: %s" % e)
> File "/usr/local/lib/python2.7/unittest/case.py", line 393, in fail
> raise self.failureExcept
[jira] [Commented] (CLOUDSTACK-5506) [Automation] component.test_egress_fw_rules test cases failed with error "global name 'list_virtual_machines' is not defined"
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5506?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13848923#comment-13848923
]
ASF subversion and git services commented on CLOUDSTACK-5506:
-
Commit 75f4f55c3555c3707e651f06b5a68509450a19fa in branch refs/heads/master
from [~gpshilamkar]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=75f4f55 ]
CLOUDSTACK-5506: Fixed egress_fw_rules.py, one of hunks was missing.
> [Automation] component.test_egress_fw_rules test cases failed with error
> "global name 'list_virtual_machines' is not defined"
> -
>
> Key: CLOUDSTACK-5506
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5506
> Project: CloudStack
> Issue Type: Test
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Automation
>Affects Versions: 4.3.0
> Environment: Automation
>Reporter: Rayees Namathponnan
>Assignee: Girish Shilamkar
> Fix For: 4.3.0
>
>
> 26 test case from suite integration.component.test_egress_fw_rules failed
> with error
> Error Message
> Warning! Cleanup failed: global name 'list_virtual_machines' is not defined
> >> begin captured logging <<
> CSLog: DEBUG: sending GET request: listDomains {}
> requests.packages.urllib3.connectionpool: DEBUG: "GET
> /client/api?apiKey=xD2wDZTvUzDtHF5SAMlCud-rv-Li61wOoIYy8KLUHKIHUqxoe0gSvxoi57iu2_h5fMnVzwH9U5FTYmDv8rCgbQ&name=expunge.interval&command=listConfigurations&signature=QTt2mo%2FRMKOAzjJuTeJUvdn7NgQ%3D&response=json&listall=True
> HTTP/1.1" 200 220
> test_01_1_egress_fr1
> (integration.component.test_egress_fw_rules.TestEgressFWRules): DEBUG:
> Request:
> http://10.223.49.197:8080/client/api?apiKey=xD2wDZTvUzDtHF5SAMlCud-rv-Li61wOoIYy8KLUHKIHUqxoe0gSvxoi57iu2_h5fMnVzwH9U5FTYmDv8rCgbQ&name=expunge.interval&command=listConfigurations&signature=QTt2mo%2FRMKOAzjJuTeJUvdn7NgQ%3D&response=json&listall=True
> Response: { "listconfigurationsresponse" : { "count":1 ,"configuration" : [
> {"category":"Advanced","name":"expunge.interval","value":"60","description":"The
> interval (in seconds) to wait before running the expunge thread."} ] } }
> test_01_1_egress_fr1
> (integration.component.test_egress_fw_rules.TestEgressFWRules): DEBUG:
> sending GET request: listConfigurations {'name': 'expunge.delay', 'listall':
> True}
> test_01_1_egress_fr1
> (integration.component.test_egress_fw_rules.TestEgressFWRules): DEBUG:
> Computed Signature by Marvin: C8BlUCJKbFRmvpjVRJjHaEiVPsk=
> requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection
> (1): 10.223.49.197
> requests.packages.urllib3.connectionpool: DEBUG: "GET
> /client/api?apiKey=xD2wDZTvUzDtHF5SAMlCud-rv-Li61wOoIYy8KLUHKIHUqxoe0gSvxoi57iu2_h5fMnVzwH9U5FTYmDv8rCgbQ&name=expunge.delay&command=listConfigurations&signature=C8BlUCJKbFRmvpjVRJjHaEiVPsk%3D&response=json&listall=True
> HTTP/1.1" 200 287
> test_01_1_egress_fr1
> (integration.component.test_egress_fw_rules.TestEgressFWRules): DEBUG:
> Request:
> http://10.223.49.197:8080/client/api?apiKey=xD2wDZTvUzDtHF5SAMlCud-rv-Li61wOoIYy8KLUHKIHUqxoe0gSvxoi57iu2_h5fMnVzwH9U5FTYmDv8rCgbQ&name=expunge.delay&command=listConfigurations&signature=C8BlUCJKbFRmvpjVRJjHaEiVPsk%3D&response=json&listall=True
> Response: { "listconfigurationsresponse" : { "count":1 ,"configuration" : [
> {"category":"Advanced","name":"expunge.delay","value":"60","description":"Determines
> how long (in seconds) to wait before actually expunging destroyed vm. The
> default value = the default value of expunge.interval"} ] } }
> test_01_1_egress_fr1
> (integration.component.test_egress_fw_rules.TestEgressFWRules): CRITICAL:
> EXCEPTION: test_01_1_egress_fr1: Traceback (most recent call last):
> File "/usr/local/lib/python2.7/unittest/case.py", line 345, in run
> self.tearDown()
> File
> "/data/Repo2/qa/cloudstack/test/integration/component/test_egress_fw_rules.py",
> line 397, in tearDown
> self.fail("Warning! Cleanup failed: %s" % e)
> File "/usr/local/lib/python2.7/unittest/case.py", line 393, in fail
> raise self.failureException(msg)
> AssertionError: Warning! Cleanup failed: global name 'list_virtual_machines'
> is not defined
> - >> end captured logging << -
> Stacktrace
> File "/usr/local/lib/python2.7/unittest/case.py", line 345, in run
> self.tearDown()
> File
> "/data/Repo2/qa/cloudstack/test/integration/component/test_egress_fw_rules.py",
> line 397, in tearDown
> self.fail("Warning! Cleanup failed: %s" % e)
> File "/usr/local/lib/python2.7/unittest/case.py", line 393, in fail
> raise self.failureExc
[jira] [Resolved] (CLOUDSTACK-5506) [Automation] component.test_egress_fw_rules test cases failed with error "global name 'list_virtual_machines' is not defined"
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5506?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Girish Shilamkar resolved CLOUDSTACK-5506.
--
Resolution: Fixed
Fix Version/s: 4.4.0
4.2.1
Committed to 4.2, 4.3 and master
> [Automation] component.test_egress_fw_rules test cases failed with error
> "global name 'list_virtual_machines' is not defined"
> -
>
> Key: CLOUDSTACK-5506
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5506
> Project: CloudStack
> Issue Type: Test
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Automation
>Affects Versions: 4.3.0
> Environment: Automation
>Reporter: Rayees Namathponnan
>Assignee: Girish Shilamkar
> Fix For: 4.2.1, 4.3.0, 4.4.0
>
>
> 26 test case from suite integration.component.test_egress_fw_rules failed
> with error
> Error Message
> Warning! Cleanup failed: global name 'list_virtual_machines' is not defined
> >> begin captured logging <<
> CSLog: DEBUG: sending GET request: listDomains {}
> requests.packages.urllib3.connectionpool: DEBUG: "GET
> /client/api?apiKey=xD2wDZTvUzDtHF5SAMlCud-rv-Li61wOoIYy8KLUHKIHUqxoe0gSvxoi57iu2_h5fMnVzwH9U5FTYmDv8rCgbQ&name=expunge.interval&command=listConfigurations&signature=QTt2mo%2FRMKOAzjJuTeJUvdn7NgQ%3D&response=json&listall=True
> HTTP/1.1" 200 220
> test_01_1_egress_fr1
> (integration.component.test_egress_fw_rules.TestEgressFWRules): DEBUG:
> Request:
> http://10.223.49.197:8080/client/api?apiKey=xD2wDZTvUzDtHF5SAMlCud-rv-Li61wOoIYy8KLUHKIHUqxoe0gSvxoi57iu2_h5fMnVzwH9U5FTYmDv8rCgbQ&name=expunge.interval&command=listConfigurations&signature=QTt2mo%2FRMKOAzjJuTeJUvdn7NgQ%3D&response=json&listall=True
> Response: { "listconfigurationsresponse" : { "count":1 ,"configuration" : [
> {"category":"Advanced","name":"expunge.interval","value":"60","description":"The
> interval (in seconds) to wait before running the expunge thread."} ] } }
> test_01_1_egress_fr1
> (integration.component.test_egress_fw_rules.TestEgressFWRules): DEBUG:
> sending GET request: listConfigurations {'name': 'expunge.delay', 'listall':
> True}
> test_01_1_egress_fr1
> (integration.component.test_egress_fw_rules.TestEgressFWRules): DEBUG:
> Computed Signature by Marvin: C8BlUCJKbFRmvpjVRJjHaEiVPsk=
> requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection
> (1): 10.223.49.197
> requests.packages.urllib3.connectionpool: DEBUG: "GET
> /client/api?apiKey=xD2wDZTvUzDtHF5SAMlCud-rv-Li61wOoIYy8KLUHKIHUqxoe0gSvxoi57iu2_h5fMnVzwH9U5FTYmDv8rCgbQ&name=expunge.delay&command=listConfigurations&signature=C8BlUCJKbFRmvpjVRJjHaEiVPsk%3D&response=json&listall=True
> HTTP/1.1" 200 287
> test_01_1_egress_fr1
> (integration.component.test_egress_fw_rules.TestEgressFWRules): DEBUG:
> Request:
> http://10.223.49.197:8080/client/api?apiKey=xD2wDZTvUzDtHF5SAMlCud-rv-Li61wOoIYy8KLUHKIHUqxoe0gSvxoi57iu2_h5fMnVzwH9U5FTYmDv8rCgbQ&name=expunge.delay&command=listConfigurations&signature=C8BlUCJKbFRmvpjVRJjHaEiVPsk%3D&response=json&listall=True
> Response: { "listconfigurationsresponse" : { "count":1 ,"configuration" : [
> {"category":"Advanced","name":"expunge.delay","value":"60","description":"Determines
> how long (in seconds) to wait before actually expunging destroyed vm. The
> default value = the default value of expunge.interval"} ] } }
> test_01_1_egress_fr1
> (integration.component.test_egress_fw_rules.TestEgressFWRules): CRITICAL:
> EXCEPTION: test_01_1_egress_fr1: Traceback (most recent call last):
> File "/usr/local/lib/python2.7/unittest/case.py", line 345, in run
> self.tearDown()
> File
> "/data/Repo2/qa/cloudstack/test/integration/component/test_egress_fw_rules.py",
> line 397, in tearDown
> self.fail("Warning! Cleanup failed: %s" % e)
> File "/usr/local/lib/python2.7/unittest/case.py", line 393, in fail
> raise self.failureException(msg)
> AssertionError: Warning! Cleanup failed: global name 'list_virtual_machines'
> is not defined
> - >> end captured logging << -
> Stacktrace
> File "/usr/local/lib/python2.7/unittest/case.py", line 345, in run
> self.tearDown()
> File
> "/data/Repo2/qa/cloudstack/test/integration/component/test_egress_fw_rules.py",
> line 397, in tearDown
> self.fail("Warning! Cleanup failed: %s" % e)
> File "/usr/local/lib/python2.7/unittest/case.py", line 393, in fail
> raise self.failureException(msg)
> Warning! Cleanup failed: global name 'list_virtual_machines' is not defined
> >> begin captured logging <<
> CSLog: DEBUG: sending GET request: l
[jira] [Updated] (CLOUDSTACK-5403) Shared network - None of PF, LB rules work after router restart, firewall rules dropped from iptables post restart
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5403?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rajesh Battala updated CLOUDSTACK-5403: --- Assignee: (was: Rajesh Battala) > Shared network - None of PF, LB rules work after router restart, firewall > rules dropped from iptables post restart > -- > > Key: CLOUDSTACK-5403 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5403 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server, Network Controller >Affects Versions: 4.3.0 > Environment: Advanced zone, shared network on Hyper-V >Reporter: Sowmya Krishnan >Priority: Critical > Fix For: 4.3.0 > > Attachments: iptables_after_restart.gz, iptables_before_restart.gz, > restart_vr.log.gz, restart_vr_agent.log.log > > > None of PF, LB or firewall rules work after router is restarted in shared > network, advanced zone > Steps: > Create a shared network in advanced zone > Acquire IP > Create PF and corresponding Firewall rule > Acquire another IP > Create LB and corresponding Firewall rule > Ensure all the rules work > Restart router > Check all rules > Result: > None of PF or LB rules work after router restart > I've tested this only in Hypev-V so far. I'll update the bug in case I am > able to test in any other hypervisor as well. > The following rules are dropped from iptables FORWARD chain after restart: > ACCEPT tcp -- anywhere shareduser1vm1 state > RELATED,ESTABLISHED /* 10.102.196.239:888:888 */ > ACCEPT tcp -- anywhere shareduser1vm1 tcp dpt:http > state NEW /* 10.102.196.239:888:888 */ > So also the firewall rules corresponding to the LB rule source ip > The rules themselves exist in DB though: > mysql> select * from firewall_rules; > ++--+---++--++--+++---++--+-+---+---+-+--++--+ > | id | uuid | ip_address_id | start_port | > end_port | state | protocol | purpose| account_id | domain_id | > network_id | xid | created | > icmp_code | icmp_type | related | type | vpc_id | traffic_type | > ++--+---++--++--+++---++--+-+---+---+-+--++--+ > | 1 | b9082345-8a3d-4f6d-9b64-3d2d98e65d2d | 5 |888 | > 888 | Active | tcp | Firewall | 4 | 2 | > 205 | 5cf27b56-4d37-4ec1-bdf8-ede0407f0115 | 2013-12-06 06:51:40 | NULL > | NULL |NULL | User | NULL | Ingress | > | 2 | 5b657e22-649a-4cd4-b23c-2416243f48ba | 5 |888 | > 888 | Active | tcp | PortForwarding | 4 | 2 | > 205 | aad0e89d-f0df-4ee2-949d-39f129a1383a | 2013-12-06 06:52:13 | NULL > | NULL |NULL | User | NULL | NULL | > | 13 | 42f795f9-45e6-471f-9b17-4ce631a09531 | 6 |888 | > 888 | Active | tcp | Firewall | 4 | 2 | > 205 | 0802945b-23b8-4b95-9441-f6b89e66d806 | 2013-12-06 11:27:08 | NULL > | NULL |NULL | User | NULL | Ingress | > | 14 | 9f5aa3dd-b8e9-4193-b635-c5fd7e188f35 | 6 |888 | > 888 | Active | tcp | LoadBalancing | 4 | 2 | > 205 | ef7067b9-38b3-4d42-b8ee-5bfe44a817fa | 2013-12-06 11:27:53 | NULL > | NULL |NULL | User | NULL | NULL | > ++--+---++--++--+++---++--+-+---+---+-+--++--+ > 4 rows in set (0.00 sec) > mysql> select * from load_balancing_rules; > ++--+-++--++---+--++-+ > | id | name | description | default_port_start | default_port_end | > algorithm | source_ip_address | source_ip_address_network_id | scheme | > lb_protocol | > ++--+-++--++---+--
[jira] [Commented] (CLOUDSTACK-5188) Password reset of vm on Xen and VMware does not work on first reboot
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13848933#comment-13848933 ] Jayapal Reddy commented on CLOUDSTACK-5188: --- Hi, I tried password reset with xenserver host using the script http://people.apache.org/~tsp/cloud-set-guest-password. Enabled debug in the script (set -x). I did could not reproduced this issue in xen. If it is reproduces again, please attach the below mentioned logs. 1. MS logs 2. Password entries in VR before and after VM boot. (/var/cache/cloud/password) 3. Enable debug in password script and attach the logs password script on VM start. Please find the blow logs: Before Vm reboot: root@r-4-VM:~# cat /var/cache/cloud/passwords 10.1.1.171=saved_password 10.1.1.4=vT9nithuq After VM reboot: root@r-4-VM:~# cat /var/cache/cloud/passwords 10.1.1.171=saved_password 10.1.1.4=saved_password logs from the VM boot: + logger -t cloud 'Sending request to password server at 10.1.1.1' ++ wget -q -t 3 -T 20 -O - --header 'DomU_Request: send_my_password' 10.1.1.1:8080 + password=$'vT9nithuq\r' ++ echo $'vT9nithuq\r' ++ tr -d '\r' + password=vT9nithuq + '[' 0 -eq 0 ']' + logger -t cloud 'Got response from server at 10.1.1.1' + case $password in + logger -t cloud 'VM got a valid password from server at 10.1.1.1' + password_received=1 + break + '[' 1 == 0 ']' + logger -t cloud 'Changing password ...' + echo vT9nithuq + passwd --stdin root > Password reset of vm on Xen and VMware does not work on first reboot > > > Key: CLOUDSTACK-5188 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5188 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Test >Affects Versions: 4.2.1, 4.3.0 > Environment: VMware and Xen >Reporter: Girish Shilamkar >Assignee: Jayapal Reddy >Priority: Blocker > > The issue was uncovered as test_vm_passwdenabled.py was consistently failing > on Vmware and Xen. Note this issue is not seen on KVM. > Procedure: > 1. Create a vm > 2. Enable password management. In vm do following: > $ cd /etc/init.d > $ wget http://people.apache.org/~tsp/cloud-set-guest-password > $ chmod +x /etc/init.d/cloud-set-guest-password > $ chkconfig --add cloud-set-guest-password > 3. Stop vm > 4. Create template from vm's volume > 5. Delete vm > 6. Create new vm from template created in step 4 > 7. Stop vm > 8. Reset password > 9. Start vm > 10. Ssh to vm using password obtained in step 8 > The ssh to vm using new password will fail but ssh with old password works > Now if vm is stopped and started again, the new password will work. Thus > password is reset only on the second boot. -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Resolved] (CLOUDSTACK-5188) Password reset of vm on Xen and VMware does not work on first reboot
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5188?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jayapal Reddy resolved CLOUDSTACK-5188. --- Resolution: Cannot Reproduce > Password reset of vm on Xen and VMware does not work on first reboot > > > Key: CLOUDSTACK-5188 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5188 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Test >Affects Versions: 4.2.1, 4.3.0 > Environment: VMware and Xen >Reporter: Girish Shilamkar >Assignee: Jayapal Reddy >Priority: Blocker > > The issue was uncovered as test_vm_passwdenabled.py was consistently failing > on Vmware and Xen. Note this issue is not seen on KVM. > Procedure: > 1. Create a vm > 2. Enable password management. In vm do following: > $ cd /etc/init.d > $ wget http://people.apache.org/~tsp/cloud-set-guest-password > $ chmod +x /etc/init.d/cloud-set-guest-password > $ chkconfig --add cloud-set-guest-password > 3. Stop vm > 4. Create template from vm's volume > 5. Delete vm > 6. Create new vm from template created in step 4 > 7. Stop vm > 8. Reset password > 9. Start vm > 10. Ssh to vm using password obtained in step 8 > The ssh to vm using new password will fail but ssh with old password works > Now if vm is stopped and started again, the new password will work. Thus > password is reset only on the second boot. -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Commented] (CLOUDSTACK-5321) [Hyper-V] No default cent os template available for Hyper-V
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13848934#comment-13848934 ] Rajesh Battala commented on CLOUDSTACK-5321: I had generated the new template. Need to push the db entry patch. Will push the patch after testing it. > [Hyper-V] No default cent os template available for Hyper-V > --- > > Key: CLOUDSTACK-5321 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5321 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Hypervisor Controller, Management Server >Affects Versions: 4.3.0 > Environment: Latest build from 4.3 >Reporter: Sanjeev N >Assignee: Rajesh Battala >Priority: Critical > Labels: hyper-V, > Fix For: 4.3.0 > > > [Hyper-V] No default cent os template available for Hyper-V > For all the existing hyeprvisors(e.g.xen,kvm,vmware) we have a corresponding > default cent os template entry in vm_template. Also these default templates > would get downloaded to secondary storage as and when the SSVM is up. This is > not happening with Hyper-v. > No default cent-os template entry is found in the vm_template table. -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Assigned] (CLOUDSTACK-5267) [Automation] instance.name name should not append with VM's Name
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Girish Shilamkar reassigned CLOUDSTACK-5267: Assignee: Girish Shilamkar (was: Gaurav Aradhye) > [Automation] instance.name name should not append with VM's Name > > > Key: CLOUDSTACK-5267 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5267 > Project: CloudStack > Issue Type: Test > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation >Affects Versions: 4.3.0 > Environment: Branch : 4.3.0 >Reporter: Rayees Namathponnan >Assignee: Girish Shilamkar >Priority: Blocker > Labels: automation > Fix For: 4.3.0 > > > Steps to reproduce > Step 1 : set instance.name=TestVM in global parameter > Step 2 : Restart MS and Deploy Vm, dont specify any name while deploying the > VM > Actual Result > UUID of new VM is 56276ab1-3353-473c-8b35-f27f81f68bd8, and vm should be > deployed with name "56276ab1-3353-473c-8b35-f27f81f68bd8" > vm deployed with name TestVM56276ab1-3353-473c-8b35-f27f81f68bd8, here > instance.name also included > We need to remove instance.name from vm name -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Commented] (CLOUDSTACK-5267) [Automation] instance.name name should not append with VM's Name
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13848970#comment-13848970 ] Girish Shilamkar commented on CLOUDSTACK-5267: -- Rayees, Which testcase is failing ? I see that test_01_cusom_hostname_instancename_flase is passing. Regards, Girish > [Automation] instance.name name should not append with VM's Name > > > Key: CLOUDSTACK-5267 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5267 > Project: CloudStack > Issue Type: Test > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation >Affects Versions: 4.3.0 > Environment: Branch : 4.3.0 >Reporter: Rayees Namathponnan >Assignee: Girish Shilamkar >Priority: Blocker > Labels: automation > Fix For: 4.3.0 > > > Steps to reproduce > Step 1 : set instance.name=TestVM in global parameter > Step 2 : Restart MS and Deploy Vm, dont specify any name while deploying the > VM > Actual Result > UUID of new VM is 56276ab1-3353-473c-8b35-f27f81f68bd8, and vm should be > deployed with name "56276ab1-3353-473c-8b35-f27f81f68bd8" > vm deployed with name TestVM56276ab1-3353-473c-8b35-f27f81f68bd8, here > instance.name also included > We need to remove instance.name from vm name -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Created] (CLOUDSTACK-5514) Response of listAccounts API call includes removed users
Likitha Shetty created CLOUDSTACK-5514: -- Summary: Response of listAccounts API call includes removed users Key: CLOUDSTACK-5514 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5514 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: API Affects Versions: 4.2.0 Reporter: Likitha Shetty Assignee: Likitha Shetty Fix For: 4.3.0 Removed users should not be listed in listAccounts API response -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Assigned] (CLOUDSTACK-5342) Add NIC to virtual machine fails in KVM
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gaurav Aradhye reassigned CLOUDSTACK-5342:
--
Assignee: Gaurav Aradhye (was: Marcus Sorensen)
> Add NIC to virtual machine fails in KVM
> ---
>
> Key: CLOUDSTACK-5342
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5342
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Network Controller
>Affects Versions: 4.3.0
> Environment: KVM advanced
>Reporter: Gaurav Aradhye
>Assignee: Gaurav Aradhye
>Priority: Blocker
> Fix For: 4.3.0
>
>
> Add network to VM test cases fail in KVM with following error.
> Execute cmd: asyncquery failed, due to: {errorcode : 530, errortext :
> u'Unable to add NIC to VM[User|VM-e9350ee5-bf2e-418c-91d6-1535dcb4d488]'}
> The same test cases execute successfully on XenServer. As per the feature
> specification (see
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Add+Remove+Networks+to+VMs),
> "Add network to VM" feature should be supported on KVM too.
--
This message was sent by Atlassian JIRA
(v6.1.4#6159)
[jira] [Commented] (CLOUDSTACK-5514) Response of listAccounts API call includes removed users
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13849004#comment-13849004 ] ASF subversion and git services commented on CLOUDSTACK-5514: - Commit 6b7ea7f90d7f81f983b77df86b651e010a8d3a06 in branch refs/heads/4.3 from [~likithas] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=6b7ea7f ] CLOUDSTACK-5514. Response of listAccounts API call includes removed users > Response of listAccounts API call includes removed users > > > Key: CLOUDSTACK-5514 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5514 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: API >Affects Versions: 4.2.0 >Reporter: Likitha Shetty >Assignee: Likitha Shetty > Fix For: 4.3.0 > > > Removed users should not be listed in listAccounts API response -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Resolved] (CLOUDSTACK-5514) Response of listAccounts API call includes removed users
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5514?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Likitha Shetty resolved CLOUDSTACK-5514. Resolution: Fixed > Response of listAccounts API call includes removed users > > > Key: CLOUDSTACK-5514 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5514 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: API >Affects Versions: 4.2.0 >Reporter: Likitha Shetty >Assignee: Likitha Shetty > Fix For: 4.3.0 > > > Removed users should not be listed in listAccounts API response -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Commented] (CLOUDSTACK-5514) Response of listAccounts API call includes removed users
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13849007#comment-13849007 ] ASF subversion and git services commented on CLOUDSTACK-5514: - Commit 7cac5aa9fc1ad8e8aafd9189020d594059625db3 in branch refs/heads/master from [~likithas] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=7cac5aa ] CLOUDSTACK-5514. Response of listAccounts API call includes removed users > Response of listAccounts API call includes removed users > > > Key: CLOUDSTACK-5514 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5514 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: API >Affects Versions: 4.2.0 >Reporter: Likitha Shetty >Assignee: Likitha Shetty > Fix For: 4.3.0 > > > Removed users should not be listed in listAccounts API response -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Commented] (CLOUDSTACK-2428) HA - When the master host is disconnected , the host status contines to remain in "Up" state because of com.cloud.utils.exception.CloudRuntimeException: Unable to
[
https://issues.apache.org/jira/browse/CLOUDSTACK-2428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13849010#comment-13849010
]
Koushik Das commented on CLOUDSTACK-2428:
-
Sangeetha,
I am not abe to repro the issue. The MS logs also doesn't say much. If you are
able to repro the issue again can you share the setup if possible?
-Koushik
> HA - When the master host is disconnected , the host status contines to
> remain in "Up" state because of
> com.cloud.utils.exception.CloudRuntimeException: Unable to reset master of
> slave
> -
>
> Key: CLOUDSTACK-2428
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2428
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server
>Affects Versions: 4.2.0, 4.3.0
> Environment: Build from pvaln
>Reporter: Sangeetha Hariharan
>Assignee: Koushik Das
>Priority: Critical
> Fix For: 4.2.0, 4.3.0
>
> Attachments: hostdown.rar, hostdown.rar, logs.rar, logs_7_29,
> management-server.rar
>
>
> 1. Advance zone with 1 cluster with 2 hosts. Create Shared network with
> private vlan.
> 2. Deploy few HA enabled Vms in this network.
> 3. pull network cable for one of the host.
> When cloudstack detects that the host is disconnected , it is not able to out
> the host in disconnected state and start HA for Vms that are HA enabeld,
> I see the following exception in the management server logs:
> 2013-05-09 17:15:55,576 DEBUG [agent.manager.DirectAgentAttache]
> (DirectAgent-267:null) Seq 1-1435828229: Executing request
> 2013-05-09 17:15:55,602 DEBUG [xen.resource.XenServerConnectionPool]
> (DirectAgent-267:null) Catch Exception:
> com.xensource.xenapi.Types$HostOffline Host is offline 10.223.81.62 due to
> You attempted an operation which involves a host which could not be contacted.
> 2013-05-09 17:15:55,603 DEBUG [xen.resource.XenServerConnectionPool]
> (DirectAgent-267:null) Trying to reset master of slave 10.223.81.62 to
> 10.223.81.61
> 2013-05-09 17:16:02,319 WARN [xen.resource.CitrixResourceBase]
> (DirectAgent-265:null) can not ping xenserver
> 520d4994-8b1f-4dda-b51d-2ee63750abf6
> 2013-05-09 17:16:02,319 WARN [agent.manager.DirectAgentAttache]
> (DirectAgent-265:null) Unable to get current status on 1
> 2013-05-09 17:16:02,321 INFO [agent.manager.AgentManagerImpl]
> (AgentTaskPool-11:null) Investigating why host 1 has disconnected with event
> AgentDisconnected
> 2013-05-09 17:16:02,321 DEBUG [agent.manager.AgentManagerImpl]
> (AgentTaskPool-11:null) checking if agent (1) is alive
> 2013-05-09 17:16:02,323 DEBUG [agent.transport.Request]
> (AgentTaskPool-11:null) Seq 1-1435828294: Sending { Cmd , MgmtId:
> 7647994577963, via: 1, Ver: v1, Flags: 100011,
> [{"CheckHealthCommand":{"wait":50}}] }
> 2013-05-09 17:16:02,323 DEBUG [agent.transport.Request]
> (AgentTaskPool-11:null) Seq 1-1435828294: Executing: { Cmd , MgmtId:
> 7647994577963, via: 1, Ver: v1, Flags: 100011,
> [{"CheckHealthCommand":{"wait":50}}] }
> 2013-05-09 17:16:02,323 DEBUG [agent.manager.DirectAgentAttache]
> (DirectAgent-271:null) Seq 1-1435828294: Executing request
> 2013-05-09 17:16:04,035 DEBUG [agent.manager.AgentAttache]
> (AgentTaskPool-10:null) Seq 6-474349576: Waiting some more time because this
> is the current command
> 2013-05-09 17:16:04,040 DEBUG [xen.resource.XenServerConnectionPool]
> (DirectAgent-268:null) localLogout has problem Failed to read server's
> response: connect timed out
> 2013-05-09 17:16:04,040 WARN [agent.manager.DirectAgentAttache]
> (DirectAgent-268:null) Seq 1-1435828292: Exception Caught while executing
> command
> com.cloud.utils.exception.CloudRuntimeException: Unable to reset master of
> slave 10.223.81.62 to 10.223.81.61 due to org.apache.xmlrpc.XmlRpcException:
> Failed to read server's response: connect timed out
> at
> com.cloud.hypervisor.xen.resource.XenServerConnectionPool.PoolEmergencyResetMaster(XenServerConnectionPool.java:443)
> at
> com.cloud.hypervisor.xen.resource.XenServerConnectionPool.connect(XenServerConnectionPool.java:661)
> at
> com.cloud.hypervisor.xen.resource.CitrixResourceBase.getConnection(CitrixResourceBase.java:5639)
> at
> com.cloud.hypervisor.xen.resource.CitrixResourceBase.execute(CitrixResourceBase.java:1682)
> at
> com.cloud.hypervisor.xen.resource.CitrixResourceBase.executeRequest(CitrixResourceBase.java:524)
> at
> com.cloud.hypervisor.xen.resource.XenServer56Resource.executeRequest(XenServer56Resource.java:73)
> at
> com.cloud.hype
[jira] [Assigned] (CLOUDSTACK-2428) HA - When the master host is disconnected , the host status contines to remain in "Up" state because of com.cloud.utils.exception.CloudRuntimeException: Unable to r
[
https://issues.apache.org/jira/browse/CLOUDSTACK-2428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Koushik Das reassigned CLOUDSTACK-2428:
---
Assignee: Sangeetha Hariharan (was: Koushik Das)
> HA - When the master host is disconnected , the host status contines to
> remain in "Up" state because of
> com.cloud.utils.exception.CloudRuntimeException: Unable to reset master of
> slave
> -
>
> Key: CLOUDSTACK-2428
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2428
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server
>Affects Versions: 4.2.0, 4.3.0
> Environment: Build from pvaln
>Reporter: Sangeetha Hariharan
>Assignee: Sangeetha Hariharan
>Priority: Critical
> Fix For: 4.2.0, 4.3.0
>
> Attachments: hostdown.rar, hostdown.rar, logs.rar, logs_7_29,
> management-server.rar
>
>
> 1. Advance zone with 1 cluster with 2 hosts. Create Shared network with
> private vlan.
> 2. Deploy few HA enabled Vms in this network.
> 3. pull network cable for one of the host.
> When cloudstack detects that the host is disconnected , it is not able to out
> the host in disconnected state and start HA for Vms that are HA enabeld,
> I see the following exception in the management server logs:
> 2013-05-09 17:15:55,576 DEBUG [agent.manager.DirectAgentAttache]
> (DirectAgent-267:null) Seq 1-1435828229: Executing request
> 2013-05-09 17:15:55,602 DEBUG [xen.resource.XenServerConnectionPool]
> (DirectAgent-267:null) Catch Exception:
> com.xensource.xenapi.Types$HostOffline Host is offline 10.223.81.62 due to
> You attempted an operation which involves a host which could not be contacted.
> 2013-05-09 17:15:55,603 DEBUG [xen.resource.XenServerConnectionPool]
> (DirectAgent-267:null) Trying to reset master of slave 10.223.81.62 to
> 10.223.81.61
> 2013-05-09 17:16:02,319 WARN [xen.resource.CitrixResourceBase]
> (DirectAgent-265:null) can not ping xenserver
> 520d4994-8b1f-4dda-b51d-2ee63750abf6
> 2013-05-09 17:16:02,319 WARN [agent.manager.DirectAgentAttache]
> (DirectAgent-265:null) Unable to get current status on 1
> 2013-05-09 17:16:02,321 INFO [agent.manager.AgentManagerImpl]
> (AgentTaskPool-11:null) Investigating why host 1 has disconnected with event
> AgentDisconnected
> 2013-05-09 17:16:02,321 DEBUG [agent.manager.AgentManagerImpl]
> (AgentTaskPool-11:null) checking if agent (1) is alive
> 2013-05-09 17:16:02,323 DEBUG [agent.transport.Request]
> (AgentTaskPool-11:null) Seq 1-1435828294: Sending { Cmd , MgmtId:
> 7647994577963, via: 1, Ver: v1, Flags: 100011,
> [{"CheckHealthCommand":{"wait":50}}] }
> 2013-05-09 17:16:02,323 DEBUG [agent.transport.Request]
> (AgentTaskPool-11:null) Seq 1-1435828294: Executing: { Cmd , MgmtId:
> 7647994577963, via: 1, Ver: v1, Flags: 100011,
> [{"CheckHealthCommand":{"wait":50}}] }
> 2013-05-09 17:16:02,323 DEBUG [agent.manager.DirectAgentAttache]
> (DirectAgent-271:null) Seq 1-1435828294: Executing request
> 2013-05-09 17:16:04,035 DEBUG [agent.manager.AgentAttache]
> (AgentTaskPool-10:null) Seq 6-474349576: Waiting some more time because this
> is the current command
> 2013-05-09 17:16:04,040 DEBUG [xen.resource.XenServerConnectionPool]
> (DirectAgent-268:null) localLogout has problem Failed to read server's
> response: connect timed out
> 2013-05-09 17:16:04,040 WARN [agent.manager.DirectAgentAttache]
> (DirectAgent-268:null) Seq 1-1435828292: Exception Caught while executing
> command
> com.cloud.utils.exception.CloudRuntimeException: Unable to reset master of
> slave 10.223.81.62 to 10.223.81.61 due to org.apache.xmlrpc.XmlRpcException:
> Failed to read server's response: connect timed out
> at
> com.cloud.hypervisor.xen.resource.XenServerConnectionPool.PoolEmergencyResetMaster(XenServerConnectionPool.java:443)
> at
> com.cloud.hypervisor.xen.resource.XenServerConnectionPool.connect(XenServerConnectionPool.java:661)
> at
> com.cloud.hypervisor.xen.resource.CitrixResourceBase.getConnection(CitrixResourceBase.java:5639)
> at
> com.cloud.hypervisor.xen.resource.CitrixResourceBase.execute(CitrixResourceBase.java:1682)
> at
> com.cloud.hypervisor.xen.resource.CitrixResourceBase.executeRequest(CitrixResourceBase.java:524)
> at
> com.cloud.hypervisor.xen.resource.XenServer56Resource.executeRequest(XenServer56Resource.java:73)
> at
> com.cloud.hypervisor.xen.resource.XenServer610Resource.executeRequest(XenServer610Resource.java:102)
> at
> com.cloud.agent.manager.DirectAgentAttache$Task.run(Di
[jira] [Created] (CLOUDSTACK-5515) #cpu ,cpuspeed and ram is set to NULL in usage db(vm_instance table) after vm stop and start
prashant kumar mishra created CLOUDSTACK-5515: - Summary: #cpu ,cpuspeed and ram is set to NULL in usage db(vm_instance table) after vm stop and start Key: CLOUDSTACK-5515 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5515 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Usage Affects Versions: 4.3.0 Reporter: prashant kumar mishra Priority: Critical Fix For: 4.3.0 Steps to reproduce - 1-prapare a CS setup + install usage server 2-create a dynamic compute offering say d1 3-deploy a vm using d1 4-stop and start vm Actual #cpu , cpuspeed, memory is set to null after stop start Expected - after vm stop-start #cpu , cpuspeed and memory should get updated according to CO -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Updated] (CLOUDSTACK-5515) #cpu ,cpuspeed and ram is set to NULL in usage db(vm_instance table) after vm stop and start
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] prashant kumar mishra updated CLOUDSTACK-5515: -- Attachment: Logs_Db.rar > #cpu ,cpuspeed and ram is set to NULL in usage db(vm_instance table) after vm > stop and start > > > Key: CLOUDSTACK-5515 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5515 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Usage >Affects Versions: 4.3.0 >Reporter: prashant kumar mishra >Priority: Critical > Fix For: 4.3.0 > > Attachments: Logs_Db.rar > > > Steps to reproduce > - > 1-prapare a CS setup + install usage server > 2-create a dynamic compute offering say d1 > 3-deploy a vm using d1 > 4-stop and start vm > Actual > > #cpu , cpuspeed, memory is set to null after stop start > Expected > - > after vm stop-start #cpu , cpuspeed and memory should get updated according > to CO -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Commented] (CLOUDSTACK-4598) [Performance Testing] High delays during deployVM - both network delay and deployment planner delay
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4598?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13849018#comment-13849018 ] Murali Reddy commented on CLOUDSTACK-4598: -- Is this a regression in performance compared to 4.1? > [Performance Testing] High delays during deployVM - both network delay and > deployment planner delay > --- > > Key: CLOUDSTACK-4598 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4598 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.2.0 > Environment: Simulator environment with large scale set up >Reporter: Sowmya Krishnan >Assignee: Murali Reddy >Priority: Critical > Fix For: 4.3.0 > > Attachments: deployVMjob_999.log.gz > > > This is mostly similar to CLOUDSTACK-3441 and CLOUDSTACK-4179. Both these > issues were fixed and verified in comparatively smaller environment with 4K > and 8K hosts and 12K VMs > Now trying in much larger infrastructure with 20k hosts, 20K clusters and 2K > Pods. This is also a special case where we are trying to deploy one VM in > each host. > I am seeing delay both while acquiring network lock and during deployment > planning. > (There was also an ERROR observed in the log during deployment) > Log snippet: > 2013-09-02 22:40:52,335 DEBUG [cloud.deploy.FirstFitPlanner] > (Job-Executor-336:job-999 = [ f437e46a-dfa4-4cea-a518-7da2f5360a89 ]) Listing > clusters in order of aggregate capacity, that have (atleast one host with) > enough CPU and RAM capacity under this Zone: 1 > 2013-09-02 22:40:57,544 DEBUG [cloud.deploy.FirstFitPlanner] > (Job-Executor-336:job-999 = [ f437e46a-dfa4-4cea-a518-7da2f5360a89 ]) > Removing from the clusterId list these clusters from avoid set: [] > .. > .. > 2013-09-02 22:41:05,637 DEBUG [cloud.network.NetworkManagerImpl] > (Job-Executor-336:job-999 = [ f437e46a-dfa4-4cea-a518-7da2f5360a89 ]) > Changing active number > of nics for network id=204 on 1 > 2013-09-02 22:41:05,690 DEBUG [cloud.network.NetworkManagerImpl] > (Job-Executor-336:job-999 = [ f437e46a-dfa4-4cea-a518-7da2f5360a89 ]) Asking > VirtualRouter to prepare for > Nic[2246-1407-0d530dd3-3f25-4fde-b1fb-9ff9188f89e6-172.4.211.191] > 2013-09-02 22:51:04,680 ERROR [cloud.vm.VirtualMachineManagerImpl] > (Job-Executor-336:job-999 = [ f437e46a-dfa4-4cea-a518-7da2f5360a89 ]) Failed > to start instance VM[User|414aa09b-a38c-4b30-bf9c-f1d9fe51134f] > 2013-09-02 22:51:04,702 DEBUG [cloud.vm.VirtualMachineManagerImpl] > (Job-Executor-336:job-999 = [ f437e46a-dfa4-4cea-a518-7da2f5360a89 ]) > Cleaning up resources for the vm > VM[User|414aa09b-a38c-4b30-bf9c-f1d9fe51134f] in Starting state > .. > .. > 2013-09-02 22:51:17,018 DEBUG [cloud.network.NetworkManagerImpl] > (Job-Executor-336:job-999 = [ f437e46a-dfa4-4cea-a518-7da2f5360a89 ]) > Changing active number of nics for network id=204 on 1 > 2013-09-02 22:51:17,074 DEBUG [cloud.network.NetworkManagerImpl] > (Job-Executor-336:job-999 = [ f437e46a-dfa4-4cea-a518-7da2f5360a89 ]) Asking > VirtualRouter to prepare for > Nic[2246-1407-159bacce-8663-477e-ab37-2d1081c0630b-172.4.211.191] > 2013-09-02 22:57:56,139 DEBUG > [network.router.VirtualNetworkApplianceManagerImpl] (Job-Executor-336:job-999 > = [ f437e46a-dfa4-4cea-a518-7da2f5360a89 ]) Lock is acquired for network id > 204 as a part of router startup in > Dest[Zone(Id)-Pod(Id)-Cluster(Id)-Host(Id)-Storage(Volume(Id|Type-->Pool(Id))] > : > Dest[Zone(1)-Pod(975)-Cluster(9749)-Host(9750)-Storage(Volume(1407|ROOT-->Pool(9749))] > 2013-09-02 22:57:56,144 DEBUG > [network.router.VirtualNetworkApplianceManagerImpl] (Job-Executor-336:job-999 > = [ f437e46a-dfa4-4cea-a518-7da2f5360a89 ]) Lock is released for network id > 204 as a part of router startup in > Dest[Zone(Id)-Pod(Id)-Cluster(Id)-Host(Id)-Storage(Volume(Id|Type-->Pool(Id))] > : > Dest[Zone(1)-Pod(975)-Cluster(9749)-Host(9750)-Storage(Volume(1407|ROOT-->Pool(9749))] > .. > .. -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Reopened] (CLOUDSTACK-5276) ListView for selecting VM under LB,portforwarding and static nat configuration pages is not valid.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] manasaveloori reopened CLOUDSTACK-5276: --- Able to reproduce the issue on Lb and port forwarding configuration pages. For PF:List view is not valid. For LB Valid .But there will be 2 options to select the VMs(Listview and normal check boxes which may confuse the user) It is resolved only under static nat page. > ListView for selecting VM under LB,portforwarding and static nat > configuration pages is not valid. > > > Key: CLOUDSTACK-5276 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5276 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.3.0 >Reporter: manasaveloori >Assignee: Jessica Wang >Priority: Critical > Fix For: 4.3.0 > > Attachments: listview.jpg > > > While configuring the portforwarding,LB and static NAT,we need to select the > VMs. > As per the new UI we are getting two options to select the VMS(listview on > left side and individual select option on right side). > While selecting the VMs using the listview widget, the rules are not getting > applied in VR but just seen in UI.The correct functionality is with right > hand side select buttons. I think the listview is not valid under these > configuration pages. -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Closed] (CLOUDSTACK-5273) Applying static Nat by selecting the VM using List view under static Nat configuration page is making CS inaccessible.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] manasaveloori closed CLOUDSTACK-5273. - working fine. > Applying static Nat by selecting the VM using List view under static Nat > configuration page is making CS inaccessible. > -- > > Key: CLOUDSTACK-5273 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5273 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.3.0 >Reporter: manasaveloori >Assignee: Brian Federle >Priority: Critical > Fix For: 4.3.0 > > > Steps: > 1.Have CS with any HV. > 2.Deploy a View VM. > 3.Go to the network and acquire an IP. > 4.Configure static nat->while selecting the VM we are having 2 options > ,one is list view[checkbox] and another is radio button. > 5.Select the VM using list view[checkbox] on left side and click apply > Observation: > Static nat rule will not get applied but the CS gets hanged and the > following is the error shown in fire bug. > 200 OK 1.39s jquery.js (line 7829) > TypeError: args.context.instances[0] is undefined > virtualmachineid: args.context.instances[0].id -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Commented] (CLOUDSTACK-5276) ListView for selecting VM under LB,portforwarding and static nat configuration pages is not valid.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13849038#comment-13849038 ] manasaveloori commented on CLOUDSTACK-5276: --- Under LB configuration..Applying LB on multiple VMs using List view is failing.The same is successful when selecting multiple VMs using individual check boxes. > ListView for selecting VM under LB,portforwarding and static nat > configuration pages is not valid. > > > Key: CLOUDSTACK-5276 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5276 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.3.0 >Reporter: manasaveloori >Assignee: Jessica Wang >Priority: Critical > Fix For: 4.3.0 > > Attachments: listview.jpg > > > While configuring the portforwarding,LB and static NAT,we need to select the > VMs. > As per the new UI we are getting two options to select the VMS(listview on > left side and individual select option on right side). > While selecting the VMs using the listview widget, the rules are not getting > applied in VR but just seen in UI.The correct functionality is with right > hand side select buttons. I think the listview is not valid under these > configuration pages. -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Closed] (CLOUDSTACK-5322) CreateNetwork command doesnt fails on non upgraded vpc router
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] manasaveloori closed CLOUDSTACK-5322. - Closing the issue based on Kishan's comments. > CreateNetwork command doesnt fails on non upgraded vpc router > -- > > Key: CLOUDSTACK-5322 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5322 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Upgrade, Virtual Router >Affects Versions: 4.3.0 >Reporter: shweta agarwal >Assignee: Kishan Kavala >Priority: Critical > Fix For: 4.3.0 > > > Repro steps: > On 3.0.7 setup create a vpc network and some vms in that network > Upgrade to 4.3 > while router is still in old version template create a new tire in VPC network > bug: > New Tier is created without any failure > Expected result: > We should not let new tire creation till router of the VPC network is upgraded > this in turn is creating further problems > 1. able to create a new VM withing this new tier even though router is not > upgraded > 2. able to create a new PF rule /LB rule within this new tier without failure > so to block all these issue we should block creation of new tier itself > inside a VPC network if its router is not upgraded. > API call > http://10.147.40.27:8080/client/api?command=createNetwork&response=json&sessionkey=RFrlpoXdvIxKUO5UzITn%2BF6IuYk%3D&zoneId=71c3d210-e0f7-4ea0-80b3-1a3769cdaeb2&vpcid=19dae370-c4db-469d-9328-4966a90f2c09&domainid=1&account=admin&networkOfferingId=700de393-1d94-4f74-94b6-42e1191781f5&name=data-8&displayText=data-8&gateway=10.0.1.1&netmask=255.255.255.0&_=1385966007752 -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Commented] (CLOUDSTACK-5495) [Automation] Unable to stop VM
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13849072#comment-13849072
]
Bharat Kumar commented on CLOUDSTACK-5495:
--
Hi,
I was not able to reproduce this in 4.3 when we set the execute in sequence to
true for stopvm command.
i am seeing this error on xenserver when the vm stop fails.
VM.clean_shutdown locking failed: caught transient failure
OTHER_OPERATION_IN_PROGRESS: [ VM.clean_shutdown;
OpaqueRef:3f36c0e8-d0c5-29ba-c6b1-9a586d8b8205 ]
Server_helpers.exec exception_handler: Got exception VM_BAD_POWER_STATE: [
OpaqueRef:3f36c0e8-d0c5-29ba-c6b1-9a586d8b8205; running; halted ]
Attaching the xensource.log
> [Automation] Unable to stop VM
> --
>
> Key: CLOUDSTACK-5495
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5495
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server
>Affects Versions: 4.3.0
> Environment: XenServer 6.2
> advanced zone
>Reporter: Srikanteswararao Talluri
>Assignee: Bharat Kumar
>Priority: Blocker
> Fix For: 4.3.0
>
> Attachments: newrunmgmt.log.zip
>
>
> Unable to Stop VM - error is hit multiple times during automation run
> Here is the stack trace:
> ===END=== 10.147.38.149 -- GET
> signature=ObNDNvmDCDDBoa%2FJ%2BFOtWBiGH%2BA%3D&apiKey=-neX9tpPuZ8bg04MAmolZWYSQkgjXMRmPNxou5hJcwAUk9Ti3nQj2ii_W4WylGRUwOjo1PW233odZZUX0-1dbg&command=queryAsyncJobResult&response=json&jobid=144b5660-716f-449c-9b52-f18ba738ad28
> 2013-12-14 00:52:18,153 WARN [c.c.h.x.r.CitrixResourceBase]
> (DirectAgent-375:ctx-3500a12b) VM destroy failed in Stop i-271-491-QA Command
> due to null
> You gave an invalid object reference. The object may have recently been
> deleted. The class parameter gives the type of reference given, and the
> handle parameter echoes the bad value given.
> at com.xensource.xenapi.Types.checkResponse(Types.java:209)
> at com.xensource.xenapi.Connection.dispatch(Connection.java:368)
> at
> com.cloud.hypervisor.xen.resource.XenServerConnectionPool$XenServerConnection.dispatch(XenServerConnectionPool.java:909)
> at com.xensource.xenapi.VM.getPowerState(VM.java:746)
> at
> com.cloud.hypervisor.xen.resource.CitrixResourceBase.execute(CitrixResourceBase.java:4168)
> at
> com.cloud.hypervisor.xen.resource.CitrixResourceBase.executeRequest(CitrixResourceBase.java:492)
> at
> com.cloud.hypervisor.xen.resource.XenServer56Resource.executeRequest(XenServer56Resource.java:59)
> at
> com.cloud.hypervisor.xen.resource.XenServer610Resource.executeRequest(XenServer610Resource.java:106)
> at
> com.cloud.agent.manager.DirectAgentAttache$Task.runInContext(DirectAgentAttache.java:216)
> 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
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:165)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:679)
> 2013-12-14 00:52:18,161 DEBUG [c.c.h.x.r.CitrixResourceBase]
> (DirectAgent-375:ctx-3500a12b) 10. The VM i-271-491-QA is in Running state
> 2013-12-14 00:52:18,161 DEBUG [c.c.a.m.DirectAgentAttache]
> (DirectAgent-375:ctx-3500a12b) Seq 1-494866421: Response Received:
> 2013-12-14 00:52:18,161 DEBUG [c.c.a.t.Request]
> (DirectAgent-375:ctx-3500a12b) Seq 1-494866421: Processing: { Ans: , MgmtId:
> 6631563722783, via: 1, Ver: v1, Flags: 10,
> [{"com.cloud.agent.api.StopAnswer":{"platform":"viridian:true;acpi:1;apic:true;pae:true;nx:true","result":false,"details":"Stop
> VM failed","wait":0}}] }
>
[jira] [Updated] (CLOUDSTACK-5495) [Automation] Unable to stop VM
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5495?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bharat Kumar updated CLOUDSTACK-5495:
-
Attachment: xensource-unabel-to-stop-vm.log
> [Automation] Unable to stop VM
> --
>
> Key: CLOUDSTACK-5495
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5495
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server
>Affects Versions: 4.3.0
> Environment: XenServer 6.2
> advanced zone
>Reporter: Srikanteswararao Talluri
>Assignee: Bharat Kumar
>Priority: Blocker
> Fix For: 4.3.0
>
> Attachments: newrunmgmt.log.zip, xensource-unabel-to-stop-vm.log
>
>
> Unable to Stop VM - error is hit multiple times during automation run
> Here is the stack trace:
> ===END=== 10.147.38.149 -- GET
> signature=ObNDNvmDCDDBoa%2FJ%2BFOtWBiGH%2BA%3D&apiKey=-neX9tpPuZ8bg04MAmolZWYSQkgjXMRmPNxou5hJcwAUk9Ti3nQj2ii_W4WylGRUwOjo1PW233odZZUX0-1dbg&command=queryAsyncJobResult&response=json&jobid=144b5660-716f-449c-9b52-f18ba738ad28
> 2013-12-14 00:52:18,153 WARN [c.c.h.x.r.CitrixResourceBase]
> (DirectAgent-375:ctx-3500a12b) VM destroy failed in Stop i-271-491-QA Command
> due to null
> You gave an invalid object reference. The object may have recently been
> deleted. The class parameter gives the type of reference given, and the
> handle parameter echoes the bad value given.
> at com.xensource.xenapi.Types.checkResponse(Types.java:209)
> at com.xensource.xenapi.Connection.dispatch(Connection.java:368)
> at
> com.cloud.hypervisor.xen.resource.XenServerConnectionPool$XenServerConnection.dispatch(XenServerConnectionPool.java:909)
> at com.xensource.xenapi.VM.getPowerState(VM.java:746)
> at
> com.cloud.hypervisor.xen.resource.CitrixResourceBase.execute(CitrixResourceBase.java:4168)
> at
> com.cloud.hypervisor.xen.resource.CitrixResourceBase.executeRequest(CitrixResourceBase.java:492)
> at
> com.cloud.hypervisor.xen.resource.XenServer56Resource.executeRequest(XenServer56Resource.java:59)
> at
> com.cloud.hypervisor.xen.resource.XenServer610Resource.executeRequest(XenServer610Resource.java:106)
> at
> com.cloud.agent.manager.DirectAgentAttache$Task.runInContext(DirectAgentAttache.java:216)
> 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
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:165)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:679)
> 2013-12-14 00:52:18,161 DEBUG [c.c.h.x.r.CitrixResourceBase]
> (DirectAgent-375:ctx-3500a12b) 10. The VM i-271-491-QA is in Running state
> 2013-12-14 00:52:18,161 DEBUG [c.c.a.m.DirectAgentAttache]
> (DirectAgent-375:ctx-3500a12b) Seq 1-494866421: Response Received:
> 2013-12-14 00:52:18,161 DEBUG [c.c.a.t.Request]
> (DirectAgent-375:ctx-3500a12b) Seq 1-494866421: Processing: { Ans: , MgmtId:
> 6631563722783, via: 1, Ver: v1, Flags: 10,
> [{"com.cloud.agent.api.StopAnswer":{"platform":"viridian:true;acpi:1;apic:true;pae:true;nx:true","result":false,"details":"Stop
> VM failed","wait":0}}] }
> 2013-12-14 00:52:18,161 DEBUG [c.c.a.t.Request] (Job-Executor-71:ctx-aedce201
> ctx-ee5f8ea3) Seq 1-494866421: Received: { Ans: , MgmtId: 6631563722783,
> via: 1, Ver: v1, Flags: 10, { StopAnswer } }
> 2013-12-14 00:52:18,173 WARN [c.c.v.VirtualMachineManagerImpl]
> (Job-Executor-71:ctx-aedce201 ctx-ee5f8ea3) Unable to stop vm
> VM[User|QA-b6e685bf-4ba1-4572-8728-3bfd0106f6d7]
> 2013-12-14 00:52:18,187 DEBUG [c.c.v.d.VMInstanceDaoImpl]
> (Job-Executor-71:ctx-aedce201 ctx-
[jira] [Commented] (CLOUDSTACK-5493) Group by cluster options in router page shows count for only running routers
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5493?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13849074#comment-13849074
]
manasaveloori commented on CLOUDSTACK-5493:
---
applies to group by account as well.
> Group by cluster options in router page shows count for only running routers
>
>
> Key: CLOUDSTACK-5493
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5493
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: UI
>Affects Versions: 4.3.0
>Reporter: shweta agarwal
> Fix For: 4.3.0
>
>
> Group by cluster options in router pages shows count for only running routers
> while pod , zone considers both running and stopped routers
> API :
> http://10.147.40.27:8080/client/api?command=listRouters&response=json&sessionkey=lDWk06sWJovcFLDuw3MHaS00N4Q%3D&clusterid=3e27c364-4f21-4eda-9ef8-ac7af9b123c0&listAll=true&page=1&pagesize=20&_=1386935231874
> Response :
> Notice response shows only 4 routers though in my setup I have 10 routers : 4
> running, 5 stopped , 1 project related and only one cluster
> { "listroutersresponse" : { "count":4 ,"router" : [
> {"id":"3d05883f-3089-449a-84a2-bb7d758f1e82","zoneid":"60e7f3ce-cb9c-45e1-8c8b-9d93d2adf060","zonename":"xen","dns1":"10.140.50.6","gateway":"10.147.51.1","name":"r-19-VM","podid":"a5d5234e-86d6-41f8-ac8c-5bdf24288231","hostid":"90ac48de-eb48-4283-b2f9-1a6581a92fb6","hostname":"Rack1Pod1Host24","linklocalip":"169.254.1.123","linklocalmacaddress":"0e:00:a9:fe:01:7b","linklocalnetmask":"255.255.0.0","linklocalnetworkid":"d73e3fa7-c561-4e04-be13-d242832a9f3f","publicip":"10.147.51.21","publicmacaddress":"06:bd:38:00:00:20","publicnetmask":"255.255.255.0","publicnetworkid":"b5b1260c-30a0-4a6e-9780-ca4ae4809373","templateid":"ce21f5d6-630f-11e3-9a2f-97407caff5c2","created":"2013-12-12T17:56:08+0530","state":"Running","account":"admin","domainid":"94814869-1330-42b9-8e74-77a407a3cd7e","domain":"child1","serviceofferingid":"72743e39-323d-4aba-9076-6c43b72252c1","serviceofferingname":"System
> Offering For Software
> Router","isredundantrouter":false,"redundantstate":"UNKNOWN","version":"3.0","vpcid":"07fcf168-3086-40c0-bd9b-eddb70396aaa","role":"VIRTUAL_ROUTER","nic":[{"id":"87f6bfb3-f993-4cc6-8332-4b25efd298a3","networkid":"d73e3fa7-c561-4e04-be13-d242832a9f3f","netmask":"255.255.0.0","gateway":"169.254.0.1","ipaddress":"169.254.1.123","traffictype":"Control","isdefault":false,"macaddress":"0e:00:a9:fe:01:7b"},{"id":"8066d1e0-ee16-4ade-898e-3a232efb8345","networkid":"b5b1260c-30a0-4a6e-9780-ca4ae4809373","netmask":"255.255.255.0","gateway":"10.147.51.1","ipaddress":"10.147.51.21","isolationuri":"vlan://51","broadcasturi":"vlan://51","traffictype":"Public","isdefault":true,"macaddress":"06:bd:38:00:00:20"}],"requiresupgrade":true},
>
> {"id":"e934a9a2-c205-47fb-9844-98c95fdcd9a4","zoneid":"60e7f3ce-cb9c-45e1-8c8b-9d93d2adf060","zonename":"xen","dns1":"10.140.50.6","gateway":"10.147.51.1","name":"r-8-VM","podid":"a5d5234e-86d6-41f8-ac8c-5bdf24288231","hostid":"90ac48de-eb48-4283-b2f9-1a6581a92fb6","hostname":"Rack1Pod1Host24","linklocalip":"169.254.3.171","linklocalmacaddress":"0e:00:a9:fe:03:ab","linklocalnetmask":"255.255.0.0","linklocalnetworkid":"d73e3fa7-c561-4e04-be13-d242832a9f3f","publicip":"10.147.51.14","publicmacaddress":"06:f3:fe:00:00:19","publicnetmask":"255.255.255.0","publicnetworkid":"b5b1260c-30a0-4a6e-9780-ca4ae4809373","templateid":"ce21f5d6-630f-11e3-9a2f-97407caff5c2","created":"2013-12-12T17:49:40+0530","state":"Running","account":"shweta","domainid":"226fe5b1-c1be-45bf-a3d4-5bb6ca08ee87","domain":"child","serviceofferingid":"72743e39-323d-4aba-9076-6c43b72252c1","serviceofferingname":"System
> Offering For Software
> Router","isredundantrouter":false,"redundantstate":"UNKNOWN","version":"3.0","vpcid":"6e00939b-2db8-4227-904f-07dc954ae353","role":"VIRTUAL_ROUTER","nic":[{"id":"e0e4fa7d-2bd6-4d56-967d-9f021bffb34a","networkid":"d73e3fa7-c561-4e04-be13-d242832a9f3f","netmask":"255.255.0.0","gateway":"169.254.0.1","ipaddress":"169.254.3.171","traffictype":"Control","isdefault":false,"macaddress":"0e:00:a9:fe:03:ab"},{"id":"5c2f5398-b3a6-403b-82c9-cf4a00461a0d","networkid":"b5b1260c-30a0-4a6e-9780-ca4ae4809373","netmask":"255.255.255.0","gateway":"10.147.51.1","ipaddress":"10.147.51.14","isolationuri":"vlan://51","broadcasturi":"vlan://51","traffictype":"Public","isdefault":true,"macaddress":"06:f3:fe:00:00:19"}],"requiresupgrade":true},
>
> {"id":"27e5c26c-5101-4b13-b8c0-666e7f0adf72","zoneid":"60e7f3ce-cb9c-45e1-8c8b-9d93d2adf060","zonename":"xen","dns1":"10.140.50.6","gateway":"10.147.51.1","name":"r-16-VM","podid":"a5d5234e-86d6-41f8-ac8c-5bdf24288231","hostid":"90ac48de-eb48-4283-b
[jira] [Commented] (CLOUDSTACK-5515) #cpu ,cpuspeed and ram is set to NULL in usage db(vm_instance table) after vm stop and start
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5515?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13849080#comment-13849080 ] prashant kumar mishra commented on CLOUDSTACK-5515: --- seeing same problem when i do change CO > #cpu ,cpuspeed and ram is set to NULL in usage db(vm_instance table) after vm > stop and start > > > Key: CLOUDSTACK-5515 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5515 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Usage >Affects Versions: 4.3.0 >Reporter: prashant kumar mishra >Priority: Critical > Fix For: 4.3.0 > > Attachments: Logs_Db.rar > > > Steps to reproduce > - > 1-prapare a CS setup + install usage server > 2-create a dynamic compute offering say d1 > 3-deploy a vm using d1 > 4-stop and start vm > Actual > > #cpu , cpuspeed, memory is set to null after stop start > Expected > - > after vm stop-start #cpu , cpuspeed and memory should get updated according > to CO -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Comment Edited] (CLOUDSTACK-5515) #cpu ,cpuspeed and ram is set to NULL in usage db(vm_instance table) after vm stop and start
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5515?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13849080#comment-13849080 ] prashant kumar mishra edited comment on CLOUDSTACK-5515 at 12/16/13 11:52 AM: -- facing same problem when i do change CO was (Author: prashantkm): seeing same problem when i do change CO > #cpu ,cpuspeed and ram is set to NULL in usage db(vm_instance table) after vm > stop and start > > > Key: CLOUDSTACK-5515 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5515 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Usage >Affects Versions: 4.3.0 >Reporter: prashant kumar mishra >Priority: Critical > Fix For: 4.3.0 > > Attachments: Logs_Db.rar > > > Steps to reproduce > - > 1-prapare a CS setup + install usage server > 2-create a dynamic compute offering say d1 > 3-deploy a vm using d1 > 4-stop and start vm > Actual > > #cpu , cpuspeed, memory is set to null after stop start > Expected > - > after vm stop-start #cpu , cpuspeed and memory should get updated according > to CO -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Updated] (CLOUDSTACK-5423) [Automation] : deployAndRun and TestCaseExecuteEngine needs modification
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Srikanteswararao Talluri updated CLOUDSTACK-5423: - Issue Type: Test (was: Bug) > [Automation] : deployAndRun and TestCaseExecuteEngine needs modification > > > Key: CLOUDSTACK-5423 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5423 > Project: CloudStack > Issue Type: Test > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation, marvin >Reporter: Santhosh Kumar Edukulla >Assignee: Santhosh Kumar Edukulla > > 1. As part of recent changes to marvin, mentioned files requires some > changes. > 2. Some cleaning is as well required for these two files. Did clean up. > 3. Did cleanup in deployAndRun and added proper flow for ease of > understanding. > 4. Removed unwanted logging and used MarvinInit for initialization of Marvin. > 5. Removed few unwanted loops and redundant code. > 6. Renamed TestCaseExecuteEngine.py -> tcExecuteEngine.py inline with other > naming convention for modules in Marvin > 7. Added few codes and doc strings. -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Commented] (CLOUDSTACK-5145) ListNetworkACL API should list ACLs owned by the user only
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13849112#comment-13849112 ] ASF subversion and git services commented on CLOUDSTACK-5145: - Commit e2805b802cb7eb82bf885199e0bd289bcb599167 in branch refs/heads/4.3 from [~kishan] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=e2805b8 ] CLOUDSTACK-5145 : Added permission checks while deleting network ACLs > ListNetworkACL API should list ACLs owned by the user only > -- > > Key: CLOUDSTACK-5145 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5145 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Kishan Kavala >Assignee: Kishan Kavala >Priority: Blocker > Fix For: 4.2.1, 4.3.0 > > > ListNetworkACL API should filter ACLs by caller and list ACLs which can be > accessed by the user only. > If API call is not called with a networkid or other filter, every ACL in the > system is dumped, which is both a performance issue and a security issue. If > a networkid is provided, but the network doesn't have an ACL list or any ACL > items attached, the same issue occurs. > Likewise, listNetworkACLLists gives access to see non-owned lists, which in > turn gives vpc ids for non-owned resources. > Example: > 1. Set up a zone > 2. Create a VPC or network as admin > 3. Create an ACL list for the network > 4. Create a new domain and unprivileged user > 5. Generate API keys for user > 6. Issue a 'listNetworkACLs' API call. You should see the ACL list items from > the admin-owned list > 7. Issue a 'listNetworkACLLists' API call referencing aclid from non-owned > acl item. You should see the acl list info and which vpc it belongs to. > 8. Listing the vpc attached to the acl list properly stops with an > 'unauthorized' response as step 7 above should. -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Commented] (CLOUDSTACK-5145) ListNetworkACL API should list ACLs owned by the user only
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13849113#comment-13849113 ] ASF subversion and git services commented on CLOUDSTACK-5145: - Commit 3a3fec3cb6bb4f9a008370ea02279d286654b01a in branch refs/heads/master from [~kishan] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=3a3fec3 ] CLOUDSTACK-5145 : Added permission checks while deleting network ACLs Conflicts: server/src/com/cloud/network/vpc/NetworkACLServiceImpl.java > ListNetworkACL API should list ACLs owned by the user only > -- > > Key: CLOUDSTACK-5145 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5145 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Kishan Kavala >Assignee: Kishan Kavala >Priority: Blocker > Fix For: 4.2.1, 4.3.0 > > > ListNetworkACL API should filter ACLs by caller and list ACLs which can be > accessed by the user only. > If API call is not called with a networkid or other filter, every ACL in the > system is dumped, which is both a performance issue and a security issue. If > a networkid is provided, but the network doesn't have an ACL list or any ACL > items attached, the same issue occurs. > Likewise, listNetworkACLLists gives access to see non-owned lists, which in > turn gives vpc ids for non-owned resources. > Example: > 1. Set up a zone > 2. Create a VPC or network as admin > 3. Create an ACL list for the network > 4. Create a new domain and unprivileged user > 5. Generate API keys for user > 6. Issue a 'listNetworkACLs' API call. You should see the ACL list items from > the admin-owned list > 7. Issue a 'listNetworkACLLists' API call referencing aclid from non-owned > acl item. You should see the acl list info and which vpc it belongs to. > 8. Listing the vpc attached to the acl list properly stops with an > 'unauthorized' response as step 7 above should. -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Commented] (CLOUDSTACK-5145) ListNetworkACL API should list ACLs owned by the user only
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13849115#comment-13849115 ] ASF subversion and git services commented on CLOUDSTACK-5145: - Commit e2915c6ce57cf8a429a2c8a9b1980faf1c4f8574 in branch refs/heads/master from [~kishan] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=e2915c6 ] CLOUDSTACK-5145 : Added permission checks while deleting network ACLs > ListNetworkACL API should list ACLs owned by the user only > -- > > Key: CLOUDSTACK-5145 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5145 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Kishan Kavala >Assignee: Kishan Kavala >Priority: Blocker > Fix For: 4.2.1, 4.3.0 > > > ListNetworkACL API should filter ACLs by caller and list ACLs which can be > accessed by the user only. > If API call is not called with a networkid or other filter, every ACL in the > system is dumped, which is both a performance issue and a security issue. If > a networkid is provided, but the network doesn't have an ACL list or any ACL > items attached, the same issue occurs. > Likewise, listNetworkACLLists gives access to see non-owned lists, which in > turn gives vpc ids for non-owned resources. > Example: > 1. Set up a zone > 2. Create a VPC or network as admin > 3. Create an ACL list for the network > 4. Create a new domain and unprivileged user > 5. Generate API keys for user > 6. Issue a 'listNetworkACLs' API call. You should see the ACL list items from > the admin-owned list > 7. Issue a 'listNetworkACLLists' API call referencing aclid from non-owned > acl item. You should see the acl list info and which vpc it belongs to. > 8. Listing the vpc attached to the acl list properly stops with an > 'unauthorized' response as step 7 above should. -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Closed] (CLOUDSTACK-5443) [Automation] Test cases failing with error "'cloudConnection' object has no attribute 'logging'"
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5443?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Santhosh Kumar Edukulla closed CLOUDSTACK-5443.
---
> [Automation] Test cases failing with error "'cloudConnection' object has no
> attribute 'logging'"
>
>
> Key: CLOUDSTACK-5443
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5443
> Project: CloudStack
> Issue Type: Test
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Automation, marvin
>Affects Versions: 4.3.0
> Environment: vmware
>Reporter: Rayees Namathponnan
>Assignee: Santhosh Kumar Edukulla
>Priority: Blocker
> Fix For: 4.3.0
>
> Attachments: logs.rar
>
>
> job:37 Regression_VMWARE_50_Multi_2
> Automation test cases failing with cloudstack connection error
> "'cloudConnection' object has no attribute 'logging'", this issue observed
> with latest Marvin
> Test cases failing
> integration.component.test_assign_vm.TestVMOwnership.test_09_move_across_subdomain
>
> integration.component.test_cpu_limits.TestDomainCPULimitsConfiguration.test_01_stop_start_instance
> integration.component.test_cpu_project_limits.TestProjectsCPULimits.test_01_project_counts_start_stop_instance
>
> integration.component.test_mm_project_limits.TestProjectsMemoryLimits.test_01_project_vmlifecycle_start_stop_instance
>
> Observed below error
> Stacktrace
> File "/usr/local/lib/python2.7/unittest/case.py", line 318, in run
> testMethod()
> File
> "/data/Repo2/qa/cloudstack/test/integration/component/test_assign_vm.py",
> line 48, in test_wrap_exception_log
> raise e
> 'cloudConnection' object has no attribute 'logging'
> Error Message
> 'cloudConnection' object has no attribute 'logging'
> >> begin captured logging <<
> test_09_move_across_subdomain
> (integration.component.test_assign_vm.TestVMOwnership): DEBUG:
> STARTED : TC: test_09_move_across_subdomain :::
> test_09_move_across_subdomain
> (integration.component.test_assign_vm.TestVMOwnership): DEBUG: sending GET
> request: listDomains {'name': 'ROOT'}
> test_09_move_across_subdomain
> (integration.component.test_assign_vm.TestVMOwnership): DEBUG: Computed
> Signature by Marvin: pvEAZcMfP6d6DvVUwquxrLc4Yfc=
> requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection
> (1): 10.223.49.197
> requests.packages.urllib3.connectionpool: DEBUG: "GET
> /client/api?apiKey=Q438pTijzg8GTLcjOLCqAKRS1bot1P5ZV6jquQNyUBUpZeBrIWOg3X50pVi6J6MadD7B9cWREBJPPR2BrCGviQ&name=ROOT&command=listDomains&signature=pvEAZcMfP6d6DvVUwquxrLc4Yfc%3D&response=json
> HTTP/1.1" 200 158
> test_09_move_across_subdomain
> (integration.component.test_assign_vm.TestVMOwnership): DEBUG: Request:
> http://10.223.49.197:8080/client/api?apiKey=Q438pTijzg8GTLcjOLCqAKRS1bot1P5ZV6jquQNyUBUpZeBrIWOg3X50pVi6J6MadD7B9cWREBJPPR2BrCGviQ&name=ROOT&command=listDomains&signature=pvEAZcMfP6d6DvVUwquxrLc4Yfc%3D&response=json
> Response: { "listdomainsresponse" : { "count":1 ,"domain" : [
> {"id":"e122f80a-6135-11e3-9c62-52b2d980df8a","name":"ROOT","level":0,"haschild":true,"path":"ROOT"}
> ] } }
> test_09_move_across_subdomain
> (integration.component.test_assign_vm.TestVMOwnership): DEBUG: sending GET
> request: listDomains {'name': u'Domain-Z1P4GU', 'listall': True}
> test_09_move_across_subdomain
> (integration.component.test_assign_vm.TestVMOwnership): DEBUG: Computed
> Signature by Marvin: aHNonLmePpsQ+D70YMGp5EsVTz8=
> requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection
> (1): 10.223.49.197
> requests.packages.urllib3.connectionpool: DEBUG: "GET
> /client/api?apiKey=Q438pTijzg8GTLcjOLCqAKRS1bot1P5ZV6jquQNyUBUpZeBrIWOg3X50pVi6J6MadD7B9cWREBJPPR2BrCGviQ&name=Domain-Z1P4GU&command=listDomains&signature=aHNonLmePpsQ%2BD70YMGp5EsVTz8%3D&response=json&listall=True
> HTTP/1.1" 200 287
> test_09_move_across_subdomain
> (integration.component.test_assign_vm.TestVMOwnership): DEBUG: Request:
> http://10.223.49.197:8080/client/api?apiKey=Q438pTijzg8GTLcjOLCqAKRS1bot1P5ZV6jquQNyUBUpZeBrIWOg3X50pVi6J6MadD7B9cWREBJPPR2BrCGviQ&name=Domain-Z1P4GU&command=listDomains&signature=aHNonLmePpsQ%2BD70YMGp5EsVTz8%3D&response=json&listall=True
> Response: { "listdomainsresponse" : { "count":1 ,"domain" : [
> {"id":"1c49167e-a6c4-4cbd-9afa-7dd0b28f9fa8","name":"Domain-Z1P4GU","level":2,"parentdomainid":"b6722bca-3cdb-44fc-9c40-79c06f6c95ef","parentdomainname":"Domain-BC9BFM","haschild":false,"path":"ROOT/Domain-BC9BFM/Domain-Z1P4GU"}
> ] } }
> test_09_move_across_subdomain
> (integration.component.test_assign_vm.TestVMOwnership): DEBUG: sending GET
> request: listAccounts {'domainid'
[jira] [Resolved] (CLOUDSTACK-5443) [Automation] Test cases failing with error "'cloudConnection' object has no attribute 'logging'"
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5443?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Santhosh Kumar Edukulla resolved CLOUDSTACK-5443.
-
Resolution: Fixed
> [Automation] Test cases failing with error "'cloudConnection' object has no
> attribute 'logging'"
>
>
> Key: CLOUDSTACK-5443
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5443
> Project: CloudStack
> Issue Type: Test
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Automation, marvin
>Affects Versions: 4.3.0
> Environment: vmware
>Reporter: Rayees Namathponnan
>Assignee: Santhosh Kumar Edukulla
>Priority: Blocker
> Fix For: 4.3.0
>
> Attachments: logs.rar
>
>
> job:37 Regression_VMWARE_50_Multi_2
> Automation test cases failing with cloudstack connection error
> "'cloudConnection' object has no attribute 'logging'", this issue observed
> with latest Marvin
> Test cases failing
> integration.component.test_assign_vm.TestVMOwnership.test_09_move_across_subdomain
>
> integration.component.test_cpu_limits.TestDomainCPULimitsConfiguration.test_01_stop_start_instance
> integration.component.test_cpu_project_limits.TestProjectsCPULimits.test_01_project_counts_start_stop_instance
>
> integration.component.test_mm_project_limits.TestProjectsMemoryLimits.test_01_project_vmlifecycle_start_stop_instance
>
> Observed below error
> Stacktrace
> File "/usr/local/lib/python2.7/unittest/case.py", line 318, in run
> testMethod()
> File
> "/data/Repo2/qa/cloudstack/test/integration/component/test_assign_vm.py",
> line 48, in test_wrap_exception_log
> raise e
> 'cloudConnection' object has no attribute 'logging'
> Error Message
> 'cloudConnection' object has no attribute 'logging'
> >> begin captured logging <<
> test_09_move_across_subdomain
> (integration.component.test_assign_vm.TestVMOwnership): DEBUG:
> STARTED : TC: test_09_move_across_subdomain :::
> test_09_move_across_subdomain
> (integration.component.test_assign_vm.TestVMOwnership): DEBUG: sending GET
> request: listDomains {'name': 'ROOT'}
> test_09_move_across_subdomain
> (integration.component.test_assign_vm.TestVMOwnership): DEBUG: Computed
> Signature by Marvin: pvEAZcMfP6d6DvVUwquxrLc4Yfc=
> requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection
> (1): 10.223.49.197
> requests.packages.urllib3.connectionpool: DEBUG: "GET
> /client/api?apiKey=Q438pTijzg8GTLcjOLCqAKRS1bot1P5ZV6jquQNyUBUpZeBrIWOg3X50pVi6J6MadD7B9cWREBJPPR2BrCGviQ&name=ROOT&command=listDomains&signature=pvEAZcMfP6d6DvVUwquxrLc4Yfc%3D&response=json
> HTTP/1.1" 200 158
> test_09_move_across_subdomain
> (integration.component.test_assign_vm.TestVMOwnership): DEBUG: Request:
> http://10.223.49.197:8080/client/api?apiKey=Q438pTijzg8GTLcjOLCqAKRS1bot1P5ZV6jquQNyUBUpZeBrIWOg3X50pVi6J6MadD7B9cWREBJPPR2BrCGviQ&name=ROOT&command=listDomains&signature=pvEAZcMfP6d6DvVUwquxrLc4Yfc%3D&response=json
> Response: { "listdomainsresponse" : { "count":1 ,"domain" : [
> {"id":"e122f80a-6135-11e3-9c62-52b2d980df8a","name":"ROOT","level":0,"haschild":true,"path":"ROOT"}
> ] } }
> test_09_move_across_subdomain
> (integration.component.test_assign_vm.TestVMOwnership): DEBUG: sending GET
> request: listDomains {'name': u'Domain-Z1P4GU', 'listall': True}
> test_09_move_across_subdomain
> (integration.component.test_assign_vm.TestVMOwnership): DEBUG: Computed
> Signature by Marvin: aHNonLmePpsQ+D70YMGp5EsVTz8=
> requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection
> (1): 10.223.49.197
> requests.packages.urllib3.connectionpool: DEBUG: "GET
> /client/api?apiKey=Q438pTijzg8GTLcjOLCqAKRS1bot1P5ZV6jquQNyUBUpZeBrIWOg3X50pVi6J6MadD7B9cWREBJPPR2BrCGviQ&name=Domain-Z1P4GU&command=listDomains&signature=aHNonLmePpsQ%2BD70YMGp5EsVTz8%3D&response=json&listall=True
> HTTP/1.1" 200 287
> test_09_move_across_subdomain
> (integration.component.test_assign_vm.TestVMOwnership): DEBUG: Request:
> http://10.223.49.197:8080/client/api?apiKey=Q438pTijzg8GTLcjOLCqAKRS1bot1P5ZV6jquQNyUBUpZeBrIWOg3X50pVi6J6MadD7B9cWREBJPPR2BrCGviQ&name=Domain-Z1P4GU&command=listDomains&signature=aHNonLmePpsQ%2BD70YMGp5EsVTz8%3D&response=json&listall=True
> Response: { "listdomainsresponse" : { "count":1 ,"domain" : [
> {"id":"1c49167e-a6c4-4cbd-9afa-7dd0b28f9fa8","name":"Domain-Z1P4GU","level":2,"parentdomainid":"b6722bca-3cdb-44fc-9c40-79c06f6c95ef","parentdomainname":"Domain-BC9BFM","haschild":false,"path":"ROOT/Domain-BC9BFM/Domain-Z1P4GU"}
> ] } }
> test_09_move_across_subdomain
> (integration.component.test_assign_vm.TestVMOwnership): DEBUG: sending GET
> request
[jira] [Closed] (CLOUDSTACK-5449) [Automation] Marvin tests are failing because it failed to create log directory
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5449?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Srikanteswararao Talluri closed CLOUDSTACK-5449.
> [Automation] Marvin tests are failing because it failed to create log
> directory
> ---
>
> Key: CLOUDSTACK-5449
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5449
> Project: CloudStack
> Issue Type: Test
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Automation, marvin
>Affects Versions: 4.3.0
>Reporter: Srikanteswararao Talluri
>Assignee: Srikanteswararao Talluri
>Priority: Critical
> Fix For: 4.3.0
>
>
> nosetests --with-xunit --xunit-file=test_loadbalance.xml --with-marvin
> --marvin-config=/hudson/scripts/nightly_asf_master.cfg
> /root/cloudstack/test//integration/smoke/test_loadbalance.py --load -a
> tags=advanced
> Exception Occurred Under __initLogging :[Errno 17] File exists:
> '/hudson/workspace/logs13867140921'
> Traceback (most recent call last):
> File "/usr/local/bin/nosetests", line 9, in
> load_entry_point('nose==1.3.0', 'console_scripts', 'nosetests')()
> File "/usr/local/lib/python2.7/site-packages/nose/core.py", line 118, in
> __init__
> **extra_args)
> File "/usr/local/lib/python2.7/unittest/main.py", line 95, in __init__
> self.runTests()
> File "/usr/local/lib/python2.7/site-packages/nose/core.py", line 197, in
> runTests
> result = self.testRunner.run(self.test)
> File "/usr/local/lib/python2.7/site-packages/nose/core.py", line 61, in run
> test(result)
> File "/usr/local/lib/python2.7/site-packages/nose/suite.py", line 176, in
> __call__
> return self.run(*arg, **kw)
> File "/usr/local/lib/python2.7/site-packages/nose/suite.py", line 223, in
> run
> test(orig)
> File "/usr/local/lib/python2.7/site-packages/nose/suite.py", line 176, in
> __call__
> return self.run(*arg, **kw)
> File "/usr/local/lib/python2.7/site-packages/nose/suite.py", line 223, in
> run
> test(orig)
> File "/usr/local/lib/python2.7/site-packages/nose/suite.py", line 176, in
> __call__
> return self.run(*arg, **kw)
> File "/usr/local/lib/python2.7/site-packages/nose/suite.py", line 223, in
> run
> test(orig)
> File "/usr/local/lib/python2.7/site-packages/nose/suite.py", line 176, in
> __call__
> return self.run(*arg, **kw)
> File "/usr/local/lib/python2.7/site-packages/nose/suite.py", line 223, in
> run
> test(orig)
> File "/usr/local/lib/python2.7/site-packages/nose/suite.py", line 176, in
> __call__
> return self.run(*arg, **kw)
> File "/usr/local/lib/python2.7/site-packages/nose/suite.py", line 223, in
> run
> test(orig)
> File "/usr/local/lib/python2.7/site-packages/nose/suite.py", line 176, in
> __call__
> return self.run(*arg, **kw)
> File "/usr/local/lib/python2.7/site-packages/nose/suite.py", line 223, in
> run
> test(orig)
> File "/usr/local/lib/python2.7/site-packages/nose/case.py", line 45, in
> __call__
> return self.run(*arg, **kwarg)
> File "/usr/local/lib/python2.7/site-packages/nose/case.py", line 138, in run
> result.addError(self, err)
> File "/usr/local/lib/python2.7/site-packages/nose/proxy.py", line 124, in
> addError
> plugin_handled = plugins.handleError(self.test, err)
> File "/usr/local/lib/python2.7/site-packages/nose/plugins/manager.py", line
> 99, in __call__
> return self.call(*arg, **kw)
> File "/usr/local/lib/python2.7/site-packages/nose/plugins/manager.py", line
> 167, in simple
> result = meth(*arg, **kw)
> File "/usr/local/lib/python2.7/site-packages/marvin/marvinPlugin.py", line
> 146, in handleError
> self.tcRunLogger.fatal("%s: %s: %s" %
> AttributeError: 'NoneType' object has no attribute 'fatal'
--
This message was sent by Atlassian JIRA
(v6.1.4#6159)
[jira] [Resolved] (CLOUDSTACK-5449) [Automation] Marvin tests are failing because it failed to create log directory
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5449?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Srikanteswararao Talluri resolved CLOUDSTACK-5449.
--
Resolution: Fixed
> [Automation] Marvin tests are failing because it failed to create log
> directory
> ---
>
> Key: CLOUDSTACK-5449
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5449
> Project: CloudStack
> Issue Type: Test
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Automation, marvin
>Affects Versions: 4.3.0
>Reporter: Srikanteswararao Talluri
>Assignee: Srikanteswararao Talluri
>Priority: Critical
> Fix For: 4.3.0
>
>
> nosetests --with-xunit --xunit-file=test_loadbalance.xml --with-marvin
> --marvin-config=/hudson/scripts/nightly_asf_master.cfg
> /root/cloudstack/test//integration/smoke/test_loadbalance.py --load -a
> tags=advanced
> Exception Occurred Under __initLogging :[Errno 17] File exists:
> '/hudson/workspace/logs13867140921'
> Traceback (most recent call last):
> File "/usr/local/bin/nosetests", line 9, in
> load_entry_point('nose==1.3.0', 'console_scripts', 'nosetests')()
> File "/usr/local/lib/python2.7/site-packages/nose/core.py", line 118, in
> __init__
> **extra_args)
> File "/usr/local/lib/python2.7/unittest/main.py", line 95, in __init__
> self.runTests()
> File "/usr/local/lib/python2.7/site-packages/nose/core.py", line 197, in
> runTests
> result = self.testRunner.run(self.test)
> File "/usr/local/lib/python2.7/site-packages/nose/core.py", line 61, in run
> test(result)
> File "/usr/local/lib/python2.7/site-packages/nose/suite.py", line 176, in
> __call__
> return self.run(*arg, **kw)
> File "/usr/local/lib/python2.7/site-packages/nose/suite.py", line 223, in
> run
> test(orig)
> File "/usr/local/lib/python2.7/site-packages/nose/suite.py", line 176, in
> __call__
> return self.run(*arg, **kw)
> File "/usr/local/lib/python2.7/site-packages/nose/suite.py", line 223, in
> run
> test(orig)
> File "/usr/local/lib/python2.7/site-packages/nose/suite.py", line 176, in
> __call__
> return self.run(*arg, **kw)
> File "/usr/local/lib/python2.7/site-packages/nose/suite.py", line 223, in
> run
> test(orig)
> File "/usr/local/lib/python2.7/site-packages/nose/suite.py", line 176, in
> __call__
> return self.run(*arg, **kw)
> File "/usr/local/lib/python2.7/site-packages/nose/suite.py", line 223, in
> run
> test(orig)
> File "/usr/local/lib/python2.7/site-packages/nose/suite.py", line 176, in
> __call__
> return self.run(*arg, **kw)
> File "/usr/local/lib/python2.7/site-packages/nose/suite.py", line 223, in
> run
> test(orig)
> File "/usr/local/lib/python2.7/site-packages/nose/suite.py", line 176, in
> __call__
> return self.run(*arg, **kw)
> File "/usr/local/lib/python2.7/site-packages/nose/suite.py", line 223, in
> run
> test(orig)
> File "/usr/local/lib/python2.7/site-packages/nose/case.py", line 45, in
> __call__
> return self.run(*arg, **kwarg)
> File "/usr/local/lib/python2.7/site-packages/nose/case.py", line 138, in run
> result.addError(self, err)
> File "/usr/local/lib/python2.7/site-packages/nose/proxy.py", line 124, in
> addError
> plugin_handled = plugins.handleError(self.test, err)
> File "/usr/local/lib/python2.7/site-packages/nose/plugins/manager.py", line
> 99, in __call__
> return self.call(*arg, **kw)
> File "/usr/local/lib/python2.7/site-packages/nose/plugins/manager.py", line
> 167, in simple
> result = meth(*arg, **kw)
> File "/usr/local/lib/python2.7/site-packages/marvin/marvinPlugin.py", line
> 146, in handleError
> self.tcRunLogger.fatal("%s: %s: %s" %
> AttributeError: 'NoneType' object has no attribute 'fatal'
--
This message was sent by Atlassian JIRA
(v6.1.4#6159)
[jira] [Commented] (CLOUDSTACK-5264) Xenserver - Full Snapshots are not being created even after snapshot.delta.max is exceeded
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13849142#comment-13849142 ] Harikrishna Patnala commented on CLOUDSTACK-5264: - Patch is ready to review @https://reviews.apache.org/r/16293/ > Xenserver - Full Snapshots are not being created even after > snapshot.delta.max is exceeded > -- > > Key: CLOUDSTACK-5264 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5264 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.3.0 > Environment: Build from 4.3 >Reporter: Sangeetha Hariharan >Assignee: Harikrishna Patnala >Priority: Blocker > Fix For: 4.3.0 > > Attachments: management-server.rar > > > Snapshots are not being created even after snapshot.delta.max is exceeded. > Set up - Advanced zone with 2 Xenserver 6.2 hosts > Deploy 10 Vms in each of the hosts , so we start with 20 Vms. > We are constantly writing to the ROOT volume ( print timestamp every 1 > minute). > Start concurrent snapshots for ROOT volumes for all the Vms. > Even after 16 snapshots have been created for the ROOT volumes , subsequent > snapshot is still not a FULL snapshot. They continue to be delta snapshot. > mysql> select snapshot_id, > parent_snapshot_id,install_path,store_id,store_role from snapshot_store_ref > where volume_id=89; > +-++-+--++ > | snapshot_id | parent_snapshot_id | install_path >| store_id | store_role | > +-++-+--++ > | 23 | 0 | > snapshots/9/89/8546a63f-dc01-4348-babc-c34c138579c7 |1 | Image | > | 45 | 23 | > snapshots/9/89/9d1404ca-c97e-4f6b-a1a4-3bb5fb1d3900 |1 | Image | > | 105 | 45 | > snapshots/9/89/0323b0cb-446e-4550-a443-d135c4a960b8 |1 | Image | > | 126 |105 | > snapshots/9/89/e440d533-c5cf-464c-940a-505d5b0108c4 |1 | Image | > | 148 |126 | > snapshots/9/89/53f884fb-cd9c-4c35-bcf1-b90f3ce0ea5f |1 | Image | > | 170 |148 | > snapshots/9/89/8ad156ad-e63f-44e1-a8ad-7bcc8acd0b26 |1 | Image | > | 192 |170 | > snapshots/9/89/2781b5af-7c92-482c-8775-f331c7df9b2b |1 | Image | > | 214 |192 | > snapshots/9/89/a2c06f0c-92e4-41b2-a4cb-7d1675146111 |1 | Image | > | 236 |214 | > snapshots/9/89/3bd9fe33-ce59-4148-825f-f9e75e56d088 |1 | Image | > | 258 |236 | > snapshots/9/89/ab414c2b-ed16-4ee2-b3f8-d17b5075fe8d |1 | Image | > | 280 |258 | > snapshots/9/89/cdd97481-d32d-4350-aaae-0a2132c2d934 |1 | Image | > | 302 |280 | > snapshots/9/89/1d82a5a0-1a75-44f3-8a27-dffcf1127b62 |1 | Image | > | 324 |302 | > snapshots/9/89/061043e7-9c22-404c-88e5-183ab4590f5e |1 | Image | > | 346 |324 | > snapshots/9/89/f82e0d43-e83b-493b-b953-6f06a94a369b |1 | Image | > | 368 |346 | > snapshots/9/89/6c0065ad-9fc0-4ce6-957c-0475153c2ed4 |1 | Image | > | 390 |368 | > snapshots/9/89/4399cb51-78a0-4e95-8fc5-8fe2e9e3aa9a |1 | Image | > | 412 |390 | > snapshots/9/89/dd295bd3-1fab-44ad-820e-67a037c828c7 |1 | Image | > | 434 |412 | > snapshots/9/89/afc0ed83-24d5-4373-8e0d-2047d965f1b2 |1 | Image | > | 456 |434 | > snapshots/9/89/88ffc423-a8c6-49c1-8eba-5a91e80c |1 | Image | > | 478 | 0 | 513340d8-d788-4f80-99d4-e8331ce97818 >|1 | Primary| > | 478 |456 | > snapshots/9/89/53d67b21-e6b9-4382-a41e-7c18a7605af0 |1 | Image | > +-++-+--++ > 21 rows in set (0.00 sec) > In secondary store: > -rw-r--r-- 1 root root 7186309632 Nov 22 15:42 > 8546a63f-dc01-4348-babc-c34c138579c7.vhd > -rw-r--r-- 1 root root 155537920 Nov 22 16:36 > 9d1404ca-c97e-4f6b-a1a4-3bb5fb1d3900.vhd > -rw-r--r-- 1 root root 229081600 Nov 24
[jira] [Updated] (CLOUDSTACK-5264) Xenserver - Full Snapshots are not being created even after snapshot.delta.max is exceeded
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Harikrishna Patnala updated CLOUDSTACK-5264: Status: Ready To Review (was: In Progress) > Xenserver - Full Snapshots are not being created even after > snapshot.delta.max is exceeded > -- > > Key: CLOUDSTACK-5264 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5264 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.3.0 > Environment: Build from 4.3 >Reporter: Sangeetha Hariharan >Assignee: Harikrishna Patnala >Priority: Blocker > Fix For: 4.3.0 > > Attachments: management-server.rar > > > Snapshots are not being created even after snapshot.delta.max is exceeded. > Set up - Advanced zone with 2 Xenserver 6.2 hosts > Deploy 10 Vms in each of the hosts , so we start with 20 Vms. > We are constantly writing to the ROOT volume ( print timestamp every 1 > minute). > Start concurrent snapshots for ROOT volumes for all the Vms. > Even after 16 snapshots have been created for the ROOT volumes , subsequent > snapshot is still not a FULL snapshot. They continue to be delta snapshot. > mysql> select snapshot_id, > parent_snapshot_id,install_path,store_id,store_role from snapshot_store_ref > where volume_id=89; > +-++-+--++ > | snapshot_id | parent_snapshot_id | install_path >| store_id | store_role | > +-++-+--++ > | 23 | 0 | > snapshots/9/89/8546a63f-dc01-4348-babc-c34c138579c7 |1 | Image | > | 45 | 23 | > snapshots/9/89/9d1404ca-c97e-4f6b-a1a4-3bb5fb1d3900 |1 | Image | > | 105 | 45 | > snapshots/9/89/0323b0cb-446e-4550-a443-d135c4a960b8 |1 | Image | > | 126 |105 | > snapshots/9/89/e440d533-c5cf-464c-940a-505d5b0108c4 |1 | Image | > | 148 |126 | > snapshots/9/89/53f884fb-cd9c-4c35-bcf1-b90f3ce0ea5f |1 | Image | > | 170 |148 | > snapshots/9/89/8ad156ad-e63f-44e1-a8ad-7bcc8acd0b26 |1 | Image | > | 192 |170 | > snapshots/9/89/2781b5af-7c92-482c-8775-f331c7df9b2b |1 | Image | > | 214 |192 | > snapshots/9/89/a2c06f0c-92e4-41b2-a4cb-7d1675146111 |1 | Image | > | 236 |214 | > snapshots/9/89/3bd9fe33-ce59-4148-825f-f9e75e56d088 |1 | Image | > | 258 |236 | > snapshots/9/89/ab414c2b-ed16-4ee2-b3f8-d17b5075fe8d |1 | Image | > | 280 |258 | > snapshots/9/89/cdd97481-d32d-4350-aaae-0a2132c2d934 |1 | Image | > | 302 |280 | > snapshots/9/89/1d82a5a0-1a75-44f3-8a27-dffcf1127b62 |1 | Image | > | 324 |302 | > snapshots/9/89/061043e7-9c22-404c-88e5-183ab4590f5e |1 | Image | > | 346 |324 | > snapshots/9/89/f82e0d43-e83b-493b-b953-6f06a94a369b |1 | Image | > | 368 |346 | > snapshots/9/89/6c0065ad-9fc0-4ce6-957c-0475153c2ed4 |1 | Image | > | 390 |368 | > snapshots/9/89/4399cb51-78a0-4e95-8fc5-8fe2e9e3aa9a |1 | Image | > | 412 |390 | > snapshots/9/89/dd295bd3-1fab-44ad-820e-67a037c828c7 |1 | Image | > | 434 |412 | > snapshots/9/89/afc0ed83-24d5-4373-8e0d-2047d965f1b2 |1 | Image | > | 456 |434 | > snapshots/9/89/88ffc423-a8c6-49c1-8eba-5a91e80c |1 | Image | > | 478 | 0 | 513340d8-d788-4f80-99d4-e8331ce97818 >|1 | Primary| > | 478 |456 | > snapshots/9/89/53d67b21-e6b9-4382-a41e-7c18a7605af0 |1 | Image | > +-++-+--++ > 21 rows in set (0.00 sec) > In secondary store: > -rw-r--r-- 1 root root 7186309632 Nov 22 15:42 > 8546a63f-dc01-4348-babc-c34c138579c7.vhd > -rw-r--r-- 1 root root 155537920 Nov 22 16:36 > 9d1404ca-c97e-4f6b-a1a4-3bb5fb1d3900.vhd > -rw-r--r-- 1 root root 229081600 Nov 24 18:52 > 0323b0cb-446e-4550-a443-d135c4a960b8.vhd > -rw-r--r-- 1 root
[jira] [Commented] (CLOUDSTACK-4616) When system Vms fail to start when host is down , link local Ip addresses do not get released resulting in all the link local Ip addresses being consumed eventual
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13849152#comment-13849152 ] ASF subversion and git services commented on CLOUDSTACK-4616: - Commit df16623533b1968e33afa89cd52fb231730ca3bc in branch refs/heads/4.3 from [~murali.reddy] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=df16623 ] CLOUDSTACK-4616: When system Vms fail to start when host is down , link local Ip addresses do not get released resulting in all the link local Ip addresses being consumed eventually. fix ensure Nics with reservation strategy 'Start' should go through release phase in the Nic life cycle so that release is performed before Nic is removed to avoid resource leaks. > When system Vms fail to start when host is down , link local Ip addresses do > not get released resulting in all the link local Ip addresses being consumed > eventually. > -- > > Key: CLOUDSTACK-4616 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4616 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.2.1 > Environment: Build from 4.2-forward >Reporter: Sangeetha Hariharan >Assignee: Murali Reddy >Priority: Critical > Fix For: 4.3.0 > > Attachments: hostdown.rar > > > When system Vms fail to start when host is down , link local Ip addresses do > not get released resulting in all the link local Ip addresses being consumed > eventually. > Steps to reproduce the problem: > Advanced zone with 1 cluster having 1 host (Xenserver). > Had SSVM,CCPVM, 2 routers and few user Vms running in the host. > power down the host. > When host was powered down , host is still marked as being in "Up" state . > Bug tracked in - CLOUDSTACK-2140. > Attempt to restart all the system Vms in the host that is down is made > continuously and it fails. > These failed attempts do not result in releasing the linked local Ip , > resulting in all linked local Ips being consumed. > When the host is actually powered on , attempts to start the System Vms fail > , because of teh following exception seen in the management-server.logs: > 013-09-05 12:00:09,551 INFO [cloud.vm.VirtualMachineManagerImpl] > (secstorage-1:null) Insufficient capacity > com.cloud.exception.InsufficientAddressCapacityException: Insufficient link > local address capacityScope=interface com.cloud.dc.DataCenter; id=1 > at > com.cloud.network.guru.ControlNetworkGuru.reserve(ControlNetworkGuru.java:156) > at > com.cloud.network.NetworkManagerImpl.prepareNic(NetworkManagerImpl.java:2157) > at > com.cloud.network.NetworkManagerImpl.prepare(NetworkManagerImpl.java:2127) > at > com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManagerImpl.java:886) > at > com.cloud.vm.VirtualMachineManagerImpl.start(VirtualMachineManagerImpl.java:578) > at > com.cloud.vm.VirtualMachineManagerImpl.start(VirtualMachineManagerImpl.java:571) > at > com.cloud.storage.secondary.SecondaryStorageManagerImpl.startSecStorageVm(SecondaryStorageManagerImpl.java:267) > at > com.cloud.storage.secondary.SecondaryStorageManagerImpl.allocCapacity(SecondaryStorageManagerImpl.java:696) > at > com.cloud.storage.secondary.SecondaryStorageManagerImpl.expandPool(SecondaryStorageManagerImpl.java:1300) > 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:104) > at > com.cloud.vm.SystemVmLoadScanner.access$100(SystemVmLoadScanner.java:33) > at > com.cloud.vm.SystemVmLoadScanner$1.reallyRun(SystemVmLoadScanner.java:81) > at com.cloud.vm.SystemVmLoadScanner$1.run(SystemVmLoadScanner.java:72) > at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) > at > java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:351) > at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:178) > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:165) > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:267) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(Th
[jira] [Commented] (CLOUDSTACK-4616) When system Vms fail to start when host is down , link local Ip addresses do not get released resulting in all the link local Ip addresses being consumed eventual
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13849154#comment-13849154 ] ASF subversion and git services commented on CLOUDSTACK-4616: - Commit c6c299523151345bbc3c97614c8ac995676e229b in branch refs/heads/master from [~murali.reddy] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=c6c2995 ] CLOUDSTACK-4616: When system Vms fail to start when host is down , link local Ip addresses do not get released resulting in all the link local Ip addresses being consumed eventually. fix ensure Nics with reservation strategy 'Start' should go through release phase in the Nic life cycle so that release is performed before Nic is removed to avoid resource leaks. > When system Vms fail to start when host is down , link local Ip addresses do > not get released resulting in all the link local Ip addresses being consumed > eventually. > -- > > Key: CLOUDSTACK-4616 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4616 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.2.1 > Environment: Build from 4.2-forward >Reporter: Sangeetha Hariharan >Assignee: Murali Reddy >Priority: Critical > Fix For: 4.3.0 > > Attachments: hostdown.rar > > > When system Vms fail to start when host is down , link local Ip addresses do > not get released resulting in all the link local Ip addresses being consumed > eventually. > Steps to reproduce the problem: > Advanced zone with 1 cluster having 1 host (Xenserver). > Had SSVM,CCPVM, 2 routers and few user Vms running in the host. > power down the host. > When host was powered down , host is still marked as being in "Up" state . > Bug tracked in - CLOUDSTACK-2140. > Attempt to restart all the system Vms in the host that is down is made > continuously and it fails. > These failed attempts do not result in releasing the linked local Ip , > resulting in all linked local Ips being consumed. > When the host is actually powered on , attempts to start the System Vms fail > , because of teh following exception seen in the management-server.logs: > 013-09-05 12:00:09,551 INFO [cloud.vm.VirtualMachineManagerImpl] > (secstorage-1:null) Insufficient capacity > com.cloud.exception.InsufficientAddressCapacityException: Insufficient link > local address capacityScope=interface com.cloud.dc.DataCenter; id=1 > at > com.cloud.network.guru.ControlNetworkGuru.reserve(ControlNetworkGuru.java:156) > at > com.cloud.network.NetworkManagerImpl.prepareNic(NetworkManagerImpl.java:2157) > at > com.cloud.network.NetworkManagerImpl.prepare(NetworkManagerImpl.java:2127) > at > com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManagerImpl.java:886) > at > com.cloud.vm.VirtualMachineManagerImpl.start(VirtualMachineManagerImpl.java:578) > at > com.cloud.vm.VirtualMachineManagerImpl.start(VirtualMachineManagerImpl.java:571) > at > com.cloud.storage.secondary.SecondaryStorageManagerImpl.startSecStorageVm(SecondaryStorageManagerImpl.java:267) > at > com.cloud.storage.secondary.SecondaryStorageManagerImpl.allocCapacity(SecondaryStorageManagerImpl.java:696) > at > com.cloud.storage.secondary.SecondaryStorageManagerImpl.expandPool(SecondaryStorageManagerImpl.java:1300) > 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:104) > at > com.cloud.vm.SystemVmLoadScanner.access$100(SystemVmLoadScanner.java:33) > at > com.cloud.vm.SystemVmLoadScanner$1.reallyRun(SystemVmLoadScanner.java:81) > at com.cloud.vm.SystemVmLoadScanner$1.run(SystemVmLoadScanner.java:72) > at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) > at > java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:351) > at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:178) > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:165) > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:267) > at > java.util.concurrent.ThreadPoolExecutor.runWorker
[jira] [Created] (CLOUDSTACK-5517) NPE observed during "release portable IPs" as part of account cleanup
Murali Reddy created CLOUDSTACK-5517: Summary: NPE observed during "release portable IPs" as part of account cleanup Key: CLOUDSTACK-5517 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5517 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Affects Versions: 4.2.0 Reporter: Murali Reddy Assignee: Murali Reddy Fix For: 4.3.0 Failed to cleanup accounts ; observed below NPE in MS log 2013-11-15 07:58:14,832 DEBUG [db.Transaction.Transaction] (AccountChecker-1:null) Rolling back the transaction: Time = 10002 Name = -Account ManagerImpl$AccountCleanupTask.run:1509-Executors$RunnableAdapter.call:471-FutureTask$Sync.innerRunAndReset:351-FutureTask.runAndReset:178-Sch eduledThreadPoolExecutor$ScheduledFutureTask.access$201:165-ScheduledThreadPoolExecutor$ScheduledFutureTask.run:267-ThreadPoolExecutor.runWork er:1110-ThreadPoolExecutor$Worker.run:603-Thread.run:679; called by -Transaction.rollback:897-Transaction.removeUpTo:840-Transaction.close:664 -TransactionContextBuilder.interceptException:63-ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept:133-AccountManagerImpl.cl eanupAccount:743-AccountManagerImpl$AccountCleanupTask.run:1516-Executors$RunnableAdapter.call:471-FutureTask$Sync.innerRunAndReset:351-Future Task.runAndReset:178-ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201:165-ScheduledThreadPoolExecutor$ScheduledFutureTask.run:267 2013-11-15 07:58:14,833 WARN [cloud.user.AccountManagerImpl] (AccountChecker-1:null) Failed to cleanup account Acct[c1ee43bc-6ff8-459b-854e-1 85719e53afd-test-TestEgressFWRules-H56EZ1] due to java.lang.NullPointerException at com.cloud.network.NetworkManagerImpl.releasePortableIpAddress(NetworkManagerImpl.java:1292) at com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.j ava:125) at com.cloud.user.AccountManagerImpl.cleanupAccount(AccountManagerImpl.java:743) at com.cloud.user.AccountManagerImpl$AccountCleanupTask.run(AccountManagerImpl.java:1516) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:351) at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:178) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:165) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:267) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) at java.lang.Thread.run(Thread.java:679) 2013-11-15 07:58:14,833 INFO [cloud.user.AccountManagerImpl] (AccountChecker-1:null) Cleanup for account 80 is needed. 2013-11-15 07:58:14,834 DEBUG [cloud.user.AccountManagerImpl] (AccountChecker-1:null) Cleaning up 237 2013-11-15 07:58:14,839 DEBUG [cloud.user.AccountManagerImpl] (AccountChecker-1:null) Successfully deleted snapshots directories for all volum es under account 237 across all zones -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Created] (CLOUDSTACK-5518) [Automation] test_04_remove_unused_range is removing all unused VLAN ranges which is causing insufficient network capacity
Srikanteswararao Talluri created CLOUDSTACK-5518:
Summary: [Automation] test_04_remove_unused_range is removing all
unused VLAN ranges which is causing insufficient network capacity
Key: CLOUDSTACK-5518
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5518
Project: CloudStack
Issue Type: Test
Security Level: Public (Anyone can view this level - this is the default.)
Components: Automation
Affects Versions: 4.3.0
Reporter: Srikanteswararao Talluri
Assignee: Srikanteswararao Talluri
Priority: Critical
Fix For: 4.3.0
This test has left only two VLANs in the physical network.
Stacktrace
File "/usr/local/lib/python2.7/unittest/case.py", line 345, in run
self.tearDown()
File
"/root/cloudstack/test/integration/component/test_non_contiguous_vlan.py", line
128, in tearDown
self.physicalnetwork.update(self.apiClient, id = self.physicalnetworkid,
vlan=self.existingvlan)
File "/usr/local/lib/python2.7/site-packages/marvin/integration/lib/base.py",
line 2520, in update
return apiclient.updatePhysicalNetwork(cmd)
File
"/usr/local/lib/python2.7/site-packages/marvin/cloudstackAPI/cloudstackAPIClient.py",
line 688, in updatePhysicalNetwork
response = self.connection.marvinRequest(command, response_type=response,
method=method)
File "/usr/local/lib/python2.7/site-packages/marvin/cloudstackConnection.py",
line 280, in marvinRequest
response = self.poll(asyncJobId, response_type)
File "/usr/local/lib/python2.7/site-packages/marvin/cloudstackConnection.py",
line 86, in poll
"asyncquery", asyncResonse.jobresult)
Execute cmd: asyncquery failed, due to: {errorcode : 530, errortext :
u'physicalnetwork 200 has allocated vnets in the range 1072-1073'}
--
This message was sent by Atlassian JIRA
(v6.1.4#6159)
[jira] [Updated] (CLOUDSTACK-5518) [Automation] test_04_remove_unused_range is removing all unused VLAN ranges which is causing insufficient network capacity
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5518?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Srikanteswararao Talluri updated CLOUDSTACK-5518:
-
Assignee: (was: Srikanteswararao Talluri)
> [Automation] test_04_remove_unused_range is removing all unused VLAN ranges
> which is causing insufficient network capacity
> --
>
> Key: CLOUDSTACK-5518
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5518
> Project: CloudStack
> Issue Type: Test
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Automation
>Affects Versions: 4.3.0
>Reporter: Srikanteswararao Talluri
>Priority: Critical
> Fix For: 4.3.0
>
>
> This test has left only two VLANs in the physical network.
> Stacktrace
> File "/usr/local/lib/python2.7/unittest/case.py", line 345, in run
> self.tearDown()
> File
> "/root/cloudstack/test/integration/component/test_non_contiguous_vlan.py",
> line 128, in tearDown
> self.physicalnetwork.update(self.apiClient, id = self.physicalnetworkid,
> vlan=self.existingvlan)
> File
> "/usr/local/lib/python2.7/site-packages/marvin/integration/lib/base.py", line
> 2520, in update
> return apiclient.updatePhysicalNetwork(cmd)
> File
> "/usr/local/lib/python2.7/site-packages/marvin/cloudstackAPI/cloudstackAPIClient.py",
> line 688, in updatePhysicalNetwork
> response = self.connection.marvinRequest(command, response_type=response,
> method=method)
> File
> "/usr/local/lib/python2.7/site-packages/marvin/cloudstackConnection.py", line
> 280, in marvinRequest
> response = self.poll(asyncJobId, response_type)
> File
> "/usr/local/lib/python2.7/site-packages/marvin/cloudstackConnection.py", line
> 86, in poll
> "asyncquery", asyncResonse.jobresult)
> Execute cmd: asyncquery failed, due to: {errorcode : 530, errortext :
> u'physicalnetwork 200 has allocated vnets in the range 1072-1073'}
--
This message was sent by Atlassian JIRA
(v6.1.4#6159)
[jira] [Resolved] (CLOUDSTACK-4616) When system Vms fail to start when host is down , link local Ip addresses do not get released resulting in all the link local Ip addresses being consumed eventuall
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4616?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Murali Reddy resolved CLOUDSTACK-4616. -- Resolution: Fixed > When system Vms fail to start when host is down , link local Ip addresses do > not get released resulting in all the link local Ip addresses being consumed > eventually. > -- > > Key: CLOUDSTACK-4616 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4616 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.2.1 > Environment: Build from 4.2-forward >Reporter: Sangeetha Hariharan >Assignee: Murali Reddy >Priority: Critical > Fix For: 4.3.0 > > Attachments: hostdown.rar > > > When system Vms fail to start when host is down , link local Ip addresses do > not get released resulting in all the link local Ip addresses being consumed > eventually. > Steps to reproduce the problem: > Advanced zone with 1 cluster having 1 host (Xenserver). > Had SSVM,CCPVM, 2 routers and few user Vms running in the host. > power down the host. > When host was powered down , host is still marked as being in "Up" state . > Bug tracked in - CLOUDSTACK-2140. > Attempt to restart all the system Vms in the host that is down is made > continuously and it fails. > These failed attempts do not result in releasing the linked local Ip , > resulting in all linked local Ips being consumed. > When the host is actually powered on , attempts to start the System Vms fail > , because of teh following exception seen in the management-server.logs: > 013-09-05 12:00:09,551 INFO [cloud.vm.VirtualMachineManagerImpl] > (secstorage-1:null) Insufficient capacity > com.cloud.exception.InsufficientAddressCapacityException: Insufficient link > local address capacityScope=interface com.cloud.dc.DataCenter; id=1 > at > com.cloud.network.guru.ControlNetworkGuru.reserve(ControlNetworkGuru.java:156) > at > com.cloud.network.NetworkManagerImpl.prepareNic(NetworkManagerImpl.java:2157) > at > com.cloud.network.NetworkManagerImpl.prepare(NetworkManagerImpl.java:2127) > at > com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManagerImpl.java:886) > at > com.cloud.vm.VirtualMachineManagerImpl.start(VirtualMachineManagerImpl.java:578) > at > com.cloud.vm.VirtualMachineManagerImpl.start(VirtualMachineManagerImpl.java:571) > at > com.cloud.storage.secondary.SecondaryStorageManagerImpl.startSecStorageVm(SecondaryStorageManagerImpl.java:267) > at > com.cloud.storage.secondary.SecondaryStorageManagerImpl.allocCapacity(SecondaryStorageManagerImpl.java:696) > at > com.cloud.storage.secondary.SecondaryStorageManagerImpl.expandPool(SecondaryStorageManagerImpl.java:1300) > 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:104) > at > com.cloud.vm.SystemVmLoadScanner.access$100(SystemVmLoadScanner.java:33) > at > com.cloud.vm.SystemVmLoadScanner$1.reallyRun(SystemVmLoadScanner.java:81) > at com.cloud.vm.SystemVmLoadScanner$1.run(SystemVmLoadScanner.java:72) > at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) > at > java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:351) > at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:178) > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:165) > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:267) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) > at java.lang.Thread.run(Thread.java:679) > mysql> select * from op_dc_link_local_ip_address_alloc where data_center_id=1 > and taken is null; > Empty set (0.00 sec) > -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Commented] (CLOUDSTACK-5517) NPE observed during "release portable IPs" as part of account cleanup
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5517?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13849172#comment-13849172 ] ASF subversion and git services commented on CLOUDSTACK-5517: - Commit 307e0586902bb5b1775652e31bca02c8326e15d9 in branch refs/heads/4.3 from [~murali.reddy] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=307e058 ] CLOUDSTACK-5517: NPE observed during "release portable IPs" as part of account cleanup ensure proper portable ip address are released as part of account cleanup > NPE observed during "release portable IPs" as part of account cleanup > - > > Key: CLOUDSTACK-5517 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5517 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.2.0 >Reporter: Murali Reddy >Assignee: Murali Reddy > Fix For: 4.3.0 > > > Failed to cleanup accounts ; observed below NPE in MS log > 2013-11-15 07:58:14,832 DEBUG [db.Transaction.Transaction] > (AccountChecker-1:null) Rolling back the transaction: Time = 10002 Name = > -Account > ManagerImpl$AccountCleanupTask.run:1509-Executors$RunnableAdapter.call:471-FutureTask$Sync.innerRunAndReset:351-FutureTask.runAndReset:178-Sch > eduledThreadPoolExecutor$ScheduledFutureTask.access$201:165-ScheduledThreadPoolExecutor$ScheduledFutureTask.run:267-ThreadPoolExecutor.runWork > er:1110-ThreadPoolExecutor$Worker.run:603-Thread.run:679; called by > -Transaction.rollback:897-Transaction.removeUpTo:840-Transaction.close:664 > -TransactionContextBuilder.interceptException:63-ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept:133-AccountManagerImpl.cl > eanupAccount:743-AccountManagerImpl$AccountCleanupTask.run:1516-Executors$RunnableAdapter.call:471-FutureTask$Sync.innerRunAndReset:351-Future > Task.runAndReset:178-ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201:165-ScheduledThreadPoolExecutor$ScheduledFutureTask.run:267 > 2013-11-15 07:58:14,833 WARN [cloud.user.AccountManagerImpl] > (AccountChecker-1:null) Failed to cleanup account > Acct[c1ee43bc-6ff8-459b-854e-1 > 85719e53afd-test-TestEgressFWRules-H56EZ1] due to > java.lang.NullPointerException > at > com.cloud.network.NetworkManagerImpl.releasePortableIpAddress(NetworkManagerImpl.java:1292) > at > com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.j > ava:125) > at > com.cloud.user.AccountManagerImpl.cleanupAccount(AccountManagerImpl.java:743) > at > com.cloud.user.AccountManagerImpl$AccountCleanupTask.run(AccountManagerImpl.java:1516) > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) > at java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:351) > at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:178) > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:165) > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:267) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) > at java.lang.Thread.run(Thread.java:679) > 2013-11-15 07:58:14,833 INFO [cloud.user.AccountManagerImpl] > (AccountChecker-1:null) Cleanup for account 80 is needed. > 2013-11-15 07:58:14,834 DEBUG [cloud.user.AccountManagerImpl] > (AccountChecker-1:null) Cleaning up 237 > 2013-11-15 07:58:14,839 DEBUG [cloud.user.AccountManagerImpl] > (AccountChecker-1:null) Successfully deleted snapshots directories for all > volum > es under account 237 across all zones -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Created] (CLOUDSTACK-5516) Handling of broadcast traffic in GRE-based SDN
tuna created CLOUDSTACK-5516: Summary: Handling of broadcast traffic in GRE-based SDN Key: CLOUDSTACK-5516 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5516 Project: CloudStack Issue Type: Improvement Security Level: Public (Anyone can view this level - this is the default.) Reporter: tuna Fix For: Future The overlay network creates a virtual layer-2 broadcast domain spanning over the hosts where a VM for a given network is deployed. This could result in a fairly large virtual layer-2 broadcast domain. In order to improve the performance of the network it would be vital to ensure the impact of broadcasts on network throughout is minimized. To this aim, Cloudstack knowledge about the topology of the cloud can be used for reducing the amount of broadcast traffic in the following way: - DHCP traffic - DHCP requests could be redirected to a local tap port which is connected to a dnsmasq process populated and updated by Cloudstack. DHCP traffic could then be squelched over the tunnels. Another benefit is that the initial IP configuration for the NICs might happen independently of the state of the tunnel mesh. - ARP traffic - A similar approach can be adopted for ARP broadcast, which can be redirected to a tap port connected to a process which reads ARP requests and sends ARP replies reading info from a cache maintained by Cloudstack itself While this clearly reduces the amount of broadcast traffic on the network, it increases the management burden for Cloudstack. It is vital that entries are added and invalidated into this cache in an appropriate way. While invalidation should always occur in cases such as VM stop, VM pause, and VM migration, there are several strategies for populating this cache, for instance: 1. Cloudstack could add entries to the cache as soon as the deployment plan for a VM is known 2. The cache upon a miss, might send an update request to the Cloudstack management server, which will provide the requested information (e.g.: MAC corresponding to a given IP). -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Commented] (CLOUDSTACK-5517) NPE observed during "release portable IPs" as part of account cleanup
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5517?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13849174#comment-13849174 ] ASF subversion and git services commented on CLOUDSTACK-5517: - Commit 12adbffbea77b6a21aa8350d0b0effd1c7fb9702 in branch refs/heads/master from [~murali.reddy] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=12adbff ] CLOUDSTACK-5517: NPE observed during "release portable IPs" as part of account cleanup ensure proper portable ip address are released as part of account cleanup > NPE observed during "release portable IPs" as part of account cleanup > - > > Key: CLOUDSTACK-5517 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5517 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.2.0 >Reporter: Murali Reddy >Assignee: Murali Reddy > Fix For: 4.3.0 > > > Failed to cleanup accounts ; observed below NPE in MS log > 2013-11-15 07:58:14,832 DEBUG [db.Transaction.Transaction] > (AccountChecker-1:null) Rolling back the transaction: Time = 10002 Name = > -Account > ManagerImpl$AccountCleanupTask.run:1509-Executors$RunnableAdapter.call:471-FutureTask$Sync.innerRunAndReset:351-FutureTask.runAndReset:178-Sch > eduledThreadPoolExecutor$ScheduledFutureTask.access$201:165-ScheduledThreadPoolExecutor$ScheduledFutureTask.run:267-ThreadPoolExecutor.runWork > er:1110-ThreadPoolExecutor$Worker.run:603-Thread.run:679; called by > -Transaction.rollback:897-Transaction.removeUpTo:840-Transaction.close:664 > -TransactionContextBuilder.interceptException:63-ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept:133-AccountManagerImpl.cl > eanupAccount:743-AccountManagerImpl$AccountCleanupTask.run:1516-Executors$RunnableAdapter.call:471-FutureTask$Sync.innerRunAndReset:351-Future > Task.runAndReset:178-ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201:165-ScheduledThreadPoolExecutor$ScheduledFutureTask.run:267 > 2013-11-15 07:58:14,833 WARN [cloud.user.AccountManagerImpl] > (AccountChecker-1:null) Failed to cleanup account > Acct[c1ee43bc-6ff8-459b-854e-1 > 85719e53afd-test-TestEgressFWRules-H56EZ1] due to > java.lang.NullPointerException > at > com.cloud.network.NetworkManagerImpl.releasePortableIpAddress(NetworkManagerImpl.java:1292) > at > com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.j > ava:125) > at > com.cloud.user.AccountManagerImpl.cleanupAccount(AccountManagerImpl.java:743) > at > com.cloud.user.AccountManagerImpl$AccountCleanupTask.run(AccountManagerImpl.java:1516) > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) > at java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:351) > at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:178) > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:165) > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:267) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) > at java.lang.Thread.run(Thread.java:679) > 2013-11-15 07:58:14,833 INFO [cloud.user.AccountManagerImpl] > (AccountChecker-1:null) Cleanup for account 80 is needed. > 2013-11-15 07:58:14,834 DEBUG [cloud.user.AccountManagerImpl] > (AccountChecker-1:null) Cleaning up 237 > 2013-11-15 07:58:14,839 DEBUG [cloud.user.AccountManagerImpl] > (AccountChecker-1:null) Successfully deleted snapshots directories for all > volum > es under account 237 across all zones -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Resolved] (CLOUDSTACK-5517) NPE observed during "release portable IPs" as part of account cleanup
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5517?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Murali Reddy resolved CLOUDSTACK-5517. -- Resolution: Fixed > NPE observed during "release portable IPs" as part of account cleanup > - > > Key: CLOUDSTACK-5517 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5517 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.2.0 >Reporter: Murali Reddy >Assignee: Murali Reddy > Fix For: 4.3.0 > > > Failed to cleanup accounts ; observed below NPE in MS log > 2013-11-15 07:58:14,832 DEBUG [db.Transaction.Transaction] > (AccountChecker-1:null) Rolling back the transaction: Time = 10002 Name = > -Account > ManagerImpl$AccountCleanupTask.run:1509-Executors$RunnableAdapter.call:471-FutureTask$Sync.innerRunAndReset:351-FutureTask.runAndReset:178-Sch > eduledThreadPoolExecutor$ScheduledFutureTask.access$201:165-ScheduledThreadPoolExecutor$ScheduledFutureTask.run:267-ThreadPoolExecutor.runWork > er:1110-ThreadPoolExecutor$Worker.run:603-Thread.run:679; called by > -Transaction.rollback:897-Transaction.removeUpTo:840-Transaction.close:664 > -TransactionContextBuilder.interceptException:63-ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept:133-AccountManagerImpl.cl > eanupAccount:743-AccountManagerImpl$AccountCleanupTask.run:1516-Executors$RunnableAdapter.call:471-FutureTask$Sync.innerRunAndReset:351-Future > Task.runAndReset:178-ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201:165-ScheduledThreadPoolExecutor$ScheduledFutureTask.run:267 > 2013-11-15 07:58:14,833 WARN [cloud.user.AccountManagerImpl] > (AccountChecker-1:null) Failed to cleanup account > Acct[c1ee43bc-6ff8-459b-854e-1 > 85719e53afd-test-TestEgressFWRules-H56EZ1] due to > java.lang.NullPointerException > at > com.cloud.network.NetworkManagerImpl.releasePortableIpAddress(NetworkManagerImpl.java:1292) > at > com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.j > ava:125) > at > com.cloud.user.AccountManagerImpl.cleanupAccount(AccountManagerImpl.java:743) > at > com.cloud.user.AccountManagerImpl$AccountCleanupTask.run(AccountManagerImpl.java:1516) > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) > at java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:351) > at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:178) > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:165) > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:267) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) > at java.lang.Thread.run(Thread.java:679) > 2013-11-15 07:58:14,833 INFO [cloud.user.AccountManagerImpl] > (AccountChecker-1:null) Cleanup for account 80 is needed. > 2013-11-15 07:58:14,834 DEBUG [cloud.user.AccountManagerImpl] > (AccountChecker-1:null) Cleaning up 237 > 2013-11-15 07:58:14,839 DEBUG [cloud.user.AccountManagerImpl] > (AccountChecker-1:null) Successfully deleted snapshots directories for all > volum > es under account 237 across all zones -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Commented] (CLOUDSTACK-5518) [Automation] test_04_remove_unused_range is removing all unused VLAN ranges which is causing insufficient network capacity
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13849173#comment-13849173
]
Srikanteswararao Talluri commented on CLOUDSTACK-5518:
--
This test says:
"""
# 1. Add new non contiguous range to existing vlan range
# 2. Remove unused vlan range
# 3. Unused vlan range should gte removed successfully
we should not modify the existing VLAN range which will cause other tests to
fail. Hence, remove unused VLAN range from the newly added VLAN as part of the
test.
> [Automation] test_04_remove_unused_range is removing all unused VLAN ranges
> which is causing insufficient network capacity
> --
>
> Key: CLOUDSTACK-5518
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5518
> Project: CloudStack
> Issue Type: Test
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Automation
>Affects Versions: 4.3.0
>Reporter: Srikanteswararao Talluri
>Priority: Critical
> Fix For: 4.3.0
>
>
> This test has left only two VLANs in the physical network.
> Stacktrace
> File "/usr/local/lib/python2.7/unittest/case.py", line 345, in run
> self.tearDown()
> File
> "/root/cloudstack/test/integration/component/test_non_contiguous_vlan.py",
> line 128, in tearDown
> self.physicalnetwork.update(self.apiClient, id = self.physicalnetworkid,
> vlan=self.existingvlan)
> File
> "/usr/local/lib/python2.7/site-packages/marvin/integration/lib/base.py", line
> 2520, in update
> return apiclient.updatePhysicalNetwork(cmd)
> File
> "/usr/local/lib/python2.7/site-packages/marvin/cloudstackAPI/cloudstackAPIClient.py",
> line 688, in updatePhysicalNetwork
> response = self.connection.marvinRequest(command, response_type=response,
> method=method)
> File
> "/usr/local/lib/python2.7/site-packages/marvin/cloudstackConnection.py", line
> 280, in marvinRequest
> response = self.poll(asyncJobId, response_type)
> File
> "/usr/local/lib/python2.7/site-packages/marvin/cloudstackConnection.py", line
> 86, in poll
> "asyncquery", asyncResonse.jobresult)
> Execute cmd: asyncquery failed, due to: {errorcode : 530, errortext :
> u'physicalnetwork 200 has allocated vnets in the range 1072-1073'}
--
This message was sent by Atlassian JIRA
(v6.1.4#6159)
[jira] [Created] (CLOUDSTACK-5519) [VMWARE] Cancel vCenter tasks if the task invoked by CloudStack failes with timeout error
Likitha Shetty created CLOUDSTACK-5519: -- Summary: [VMWARE] Cancel vCenter tasks if the task invoked by CloudStack failes with timeout error Key: CLOUDSTACK-5519 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5519 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: VMware Affects Versions: 4.2.1 Reporter: Likitha Shetty Assignee: Likitha Shetty Fix For: 4.3.0 If a vCenter task takes more than 20 minutes(default vCenter session timeout) to complete, then CS errors out with Socket timeout exception but the the task continues to run in vCenter. Since there is mismatch in the state of the task between CloudStack and vCenter, If a task times out in Cloudstack we should cancel the running task in vCenter. -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Assigned] (CLOUDSTACK-5440) Missing GuestOS types for CentOS6.5, Windows 8.1 and Windows Server 2012 R2
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5440?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Hitchins reassigned CLOUDSTACK-5440: -- Assignee: Alexander Hitchins > Missing GuestOS types for CentOS6.5, Windows 8.1 and Windows Server 2012 R2 > --- > > Key: CLOUDSTACK-5440 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5440 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Donal Lafferty >Assignee: Alexander Hitchins >Priority: Minor > > These operating systems were released in the last month or two, but they do > not appear as new os_guest types in > https://github.com/apache/cloudstack/blob/master/setup/db/db/schema-421to430.sql -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Assigned] (CLOUDSTACK-5438) Missing RPM dependency
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5438?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Hitchins reassigned CLOUDSTACK-5438: -- Assignee: Alexander Hitchins > Missing RPM dependency > -- > > Key: CLOUDSTACK-5438 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5438 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) > Components: KVM, Virtual Router >Affects Versions: 4.2.0 > Environment: CentOS 6 x86_64 >Reporter: Nux >Assignee: Alexander Hitchins > Labels: kvm,, rpm,, vr > > Hello, > On CS 4.2 with KVM on CentOS the cloudstack-agent RPM should have > openssh-clients as a dependency, otherwise the host cannot contact the > Virtual Router, making it's deployment impossible. > A minimal CentOS deployment comes without this package and I would guess many > start from a minimal deployment. > This is probably also valid for Debian/Ubuntu. -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Commented] (CLOUDSTACK-5250) [Automation] integration.smoke.test_network.TestReleaseIP.test_releaseIP failing
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13849226#comment-13849226
]
Rayees Namathponnan commented on CLOUDSTACK-5250:
-
This is an intermediate issue
> [Automation] integration.smoke.test_network.TestReleaseIP.test_releaseIP
> failing
> --
>
> Key: CLOUDSTACK-5250
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5250
> Project: CloudStack
> Issue Type: Test
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Automation
>Affects Versions: 4.3.0
> Environment: KVM
> automation
>Reporter: Rayees Namathponnan
> Fix For: 4.3.0
>
>
> [Automation] integration.smoke.test_network.TestReleaseIP.test_releaseIP
> failing after fixing CLOUDSTACK-4344
> heck if disassociated IP Address is no longer available
> >> begin captured logging <<
> test_releaseIP (integration.smoke.test_network.TestReleaseIP): DEBUG:
> Deleting Public IP : 2c0e1ad7-639b-4564-ba82-d44a41740c34
> test_releaseIP (integration.smoke.test_network.TestReleaseIP): DEBUG: List
> Public IP response[{networkid : u'04c5487a-5754-432f-81cd-d52738c1eb9c',
> physicalnetworkid : u'ddf995ff-4f12-4cae-9729-5b763a1e1170', account :
> u'test-TestReleaseIP-test_releaseIP-RTK06M', domainid :
> u'5f0d3956-531c-11e3-a447-1a6f7bb0d0a8', issourcenat : True, isstaticnat :
> False, tags : [], associatednetworkname :
> u'test-TestReleaseIP-test_releaseIP-RTK06M-network', domain : u'ROOT', vlanid
> : u'7746889d-db42-41c2-90d1-1876847c2377', zoneid :
> u'9338ab1f-fee3-43dc-98cc-9aa2839b0d19', vlanname : u'vlan://1221', state :
> u'Allocated', associatednetworkid : u'823a5c6c-53d4-4dc0-8672-a3daeb9ff6ff',
> zonename : u'Adv-KVM-Zone1', forvirtualnetwork : True, allocated :
> u'2013-11-21T20:11:44-0800', issystem : False, ipaddress : u'10.223.122.74',
> id : u'2c0e1ad7-639b-4564-ba82-d44a41740c34', isportable : False}]
> - >> end captured logging << -
> Stacktrace
> File "/usr/local/lib/python2.7/unittest/case.py", line 318, in run
> testMethod()
> File "/Repo_30X/ipcl/cloudstack/test/integration/smoke/test_network.py",
> line 859, in test_releaseIP
> "Check if disassociated IP Address is no longer available"
> File "/usr/local/lib/python2.7/unittest/case.py", line 494, in assertEqual
> assertion_func(first, second, msg=msg)
> File "/usr/local/lib/python2.7/unittest/case.py", line 487, in
> _baseAssertEqual
> raise self.failureException(msg)
> Check if disassociated IP Address is no longer available
> >> begin captured logging <<
> test_releaseIP (integration.smoke.test_network.TestReleaseIP): DEBUG:
> Deleting Public IP : 2c0e1ad7-639b-4564-ba82-d44a41740c34
> test_releaseIP (integration.smoke.test_network.TestReleaseIP): DEBUG: List
> Public IP response[{networkid : u'04c5487a-5754-432f-81cd-d52738c1eb9c',
> physicalnetworkid : u'ddf995ff-4f12-4cae-9729-5b763a1e1170', account :
> u'test-TestReleaseIP-test_releaseIP-RTK06M', domainid :
> u'5f0d3956-531c-11e3-a447-1a6f7bb0d0a8', issourcenat : True, isstaticnat :
> False, tags : [], associatednetworkname :
> u'test-TestReleaseIP-test_releaseIP-RTK06M-network', domain : u'ROOT', vlanid
> : u'7746889d-db42-41c2-90d1-1876847c2377', zoneid :
> u'9338ab1f-fee3-43dc-98cc-9aa2839b0d19', vlanname : u'vlan://1221', state :
> u'Allocated', associatednetworkid : u'823a5c6c-53d4-4dc0-8672-a3daeb9ff6ff',
> zonename : u'Adv-KVM-Zone1', forvirtualnetwork : True, allocated :
> u'2013-11-21T20:11:44-0800', issystem : False, ipaddress : u'10.223.122.74',
> id : u'2c0e1ad7-639b-4564-ba82-d44a41740c34', isportable : False}]
> - >> end captured logging << -
--
This message was sent by Atlassian JIRA
(v6.1.4#6159)
[jira] [Commented] (CLOUDSTACK-5267) [Automation] instance.name name should not append with VM's Name
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13849229#comment-13849229 ] Rayees Namathponnan commented on CLOUDSTACK-5267: - seems got fixed part of other defect fix > [Automation] instance.name name should not append with VM's Name > > > Key: CLOUDSTACK-5267 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5267 > Project: CloudStack > Issue Type: Test > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation >Affects Versions: 4.3.0 > Environment: Branch : 4.3.0 >Reporter: Rayees Namathponnan >Assignee: Girish Shilamkar >Priority: Blocker > Labels: automation > Fix For: 4.3.0 > > > Steps to reproduce > Step 1 : set instance.name=TestVM in global parameter > Step 2 : Restart MS and Deploy Vm, dont specify any name while deploying the > VM > Actual Result > UUID of new VM is 56276ab1-3353-473c-8b35-f27f81f68bd8, and vm should be > deployed with name "56276ab1-3353-473c-8b35-f27f81f68bd8" > vm deployed with name TestVM56276ab1-3353-473c-8b35-f27f81f68bd8, here > instance.name also included > We need to remove instance.name from vm name -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Commented] (CLOUDSTACK-4332) [Automation][VMware] test_netscaler_lb_algo test case failed with error 'ROUNDROBIN' algorithm should be configured on NS
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13849318#comment-13849318
]
Girish Shilamkar commented on CLOUDSTACK-4332:
--
Rayees, this is a setup issue. Talluri knows more about it.
> [Automation][VMware] test_netscaler_lb_algo test case failed with error
> 'ROUNDROBIN' algorithm should be configured on NS
> -
>
> Key: CLOUDSTACK-4332
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4332
> Project: CloudStack
> Issue Type: Test
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Automation, Test
>Affects Versions: 4.2.0
> Environment: Automation
>Reporter: Rayees Namathponnan
>Priority: Critical
> Fix For: 4.3.0
>
>
> Below test cases failed from test_netscaler_lb_algo
> integration.component.test_netscaler_lb_algo.TestLbAlgoRrLc.test_lb_round_robin_to_least_conn
> integration.component.test_netscaler_lb_algo.TestLbAlgoSbLc.test_lb_source_to_least_conn
> integration.component.test_netscaler_lb_algo.TestLbAlgoSbRr.test_lb_source_to_round_robin
> test cases failed with error
> SSH Access failed for 10.223.240.174: 'ROUNDROBIN' algorithm should be
> configured on NS
> >> begin captured logging <<
> testclient.testcase.TestLbAlgoRrLc: DEBUG: Creating LB rule for IP address:
> 10.223.243.39 with round robin algo
> testclient.testcase.TestLbAlgoRrLc: DEBUG: Adding
> 0e5032f4-7bc1-4baa-b3fe-0cfa83f4f56d to the LB rule SSH
> testclient.testcase.TestLbAlgoRrLc: DEBUG: SSH into Netscaler to check
> whether algorithm is configured properly or not?
> testclient.testcase.TestLbAlgoRrLc: DEBUG: SSH into netscaler: 10.223.240.174
> paramiko.transport: DEBUG: starting thread (client mode): 0xe6ffc90L
> paramiko.transport: INFO: Connected (version 2.0, client OpenSSH_4.5p1)
> paramiko.transport: DEBUG: kex algos:['diffie-hellman-group-exchange-sha256',
> 'diffie-hellman-group-exchange-sha1', 'diffie-hellman-group14-sha1',
> 'diffie-hellman-group1-sha1'] server key:['ssh-rsa', 'ssh-dss'] client
> encrypt:['aes128-ctr', 'aes192-ctr', 'aes256-ctr', 'arcfour256',
> 'arcfour128', 'aes128-cbc', '3des-cbc', 'blowfish-cbc', 'cast128-cbc',
> 'aes192-cbc', 'aes256-cbc', 'arcfour', 'rijndael-...@lysator.liu.se'] server
> encrypt:['aes128-ctr', 'aes192-ctr', 'aes256-ctr', 'arcfour256',
> 'arcfour128', 'aes128-cbc', '3des-cbc', 'blowfish-cbc', 'cast128-cbc',
> 'aes192-cbc', 'aes256-cbc', 'arcfour', 'rijndael-...@lysator.liu.se'] client
> mac:['hmac-md5', 'hmac-sha1', 'hmac-ripemd160', 'hmac-ripemd...@openssh.com',
> 'hmac-sha1-96', 'hmac-md5-96'] server mac:['hmac-md5', 'hmac-sha1',
> 'hmac-ripemd160', 'hmac-ripemd...@openssh.com', 'hmac-sha1-96',
> 'hmac-md5-96'] client compress:['none', 'z...@openssh.com'] server
> compress:['none', 'z...@openssh.com'] client lang:[''] server lang:[''] kex
> follows?False
> paramiko.transport: DEBUG: Ciphers agreed: local=aes128-ctr, remote=aes128-ctr
> paramiko.transport: DEBUG: using kex diffie-hellman-group1-sha1; server key
> type ssh-rsa; cipher: local aes128-ctr, remote aes128-ctr; mac: local
> hmac-sha1, remote hmac-sha1; compression: local none, remote none
> paramiko.transport: DEBUG: Switch to new keys ...
> paramiko.transport: DEBUG: Adding ssh-rsa host key for 10.223.240.174:
> d649584fc563d9bf271484c8f3146dc2
> paramiko.transport: DEBUG: Trying discovered key
> d73731e045a189d941928d25f66aa458 in /root/.ssh/id_rsa
> paramiko.transport: DEBUG: userauth is OK
> paramiko.transport: INFO: Authentication (publickey) failed.
> paramiko.transport: DEBUG: userauth is OK
> paramiko.transport: INFO: Authentication (password) successful!
> sshClient: DEBUG: SSH connect: nsroot@10.223.240.174 with passwd nsroot
> testclient.testcase.TestLbAlgoRrLc: DEBUG: command: show lb vserver
> Cloud-VirtualServer-10.223.243.39-22
> paramiko.transport: DEBUG: [chan 1] Max packet in: 34816 bytes
> paramiko.transport: DEBUG: [chan 1] Max packet out: 32768 bytes
> paramiko.transport: INFO: Secsh channel 1 opened.
> paramiko.transport: DEBUG: [chan 1] Sesch channel 1 request ok
> paramiko.transport: DEBUG: [chan 1] EOF received (1)
> paramiko.transport: DEBUG: [chan 1] EOF sent (1)
> sshClient: DEBUG: {Cmd: show lb vserver Cloud-VirtualServer-10.223.243.39-22
> via Host: 10.223.240.174} {returns: [' Done', 'ERROR: No such resource [name,
> Cloud-VirtualServer-10.223.243.39-22]']}
> testclient.testcase.TestLbAlgoRrLc: DEBUG: Output: [' Done', 'ERROR: No such
> resource [name, Cloud-VirtualServer-10.223.243.39-22]']
> - >> end captured logging << -
> Stacktrace
> File "/usr/loc
[jira] [Updated] (CLOUDSTACK-2935) Improve Marvin support for cleanup
[ https://issues.apache.org/jira/browse/CLOUDSTACK-2935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Girish Shilamkar updated CLOUDSTACK-2935: - Assignee: Santhosh Kumar Edukulla (was: Prasanna Santhanam) > Improve Marvin support for cleanup > -- > > Key: CLOUDSTACK-2935 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-2935 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation >Affects Versions: 4.2.0 > Environment: Automation >Reporter: Rayees Namathponnan >Assignee: Santhosh Kumar Edukulla >Priority: Critical > Fix For: Future > > > When setUpClass/setUp fails in unittest, we cannot perform the > tearDownClass/tearDown allowing for cleanup to happen successfully. If VM > deployments start failing we end up exhausting resources in the cloud. This > needs to be handled better in the framework for want of a better solution > from Python's unittest. > http://bugs.python.org/issue5538 -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Resolved] (CLOUDSTACK-4333) [Automation][Volume] test_recurring_snapshots test cases failed during API call "List snapshots"
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Girish Shilamkar resolved CLOUDSTACK-4333.
--
Resolution: Fixed
Not seen in daily runs.
> [Automation][Volume] test_recurring_snapshots test cases failed during API
> call "List snapshots"
>
>
> Key: CLOUDSTACK-4333
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4333
> Project: CloudStack
> Issue Type: Test
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Automation, Test
>Affects Versions: 4.2.0
> Environment: Automation
>Reporter: Rayees Namathponnan
>Priority: Critical
> Fix For: 4.3.0
>
>
> Below test cases failed in vmware run
> integration.component.test_recurring_snapshots.TestRecurringSnapshots.test_recurring_snapshot_data_disk
> integration.component.test_recurring_snapshots.TestRecurringSnapshots.test_recurring_snapshot_root_disk
> Observed below error
> Error Message
> List snapshots API call failed.
> Stacktrace
> Traceback (most recent call last):
> File "/usr/local/lib/python2.7/unittest/case.py", line 318, in run
> testMethod()
> File
> "/data/Repo2/qa/cloudstack/test/integration/component/test_recurring_snapshots.py",
> line 293, in test_recurring_snapshot_root_disk
> raise Exception("List snapshots API call failed.")
> Exception: List snapshots API call failed.
--
This message was sent by Atlassian JIRA
(v6.1.4#6159)
[jira] [Resolved] (CLOUDSTACK-4537) [Automation] Test case test_vpc_vm_life_cycle.py: TestVMLifeCycleSharedNwVPC failed with Insufficient address capacity error
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Girish Shilamkar resolved CLOUDSTACK-4537. -- Resolution: Fixed Fix Version/s: 4.4.0 4.2.1 Code merged. > [Automation] Test case test_vpc_vm_life_cycle.py: TestVMLifeCycleSharedNwVPC > failed with Insufficient address capacity error > -- > > Key: CLOUDSTACK-4537 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4537 > Project: CloudStack > Issue Type: Test > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation >Affects Versions: 4.2.0 > Environment: Automaiton >Reporter: Rayees Namathponnan >Assignee: Girish Shilamkar >Priority: Critical > Fix For: 4.2.1, 4.3.0, 4.4.0 > > > Test case test_vpc_vm_life_cycle.py:failed in latest runs, failed with > insuffcient address capacity, before running this test, i checked the env; > there are enough free IP, but still it failed > Observed below error in test log > Error Message > Execute cmd: deployvirtualmachine failed, due to: errorCode: 533, > errorText:Insufficient address capacity > Stacktrace > Traceback (most recent call last): > File "/usr/local/lib/python2.7/site-packages/nose/suite.py", line 208, in > run > self.setUp() > File "/usr/local/lib/python2.7/site-packages/nose/suite.py", line 291, in > setUp > self.setupContext(ancestor) > File "/usr/local/lib/python2.7/site-packages/nose/suite.py", line 314, in > setupContext > try_run(context, names) > File "/usr/local/lib/python2.7/site-packages/nose/util.py", line 469, in > try_run > return func() > File > "/Repo_30X/ipcl/cloudstack/test/integration/component/test_vpc_vm_life_cycle.py", > line 1005, in setUpClass > str(cls.network_2.id)] > File > "/usr/local/lib/python2.7/site-packages/marvin/integration/lib/base.py", line > 407, in create > virtual_machine = apiclient.deployVirtualMachine(cmd, method=method) > File > "/usr/local/lib/python2.7/site-packages/marvin/cloudstackAPI/cloudstackAPIClient.py", > line 618, in deployVirtualMachine > response = self.connection.marvin_request(command, > response_type=response, method=method) > File > "/usr/local/lib/python2.7/site-packages/marvin/cloudstackConnection.py", line > 222, in marvin_request > response = jsonHelper.getResultObj(response.json(), response_type) > File "/usr/local/lib/python2.7/site-packages/marvin/jsonHelper.py", line > 148, in getResultObj > raise cloudstackException.cloudstackAPIException(respname, errMsg) > cloudstackAPIException: Execute cmd: deployvirtualmachine failed, due to: > errorCode: 533, errorText:Insufficient address capacity > Below error from MS log > 2013-08-28 07:51:27,808 WARN [cloud.network.NetworkManagerImpl] > (catalina-exec-5:null) Unable to get ip adress in zone id=1, vlanId > id=[Ljava.lang.Object;@5b50eae5, network > id=500 > 2013-08-28 07:51:27,819 DEBUG [db.Transaction.Transaction] > (catalina-exec-5:null) Rolling back the transaction: Time = 65 Name = > createVirtualMachine; called by -Transaction. > rollback:898-Transaction.removeUpTo:841-Transaction.close:665-TransactionContextBuilder.interceptException:63-ComponentInstantiationPostProcessor$InterceptorDispatcher.interce > pt:133-NetworkManagerImpl.assignPublicIpAddress:376-NetworkManagerImpl.allocateDirectIp:4482-ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept:125-DirectNetw > orkGuru.allocateDirectIp:233-ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept:125-DirectNetworkGuru.allocate:204-NetworkManagerImpl.allocateNic:1746 > 2013-08-28 07:51:27,876 INFO [user.vm.DeployVMCmd] (catalina-exec-5:null) > com.cloud.exception.InsufficientAddressCapacityException: Insufficient > address capacityScope=interface com.cloud.dc.DataCenter; id=1 > 2013-08-28 07:51:27,877 TRACE [user.vm.DeployVMCmd] (catalina-exec-5:null) > Insufficient address capacity > com.cloud.exception.InsufficientAddressCapacityException: Insufficient > address capacityScope=interface com.cloud.dc.DataCenter; id=1 > at > com.cloud.network.NetworkManagerImpl.fetchNewPublicIp(NetworkManagerImpl.java:479) > at > com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(ComponentInstantiationPostProcessor.java:125) > at > com.cloud.network.NetworkManagerImpl.assignPublicIpAddress(NetworkManagerImpl.java:376) > at > com.cloud.network.NetworkManagerImpl.allocateDirectIp(NetworkManagerImpl.java:4482) > at > com.cloud.utils.component.ComponentInstantiationPostProcessor$InterceptorDispatcher.intercept(Compone
[jira] [Resolved] (CLOUDSTACK-4648) [Automation] Test cases TestCreateVMSnapshotTemplate.test_01_createVM_snapshotTemplate failed with assert error
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4648?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Girish Shilamkar resolved CLOUDSTACK-4648.
--
Resolution: Fixed
Fix Version/s: 4.4.0
4.2.1
> [Automation] Test cases
> TestCreateVMSnapshotTemplate.test_01_createVM_snapshotTemplate failed with
> assert error
>
>
> Key: CLOUDSTACK-4648
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4648
> Project: CloudStack
> Issue Type: Test
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Automation, Test
>Affects Versions: 4.2.1
> Environment: KVM
> 4.2-forward
>Reporter: Rayees Namathponnan
>Assignee: Gaurav Aradhye
>Priority: Critical
> Fix For: 4.2.1, 4.3.0, 4.4.0
>
>
> Test case
> integration.component.test_snapshots.TestCreateVMSnapshotTemplate.test_01_createVM_snapshotTemplate
> failed with asset errorr
> Error Message
> False is not True
> >> begin captured logging <<
> test_01_createVM_snapshotTemplate
> (integration.component.test_snapshots.TestCreateVMSnapshotTemplate): DEBUG:
> Created VM with ID: c7bc243f-54ed-49e1-abfb-41e59ab4e559
> test_01_createVM_snapshotTemplate
> (integration.component.test_snapshots.TestCreateVMSnapshotTemplate): DEBUG:
> Snapshot created: ID - 7c76e8d0-0351-4be0-95f3-04f0b6075551
> test_01_createVM_snapshotTemplate
> (integration.component.test_snapshots.TestCreateVMSnapshotTemplate): DEBUG:
> select backup_snap_id, account_id, volume_id from snapshots where uuid =
> '7c76e8d0-0351-4be0-95f3-04f0b6075551';
> test_01_createVM_snapshotTemplate
> (integration.component.test_snapshots.TestCreateVMSnapshotTemplate): DEBUG:
> Created template from snapshot: 26c7a850-7295-4cd2-bf5e-87214f9ae666
> test_01_createVM_snapshotTemplate
> (integration.component.test_snapshots.TestCreateVMSnapshotTemplate): DEBUG:
> Created VM with ID: ddb07a66-e123-4577-8b7e-16be730829ed from template:
> 26c7a850-7295-4cd2-bf5e-87214f9ae666
> paramiko.transport: DEBUG: starting thread (client mode): 0x4654c10L
> paramiko.transport: INFO: Connected (version 2.0, client OpenSSH_5.3)
> paramiko.transport: DEBUG: kex algos:['diffie-hellman-group-exchange-sha256',
> 'diffie-hellman-group-exchange-sha1', 'diffie-hellman-group14-sha1',
> 'diffie-hellman-group1-sha1'] server key:['ssh-rsa', 'ssh-dss'] client
> encrypt:['aes128-ctr', 'aes192-ctr', 'aes256-ctr', 'arcfour256',
> 'arcfour128', 'aes128-cbc', '3des-cbc', 'blowfish-cbc', 'cast128-cbc',
> 'aes192-cbc', 'aes256-cbc', 'arcfour', 'rijndael-...@lysator.liu.se'] server
> encrypt:['aes128-ctr', 'aes192-ctr', 'aes256-ctr', 'arcfour256',
> 'arcfour128', 'aes128-cbc', '3des-cbc', 'blowfish-cbc', 'cast128-cbc',
> 'aes192-cbc', 'aes256-cbc', 'arcfour', 'rijndael-...@lysator.liu.se'] client
> mac:['hmac-md5', 'hmac-sha1', 'umac...@openssh.com', 'hmac-ripemd160',
> 'hmac-ripemd...@openssh.com', 'hmac-sha1-96', 'hmac-md5-96'] server
> mac:['hmac-md5', 'hmac-sha1', 'umac...@openssh.com', 'hmac-ripemd160',
> 'hmac-ripemd...@openssh.com', 'hmac-sha1-96', 'hmac-md5-96'] client
> compress:['none', 'z...@openssh.com'] server compress:['none',
> 'z...@openssh.com'] client lang:[''] server lang:[''] kex follows?False
> paramiko.transport: DEBUG: Ciphers agreed: local=aes128-ctr, remote=aes128-ctr
> paramiko.transport: DEBUG: using kex diffie-hellman-group1-sha1; server key
> type ssh-rsa; cipher: local aes128-ctr, remote aes128-ctr; mac: local
> hmac-sha1, remote hmac-sha1; compression: local none, remote none
> paramiko.transport: DEBUG: Switch to new keys ...
> paramiko.transport: DEBUG: Adding ssh-rsa host key for 10.223.49.195:
> 46bde2f19851ddbdf5b062510a1d4200
> paramiko.transport: DEBUG: Trying discovered key
> 76be480fa6b8ad3b78082d6d19e4ee44 in /root/.ssh/id_rsa
> paramiko.transport: DEBUG: userauth is OK
> paramiko.transport: INFO: Authentication (publickey) successful!
> sshClient: DEBUG: SSH connect: root@10.223.49.195 with passwd password
> paramiko.transport: DEBUG: [chan 1] Max packet in: 34816 bytes
> paramiko.transport: DEBUG: [chan 1] Max packet out: 32768 bytes
> paramiko.transport: INFO: Secsh channel 1 opened.
> paramiko.transport: DEBUG: [chan 1] Sesch channel 1 request ok
> paramiko.transport: DEBUG: [chan 1] EOF received (1)
> sshClient: DEBUG: {Cmd: mkdir -p %s /mnt/tmp via Host: 10.223.49.195}
> {returns: []}
> paramiko.transport: DEBUG: [chan 2] Max packet in: 34816 bytes
> paramiko.transport: DEBUG: [chan 1] EOF sent (1)
> paramiko.transport: DEBUG: [chan 2] Max packet out: 32768 bytes
> paramiko.transport: INFO: Secsh channel 2 opened.
> paramiko.transport: DEBUG: [chan 2] Sesch channel
[jira] [Resolved] (CLOUDSTACK-4633) [Automation] test_project_limits.py test cases failed with No module named integration
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4633?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Girish Shilamkar resolved CLOUDSTACK-4633. -- Resolution: Cannot Reproduce Not seen in daily run. > [Automation] test_project_limits.py test cases failed with No module named > integration > -- > > Key: CLOUDSTACK-4633 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4633 > Project: CloudStack > Issue Type: Test > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation, Test >Affects Versions: 4.2.1 > Environment: Automation >Reporter: Rayees Namathponnan >Assignee: Gaurav Aradhye >Priority: Critical > Fix For: 4.3.0 > > > test_project_limits.py Failed with below error > No module named integration > Stacktrace > Traceback (most recent call last): > File "/usr/local/lib/python2.7/unittest/case.py", line 318, in run > testMethod() > File "/usr/local/lib/python2.7/site-packages/nose/loader.py", line 413, in > loadTestsFromName > addr.filename, addr.module) > File "/usr/local/lib/python2.7/site-packages/nose/importer.py", line 47, in > importFromPath > return self.importFromDir(dir_path, fqname) > File "/usr/local/lib/python2.7/site-packages/nose/importer.py", line 79, in > importFromDir > fh, filename, desc = find_module(part, path) > ImportError: No module named integration -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Resolved] (CLOUDSTACK-5102) integration.component.test_volumes.TestVolumes.test_create_volume_under_domain test failed with syntax error
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Girish Shilamkar resolved CLOUDSTACK-5102. -- Resolution: Fixed Fix Version/s: 4.4.0 4.2.1 Fixed as part of marvin changes. > integration.component.test_volumes.TestVolumes.test_create_volume_under_domain > test failed with syntax error > - > > Key: CLOUDSTACK-5102 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5102 > Project: CloudStack > Issue Type: Test > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation >Affects Versions: 4.3.0 >Reporter: Srikanteswararao Talluri >Priority: Critical > Fix For: 4.2.1, 4.3.0, 4.4.0 > > > Error Message > __init__() takes at most 6 arguments (9 given) > Stacktrace > Traceback (most recent call last): > File "/usr/local/lib/python2.7/unittest/case.py", line 327, in run > testMethod() > File "/root/asf/cloudstack/test/integration/component/test_volumes.py", > line 1108, in test_create_volume_under_domain > domapiclient = self.testClient.getUserApiClient(account=domuser.name, > domain=dom.name) > File > "/usr/local/lib/python2.7/site-packages/marvin/cloudstackTestClient.py", line > 185, in getUserApiClient > self.createUserApiClient(account, domain, type) > File > "/usr/local/lib/python2.7/site-packages/marvin/cloudstackTestClient.py", line > 158, in createUserApiClient > self.connection.logging) > TypeError: __init__() takes at most 6 arguments (9 given) -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Resolved] (CLOUDSTACK-4487) [Automation] Netscaler test cases failed due missing attribute 'network_offering'
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Girish Shilamkar resolved CLOUDSTACK-4487.
--
Resolution: Fixed
Fix Version/s: 4.4.0
4.2.1
> [Automation] Netscaler test cases failed due missing attribute
> 'network_offering'
> -
>
> Key: CLOUDSTACK-4487
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4487
> Project: CloudStack
> Issue Type: Test
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Automation, Test
>Affects Versions: 4.2.0
> Environment: Automaion
>Reporter: Rayees Namathponnan
>Assignee: Sowmya Krishnan
>Priority: Critical
> Fix For: 4.2.1, 4.3.0, 4.4.0
>
>
> Netscaler test cases failed with below error
> :setup (from nosetests)
> Failing for the past 2 builds (Since Unstable#17 )
> Took 0 ms.
> Error Message
> Warning: Exception during cleanup : type object 'TestLbAlgoLcRr' has no
> attribute 'network_offering'
> Stacktrace
> Traceback (most recent call last):
> File "/usr/local/lib/python2.7/site-packages/nose/suite.py", line 208, in
> run
> self.setUp()
> File "/usr/local/lib/python2.7/site-packages/nose/suite.py", line 291, in
> setUp
> self.setupContext(ancestor)
> File "/usr/local/lib/python2.7/site-packages/nose/suite.py", line 314, in
> setupContext
> try_run(context, names)
> File "/usr/local/lib/python2.7/site-packages/nose/util.py", line 469, in
> try_run
> return func()
> File
> "/data/Repo2/qa/cloudstack/test/integration/component/test_netscaler_lb_algo.py",
> line 1052, in setUpClass
> cls.tearDownClass()
> File
> "/data/Repo2/qa/cloudstack/test/integration/component/test_netscaler_lb_algo.py",
> line 1073, in tearDownClass
> raise Exception("Warning: Exception during cleanup : %s" % e)
> Exception: Warning: Exception during cleanup : type object 'TestLbAlgoLcRr'
> has no attribute 'network_offering'
--
This message was sent by Atlassian JIRA
(v6.1.4#6159)
[jira] [Resolved] (CLOUDSTACK-4336) [Automation] Test case TestUploadAttachVolume.test_upload_attach_volume failed raise exception
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Girish Shilamkar resolved CLOUDSTACK-4336.
--
Resolution: Cannot Reproduce
Not seen in daily runs.
> [Automation] Test case TestUploadAttachVolume.test_upload_attach_volume
> failed raise exception
> --
>
> Key: CLOUDSTACK-4336
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4336
> Project: CloudStack
> Issue Type: Test
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Automation
>Affects Versions: 4.2.0
> Environment: Automation
>Reporter: Rayees Namathponnan
>Priority: Critical
> Fix For: 4.3.0
>
>
> Test case
> integration.component.test_stopped_vm.TestUploadAttachVolume.test_upload_attach_volume
> failed with latest run
> Error Message
> Exception not raised
> >> begin captured logging <<
> testclient.testcase.TestUploadAttachVolume: DEBUG: Uploading the volume:
> DataDisk
> testclient.testcase.TestUploadAttachVolume: DEBUG: Uploading the volume:
> DataDisk
> testclient.testcase.TestUploadAttachVolume: DEBUG: Volume: %s uploaded
> successfully
> testclient.testcase.TestUploadAttachVolume: DEBUG: Deploying VM instance in
> account: test-T3F1UI
> testclient.testcase.TestUploadAttachVolume: DEBUG: Failed to attach the
> volume as expected
> - >> end captured logging << -
> Stacktrace
> File "/usr/local/lib/python2.7/unittest/case.py", line 318, in run
> testMethod()
> File
> "/Repo_30X/ipcl/cloudstack/test/integration/component/test_stopped_vm.py",
> line 1702, in test_upload_attach_volume
> self.debug("Failed to attach the volume as expected")
> File "/usr/local/lib/python2.7/unittest/case.py", line 112, in __exit__
> "{0} not raised".format(exc_name))
> Exception not raised
> >> begin captured logging <<
> testclient.testcase.TestUploadAttachVolume: DEBUG: Uploading the volume:
> DataDisk
> testclient.testcase.TestUploadAttachVolume: DEBUG: Uploading the volume:
> DataDisk
> testclient.testcase.TestUploadAttachVolume: DEBUG: Volume: %s uploaded
> successfully
> testclient.testcase.TestUploadAttachVolume: DEBUG: Deploying VM instance in
> account: test-T3F1UI
> testclient.testcase.TestUploadAttachVolume: DEBUG: Failed to attach the
> volume as expected
> - >> end captured logging << -
--
This message was sent by Atlassian JIRA
(v6.1.4#6159)
[jira] [Commented] (CLOUDSTACK-4904) Unable to see a derieved template if the parent template is deleted
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13849425#comment-13849425 ] Harikrishna Patnala commented on CLOUDSTACK-4904: - On master and 4.3 when template/iso is removed then the entry in vm_template table "State" column is marked as "inactive". template_view contains only templates/ISOs where state = "active" Due to this we could not list the removed templates from template_view. > Unable to see a derieved template if the parent template is deleted > --- > > Key: CLOUDSTACK-4904 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4904 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Template >Affects Versions: 4.2.0 >Reporter: Harikrishna Patnala >Assignee: Harikrishna Patnala >Priority: Critical > Fix For: 4.3.0 > > > Functionality required/broken - For a template, if the parent template info > (template Id) is provided in the listTemplates API then one should be able to > query for the parent template id as well (whether existing/removed doesn't > matter) -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Created] (CLOUDSTACK-5520) Script errors seen when trying to seed the 64 bit Xenserver templates.
Sangeetha Hariharan created CLOUDSTACK-5520: --- Summary: Script errors seen when trying to seed the 64 bit Xenserver templates. Key: CLOUDSTACK-5520 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5520 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.3.0 Environment: Build from 4.3 Reporter: Sangeetha Hariharan Priority: Critical Fix For: 4.3.0 Following error seen when trying to seed the latest 64 bit template for Xenserver but the script reports success. Uncompressing to /usr/share/cloudstack-common/scripts/storage/secondary/a10e2bc7-b50e-46cc-8f84-ad8cbb42ab50.vhd.tmp (type bz2)...could take a long time /usr/share/cloudstack-common/scripts/storage/secondary/createtmplt.sh: line 207: [: isCifs: integer expression expected Moving to /mnt/secondary/template/tmpl/1/1///a10e2bc7-b50e-46cc-8f84-ad8cbb42ab50.vhd...could take a while mv: failed to preserve ownership for `//mnt/secondary/template/tmpl/1/1///a10e2bc7-b50e-46cc-8f84-ad8cbb42ab50.vhd': Invalid argument Successfully installed system VM template to /mnt/secondary/template/tmpl/1/1/ -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Updated] (CLOUDSTACK-5520) Script errors seen when trying to seed the 64 bit Xenserver templates.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5520?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sangeetha Hariharan updated CLOUDSTACK-5520: Description: Following error seen when trying to seed the latest 64 bit template for Xenserver but the script reports success. [root@rhel64-1 secondary]# /usr/share/cloudstack-common/scripts/storage/secondary/cloud-install-sys-tmplt -m /mnt/secondary -u http://nfs1.lab.vmops.com/templates/felton_qa/64/systemvm64template-2013-12-16-master-xen.vhd.bz2 -h xenserver -F --2013-12-16 14:30:33-- http://nfs1.lab.vmops.com/templates/felton_qa/64/systemvm64template-2013-12-16-master-xen.vhd.bz2 Resolving nfs1.lab.vmops.com... 10.223.110.231 Connecting to nfs1.lab.vmops.com|10.223.110.231|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 229311649 (219M) [application/x-bzip2] Saving to: â/usr/share/cloudstack-common/scripts/storage/secondary/91b86630-cee7-4aa9-9e60-824bdb06a7e9.vhdâ 100%[==>] 229,311,649 112M/s in 2.0s 2013-12-16 14:30:35 (112 MB/s) - â/usr/share/cloudstack-common/scripts/storage/secondary/91b86630-cee7-4aa9-9e60-824bdb06a7e9.vhdâ Uncompressing to /usr/share/cloudstack-common/scripts/storage/secondary/91b86630-cee7-4aa9-9e60-824bdb06a7e9.vhd.tmp (type bz2)...could take a long time /usr/share/cloudstack-common/scripts/storage/secondary/createtmplt.sh: line 207: [: isCifs: integer expression expected Moving to /mnt/secondary/template/tmpl/1/1///91b86630-cee7-4aa9-9e60-824bdb06a7e9.vhd...could take a while mv: failed to preserve ownership for `//mnt/secondary/template/tmpl/1/1///91b86630-cee7-4aa9-9e60-824bdb06a7e9.vhd': Invalid argument Successfully installed system VM template to /mnt/secondary/template/tmpl/1/1/ [root@rhel64-1 secondary]# was: Following error seen when trying to seed the latest 64 bit template for Xenserver but the script reports success. Uncompressing to /usr/share/cloudstack-common/scripts/storage/secondary/a10e2bc7-b50e-46cc-8f84-ad8cbb42ab50.vhd.tmp (type bz2)...could take a long time /usr/share/cloudstack-common/scripts/storage/secondary/createtmplt.sh: line 207: [: isCifs: integer expression expected Moving to /mnt/secondary/template/tmpl/1/1///a10e2bc7-b50e-46cc-8f84-ad8cbb42ab50.vhd...could take a while mv: failed to preserve ownership for `//mnt/secondary/template/tmpl/1/1///a10e2bc7-b50e-46cc-8f84-ad8cbb42ab50.vhd': Invalid argument Successfully installed system VM template to /mnt/secondary/template/tmpl/1/1/ > Script errors seen when trying to seed the 64 bit Xenserver templates. > -- > > Key: CLOUDSTACK-5520 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5520 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.3.0 > Environment: Build from 4.3 >Reporter: Sangeetha Hariharan >Priority: Critical > Fix For: 4.3.0 > > > Following error seen when trying to seed the latest 64 bit template for > Xenserver but the script reports success. > [root@rhel64-1 secondary]# > /usr/share/cloudstack-common/scripts/storage/secondary/cloud-install-sys-tmplt > -m /mnt/secondary -u > http://nfs1.lab.vmops.com/templates/felton_qa/64/systemvm64template-2013-12-16-master-xen.vhd.bz2 > -h xenserver -F > --2013-12-16 14:30:33-- > http://nfs1.lab.vmops.com/templates/felton_qa/64/systemvm64template-2013-12-16-master-xen.vhd.bz2 > Resolving nfs1.lab.vmops.com... 10.223.110.231 > Connecting to nfs1.lab.vmops.com|10.223.110.231|:80... connected. > HTTP request sent, awaiting response... 200 OK > Length: 229311649 (219M) [application/x-bzip2] > Saving to: > â/usr/share/cloudstack-common/scripts/storage/secondary/91b86630-cee7-4aa9-9e60-824bdb06a7e9.vhdâ > 100%[==>] > 229,311,649 112M/s in 2.0s > 2013-12-16 14:30:35 (112 MB/s) - > â/usr/share/cloudstack-common/scripts/storage/secondary/91b86630-cee7-4aa9-9e60-824bdb06a7e9.vhdâ > Uncompressing to > /usr/share/cloudstack-common/scripts/storage/secondary/91b86630-cee7-4aa9-9e60-824bdb06a7e9.vhd.tmp > (type bz2)...could take a long time > /usr/share/cloudstack-common/scripts/storage/secondary/createtmplt.sh: line > 207: [: isCifs: integer expression expected > Moving to > /mnt/secondary/template/tmpl/1/1///91b86630-cee7-4aa9-9e60-824bdb06a7e9.vhd...could > take a while > mv: failed to preserve ownership for > `//mnt/secondary/template/tmpl/1/1///91b86630-cee7-4aa9-9e60-824bdb06a7e9.vhd': > Invalid argument > Successfully installed system VM template to > /mnt/secondary/template/tmpl/1/1/ > [root@rhel64-1
[jira] [Commented] (CLOUDSTACK-4622) [IP Reservation][If a VM from guest network is added to network tier of VPC then IP reservation allows the CIDR to be a superset of Network CIDR for that VPC tier
[
https://issues.apache.org/jira/browse/CLOUDSTACK-4622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13849637#comment-13849637
]
Alena Prokharchyk commented on CLOUDSTACK-4622:
---
Saksham,
I reproduced the scenario, and the scenario you've tested, is not quite valid.
When you add a nic from another network to the VPC vm, and do ip reservation in
that network, it shoudln't obey the VPC CIDR limitation. VPC cidr limitation
affects only networks that are being the part of this VPC. I've tested CIDR
modification for VPC network, it doesn't let updates outside of the VPC cidr.
Here is the error being thrown: "Invalid value of Guest VM CIDR. For IP
Reservation, Guest VM CIDR should be a subset of network CIDR : 10.1.1.0/24"
But there is a completely different critical bug in addNetwork functionality -
it doesn't respect VPC limitation: VM can belong to only one VPC + 0-(n) number
of Shared networks.
To fix:
* Don't let attach Isolated networks to VM belonging to VPC.
* Don't let attach VPC network(s) to the vm belonging to Isolated network
Both UI and Java code should be fixed. UI should only display networks that can
be potentially attached to the VM. Java code in addNetwork method should obey
all the limitations, and throw an exception if violated.
Saksham, please go ahead and create a new patch. You can either attach it to
this bug, or file a new one for that matter.
> [IP Reservation][If a VM from guest network is added to network tier of VPC
> then IP reservation allows the CIDR to be a superset of Network CIDR for
> that VPC tier
> ---
>
> Key: CLOUDSTACK-4622
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4622
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Network Controller
>Affects Versions: 4.2.0
>Reporter: Abhinav Roy
>Assignee: Saksham Srivastava
>Priority: Critical
> Fix For: 4.3.0
>
> Attachments: CS-4622.zip
>
>
> Steps :
> ===
> 1. Deploy a CS 4.2 advanced networking setup
> 2. Create a Guest network , gn1 and deploy a VM, vm1 on that network.
> 3. Create a VPC Tier, tier1 with CIDR as 10.1.2.1/24 and deploy a vm , v1t1
> on that tier.
> 4. Go to Instances -> vm1 -> nics -> Add Network to VMand add tier1
> network to vm1.
> 5. Now, go to tier1 and do IP reservation with CIDR as 10.1.2.1/23
> Expected behaviour :
> =
> The IP reservation should fail as the CIDR 10.1.2.1/23 is not a subset of the
> network CIDR which is 10.1.2.1/24
> Observed behaviour :
>
> The IP reservation goes through , here is a snippet from management server
> logs
> 2013-09-06 12:13:27,760 DEBUG [cloud.async.AsyncJobManagerImpl]
> (catalina-exec-13:null) submit async job-39 = [
> 4562cb4d-54d5-4b7e-90bd-e3d2c679ab5e ], details: AsyncJobVO {id:39, userId:
> 2, accountId: 2, sessionKey: null, instanceType: None, instanceId: null, cmd:
> org.apache.cloudstack.api.command.user.network.UpdateNetworkCmd,
> cmdOriginator: null, cmdInfo:
> {"id":"674355e5-8c3b-44a2-b47d-d198548ccea7","response":"json","sessionkey":"moOLxaFrqNc50wz6SDh6v413RnA\u003d","cmdEventType":"NETWORK.UPDATE","ctxUserId":"2","name":"TIER-1","guestvmcidr":"10.1.2.0/23","displaytext":"TIER-1","httpmethod":"GET","_":"1378450020843","ctxAccountId":"2","ctxStartEventId":"134"},
> cmdVersion: 0, callbackType: 0, callbackAddress: null, status: 0,
> processStatus: 0, resultCode: 0, result: null, initMsid: 280320865129348,
> completeMsid: null, lastUpdated: null, lastPolled: null, created: null}
> 2013-09-06 12:13:27,761 DEBUG [cloud.api.ApiServlet] (catalina-exec-13:null)
> ===END=== 10.144.7.25 -- GET
> command=updateNetwork&response=json&sessionkey=moOLxaFrqNc50wz6SDh6v413RnA%3D&id=674355e5-8c3b-44a2-b47d-d198548ccea7&name=TIER-1&displaytext=TIER-1&guestvmcidr=10.1.2.0%2F23&_=1378450020843
> 2013-09-06 12:13:27,763 DEBUG [cloud.async.AsyncJobManagerImpl]
> (Job-Executor-53:job-39 = [ 4562cb4d-54d5-4b7e-90bd-e3d2c679ab5e ]) Executing
> org.apache.cloudstack.api.command.user.network.UpdateNetworkCmd for job-39 =
> [ 4562cb4d-54d5-4b7e-90bd-e3d2c679ab5e ]
> 2013-09-06 12:13:27,771 DEBUG [cloud.async.AsyncJobManagerImpl]
> (Job-Executor-53:job-39 = [ 4562cb4d-54d5-4b7e-90bd-e3d2c679ab5e ]) Sync
> job-39 = [ 4562cb4d-54d5-4b7e-90bd-e3d2c679ab5e ] execution on object
> network.205
> 2013-09-06 12:13:27,778 DEBUG [cloud.async.AsyncJobManagerImpl]
> (Job-Executor-53:job-39 = [ 4562cb4d-54d5-4b7e-90bd-e3d2c679ab5e ]) job
> org.apache.cloudstack.api.command.user.network.UpdateNetworkCmd for job-39 =
> [
[jira] [Created] (CLOUDSTACK-5521) KVM needs a cpu topology
Marcus Sorensen created CLOUDSTACK-5521: --- Summary: KVM needs a cpu topology Key: CLOUDSTACK-5521 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5521 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: KVM Reporter: Marcus Sorensen Assignee: Marcus Sorensen When creating VMs, KVM creates each CPU as its own socket. This is problematic for a few reasons, but most notably for guest OSes that are licensed per socket. Need to update KVM cpu topology to look more like a real server with # of cores per socket. -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Assigned] (CLOUDSTACK-5486) [UI] List Template for non root admin account does not display tags for pubic templates
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jessica Wang reassigned CLOUDSTACK-5486:
Assignee: Jessica Wang
> [UI] List Template for non root admin account does not display tags for pubic
> templates
> ---
>
> Key: CLOUDSTACK-5486
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5486
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: UI
>Affects Versions: 4.2.0, 4.2.1
>Reporter: Saksham Srivastava
>Assignee: Jessica Wang
>
> Steps to reproduce:
> 1. As a root admin register a public template
> 2. Add tags to the template
> 3. Log in as non root admin user
> 4. Template list will not have tags listeed those were created in step 2
> List template response does contain tags :
> { "listtemplatesresponse" : { "count":1 ,"template" : [
> {"id":"ba29b217-0284-4149-9348-54713ff2f20d","name":"template","displaytext":"template","ispublic":true,"created":"2013-12-12T19:01:17+0530","isready":true,"passwordenabled":false,"format":"VHD","isfeatured":false,"crossZones":true,"ostypeid":"faac95de-62f6-11e3-8a00-1a9dc5aab6d3","ostypename":"Other
>
> (64-bit)","account":"admin","zoneid":"64d7a63c-05a5-4539-9560-e53eaff2b205","zonename":"zonez","size":52428800,"templatetype":"USER","hypervisor":"XenServer","domain":"ROOT","domainid":"fb94c872-62f6-11e3-8a00-1a9dc5aab6d3","isextractable":false,"checksum":"046e134e642e6d344b34648223ba4bc1","details":{"hypervisortoolsversion":"xenserver61"},
> "tags":[{"key":"mytag","value":"tag-value","resourcetype":"Template","resourceid":"ba29b217-0284-4149-9348-54713ff2f20d","account":"admin","domainid":"fb94c872-62f6-11e3-8a00-1a9dc5aab6d3","domain":"ROOT"}],"sshkeyenabled":false,"isdynamicallyscalable":false}
> ] } }
--
This message was sent by Atlassian JIRA
(v6.1.4#6159)
[jira] [Updated] (CLOUDSTACK-5515) #cpu ,cpuspeed and ram is set to NULL in usage db(vm_instance table) after vm stop and start
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Animesh Chaturvedi updated CLOUDSTACK-5515: --- Assignee: Bharat Kumar > #cpu ,cpuspeed and ram is set to NULL in usage db(vm_instance table) after vm > stop and start > > > Key: CLOUDSTACK-5515 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5515 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Usage >Affects Versions: 4.3.0 >Reporter: prashant kumar mishra >Assignee: Bharat Kumar >Priority: Critical > Fix For: 4.3.0 > > Attachments: Logs_Db.rar > > > Steps to reproduce > - > 1-prapare a CS setup + install usage server > 2-create a dynamic compute offering say d1 > 3-deploy a vm using d1 > 4-stop and start vm > Actual > > #cpu , cpuspeed, memory is set to null after stop start > Expected > - > after vm stop-start #cpu , cpuspeed and memory should get updated according > to CO -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Assigned] (CLOUDSTACK-5276) ListView for selecting VM under LB,portforwarding and static nat configuration pages is not valid.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jessica Wang reassigned CLOUDSTACK-5276: Assignee: Brian Federle (was: Jessica Wang) > ListView for selecting VM under LB,portforwarding and static nat > configuration pages is not valid. > > > Key: CLOUDSTACK-5276 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5276 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.3.0 >Reporter: manasaveloori >Assignee: Brian Federle >Priority: Critical > Fix For: 4.3.0 > > Attachments: listview.jpg > > > While configuring the portforwarding,LB and static NAT,we need to select the > VMs. > As per the new UI we are getting two options to select the VMS(listview on > left side and individual select option on right side). > While selecting the VMs using the listview widget, the rules are not getting > applied in VR but just seen in UI.The correct functionality is with right > hand side select buttons. I think the listview is not valid under these > configuration pages. -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Commented] (CLOUDSTACK-5276) ListView for selecting VM under LB,portforwarding and static nat configuration pages is not valid.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13849778#comment-13849778 ] ASF subversion and git services commented on CLOUDSTACK-5276: - Commit a6792c57bdfeeefa08a7473d4ee2b21b46ba8018 in branch refs/heads/4.3 from [~bfederle] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=a6792c5 ] CLOUDSTACK-5276: Remove wrong select column from LB/PF list select > ListView for selecting VM under LB,portforwarding and static nat > configuration pages is not valid. > > > Key: CLOUDSTACK-5276 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5276 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.3.0 >Reporter: manasaveloori >Assignee: Brian Federle >Priority: Critical > Fix For: 4.3.0 > > Attachments: listview.jpg > > > While configuring the portforwarding,LB and static NAT,we need to select the > VMs. > As per the new UI we are getting two options to select the VMS(listview on > left side and individual select option on right side). > While selecting the VMs using the listview widget, the rules are not getting > applied in VR but just seen in UI.The correct functionality is with right > hand side select buttons. I think the listview is not valid under these > configuration pages. -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Resolved] (CLOUDSTACK-5276) ListView for selecting VM under LB,portforwarding and static nat configuration pages is not valid.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Federle resolved CLOUDSTACK-5276. --- Resolution: Fixed > ListView for selecting VM under LB,portforwarding and static nat > configuration pages is not valid. > > > Key: CLOUDSTACK-5276 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5276 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.3.0 >Reporter: manasaveloori >Assignee: Brian Federle >Priority: Critical > Fix For: 4.3.0 > > Attachments: listview.jpg > > > While configuring the portforwarding,LB and static NAT,we need to select the > VMs. > As per the new UI we are getting two options to select the VMS(listview on > left side and individual select option on right side). > While selecting the VMs using the listview widget, the rules are not getting > applied in VR but just seen in UI.The correct functionality is with right > hand side select buttons. I think the listview is not valid under these > configuration pages. -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Commented] (CLOUDSTACK-5276) ListView for selecting VM under LB,portforwarding and static nat configuration pages is not valid.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13849780#comment-13849780 ] ASF subversion and git services commented on CLOUDSTACK-5276: - Commit 6ad0e4913eedffd87636e94ccf607565d96f31d8 in branch refs/heads/master from [~bfederle] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=6ad0e49 ] CLOUDSTACK-5276: Remove wrong select column from LB/PF list select > ListView for selecting VM under LB,portforwarding and static nat > configuration pages is not valid. > > > Key: CLOUDSTACK-5276 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5276 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.3.0 >Reporter: manasaveloori >Assignee: Brian Federle >Priority: Critical > Fix For: 4.3.0 > > Attachments: listview.jpg > > > While configuring the portforwarding,LB and static NAT,we need to select the > VMs. > As per the new UI we are getting two options to select the VMS(listview on > left side and individual select option on right side). > While selecting the VMs using the listview widget, the rules are not getting > applied in VR but just seen in UI.The correct functionality is with right > hand side select buttons. I think the listview is not valid under these > configuration pages. -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Commented] (CLOUDSTACK-5407) site-to-site VPN VR-to-VR After VPN connection successfully established , site with passive mode remains in "Disconnected" state
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13849825#comment-13849825
]
Sheng Yang commented on CLOUDSTACK-5407:
Where is the log??!!
> site-to-site VPN VR-to-VR After VPN connection successfully established ,
> site with passive mode remains in "Disconnected" state
>
>
> Key: CLOUDSTACK-5407
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5407
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server
>Affects Versions: 4.3.0
> Environment: MSrhel 6.4 12/5/13 latest build 97
> host XS 6.2
>Reporter: angeline shen
>Assignee: Sheng Yang
>Priority: Critical
> Fix For: 4.3.0
>
> Attachments: v16.htm
>
>
> 1. admin creates vpc1, VPN customer gateway tovpc2
>d1user creates vpc2, VPN customer gateway toadmin
> 2. admincreates VPN connection to 'tovpc2'passive mode
> d1user creatses VPN connection to 'toadmin'
> 3. After VPN connection successful, d1user VPN connection shows "connected",
> but admin shows "Disconnected"
> http://10.223.130.107:8080/client/api?command=listVpnConnections&listAll=true&page=1&pagesize=20&response=json&sessionkey=b3xkTyC7CxDFKBCNY%2ByGqaoK4rk%3D&vpcid=b4bd8438-b17a-4bb3-9ff8-6b980e148cd8&_=1386373747078
> { "listvpnconnectionsresponse" : { "count":1 ,"vpnconnection" : [
> {"id":"6a56648a-78b3-4ab7-a709-42d1e291ef23","s2svpngatewayid":"95790330-3201-4f3f-b824-ab3efbef","publicip":"10.223.123.17","s2scustomergatewayid":"af688052-a2fd-44b2-8c07-cb6c938e5483","gateway":"10.223.123.53","cidrlist":"10.2.1.1/16","ipsecpsk":"123123","ikepolicy":"3des-md5","esppolicy":"3des-md5","ikelifetime":86400,"esplifetime":3600,"dpd":false,"state":"Disconnected","passive":true,"account":"admin","domainid":"31a9bc00-5de9-11e3-a6e9-06c6ac000773","domain":"ROOT","created":"2013-12-06T14:31:10-0800"}
> ] } }
--
This message was sent by Atlassian JIRA
(v6.1.4#6159)
[jira] [Commented] (CLOUDSTACK-5334) [Automation] Failed to create template from snapshot while executing copy command, observed NPE In SSVM log
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13849834#comment-13849834
]
Nitin Mehta commented on CLOUDSTACK-5334:
-
This seems to be a KVM specific issue. I tried this operation on XS and it
succeeded. From the code as well it seems like to be a KVM specific check. So
unassigning.
} else if (srcData.getHypervisorType() == HypervisorType.KVM) {
File srcFile = getFile(srcData.getPath(), srcDataStore.getUrl());
File destFile = getFile(destData.getPath(), destDataStore.getUrl());
ImageFormat srcFormat = srcData.getVolume().getFormat();
> [Automation] Failed to create template from snapshot while executing copy
> command, observed NPE In SSVM log
> ---
>
> Key: CLOUDSTACK-5334
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5334
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Template
>Affects Versions: 4.3.0
> Environment: KVM
> Branch 4.3
>Reporter: Rayees Namathponnan
>Assignee: Nitin Mehta
>Priority: Blocker
> Fix For: 4.3.0
>
> Attachments: CLOUDSTACK-5334.rar
>
>
> Steps to reproduce
> Step 1 : snapshot root volume
> Step 2 : Create template from snapshot
> Result
> Failed to create template from snapshot, observed below "copy command failure
> and NPE" in MS log and SSVM log
> MS log
> 2013-12-02 08:28:49,406 DEBUG [o.a.c.s.m.AncientDataMotionStrategy]
> (Job-Executor-140:ctx-62f776d6 ctx-120aa5f1) copyAsync inspecting src type
> SNAPSHOT copy
> Async inspecting dest type TEMPLATE
> 2013-12-02 08:28:49,418 DEBUG [c.c.a.t.Request]
> (Job-Executor-140:ctx-62f776d6 ctx-120aa5f1) Seq 8-1124074796: Sending { Cmd
> , MgmtId: 29066118877352, via:
> 8(s-5-VM), Ver: v1, Flags: 100011,
> [{"org.apache.cloudstack.storage.command.CopyCommand":{"srcTO":{"org.apache.cloudstack.storage.to.SnapshotObjectTO":{"pa
> th":"snapshots/282/589/d2b20627-b60e-489b-9eee-9f4705331a72","dataStore":{"com.cloud.agent.api.to.NfsTO":{"_url":"nfs://10.223.110.232:/export/home/rayees/S
> C_QA_AUTO4/secondary","_role":"Image"}},"name":"VM-f9e129c2-8d62-4b70-8105-abd304bf7605_ROOT-526_20131202080509","hypervisorType":"KVM","id":20,"quiescevm":
> false}},"destTO":{"org.apache.cloudstack.storage.to.TemplateObjectTO":{"path":"template/tmpl/282/236","uuid":"1e48c6bf-388e-4184-93f5-28a21b12329c","id":236
> ,"format":"RAW","accountId":282,"hvm":true,"displayText":"raytemp","imageDataStore":{"com.cloud.agent.api.to.NfsTO":{"_url":"nfs://10.223.110.232:/export/ho
> me/rayees/SC_QA_AUTO4/secondary","_role":"Image"}},"name":"2c497573e-38cc-3f4d-a73a-49c7b63bbb6c","hypervisorType":"KVM"}},"executeInSequence":false,"wait":
> 10800}}] }
> 2013-12-02 08:28:49,655 DEBUG [c.c.a.t.Request]
> (AgentManager-Handler-14:null) Seq 8-1124074796: Processing: { Ans: ,
> MgmtId: 29066118877352, via: 8, Ver:
> v1, Flags: 10,
> [{"com.cloud.agent.api.Answer":{"result":false,"details":"java.lang.NullPointerException\n\tat
> org.apache.cloudstack.storage.resource.NfsSeco
> ndaryStorageResource.copySnapshotToTemplateFromNfsToNfs(NfsSecondaryStorageResource.java:449)\n\tat
> org.apache.cloudstack.storage.resource.NfsSecondaryStora
> geResource.createTemplateFromSnapshot(NfsSecondaryStorageResource.java:546)\n\tat
> org.apache.cloudstack.storage.resource.NfsSecondaryStorageResource.execute
> (NfsSecondaryStorageResource.java:625)\n\tat
> org.apache.cloudstack.storage.resource.NfsSecondaryStorageResource.executeRequest(NfsSecondaryStorageResource.j
> ava:236)\n\tat
> com.cloud.storage.resource.PremiumSecondaryStorageResource.defaultAction(PremiumSecondaryStorageResource.java:63)\n\tat
> com.cloud.storage.res
> ource.PremiumSecondaryStorageResource.executeRequest(PremiumSecondaryStorageResource.java:59)\n\tat
> com.cloud.agent.Agent.processRequest(Agent.java:498)\n\t
> at com.cloud.agent.Agent$AgentRequestHandler.doTask(Agent.java:806)\n\tat
> com.cloud.utils.nio.Task.run(Task.java:83)\n\tat
> java.util.concurrent.ThreadPoolEx
> ecutor.runWorker(ThreadPoolExecutor.java:1146)\n\tat
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)\n\tat
> java.lang.Thread.
> run(Thread.java:679)\n","wait":0}}] }
> 2013-12-02 08:28:49,656 DEBUG [c.c.a.t.Request]
> (Job-Executor-140:ctx-62f776d6 ctx-120aa5f1) Seq 8-1124074796: Received: {
> Ans: , MgmtId: 29066118877352, v
> ia: 8, Ver: v1, Flags: 10, { Answer } }
> 2013-12-02 08:28:49,663 DEBUG [c.c.t.TemplateManagerImpl]
> (Job-Executor-140:ctx-62f776d6 ctx-120aa5f1) Failed to create
> templatejava.lang.NullPointerExcepti
> on
> at
> org.apache.clou
[jira] [Updated] (CLOUDSTACK-5334) [Automation] Failed to create template from snapshot while executing copy command, observed NPE In SSVM log
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nitin Mehta updated CLOUDSTACK-5334:
Assignee: (was: Nitin Mehta)
> [Automation] Failed to create template from snapshot while executing copy
> command, observed NPE In SSVM log
> ---
>
> Key: CLOUDSTACK-5334
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5334
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Template
>Affects Versions: 4.3.0
> Environment: KVM
> Branch 4.3
>Reporter: Rayees Namathponnan
>Priority: Blocker
> Fix For: 4.3.0
>
> Attachments: CLOUDSTACK-5334.rar
>
>
> Steps to reproduce
> Step 1 : snapshot root volume
> Step 2 : Create template from snapshot
> Result
> Failed to create template from snapshot, observed below "copy command failure
> and NPE" in MS log and SSVM log
> MS log
> 2013-12-02 08:28:49,406 DEBUG [o.a.c.s.m.AncientDataMotionStrategy]
> (Job-Executor-140:ctx-62f776d6 ctx-120aa5f1) copyAsync inspecting src type
> SNAPSHOT copy
> Async inspecting dest type TEMPLATE
> 2013-12-02 08:28:49,418 DEBUG [c.c.a.t.Request]
> (Job-Executor-140:ctx-62f776d6 ctx-120aa5f1) Seq 8-1124074796: Sending { Cmd
> , MgmtId: 29066118877352, via:
> 8(s-5-VM), Ver: v1, Flags: 100011,
> [{"org.apache.cloudstack.storage.command.CopyCommand":{"srcTO":{"org.apache.cloudstack.storage.to.SnapshotObjectTO":{"pa
> th":"snapshots/282/589/d2b20627-b60e-489b-9eee-9f4705331a72","dataStore":{"com.cloud.agent.api.to.NfsTO":{"_url":"nfs://10.223.110.232:/export/home/rayees/S
> C_QA_AUTO4/secondary","_role":"Image"}},"name":"VM-f9e129c2-8d62-4b70-8105-abd304bf7605_ROOT-526_20131202080509","hypervisorType":"KVM","id":20,"quiescevm":
> false}},"destTO":{"org.apache.cloudstack.storage.to.TemplateObjectTO":{"path":"template/tmpl/282/236","uuid":"1e48c6bf-388e-4184-93f5-28a21b12329c","id":236
> ,"format":"RAW","accountId":282,"hvm":true,"displayText":"raytemp","imageDataStore":{"com.cloud.agent.api.to.NfsTO":{"_url":"nfs://10.223.110.232:/export/ho
> me/rayees/SC_QA_AUTO4/secondary","_role":"Image"}},"name":"2c497573e-38cc-3f4d-a73a-49c7b63bbb6c","hypervisorType":"KVM"}},"executeInSequence":false,"wait":
> 10800}}] }
> 2013-12-02 08:28:49,655 DEBUG [c.c.a.t.Request]
> (AgentManager-Handler-14:null) Seq 8-1124074796: Processing: { Ans: ,
> MgmtId: 29066118877352, via: 8, Ver:
> v1, Flags: 10,
> [{"com.cloud.agent.api.Answer":{"result":false,"details":"java.lang.NullPointerException\n\tat
> org.apache.cloudstack.storage.resource.NfsSeco
> ndaryStorageResource.copySnapshotToTemplateFromNfsToNfs(NfsSecondaryStorageResource.java:449)\n\tat
> org.apache.cloudstack.storage.resource.NfsSecondaryStora
> geResource.createTemplateFromSnapshot(NfsSecondaryStorageResource.java:546)\n\tat
> org.apache.cloudstack.storage.resource.NfsSecondaryStorageResource.execute
> (NfsSecondaryStorageResource.java:625)\n\tat
> org.apache.cloudstack.storage.resource.NfsSecondaryStorageResource.executeRequest(NfsSecondaryStorageResource.j
> ava:236)\n\tat
> com.cloud.storage.resource.PremiumSecondaryStorageResource.defaultAction(PremiumSecondaryStorageResource.java:63)\n\tat
> com.cloud.storage.res
> ource.PremiumSecondaryStorageResource.executeRequest(PremiumSecondaryStorageResource.java:59)\n\tat
> com.cloud.agent.Agent.processRequest(Agent.java:498)\n\t
> at com.cloud.agent.Agent$AgentRequestHandler.doTask(Agent.java:806)\n\tat
> com.cloud.utils.nio.Task.run(Task.java:83)\n\tat
> java.util.concurrent.ThreadPoolEx
> ecutor.runWorker(ThreadPoolExecutor.java:1146)\n\tat
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)\n\tat
> java.lang.Thread.
> run(Thread.java:679)\n","wait":0}}] }
> 2013-12-02 08:28:49,656 DEBUG [c.c.a.t.Request]
> (Job-Executor-140:ctx-62f776d6 ctx-120aa5f1) Seq 8-1124074796: Received: {
> Ans: , MgmtId: 29066118877352, v
> ia: 8, Ver: v1, Flags: 10, { Answer } }
> 2013-12-02 08:28:49,663 DEBUG [c.c.t.TemplateManagerImpl]
> (Job-Executor-140:ctx-62f776d6 ctx-120aa5f1) Failed to create
> templatejava.lang.NullPointerExcepti
> on
> at
> org.apache.cloudstack.storage.resource.NfsSecondaryStorageResource.copySnapshotToTemplateFromNfsToNfs(NfsSecondaryStorageResource.java:449)
> at
> org.apache.cloudstack.storage.resource.NfsSecondaryStorageResource.createTemplateFromSnapshot(NfsSecondaryStorageResource.java:546)
> at
> org.apache.cloudstack.storage.resource.NfsSecondaryStorageResource.execute(NfsSecondaryStorageResource.java:625)
> at
> org.apache.cloudstack.storage.resource.NfsSecondaryStorageResource.executeRequest(NfsSecondaryStorageResour
[jira] [Commented] (CLOUDSTACK-5521) KVM needs a cpu topology
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13849850#comment-13849850 ] ASF subversion and git services commented on CLOUDSTACK-5521: - Commit 2f53295151820c56c683ed280691ebd479d25ec2 in branch refs/heads/master from [~mlsorensen] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=2f53295 ] CLOUDSTACK-5521: Create multi-core topology when deploying KVM virtual machines with many cores > KVM needs a cpu topology > > > Key: CLOUDSTACK-5521 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5521 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: KVM >Reporter: Marcus Sorensen >Assignee: Marcus Sorensen > > When creating VMs, KVM creates each CPU as its own socket. This is > problematic for a few reasons, but most notably for guest OSes that are > licensed per socket. Need to update KVM cpu topology to look more like a real > server with # of cores per socket. -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Commented] (CLOUDSTACK-669) Better VM Sync
[ https://issues.apache.org/jira/browse/CLOUDSTACK-669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13849851#comment-13849851 ] ASF subversion and git services commented on CLOUDSTACK-669: Commit 9d3827e6fe48b23639392bfe25c4d3bd2c083eac in branch refs/heads/master from [~kelveny] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=9d3827e ] CLOUDSTACK-669: refactor VM work job dispatcher to allow volume/snapshot manager to participate serialized job handling > Better VM Sync > -- > > Key: CLOUDSTACK-669 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-669 > Project: CloudStack > Issue Type: New Feature > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Reporter: Hari Kannan >Assignee: Kelven Yang > Fix For: 4.3.0 > > > https://cwiki.apache.org/confluence/display/CLOUDSTACK/VMWare+Enhancements+-+Support+for+DRS+and+VM+HA -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Resolved] (CLOUDSTACK-5521) KVM needs a cpu topology
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5521?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcus Sorensen resolved CLOUDSTACK-5521. - Resolution: Fixed Fix Version/s: 4.4.0 > KVM needs a cpu topology > > > Key: CLOUDSTACK-5521 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5521 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: KVM >Reporter: Marcus Sorensen >Assignee: Marcus Sorensen > Fix For: 4.4.0 > > > When creating VMs, KVM creates each CPU as its own socket. This is > problematic for a few reasons, but most notably for guest OSes that are > licensed per socket. Need to update KVM cpu topology to look more like a real > server with # of cores per socket. -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Commented] (CLOUDSTACK-5521) KVM needs a cpu topology
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13849865#comment-13849865 ] ASF subversion and git services commented on CLOUDSTACK-5521: - Commit 6ae1c26b9a7964ce96202719368fe0830534c51e in branch refs/heads/4.3 from [~mlsorensen] [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=6ae1c26 ] CLOUDSTACK-5521: Create multi-core topology when deploying KVM virtual machines with many cores > KVM needs a cpu topology > > > Key: CLOUDSTACK-5521 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5521 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: KVM >Reporter: Marcus Sorensen >Assignee: Marcus Sorensen > Fix For: 4.4.0 > > > When creating VMs, KVM creates each CPU as its own socket. This is > problematic for a few reasons, but most notably for guest OSes that are > licensed per socket. Need to update KVM cpu topology to look more like a real > server with # of cores per socket. -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Commented] (CLOUDSTACK-5520) Script errors seen when trying to seed the 64 bit Xenserver templates.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13849915#comment-13849915 ] Sangeetha Hariharan commented on CLOUDSTACK-5520: - When trying to install kvm templates , I see only the permission issues "mv: failed to preserve ownership for `//mnt/secondary/template/tmpl/1/3///83e2f84c-97c4-46ef-8c38-df55c5641904.qcow2': Invalid argument" [root@rhel64-2 management]# /usr/share/cloudstack-common/scripts/storage/secondary/cloud-install-sys-tmplt -m /mnt/secondary -u http://10.223.110.231/templates/felton_qa/64/systemvm64template-2013-10-24-master-kvm.qcow2.bz2 -h kvm --2013-12-16 19:20:34-- http://10.223.110.231/templates/felton_qa/64/systemvm64template-2013-10-24-master-kvm.qcow2.bz2 Connecting to 10.223.110.231:80... connected. HTTP request sent, awaiting response... 200 OK Length: 266447232 (254M) [application/x-bzip2] Saving to: â/usr/share/cloudstack-common/scripts/storage/secondary/83e2f84c-97c4-46ef-8c38-df55c5641904.qcow2â 100%[==>] 266,447,232 93.3M/s in 2.7s 2013-12-16 19:20:37 (93.3 MB/s) - â/usr/share/cloudstack-common/scripts/storage/secondary/83e2f84c-97c4-46ef-8c38-df55c5641904.qcow2â Uncompressing to /usr/share/cloudstack-common/scripts/storage/secondary/83e2f84c-97c4-46ef-8c38-df55c5641904.qcow2.tmp (type bz2)...could take a long time Moving to /mnt/secondary/template/tmpl/1/3///83e2f84c-97c4-46ef-8c38-df55c5641904.qcow2...could take a while mv: failed to preserve ownership for `//mnt/secondary/template/tmpl/1/3///83e2f84c-97c4-46ef-8c38-df55c5641904.qcow2': Invalid argument Successfully installed system VM template to /mnt/secondary/template/tmpl/1/3/ [root@rhel64-2 management]# > Script errors seen when trying to seed the 64 bit Xenserver templates. > -- > > Key: CLOUDSTACK-5520 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5520 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.3.0 > Environment: Build from 4.3 >Reporter: Sangeetha Hariharan >Priority: Critical > Fix For: 4.3.0 > > > Following error seen when trying to seed the latest 64 bit template for > Xenserver but the script reports success. > [root@rhel64-1 secondary]# > /usr/share/cloudstack-common/scripts/storage/secondary/cloud-install-sys-tmplt > -m /mnt/secondary -u > http://nfs1.lab.vmops.com/templates/felton_qa/64/systemvm64template-2013-12-16-master-xen.vhd.bz2 > -h xenserver -F > --2013-12-16 14:30:33-- > http://nfs1.lab.vmops.com/templates/felton_qa/64/systemvm64template-2013-12-16-master-xen.vhd.bz2 > Resolving nfs1.lab.vmops.com... 10.223.110.231 > Connecting to nfs1.lab.vmops.com|10.223.110.231|:80... connected. > HTTP request sent, awaiting response... 200 OK > Length: 229311649 (219M) [application/x-bzip2] > Saving to: > â/usr/share/cloudstack-common/scripts/storage/secondary/91b86630-cee7-4aa9-9e60-824bdb06a7e9.vhdâ > 100%[==>] > 229,311,649 112M/s in 2.0s > 2013-12-16 14:30:35 (112 MB/s) - > â/usr/share/cloudstack-common/scripts/storage/secondary/91b86630-cee7-4aa9-9e60-824bdb06a7e9.vhdâ > Uncompressing to > /usr/share/cloudstack-common/scripts/storage/secondary/91b86630-cee7-4aa9-9e60-824bdb06a7e9.vhd.tmp > (type bz2)...could take a long time > /usr/share/cloudstack-common/scripts/storage/secondary/createtmplt.sh: line > 207: [: isCifs: integer expression expected > Moving to > /mnt/secondary/template/tmpl/1/1///91b86630-cee7-4aa9-9e60-824bdb06a7e9.vhd...could > take a while > mv: failed to preserve ownership for > `//mnt/secondary/template/tmpl/1/1///91b86630-cee7-4aa9-9e60-824bdb06a7e9.vhd': > Invalid argument > Successfully installed system VM template to > /mnt/secondary/template/tmpl/1/1/ > [root@rhel64-1 secondary]# -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Commented] (CLOUDSTACK-5252) list router api not giving correct results with zone, pod, clusters paramenters
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5252?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13849924#comment-13849924
]
ASF subversion and git services commented on CLOUDSTACK-5252:
-
Commit f919441c347f51d618f70c8044b6c00a7a8f72f2 in branch refs/heads/master
from [~jessicawang]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=f919441 ]
CLOUDSTACK-5252: UI > Infrastructure > Virtual Routers > group by
zone/pod/cluster > include project-related routers into calculation.
> list router api not giving correct results with zone, pod, clusters
> paramenters
> ---
>
> Key: CLOUDSTACK-5252
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5252
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Upgrade
>Affects Versions: 4.3.0
> Environment: upgrade from 3.0.7 to 4.3
>Reporter: shweta agarwal
>Assignee: Jessica Wang
>Priority: Blocker
> Fix For: 4.3.0
>
>
> list router api is not giving correct result when called with any of the
> following parameters
> Zoneid
> clusterid
> podid
> Cloudmonkey output for
> list routers zoneid=1 | more
> "count": 1,
> "router": [
> {
> "account": "admin",
> "created": "2013-11-22T01:22:28-0500",
> "dns1": "10.140.50.6",
> "domain": "ROOT",
> "domainid": "1",
> "gateway": "10.147.51.1",
> "guestipaddress": "10.1.1.1",
> "guestmacaddress": "02:00:01:99:00:02",
> "guestnetmask": "255.255.255.0",
> "guestnetworkid": "2cd93b6f-c78a-44ec-93c6-d621744358c8",
> "hostid": "ccf22f38-7fec-404c-b250-c209b14694e9",
> "hostname": "Rack1Pod1Host27",
> "id": "ca7f684d-915f-4d65-8b93-10eab67f8bb7",
> "isredundantrouter": false,
> "linklocalip": "169.254.2.244",
> "linklocalmacaddress": "0e:00:a9:fe:02:f4",
> "linklocalnetmask": "255.255.0.0",
> "linklocalnetworkid": "ad987a17-2987-4354-80a0-568cdc21678f",
> "name": "r-6-VM",
> "networkdomain": "cs2cloud.internal",
> "nic": [
> {
> "broadcasturi": "vlan://1059",
> "id": "fdf69706-b0f3-4827-8d93-00edc973dfcf",
> "ipaddress": "10.1.1.1",
> "isdefault": false,
> "isolationuri": "vlan://1059",
> "macaddress": "02:00:01:99:00:02",
> "netmask": "255.255.255.0",
> "networkid": "2cd93b6f-c78a-44ec-93c6-d621744358c8",
> "networkname": "vr-xen-admin",
> "traffictype": "Guest",
> "type": "Isolated"
> },
> {
> "gateway": "169.254.0.1",
> "id": "ae74a4b2-05c5-4543-8a94-7770626f07dc",
> "ipaddress": "169.254.2.244",
> "isdefault": false,
> "macaddress": "0e:00:a9:fe:02:f4",
> "netmask": "255.255.0.0",
> "networkid": "ad987a17-2987-4354-80a0-568cdc21678f",
> "traffictype": "Control"
> },
> {
> "broadcasturi": "vlan://51",
> "gateway": "10.147.51.1",
> "id": "cebdf095-b3cd-4053-9dc7-b73ca1eb4f02",
> "ipaddress": "10.147.51.21",
> "isdefault": true,
> "isolationuri": "vlan://51",
> "macaddress": "06:bb:aa:00:00:20",
> "netmask": "255.255.255.0",
> "networkid": "2b27fca6-89ba-441b-a402-3ca9b1fab670",
> "traffictype": "Public"
> }
> ],
> "podid": "057eb551-1ebc-438f-a960-6958ef5182f4",
> "publicip": "10.147.51.21",
> "publicmacaddress": "06:bb:aa:00:00:20",
> "publicnetmask": "255.255.255.0",
> "publicnetworkid": "2b27fca6-89ba-441b-a402-3ca9b1fab670",
> "redundantstate": "UNKNOWN",
> "requiresupgrade": true,
> "role": "VIRTUAL_ROUTER",
> "serviceofferingid": "1b56ab92-9d5d-49e1-819c-e938b83e6986",
> "serviceofferingname": "System Offering For Software Router",
> "state": "Running",
> "templateid": "d03705f4-072d-4766-9f61-6ba32524732c",
> "version": "3.0",
> "zoneid": "2998d037-1956-40a2-b9d5-db144fb87408",
> "zonename": "xen"
> }
> ]
> }
> While DB shows may more routers in zone 1
> select * from vm_instance where data_center_id=1 and type="DomainRouter"
> "id" "name" "uuid" "instance_name" "state" "vm_template_id"
> "guest_os_id" "private_mac_address" "private_ip_address""pod_id"
> "data_center_id""host_id" "last_host_id" "proxy_id"
> "proxy_assign_time" "vnc_password" "ha_enabled""limit_cpu_use"
> "update_count" "update_time" "created" "removed" "type"
> "vm_type" "account_id""domain_id" "s
[jira] [Commented] (CLOUDSTACK-5252) list router api not giving correct results with zone, pod, clusters paramenters
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5252?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13849922#comment-13849922
]
ASF subversion and git services commented on CLOUDSTACK-5252:
-
Commit 3abc2a0ac10f458b41154a91b6a339e86363d90a in branch refs/heads/4.3 from
[~jessicawang]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=3abc2a0 ]
CLOUDSTACK-5252: UI > Infrastructure > Virtual Routers > group by
zone/pod/cluster > include project-related routers into calculation.
> list router api not giving correct results with zone, pod, clusters
> paramenters
> ---
>
> Key: CLOUDSTACK-5252
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5252
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Upgrade
>Affects Versions: 4.3.0
> Environment: upgrade from 3.0.7 to 4.3
>Reporter: shweta agarwal
>Assignee: Jessica Wang
>Priority: Blocker
> Fix For: 4.3.0
>
>
> list router api is not giving correct result when called with any of the
> following parameters
> Zoneid
> clusterid
> podid
> Cloudmonkey output for
> list routers zoneid=1 | more
> "count": 1,
> "router": [
> {
> "account": "admin",
> "created": "2013-11-22T01:22:28-0500",
> "dns1": "10.140.50.6",
> "domain": "ROOT",
> "domainid": "1",
> "gateway": "10.147.51.1",
> "guestipaddress": "10.1.1.1",
> "guestmacaddress": "02:00:01:99:00:02",
> "guestnetmask": "255.255.255.0",
> "guestnetworkid": "2cd93b6f-c78a-44ec-93c6-d621744358c8",
> "hostid": "ccf22f38-7fec-404c-b250-c209b14694e9",
> "hostname": "Rack1Pod1Host27",
> "id": "ca7f684d-915f-4d65-8b93-10eab67f8bb7",
> "isredundantrouter": false,
> "linklocalip": "169.254.2.244",
> "linklocalmacaddress": "0e:00:a9:fe:02:f4",
> "linklocalnetmask": "255.255.0.0",
> "linklocalnetworkid": "ad987a17-2987-4354-80a0-568cdc21678f",
> "name": "r-6-VM",
> "networkdomain": "cs2cloud.internal",
> "nic": [
> {
> "broadcasturi": "vlan://1059",
> "id": "fdf69706-b0f3-4827-8d93-00edc973dfcf",
> "ipaddress": "10.1.1.1",
> "isdefault": false,
> "isolationuri": "vlan://1059",
> "macaddress": "02:00:01:99:00:02",
> "netmask": "255.255.255.0",
> "networkid": "2cd93b6f-c78a-44ec-93c6-d621744358c8",
> "networkname": "vr-xen-admin",
> "traffictype": "Guest",
> "type": "Isolated"
> },
> {
> "gateway": "169.254.0.1",
> "id": "ae74a4b2-05c5-4543-8a94-7770626f07dc",
> "ipaddress": "169.254.2.244",
> "isdefault": false,
> "macaddress": "0e:00:a9:fe:02:f4",
> "netmask": "255.255.0.0",
> "networkid": "ad987a17-2987-4354-80a0-568cdc21678f",
> "traffictype": "Control"
> },
> {
> "broadcasturi": "vlan://51",
> "gateway": "10.147.51.1",
> "id": "cebdf095-b3cd-4053-9dc7-b73ca1eb4f02",
> "ipaddress": "10.147.51.21",
> "isdefault": true,
> "isolationuri": "vlan://51",
> "macaddress": "06:bb:aa:00:00:20",
> "netmask": "255.255.255.0",
> "networkid": "2b27fca6-89ba-441b-a402-3ca9b1fab670",
> "traffictype": "Public"
> }
> ],
> "podid": "057eb551-1ebc-438f-a960-6958ef5182f4",
> "publicip": "10.147.51.21",
> "publicmacaddress": "06:bb:aa:00:00:20",
> "publicnetmask": "255.255.255.0",
> "publicnetworkid": "2b27fca6-89ba-441b-a402-3ca9b1fab670",
> "redundantstate": "UNKNOWN",
> "requiresupgrade": true,
> "role": "VIRTUAL_ROUTER",
> "serviceofferingid": "1b56ab92-9d5d-49e1-819c-e938b83e6986",
> "serviceofferingname": "System Offering For Software Router",
> "state": "Running",
> "templateid": "d03705f4-072d-4766-9f61-6ba32524732c",
> "version": "3.0",
> "zoneid": "2998d037-1956-40a2-b9d5-db144fb87408",
> "zonename": "xen"
> }
> ]
> }
> While DB shows may more routers in zone 1
> select * from vm_instance where data_center_id=1 and type="DomainRouter"
> "id" "name" "uuid" "instance_name" "state" "vm_template_id"
> "guest_os_id" "private_mac_address" "private_ip_address""pod_id"
> "data_center_id""host_id" "last_host_id" "proxy_id"
> "proxy_assign_time" "vnc_password" "ha_enabled""limit_cpu_use"
> "update_count" "update_time" "created" "removed" "type"
> "vm_type" "account_id""domain_id" "serv
[jira] [Commented] (CLOUDSTACK-5407) site-to-site VPN VR-to-VR After VPN connection successfully established , site with passive mode remains in "Disconnected" state
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13849977#comment-13849977
]
Sheng Yang commented on CLOUDSTACK-5407:
I cannot reproduce the issue.
The update of connection status is executed every 30 seconds.
Also, if there is no VM in the VPC, the update won't be executed.
> site-to-site VPN VR-to-VR After VPN connection successfully established ,
> site with passive mode remains in "Disconnected" state
>
>
> Key: CLOUDSTACK-5407
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5407
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server
>Affects Versions: 4.3.0
> Environment: MSrhel 6.4 12/5/13 latest build 97
> host XS 6.2
>Reporter: angeline shen
>Assignee: Sheng Yang
>Priority: Critical
> Fix For: 4.3.0
>
> Attachments: v16.htm
>
>
> 1. admin creates vpc1, VPN customer gateway tovpc2
>d1user creates vpc2, VPN customer gateway toadmin
> 2. admincreates VPN connection to 'tovpc2'passive mode
> d1user creatses VPN connection to 'toadmin'
> 3. After VPN connection successful, d1user VPN connection shows "connected",
> but admin shows "Disconnected"
> http://10.223.130.107:8080/client/api?command=listVpnConnections&listAll=true&page=1&pagesize=20&response=json&sessionkey=b3xkTyC7CxDFKBCNY%2ByGqaoK4rk%3D&vpcid=b4bd8438-b17a-4bb3-9ff8-6b980e148cd8&_=1386373747078
> { "listvpnconnectionsresponse" : { "count":1 ,"vpnconnection" : [
> {"id":"6a56648a-78b3-4ab7-a709-42d1e291ef23","s2svpngatewayid":"95790330-3201-4f3f-b824-ab3efbef","publicip":"10.223.123.17","s2scustomergatewayid":"af688052-a2fd-44b2-8c07-cb6c938e5483","gateway":"10.223.123.53","cidrlist":"10.2.1.1/16","ipsecpsk":"123123","ikepolicy":"3des-md5","esppolicy":"3des-md5","ikelifetime":86400,"esplifetime":3600,"dpd":false,"state":"Disconnected","passive":true,"account":"admin","domainid":"31a9bc00-5de9-11e3-a6e9-06c6ac000773","domain":"ROOT","created":"2013-12-06T14:31:10-0800"}
> ] } }
--
This message was sent by Atlassian JIRA
(v6.1.4#6159)
[jira] [Resolved] (CLOUDSTACK-5407) site-to-site VPN VR-to-VR After VPN connection successfully established , site with passive mode remains in "Disconnected" state
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5407?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sheng Yang resolved CLOUDSTACK-5407.
Resolution: Cannot Reproduce
If you can reproduce, please provide the environment and mgmt server log.
> site-to-site VPN VR-to-VR After VPN connection successfully established ,
> site with passive mode remains in "Disconnected" state
>
>
> Key: CLOUDSTACK-5407
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5407
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server
>Affects Versions: 4.3.0
> Environment: MSrhel 6.4 12/5/13 latest build 97
> host XS 6.2
>Reporter: angeline shen
>Assignee: Sheng Yang
>Priority: Critical
> Fix For: 4.3.0
>
> Attachments: v16.htm
>
>
> 1. admin creates vpc1, VPN customer gateway tovpc2
>d1user creates vpc2, VPN customer gateway toadmin
> 2. admincreates VPN connection to 'tovpc2'passive mode
> d1user creatses VPN connection to 'toadmin'
> 3. After VPN connection successful, d1user VPN connection shows "connected",
> but admin shows "Disconnected"
> http://10.223.130.107:8080/client/api?command=listVpnConnections&listAll=true&page=1&pagesize=20&response=json&sessionkey=b3xkTyC7CxDFKBCNY%2ByGqaoK4rk%3D&vpcid=b4bd8438-b17a-4bb3-9ff8-6b980e148cd8&_=1386373747078
> { "listvpnconnectionsresponse" : { "count":1 ,"vpnconnection" : [
> {"id":"6a56648a-78b3-4ab7-a709-42d1e291ef23","s2svpngatewayid":"95790330-3201-4f3f-b824-ab3efbef","publicip":"10.223.123.17","s2scustomergatewayid":"af688052-a2fd-44b2-8c07-cb6c938e5483","gateway":"10.223.123.53","cidrlist":"10.2.1.1/16","ipsecpsk":"123123","ikepolicy":"3des-md5","esppolicy":"3des-md5","ikelifetime":86400,"esplifetime":3600,"dpd":false,"state":"Disconnected","passive":true,"account":"admin","domainid":"31a9bc00-5de9-11e3-a6e9-06c6ac000773","domain":"ROOT","created":"2013-12-06T14:31:10-0800"}
> ] } }
--
This message was sent by Atlassian JIRA
(v6.1.4#6159)
[jira] [Reopened] (CLOUDSTACK-5250) [Automation] integration.smoke.test_network.TestReleaseIP.test_releaseIP failing
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rayees Namathponnan reopened CLOUDSTACK-5250:
-
Observed in latest vmware run;
> [Automation] integration.smoke.test_network.TestReleaseIP.test_releaseIP
> failing
> --
>
> Key: CLOUDSTACK-5250
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5250
> Project: CloudStack
> Issue Type: Test
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Automation
>Affects Versions: 4.3.0
> Environment: KVM
> automation
>Reporter: Rayees Namathponnan
> Fix For: 4.3.0
>
>
> [Automation] integration.smoke.test_network.TestReleaseIP.test_releaseIP
> failing after fixing CLOUDSTACK-4344
> heck if disassociated IP Address is no longer available
> >> begin captured logging <<
> test_releaseIP (integration.smoke.test_network.TestReleaseIP): DEBUG:
> Deleting Public IP : 2c0e1ad7-639b-4564-ba82-d44a41740c34
> test_releaseIP (integration.smoke.test_network.TestReleaseIP): DEBUG: List
> Public IP response[{networkid : u'04c5487a-5754-432f-81cd-d52738c1eb9c',
> physicalnetworkid : u'ddf995ff-4f12-4cae-9729-5b763a1e1170', account :
> u'test-TestReleaseIP-test_releaseIP-RTK06M', domainid :
> u'5f0d3956-531c-11e3-a447-1a6f7bb0d0a8', issourcenat : True, isstaticnat :
> False, tags : [], associatednetworkname :
> u'test-TestReleaseIP-test_releaseIP-RTK06M-network', domain : u'ROOT', vlanid
> : u'7746889d-db42-41c2-90d1-1876847c2377', zoneid :
> u'9338ab1f-fee3-43dc-98cc-9aa2839b0d19', vlanname : u'vlan://1221', state :
> u'Allocated', associatednetworkid : u'823a5c6c-53d4-4dc0-8672-a3daeb9ff6ff',
> zonename : u'Adv-KVM-Zone1', forvirtualnetwork : True, allocated :
> u'2013-11-21T20:11:44-0800', issystem : False, ipaddress : u'10.223.122.74',
> id : u'2c0e1ad7-639b-4564-ba82-d44a41740c34', isportable : False}]
> - >> end captured logging << -
> Stacktrace
> File "/usr/local/lib/python2.7/unittest/case.py", line 318, in run
> testMethod()
> File "/Repo_30X/ipcl/cloudstack/test/integration/smoke/test_network.py",
> line 859, in test_releaseIP
> "Check if disassociated IP Address is no longer available"
> File "/usr/local/lib/python2.7/unittest/case.py", line 494, in assertEqual
> assertion_func(first, second, msg=msg)
> File "/usr/local/lib/python2.7/unittest/case.py", line 487, in
> _baseAssertEqual
> raise self.failureException(msg)
> Check if disassociated IP Address is no longer available
> >> begin captured logging <<
> test_releaseIP (integration.smoke.test_network.TestReleaseIP): DEBUG:
> Deleting Public IP : 2c0e1ad7-639b-4564-ba82-d44a41740c34
> test_releaseIP (integration.smoke.test_network.TestReleaseIP): DEBUG: List
> Public IP response[{networkid : u'04c5487a-5754-432f-81cd-d52738c1eb9c',
> physicalnetworkid : u'ddf995ff-4f12-4cae-9729-5b763a1e1170', account :
> u'test-TestReleaseIP-test_releaseIP-RTK06M', domainid :
> u'5f0d3956-531c-11e3-a447-1a6f7bb0d0a8', issourcenat : True, isstaticnat :
> False, tags : [], associatednetworkname :
> u'test-TestReleaseIP-test_releaseIP-RTK06M-network', domain : u'ROOT', vlanid
> : u'7746889d-db42-41c2-90d1-1876847c2377', zoneid :
> u'9338ab1f-fee3-43dc-98cc-9aa2839b0d19', vlanname : u'vlan://1221', state :
> u'Allocated', associatednetworkid : u'823a5c6c-53d4-4dc0-8672-a3daeb9ff6ff',
> zonename : u'Adv-KVM-Zone1', forvirtualnetwork : True, allocated :
> u'2013-11-21T20:11:44-0800', issystem : False, ipaddress : u'10.223.122.74',
> id : u'2c0e1ad7-639b-4564-ba82-d44a41740c34', isportable : False}]
> - >> end captured logging << -
--
This message was sent by Atlassian JIRA
(v6.1.4#6159)
[jira] [Closed] (CLOUDSTACK-5405) [Automation] Basic zone with SG : Test cases deploying VMs with security group which not belong to account
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5405?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rayees Namathponnan closed CLOUDSTACK-5405.
---
Verified
> [Automation] Basic zone with SG : Test cases deploying VMs with security
> group which not belong to account
> ---
>
> Key: CLOUDSTACK-5405
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5405
> Project: CloudStack
> Issue Type: Test
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Automation
>Affects Versions: 4.3.0
> Environment: KVM
> Automation
>Reporter: Rayees Namathponnan
>Assignee: Girish Shilamkar
>Priority: Blocker
> Fix For: 4.2.1, 4.3.0
>
>
> run BVT test cases in basic zone with SG environment
> test_volume.py:TestVolumes
> Test cases failing with below error
> Execute cmd: deployvirtualmachine failed, due to: errorCode: 531,
> errorText:Entity
> com.cloud.network.security.SecurityGroupVO$$EnhancerByCGLIB$$adfb77c8@6c9922fd
> and entity
> Acct[1ba19e88-1614-4675-9613-89b2f104e836-test-TestCreateVolume-UCFUY3]
> belong to different accounts
> Stacktrace
> Traceback (most recent call last):
> File "/usr/local/lib/python2.7/site-packages/nose/suite.py", line 208, in
> run
> self.setUp()
> File "/usr/local/lib/python2.7/site-packages/nose/suite.py", line 291, in
> setUp
> self.setupContext(ancestor)
> File "/usr/local/lib/python2.7/site-packages/nose/suite.py", line 314, in
> setupContext
> try_run(context, names)
> File "/usr/local/lib/python2.7/site-packages/nose/util.py", line 469, in
> try_run
> return func()
> File "/Repo_30X/ipcl/cloudstack/test/integration/smoke/test_volumes.py",
> line 333, in setUpClass
> mode=cls.services["mode"]
> File
> "/usr/local/lib/python2.7/site-packages/marvin/integration/lib/base.py", line
> 408, in create
> virtual_machine = apiclient.deployVirtualMachine(cmd, method=method)
> File
> "/usr/local/lib/python2.7/site-packages/marvin/cloudstackAPI/cloudstackAPIClient.py",
> line 623, in deployVirtualMachine
> response = self.connection.marvinRequest(command, response_type=response,
> method=method)
> File
> "/usr/local/lib/python2.7/site-packages/marvin/cloudstackConnection.py", line
> 279, in marvinRequest
> response = jsonHelper.getResultObj(response.json(), response_type)
> File "/usr/local/lib/python2.7/site-packages/marvin/jsonHelper.py", line
> 148, in getResultObj
> raise cloudstackException.cloudstackAPIException(respname, errMsg)
> cloudstackAPIException: Execute cmd: deployvirtualmachine failed, due to:
> errorCode: 531, errorText:Entity
> com.cloud.network.security.SecurityGroupVO$$EnhancerByCGLIB$$adfb77c8@6c9922fd
> and entity
> Acct[1ba19e88-1614-4675-9613-89b2f104e836-test-TestCreateVolume-UCFUY3]
> belong to different accounts
> Reason for the failure
> Test case created account "test-TestCreateVolume-QXLJ8M" and created security
> group for this account "Name : default, Description : Default Security
> Group, Account: test-TestCreateVolume-QXLJ8M"
> Please see the log test case trying to deploy with SG "basic_sec_grp" which
> is belong to admin account , instead of security belong to account
> "test-TestCreateVolume-QXLJ8M"
> 2013-12-06 11:03:09,136 INFO [a.c.c.a.ApiServer]
> (catalina-exec-25:ctx-66962f4f ctx-ab72e36e ctx-0de15a42) (userId=2
> accountId=2 sessionId=null) 10.223.240.193 -- GET apiKey=4PKA7xH56
> fMp-9S0TEAsyBYNBzdnffzYeq03cm4GuA6RDO6E9d69ULNWiu778dzPb5tFhSk6RBqJ26Xdi_iTlg&securitygroupname=basic_sec_grp&command=listSecurityGroups&signature=Dv7uasuirly5dQHFW5MJwHzgZkg%3D&respon
> se=json 200 { "listsecuritygroupsresponse" : { "count":1 ,"securitygroup" : [
>
> {"id":"98e72a15-c505-49f8-951e-aba15d58442b","name":"basic_sec_grp","account":"admin","domainid":"bce4672
> 4-5e44-11e3-8936-4290361b938f","domain":"ROOT","ingressrule":[{"ruleid":"9e112034-99ef-4d6b-8417-3c5383706045","protocol":"tcp","startport":22,"endport":22,"cidr":"0.0.0.0/0"}],"egress
> rule":[],"tags":[]} ] } }
> 2013-12-06 11:03:09,203 INFO [a.c.c.a.ApiServer]
> (catalina-exec-19:ctx-f8b6a8b5 ctx-646818bc ctx-d643d28e) (userId=2
> accountId=2 sessionId=null) 10.223.240.193 -- GET domainid=bce4672
> 4-5e44-11e3-8936-4290361b938f&zoneid=f229ef91-e5a0-4a29-9965-3dd95581b8f7&apiKey=4PKA7xH56fMp-9S0TEAsyBYNBzdnffzYeq03cm4GuA6RDO6E9d69ULNWiu778dzPb5tFhSk6RBqJ26Xdi_iTlg&serviceofferingi
> d=9d809384-94f5-41e2-9ac0-249d0053883d&signature=L%2FfAYntOVSOFcICWJHKo%2Bs6k954%3D&templateid=bce8a51e-5e44-11e3-8936-4290361b938f&response=json&account=test-TestCreateVolume-QXLJ8M&s
> ecuritygroupids=98e72a15-c505-49f8-951e-aba15d58442b&command=deployVirtualMachine&hypervisor=KVM
[jira] [Resolved] (CLOUDSTACK-5267) [Automation] instance.name name should not append with VM's Name
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Girish Shilamkar resolved CLOUDSTACK-5267. -- Resolution: Fixed Fix Version/s: 4.2.1 > [Automation] instance.name name should not append with VM's Name > > > Key: CLOUDSTACK-5267 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5267 > Project: CloudStack > Issue Type: Test > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Automation >Affects Versions: 4.3.0 > Environment: Branch : 4.3.0 >Reporter: Rayees Namathponnan >Assignee: Girish Shilamkar >Priority: Blocker > Labels: automation > Fix For: 4.2.1, 4.3.0 > > > Steps to reproduce > Step 1 : set instance.name=TestVM in global parameter > Step 2 : Restart MS and Deploy Vm, dont specify any name while deploying the > VM > Actual Result > UUID of new VM is 56276ab1-3353-473c-8b35-f27f81f68bd8, and vm should be > deployed with name "56276ab1-3353-473c-8b35-f27f81f68bd8" > vm deployed with name TestVM56276ab1-3353-473c-8b35-f27f81f68bd8, here > instance.name also included > We need to remove instance.name from vm name -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Assigned] (CLOUDSTACK-5250) [Automation] integration.smoke.test_network.TestReleaseIP.test_releaseIP failing
[
https://issues.apache.org/jira/browse/CLOUDSTACK-5250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Girish Shilamkar reassigned CLOUDSTACK-5250:
Assignee: Girish Shilamkar
> [Automation] integration.smoke.test_network.TestReleaseIP.test_releaseIP
> failing
> --
>
> Key: CLOUDSTACK-5250
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5250
> Project: CloudStack
> Issue Type: Test
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Automation
>Affects Versions: 4.3.0
> Environment: KVM
> automation
>Reporter: Rayees Namathponnan
>Assignee: Girish Shilamkar
> Fix For: 4.3.0
>
>
> [Automation] integration.smoke.test_network.TestReleaseIP.test_releaseIP
> failing after fixing CLOUDSTACK-4344
> heck if disassociated IP Address is no longer available
> >> begin captured logging <<
> test_releaseIP (integration.smoke.test_network.TestReleaseIP): DEBUG:
> Deleting Public IP : 2c0e1ad7-639b-4564-ba82-d44a41740c34
> test_releaseIP (integration.smoke.test_network.TestReleaseIP): DEBUG: List
> Public IP response[{networkid : u'04c5487a-5754-432f-81cd-d52738c1eb9c',
> physicalnetworkid : u'ddf995ff-4f12-4cae-9729-5b763a1e1170', account :
> u'test-TestReleaseIP-test_releaseIP-RTK06M', domainid :
> u'5f0d3956-531c-11e3-a447-1a6f7bb0d0a8', issourcenat : True, isstaticnat :
> False, tags : [], associatednetworkname :
> u'test-TestReleaseIP-test_releaseIP-RTK06M-network', domain : u'ROOT', vlanid
> : u'7746889d-db42-41c2-90d1-1876847c2377', zoneid :
> u'9338ab1f-fee3-43dc-98cc-9aa2839b0d19', vlanname : u'vlan://1221', state :
> u'Allocated', associatednetworkid : u'823a5c6c-53d4-4dc0-8672-a3daeb9ff6ff',
> zonename : u'Adv-KVM-Zone1', forvirtualnetwork : True, allocated :
> u'2013-11-21T20:11:44-0800', issystem : False, ipaddress : u'10.223.122.74',
> id : u'2c0e1ad7-639b-4564-ba82-d44a41740c34', isportable : False}]
> - >> end captured logging << -
> Stacktrace
> File "/usr/local/lib/python2.7/unittest/case.py", line 318, in run
> testMethod()
> File "/Repo_30X/ipcl/cloudstack/test/integration/smoke/test_network.py",
> line 859, in test_releaseIP
> "Check if disassociated IP Address is no longer available"
> File "/usr/local/lib/python2.7/unittest/case.py", line 494, in assertEqual
> assertion_func(first, second, msg=msg)
> File "/usr/local/lib/python2.7/unittest/case.py", line 487, in
> _baseAssertEqual
> raise self.failureException(msg)
> Check if disassociated IP Address is no longer available
> >> begin captured logging <<
> test_releaseIP (integration.smoke.test_network.TestReleaseIP): DEBUG:
> Deleting Public IP : 2c0e1ad7-639b-4564-ba82-d44a41740c34
> test_releaseIP (integration.smoke.test_network.TestReleaseIP): DEBUG: List
> Public IP response[{networkid : u'04c5487a-5754-432f-81cd-d52738c1eb9c',
> physicalnetworkid : u'ddf995ff-4f12-4cae-9729-5b763a1e1170', account :
> u'test-TestReleaseIP-test_releaseIP-RTK06M', domainid :
> u'5f0d3956-531c-11e3-a447-1a6f7bb0d0a8', issourcenat : True, isstaticnat :
> False, tags : [], associatednetworkname :
> u'test-TestReleaseIP-test_releaseIP-RTK06M-network', domain : u'ROOT', vlanid
> : u'7746889d-db42-41c2-90d1-1876847c2377', zoneid :
> u'9338ab1f-fee3-43dc-98cc-9aa2839b0d19', vlanname : u'vlan://1221', state :
> u'Allocated', associatednetworkid : u'823a5c6c-53d4-4dc0-8672-a3daeb9ff6ff',
> zonename : u'Adv-KVM-Zone1', forvirtualnetwork : True, allocated :
> u'2013-11-21T20:11:44-0800', issystem : False, ipaddress : u'10.223.122.74',
> id : u'2c0e1ad7-639b-4564-ba82-d44a41740c34', isportable : False}]
> - >> end captured logging << -
--
This message was sent by Atlassian JIRA
(v6.1.4#6159)
[jira] [Updated] (CLOUDSTACK-4578) [vmware]SSVM is not getting created if one host down from a cluster
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4578?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Damodar Reddy T updated CLOUDSTACK-4578: Assignee: Kelven Yang (was: Damodar Reddy T) > [vmware]SSVM is not getting created if one host down from a cluster > --- > > Key: CLOUDSTACK-4578 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4578 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: VMware >Affects Versions: 4.2.0 > Environment: Vmware > 4.2.-forward >Reporter: Rayees Namathponnan >Assignee: Kelven Yang >Priority: Critical > Fix For: 4.3.0 > > Attachments: CLOUDSTACK-4578.rar > > > Steps to reproduce > Step 1 : Create vmware advanced zone with 2 host in a cluster (HA not > enabled ) > Step 2 : Check SSVM, in which host is running > Step 3 : Shutdown the host, in where SSVM is running > Expected Result > > New SSVM should be created on second host (Running Host) > Actual result > -- > SSVM is not getting created on second host; > Work around > -- > You need to force fully stop SSVM trough API, then new SSVM gets created on > second host > We need to document this -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Commented] (CLOUDSTACK-4578) [vmware]SSVM is not getting created if one host down from a cluster
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13850114#comment-13850114 ] Damodar Reddy T commented on CLOUDSTACK-4578: - Assigning it to Kelven as it get fixed as part of vm sync feature > [vmware]SSVM is not getting created if one host down from a cluster > --- > > Key: CLOUDSTACK-4578 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4578 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: VMware >Affects Versions: 4.2.0 > Environment: Vmware > 4.2.-forward >Reporter: Rayees Namathponnan >Assignee: Kelven Yang >Priority: Critical > Fix For: 4.3.0 > > Attachments: CLOUDSTACK-4578.rar > > > Steps to reproduce > Step 1 : Create vmware advanced zone with 2 host in a cluster (HA not > enabled ) > Step 2 : Check SSVM, in which host is running > Step 3 : Shutdown the host, in where SSVM is running > Expected Result > > New SSVM should be created on second host (Running Host) > Actual result > -- > SSVM is not getting created on second host; > Work around > -- > You need to force fully stop SSVM trough API, then new SSVM gets created on > second host > We need to document this -- This message was sent by Atlassian JIRA (v6.1.4#6159)
