date:20140821

shweta agarwal created CLOUDSTACK-7382:
--

 Summary: [LXC] [UI] remove non linux based os from dropdown of 
register templates
 Key: CLOUDSTACK-7382
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7382
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: KVM, UI
Affects Versions: 4.5.0
Reporter: shweta agarwal
 Fix For: 4.5.0


Repro steps
Try to register  rhel 7 template on rhel 7 LXC setup .

Bug:
OS types rhel 7 nos shown in UI in dropdown

We should also remove other non Linux based OS from this list in case of LXC




--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CLOUDSTACK-7351) [Automation] test_02_deploy_ha_vm_from_iso test case fails during VM deploy

2014-08-21 Thread Harikrishna Patnala (JIRA)


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14105114#comment-14105114
 ] 

Harikrishna Patnala commented on CLOUDSTACK-7351:
-

I saw the below commit which removes the hardcoded value 
(hypervisor=XenServer), we need to pass the hypervisortype while deploying the 
VM.

commit 2109418469e7434bfc13fce0a20d5464d0b7862f
Author: Gaurav Aradhye gaurav.arad...@clogeny.com
Date:   Tue Aug 5 14:04:19 2014 +0530

Fixed Marvin Issue: Hypervisor value was hardcoded to XenServer while 
deploying VM if not specified

 [Automation] test_02_deploy_ha_vm_from_iso test case fails during VM deploy 
 

 Key: CLOUDSTACK-7351
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7351
 Project: CloudStack
  Issue Type: Test
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Management Server
Affects Versions: 4.5.0
 Environment: KVM (RHEL 6.3)
Reporter: Rayees Namathponnan
Assignee: Girish Shilamkar
Priority: Critical
 Fix For: 4.5.0

 Attachments: CLOUDSTACK-7351.rar


 This issue observed while running the test case 
 integration.component.test_stopped_vm.TestDeployHaEnabledVM.test_02_deploy_ha_vm_from_iso
 This test case deploying VM with below command 
 2014-08-14 15:59:45,255 DEBUG [c.c.a.ApiServlet] 
 (catalina-exec-10:ctx-4e4260d3) ===START===  10.223.240.194 -- GET  
 account=test-TestVMAcc
 ountLimit-test_02_deploy_ha_vm_from_iso-AYL50Ydomainid=8b53537a-23f9-11e4-9ac6-1a6f7bb0d0a8displayname=testserversignature=4xBMTxK5iiaze
 Fgwm2GisNo1SvM%3Dzoneid=a99226f1-d924-4156-8157-90bec0fa6579apiKey=uBqUNp_2XuCg6uwv_LMLO2W6drySk_RYAiVlcdSda1yBfLTiC2SAlFk2LX9HLLpPkAs0zo
 TzASxzSN0OSUnfoQstartvm=Truetemplateid=5cc1e055-5f49-4f12-91da-d01bf7ee509ccommand=deployVirtualMachineresponse=jsondiskofferingid=543
 e345e-645a-4bf9-bd4e-af1db46470e7serviceofferingid=db22034a-1bdd-494f-9627-fb6fd4e16585
 This deployment failed with below error 
 2014-08-14 15:59:45,353 DEBUG [o.a.c.e.o.NetworkOrchestrator] 
 (catalina-exec-10:ctx-4e4260d3 ctx-b9541cb6 ctx-d0edfeec) Releasing lock for 
 Acct[76597f29-a3e7-41a8-abc7-1cef552cf748-test-TestVMAccountLimit-test_02_deploy_ha_vm_from_iso-AYL50Y]
 2014-08-14 15:59:45,388 INFO  [c.c.a.ApiServer] 
 (catalina-exec-10:ctx-4e4260d3 ctx-b9541cb6 ctx-d0edfeec) hypervisor 
 parameter is needed to deploy VM or the hypervisor parameter value passed is 
 invalid
 Is it required to pass hypervisor type ? 



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Assigned] (CLOUDSTACK-7364) NetScaler won't create the Public VLAN and Bind the IP to it

2014-08-21 Thread Rajesh Battala (JIRA)


 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rajesh Battala reassigned CLOUDSTACK-7364:
--

Assignee: Rajesh Battala

 NetScaler won't create the Public VLAN and Bind the IP to it
 

 Key: CLOUDSTACK-7364
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7364
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
Affects Versions: 4.3.0, 4.4.0, 4.4.1
Reporter: Francois Gaudreault
Assignee: Rajesh Battala
Priority: Critical
 Attachments: management-server.log.debug.gz


 When adding a Load Balancing rule with the NetScaler, the provider will tag 
 and bind the private IP to the appropriate interface. However, the behaviour 
 for the Public Interface is different. It simply adds the IP untagged on all 
 interfaces. This is wrong.
 The public VLAN should be tagged, and the VIP bound to the right VLAN tag to 
 avoid unnecessary ARP on other VLANs.
 NS Version tested: 123,11, 127.10, 128.8



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Assigned] (CLOUDSTACK-6998) Integration with external DNS Provider (like Bind, PowerDNS)


 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rohit Yadav reassigned CLOUDSTACK-6998:
---

Assignee: Rohit Yadav

 Integration with external DNS Provider (like Bind, PowerDNS)
 

 Key: CLOUDSTACK-6998
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6998
 Project: CloudStack
  Issue Type: New Feature
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Management Server
Affects Versions: 4.3.0
Reporter: Silvano Buback
Assignee: Rohit Yadav
  Labels: dns, features
 Fix For: 4.5.0


 When deploying Advanced Networks, Virtual Routers are used to isolate 
 networks and provide DNS service for all machines inside each network. While 
 this approach is better for keeping networks more secure and self-contained, 
 it imposes a challenge when machines need to translate names that belong to 
 machines from another network, i.e. machine in network A needs to find the IP 
 address of a machine in network B.
 A common solution for this problem is to make sure the Virtual Router from 
 network B has its name translated from network A, but this does not scale to 
 a corporate network, where you need to translate domain names of every 
 machine from every network.
 We tackled this problem by using a centralized DNS server, which is external 
 to all networks in Cloudstack. That way, every machine is registered in that 
 server and every other machine can translate its name by accessing that 
 server as well. This server can run any known enterprise DNS server, such as 
 Bind or PowerDNS, and provide its services through an external API.
 This proposal includes both a DNS API to be run in a DNS server and a plugin 
 designed for integrating virtual machines and virtual networks in Cloudstack 
 with DNS API.
 I put design document in wiki 
 https://cwiki.apache.org/confluence/display/CLOUDSTACK/Bind+and+PowerDNS+integration+by+Globo+DNSAPI.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Resolved] (CLOUDSTACK-6998) Integration with external DNS Provider (like Bind, PowerDNS)

2014-08-21 Thread ASF subversion and git services (JIRA)

[
https://issues.apache.org/jira/browse/CLOUDSTACK-6998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Rohit Yadav resolved CLOUDSTACK-6998.
-

Resolution: Fixed

Tested on latest master, it builds cleanly with unit tests and patch applied
cleanly too. Tested to work against simulator.

I'm going ahead to merge it now on master, further issues can be address later
if found against using a real host. Accepting the review request:
https://reviews.apache.org/r/24611/

Thanks to everyone involved on this feature.

Integration with external DNS Provider (like Bind, PowerDNS)

Key: CLOUDSTACK-6998
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6998
Project: CloudStack
Issue Type: New Feature
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Management Server
Affects Versions: 4.3.0
Reporter: Silvano Buback
Assignee: Rohit Yadav
Labels: dns, features
Fix For: 4.5.0

When deploying Advanced Networks, Virtual Routers are used to isolate
networks and provide DNS service for all machines inside each network. While
this approach is better for keeping networks more secure and self-contained,
it imposes a challenge when machines need to translate names that belong to
machines from another network, i.e. machine in network A needs to find the IP
address of a machine in network B.
A common solution for this problem is to make sure the Virtual Router from
network B has its name translated from network A, but this does not scale to
a corporate network, where you need to translate domain names of every
machine from every network.
We tackled this problem by using a centralized DNS server, which is external
to all networks in Cloudstack. That way, every machine is registered in that
server and every other machine can translate its name by accessing that
server as well. This server can run any known enterprise DNS server, such as
Bind or PowerDNS, and provide its services through an external API.
This proposal includes both a DNS API to be run in a DNS server and a plugin
designed for integrating virtual machines and virtual networks in Cloudstack
with DNS API.
I put design document in wiki
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Bind+and+PowerDNS+integration+by+Globo+DNSAPI.

--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CLOUDSTACK-6998) Integration with external DNS Provider (like Bind, PowerDNS)


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14105275#comment-14105275
 ] 

ASF subversion and git services commented on CLOUDSTACK-6998:
-

Commit 233445ed68e3f903367e14a277ec2a5de9597b52 in cloudstack's branch 
refs/heads/master from [~daniel.simoes]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=233445e ]

CLOUDSTACK-6998: GloboDNS, Integration with external DNS Provider

This is a feature to handle DNS entries by means of an external DNS Provider,
such as Bind. These entries include DNS domains and reverse domains, VM records
and reverse records.

For a complete description, please refer to the design document available at
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Bind+and+PowerDNS+integration+by+Globo+DNSAPI

For the discussion about this feature on the dev mailing list, please refer to
http://markmail.org/thread/fvwf36hpxotiibka

Summary:
- new Network Service Provider called GloboDNS
- new Network Element to manage network domains and VM records (entries) on an 
external API
- new Network Resource to communicate with GloboDNS (open source)
- new API command to add DNS server
- new global option to determine if this provider should override VM entries on 
external DNS server
- changes in UI to include GloboDNS in Providers list

Signed-off-by: Rohit Yadav rohit.ya...@shapeblue.com


 Integration with external DNS Provider (like Bind, PowerDNS)
 

 Key: CLOUDSTACK-6998
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6998
 Project: CloudStack
  Issue Type: New Feature
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Management Server
Affects Versions: 4.3.0
Reporter: Silvano Buback
Assignee: Rohit Yadav
  Labels: dns, features
 Fix For: 4.5.0


 When deploying Advanced Networks, Virtual Routers are used to isolate 
 networks and provide DNS service for all machines inside each network. While 
 this approach is better for keeping networks more secure and self-contained, 
 it imposes a challenge when machines need to translate names that belong to 
 machines from another network, i.e. machine in network A needs to find the IP 
 address of a machine in network B.
 A common solution for this problem is to make sure the Virtual Router from 
 network B has its name translated from network A, but this does not scale to 
 a corporate network, where you need to translate domain names of every 
 machine from every network.
 We tackled this problem by using a centralized DNS server, which is external 
 to all networks in Cloudstack. That way, every machine is registered in that 
 server and every other machine can translate its name by accessing that 
 server as well. This server can run any known enterprise DNS server, such as 
 Bind or PowerDNS, and provide its services through an external API.
 This proposal includes both a DNS API to be run in a DNS server and a plugin 
 designed for integrating virtual machines and virtual networks in Cloudstack 
 with DNS API.
 I put design document in wiki 
 https://cwiki.apache.org/confluence/display/CLOUDSTACK/Bind+and+PowerDNS+integration+by+Globo+DNSAPI.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CLOUDSTACK-7324) listAsyncJobs returns jobs with no cmd

2014-08-21 Thread Koushik Das (JIRA)

[
https://issues.apache.org/jira/browse/CLOUDSTACK-7324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14105284#comment-14105284
]

Koushik Das commented on CLOUDSTACK-7324:
-

As part of the job framework changes, a new type of internal job VmWork got
introduced. This is reusing the same async_job table which used to store only
the async api jobs previously. This additional data has resulted in the issue
described.

Possible solution - add a new filter parameter 'jobType'. This should be
defaulted to async api job to keep the old behaviour.

listAsyncJobs returns jobs with no cmd
--

Key: CLOUDSTACK-7324
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7324
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: API
Affects Versions: 4.4.0
Reporter: Brian Angus
Priority: Minor

when running listAsyncJobs it will return jobids that do not have a cmd.
Like this:{code}
{
accountid: 72e70a88-18d8-11e4-98d6-5254004eff4f,
userid: 72e71cf8-18d8-11e4-98d6-5254004eff4f,
jobstatus: 0,
jobprocstatus: 0,
jobresultcode: 0,
created: 2014-08-07T10:51:43-0600,
jobid: d17b557b-e36c-4f1e-badd-2013b1eb3af1
},
{code}
jobstatus,jobprocstataus, and jobresultcode are always 0.
These appear to be internal threads to cloudstack and not related to any user
submitted jobs.
They do have an entry in the async_job table but provide no useful data in
the listAsyncJobs API call.

--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CLOUDSTACK-6099) live migration is failing for vm deployed using dynaic compute offerings with NPE;unhandled exception executing api command: findHostsForMigration java.lang.NullPoin


 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6099?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rohit Yadav updated CLOUDSTACK-6099:


Fix Version/s: 4.4.1
   4.3.1
   4.5.0

 live migration is failing for vm deployed using dynaic compute offerings with 
 NPE;unhandled exception executing api command: findHostsForMigration 
 java.lang.NullPointerException
 -

 Key: CLOUDSTACK-6099
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6099
 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, 4.4.0, 4.3.1, 4.4.1
Reporter: Bharat Kumar
Assignee: Bharat Kumar
 Fix For: 4.5.0, 4.3.1, 4.4.1


 Steps to reproduce
 ===
 1-Prepare CS setup with xen 6.2 ,two host in a cluster
 2-create a custom service offering
 3-deploy a vm with custom service offering
 4-try to migrate vm
 Expected
 =
 vm should get migrate successfully
 Actual
 ==
 Migrate vm is failing with NPE
 observation
 ===
 migrate vm is working fine for vms deployed with regular compute offering
 Log
 ===
 2014-02-03 10:07:25,229 DEBUG [c.c.s.StorageManagerImpl] 
 (catalina-exec-16:ctx-fca502c2 ctx-cb0c10a8) Checking pool: 1 for volume 
 allocation [Vol[11|vm=8|ROOT]], maxSize : 11804569632768, totalAllocatedSize 
 : 115238502400, askingSize : 0, allocated disable threshold: 0.85
 2014-02-03 10:07:25,230 DEBUG [o.a.c.s.a.ClusterScopeStoragePoolAllocator] 
 (catalina-exec-16:ctx-fca502c2 ctx-cb0c10a8) ClusterScopeStoragePoolAllocator 
 returning 1 suitable storage pools
 2014-02-03 10:07:25,234 DEBUG [c.c.a.m.a.i.FirstFitAllocator] 
 (catalina-exec-16:ctx-fca502c2 ctx-cb0c10a8) FirstFitAllocator has 1 hosts to 
 check for allocation: [Host[-4-Routing]]
 2014-02-03 10:07:25,237 DEBUG [c.c.a.m.a.i.FirstFitAllocator] 
 (catalina-exec-16:ctx-fca502c2 ctx-cb0c10a8) Found 1 hosts for allocation 
 after prioritization: [Host[-4-Routing]]
 2014-02-03 10:07:25,238 ERROR [c.c.a.ApiServer] 
 (catalina-exec-16:ctx-fca502c2 ctx-cb0c10a8) unhandled exception executing 
 api command: findHostsForMigration
 java.lang.NullPointerException
 at 
 com.cloud.agent.manager.allocator.impl.FirstFitAllocator.allocateTo(FirstFitAllocator.java:267)
 at 
 com.cloud.agent.manager.allocator.impl.FirstFitAllocator.allocateTo(FirstFitAllocator.java:238)
 at 
 com.cloud.server.ManagementServerImpl.listHostsForMigrationOfVM(ManagementServerImpl.java:1195)
 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 $Proxy210.listHostsForMigrationOfVM(Unknown Source)
 at 
 org.apache.cloudstack.api.command.admin.host.FindHostsForMigrationCmd.execute(FindHostsForMigrationCmd.java:75)
 at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:161)
 at com.cloud.api.ApiServer.queueCommand(ApiServer.java:531)
 at com.cloud.api.ApiServer.handleRequest(ApiServer.java:374)
 at com.cloud.api.ApiServlet.processRequestInContext(ApiServlet.java:322)
 at com.cloud.api.ApiServlet.access$000(ApiServlet.java:52)
 at com.cloud.api.ApiServlet$1.run(ApiServlet.java:114)
 at 
 org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
 at 
 org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
 at 
 org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
 at com.cloud.api.ApiServlet.processRequest(ApiServlet.java:111)
 at com.cloud.api.ApiServlet.doGet(ApiServlet.java:73)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:617)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
 at

[jira] [Updated] (CLOUDSTACK-6099) live migration is failing for vm deployed using dynaic compute offerings with NPE;unhandled exception executing api command: findHostsForMigration java.lang.NullPoin


 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6099?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rohit Yadav updated CLOUDSTACK-6099:


Affects Version/s: 4.4.1
   4.3.1
   4.4.0
   4.3.0

 live migration is failing for vm deployed using dynaic compute offerings with 
 NPE;unhandled exception executing api command: findHostsForMigration 
 java.lang.NullPointerException
 -

 Key: CLOUDSTACK-6099
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6099
 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, 4.4.0, 4.3.1, 4.4.1
Reporter: Bharat Kumar
Assignee: Bharat Kumar
 Fix For: 4.5.0, 4.3.1, 4.4.1


 Steps to reproduce
 ===
 1-Prepare CS setup with xen 6.2 ,two host in a cluster
 2-create a custom service offering
 3-deploy a vm with custom service offering
 4-try to migrate vm
 Expected
 =
 vm should get migrate successfully
 Actual
 ==
 Migrate vm is failing with NPE
 observation
 ===
 migrate vm is working fine for vms deployed with regular compute offering
 Log
 ===
 2014-02-03 10:07:25,229 DEBUG [c.c.s.StorageManagerImpl] 
 (catalina-exec-16:ctx-fca502c2 ctx-cb0c10a8) Checking pool: 1 for volume 
 allocation [Vol[11|vm=8|ROOT]], maxSize : 11804569632768, totalAllocatedSize 
 : 115238502400, askingSize : 0, allocated disable threshold: 0.85
 2014-02-03 10:07:25,230 DEBUG [o.a.c.s.a.ClusterScopeStoragePoolAllocator] 
 (catalina-exec-16:ctx-fca502c2 ctx-cb0c10a8) ClusterScopeStoragePoolAllocator 
 returning 1 suitable storage pools
 2014-02-03 10:07:25,234 DEBUG [c.c.a.m.a.i.FirstFitAllocator] 
 (catalina-exec-16:ctx-fca502c2 ctx-cb0c10a8) FirstFitAllocator has 1 hosts to 
 check for allocation: [Host[-4-Routing]]
 2014-02-03 10:07:25,237 DEBUG [c.c.a.m.a.i.FirstFitAllocator] 
 (catalina-exec-16:ctx-fca502c2 ctx-cb0c10a8) Found 1 hosts for allocation 
 after prioritization: [Host[-4-Routing]]
 2014-02-03 10:07:25,238 ERROR [c.c.a.ApiServer] 
 (catalina-exec-16:ctx-fca502c2 ctx-cb0c10a8) unhandled exception executing 
 api command: findHostsForMigration
 java.lang.NullPointerException
 at 
 com.cloud.agent.manager.allocator.impl.FirstFitAllocator.allocateTo(FirstFitAllocator.java:267)
 at 
 com.cloud.agent.manager.allocator.impl.FirstFitAllocator.allocateTo(FirstFitAllocator.java:238)
 at 
 com.cloud.server.ManagementServerImpl.listHostsForMigrationOfVM(ManagementServerImpl.java:1195)
 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 $Proxy210.listHostsForMigrationOfVM(Unknown Source)
 at 
 org.apache.cloudstack.api.command.admin.host.FindHostsForMigrationCmd.execute(FindHostsForMigrationCmd.java:75)
 at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:161)
 at com.cloud.api.ApiServer.queueCommand(ApiServer.java:531)
 at com.cloud.api.ApiServer.handleRequest(ApiServer.java:374)
 at com.cloud.api.ApiServlet.processRequestInContext(ApiServlet.java:322)
 at com.cloud.api.ApiServlet.access$000(ApiServlet.java:52)
 at com.cloud.api.ApiServlet$1.run(ApiServlet.java:114)
 at 
 org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
 at 
 org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
 at 
 org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
 at com.cloud.api.ApiServlet.processRequest(ApiServlet.java:111)
 at com.cloud.api.ApiServlet.doGet(ApiServlet.java:73)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:617)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
 at

[jira] [Updated] (CLOUDSTACK-6099) live migration is failing for vm deployed using dynaic compute offerings with NPE;unhandled exception executing api command: findHostsForMigration java.lang.NullPoin


 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6099?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rohit Yadav updated CLOUDSTACK-6099:


Priority: Critical  (was: Major)

 live migration is failing for vm deployed using dynaic compute offerings with 
 NPE;unhandled exception executing api command: findHostsForMigration 
 java.lang.NullPointerException
 -

 Key: CLOUDSTACK-6099
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6099
 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, 4.4.0, 4.3.1, 4.4.1
Reporter: Bharat Kumar
Assignee: Bharat Kumar
Priority: Critical
 Fix For: 4.5.0, 4.3.1, 4.4.1


 Steps to reproduce
 ===
 1-Prepare CS setup with xen 6.2 ,two host in a cluster
 2-create a custom service offering
 3-deploy a vm with custom service offering
 4-try to migrate vm
 Expected
 =
 vm should get migrate successfully
 Actual
 ==
 Migrate vm is failing with NPE
 observation
 ===
 migrate vm is working fine for vms deployed with regular compute offering
 Log
 ===
 2014-02-03 10:07:25,229 DEBUG [c.c.s.StorageManagerImpl] 
 (catalina-exec-16:ctx-fca502c2 ctx-cb0c10a8) Checking pool: 1 for volume 
 allocation [Vol[11|vm=8|ROOT]], maxSize : 11804569632768, totalAllocatedSize 
 : 115238502400, askingSize : 0, allocated disable threshold: 0.85
 2014-02-03 10:07:25,230 DEBUG [o.a.c.s.a.ClusterScopeStoragePoolAllocator] 
 (catalina-exec-16:ctx-fca502c2 ctx-cb0c10a8) ClusterScopeStoragePoolAllocator 
 returning 1 suitable storage pools
 2014-02-03 10:07:25,234 DEBUG [c.c.a.m.a.i.FirstFitAllocator] 
 (catalina-exec-16:ctx-fca502c2 ctx-cb0c10a8) FirstFitAllocator has 1 hosts to 
 check for allocation: [Host[-4-Routing]]
 2014-02-03 10:07:25,237 DEBUG [c.c.a.m.a.i.FirstFitAllocator] 
 (catalina-exec-16:ctx-fca502c2 ctx-cb0c10a8) Found 1 hosts for allocation 
 after prioritization: [Host[-4-Routing]]
 2014-02-03 10:07:25,238 ERROR [c.c.a.ApiServer] 
 (catalina-exec-16:ctx-fca502c2 ctx-cb0c10a8) unhandled exception executing 
 api command: findHostsForMigration
 java.lang.NullPointerException
 at 
 com.cloud.agent.manager.allocator.impl.FirstFitAllocator.allocateTo(FirstFitAllocator.java:267)
 at 
 com.cloud.agent.manager.allocator.impl.FirstFitAllocator.allocateTo(FirstFitAllocator.java:238)
 at 
 com.cloud.server.ManagementServerImpl.listHostsForMigrationOfVM(ManagementServerImpl.java:1195)
 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 $Proxy210.listHostsForMigrationOfVM(Unknown Source)
 at 
 org.apache.cloudstack.api.command.admin.host.FindHostsForMigrationCmd.execute(FindHostsForMigrationCmd.java:75)
 at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:161)
 at com.cloud.api.ApiServer.queueCommand(ApiServer.java:531)
 at com.cloud.api.ApiServer.handleRequest(ApiServer.java:374)
 at com.cloud.api.ApiServlet.processRequestInContext(ApiServlet.java:322)
 at com.cloud.api.ApiServlet.access$000(ApiServlet.java:52)
 at com.cloud.api.ApiServlet$1.run(ApiServlet.java:114)
 at 
 org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
 at 
 org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
 at 
 org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
 at com.cloud.api.ApiServlet.processRequest(ApiServlet.java:111)
 at com.cloud.api.ApiServlet.doGet(ApiServlet.java:73)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:617)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
 at

[jira] [Created] (CLOUDSTACK-7383) [LXC][UI] dont show vm snapshot button in UI

shweta agarwal created CLOUDSTACK-7383:
--

 Summary: [LXC][UI] dont show vm snapshot button in UI
 Key: CLOUDSTACK-7383
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7383
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: UI
Affects Versions: 4.5.0
Reporter: shweta agarwal
 Fix For: 4.5.0
 Attachments: vmsnap.png

Repro steps:

Vm snapshot is not supported in LXC so we should not show VM  snapshot option  
in UI in instance tab , the way we do it for KVM .We dont show VM  snapshot 
button in cae of KVM vm.

Attaching snapshot



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CLOUDSTACK-7383) [LXC][UI] dont show vm snapshot button in UI


 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

shweta agarwal updated CLOUDSTACK-7383:
---

Attachment: vmsnap.png

 [LXC][UI] dont show vm snapshot button in UI
 

 Key: CLOUDSTACK-7383
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7383
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: UI
Affects Versions: 4.5.0
Reporter: shweta agarwal
 Fix For: 4.5.0

 Attachments: vmsnap.png


 Repro steps:
 Vm snapshot is not supported in LXC so we should not show VM  snapshot option 
  in UI in instance tab , the way we do it for KVM .We dont show VM  snapshot 
 button in cae of KVM vm.
 Attaching snapshot



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Created] (CLOUDSTACK-7384) [LXC][UI] show change service offering command ption only when VM is in stop state

shweta agarwal created CLOUDSTACK-7384:
--

 Summary: [LXC][UI] show change service offering command ption only 
when VM is in stop state
 Key: CLOUDSTACK-7384
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7384
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: UI
Affects Versions: 4.5.0
Reporter: shweta agarwal
 Fix For: 4.5.0


we should show change service offerings of a LXC VM in stop state in  Instance 
detail tab , the way we do it in KVM VMs.

Attaching screen shot 



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CLOUDSTACK-7384) [LXC][UI] show change service offering command ption only when VM is in stop state


 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

shweta agarwal updated CLOUDSTACK-7384:
---

Attachment: change.png

 [LXC][UI] show change service offering command ption only when VM is in stop 
 state
 --

 Key: CLOUDSTACK-7384
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7384
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: UI
Affects Versions: 4.5.0
Reporter: shweta agarwal
 Fix For: 4.5.0

 Attachments: change.png


 we should show change service offerings of a LXC VM in stop state in  
 Instance detail tab , the way we do it in KVM VMs. 
 Currently we show change service offering option in LXC VMs when VM is 
 running as well
 Attaching screen shot 



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CLOUDSTACK-7384) [LXC][UI] show change service offering command ption only when VM is in stop state

2014-08-21 Thread ASF subversion and git services (JIRA)


 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

shweta agarwal updated CLOUDSTACK-7384:
---

Description: 
we should show change service offerings of a LXC VM in stop state in  Instance 
detail tab , the way we do it in KVM VMs. 
Currently we show change service offering option in LXC VMs when VM is running 
as well

Attaching screen shot 

  was:
we should show change service offerings of a LXC VM in stop state in  Instance 
detail tab , the way we do it in KVM VMs.

Attaching screen shot 


 [LXC][UI] show change service offering command ption only when VM is in stop 
 state
 --

 Key: CLOUDSTACK-7384
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7384
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: UI
Affects Versions: 4.5.0
Reporter: shweta agarwal
 Fix For: 4.5.0

 Attachments: change.png


 we should show change service offerings of a LXC VM in stop state in  
 Instance detail tab , the way we do it in KVM VMs. 
 Currently we show change service offering option in LXC VMs when VM is 
 running as well
 Attaching screen shot 



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CLOUDSTACK-7349) [Automation] CloudRuntimeException with stacktrace in MS log


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14105334#comment-14105334
 ] 

ASF subversion and git services commented on CLOUDSTACK-7349:
-

Commit 73d53e5f43dcb3a3caa5025fea2b07a74d55 in cloudstack's branch 
refs/heads/master from Jayapal
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=73d53e5 ]

CLOUDSTACK-7349: Catching exception in API assigntoloadbalancerrule command


 [Automation] CloudRuntimeException  with stacktrace in  MS log
 --

 Key: CLOUDSTACK-7349
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7349
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Management Server
Affects Versions: 4.5.0
Reporter: Rayees Namathponnan
Assignee: Jayapal Reddy
Priority: Critical
 Fix For: 4.5.0


 This issue observed during automation run, there are many InvalidParameter 
 Exception with stacktrace, this should be handled properly 
 2014-08-14 00:34:16,190 ERROR [c.c.a.ApiAsyncJobDispatcher] 
 (API-Job-Executor-96:ctx-7c9884ce job-6881) Unexpected exception while 
 executin
 g 
 org.apache.cloudstack.api.command.user.loadbalancer.AssignToLoadBalancerRuleCmd
 com.cloud.utils.exception.CloudRuntimeException: Failed to add specified 
 loadbalancerruleid for vms [973]
 at 
 com.cloud.network.lb.LoadBalancingRulesManagerImpl.assignToLoadBalancer(LoadBalancingRulesManagerImpl.java:1139)
 at sun.reflect.GeneratedMethodAccessor774.invoke(Unknown Source)
 at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 at java.lang.reflect.Method.invoke(Method.java:606)
 at 
 org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317)
 at 
 org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
 at 
 org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
 at 
 org.apache.cloudstack.network.contrail.management.EventUtils$EventInterceptor.invoke(EventUtils.java:106)
 at 
 org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161)
 at 
 com.cloud.event.ActionEventInterceptor.invoke(ActionEventInterceptor.java:51)
 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 com.sun.proxy.$Proxy137.assignToLoadBalancer(Unknown Source)
 at 
 org.apache.cloudstack.api.command.user.loadbalancer.AssignToLoadBalancerRuleCmd.execute(AssignToLoadBalancerRuleCmd.java:169)
 at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:141)
 at 
 com.cloud.api.ApiAsyncJobDispatcher.runJob(ApiAsyncJobDispatcher.java:108)
 at 
 org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:503)
 at 
 org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49)
 at 
 org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
 at 
 org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
 at 
 org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
 at 
 org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46)
 at 
 org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.run(AsyncJobManagerImpl.java:460)
 at 
 java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
 at java.util.concurrent.FutureTask.run(FutureTask.java:262)
 at 
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
 at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
 at java.lang.Thread.run(Thread.java:744)
 2014-08-14 00:34:16,191 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
 (API-Job-Executor-96:ctx-7c9884ce job-6881) Complete async job-6881, 
 jobStatus: FAILED, resultCode: 530, result:

[jira] [Updated] (CLOUDSTACK-7384) [LXC][UI] show change service offering command option only when VM is in stop state

2014-08-21 Thread ASF subversion and git services (JIRA)


 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

shweta agarwal updated CLOUDSTACK-7384:
---

Summary: [LXC][UI] show change service offering command option only when VM 
is in stop state  (was: [LXC][UI] show change service offering command ption 
only when VM is in stop state)

 [LXC][UI] show change service offering command option only when VM is in stop 
 state
 ---

 Key: CLOUDSTACK-7384
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7384
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: UI
Affects Versions: 4.5.0
Reporter: shweta agarwal
 Fix For: 4.5.0

 Attachments: change.png


 we should show change service offerings of a LXC VM in stop state in  
 Instance detail tab , the way we do it in KVM VMs. 
 Currently we show change service offering option in LXC VMs when VM is 
 running as well
 Attaching screen shot 



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CLOUDSTACK-6892) Database HA Config prevents mgmt server from starting


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14105381#comment-14105381
 ] 

ASF subversion and git services commented on CLOUDSTACK-6892:
-

Commit b4601be4bf782772bb0b05d38a276d2ba3beb002 in cloudstack's branch 
refs/heads/4.4 from [~htrippaers]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=b4601be ]

CLOUDSTACK-6892 Create separate package for the mysql HA component

(cherry picked from commit 539db08956eff322efd11771d46d29df0c7289b2)
Signed-off-by: Rohit Yadav rohit.ya...@shapeblue.com

Conflicts:
packaging/centos63/cloud.spec


 Database HA Config prevents mgmt server from starting
 -

 Key: CLOUDSTACK-6892
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6892
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Install and Setup, Management Server
Affects Versions: Future, 4.3.0, 4.4.0
 Environment: MySQL configured for DB HA
Reporter: Adrian Lewis
Assignee: Hugo Trippaers
Priority: Critical

 When configuring the database HA feature introduced in 4.3, the manangement 
 server fails to create the DB connection due to the mysql connector jar being 
 loaded using tomcat's common class loader but the 
 cloud-plugin-database-mysqlha-4.3.0.jar is loaded by the webapp class 
 loader.
 The cloud-plugin-database-mysqlha-4.3.0.jar needs to also be loaded from the 
 common class loader instead of webapp class loader.
 Fix is to declare the cloud-plugin-database-mysqlha-4.3.0.jar under the 
 common.loader section in /etc/cloudstack/management/catalina.properties.
 Only tested using a fresh install on Centos 6.5 and the public repo packages.
 Manual fix provided by Damoder Reddy in users mailing list: Looks like we 
 did not change the catalina.properties while refactoring out the mysql 
 connector part



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CLOUDSTACK-7038) MySQL Client RPMs not a dependency in CS Packages

2014-08-21 Thread ASF subversion and git services (JIRA)


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14105380#comment-14105380
 ] 

ASF subversion and git services commented on CLOUDSTACK-7038:
-

Commit 6a26e77514b955e5c9cbb00e51183ec74d3887a3 in cloudstack's branch 
refs/heads/4.4 from [~rohit.ya...@shapeblue.com]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=6a26e77 ]

CLOUDSTACK-7038: Add mysql client dependency for mgmt server, rpms and debs

Signed-off-by: Rohit Yadav rohit.ya...@shapeblue.com


 MySQL Client RPMs not a dependency in CS Packages
 -

 Key: CLOUDSTACK-7038
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7038
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Install and Setup
Affects Versions: Future, 4.3.0, 4.4.0
 Environment: Centos or RPM-based distro where MySQL installed on 
 separate server
Reporter: Adrian Lewis
Assignee: Rohit Yadav
Priority: Minor

 Perhaps simple enough to fix in docs but if anyone is installing from 
 packages on Centos, the 'mysql' client package is not installed as a 
 dependency which it should be. Likely not picked up in testing as those 
 installing the 'mysql-server' package will automatically get the client part 
 but for those using MySQL on a separate server, the management server will 
 not start.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CLOUDSTACK-6508) impossible to list projects from API with domainid set

2014-08-21 Thread ASF subversion and git services (JIRA)


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-6508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14105382#comment-14105382
 ] 

ASF subversion and git services commented on CLOUDSTACK-6508:
-

Commit 6e20058fb7fd482b4bbcd30f3c78aaa59c6c09d3 in cloudstack's branch 
refs/heads/4.4 from [~saksham]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=6e20058 ]

CLOUDSTACK-6508: impossible to list projects from API with domainid set

(cherry picked from commit 19b72d6cf57665fc3935fdd7f7e9dad9117f0616)
Signed-off-by: Rohit Yadav rohit.ya...@shapeblue.com


 impossible to list projects from API with domainid set
 --

 Key: CLOUDSTACK-6508
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6508
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: API
Affects Versions: 4.2.1, 4.3.0
Reporter: ivan derbenev
Assignee: Saksham Srivastava
  Labels: S1

 Hello, it's my first issue ever, so sorry if i made smth wrong.
 Today we was trying to setup jCloud module for jenkins, and stuck with error.
 it throws GET request:
 /client/api/?response=jsoncommand=listProjectslistAll=trueaccount=jenkinsdomainid=%domainid%apiKey=%apikey%signature=%sig%
 and returns error:
 Can't list domain id= 1 projects; unauthorized
 i have only one ROOT domain, and this user belongs to this domain
 if i go into cloudmonkey and call:
 list projects listall=true account=jenkins domainid=%domainid%
 it throws error too. If i don't use domainid attribute, query works properly
 if i call any other api function with domainid attribute, query works 
 properly
 i looked into cloudstack sources and found this function:
 https://github.com/apache/cloudstack/blob/master/server/src/com/cloud/api/query/QueryManagerImpl.java
 listProjectsInternal function
 line 1309
  if (domainId != null  domainId.equals(caller.getDomainId())) {
 throw new PermissionDeniedException(Can't list domain id=  
 + domainId +  projects; unauthorized);
 }
 so if i understand it well it check whether i provide a domainid and if user 
 belongs to domain with this domainid it throws exception
 I don't think this is how this API function should work.
 Am i mistaken anywhere or this is really a bug?



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Created] (CLOUDSTACK-7385) integration.component.test_persistent_networks.TestRestartPersistentNetwork.test_cleanup_persistent_network_1_true

2014-08-21 Thread Gaurav Aradhye (JIRA)

Gaurav Aradhye created CLOUDSTACK-7385:
--

 Summary: 
integration.component.test_persistent_networks.TestRestartPersistentNetwork.test_cleanup_persistent_network_1_true
 Key: CLOUDSTACK-7385
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7385
 Project: CloudStack
  Issue Type: Test
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Automation
Affects Versions: 4.5.0
Reporter: Gaurav Aradhye
Assignee: Gaurav Aradhye
 Fix For: 4.5.0


integration.component.test_persistent_networks.TestRestartPersistentNetwork.test_cleanup_persistent_network_1_true
 failed while creating LB rule.

The network offering used does not have anything for service provider of LB.

Execute cmd: createloadbalancerrule failed, due to: errorCode: 530, 
errorText:Failed to create load balancer rule: SSH
  begin captured stdout  -
=== TestName: test_cleanup_persistent_network_1_true | Status : EXCEPTION ===


-  end captured stdout  --
  begin captured logging  
test_project_operations 
(integration.component.test_persistent_networks.TestProjectAccountOperations): 
DEBUG: Payload: {'signature': 'NkvfIxXjm37fMP1qzpTof19L5uM=', 'apiKey': 
u'vw7clWnz7nCvrzKW0XaCorzOi1Tg4-U0gv0D-tpjtBaP0CoaV5BVER0Z710FgwR6yUiReoWg56bJJpJkHIKJyA',
 'command': 'deleteServiceOffering', 'id': 
u'455dca18-7b5f-454c-b1e4-276713a1afd6', 'response': 'json'}
test_project_operations 
(integration.component.test_persistent_networks.TestProjectAccountOperations): 
DEBUG: Sending GET Cmd : deleteServiceOffering===
requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection 
(1): 10.223.49.197
requests.packages.urllib3.connectionpool: DEBUG: GET 
/client/api?response=jsonapiKey=vw7clWnz7nCvrzKW0XaCorzOi1Tg4-U0gv0D-tpjtBaP0CoaV5BVER0Z710FgwR6yUiReoWg56bJJpJkHIKJyAcommand=deleteServiceOfferingid=455dca18-7b5f-454c-b1e4-276713a1afd6signature=NkvfIxXjm37fMP1qzpTof19L5uM%3D
 HTTP/1.1 200 60
test_project_operations 
(integration.component.test_persistent_networks.TestProjectAccountOperations): 
DEBUG: Response : {success : u'true'}
test_project_operations 
(integration.component.test_persistent_networks.TestProjectAccountOperations): 
DEBUG: Payload: {'signature': 'QW8yNTjMSoL0AF0aTS1VwHK7ZFE=', 'apiKey': 
u'vw7clWnz7nCvrzKW0XaCorzOi1Tg4-U0gv0D-tpjtBaP0CoaV5BVER0Z710FgwR6yUiReoWg56bJJpJkHIKJyA',
 'command': 'deleteNetworkOffering', 'id': 
u'acd392e4-438e-40c0-a068-91f3c8934dac', 'response': 'json'}
test_project_operations 
(integration.component.test_persistent_networks.TestProjectAccountOperations): 
DEBUG: Sending GET Cmd : deleteNetworkOffering===
requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection 
(1): 10.223.49.197
requests.packages.urllib3.connectionpool: DEBUG: GET 
/client/api?response=jsonapiKey=vw7clWnz7nCvrzKW0XaCorzOi1Tg4-U0gv0D-tpjtBaP0CoaV5BVER0Z710FgwR6yUiReoWg56bJJpJkHIKJyAcommand=deleteNetworkOfferingid=acd392e4-438e-40c0-a068-91f3c8934dacsignature=QW8yNTjMSoL0AF0aTS1VwHK7ZFE%3D
 HTTP/1.1 200 60
test_project_operations 
(integration.component.test_persistent_networks.TestProjectAccountOperations): 
DEBUG: Response : {success : u'true'}
test_project_operations 
(integration.component.test_persistent_networks.TestProjectAccountOperations): 
DEBUG: Payload: {'apiKey': 
u'vw7clWnz7nCvrzKW0XaCorzOi1Tg4-U0gv0D-tpjtBaP0CoaV5BVER0Z710FgwR6yUiReoWg56bJJpJkHIKJyA',
 'command': 'listDomains', 'signature': 'abp39oNvouTjuE9WsvqUW8y27O4=', 
'response': 'json'}
test_project_operations 
(integration.component.test_persistent_networks.TestProjectAccountOperations): 
DEBUG: Sending GET Cmd : listDomains===
requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection 
(1): 10.223.49.197
requests.packages.urllib3.connectionpool: DEBUG: GET 
/client/api?apiKey=vw7clWnz7nCvrzKW0XaCorzOi1Tg4-U0gv0D-tpjtBaP0CoaV5BVER0Z710FgwR6yUiReoWg56bJJpJkHIKJyAcommand=listDomainsresponse=jsonsignature=abp39oNvouTjuE9WsvqUW8y27O4%3D
 HTTP/1.1 200 986
test_project_operations 
(integration.component.test_persistent_networks.TestProjectAccountOperations): 
DEBUG: Response : [{path : u'ROOT', haschild : True, id : 
u'56509a2a-2773-11e4-a7b2-52b2d980df8a', name : u'ROOT', level : 0}, {haschild 
: False, parentdomainid : u'56509a2a-2773-11e4-a7b2-52b2d980df8a', level : 1, 
parentdomainname : u'ROOT', path : u'ROOT/Domain-CA9FGU', id : 
u'7d0c06b9-a5cd-4d21-a701-108d79a6297d', name : u'Domain-CA9FGU'}, {haschild : 
False, parentdomainid : u'56509a2a-2773-11e4-a7b2-52b2d980df8a', level : 1, 
parentdomainname : u'ROOT', path : u'ROOT/Domain-WW4234', id : 
u'6bd17fc3-345d-4f9f-bea2-6a5854aa235a', name : u'Domain-WW4234'}, {haschild : 
False, parentdomainid :

[jira] [Resolved] (CLOUDSTACK-7368) [Automation] Fix the script test_add_remove_network.py - Accounts are not cleaned up during successful test execution

2014-08-21 Thread Gaurav Aradhye (JIRA)


 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gaurav Aradhye resolved CLOUDSTACK-7368.


Resolution: Fixed

 [Automation] Fix the script test_add_remove_network.py - Accounts are not 
 cleaned up during successful test execution
 ---

 Key: CLOUDSTACK-7368
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7368
 Project: CloudStack
  Issue Type: Test
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Automation, Test
Affects Versions: 4.5.0
Reporter: Chandan Purushothama
Assignee: Gaurav Aradhye
Priority: Critical
 Fix For: 4.5.0


 Notice that the accounts are not cleaned up during successful test execution 
 in the script below.
 {Code}
 @attr(tags = [advanced])
 def test_24_add_nw_different_domain(self):
 Add network to running VM
 # 1. Create two domains
 # 2. Create network in one domain and create virtual machine in other 
 domain
 # 3. Ad isolated/shared network belonging to one domain to the vm 
 belonging to other domain
 # Validate the following:
 # 1. Adding network should fail
 network = None #The network which we are adding to the vm
 try:
 tempCleanupList = []
 self.child_domain_1 = Domain.create(self.apiclient,
 services=self.services[domain],
 parentdomainid=self.domain.id)
 tempCleanupList.append(self.child_domain_1)
 self.child_do_admin_1 = Account.create(
 self.apiclient,
 self.services[account],
 admin=True,
 domainid=self.child_domain_1.id
 )
 tempCleanupList.append(self.child_do_admin_1)
 self.child_domain_2 = Domain.create(self.apiclient,
   
 services=self.services[domain],
   parentdomainid=self.domain.id)
 tempCleanupList.append(self.child_domain_2)
 self.child_do_admin_2 = Account.create(
 self.apiclient,
 self.services[account],
 admin=True,
 domainid=self.child_domain_2.id)
 tempCleanupList.append(self.child_do_admin_2)
 except Exception as e:
 tempCleanupList.reverse()
 self.cleanup += tempCleanupList
 self.fail(e)
 ## Notice that the Accounts are not added to cleanup list to get cleaned up 
 during successful test execution
 network = 
 Network.create(self.api_client,self.services[isolated_network],self.child_do_admin_1.name,
  
 self.child_do_admin_1.domainid,networkofferingid=self.isolated_network_offering.id)
 virtual_machine = VirtualMachine.create(self.apiclient, 
 self.services[virtual_machine],accountid=self.child_do_admin_2.name,
 
 domainid=self.child_do_admin_2.domainid, 
 serviceofferingid=self.service_offering.id,
 
 mode=self.zone.networktype)
 time.sleep(self.services[sleep])
 self.debug(Trying to %s network in domain %s to a vm in domain %s, 
 This should fail %
(network.type, self.child_domain_1.name, 
 self.child_domain_2.name))
 with self.assertRaises(Exception) as e:
 virtual_machine.add_nic(self.apiclient, network.id)
 self.debug(Operation failed with exception %s % e.exception)
 return
 {Code}
 Due to the above mentioned bug, the follow error is seen:
 {Code}
 test_25_add_nw_above_account_limit 
 (test_add_remove_network.TestAddNetworkToVirtualMachine): DEBUG: 
 Sending GET Cmd : deleteServiceOffering===
 requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection 
 (1): 10.223.130.79
 requests.packages.urllib3.connectionpool: DEBUG: GET 
 /client/api?response=jsonapiKey=ZI83p8k86jxdFO75d5mjeU5qvLiMvSK2tUnhcSfQc2TDbIJWI4MuvF1w0SkSZ3RB-pykb4VhQaLUVhq6apOqogcommand=deleteServiceOfferingid=d6397b91-56a8-4bbc-94ba-2fdbf7fb4582signature=Y7VStlORyVL1MqIGfZxjvr30TJw%3D
  HTTP/1.1 200 60
 test_25_add_nw_above_account_limit 
 (test_add_remove_network.TestAddNetworkToVirtualMachine): DEBUG: Response : 
 {success : u'true'}
 test_25_add_nw_above_account_limit

[jira] [Commented] (CLOUDSTACK-7327) Failed to deploy instance when using an IP from freshly added IP pool

2014-08-21 Thread Loic Lambiel (JIRA)


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14105484#comment-14105484
 ] 

Loic Lambiel commented on CLOUDSTACK-7327:
--

Hi, the zone has been setup using the wizard (CS 4.0.0). We never used or set 
vlan tagging. We added several IP ranges using the wizard without issue on CS 
4.0.0. As far as I remember the network config hasn't changed since the initial 
setup. We upgraded to 4.3 and faced this issue on new IP pool add.

 Failed to deploy instance when using an IP from freshly added IP pool
 -

 Key: CLOUDSTACK-7327
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7327
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: KVM
Affects Versions: 4.3.0
 Environment: Cloudstack 4.3, Basic networking, KVM on ubuntu 12.04
Reporter: Loic Lambiel
Assignee: Kishan Kavala

 Hi,
 We have a case where an instance failed to deploy when it takes an IP from a 
 freshly added IP pool range.
 Our setup: Cloudstack 4.3, Basic networking, KVM on Ubuntu 12.04. Our setup 
 is running since 4.0.0.
 The workaround is to change the vlan_id field of the ip pool in the 
 cloud.vlan table from EC2://untagged to untagged
 Below the logs:
 *Management server:*
 {quote}
 ERROR [cloud.vm.VirtualMachineManagerImpl] (Job-Executor-13:ctx-3e34bc70 
 ctx-b69247df) Failed to start instance 
 VM[User|VM-fe3812d7-9d3d-49d8-9692-d9a8c976
 6c6f]
 com.cloud.utils.exception.CloudRuntimeException: Unable to get answer that is 
 of class com.cloud.agent.api.StartAnswer
 at com.cloud.agent.manager.Commands.getAnswer(Commands.java:80)
 at 
 com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:992)
 at 
 com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManagerImpl.java:761)
 at 
 com.cloud.vm.VirtualMachineManagerImpl.start(VirtualMachineManagerImpl.java:601)
 at 
 org.apache.cloudstack.engine.cloud.entity.api.VMEntityManagerImpl.deployVirtualMachine(VMEntityManagerImpl.java:228)
 at 
 org.apache.cloudstack.engine.cloud.entity.api.VirtualMachineEntityImpl.deploy(VirtualMachineEntityImpl.java:207)
 at 
 com.cloud.vm.UserVmManagerImpl.startVirtualMachine(UserVmManagerImpl.java:3581)
 at 
 com.cloud.vm.UserVmManagerImpl.startVirtualMachine(UserVmManagerImpl.java:3161)
 at 
 com.cloud.vm.UserVmManagerImpl.startVirtualMachine(UserVmManagerImpl.java:3147)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
 at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 at java.lang.reflect.Method.invoke(Method.java:606)
 at 
 org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317)
 at 
 org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
 at 
 org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
 at 
 com.cloud.event.ActionEventInterceptor.invoke(ActionEventInterceptor.java:50)
 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 com.sun.proxy.$Proxy169.startVirtualMachine(Unknown Source)
 at 
 org.apache.cloudstack.api.command.user.vm.DeployVMCmd.execute(DeployVMCmd.java:443)
 at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:161)
 at 
 com.cloud.api.ApiAsyncJobDispatcher.runJobInContext(ApiAsyncJobDispatcher.java:109)
 at 
 com.cloud.api.ApiAsyncJobDispatcher$1.run(ApiAsyncJobDispatcher.java:66)
 at 
 org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
 at 
 org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
 at 
 org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
 at 
 com.cloud.api.ApiAsyncJobDispatcher.runJob(ApiAsyncJobDispatcher.java:63)
 at

[jira] [Commented] (CLOUDSTACK-7316) hitting java.lang.reflect.InvocationTargetException while starting usage server

2014-08-21 Thread Nitin Mehta (JIRA)


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14105646#comment-14105646
 ] 

Nitin Mehta commented on CLOUDSTACK-7316:
-

Hi Shweta - I saw the logs and the lowest exception in it shows something as 
below. Do you have the 'key' file in your setup for encryption. If not can you 
do that and see if it resolves the issue ?
Meanwhile I will get instructions from Kishan to run the usage server as I dont 
know how to do it.

at java.lang.reflect.Constructor.newInstance(Constructor.java:525)
at net.sf.cglib.core.ReflectUtils.newInstance(ReflectUtils.java:228)
... 39 more
Caused by: com.cloud.utils.exception.CloudRuntimeException: key File containing 
secret key not found in the classpath: 
at 
com.cloud.utils.crypt.EncryptionSecretKeyChecker.check(EncryptionSecretKeyChecker.java:84)
at com.cloud.utils.db.DbProperties.getDbProperties(DbProperties.java:80)
at 
com.cloud.utils.db.TransactionLegacy.clinit(TransactionLegacy.java:1023)
... 50 more
12/08/2014 05:03:01 17259 jsvc.exec error: Cannot start daemon
12/08/2014 05:03:01 17258 jsvc.exec error: Service exit with a return value of 5

 hitting java.lang.reflect.InvocationTargetException while starting usage 
 server
 ---

 Key: CLOUDSTACK-7316
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7316
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Usage
Affects Versions: 4.5.0
Reporter: shweta agarwal
Assignee: Nitin Mehta
Priority: Blocker
 Fix For: 4.5.0

 Attachments: usage.tar.gz


 Repro steps:
 Install MS and usage server
 Start MS and usage server
 Bug:
 Usage server will stop after starting
 usage log shows :
 java.lang.reflect.InvocationTargetException
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
 at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 at java.lang.reflect.Method.invoke(Method.java:601)
 at 
 org.apache.commons.daemon.support.DaemonLoader.start(DaemonLoader.java:243)
 Caused by: org.springframework.beans.factory.BeanCreationException: Error 
 creating bean with name 'vmDiskUsageParser': Injection of autowired 
 dependencies failed; nested exception is 
 org.springframework.beans.factory.BeanCreationException: Could not autowire 
 field: private com.cloud.usage.dao.UsageDao 
 com.cloud.usage.parser.VmDiskUsageParser._usageDao; nested exception is 
 org.springframework.beans.factory.BeanCreationException: Error creating bean 
 with name 'usageDaoImpl' defined in URL 
 [jar:file:/usr/share/cloudstack-usage/lib/cloud-engine-schema-4.5.0-SNAPSHOT.jar!/com/cloud/usage/dao/UsageDaoImpl.class]:
  BeanPostProcessor before instantiation of bean failed; nested exception is 
 net.sf.cglib.core.CodeGenerationException: 
 java.lang.ExceptionInInitializerError--null
 at 
 org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor.postProcessPropertyValues(AutowiredAnnotationBeanPostProcessor.java:288)
 at 
 org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.populateBean(AbstractAutowireCapableBeanFactory.java:1116)
 at 
 org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:519)
 at 
 org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:458)
 at 
 org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:295)
 at 
 org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:223)
 at 
 org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:292)
 at 
 org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:194)
 at 
 org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:628)
 at 
 org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:932)
 at 
 org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:479)
 at 
 org.springframework.context.support.ClassPathXmlApplicationContext.init(ClassPathXmlApplicationContext.java:139)
 at

[jira] [Commented] (CLOUDSTACK-7184) HA should wait for at least 'xen.heartbeat.interval' sec before starting HA on vm's when host is marked down

2014-08-21 Thread John Kinsella (JIRA)

[
https://issues.apache.org/jira/browse/CLOUDSTACK-7184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14105710#comment-14105710
]

John Kinsella commented on CLOUDSTACK-7184:
---

I've seen similar with KVM - I'm not sure this is necessarily tied to Xen? I'd
suggest that possibly CS be a little more thorough before deciding a VM is
down...maybe via channels other than the agent/VR?

HA should wait for at least 'xen.heartbeat.interval' sec before starting HA
on vm's when host is marked down

Key: CLOUDSTACK-7184
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7184
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Hypervisor Controller, Management Server, XenServer
Affects Versions: 4.3.0, 4.4.0, 4.5.0
Environment: CloudStack 4.3 with XenServer 6.2 hypervisors
Reporter: Remi Bergsma
Priority: Blocker

Hypervisor got isolated for 30 seconds due to a network issue. CloudStack did
discover this and marked the host as down, and immediately started HA. Just
18 seconds later the hypervisor returned and we ended up with 5 vm's that
were running on two hypervisors at the same time.
This, of course, resulted in file system corruption and the loss of the vm's.
One side of the story is why XenServer allowed this to happen (will not
bother you with this one). The CloudStack side of the story: HA should only
start after at least xen.heartbeat.interval seconds. If the host is down long
enough, the Xen heartbeat script will fence the hypervisor and prevent
corruption. If it is not down long enough, nothing should happen.
Logs (short):
2014-07-25 05:03:28,596 WARN [c.c.a.m.DirectAgentAttache]
(DirectAgent-122:ctx-690badc5) Unable to get current status on 505(mccpvmXX)
.
2014-07-25 05:03:31,920 ERROR [c.c.a.m.AgentManagerImpl]
(AgentTaskPool-10:ctx-11b9af3e) Host is down: 505-mccpvmXX. Starting HA on
the VMs
.
2014-07-25 05:03:49,655 DEBUG [c.c.h.Status] (ClusteredAgentManager
Timer:ctx-0e00979c) Transition:[Resource state = Enabled, Agent event =
AgentDisconnected, Host id = 505, name = mccpvmXX]
cs marks host down: 2014-07-25 05:03:31,920
cs marks host up: 2014-07-25 05:03:49,655

--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CLOUDSTACK-7184) HA should wait for at least 'xen.heartbeat.interval' sec before starting HA on vm's when host is marked down

2014-08-21 Thread Joris van Lieshout (JIRA)

[
https://issues.apache.org/jira/browse/CLOUDSTACK-7184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14105718#comment-14105718
]

Joris van Lieshout commented on CLOUDSTACK-7184:

Hi, I am currently out of office and will be back Wednesday the 27th of August.
During this time I will have limited access to e-mail and might not be able to
take your call. For urgent matter regarding ASR please contact
int-...@schubergphilis.com instead. For other urgent matter please contact one
of my colleagues.

Kind regards,
Joris van Lieshout

Schuberg Philis
schubergphilis.com

+31207506672
+31651428188

HA should wait for at least 'xen.heartbeat.interval' sec before starting HA
on vm's when host is marked down

--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CLOUDSTACK-7316) hitting java.lang.reflect.InvocationTargetException while starting usage server

2014-08-21 Thread Nitin Mehta (JIRA)


 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Nitin Mehta updated CLOUDSTACK-7316:


Assignee: Kishan Kavala  (was: Nitin Mehta)

 hitting java.lang.reflect.InvocationTargetException while starting usage 
 server
 ---

 Key: CLOUDSTACK-7316
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7316
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Usage
Affects Versions: 4.5.0
Reporter: shweta agarwal
Assignee: Kishan Kavala
Priority: Blocker
 Fix For: 4.5.0

 Attachments: usage.tar.gz


 Repro steps:
 Install MS and usage server
 Start MS and usage server
 Bug:
 Usage server will stop after starting
 usage log shows :
 java.lang.reflect.InvocationTargetException
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
 at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 at java.lang.reflect.Method.invoke(Method.java:601)
 at 
 org.apache.commons.daemon.support.DaemonLoader.start(DaemonLoader.java:243)
 Caused by: org.springframework.beans.factory.BeanCreationException: Error 
 creating bean with name 'vmDiskUsageParser': Injection of autowired 
 dependencies failed; nested exception is 
 org.springframework.beans.factory.BeanCreationException: Could not autowire 
 field: private com.cloud.usage.dao.UsageDao 
 com.cloud.usage.parser.VmDiskUsageParser._usageDao; nested exception is 
 org.springframework.beans.factory.BeanCreationException: Error creating bean 
 with name 'usageDaoImpl' defined in URL 
 [jar:file:/usr/share/cloudstack-usage/lib/cloud-engine-schema-4.5.0-SNAPSHOT.jar!/com/cloud/usage/dao/UsageDaoImpl.class]:
  BeanPostProcessor before instantiation of bean failed; nested exception is 
 net.sf.cglib.core.CodeGenerationException: 
 java.lang.ExceptionInInitializerError--null
 at 
 org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor.postProcessPropertyValues(AutowiredAnnotationBeanPostProcessor.java:288)
 at 
 org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.populateBean(AbstractAutowireCapableBeanFactory.java:1116)
 at 
 org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:519)
 at 
 org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:458)
 at 
 org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:295)
 at 
 org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:223)
 at 
 org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:292)
 at 
 org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:194)
 at 
 org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:628)
 at 
 org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:932)
 at 
 org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:479)
 at 
 org.springframework.context.support.ClassPathXmlApplicationContext.init(ClassPathXmlApplicationContext.java:139)
 at 
 org.springframework.context.support.ClassPathXmlApplicationContext.init(ClassPathXmlApplicationContext.java:83)
 at com.cloud.usage.UsageServer.start(UsageServer.java:57)
 ... 5 more
 Caused by: org.springframework.beans.factory.BeanCreationException: Could not 
 autowire field: private com.cloud.usage.dao.UsageDao 
 com.cloud.usage.parser.VmDiskUsageParser._usageDao; nested exception is 
 org.springframework.beans.factory.BeanCreationException: Error creating bean 
 with name 'usageDaoImpl' defined in URL 
 [jar:file:/usr/share/cloudstack-usage/lib/cloud-engine-schema-4.5.0-SNAPSHOT.jar!/com/cloud/usage/dao/UsageDaoImpl.class]:
  BeanPostProcessor before instantiation of bean failed; nested exception is 
 net.sf.cglib.core.CodeGenerationException: 
 java.lang.ExceptionInInitializerError--null
 at 
 org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor$AutowiredFieldElement.inject(AutowiredAnnotationBeanPostProcessor.java:514)



--
This message was sent by Atlassian JIRA

[jira] [Commented] (CLOUDSTACK-7316) hitting java.lang.reflect.InvocationTargetException while starting usage server

2014-08-21 Thread Nitin Mehta (JIRA)


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14105989#comment-14105989
 ] 

Nitin Mehta commented on CLOUDSTACK-7316:
-

Reassigning to Kishan so that blocker gets immediate attention.

 hitting java.lang.reflect.InvocationTargetException while starting usage 
 server
 ---

 Key: CLOUDSTACK-7316
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7316
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Usage
Affects Versions: 4.5.0
Reporter: shweta agarwal
Assignee: Kishan Kavala
Priority: Blocker
 Fix For: 4.5.0

 Attachments: usage.tar.gz


 Repro steps:
 Install MS and usage server
 Start MS and usage server
 Bug:
 Usage server will stop after starting
 usage log shows :
 java.lang.reflect.InvocationTargetException
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
 at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 at java.lang.reflect.Method.invoke(Method.java:601)
 at 
 org.apache.commons.daemon.support.DaemonLoader.start(DaemonLoader.java:243)
 Caused by: org.springframework.beans.factory.BeanCreationException: Error 
 creating bean with name 'vmDiskUsageParser': Injection of autowired 
 dependencies failed; nested exception is 
 org.springframework.beans.factory.BeanCreationException: Could not autowire 
 field: private com.cloud.usage.dao.UsageDao 
 com.cloud.usage.parser.VmDiskUsageParser._usageDao; nested exception is 
 org.springframework.beans.factory.BeanCreationException: Error creating bean 
 with name 'usageDaoImpl' defined in URL 
 [jar:file:/usr/share/cloudstack-usage/lib/cloud-engine-schema-4.5.0-SNAPSHOT.jar!/com/cloud/usage/dao/UsageDaoImpl.class]:
  BeanPostProcessor before instantiation of bean failed; nested exception is 
 net.sf.cglib.core.CodeGenerationException: 
 java.lang.ExceptionInInitializerError--null
 at 
 org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor.postProcessPropertyValues(AutowiredAnnotationBeanPostProcessor.java:288)
 at 
 org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.populateBean(AbstractAutowireCapableBeanFactory.java:1116)
 at 
 org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:519)
 at 
 org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:458)
 at 
 org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:295)
 at 
 org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:223)
 at 
 org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:292)
 at 
 org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:194)
 at 
 org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:628)
 at 
 org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:932)
 at 
 org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:479)
 at 
 org.springframework.context.support.ClassPathXmlApplicationContext.init(ClassPathXmlApplicationContext.java:139)
 at 
 org.springframework.context.support.ClassPathXmlApplicationContext.init(ClassPathXmlApplicationContext.java:83)
 at com.cloud.usage.UsageServer.start(UsageServer.java:57)
 ... 5 more
 Caused by: org.springframework.beans.factory.BeanCreationException: Could not 
 autowire field: private com.cloud.usage.dao.UsageDao 
 com.cloud.usage.parser.VmDiskUsageParser._usageDao; nested exception is 
 org.springframework.beans.factory.BeanCreationException: Error creating bean 
 with name 'usageDaoImpl' defined in URL 
 [jar:file:/usr/share/cloudstack-usage/lib/cloud-engine-schema-4.5.0-SNAPSHOT.jar!/com/cloud/usage/dao/UsageDaoImpl.class]:
  BeanPostProcessor before instantiation of bean failed; nested exception is 
 net.sf.cglib.core.CodeGenerationException: 
 java.lang.ExceptionInInitializerError--null
 at

[jira] [Created] (CLOUDSTACK-7387) [Automation] Fix the script test_vpc_host_maintenance.py - Code is hardcoded to use certain host tags

Chandan Purushothama created CLOUDSTACK-7387:


 Summary: [Automation] Fix the script 
test_vpc_host_maintenance.py - Code is hardcoded to use certain host tags
 Key: CLOUDSTACK-7387
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7387
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Automation, Test
Affects Versions: 4.5.0
Reporter: Chandan Purushothama
Priority: Critical
 Fix For: 4.5.0


Currently script assumes that the deployment has hosts with host_tag 
HOST_TAGS_HERE and uses two service offerings with this host_tag. The script 
is hardcoded with the above information. The proper design and correction 
should be as follows.

# Find the cluster with two hosts
## If no two host cluster is found error out with proper message
# Edit the host tags on the two hosts to two different unique names
# Create corresponding service offerings with the two different unique names
# Conduct the tests
# In teardown script section of the script, edit the host tags on the hosts to 
empty.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CLOUDSTACK-7387) [Automation] Fix the script test_vpc_host_maintenance.py - Code is hardcoded to use certain host tags

2014-08-21 Thread ASF subversion and git services (JIRA)

[
https://issues.apache.org/jira/browse/CLOUDSTACK-7387?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Chandan Purushothama updated CLOUDSTACK-7387:
-

Description:
*Script is at*: component/maint/.

Currently script assumes that the deployment has hosts with host_tag
HOST_TAGS_HERE and uses two service offerings with this host_tag. The script
is hardcoded with the above information. The proper design and correction
should be as follows.

# Find the cluster with two hosts
## If no two host cluster is found error out with proper message
# Edit the host tags on the two hosts to two different unique names
# Create corresponding service offerings with the two different unique names
# Conduct the tests
# In teardown script section of the script, edit the host tags on the hosts to
empty.

was:
Currently script assumes that the deployment has hosts with host_tag
HOST_TAGS_HERE and uses two service offerings with this host_tag. The script
is hardcoded with the above information. The proper design and correction
should be as follows.

[Automation] Fix the script test_vpc_host_maintenance.py - Code is
hardcoded to use certain host tags
---

Key: CLOUDSTACK-7387
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7387
Project: CloudStack
Issue Type: Bug
Security Level: Public(Anyone can view this level - this is the
default.)
Components: Automation, Test
Affects Versions: 4.5.0
Reporter: Chandan Purushothama
Priority: Critical
Fix For: 4.5.0

*Script is at*: component/maint/.
Currently script assumes that the deployment has hosts with host_tag
HOST_TAGS_HERE and uses two service offerings with this host_tag. The
script is hardcoded with the above information. The proper design and
correction should be as follows.
# Find the cluster with two hosts
## If no two host cluster is found error out with proper message
# Edit the host tags on the two hosts to two different unique names
# Create corresponding service offerings with the two different unique names
# Conduct the tests
# In teardown script section of the script, edit the host tags on the hosts
to empty.

--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CLOUDSTACK-7260) Management server not responding after some time for Vmware due to Oom (cannot create native thread)


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14106034#comment-14106034
 ] 

ASF subversion and git services commented on CLOUDSTACK-7260:
-

Commit 997f74af1cb02f9c7b6b11513e4f192eec02e786 in cloudstack's branch 
refs/heads/4.3 from [~minchen07]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=997f74a ]

CLOUDSTACK-7260: Management server not responding after some time for
Vmware due to Oom (cannot create native thread).

 Management server not responding after some time for Vmware due to Oom 
 (cannot create native thread)
 

 Key: CLOUDSTACK-7260
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7260
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: VMware
Affects Versions: 4.2.0
Reporter: Min Chen
Assignee: Min Chen
Priority: Blocker
 Fix For: 4.5.0


 For a deployment with many hosts, 1 hour after starting management server is 
 not responding well (very slow) and UI also hung. User is unable to deploy 
 VM. In the MS log, we can see this happening:
 2014-07-27 00:47:32,139 ERROR [o.a.c.f.j.i.AsyncJobManagerImpl] 
 (AsyncJobMgr-Heartbeat-1:ctx-06c59569) Unexpected exception when trying to 
 execute queue item, 
 java.lang.OutOfMemoryError: unable to create new native thread
 at java.lang.Thread.start0(Native Method)



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Created] (CLOUDSTACK-7388) [Automation] Fix the script test_redundant_router.py - Script is hardcoded to use password as Host's password

Chandan Purushothama created CLOUDSTACK-7388:


 Summary: [Automation] Fix the script test_redundant_router.py - 
Script is hardcoded to use password as Host's password
 Key: CLOUDSTACK-7388
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7388
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Automation, Test
Affects Versions: 4.5.0
Reporter: Chandan Purushothama
Priority: Critical
 Fix For: 4.5.0


Observe the below code in test_redundant_router.py script:

{code}
...
.
.
},
host: {
 username: root,
 password: password,
 publicport: 22,
},
network: {
.
.
.
.
@attr(tags=[advanced, advancedns, ssh])
def test_redundantVR_internals(self):
Test redundant router internals

.
.
.
else:
result = get_process_status(
backup_host.ipaddress,
self.services['host'][publicport],
self.services['host'][username],
self.services['host'][password],
backup_router.linklocalip,
'ip addr show eth2',
)
res = str(result)
.
.
.
{code}

The above code should be changed to use the host information from configuration 
file outside this script.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CLOUDSTACK-7389) [Automation] Fix the script test_bugs.py - Unable to find Ostype is required for registering template


 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7389?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Chandan Purushothama updated CLOUDSTACK-7389:
-

Description: 
Script is at: component/maint/.

{code}
@attr(required_hardware=false)
@attr(storage=s3)
def test_es_1863_register_template_s3_domain_admin_user(self):

@Desc: Test whether cloudstack allows Domain admin or user to register 
a template using
S3/Swift object store.
@Steps:
Step1: create a Domain and users in it.
Step2: Register a template as Domain admin.
Step3: Register a template as Domain user.
Step4: Template should be registered successfully.

# Step1: create a Domain and users in it.
self.newdomain = Domain.create(self.apiClient,
   self.services[domain])

#create account in the domain
self.account_domain = Account.create(
self.apiClient,
self.services[account],
domainid=self.newdomain.id
)
self.cleanup.append(self.account_domain)
self.cleanup.append(self.newdomain)
# Getting authentication for user in newly created Account in domain
self.domain_user = self.account_domain.user[0]
self.domain_userapiclient = 
self.testClient.getUserApiClient(self.domain_user.username, self.newdomain.name)

# Step2: Register a template as Domain admin.
self.domain_template = Template.register(
self.apiClient,
self.services[templateregister],
zoneid=self.zone.id,
account=self.account_domain.name,
domainid=self.newdomain.id,
hypervisor=self.hypervisor
)
# Wait for template to download
self.domain_template.download(self.api_client)

# Wait for template status to be changed across
time.sleep(60)
# Step3: Register a template as Domain user.
self.domain_user_template = Template.register(
self.domain_userapiclient,
self.services[templateregister],
zoneid=self.zone.id,
account=self.account_domain.name,
domainid=self.newdomain.id,
hypervisor=self.hypervisor
)
{code}

*Error Message*

Unable to find Ostype is required for registering template
  begin captured stdout  -
=== TestName: test_es_1863_register_template_s3_domain_admin_user | Status : 
EXCEPTION ===


-  end captured stdout  --

  was:

{code}
@attr(required_hardware=false)
@attr(storage=s3)
def test_es_1863_register_template_s3_domain_admin_user(self):

@Desc: Test whether cloudstack allows Domain admin or user to register 
a template using
S3/Swift object store.
@Steps:
Step1: create a Domain and users in it.
Step2: Register a template as Domain admin.
Step3: Register a template as Domain user.
Step4: Template should be registered successfully.

# Step1: create a Domain and users in it.
self.newdomain = Domain.create(self.apiClient,
   self.services[domain])

#create account in the domain
self.account_domain = Account.create(
self.apiClient,
self.services[account],
domainid=self.newdomain.id
)
self.cleanup.append(self.account_domain)
self.cleanup.append(self.newdomain)
# Getting authentication for user in newly created Account in domain
self.domain_user = self.account_domain.user[0]
self.domain_userapiclient = 
self.testClient.getUserApiClient(self.domain_user.username, self.newdomain.name)

# Step2: Register a template as Domain admin.
self.domain_template = Template.register(
self.apiClient,
self.services[templateregister],
zoneid=self.zone.id,
account=self.account_domain.name,
domainid=self.newdomain.id,
hypervisor=self.hypervisor
)
# Wait for template to download
self.domain_template.download(self.api_client)

# Wait for template status to be changed across

[jira] [Created] (CLOUDSTACK-7389) [Automation] Fix the script test_bugs.py - Unable to find Ostype is required for registering template

Chandan Purushothama created CLOUDSTACK-7389:


 Summary: [Automation] Fix the script test_bugs.py - Unable to 
find Ostype is required for registering template
 Key: CLOUDSTACK-7389
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7389
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Automation, Test
Affects Versions: 4.5.0
Reporter: Chandan Purushothama
Priority: Critical
 Fix For: 4.5.0



{code}
@attr(required_hardware=false)
@attr(storage=s3)
def test_es_1863_register_template_s3_domain_admin_user(self):

@Desc: Test whether cloudstack allows Domain admin or user to register 
a template using
S3/Swift object store.
@Steps:
Step1: create a Domain and users in it.
Step2: Register a template as Domain admin.
Step3: Register a template as Domain user.
Step4: Template should be registered successfully.

# Step1: create a Domain and users in it.
self.newdomain = Domain.create(self.apiClient,
   self.services[domain])

#create account in the domain
self.account_domain = Account.create(
self.apiClient,
self.services[account],
domainid=self.newdomain.id
)
self.cleanup.append(self.account_domain)
self.cleanup.append(self.newdomain)
# Getting authentication for user in newly created Account in domain
self.domain_user = self.account_domain.user[0]
self.domain_userapiclient = 
self.testClient.getUserApiClient(self.domain_user.username, self.newdomain.name)

# Step2: Register a template as Domain admin.
self.domain_template = Template.register(
self.apiClient,
self.services[templateregister],
zoneid=self.zone.id,
account=self.account_domain.name,
domainid=self.newdomain.id,
hypervisor=self.hypervisor
)
# Wait for template to download
self.domain_template.download(self.api_client)

# Wait for template status to be changed across
time.sleep(60)
# Step3: Register a template as Domain user.
self.domain_user_template = Template.register(
self.domain_userapiclient,
self.services[templateregister],
zoneid=self.zone.id,
account=self.account_domain.name,
domainid=self.newdomain.id,
hypervisor=self.hypervisor
)
{code}

*Error Message*

Unable to find Ostype is required for registering template
  begin captured stdout  -
=== TestName: test_es_1863_register_template_s3_domain_admin_user | Status : 
EXCEPTION ===


-  end captured stdout  --



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CLOUDSTACK-7388) [Automation] Fix the script test_redundant_router.py - Script is hardcoded to use password as Host's password


 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Chandan Purushothama updated CLOUDSTACK-7388:
-

Description: 
Script is at: component/maint/.

Observe the below code in test_redundant_router.py script:

{code}
...
.
.
},
host: {
 username: root,
 password: password,
 publicport: 22,
},
network: {
.
.
.
.
@attr(tags=[advanced, advancedns, ssh])
def test_redundantVR_internals(self):
Test redundant router internals

.
.
.
else:
result = get_process_status(
backup_host.ipaddress,
self.services['host'][publicport],
self.services['host'][username],
self.services['host'][password],
backup_router.linklocalip,
'ip addr show eth2',
)
res = str(result)
.
.
.
{code}

The above code should be changed to use the host information from configuration 
file outside this script.

  was:
Observe the below code in test_redundant_router.py script:

{code}
...
.
.
},
host: {
 username: root,
 password: password,
 publicport: 22,
},
network: {
.
.
.
.
@attr(tags=[advanced, advancedns, ssh])
def test_redundantVR_internals(self):
Test redundant router internals

.
.
.
else:
result = get_process_status(
backup_host.ipaddress,
self.services['host'][publicport],
self.services['host'][username],
self.services['host'][password],
backup_router.linklocalip,
'ip addr show eth2',
)
res = str(result)
.
.
.
{code}

The above code should be changed to use the host information from configuration 
file outside this script.


 [Automation] Fix the script test_redundant_router.py - Script is hardcoded 
 to use password as Host's password
 -

 Key: CLOUDSTACK-7388
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7388
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Automation, Test
Affects Versions: 4.5.0
Reporter: Chandan Purushothama
Priority: Critical
 Fix For: 4.5.0


 Script is at: component/maint/.
 Observe the below code in test_redundant_router.py script:
 {code}
 ...
 .
 .
 },
 host: {
  username: root,
  password: password,
  publicport: 22,
 },
 network: {
 .
 .
 .
 .
 @attr(tags=[advanced, advancedns, ssh])
 def test_redundantVR_internals(self):
 Test redundant router internals
 
 .
 .
 .
 else:
 result = get_process_status(
 backup_host.ipaddress,
 self.services['host'][publicport],
 self.services['host'][username],
 self.services['host'][password],
 backup_router.linklocalip,
 'ip addr show eth2',
 )
 res = str(result)
 .
 .
 .
 {code}
 The above code should be changed to use the host information from 
 configuration file outside this script.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Created] (CLOUDSTACK-7390) [Automation] Fix the script test_bugs.py - Invalid Parameters

Chandan Purushothama created CLOUDSTACK-7390:


 Summary: [Automation] Fix the script test_bugs.py - Invalid 
Parameters
 Key: CLOUDSTACK-7390
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7390
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Automation, Test
Affects Versions: 4.5.0
Reporter: Chandan Purushothama
Priority: Critical
 Fix For: 4.5.0


Script is at: component/maint/.

{code}
@attr(tags=[advanced, basic])
@attr(required_hardware=false)
@attr(configuration='apply.allocation.algorithm.to.pods')
def test_es_47_list_os_types_win_2012(self):

@Desc: Test VM creation while apply.allocation.algorithm.to.pods is 
set to true
@Reference: https://issues.apache.org/jira/browse/CLOUDSTACK-4947
@Steps:
Step1: register windows 2012 VM template as windows 8 template
Step2: deploy a VM with windows2012 template and  Verify that VM 
creation is successful

 

# register windows 2012 VM template as windows 8 template
self.win2012_template = Template.register(
self.apiClient,
self.services[win2012template],
zoneid=self.zone.id,
account=self.account.name,
domainid=self.domain.id,
hypervisor=self.hypervisor
)


# Wait for template to download
self.win2012_template.download(self.apiClient)
self.cleanup.append(self.win2012_template)
# Wait for template status to be changed across
time.sleep(60)
# Deploy
self.debug(Deploying win 2012 VM in account: %s % self.account.name)
self.services[virtual_machine][displayname] = win2012
self.services[virtual_machine][zoneid] = self.zone.id
self.services[virtual_machine][template] = self.win2012_template.id
vm1 = VirtualMachine.create(
self.apiClient,
self.services[virtual_machine2],
accountid=self.account.name,
domainid=self.account.domainid,
serviceofferingid=self.service_offering.id,
)
self.cleanup.append(vm1)
# Verify VM state
self.assertEqual(
vm1.state,
'Running',
Check VM state is Running or not
)
return

 
{code}


Client Error Information:


test_es_47_list_os_types_win_2012 
(integration.component.maint.test_bugs.Test42xBugsMgmtSvr): DEBUG: 
Sending GET Cmd : listTemplates===
requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection 
(1): 10.220.135.39
requests.packages.urllib3.connectionpool: DEBUG: GET 
/client/api?templatefilter=selfapiKey=NpffyWZkfwK7gPcNpx28Ohv6K56ftl57A409SyokqHjJ2ZNe3AvvF3F0teTETeIIqrtlcWpQOooM3cQyPveGXwzoneid=f2acfe0c-c8c8-4353-8f97-a3e0f14d6357command=listTemplatessignature=LjryRXT0OpAYRm%2BuM5slT8BkAh4%3Did=1ee5bf28-5cbe-41e4-ba11-0418ecda39c4response=json
 HTTP/1.1 200 847
test_es_47_list_os_types_win_2012 
(integration.component.maint.test_bugs.Test42xBugsMgmtSvr): DEBUG: Response : 
[{domain : u'ROOT', domainid : u'9d7d4d5c-281e-11e4-b06a-d2bc9de3652e', 
ostypename : u'Windows 8 (64-bit)', zoneid : 
u'f2acfe0c-c8c8-4353-8f97-a3e0f14d6357', displaytext : u'win2012', ostypeid : 
u'9d9979e6-281e-11e4-b06a-d2bc9de3652e', passwordenabled : False, id : 
u'1ee5bf28-5cbe-41e4-ba11-0418ecda39c4', size : 34359738368, isready : True, 
format : u'OVA', templatetype : u'USER', details : {hypervisortoolsversion : 
u'xenserver61'}, zonename : u'XenRT-Zone-0', status : u'Download Complete', 
isdynamicallyscalable : False, tags : [], isfeatured : False, sshkeyenabled : 
False, isextractable : False, crossZones : False, account : 
u'test-a-Test42xBugsMgmtSvr-BJ4H02', name : u'win2012-S1SJ8X', created : 
u'2014-08-20T13:24:49+', hypervisor : u'XenServer', ispublic : False, 
checksum : u'b31fec1e736b8bc27db9d0f6740c6622'}]
test_es_47_list_os_types_win_2012 
(integration.component.maint.test_bugs.Test42xBugsMgmtSvr): DEBUG: Deploying 
win 2012 VM in account: test-a-Test42xBugsMgmtSvr-BJ4H02
test_es_47_list_os_types_win_2012 
(integration.component.maint.test_bugs.Test42xBugsMgmtSvr): DEBUG: *CmdName: 
deployVirtualMachine Parameter : templateid is Required*
test_es_47_list_os_types_win_2012 
(integration.component.maint.test_bugs.Test42xBugsMgmtSvr): ERROR: 
marvinRequest : CmdName:

[jira] [Updated] (CLOUDSTACK-7387) [Automation] Fix the script test_vpc_host_maintenance.py - Code is hardcoded to use certain host tags


 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7387?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Chandan Purushothama updated CLOUDSTACK-7387:
-

Issue Type: Test  (was: Bug)

 [Automation] Fix the script test_vpc_host_maintenance.py - Code is 
 hardcoded to use certain host tags
 ---

 Key: CLOUDSTACK-7387
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7387
 Project: CloudStack
  Issue Type: Test
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Automation, Test
Affects Versions: 4.5.0
Reporter: Chandan Purushothama
Priority: Critical
 Fix For: 4.5.0


 *Script is at*: component/maint/.
 Currently script assumes that the deployment has hosts with host_tag 
 HOST_TAGS_HERE and uses two service offerings with this host_tag. The 
 script is hardcoded with the above information. The proper design and 
 correction should be as follows.
 # Find the cluster with two hosts
 ## If no two host cluster is found error out with proper message
 # Edit the host tags on the two hosts to two different unique names
 # Create corresponding service offerings with the two different unique names
 # Conduct the tests
 # In teardown script section of the script, edit the host tags on the hosts 
 to empty.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CLOUDSTACK-7389) [Automation] Fix the script test_bugs.py - Unable to find Ostype is required for registering template


 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7389?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Chandan Purushothama updated CLOUDSTACK-7389:
-

Issue Type: Test  (was: Bug)

 [Automation] Fix the script test_bugs.py - Unable to find Ostype is 
 required for registering template
 ---

 Key: CLOUDSTACK-7389
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7389
 Project: CloudStack
  Issue Type: Test
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Automation, Test
Affects Versions: 4.5.0
Reporter: Chandan Purushothama
Priority: Critical
 Fix For: 4.5.0


 Script is at: component/maint/.
 {code}
 @attr(required_hardware=false)
 @attr(storage=s3)
 def test_es_1863_register_template_s3_domain_admin_user(self):
 
 @Desc: Test whether cloudstack allows Domain admin or user to 
 register a template using
 S3/Swift object store.
 @Steps:
 Step1: create a Domain and users in it.
 Step2: Register a template as Domain admin.
 Step3: Register a template as Domain user.
 Step4: Template should be registered successfully.
 
 # Step1: create a Domain and users in it.
 self.newdomain = Domain.create(self.apiClient,
self.services[domain])
 #create account in the domain
 self.account_domain = Account.create(
 self.apiClient,
 self.services[account],
 domainid=self.newdomain.id
 )
 self.cleanup.append(self.account_domain)
 self.cleanup.append(self.newdomain)
 # Getting authentication for user in newly created Account in domain
 self.domain_user = self.account_domain.user[0]
 self.domain_userapiclient = 
 self.testClient.getUserApiClient(self.domain_user.username, 
 self.newdomain.name)
 # Step2: Register a template as Domain admin.
 self.domain_template = Template.register(
 self.apiClient,
 self.services[templateregister],
 zoneid=self.zone.id,
 account=self.account_domain.name,
 domainid=self.newdomain.id,
 hypervisor=self.hypervisor
 )
 # Wait for template to download
 self.domain_template.download(self.api_client)
 # Wait for template status to be changed across
 time.sleep(60)
 # Step3: Register a template as Domain user.
 self.domain_user_template = Template.register(
 self.domain_userapiclient,
 self.services[templateregister],
 zoneid=self.zone.id,
 account=self.account_domain.name,
 domainid=self.newdomain.id,
 hypervisor=self.hypervisor
 )
 {code}
 *Error Message*
 Unable to find Ostype is required for registering template
   begin captured stdout  -
 === TestName: test_es_1863_register_template_s3_domain_admin_user | Status : 
 EXCEPTION ===
 -  end captured stdout  --



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CLOUDSTACK-7390) [Automation] Fix the script test_bugs.py - Invalid Parameters


 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7390?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Chandan Purushothama updated CLOUDSTACK-7390:
-

Issue Type: Test  (was: Bug)

 [Automation] Fix the script test_bugs.py - Invalid Parameters
 ---

 Key: CLOUDSTACK-7390
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7390
 Project: CloudStack
  Issue Type: Test
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Automation, Test
Affects Versions: 4.5.0
Reporter: Chandan Purushothama
Priority: Critical
 Fix For: 4.5.0


 Script is at: component/maint/.
 {code}
 @attr(tags=[advanced, basic])
 @attr(required_hardware=false)
 @attr(configuration='apply.allocation.algorithm.to.pods')
 def test_es_47_list_os_types_win_2012(self):
 
 @Desc: Test VM creation while apply.allocation.algorithm.to.pods is 
 set to true
 @Reference: https://issues.apache.org/jira/browse/CLOUDSTACK-4947
 @Steps:
 Step1: register windows 2012 VM template as windows 8 template
 Step2: deploy a VM with windows2012 template and  Verify that VM 
 creation is successful
  
 # register windows 2012 VM template as windows 8 template
 self.win2012_template = Template.register(
 self.apiClient,
 self.services[win2012template],
 zoneid=self.zone.id,
 account=self.account.name,
 domainid=self.domain.id,
 hypervisor=self.hypervisor
 )
 # Wait for template to download
 self.win2012_template.download(self.apiClient)
 self.cleanup.append(self.win2012_template)
 # Wait for template status to be changed across
 time.sleep(60)
 # Deploy
 self.debug(Deploying win 2012 VM in account: %s % self.account.name)
 self.services[virtual_machine][displayname] = win2012
 self.services[virtual_machine][zoneid] = self.zone.id
 self.services[virtual_machine][template] = 
 self.win2012_template.id
 vm1 = VirtualMachine.create(
 self.apiClient,
 self.services[virtual_machine2],
 accountid=self.account.name,
 domainid=self.account.domainid,
 serviceofferingid=self.service_offering.id,
 )
 self.cleanup.append(vm1)
 # Verify VM state
 self.assertEqual(
 vm1.state,
 'Running',
 Check VM state is Running or not
 )
 return
   

 {code}
 
 Client Error Information:
 
 test_es_47_list_os_types_win_2012 
 (integration.component.maint.test_bugs.Test42xBugsMgmtSvr): DEBUG: 
 Sending GET Cmd : listTemplates===
 requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection 
 (1): 10.220.135.39
 requests.packages.urllib3.connectionpool: DEBUG: GET 
 /client/api?templatefilter=selfapiKey=NpffyWZkfwK7gPcNpx28Ohv6K56ftl57A409SyokqHjJ2ZNe3AvvF3F0teTETeIIqrtlcWpQOooM3cQyPveGXwzoneid=f2acfe0c-c8c8-4353-8f97-a3e0f14d6357command=listTemplatessignature=LjryRXT0OpAYRm%2BuM5slT8BkAh4%3Did=1ee5bf28-5cbe-41e4-ba11-0418ecda39c4response=json
  HTTP/1.1 200 847
 test_es_47_list_os_types_win_2012 
 (integration.component.maint.test_bugs.Test42xBugsMgmtSvr): DEBUG: Response : 
 [{domain : u'ROOT', domainid : u'9d7d4d5c-281e-11e4-b06a-d2bc9de3652e', 
 ostypename : u'Windows 8 (64-bit)', zoneid : 
 u'f2acfe0c-c8c8-4353-8f97-a3e0f14d6357', displaytext : u'win2012', ostypeid : 
 u'9d9979e6-281e-11e4-b06a-d2bc9de3652e', passwordenabled : False, id : 
 u'1ee5bf28-5cbe-41e4-ba11-0418ecda39c4', size : 34359738368, isready : True, 
 format : u'OVA', templatetype : u'USER', details : {hypervisortoolsversion : 
 u'xenserver61'}, zonename : u'XenRT-Zone-0', status : u'Download Complete', 
 isdynamicallyscalable : False, tags : [], isfeatured : False, sshkeyenabled : 
 False, isextractable : False, crossZones : False, account : 
 u'test-a-Test42xBugsMgmtSvr-BJ4H02', name : u'win2012-S1SJ8X', created : 
 u'2014-08-20T13:24:49+', hypervisor : u'XenServer', ispublic : False, 
 checksum : u'b31fec1e736b8bc27db9d0f6740c6622'}]
 test_es_47_list_os_types_win_2012 
 (integration.component.maint.test_bugs.Test42xBugsMgmtSvr): DEBUG: Deploying 
 win 2012 VM in account: test-a-Test42xBugsMgmtSvr-BJ4H02

[jira] [Updated] (CLOUDSTACK-7388) [Automation] Fix the script test_redundant_router.py - Script is hardcoded to use password as Host's password


 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Chandan Purushothama updated CLOUDSTACK-7388:
-

Issue Type: Test  (was: Bug)

 [Automation] Fix the script test_redundant_router.py - Script is hardcoded 
 to use password as Host's password
 -

 Key: CLOUDSTACK-7388
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7388
 Project: CloudStack
  Issue Type: Test
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Automation, Test
Affects Versions: 4.5.0
Reporter: Chandan Purushothama
Priority: Critical
 Fix For: 4.5.0


 Script is at: component/maint/.
 Observe the below code in test_redundant_router.py script:
 {code}
 ...
 .
 .
 },
 host: {
  username: root,
  password: password,
  publicport: 22,
 },
 network: {
 .
 .
 .
 .
 @attr(tags=[advanced, advancedns, ssh])
 def test_redundantVR_internals(self):
 Test redundant router internals
 
 .
 .
 .
 else:
 result = get_process_status(
 backup_host.ipaddress,
 self.services['host'][publicport],
 self.services['host'][username],
 self.services['host'][password],
 backup_router.linklocalip,
 'ip addr show eth2',
 )
 res = str(result)
 .
 .
 .
 {code}
 The above code should be changed to use the host information from 
 configuration file outside this script.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Created] (CLOUDSTACK-7391) [Automation] Fix the script test_host_high_availability.py - Error Message: suitablehost should not be None

Chandan Purushothama created CLOUDSTACK-7391:


 Summary: [Automation] Fix the script 
test_host_high_availability.py - Error Message: suitablehost should not be 
None
 Key: CLOUDSTACK-7391
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7391
 Project: CloudStack
  Issue Type: Test
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Automation, Test
Affects Versions: 4.5.0
Reporter: Chandan Purushothama
 Fix For: 4.5.0



==
Client Code:
==

def test_03_cant_migrate_vm_to_host_with_ha_positive(self):
 Verify you can not migrate VMs to hosts with an ha.tag (positive) 

.
.
.
vm = vms[0]

self.debug(Deployed VM on host: %s % vm.hostid)

#Find out a Suitable host for VM migration
list_hosts_response = list_hosts(
self.apiclient,  *BUG: Query the list of hosts with vm id. Only 
then the response will have list of suitable and non-suitable hosts. Else 
suitableforMigration is not returned in the response*
)
self.assertEqual(
isinstance(list_hosts_response, list),
True,
The listHosts API returned the invalid list
)

self.assertNotEqual(
len(list_hosts_response),
0,
The listHosts returned nothing.
)
suitableHost = None
for host in list_hosts_response:
if host.suitableformigration == True and host.hostid != vm.hostid:
suitableHost = host
break

self.assertTrue(suitableHost is not None, suitablehost should not be 
None)

*Error Message: suitablehost should not be None*

{code}
Cmd : listHosts===
requests.packages.urllib3.connectionpool: INFO: Starting new HTTP connection 
(1): 10.220.135.39
requests.packages.urllib3.connectionpool: DEBUG: GET 
/client/api?apiKey=NpffyWZkfwK7gPcNpx28Ohv6K56ftl57A409SyokqHjJ2ZNe3AvvF3F0teTETeIIqrtlcWpQOooM3cQyPveGXwcommand=listHostsresponse=jsonsignature=gh2gh3mSzQNAcfMdspqc9v1JE3U%3D
 HTTP/1.1 200 3708
test_03_cant_migrate_vm_to_host_with_ha_positive 
(integration.component.maint.test_host_high_availability.TestHostHighAvailability):
 DEBUG: Response : [{name : u's-2-VM', created : u'2014-08-20T04:31:37+', 
ipaddress : u'10.220.136.107', islocalstorageactive : False, podid : 
u'027c1e45-5867-40f8-8ad9-685b5eb63dd2', resourcestate : u'Enabled', zoneid : 
u'f2acfe0c-c8c8-4353-8f97-a3e0f14d6357', state : u'Up', version : 
u'4.5.0-SNAPSHOT', managementserverid : 231707544610094, podname : 
u'XenRT-Zone-0-Pod-0', id : u'bb004159-d510-42b4-bfd5-878140a11f78', lastpinged 
: u'1970-01-16T22:04:57+', type : u'SecondaryStorageVM', events : 
u'AgentDisconnected; PingTimeout; Remove; ShutdownRequested; AgentConnected; 
HostDown; ManagementServerDown; Ping; StartAgentRebalance', zonename : 
u'XenRT-Zone-0'}, {name : u'v-1-VM', created : u'2014-08-20T04:31:37+', 
ipaddress : u'10.220.136.105', islocalstorageactive : False, podid : 
u'027c1e45-5867-40f8-8ad9-685b5eb63dd2', resourcestate : u'Enabled', zoneid : 
u'f2acfe0c-c8c8-4353-8f97-a3e0f14d6357', state : u'Up', version : 
u'4.5.0-SNAPSHOT', managementserverid : 231707544610094, podname : 
u'XenRT-Zone-0-Pod-0', id : u'f328a0d1-f4cb-4486-9550-dd46c403c3ed', lastpinged 
: u'1970-01-16T22:04:57+', type : u'ConsoleProxy', events : 
u'AgentDisconnected; PingTimeout; Remove; ShutdownRequested; AgentConnected; 
HostDown; ManagementServerDown; Ping; StartAgentRebalance', zonename : 
u'XenRT-Zone-0'}, {cpuwithoverprovisioning : u'28800.0', version : 
u'4.5.0-SNAPSHOT', memorytotal : 31073792896, zoneid : 
u'f2acfe0c-c8c8-4353-8f97-a3e0f14d6357', cpunumber : 12, managementserverid : 
231707544610094, cpuallocated : u'2.08%', memoryused : 4211653, id : 
u'1f5f180e-3eb1-4a6a-92f8-8df71df57962', cpuused : u'0.03%', hypervisorversion 
: u'6.2.0', clusterid : u'af55ad36-15c8-424b-916b-db1550aae5ff', capabilities : 
u'xen-3.0-x86_64 , xen-3.0-x86_32p , hvm-3.0-x86_32 , hvm-3.0-x86_32p , 
hvm-3.0-x86_64', state : u'Up', memoryallocated : 268435456, networkkbswrite : 
5383, cpuspeed : 2400, cpusockets : 2, type : u'Routing', events : 
u'AgentDisconnected; PingTimeout; Remove; ShutdownRequested; AgentConnected; 
HostDown; ManagementServerDown; Ping; StartAgentRebalance', zonename : 
u'XenRT-Zone-0', podid : u'027c1e45-5867-40f8-8ad9-685b5eb63dd2', clustertype : 
u'CloudManaged', hahost : False, lastpinged : u'1970-01-16T22:04:56+', 
ipaddress : u'10.220.131.132', disconnected : u'2014-08-20T04:27:31+', name 
: u'cl08-15', networkkbsread : 2563, created : u'2014-08-20T04:25:28+', 
clustername : u'XenRT-Zone-0-Pod-0-Cluster-0', hypervisor : u'XenServer', 
islocalstorageactive : False, resourcestate : u'Enabled', hosttags : u'host2', 
podname : u'XenRT-Zone-0-Pod-0'},

[jira] [Created] (CLOUDSTACK-7392) [Automation] NPE thrown during Migration of VM

Chandan Purushothama created CLOUDSTACK-7392:


 Summary: [Automation] NPE thrown during Migration of VM
 Key: CLOUDSTACK-7392
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7392
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Automation
Affects Versions: 4.5.0
Reporter: Chandan Purushothama
Priority: Critical
 Fix For: 4.5.0



===
*NullPointerException:*
===

2014-08-20 14:08:47,538 INFO  [o.a.c.f.j.i.AsyncJobMonitor] 
(API-Job-Executor-60:ctx-3bfb9e76 job-8131) Add job-8131 into job monitoring
2014-08-20 14:08:47,538 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
(API-Job-Executor-60:ctx-3bfb9e76 job-8131) Executing AsyncJobVO {id:8131, 
userId: 2, accountId: 2, instanceType: None, instanceId: null, cmd: 
org.apache.cloudstack.api.command.admin.vm.MigrateVMCmd, cmdInfo: 
{response:json,ctxDetails:{\com.cloud.vm.VirtualMachine\:\cae46088-5aec-4305-ab43-bd71e740f1d2\,\com.cloud.host.Host\:\bb004159-d510-42b4-bfd5-878140a11f78\},virtualmachineid:cae46088-5aec-4305-ab43-bd71e740f1d2,cmdEventType:VM.MIGRATE,hostid:bb004159-d510-42b4-bfd5-878140a11f78,ctxUserId:2,httpmethod:GET,ctxAccountId:2,ctxStartEventId:32647,apiKey:NpffyWZkfwK7gPcNpx28Ohv6K56ftl57A409SyokqHjJ2ZNe3AvvF3F0teTETeIIqrtlcWpQOooM3cQyPveGXw,signature:ynKin/CRvRLp9JqWtSd1xbWhyxk\u003d},
 cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result: 
null, initMsid: 231707544610094, completeMsid: null, lastUpdated: null, 
lastPolled: null, created: null}
2014-08-20 14:08:47,545 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
(catalina-exec-24:ctx-0f778c79 ctx-cc81cab0 ctx-375c2462) submit async 
job-8131, details: AsyncJobVO {id:8131, userId: 2, accountId: 2, instanceType: 
None, instanceId: null, cmd: 
org.apache.cloudstack.api.command.admin.vm.MigrateVMCmd, cmdInfo: 
{response:json,ctxDetails:{\com.cloud.vm.VirtualMachine\:\cae46088-5aec-4305-ab43-bd71e740f1d2\,\com.cloud.host.Host\:\bb004159-d510-42b4-bfd5-878140a11f78\},virtualmachineid:cae46088-5aec-4305-ab43-bd71e740f1d2,cmdEventType:VM.MIGRATE,hostid:bb004159-d510-42b4-bfd5-878140a11f78,ctxUserId:2,httpmethod:GET,ctxAccountId:2,ctxStartEventId:32647,apiKey:NpffyWZkfwK7gPcNpx28Ohv6K56ftl57A409SyokqHjJ2ZNe3AvvF3F0teTETeIIqrtlcWpQOooM3cQyPveGXw,signature:ynKin/CRvRLp9JqWtSd1xbWhyxk\u003d},
 cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result: 
null, initMsid: 231707544610094, completeMsid: null, lastUpdated: null, 
lastPolled: null, created: null}
2014-08-20 14:08:47,547 DEBUG [c.c.a.ApiServlet] (catalina-exec-24:ctx-0f778c79 
ctx-cc81cab0 ctx-375c2462) ===END===  10.220.135.48 -- GET  
hostid=bb004159-d510-42b4-bfd5-878140a11f78virtualmachineid=cae46088-5aec-4305-ab43-bd71e740f1d2apiKey=NpffyWZkfwK7gPcNpx28Ohv6K56ftl57A409SyokqHjJ2ZNe3AvvF3F0teTETeIIqrtlcWpQOooM3cQyPveGXwcommand=migrateVirtualMachinesignature=ynKin%2FCRvRLp9JqWtSd1xbWhyxk%3Dresponse=json
2014-08-20 14:08:47,551 DEBUG [c.c.a.ApiServlet] 
(catalina-exec-21:ctx-b8261333) ===START===  10.220.135.48 -- GET  
jobid=dd179539-d888-47b6-8a9e-3c264ee23df4apiKey=NpffyWZkfwK7gPcNpx28Ohv6K56ftl57A409SyokqHjJ2ZNe3AvvF3F0teTETeIIqrtlcWpQOooM3cQyPveGXwcommand=queryAsyncJobResultresponse=jsonsignature=wjUpMS7U0V4T8bdiCPgLnglOAdE%3D
2014-08-20 14:08:47,599 DEBUG [c.c.a.ApiServlet] (catalina-exec-21:ctx-b8261333 
ctx-ef6ec76a ctx-b6cbec9c) ===END===  10.220.135.48 -- GET  
jobid=dd179539-d888-47b6-8a9e-3c264ee23df4apiKey=NpffyWZkfwK7gPcNpx28Ohv6K56ftl57A409SyokqHjJ2ZNe3AvvF3F0teTETeIIqrtlcWpQOooM3cQyPveGXwcommand=queryAsyncJobResultresponse=jsonsignature=wjUpMS7U0V4T8bdiCPgLnglOAdE%3D
2014-08-20 14:08:47,614 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
(API-Job-Executor-60:ctx-3bfb9e76 job-8131 ctx-aba0d6fb) Sync job-8132 
execution on object VmWorkJobQueue.1142
2014-08-20 14:08:47,616 WARN  [c.c.u.d.Merovingian2] 
(API-Job-Executor-60:ctx-3bfb9e76 job-8131 ctx-aba0d6fb) Was unable to find 
lock for the key vm_instance1142 and thread id 474572326
2014-08-20 14:08:49,187 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
(AsyncJobMgr-Heartbeat-1:ctx-77b6882f) Execute sync-queue item: SyncQueueItemVO 
{id:3265, queueId: 3264, contentType: AsyncJob, contentId: 8132, 
lastProcessMsid: null, lastprocessNumber: null, lastProcessTime: null, created: 
Wed Aug 20 14:08:47 UTC 2014}
2014-08-20 14:08:49,188 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
(AsyncJobMgr-Heartbeat-1:ctx-77b6882f) Schedule queued job-8132
2014-08-20 14:08:49,190 INFO  [o.a.c.f.j.i.AsyncJobMonitor] 
(Work-Job-Executor-124:ctx-f8d284d4 job-8131/job-8132) Add job-8132 into job 
monitoring
2014-08-20 14:08:49,190 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
(Work-Job-Executor-124:ctx-f8d284d4 job-8131/job-8132) Executing AsyncJobVO 
{id:8132, userId: 2, accountId: 2, instanceType: null,

[jira] [Commented] (CLOUDSTACK-7392) [Automation] NPE thrown during Migration of VM


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14106160#comment-14106160
 ] 

Chandan Purushothama commented on CLOUDSTACK-7392:
--

Management Logs are present at: 
http://xenrt.xs.citrite.net/xenrt/logs/job/798816/html/CS-10.220.135.39/cloudstack/management/management-server.log

 [Automation] NPE thrown during Migration of VM
 --

 Key: CLOUDSTACK-7392
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7392
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Automation
Affects Versions: 4.5.0
Reporter: Chandan Purushothama
Priority: Critical
 Fix For: 4.5.0


 ===
 *NullPointerException:*
 ===
 2014-08-20 14:08:47,538 INFO  [o.a.c.f.j.i.AsyncJobMonitor] 
 (API-Job-Executor-60:ctx-3bfb9e76 job-8131) Add job-8131 into job monitoring
 2014-08-20 14:08:47,538 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
 (API-Job-Executor-60:ctx-3bfb9e76 job-8131) Executing AsyncJobVO {id:8131, 
 userId: 2, accountId: 2, instanceType: None, instanceId: null, cmd: 
 org.apache.cloudstack.api.command.admin.vm.MigrateVMCmd, cmdInfo: 
 {response:json,ctxDetails:{\com.cloud.vm.VirtualMachine\:\cae46088-5aec-4305-ab43-bd71e740f1d2\,\com.cloud.host.Host\:\bb004159-d510-42b4-bfd5-878140a11f78\},virtualmachineid:cae46088-5aec-4305-ab43-bd71e740f1d2,cmdEventType:VM.MIGRATE,hostid:bb004159-d510-42b4-bfd5-878140a11f78,ctxUserId:2,httpmethod:GET,ctxAccountId:2,ctxStartEventId:32647,apiKey:NpffyWZkfwK7gPcNpx28Ohv6K56ftl57A409SyokqHjJ2ZNe3AvvF3F0teTETeIIqrtlcWpQOooM3cQyPveGXw,signature:ynKin/CRvRLp9JqWtSd1xbWhyxk\u003d},
  cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result: 
 null, initMsid: 231707544610094, completeMsid: null, lastUpdated: null, 
 lastPolled: null, created: null}
 2014-08-20 14:08:47,545 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
 (catalina-exec-24:ctx-0f778c79 ctx-cc81cab0 ctx-375c2462) submit async 
 job-8131, details: AsyncJobVO {id:8131, userId: 2, accountId: 2, 
 instanceType: None, instanceId: null, cmd: 
 org.apache.cloudstack.api.command.admin.vm.MigrateVMCmd, cmdInfo: 
 {response:json,ctxDetails:{\com.cloud.vm.VirtualMachine\:\cae46088-5aec-4305-ab43-bd71e740f1d2\,\com.cloud.host.Host\:\bb004159-d510-42b4-bfd5-878140a11f78\},virtualmachineid:cae46088-5aec-4305-ab43-bd71e740f1d2,cmdEventType:VM.MIGRATE,hostid:bb004159-d510-42b4-bfd5-878140a11f78,ctxUserId:2,httpmethod:GET,ctxAccountId:2,ctxStartEventId:32647,apiKey:NpffyWZkfwK7gPcNpx28Ohv6K56ftl57A409SyokqHjJ2ZNe3AvvF3F0teTETeIIqrtlcWpQOooM3cQyPveGXw,signature:ynKin/CRvRLp9JqWtSd1xbWhyxk\u003d},
  cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result: 
 null, initMsid: 231707544610094, completeMsid: null, lastUpdated: null, 
 lastPolled: null, created: null}
 2014-08-20 14:08:47,547 DEBUG [c.c.a.ApiServlet] 
 (catalina-exec-24:ctx-0f778c79 ctx-cc81cab0 ctx-375c2462) ===END===  
 10.220.135.48 -- GET  
 hostid=bb004159-d510-42b4-bfd5-878140a11f78virtualmachineid=cae46088-5aec-4305-ab43-bd71e740f1d2apiKey=NpffyWZkfwK7gPcNpx28Ohv6K56ftl57A409SyokqHjJ2ZNe3AvvF3F0teTETeIIqrtlcWpQOooM3cQyPveGXwcommand=migrateVirtualMachinesignature=ynKin%2FCRvRLp9JqWtSd1xbWhyxk%3Dresponse=json
 2014-08-20 14:08:47,551 DEBUG [c.c.a.ApiServlet] 
 (catalina-exec-21:ctx-b8261333) ===START===  10.220.135.48 -- GET  
 jobid=dd179539-d888-47b6-8a9e-3c264ee23df4apiKey=NpffyWZkfwK7gPcNpx28Ohv6K56ftl57A409SyokqHjJ2ZNe3AvvF3F0teTETeIIqrtlcWpQOooM3cQyPveGXwcommand=queryAsyncJobResultresponse=jsonsignature=wjUpMS7U0V4T8bdiCPgLnglOAdE%3D
 2014-08-20 14:08:47,599 DEBUG [c.c.a.ApiServlet] 
 (catalina-exec-21:ctx-b8261333 ctx-ef6ec76a ctx-b6cbec9c) ===END===  
 10.220.135.48 -- GET  
 jobid=dd179539-d888-47b6-8a9e-3c264ee23df4apiKey=NpffyWZkfwK7gPcNpx28Ohv6K56ftl57A409SyokqHjJ2ZNe3AvvF3F0teTETeIIqrtlcWpQOooM3cQyPveGXwcommand=queryAsyncJobResultresponse=jsonsignature=wjUpMS7U0V4T8bdiCPgLnglOAdE%3D
 2014-08-20 14:08:47,614 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
 (API-Job-Executor-60:ctx-3bfb9e76 job-8131 ctx-aba0d6fb) Sync job-8132 
 execution on object VmWorkJobQueue.1142
 2014-08-20 14:08:47,616 WARN  [c.c.u.d.Merovingian2] 
 (API-Job-Executor-60:ctx-3bfb9e76 job-8131 ctx-aba0d6fb) Was unable to find 
 lock for the key vm_instance1142 and thread id 474572326
 2014-08-20 14:08:49,187 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
 (AsyncJobMgr-Heartbeat-1:ctx-77b6882f) Execute sync-queue item: 
 SyncQueueItemVO {id:3265, queueId: 3264, contentType: AsyncJob, contentId: 
 8132, lastProcessMsid: null, lastprocessNumber: null, lastProcessTime: null, 
 created: Wed Aug 20 14:08:47 UTC 2014}
 2014-08-20 14:08:49,188 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]

[jira] [Updated] (CLOUDSTACK-7387) [Automation] Fix the script test_vpc_host_maintenance.py - Code is hardcoded to use certain host tags


 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7387?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Chandan Purushothama updated CLOUDSTACK-7387:
-

Description: 
*Scripts are present at: 
component/maint/test_vpc_host_maintenance.py

Currently script assumes that the deployment has hosts with host_tag 
HOST_TAGS_HERE and uses two service offerings with this host_tag. The script 
is hardcoded with the above information. The proper design and correction 
should be as follows.

# Find the cluster with two hosts
## If no two host cluster is found error out with proper message
# Edit the host tags on the two hosts to two different unique names
# Create corresponding service offerings with the two different unique names
# Conduct the tests
# In teardown script section of the script, edit the host tags on the hosts to 
empty.

  was:
*Script is at*: component/maint/.

Currently script assumes that the deployment has hosts with host_tag 
HOST_TAGS_HERE and uses two service offerings with this host_tag. The script 
is hardcoded with the above information. The proper design and correction 
should be as follows.

# Find the cluster with two hosts
## If no two host cluster is found error out with proper message
# Edit the host tags on the two hosts to two different unique names
# Create corresponding service offerings with the two different unique names
# Conduct the tests
# In teardown script section of the script, edit the host tags on the hosts to 
empty.


 [Automation] Fix the script test_vpc_host_maintenance.py - Code is 
 hardcoded to use certain host tags
 ---

 Key: CLOUDSTACK-7387
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7387
 Project: CloudStack
  Issue Type: Test
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Automation, Test
Affects Versions: 4.5.0
Reporter: Chandan Purushothama
Priority: Critical
 Fix For: 4.5.0


 *Scripts are present at: 
 component/maint/test_vpc_host_maintenance.py
 Currently script assumes that the deployment has hosts with host_tag 
 HOST_TAGS_HERE and uses two service offerings with this host_tag. The 
 script is hardcoded with the above information. The proper design and 
 correction should be as follows.
 # Find the cluster with two hosts
 ## If no two host cluster is found error out with proper message
 # Edit the host tags on the two hosts to two different unique names
 # Create corresponding service offerings with the two different unique names
 # Conduct the tests
 # In teardown script section of the script, edit the host tags on the hosts 
 to empty.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CLOUDSTACK-7387) [Automation] Fix the script test_vpc_host_maintenance.py - Code is hardcoded to use certain host tags


 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7387?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Chandan Purushothama updated CLOUDSTACK-7387:
-

Description: 
*Scripts are present at:*
component/maint/test_vpc_host_maintenance.py

Currently script assumes that the deployment has hosts with host_tag 
HOST_TAGS_HERE and uses two service offerings with this host_tag. The script 
is hardcoded with the above information. The proper design and correction 
should be as follows.

# Find the cluster with two hosts
## If no two host cluster is found error out with proper message
# Edit the host tags on the two hosts to two different unique names
# Create corresponding service offerings with the two different unique names
# Conduct the tests
# In teardown script section of the script, edit the host tags on the hosts to 
empty.

  was:
*Scripts are present at: 
component/maint/test_vpc_host_maintenance.py

Currently script assumes that the deployment has hosts with host_tag 
HOST_TAGS_HERE and uses two service offerings with this host_tag. The script 
is hardcoded with the above information. The proper design and correction 
should be as follows.

# Find the cluster with two hosts
## If no two host cluster is found error out with proper message
# Edit the host tags on the two hosts to two different unique names
# Create corresponding service offerings with the two different unique names
# Conduct the tests
# In teardown script section of the script, edit the host tags on the hosts to 
empty.


 [Automation] Fix the script test_vpc_host_maintenance.py - Code is 
 hardcoded to use certain host tags
 ---

 Key: CLOUDSTACK-7387
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7387
 Project: CloudStack
  Issue Type: Test
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Automation, Test
Affects Versions: 4.5.0
Reporter: Chandan Purushothama
Priority: Critical
 Fix For: 4.5.0


 *Scripts are present at:*
 component/maint/test_vpc_host_maintenance.py
 Currently script assumes that the deployment has hosts with host_tag 
 HOST_TAGS_HERE and uses two service offerings with this host_tag. The 
 script is hardcoded with the above information. The proper design and 
 correction should be as follows.
 # Find the cluster with two hosts
 ## If no two host cluster is found error out with proper message
 # Edit the host tags on the two hosts to two different unique names
 # Create corresponding service offerings with the two different unique names
 # Conduct the tests
 # In teardown script section of the script, edit the host tags on the hosts 
 to empty.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CLOUDSTACK-7387) [Automation] Fix the script test_vpc_host_maintenance.py - Code is hardcoded to use certain host tags


 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7387?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Chandan Purushothama updated CLOUDSTACK-7387:
-

Description: 
*Scripts is present at:*
component/maint/test_vpc_host_maintenance.py

Currently script assumes that the deployment has hosts with host_tag 
HOST_TAGS_HERE and uses two service offerings with this host_tag. The script 
is hardcoded with the above information. The proper design and correction 
should be as follows.

# Find the cluster with two hosts
## If no two host cluster is found error out with proper message
# Edit the host tags on the two hosts to two different unique names
# Create corresponding service offerings with the two different unique names
# Conduct the tests
# In teardown script section of the script, edit the host tags on the hosts to 
empty.

  was:
*Scripts are present at:*
component/maint/test_vpc_host_maintenance.py

Currently script assumes that the deployment has hosts with host_tag 
HOST_TAGS_HERE and uses two service offerings with this host_tag. The script 
is hardcoded with the above information. The proper design and correction 
should be as follows.

# Find the cluster with two hosts
## If no two host cluster is found error out with proper message
# Edit the host tags on the two hosts to two different unique names
# Create corresponding service offerings with the two different unique names
# Conduct the tests
# In teardown script section of the script, edit the host tags on the hosts to 
empty.


 [Automation] Fix the script test_vpc_host_maintenance.py - Code is 
 hardcoded to use certain host tags
 ---

 Key: CLOUDSTACK-7387
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7387
 Project: CloudStack
  Issue Type: Test
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Automation, Test
Affects Versions: 4.5.0
Reporter: Chandan Purushothama
Priority: Critical
 Fix For: 4.5.0


 *Scripts is present at:*
 component/maint/test_vpc_host_maintenance.py
 Currently script assumes that the deployment has hosts with host_tag 
 HOST_TAGS_HERE and uses two service offerings with this host_tag. The 
 script is hardcoded with the above information. The proper design and 
 correction should be as follows.
 # Find the cluster with two hosts
 ## If no two host cluster is found error out with proper message
 # Edit the host tags on the two hosts to two different unique names
 # Create corresponding service offerings with the two different unique names
 # Conduct the tests
 # In teardown script section of the script, edit the host tags on the hosts 
 to empty.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CLOUDSTACK-7387) [Automation] Fix the script test_vpc_host_maintenance.py - Code is hardcoded to use certain host tags


 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7387?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Chandan Purushothama updated CLOUDSTACK-7387:
-

Description: 
*Script is present at:*
component/maint/test_vpc_host_maintenance.py

Currently script assumes that the deployment has hosts with host_tag 
HOST_TAGS_HERE and uses two service offerings with this host_tag. The script 
is hardcoded with the above information. The proper design and correction 
should be as follows.

# Find the cluster with two hosts
## If no two host cluster is found error out with proper message
# Edit the host tags on the two hosts to two different unique names
# Create corresponding service offerings with the two different unique names
# Conduct the tests
# In teardown script section of the script, edit the host tags on the hosts to 
empty.

  was:
*Scripts is present at:*
component/maint/test_vpc_host_maintenance.py

Currently script assumes that the deployment has hosts with host_tag 
HOST_TAGS_HERE and uses two service offerings with this host_tag. The script 
is hardcoded with the above information. The proper design and correction 
should be as follows.

# Find the cluster with two hosts
## If no two host cluster is found error out with proper message
# Edit the host tags on the two hosts to two different unique names
# Create corresponding service offerings with the two different unique names
# Conduct the tests
# In teardown script section of the script, edit the host tags on the hosts to 
empty.


 [Automation] Fix the script test_vpc_host_maintenance.py - Code is 
 hardcoded to use certain host tags
 ---

 Key: CLOUDSTACK-7387
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7387
 Project: CloudStack
  Issue Type: Test
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Automation, Test
Affects Versions: 4.5.0
Reporter: Chandan Purushothama
Priority: Critical
 Fix For: 4.5.0


 *Script is present at:*
 component/maint/test_vpc_host_maintenance.py
 Currently script assumes that the deployment has hosts with host_tag 
 HOST_TAGS_HERE and uses two service offerings with this host_tag. The 
 script is hardcoded with the above information. The proper design and 
 correction should be as follows.
 # Find the cluster with two hosts
 ## If no two host cluster is found error out with proper message
 # Edit the host tags on the two hosts to two different unique names
 # Create corresponding service offerings with the two different unique names
 # Conduct the tests
 # In teardown script section of the script, edit the host tags on the hosts 
 to empty.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Created] (CLOUDSTACK-7393) [Automation] Fix the script test_vpc_vm_life_cycle.py - Code is hardcoded to use certain host tags

Chandan Purushothama created CLOUDSTACK-7393:


 Summary: [Automation] Fix the script test_vpc_vm_life_cycle.py - 
Code is hardcoded to use certain host tags
 Key: CLOUDSTACK-7393
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7393
 Project: CloudStack
  Issue Type: Test
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Automation, Test
Affects Versions: 4.5.0
Reporter: Chandan Purushothama
Priority: Critical
 Fix For: 4.5.0


*Script is present at:*
component/test_vpc_vm_life_cycle.py

Currently script assumes that the deployment has hosts with host_tags host1 
and host2 and uses two service offerings with these host_tags. The script is 
hardcoded with the above information. The proper design and correction should 
be as follows.

Find the cluster with two hosts
If no two host cluster is found error out with proper message
Edit the host tags on the two hosts to two different unique names
Create corresponding service offerings with the two different unique names
Conduct the tests
In teardown script section of the script, edit the host tags on the hosts 
to empty.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Created] (CLOUDSTACK-7394) Caller should be owner after creating template from snapshot/volume

2014-08-21 Thread ASF subversion and git services (JIRA)

Min Chen created CLOUDSTACK-7394:


 Summary: Caller should be owner after creating template from 
snapshot/volume
 Key: CLOUDSTACK-7394
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7394
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: API
Affects Versions: 4.0.0
Reporter: Min Chen
Assignee: Min Chen
Priority: Critical
 Fix For: 4.5.0


Caller should be owner of template when creating template from snapshot or 
template. Currently the owner is set as snapshot or volume owner and they are 
charged, this is wrong.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CLOUDSTACK-7394) Caller should be owner after creating template from snapshot/volume


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14106233#comment-14106233
 ] 

ASF subversion and git services commented on CLOUDSTACK-7394:
-

Commit 1436ce62b61a2783a7c9d56d8611c5cb448cfd4e in cloudstack's branch 
refs/heads/master from [~minchen07]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=1436ce6 ]

CLOUDSTACK-7394:Caller should be owner after creating template from
snapshot/volume.


 Caller should be owner after creating template from snapshot/volume
 ---

 Key: CLOUDSTACK-7394
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7394
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: API
Affects Versions: 4.0.0
Reporter: Min Chen
Assignee: Min Chen
Priority: Critical
 Fix For: 4.5.0


 Caller should be owner of template when creating template from snapshot or 
 template. Currently the owner is set as snapshot or volume owner and they are 
 charged, this is wrong.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Resolved] (CLOUDSTACK-7394) Caller should be owner after creating template from snapshot/volume


 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7394?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Min Chen resolved CLOUDSTACK-7394.
--

Resolution: Fixed

The account_id for the template created should be the caller account id, also 
resource_count table should be properly updated for caller instead of 
volume/snapshot owner.

 Caller should be owner after creating template from snapshot/volume
 ---

 Key: CLOUDSTACK-7394
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7394
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: API
Affects Versions: 4.0.0
Reporter: Min Chen
Assignee: Min Chen
Priority: Critical
 Fix For: 4.5.0


 Caller should be owner of template when creating template from snapshot or 
 template. Currently the owner is set as snapshot or volume owner and they are 
 charged, this is wrong.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Resolved] (CLOUDSTACK-7344) VOLUME.DELETE usage event missing for VM's in ERROR state


 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Min Chen resolved CLOUDSTACK-7344.
--

Resolution: Fixed

 VOLUME.DELETE usage event missing for VM's in ERROR state
 -

 Key: CLOUDSTACK-7344
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7344
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Storage Controller
Affects Versions: 4.2.0
Reporter: Min Chen
Assignee: Min Chen
Priority: Critical
 Fix For: 4.5.0


 CloudStack is not generating the VOLUME.DELETE event for VM's which are 
 failed to be deployed. That is if the VM deployment is failed for some 
 reason. The VM state is updated as ERROR and cleanup is performed to release 
 the resources allocated to the VM. As a part of cleanup volume state is 
 updated as 'DESTROY' but no VOLUME.DELETE event is generated causing the 
 usage issue customer is seeing now.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CLOUDSTACK-7344) VOLUME.DELETE usage event missing for VM's in ERROR state


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14106241#comment-14106241
 ] 

Min Chen commented on CLOUDSTACK-7344:
--

When we mark a volume as destroyed (not really expunged), we should always 
publish VOLUME.DELETE event.

 VOLUME.DELETE usage event missing for VM's in ERROR state
 -

 Key: CLOUDSTACK-7344
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7344
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Storage Controller
Affects Versions: 4.2.0
Reporter: Min Chen
Assignee: Min Chen
Priority: Critical
 Fix For: 4.5.0


 CloudStack is not generating the VOLUME.DELETE event for VM's which are 
 failed to be deployed. That is if the VM deployment is failed for some 
 reason. The VM state is updated as ERROR and cleanup is performed to release 
 the resources allocated to the VM. As a part of cleanup volume state is 
 updated as 'DESTROY' but no VOLUME.DELETE event is generated causing the 
 usage issue customer is seeing now.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CLOUDSTACK-7266) Deleting account is not cleaning the snapshot entries in secondary storage


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14106256#comment-14106256
 ] 

Min Chen commented on CLOUDSTACK-7266:
--

This is the reason indicated from SSVM log:
2014-08-06 06:04:52,773 WARN  [storage.resource.NfsSecondaryStorageResource] 
(agentRequest-Handler-1:null) Failed to delete file 
/mnt/SecStorage/0e8da06e-0788-3efb-86a6-b0705a2205d3/snapshots/4/19/*, err=rm: 
cannot remove 
`/mnt/SecStorage/0e8da06e-0788-3efb-86a6-b0705a2205d3/snapshots/4/19/9ef00274-3b42-4e4d-81a2-13e055f7f162':
 Is a directoryrm: cannot remove 
`/mnt/SecStorage/0e8da06e-0788-3efb-86a6-b0705a2205d3/snapshots/4/19/b3086b0a-d8fb-453f-9339-7b4ff4b12a02':
 Is a directoryrm: cannot remove 
`/mnt/SecStorage/0e8da06e-0788-3efb-86a6-b0705a2205d3/snapshots/4/19/d73794f8-0ef1-4a06-a800-8ae9ed344742':
 Is a directory
The snapshot directory has nested directory, we should use recursive option for 
rm command.

 Deleting account is not cleaning the snapshot entries in secondary storage
 --

 Key: CLOUDSTACK-7266
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7266
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Snapshot
Affects Versions: 4.5.0
Reporter: manasaveloori
Assignee: Min Chen
Priority: Critical
 Fix For: 4.5.0

 Attachments: cloud.log-20140806.gz, management-server.rar, 
 mysqldump45.dmp


 Steps:
 1. Deployed CS with ESXi5.1
 2. Created VM with data disk.
 3. Created snapshots on both root and data disks.
 4. Now deleted the account.
  id: 4
account_name: test
uuid: c55b8251-7bb0-4531-bd7e-7811d55160e6
type: 0
   domain_id: 1
   state: enabled
 removed: 2014-08-06 06:04:50
  cleanup_needed: 0
  network_domain: NULL
 default_zone_id: NULL
 default: 0
 5. All the snapshots got deleted as apart of account clean up in DB
 mysql select * from snapshots where account_id=4\G;
 *** 1. row ***
   id: 38
   data_center_id: 1
   account_id: 4
domain_id: 1
volume_id: 18
 disk_offering_id: 1
   status: Destroyed
 path: NULL
 name: testvmacct1_ROOT-11_2014080605
 uuid: 716f0dd5-056e-4cab-b814-125fc6fe84e6
snapshot_type: 0
 type_description: MANUAL
 size: 2147483648
  created: 2014-08-06 05:44:44
  removed: NULL
   backup_snap_id: NULL
 swift_id: NULL
   sechost_id: NULL
 prev_snap_id: NULL
  hypervisor_type: VMware
  version: 2.2
s3_id: NULL
 *** 2. row ***
   id: 39
   data_center_id: 1
   account_id: 4
domain_id: 1
volume_id: 18
 disk_offering_id: 1
   status: Destroyed
 path: NULL
 name: testvmacct1_ROOT-11_20140806054650
 uuid: ea949547-5ef7-40b0-99a6-152d346a0ad6
snapshot_type: 3
 type_description: HOURLY
 size: 2147483648
  created: 2014-08-06 05:46:50
  removed: NULL
   backup_snap_id: NULL
 swift_id: NULL
   sechost_id: NULL
 prev_snap_id: NULL
  hypervisor_type: VMware
  version: 2.2
s3_id: NULL
 *** 3. row ***
   id: 40
   data_center_id: 1
   account_id: 4
domain_id: 1
volume_id: 18
 disk_offering_id: 1
   status: Destroyed
 path: NULL
 name: testvmacct1_ROOT-11_20140806055150
 uuid: b8af0810-b08a-40bd-a114-13a4d75907ca
snapshot_type: 4
 type_description: DAILY
 size: 2147483648
  created: 2014-08-06 05:51:50
  removed: NULL
   backup_snap_id: NULL
 swift_id: NULL
   sechost_id: NULL
 prev_snap_id: NULL
  hypervisor_type: VMware
  version: 2.2
s3_id: NULL
 *** 4. row ***
   id: 41
   data_center_id: 1
   account_id: 4
domain_id: 1
volume_id: 18
 disk_offering_id: 1
   status: Destroyed
 path: NULL
 name: testvmacct1_ROOT-11_20140806055150
 uuid: dda5cfb7-f5ab-4bd0-bdd3-953932e77f5e
snapshot_type: 5
 type_description: WEEKLY
 size: 2147483648
  created: 2014-08-06 05:51:50
  removed: NULL
   backup_snap_id: NULL
 swift_id: NULL
   sechost_id: NULL
 prev_snap_id: NULL
  hypervisor_type: VMware
  version: 2.2
s3_id: NULL
 *** 5. row ***

[jira] [Resolved] (CLOUDSTACK-7349) [Automation] CloudRuntimeException with stacktrace in MS log


 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7349?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jayapal Reddy resolved CLOUDSTACK-7349.
---

Resolution: Fixed

 [Automation] CloudRuntimeException  with stacktrace in  MS log
 --

 Key: CLOUDSTACK-7349
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7349
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Management Server
Affects Versions: 4.5.0
Reporter: Rayees Namathponnan
Assignee: Jayapal Reddy
Priority: Critical
 Fix For: 4.5.0


 This issue observed during automation run, there are many InvalidParameter 
 Exception with stacktrace, this should be handled properly 
 2014-08-14 00:34:16,190 ERROR [c.c.a.ApiAsyncJobDispatcher] 
 (API-Job-Executor-96:ctx-7c9884ce job-6881) Unexpected exception while 
 executin
 g 
 org.apache.cloudstack.api.command.user.loadbalancer.AssignToLoadBalancerRuleCmd
 com.cloud.utils.exception.CloudRuntimeException: Failed to add specified 
 loadbalancerruleid for vms [973]
 at 
 com.cloud.network.lb.LoadBalancingRulesManagerImpl.assignToLoadBalancer(LoadBalancingRulesManagerImpl.java:1139)
 at sun.reflect.GeneratedMethodAccessor774.invoke(Unknown Source)
 at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 at java.lang.reflect.Method.invoke(Method.java:606)
 at 
 org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317)
 at 
 org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
 at 
 org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
 at 
 org.apache.cloudstack.network.contrail.management.EventUtils$EventInterceptor.invoke(EventUtils.java:106)
 at 
 org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161)
 at 
 com.cloud.event.ActionEventInterceptor.invoke(ActionEventInterceptor.java:51)
 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 com.sun.proxy.$Proxy137.assignToLoadBalancer(Unknown Source)
 at 
 org.apache.cloudstack.api.command.user.loadbalancer.AssignToLoadBalancerRuleCmd.execute(AssignToLoadBalancerRuleCmd.java:169)
 at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:141)
 at 
 com.cloud.api.ApiAsyncJobDispatcher.runJob(ApiAsyncJobDispatcher.java:108)
 at 
 org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:503)
 at 
 org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49)
 at 
 org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
 at 
 org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
 at 
 org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
 at 
 org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46)
 at 
 org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.run(AsyncJobManagerImpl.java:460)
 at 
 java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
 at java.util.concurrent.FutureTask.run(FutureTask.java:262)
 at 
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
 at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
 at java.lang.Thread.run(Thread.java:744)
 2014-08-14 00:34:16,191 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
 (API-Job-Executor-96:ctx-7c9884ce job-6881) Complete async job-6881, 
 jobStatus: FAILED, resultCode: 530, result: 
 org.apache.cloudstack.api.response.ExceptionResponse/null/{uuidList:[],errorcode:530,errortext:Failed
  to add specified loadbalancerruleid for vms [973]}



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Resolved] (CLOUDSTACK-7104) VPC public ips not configured after network implement from implementing


 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jayapal Reddy resolved CLOUDSTACK-7104.
---

Resolution: Fixed

 VPC public ips not configured after network implement from implementing
 ---

 Key: CLOUDSTACK-7104
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7104
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Network Controller
Affects Versions: 4.0.0
Reporter: Jayapal Reddy
Assignee: Jayapal Reddy
 Fix For: 4.5.0


 Reproducing steps:
 1. create vpc and create tier in vpc.
 2. Set network.gc to low in the global settings.
 3. Acquire ip and configure PF rule on the ip.
 4. Stop all the vms in the tier.
 5. network will remove all the rules and ips on the router after the network 
 gc interval.
 6. Now start the vm, observe that the PF public ip is not configured on the 
 interface. 



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Resolved] (CLOUDSTACK-7213) Cloud-setup-databases script should not fail if no SELinux is installed


 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jayapal Reddy resolved CLOUDSTACK-7213.
---

Resolution: Fixed

 Cloud-setup-databases script should not fail if no SELinux is installed
 ---

 Key: CLOUDSTACK-7213
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7213
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Install and Setup
Affects Versions: 4.0.0
Reporter: Jayapal Reddy
Assignee: Jayapal Reddy
 Fix For: 4.5.0


 We should update ou scripts to check if Selinux is installed, and only if it 
 is installed check if it is set to permissive mode, if it is not installed we 
 should not fail (as far as I can tell we do not have dependancy on SElinux)



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CLOUDSTACK-7218) [Automation] NPE observed while deleting account in automation run


 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jayapal Reddy updated CLOUDSTACK-7218:
--

Status: Reviewable  (was: In Progress)

 [Automation] NPE observed while deleting account in automation run
 --

 Key: CLOUDSTACK-7218
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7218
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Management Server
Affects Versions: 4.5.0
 Environment: KVM (RHEL 6.3)
Reporter: Rayees Namathponnan
Assignee: Jayapal Reddy
Priority: Critical
 Fix For: 4.5.0


 This issue is observed in automation log, NPE thrown while deleting account
 2014-07-31 02:20:56,102 DEBUG [c.c.n.r.RulesManagerImpl] 
 (API-Job-Executor-2:ctx-523291d6 job-5302 ctx-28b51397) There are no static 
 nat
  rules to apply for ip id=28
 2014-07-31 02:20:56,105 WARN  [c.c.u.AccountManagerImpl] 
 (API-Job-Executor-2:ctx-523291d6 job-5302 ctx-28b51397) Failed to cleanup 
 accou
 nt 
 Acct[b1cf2381-ab36-4ebc-90ff-f08acaf5e02d-test-account-TestVmNetworkOperations-test_add_static_nat_rule_1_ISOLATED-YI0OCS]
  due to
 java.lang.NullPointerException
 at 
 com.cloud.network.rules.RulesManagerImpl.createStaticNatForIp(RulesManagerImpl.java:1391)
 at 
 com.cloud.network.rules.RulesManagerImpl.applyStaticNatForIp(RulesManagerImpl.java:1321)
 at 
 com.cloud.network.rules.RulesManagerImpl.revokeAllPFAndStaticNatRulesForIp(RulesManagerImpl.java:1104)
 at sun.reflect.GeneratedMethodAccessor524.invoke(Unknown Source)
 at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 at java.lang.reflect.Method.invoke(Method.java:606)
 at 
 org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317)
 at 
 org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
 at 
 org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
 at 
 org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91)
 at 
 org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
 at 
 org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
 at com.sun.proxy.$Proxy105.revokeAllPFAndStaticNatRulesForIp(Unknown 
 Source)
 at 
 com.cloud.network.IpAddressManagerImpl.cleanupIpResources(IpAddressManagerImpl.java:540)
 at 
 com.cloud.network.IpAddressManagerImpl.applyIpAssociations(IpAddressManagerImpl.java:936)
 at 
 org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.cleanupNetworkResources(NetworkOrchestrator.java:2650)
 at 
 org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.destroyNetwork(NetworkOrchestrator.java:2196)
 at 
 com.cloud.user.AccountManagerImpl.cleanupAccount(AccountManagerImpl.java:793)
 at 
 com.cloud.user.AccountManagerImpl.deleteAccount(AccountManagerImpl.java:667)
 at 
 com.cloud.user.AccountManagerImpl.deleteUserAccount(AccountManagerImpl.java:1441)
 at sun.reflect.GeneratedMethodAccessor542.invoke(Unknown Source)
 at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 at java.lang.reflect.Method.invoke(Method.java:606)
 at 
 org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317)
 at 
 org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
 at 
 org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
 at 
 org.apache.cloudstack.network.contrail.management.EventUtils$EventInterceptor.invoke(EventUtils.java:106)
 at 
 org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161)
 at 
 com.cloud.event.ActionEventInterceptor.invoke(ActionEventInterceptor.java:51)
 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 com.sun.proxy.$Proxy102.deleteUserAccount(Unknown Source)

[jira] [Commented] (CLOUDSTACK-7273) Send notification to dev list if there are db related changes


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14106452#comment-14106452
 ] 

Animesh Chaturvedi commented on CLOUDSTACK-7273:


This is more like a task not a bug, so why is this logged here. May be I am  
missing some context

 Send notification to dev list if there are db related changes
 -

 Key: CLOUDSTACK-7273
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7273
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
Reporter: Nitin Mehta
Priority: Critical
 Fix For: 4.5.0


 Send notification to dev list if there are db related changes in the schema 
 file or the java upgrade file.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CLOUDSTACK-7273) Send notification to dev list if there are db related changes


 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Animesh Chaturvedi updated CLOUDSTACK-7273:
---

Priority: Major  (was: Critical)

 Send notification to dev list if there are db related changes
 -

 Key: CLOUDSTACK-7273
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7273
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
Reporter: Nitin Mehta
 Fix For: 4.5.0


 Send notification to dev list if there are db related changes in the schema 
 file or the java upgrade file.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Assigned] (CLOUDSTACK-300) Creation of compute offering allow combination of local storage + HA

2014-08-21 Thread Saksham Srivastava (JIRA)


 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Saksham Srivastava reassigned CLOUDSTACK-300:
-

Assignee: Saksham Srivastava

 Creation of  compute offering allow   combination of local storage + HA
 ---

 Key: CLOUDSTACK-300
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-300
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Management Server
Affects Versions: pre-4.0.0
 Environment: Git Revision: fb88d2e9de795528e8b9f7e16d8a89eacc5a7e12
 Git URL: https://git-wip-us.apache.org/repos/asf/incubator-cloudstack.git
Reporter: prashant kumar mishra
Assignee: Saksham Srivastava
Priority: Minor
 Fix For: 4.4.0


 HA is not supported for local storage, but crate compute offering allow user 
 to create a compute offering with a combination of Local storage and HA 
 together.  we should have a check for this combination to make sure  that it 
 should not allowed on UI/API level.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CLOUDSTACK-7311) XenServer does not support shrink data disk. FS on cwiki needs to be corrected


 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Animesh Chaturvedi updated CLOUDSTACK-7311:
---

Assignee: Anthony Xu

 XenServer does not support shrink data disk. FS on cwiki needs to be corrected
 --

 Key: CLOUDSTACK-7311
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7311
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Doc
Affects Versions: 4.5.0
Reporter: Chandan Purushothama
Assignee: Anthony Xu
Priority: Critical
 Fix For: 4.5.0


 Hello Marcus,
 Based on https://issues.apache.org/jira/browse/CLOUDSTACK-7310, Please make 
 the corresponding changes to Feature FS at 
 https://cwiki.apache.org/confluence/display/CLOUDSTACK/Resize+Data+Volumes,
 Thank you,
 Chandan.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CLOUDSTACK-7289) Bugs seen when declaring a class variable as native type (long) and have its getter method returning the corresponding object (Long) and vice versa


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14106461#comment-14106461
 ] 

Animesh Chaturvedi commented on CLOUDSTACK-7289:


I was hoping Coverity will catch it but because of autoboxing it will consider 
it ok. The NPE you mention would be because of another field. Can we write a 
script to check the occurrences?

 Bugs seen when declaring a class variable as native type (long) and have its 
 getter method returning the corresponding object (Long) and vice versa
 ---

 Key: CLOUDSTACK-7289
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7289
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
Affects Versions: 4.5.0
Reporter: Nitin Mehta
Priority: Critical
 Fix For: 4.5.0


 Declare a variable as native type (long) and have its getter method
 returning the corresponding object (Long). This is what I fixed with 
 CLOUDSTACK-7272.
 Example below. This should be fixed in the entire code base.
 Autoboxing causes NPE or defaults some values. The vice versa should be
 fixed as well meaning declaring hostId as Long and returning as native
 type (long).
 long hostId
 Long getHostId(){
 return hostId;
 }
 Right Implementation (hostId is declared as Long)
 Long hostId;
 Long getHostId(){
 return hostId;
 }



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (CLOUDSTACK-7311) XenServer does not support shrink data disk. FS on cwiki needs to be corrected


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14106463#comment-14106463
 ] 

Animesh Chaturvedi commented on CLOUDSTACK-7311:


Anthony do you mind clarifying in FS

 XenServer does not support shrink data disk. FS on cwiki needs to be corrected
 --

 Key: CLOUDSTACK-7311
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7311
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Doc
Affects Versions: 4.5.0
Reporter: Chandan Purushothama
Assignee: Anthony Xu
Priority: Critical
 Fix For: 4.5.0


 Hello Marcus,
 Based on https://issues.apache.org/jira/browse/CLOUDSTACK-7310, Please make 
 the corresponding changes to Feature FS at 
 https://cwiki.apache.org/confluence/display/CLOUDSTACK/Resize+Data+Volumes,
 Thank you,
 Chandan.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CLOUDSTACK-7339) [UI] Delete Host button is missing in the UI


 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Animesh Chaturvedi updated CLOUDSTACK-7339:
---

Assignee: Brian Federle

 [UI] Delete Host button is missing in the UI
 

 Key: CLOUDSTACK-7339
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7339
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: UI
Affects Versions: 4.5.0
Reporter: Abhinav Roy
Assignee: Brian Federle
Priority: Critical
 Fix For: 4.5.0

 Attachments: delete_host_missing.jpg


 Steps :
 ===
 1. Login to CS from UI
 2. Goto Infrastructure -  Hosts -  Hostname and put the host to 
 maintenance mode.
 3. Try to delete the Host from UI
 Expected behavior :
 ==
 UI button to delete host should be present.
 Observed behavior :
 ==
 UI button to delete host is missing.
 Attaching a screenshot for the same.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CLOUDSTACK-7369) assignVirtualMachine API name not intuitive


 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Animesh Chaturvedi updated CLOUDSTACK-7369:
---

Priority: Major  (was: Critical)

 assignVirtualMachine API name not intuitive
 ---

 Key: CLOUDSTACK-7369
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7369
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: API
Affects Versions: 4.5.0
Reporter: Nitin Mehta
 Fix For: 4.5.0


 I just went to a meetup and was talking to [~jlkinsel] who was talking about 
 moving vms from one account to another and was doing it manually through a 
 huge set of db queries. We already had this api in place since 3.0.x but 
 folks are not aware of it due to unintuitive api name. I can think of 2 
 solutions at the moment.
 1. Create another api say changeVmOwnership and internally point it to the 
 same logic as assignVirtualMachine. Mark assignVirtualMachine as deprecated 
 api name for 5.0
 2. OR in the api documentation name it as changeVmOwnership so that folks 
 would know such functionality exists and is available through APIs



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CLOUDSTACK-7392) [Automation] NPE thrown during Migration of VM


 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7392?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Animesh Chaturvedi updated CLOUDSTACK-7392:
---

Assignee: Koushik Das

 [Automation] NPE thrown during Migration of VM
 --

 Key: CLOUDSTACK-7392
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7392
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Automation
Affects Versions: 4.5.0
Reporter: Chandan Purushothama
Assignee: Koushik Das
Priority: Critical
 Fix For: 4.5.0


 ===
 *NullPointerException:*
 ===
 2014-08-20 14:08:47,538 INFO  [o.a.c.f.j.i.AsyncJobMonitor] 
 (API-Job-Executor-60:ctx-3bfb9e76 job-8131) Add job-8131 into job monitoring
 2014-08-20 14:08:47,538 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
 (API-Job-Executor-60:ctx-3bfb9e76 job-8131) Executing AsyncJobVO {id:8131, 
 userId: 2, accountId: 2, instanceType: None, instanceId: null, cmd: 
 org.apache.cloudstack.api.command.admin.vm.MigrateVMCmd, cmdInfo: 
 {response:json,ctxDetails:{\com.cloud.vm.VirtualMachine\:\cae46088-5aec-4305-ab43-bd71e740f1d2\,\com.cloud.host.Host\:\bb004159-d510-42b4-bfd5-878140a11f78\},virtualmachineid:cae46088-5aec-4305-ab43-bd71e740f1d2,cmdEventType:VM.MIGRATE,hostid:bb004159-d510-42b4-bfd5-878140a11f78,ctxUserId:2,httpmethod:GET,ctxAccountId:2,ctxStartEventId:32647,apiKey:NpffyWZkfwK7gPcNpx28Ohv6K56ftl57A409SyokqHjJ2ZNe3AvvF3F0teTETeIIqrtlcWpQOooM3cQyPveGXw,signature:ynKin/CRvRLp9JqWtSd1xbWhyxk\u003d},
  cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result: 
 null, initMsid: 231707544610094, completeMsid: null, lastUpdated: null, 
 lastPolled: null, created: null}
 2014-08-20 14:08:47,545 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
 (catalina-exec-24:ctx-0f778c79 ctx-cc81cab0 ctx-375c2462) submit async 
 job-8131, details: AsyncJobVO {id:8131, userId: 2, accountId: 2, 
 instanceType: None, instanceId: null, cmd: 
 org.apache.cloudstack.api.command.admin.vm.MigrateVMCmd, cmdInfo: 
 {response:json,ctxDetails:{\com.cloud.vm.VirtualMachine\:\cae46088-5aec-4305-ab43-bd71e740f1d2\,\com.cloud.host.Host\:\bb004159-d510-42b4-bfd5-878140a11f78\},virtualmachineid:cae46088-5aec-4305-ab43-bd71e740f1d2,cmdEventType:VM.MIGRATE,hostid:bb004159-d510-42b4-bfd5-878140a11f78,ctxUserId:2,httpmethod:GET,ctxAccountId:2,ctxStartEventId:32647,apiKey:NpffyWZkfwK7gPcNpx28Ohv6K56ftl57A409SyokqHjJ2ZNe3AvvF3F0teTETeIIqrtlcWpQOooM3cQyPveGXw,signature:ynKin/CRvRLp9JqWtSd1xbWhyxk\u003d},
  cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result: 
 null, initMsid: 231707544610094, completeMsid: null, lastUpdated: null, 
 lastPolled: null, created: null}
 2014-08-20 14:08:47,547 DEBUG [c.c.a.ApiServlet] 
 (catalina-exec-24:ctx-0f778c79 ctx-cc81cab0 ctx-375c2462) ===END===  
 10.220.135.48 -- GET  
 hostid=bb004159-d510-42b4-bfd5-878140a11f78virtualmachineid=cae46088-5aec-4305-ab43-bd71e740f1d2apiKey=NpffyWZkfwK7gPcNpx28Ohv6K56ftl57A409SyokqHjJ2ZNe3AvvF3F0teTETeIIqrtlcWpQOooM3cQyPveGXwcommand=migrateVirtualMachinesignature=ynKin%2FCRvRLp9JqWtSd1xbWhyxk%3Dresponse=json
 2014-08-20 14:08:47,551 DEBUG [c.c.a.ApiServlet] 
 (catalina-exec-21:ctx-b8261333) ===START===  10.220.135.48 -- GET  
 jobid=dd179539-d888-47b6-8a9e-3c264ee23df4apiKey=NpffyWZkfwK7gPcNpx28Ohv6K56ftl57A409SyokqHjJ2ZNe3AvvF3F0teTETeIIqrtlcWpQOooM3cQyPveGXwcommand=queryAsyncJobResultresponse=jsonsignature=wjUpMS7U0V4T8bdiCPgLnglOAdE%3D
 2014-08-20 14:08:47,599 DEBUG [c.c.a.ApiServlet] 
 (catalina-exec-21:ctx-b8261333 ctx-ef6ec76a ctx-b6cbec9c) ===END===  
 10.220.135.48 -- GET  
 jobid=dd179539-d888-47b6-8a9e-3c264ee23df4apiKey=NpffyWZkfwK7gPcNpx28Ohv6K56ftl57A409SyokqHjJ2ZNe3AvvF3F0teTETeIIqrtlcWpQOooM3cQyPveGXwcommand=queryAsyncJobResultresponse=jsonsignature=wjUpMS7U0V4T8bdiCPgLnglOAdE%3D
 2014-08-20 14:08:47,614 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
 (API-Job-Executor-60:ctx-3bfb9e76 job-8131 ctx-aba0d6fb) Sync job-8132 
 execution on object VmWorkJobQueue.1142
 2014-08-20 14:08:47,616 WARN  [c.c.u.d.Merovingian2] 
 (API-Job-Executor-60:ctx-3bfb9e76 job-8131 ctx-aba0d6fb) Was unable to find 
 lock for the key vm_instance1142 and thread id 474572326
 2014-08-20 14:08:49,187 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
 (AsyncJobMgr-Heartbeat-1:ctx-77b6882f) Execute sync-queue item: 
 SyncQueueItemVO {id:3265, queueId: 3264, contentType: AsyncJob, contentId: 
 8132, lastProcessMsid: null, lastprocessNumber: null, lastProcessTime: null, 
 created: Wed Aug 20 14:08:47 UTC 2014}
 2014-08-20 14:08:49,188 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
 (AsyncJobMgr-Heartbeat-1:ctx-77b6882f) Schedule queued job-8132
 2014-08-20 14:08:49,190 INFO  [o.a.c.f.j.i.AsyncJobMonitor]

[jira] [Commented] (CLOUDSTACK-7347) Unable to access VM trough ConsoleProxy


[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7347?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14106477#comment-14106477
 ] 

Animesh Chaturvedi commented on CLOUDSTACK-7347:


Rayees is this still an issue

 Unable to access VM trough ConsoleProxy
 ---

 Key: CLOUDSTACK-7347
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7347
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Management Server
Affects Versions: 4.5.0
Reporter: Rayees Namathponnan
Assignee: Rayees Namathponnan
Priority: Blocker
 Fix For: 4.5.0

 Attachments: cloud.out


 Steps to reproduce 
 1) Deploy advanced zone in KVM 
 2) Deploy VM
 3) Access the vm trough console proxy 
 Result 
 Unable to access the VM trough console proxy, observed below error in Console 
 proxy cloud.log
 2014-08-14 15:40:38,525 ERROR [resource.consoleproxy.ConsoleProxyResource] 
 (Console Proxy GC Thread:null) Unable to send out load info due to Unable to 
 post agent control request as link is not available
 com.cloud.exception.AgentControlChannelException: Unable to post agent 
 control request as link is not available
   at com.cloud.agent.Agent.postRequest(Agent.java:690)
   at com.cloud.agent.Agent.postRequest(Agent.java:678)
   at 
 com.cloud.agent.resource.consoleproxy.ConsoleProxyResource.reportLoadInfo(ConsoleProxyResource.java:417)
   at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
   at java.lang.reflect.Method.invoke(Method.java:606)
   at 
 com.cloud.consoleproxy.ConsoleProxy.reportLoadInfo(ConsoleProxy.java:227)
   at 
 com.cloud.consoleproxy.ConsoleProxyGCThread.run(ConsoleProxyGCThread.java:102)
 2014-08-14 15:40:38,525 DEBUG [cloud.consoleproxy.ConsoleProxyGCThread] 
 (Console Proxy GC Thread:null) Report load change : {
   connections: []
 }
 2014-08-14 15:40:41,110 ERROR [utils.nio.NioConnection] (Agent-Selector:null) 
 Unable to initialize the threads.
 java.io.IOException: SSL: Fail to init SSL! java.io.IOException: Connection 
 closed with -1 on reading size.
   at com.cloud.utils.nio.NioClient.init(NioClient.java:87)
   at com.cloud.utils.nio.NioConnection.run(NioConnection.java:111)
   at java.lang.Thread.run(Thread.java:744)
 2014-08-14 15:40:43,526 DEBUG [cloud.consoleproxy.ConsoleProxyGCThread] 
 (Console Proxy GC Thread:null) connMap={}
 2014-08-14 15:40:43,526 INFO  [utils.exception.CSExceptionErrorCode] (Console 
 Proxy GC Thread:null) Could not find exception: 
 com.cloud.exception.AgentControlChannelException in error code list for 
 exceptions
 2014-08-14 15:40:43,526 ERROR [resource.consoleproxy.ConsoleProxyResource] 
 (Console Proxy GC Thread:null) Unable to send out load info due to Unable to 
 post agent control request as link is not available
 com.cloud.exception.AgentControlChannelException: Unable to post agent 
 control request as link is not available
   at com.cloud.agent.Agent.postRequest(Agent.java:690)
   at com.cloud.agent.Agent.postRequest(Agent.java:678)
   at 
 com.cloud.agent.resource.consoleproxy.ConsoleProxyResource.reportLoadInfo(ConsoleProxyResource.java:417)
   at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
   at java.lang.reflect.Method.invoke(Method.java:606)
   at 
 com.cloud.consoleproxy.ConsoleProxy.reportLoadInfo(ConsoleProxy.java:227)
   at 
 com.cloud.consoleproxy.ConsoleProxyGCThread.run(ConsoleProxyGCThread.java:102)
 2014-08-14 15:40:43,527 DEBUG [cloud.consoleproxy.ConsoleProxyGCThread] 
 (Console Proxy GC Thread:null) Report load change : {
   connections: []
 }
 2014-08-14 15:40:46,110 INFO  [cloud.agent.Agent] (Agent-Handler-1:null) 
 Reconnecting...
 2014-08-14 15:40:46,111 INFO  [utils.nio.NioClient] (Agent-Selector:null) 
 Connecting to 10.223.49.195:8250
 2014-08-14 15:40:48,527 DEBUG [cloud.consoleproxy.ConsoleProxyGCThread] 
 (Console Proxy GC Thread:null) connMap={}



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CLOUDSTACK-7350) Introduce the state 'Expunged' for vms when the vms are expunged.


 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Animesh Chaturvedi updated CLOUDSTACK-7350:
---

Priority: Major  (was: Critical)

 Introduce the state 'Expunged' for vms when the vms are expunged. 
 --

 Key: CLOUDSTACK-7350
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7350
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
Reporter: Nitin Mehta
 Fix For: 4.5.0


 Introduce the state 'Expunged' for vms when the vms are expunged. 
 Currently it statys in 'Expunging' state and is confusing for customers and  
 to understand whether it is gone or still expunging.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CLOUDSTACK-7350) Introduce the state 'Expunged' for vms when the vms are expunged.


 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Animesh Chaturvedi updated CLOUDSTACK-7350:
---

Issue Type: Improvement  (was: Bug)

 Introduce the state 'Expunged' for vms when the vms are expunged. 
 --

 Key: CLOUDSTACK-7350
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7350
 Project: CloudStack
  Issue Type: Improvement
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
Reporter: Nitin Mehta
Priority: Critical
 Fix For: 4.5.0


 Introduce the state 'Expunged' for vms when the vms are expunged. 
 Currently it statys in 'Expunging' state and is confusing for customers and  
 to understand whether it is gone or still expunging.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CLOUDSTACK-7350) Introduce the state 'Expunged' for vms when the vms are expunged.


 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Animesh Chaturvedi updated CLOUDSTACK-7350:
---

Issue Type: Bug  (was: Improvement)

 Introduce the state 'Expunged' for vms when the vms are expunged. 
 --

 Key: CLOUDSTACK-7350
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7350
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
Reporter: Nitin Mehta
Priority: Critical
 Fix For: 4.5.0


 Introduce the state 'Expunged' for vms when the vms are expunged. 
 Currently it statys in 'Expunging' state and is confusing for customers and  
 to understand whether it is gone or still expunging.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Created] (CLOUDSTACK-7396) [Automation] Failed to stop virtual router in KVM

Rayees Namathponnan created CLOUDSTACK-7396:
---

 Summary: [Automation] Failed to stop virtual router in KVM
 Key: CLOUDSTACK-7396
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7396
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Automation
Affects Versions: 4.5.0
Reporter: Rayees Namathponnan
Priority: Blocker
 Fix For: 4.5.0


This issue observed with latest automation run, Virtual router stop fails with 
below exception 

lhY2NvdW50SWRKAAZ1c2VySWRKAAR2bUlkTAALaGFuZGxlck5hbWV0ABJMamF2YS9sYW5nL1N0cmluZzt4cAABAAEC-XQAGVZpcn
R1YWxNYWNoaW5lTWFuYWdlckltcGwA, cmdVersion: 0, status: IN_PROGRESS, 
processStatus: 0, resultCode: 0, result: null, initMsid:
 29066118877352, completeMsid: null, lastUpdated: null, lastPolled: null, 
created: Thu Aug 21 22:24:10 PDT 2014}, job origin
:8131
com.cloud.utils.exception.CloudRuntimeException: Unable to stop 
VM[DomainRouter|r-761-VM]
at 
com.cloud.vm.VirtualMachineManagerImpl.advanceStop(VirtualMachineManagerImpl.java:1523)
at 
com.cloud.vm.VirtualMachineManagerImpl.orchestrateStop(VirtualMachineManagerImpl.java:1377)
at 
com.cloud.vm.VirtualMachineManagerImpl.orchestrateStop(VirtualMachineManagerImpl.java:4594)
at sun.reflect.GeneratedMethodAccessor162.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at 
com.cloud.vm.VmWorkJobHandlerProxy.handleVmWorkJob(VmWorkJobHandlerProxy.java:107)
at 
com.cloud.vm.VirtualMachineManagerImpl.handleVmWorkJob(VirtualMachineManagerImpl.java:4738)
at com.cloud.vm.VmWorkJobDispatcher.runJob(VmWorkJobDispatcher.java:102)
at 
org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:503)
at 
org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49)
at 
org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
at 
org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
at 
org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
at 
org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46)
at 
org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.run(AsyncJobManagerImpl.java:460)
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:744)
2014-08-21 22:24:11,959 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
(Work-Job-Executor-28:ctx-8824da69 job-8131/job-8162) Comple
te async job-8162, jobStatus: FAILED, resultCode: 0, result: 
rO0ABXNyABpqYXZhLmxhbmcuUnVudGltZUV4Y2VwdGlvbp5fBkcKNIPlAgAAeHI
AE2phdmEubGFuZy5FeGNlcHRpb27Q_R8-GjscxAIAAHhyABNqYXZhLmxhbmcuVGhyb3dhYmxl1cY1Jzl3uMsDAARMAAVjYXVzZXQAFUxqYXZhL2xhbmcvVGhyb3d
hYmxlO0wADWRldGFpbE1lc3NhZ2V0ABJMamF2YS9sYW5nL1N0cmluZztbAApzdGFja1RyYWNldAAeW0xqYXZhL2xhbmcvU3RhY2tUcmFjZUVsZW1lbnQ7TAAUc3V
wcHJlc3NlZEV4Y2VwdGlvbnN0ABBMamF2YS91dGlsL0xpc3Q7eHBxAH4AB3QAREpvYiBmYWlsZWQgZHVlIHRvIGV4Y2VwdGlvbiBVbmFibGUgdG8gc3RvcCBWTVt
Eb21haW5Sb3V0ZXJ8ci03NjEtVk1ddXIAHltMamF2YS5sYW5nLlN0YWNrVHJhY2VFbGVtZW50OwJGKjw8_SI5AgAAeHANc3IAG2phdmEubGFuZy5TdGFja1R
yYWNlRWxlbWVudGEJxZomNt2FAgAESQAKbGluZU51bWJlckwADmRlY2xhcmluZ0NsYXNzcQB-AARMAAhmaWxlTm





--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CLOUDSTACK-7396) [Automation] Failed to stop VPC router in KVM


 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rayees Namathponnan updated CLOUDSTACK-7396:


Description: 
This issue observed with latest automation run,  deploy a VPC router and stop 

Virtual router stop fails with below exception 



lhY2NvdW50SWRKAAZ1c2VySWRKAAR2bUlkTAALaGFuZGxlck5hbWV0ABJMamF2YS9sYW5nL1N0cmluZzt4cAABAAEC-XQAGVZpcn
R1YWxNYWNoaW5lTWFuYWdlckltcGwA, cmdVersion: 0, status: IN_PROGRESS, 
processStatus: 0, resultCode: 0, result: null, initMsid:
 29066118877352, completeMsid: null, lastUpdated: null, lastPolled: null, 
created: Thu Aug 21 22:24:10 PDT 2014}, job origin
:8131
com.cloud.utils.exception.CloudRuntimeException: Unable to stop 
VM[DomainRouter|r-761-VM]
at 
com.cloud.vm.VirtualMachineManagerImpl.advanceStop(VirtualMachineManagerImpl.java:1523)
at 
com.cloud.vm.VirtualMachineManagerImpl.orchestrateStop(VirtualMachineManagerImpl.java:1377)
at 
com.cloud.vm.VirtualMachineManagerImpl.orchestrateStop(VirtualMachineManagerImpl.java:4594)
at sun.reflect.GeneratedMethodAccessor162.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at 
com.cloud.vm.VmWorkJobHandlerProxy.handleVmWorkJob(VmWorkJobHandlerProxy.java:107)
at 
com.cloud.vm.VirtualMachineManagerImpl.handleVmWorkJob(VirtualMachineManagerImpl.java:4738)
at com.cloud.vm.VmWorkJobDispatcher.runJob(VmWorkJobDispatcher.java:102)
at 
org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:503)
at 
org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49)
at 
org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
at 
org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
at 
org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
at 
org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46)
at 
org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.run(AsyncJobManagerImpl.java:460)
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:744)
2014-08-21 22:24:11,959 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
(Work-Job-Executor-28:ctx-8824da69 job-8131/job-8162) Comple
te async job-8162, jobStatus: FAILED, resultCode: 0, result: 
rO0ABXNyABpqYXZhLmxhbmcuUnVudGltZUV4Y2VwdGlvbp5fBkcKNIPlAgAAeHI
AE2phdmEubGFuZy5FeGNlcHRpb27Q_R8-GjscxAIAAHhyABNqYXZhLmxhbmcuVGhyb3dhYmxl1cY1Jzl3uMsDAARMAAVjYXVzZXQAFUxqYXZhL2xhbmcvVGhyb3d
hYmxlO0wADWRldGFpbE1lc3NhZ2V0ABJMamF2YS9sYW5nL1N0cmluZztbAApzdGFja1RyYWNldAAeW0xqYXZhL2xhbmcvU3RhY2tUcmFjZUVsZW1lbnQ7TAAUc3V
wcHJlc3NlZEV4Y2VwdGlvbnN0ABBMamF2YS91dGlsL0xpc3Q7eHBxAH4AB3QAREpvYiBmYWlsZWQgZHVlIHRvIGV4Y2VwdGlvbiBVbmFibGUgdG8gc3RvcCBWTVt
Eb21haW5Sb3V0ZXJ8ci03NjEtVk1ddXIAHltMamF2YS5sYW5nLlN0YWNrVHJhY2VFbGVtZW50OwJGKjw8_SI5AgAAeHANc3IAG2phdmEubGFuZy5TdGFja1R
yYWNlRWxlbWVudGEJxZomNt2FAgAESQAKbGluZU51bWJlckwADmRlY2xhcmluZ0NsYXNzcQB-AARMAAhmaWxlTm



  was:
This issue observed with latest automation run, Virtual router stop fails with 
below exception 

lhY2NvdW50SWRKAAZ1c2VySWRKAAR2bUlkTAALaGFuZGxlck5hbWV0ABJMamF2YS9sYW5nL1N0cmluZzt4cAABAAEC-XQAGVZpcn
R1YWxNYWNoaW5lTWFuYWdlckltcGwA, cmdVersion: 0, status: IN_PROGRESS, 
processStatus: 0, resultCode: 0, result: null, initMsid:
 29066118877352, completeMsid: null, lastUpdated: null, lastPolled: null, 
created: Thu Aug 21 22:24:10 PDT 2014}, job origin
:8131
com.cloud.utils.exception.CloudRuntimeException: Unable to stop 
VM[DomainRouter|r-761-VM]
at 
com.cloud.vm.VirtualMachineManagerImpl.advanceStop(VirtualMachineManagerImpl.java:1523)
at 
com.cloud.vm.VirtualMachineManagerImpl.orchestrateStop(VirtualMachineManagerImpl.java:1377)
at 
com.cloud.vm.VirtualMachineManagerImpl.orchestrateStop(VirtualMachineManagerImpl.java:4594)
at sun.reflect.GeneratedMethodAccessor162.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at 
com.cloud.vm.VmWorkJobHandlerProxy.handleVmWorkJob(VmWorkJobHandlerProxy.java:107)
at

[jira] [Updated] (CLOUDSTACK-7396) [Automation] Failed to stop VPC router in KVM


 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rayees Namathponnan updated CLOUDSTACK-7396:


Description: 

This issue observed with latest automation run,  deploy a VPC router and stop 

Virtual router stop fails with below exception 

{noformat}

lhY2NvdW50SWRKAAZ1c2VySWRKAAR2bUlkTAALaGFuZGxlck5hbWV0ABJMamF2YS9sYW5nL1N0cmluZzt4cAABAAEC-XQAGVZpcn
R1YWxNYWNoaW5lTWFuYWdlckltcGwA, cmdVersion: 0, status: IN_PROGRESS, 
processStatus: 0, resultCode: 0, result: null, initMsid:
 29066118877352, completeMsid: null, lastUpdated: null, lastPolled: null, 
created: Thu Aug 21 22:24:10 PDT 2014}, job origin
:8131
com.cloud.utils.exception.CloudRuntimeException: Unable to stop 
VM[DomainRouter|r-761-VM]
at 
com.cloud.vm.VirtualMachineManagerImpl.advanceStop(VirtualMachineManagerImpl.java:1523)
at 
com.cloud.vm.VirtualMachineManagerImpl.orchestrateStop(VirtualMachineManagerImpl.java:1377)
at 
com.cloud.vm.VirtualMachineManagerImpl.orchestrateStop(VirtualMachineManagerImpl.java:4594)
at sun.reflect.GeneratedMethodAccessor162.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at 
com.cloud.vm.VmWorkJobHandlerProxy.handleVmWorkJob(VmWorkJobHandlerProxy.java:107)
at 
com.cloud.vm.VirtualMachineManagerImpl.handleVmWorkJob(VirtualMachineManagerImpl.java:4738)
at com.cloud.vm.VmWorkJobDispatcher.runJob(VmWorkJobDispatcher.java:102)
at 
org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:503)
at 
org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49)
at 
org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
at 
org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
at 
org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
at 
org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46)
at 
org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.run(AsyncJobManagerImpl.java:460)
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:744)
2014-08-21 22:24:11,959 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
(Work-Job-Executor-28:ctx-8824da69 job-8131/job-8162) Comple
te async job-8162, jobStatus: FAILED, resultCode: 0, result: 
rO0ABXNyABpqYXZhLmxhbmcuUnVudGltZUV4Y2VwdGlvbp5fBkcKNIPlAgAAeHI
AE2phdmEubGFuZy5FeGNlcHRpb27Q_R8-GjscxAIAAHhyABNqYXZhLmxhbmcuVGhyb3dhYmxl1cY1Jzl3uMsDAARMAAVjYXVzZXQAFUxqYXZhL2xhbmcvVGhyb3d
hYmxlO0wADWRldGFpbE1lc3NhZ2V0ABJMamF2YS9sYW5nL1N0cmluZztbAApzdGFja1RyYWNldAAeW0xqYXZhL2xhbmcvU3RhY2tUcmFjZUVsZW1lbnQ7TAAUc3V
wcHJlc3NlZEV4Y2VwdGlvbnN0ABBMamF2YS91dGlsL0xpc3Q7eHBxAH4AB3QAREpvYiBmYWlsZWQgZHVlIHRvIGV4Y2VwdGlvbiBVbmFibGUgdG8gc3RvcCBWTVt
Eb21haW5Sb3V0ZXJ8ci03NjEtVk1ddXIAHltMamF2YS5sYW5nLlN0YWNrVHJhY2VFbGVtZW50OwJGKjw8_SI5AgAAeHANc3IAG2phdmEubGFuZy5TdGFja1R
yYWNlRWxlbWVudGEJxZomNt2FAgAESQAKbGluZU51bWJlckwADmRlY2xhcmluZ0NsYXNzcQB-AARMAAhmaWxlTm


{noformat}

  was:
This issue observed with latest automation run,  deploy a VPC router and stop 

Virtual router stop fails with below exception 



lhY2NvdW50SWRKAAZ1c2VySWRKAAR2bUlkTAALaGFuZGxlck5hbWV0ABJMamF2YS9sYW5nL1N0cmluZzt4cAABAAEC-XQAGVZpcn
R1YWxNYWNoaW5lTWFuYWdlckltcGwA, cmdVersion: 0, status: IN_PROGRESS, 
processStatus: 0, resultCode: 0, result: null, initMsid:
 29066118877352, completeMsid: null, lastUpdated: null, lastPolled: null, 
created: Thu Aug 21 22:24:10 PDT 2014}, job origin
:8131
com.cloud.utils.exception.CloudRuntimeException: Unable to stop 
VM[DomainRouter|r-761-VM]
at 
com.cloud.vm.VirtualMachineManagerImpl.advanceStop(VirtualMachineManagerImpl.java:1523)
at 
com.cloud.vm.VirtualMachineManagerImpl.orchestrateStop(VirtualMachineManagerImpl.java:1377)
at 
com.cloud.vm.VirtualMachineManagerImpl.orchestrateStop(VirtualMachineManagerImpl.java:4594)
at sun.reflect.GeneratedMethodAccessor162.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at 
com.cloud.vm.VmWorkJobHandlerProxy.handleVmWorkJob(VmWorkJobHandlerProxy.java:107)
at

[jira] [Updated] (CLOUDSTACK-7396) [Automation] Failed to stop VPC router in KVM


 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rayees Namathponnan updated CLOUDSTACK-7396:


Summary: [Automation] Failed to stop VPC router in KVM  (was: [Automation] 
Failed to stop virtual router in KVM)

 [Automation] Failed to stop VPC router in KVM
 -

 Key: CLOUDSTACK-7396
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7396
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Automation
Affects Versions: 4.5.0
Reporter: Rayees Namathponnan
Priority: Blocker
 Fix For: 4.5.0


 This issue observed with latest automation run, Virtual router stop fails 
 with below exception 
 lhY2NvdW50SWRKAAZ1c2VySWRKAAR2bUlkTAALaGFuZGxlck5hbWV0ABJMamF2YS9sYW5nL1N0cmluZzt4cAABAAEC-XQAGVZpcn
 R1YWxNYWNoaW5lTWFuYWdlckltcGwA, cmdVersion: 0, status: IN_PROGRESS, 
 processStatus: 0, resultCode: 0, result: null, initMsid:
  29066118877352, completeMsid: null, lastUpdated: null, lastPolled: null, 
 created: Thu Aug 21 22:24:10 PDT 2014}, job origin
 :8131
 com.cloud.utils.exception.CloudRuntimeException: Unable to stop 
 VM[DomainRouter|r-761-VM]
 at 
 com.cloud.vm.VirtualMachineManagerImpl.advanceStop(VirtualMachineManagerImpl.java:1523)
 at 
 com.cloud.vm.VirtualMachineManagerImpl.orchestrateStop(VirtualMachineManagerImpl.java:1377)
 at 
 com.cloud.vm.VirtualMachineManagerImpl.orchestrateStop(VirtualMachineManagerImpl.java:4594)
 at sun.reflect.GeneratedMethodAccessor162.invoke(Unknown Source)
 at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 at java.lang.reflect.Method.invoke(Method.java:606)
 at 
 com.cloud.vm.VmWorkJobHandlerProxy.handleVmWorkJob(VmWorkJobHandlerProxy.java:107)
 at 
 com.cloud.vm.VirtualMachineManagerImpl.handleVmWorkJob(VirtualMachineManagerImpl.java:4738)
 at 
 com.cloud.vm.VmWorkJobDispatcher.runJob(VmWorkJobDispatcher.java:102)
 at 
 org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:503)
 at 
 org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49)
 at 
 org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
 at 
 org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
 at 
 org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
 at 
 org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46)
 at 
 org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.run(AsyncJobManagerImpl.java:460)
 at 
 java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
 at java.util.concurrent.FutureTask.run(FutureTask.java:262)
 at 
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
 at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
 at java.lang.Thread.run(Thread.java:744)
 2014-08-21 22:24:11,959 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
 (Work-Job-Executor-28:ctx-8824da69 job-8131/job-8162) Comple
 te async job-8162, jobStatus: FAILED, resultCode: 0, result: 
 rO0ABXNyABpqYXZhLmxhbmcuUnVudGltZUV4Y2VwdGlvbp5fBkcKNIPlAgAAeHI
 AE2phdmEubGFuZy5FeGNlcHRpb27Q_R8-GjscxAIAAHhyABNqYXZhLmxhbmcuVGhyb3dhYmxl1cY1Jzl3uMsDAARMAAVjYXVzZXQAFUxqYXZhL2xhbmcvVGhyb3d
 hYmxlO0wADWRldGFpbE1lc3NhZ2V0ABJMamF2YS9sYW5nL1N0cmluZztbAApzdGFja1RyYWNldAAeW0xqYXZhL2xhbmcvU3RhY2tUcmFjZUVsZW1lbnQ7TAAUc3V
 wcHJlc3NlZEV4Y2VwdGlvbnN0ABBMamF2YS91dGlsL0xpc3Q7eHBxAH4AB3QAREpvYiBmYWlsZWQgZHVlIHRvIGV4Y2VwdGlvbiBVbmFibGUgdG8gc3RvcCBWTVt
 Eb21haW5Sb3V0ZXJ8ci03NjEtVk1ddXIAHltMamF2YS5sYW5nLlN0YWNrVHJhY2VFbGVtZW50OwJGKjw8_SI5AgAAeHANc3IAG2phdmEubGFuZy5TdGFja1R
 yYWNlRWxlbWVudGEJxZomNt2FAgAESQAKbGluZU51bWJlckwADmRlY2xhcmluZ0NsYXNzcQB-AARMAAhmaWxlTm



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CLOUDSTACK-7396) [Automation] Failed to stop VPC router in KVM


 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rayees Namathponnan updated CLOUDSTACK-7396:


Attachment: kvm.sql
management-server.rar

Attaching MS log and SQL dump 

 [Automation] Failed to stop VPC router in KVM
 -

 Key: CLOUDSTACK-7396
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7396
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public(Anyone can view this level - this is the 
 default.) 
  Components: Automation
Affects Versions: 4.5.0
Reporter: Rayees Namathponnan
Priority: Blocker
 Fix For: 4.5.0

 Attachments: kvm.sql, management-server.rar


 This issue observed with latest automation run,  deploy a VPC router and stop 
 Virtual router stop fails with below exception 
 {noformat}
 lhY2NvdW50SWRKAAZ1c2VySWRKAAR2bUlkTAALaGFuZGxlck5hbWV0ABJMamF2YS9sYW5nL1N0cmluZzt4cAABAAEC-XQAGVZpcn
 R1YWxNYWNoaW5lTWFuYWdlckltcGwA, cmdVersion: 0, status: IN_PROGRESS, 
 processStatus: 0, resultCode: 0, result: null, initMsid:
  29066118877352, completeMsid: null, lastUpdated: null, lastPolled: null, 
 created: Thu Aug 21 22:24:10 PDT 2014}, job origin
 :8131
 com.cloud.utils.exception.CloudRuntimeException: Unable to stop 
 VM[DomainRouter|r-761-VM]
 at 
 com.cloud.vm.VirtualMachineManagerImpl.advanceStop(VirtualMachineManagerImpl.java:1523)
 at 
 com.cloud.vm.VirtualMachineManagerImpl.orchestrateStop(VirtualMachineManagerImpl.java:1377)
 at 
 com.cloud.vm.VirtualMachineManagerImpl.orchestrateStop(VirtualMachineManagerImpl.java:4594)
 at sun.reflect.GeneratedMethodAccessor162.invoke(Unknown Source)
 at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 at java.lang.reflect.Method.invoke(Method.java:606)
 at 
 com.cloud.vm.VmWorkJobHandlerProxy.handleVmWorkJob(VmWorkJobHandlerProxy.java:107)
 at 
 com.cloud.vm.VirtualMachineManagerImpl.handleVmWorkJob(VirtualMachineManagerImpl.java:4738)
 at 
 com.cloud.vm.VmWorkJobDispatcher.runJob(VmWorkJobDispatcher.java:102)
 at 
 org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:503)
 at 
 org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49)
 at 
 org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56)
 at 
 org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103)
 at 
 org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53)
 at 
 org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46)
 at 
 org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.run(AsyncJobManagerImpl.java:460)
 at 
 java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
 at java.util.concurrent.FutureTask.run(FutureTask.java:262)
 at 
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
 at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
 at java.lang.Thread.run(Thread.java:744)
 2014-08-21 22:24:11,959 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl] 
 (Work-Job-Executor-28:ctx-8824da69 job-8131/job-8162) Comple
 te async job-8162, jobStatus: FAILED, resultCode: 0, result: 
 rO0ABXNyABpqYXZhLmxhbmcuUnVudGltZUV4Y2VwdGlvbp5fBkcKNIPlAgAAeHI
 AE2phdmEubGFuZy5FeGNlcHRpb27Q_R8-GjscxAIAAHhyABNqYXZhLmxhbmcuVGhyb3dhYmxl1cY1Jzl3uMsDAARMAAVjYXVzZXQAFUxqYXZhL2xhbmcvVGhyb3d
 hYmxlO0wADWRldGFpbE1lc3NhZ2V0ABJMamF2YS9sYW5nL1N0cmluZztbAApzdGFja1RyYWNldAAeW0xqYXZhL2xhbmcvU3RhY2tUcmFjZUVsZW1lbnQ7TAAUc3V
 wcHJlc3NlZEV4Y2VwdGlvbnN0ABBMamF2YS91dGlsL0xpc3Q7eHBxAH4AB3QAREpvYiBmYWlsZWQgZHVlIHRvIGV4Y2VwdGlvbiBVbmFibGUgdG8gc3RvcCBWTVt
 Eb21haW5Sb3V0ZXJ8ci03NjEtVk1ddXIAHltMamF2YS5sYW5nLlN0YWNrVHJhY2VFbGVtZW50OwJGKjw8_SI5AgAAeHANc3IAG2phdmEubGFuZy5TdGFja1R
 yYWNlRWxlbWVudGEJxZomNt2FAgAESQAKbGluZU51bWJlckwADmRlY2xhcmluZ0NsYXNzcQB-AARMAAhmaWxlTm
 {noformat}



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (CLOUDSTACK-7396) [Automation] Failed to stop VPC router in KVM